Having been ‘doing’ both Waterfall and Agile for quite some time now I feel fairly qualified to point out the idiosyncrasies in both approaches. None of these approaches is completely wrong, and equally, none of these approaches is completely right. It all depends on the circumstances, the organizational maturity, attitude, culture and inclination.

So, while I have had my fair share of frustrations with pure command-and-control organizations, my beef today is with Agile advocates that are exhibiting less than agile attitude when attempting to bring Agile into large command-and-control environments.

The scenario I’m referring to is as follows:

An organization with long and established ‘Waterfall’ methodology and way of working is convinced to give Agile a go. The Agile practice is getting momentum in certain quarters of the organization and the Agile portfolio is steadily growing. While it is growing in absolute numbers, in relative terms it is still but a small percentage of the overall development effort managed throughout the organization. Furthermore, crucial support services, like Release Management, Production Support, Infrastructure deployment, Enterprise Architecture, Enterprise Testing, and others are not yet fully integrated into the “Agile way of working” and are still operating with what would, traditionally, be referred to as Waterfall.

The reality in such circumstances is that while the software development aspect of the project/program can utilize Agile methods, the project in its entirety is still bound to interface with non Agile delivery teams, operating with a different cadence, different milestones, and different operational requirements.

For Agile professionals, such an environment is an ongoing challenge. It requires them to accept that being adaptive also means being able to operate within a Waterfall set of constraints. Integrating Agile into a Waterfall, command-and-control organization is not a nuisance, it is not a hindrance, it is not an anomaly, it is just the way things are.

Clearly, “operating” Agile in a fully ‘Agile-committed’ organization is relatively straight forward but many organisations are not yet adapted to allow for Agile practices to flow through the organisation structure, and in such cases, being insistent of doing ‘pure’ agile is not just childish but also unproductive at all levels. Attempting to force Agility down an organization is not being able to accept the fact that agile does not operate in an organizational vacuum. As an agile professional you need to remember that it is not the ideology that is important but rather the ability of the organization to reap the benefits of its technology investments.

Think about it!

Related Post

Letter to a Young Project Manager Dear L.J. We have barely met and had only the brief and passing opportunity to exchange a mere few words before a daunting and sombre thought enter...
The First Ever PM FlashBlog is Coming to a Blog Ne... Over the past couple of weeks I have been in touch with dozens of project management related bloggers to organize the first ever coordinated blogging ...
The Ten Commandments of Project Management Over the years I've seen many attempts to construct the "10 commandments of project management". I believe there is an element of cheekiness in this a...
The Secret to Clearing the PMP Certification Exam ... The Project Management Body of Knowledge (PMBOK) The PMBOK, published by the PMI, is a compilation of the project management guidelines to be adopted...

I haven’t been here for awhile and while I’ve been busy (actually, very busy) I couldn’t resist the following message:

WISHFUL THINKING IS NOT A RECOMMENDED RISK MITIGATION STRATEGY

Think about it!

Related Post

Letter to a Young Project Manager Dear L.J. We have barely met and had only the brief and passing opportunity to exchange a mere few words before a daunting and sombre thought enter...
The First Ever PM FlashBlog is Coming to a Blog Ne... Over the past couple of weeks I have been in touch with dozens of project management related bloggers to organize the first ever coordinated blogging ...
The Ten Commandments of Project Management Over the years I've seen many attempts to construct the "10 commandments of project management". I believe there is an element of cheekiness in this a...
The Secret to Clearing the PMP Certification Exam ... The Project Management Body of Knowledge (PMBOK) The PMBOK, published by the PMI, is a compilation of the project management guidelines to be adopted...

I had the pleasure of presenting at the Australia PMI Conference in Melbourne yesterday. The topic was “Transform yourself from Traditional to Agile Project Manager”.

 

Related Post

Letter to a Young Project Manager Dear L.J. We have barely met and had only the brief and passing opportunity to exchange a mere few words before a daunting and sombre thought enter...
The First Ever PM FlashBlog is Coming to a Blog Ne... Over the past couple of weeks I have been in touch with dozens of project management related bloggers to organize the first ever coordinated blogging ...
The Ten Commandments of Project Management Over the years I've seen many attempts to construct the "10 commandments of project management". I believe there is an element of cheekiness in this a...
The Secret to Clearing the PMP Certification Exam ... The Project Management Body of Knowledge (PMBOK) The PMBOK, published by the PMI, is a compilation of the project management guidelines to be adopted...

 

In case you’re in Melbourne early September and happen to attend the Australian PMI Conference don’t forget to look me up. I will be presenting a session on “Transform yourself from traditional to Agile project manager”.

Here’s my submitted abstract:

For many ‘traditional’ project managers the encounter with agile and agility is a confrontational one. While many project managers have been trained in the art of project management based on a set of governance principles grounded in command-and-control related management techniques; managing projects in the 21st Century is developing in an environment in which agility, collaboration, exploration and adaptation are the key. This session will highlight the key issues facing project managers wishing to engage in this transition, explore the key dimensions – behavioural, conceptual and psychological – associated with this transformational change and provide a road map and a range of helpful tips for a successful incorporation of agile principles into any mode of project management, irrespective of the environment in which it will be executed.

I am hoping that by the end of the session the participants will:
1. Understand the conceptual differences between traditional project management methodologies and agile management principles
2. Be equipped with a set of tips for the incorporation of Lean and Agile principles, values and techniques in your project management activities – irrespective of the type of project management methodology you use for your projects.
3. Have a better understanding of Agile project management terminology.

Let me know if you’re going to attend and please come and introduce yourself.

Related Post

Letter to a Young Project Manager Dear L.J. We have barely met and had only the brief and passing opportunity to exchange a mere few words before a daunting and sombre thought enter...
The First Ever PM FlashBlog is Coming to a Blog Ne... Over the past couple of weeks I have been in touch with dozens of project management related bloggers to organize the first ever coordinated blogging ...
The Ten Commandments of Project Management Over the years I've seen many attempts to construct the "10 commandments of project management". I believe there is an element of cheekiness in this a...
The Secret to Clearing the PMP Certification Exam ... The Project Management Body of Knowledge (PMBOK) The PMBOK, published by the PMI, is a compilation of the project management guidelines to be adopted...

I come across many people that call themselves ‘coaches’.

I come across ‘coaches’ that certainly ‘talk the talk’ but have no real experience to back that up.

And here’s my dilemma:

Should I take such coaches seriously?

Can one become a coach by knowing the domain (as opposed to ‘doing’ in the domain)?

Am I just too damn closed minded?

Think about it!

Related Post

Letter to a Young Project Manager Dear L.J. We have barely met and had only the brief and passing opportunity to exchange a mere few words before a daunting and sombre thought enter...
The First Ever PM FlashBlog is Coming to a Blog Ne... Over the past couple of weeks I have been in touch with dozens of project management related bloggers to organize the first ever coordinated blogging ...
The Ten Commandments of Project Management Over the years I've seen many attempts to construct the "10 commandments of project management". I believe there is an element of cheekiness in this a...
The Secret to Clearing the PMP Certification Exam ... The Project Management Body of Knowledge (PMBOK) The PMBOK, published by the PMI, is a compilation of the project management guidelines to be adopted...
29. July 2014 · 9 comments · Categories: Agile

Retrospections

Like many things in life, Retrospective – as a concept – can have many layers of abstraction.

At the superficial level it can be used to identify symptoms and find ways dealing with them.

At a deeper level it can be used to highlight symptoms and attempt a rudimentary root-cause-analysis and possible experiments to address them.

At a fundamental level it can be used to highlight symptoms, explore their causes and explore the attitudes and motivations that need changing in order to better address such occurrences in the future.

If I understand this correctly, deeper retrospection and reflection require the investment of higher levels of cognitive effort. This investment, though, is likely to result in longer term benefits (compared with lower levels of retrospections).

While I can ‘see’ the benefits individuals can gain from exercising higher levels of retrospection, as they can gain better insights into themselves, their attitudes and their behaviours; I am not clear on the benefits to the organization. Are there clear, tangible, measurable benefits that would make the extra investment – in coaching and guiding teams to achieve this level – justifiable? I am still looking for the evidence.

Think about it.

Related Post

Is The Time Ripe For The Agile Revolution? One of my favourite books (and films) is "The Lord of the Rings". There are many situations presented in this book which make me pause, think and cont...
All About Awkward Agile Thinking People love slogans. They love slogans because they need something to hang on to. A stake in the ground, a beacon they can point their sinking ship to...
Implementing Earned Value Management in Agile Introduction The purpose of this article is to illustrate the way in which the Earned Value Measurement (EVM) approach is introduced into an Agile de...
Let’s Be Serious About the Agile Manifesto The Agile Manifesto states that: We are uncovering better ways of developing software by doing it and helping others do it. Through this work we ha...
25. July 2014 · Write a comment · Categories: Agile

The four weeks or so that have now passes since the Agile 2014 Conference in Melbourne have given me the opportunity to reflect on the conference and consider some of the presentations and messages I have been exposed to.

While the theme of the conference was Embracing Disruption, and while a number of the key note presentations were about Business Disruption, there was little in terms of providing hands-on, practical, implementable clues or ideas for ‘how to elicit disruption’. It is widely accepted that Agile is a vehicle for disruption. While this was certainly true in the earlier days, when Agile had to make its case and increase its market penetration, this is no longer (at least not so explicitly) the case. The level of disruption ascribed to Agile in the earlier days is no longer sufficient to refer to Agile as a disruptive force. We now need new ideas as what used to be disruptive yesterday is today’s norm.

There were two presentations, out of the one’s I’ve attended, that I believe fit the bill. One was the talk titled “Holacracy at Zappos – how do you manage to deliver value when ‘anything goes’?” by Geoff Apps, Director of Engineering at Zappos; and the other titled “Making sense of complexity by designing dynamic environments: The Lens” by Daryl Chan and Martin Kearns.

The idea behind Holacracy is ground breaking. Whether one takes this concept as a positive or negative approach to organizational structure (and associated roles and responsibilities), most will agree that this is a disruptive idea. It takes the idea of ‘self-managed teams’ one step forward and turns if from a small scale, agile development team approach to an enterprise wide adoption.

The Lens concept is about taking the adaptive nature of Agile and turning it into an enterprise level tool. It takes the Kanban Wall concept one (giant) step forward by incorporating into a visual wall the data and information where all employees (at ALL levels) can obtain and share insights regarding the overall scope of the organization’s operations.

To keep Agile relevant, to keep Agile vibrant, we need to focus on this level of discourse where Agile practitioners are encouraged to remain disruptive well beyond the known boundaries originally created for this disruption.

Think about it.

Related Post

Is The Time Ripe For The Agile Revolution? One of my favourite books (and films) is "The Lord of the Rings". There are many situations presented in this book which make me pause, think and cont...
All About Awkward Agile Thinking People love slogans. They love slogans because they need something to hang on to. A stake in the ground, a beacon they can point their sinking ship to...
Implementing Earned Value Management in Agile Introduction The purpose of this article is to illustrate the way in which the Earned Value Measurement (EVM) approach is introduced into an Agile de...
Let’s Be Serious About the Agile Manifesto The Agile Manifesto states that: We are uncovering better ways of developing software by doing it and helping others do it. Through this work we ha...

Just finished reading David and Goliath: Underdogs, Misfits, and the Art of Battling Giants (note: affiliated link) by Malcolm Gladwell.

The key premise of the book is that things are not what they seem to be. More specifically, using a number of real life examples, it demonstrates how situations they seem to be advantageous are really (in some circumstances) an indication of disadvantage and similarly, situations where the odds seem to be stacked against the main character result in a favorite outcome.

The book also questions the notion that bigger challenges require a stronger response (such as the natural tendency to apply more and stronger policing in situations where there is an apparent increase in crime) and introduces the notion of the U Curve, suggesting that doing more of something results in positive results, but only up to a point. Doing more of that thing after that point could result in negative consequences. The concept is easy to understand and to apply. For example, communicating with project stakeholders can result in tangible benefits as stakeholders are comfortable that the project is adequately managed. More communication could also be beneficial, but up to a point. If you swamp them with too much or too frequent information you will likely lose their good will and their attention. Just an example.

Think about it!

 

18. July 2014 · 4 comments · Categories: Agile

The Agile story, at some levels is a rosy one. A Manifesto that stipulates a set of values, a collection of principles that underpins these values and teams of people of different skills working together in collaboration and harmony to deliver value in the most efficient and lean way.

Behind the scenes however, organizational politics, power games and internal manoeuvring have the motive and the opportunity to use some of these values and principles in a manner not intended for originally.

Take for example the following principle:

We welcome changing requirements, even late in the development. Agile processes harness change for the customer’s competitive advantage.

On the surface, and taking this statement at face value, this is a deceleration aimed at celebrating the flexibility and adaptability of agile teams to the ever-present changing requirements. Being able to change direction and support the business in a changing landscape is one of the areas where Agile and Lean provide better value for money. This, however, assumes that people are playing it fair and this, I suspect, is a big assumption to make. If there is anything we’ve learned from behavioural economics is the fact that what you see is not necessarily what you get. Put differently, people’s behaviour is seldom rational and even when it is, one person’s rationale will not be the same as the next person, even when they shout the same slogans.

The agile principle of adapting to changing requirements can therefore be used as a pretext for pretentious commitment to a certain scope with a hidden agenda to water down that scope citing ‘being agile’ (i.e. being adaptive to changing circumstances) as the reason for that subsequent (and pre-meditated) change. This is a level of gaming the system that is often hidden from the team members and is played by competing sponsors and stakeholders. Not wanting to be seen to be lacking in support to a certain idea they provide a lip service with no intention to seeing this going through to a completion.

So what does it really mean:

At the practical level it doesn’t mean much. Sponsors and stakeholders have always had the capacity to disturb (or enhance – depending on your view point) project direction. Agile, nevertheless, provide such behaviours with a ‘get out of jail’ card. It provides a level of legitimacy that now turns such attitude into a perceived win, a perceived ‘good behaviour’. Lack of commitment could be seen by the wider community as a sign of intense agility and adaptability – clearly not in the spirit of the agile intent.

Think about it!

Related Post

Is The Time Ripe For The Agile Revolution? One of my favourite books (and films) is "The Lord of the Rings". There are many situations presented in this book which make me pause, think and cont...
All About Awkward Agile Thinking People love slogans. They love slogans because they need something to hang on to. A stake in the ground, a beacon they can point their sinking ship to...
Implementing Earned Value Management in Agile Introduction The purpose of this article is to illustrate the way in which the Earned Value Measurement (EVM) approach is introduced into an Agile de...
Let’s Be Serious About the Agile Manifesto The Agile Manifesto states that: We are uncovering better ways of developing software by doing it and helping others do it. Through this work we ha...

George Bernard Shaw once put it:

The reasonable man adapts himself to the world: the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man.

Think about it!

Related Post

Letter to a Young Project Manager Dear L.J. We have barely met and had only the brief and passing opportunity to exchange a mere few words before a daunting and sombre thought enter...
The First Ever PM FlashBlog is Coming to a Blog Ne... Over the past couple of weeks I have been in touch with dozens of project management related bloggers to organize the first ever coordinated blogging ...
The Ten Commandments of Project Management Over the years I've seen many attempts to construct the "10 commandments of project management". I believe there is an element of cheekiness in this a...
The Secret to Clearing the PMP Certification Exam ... The Project Management Body of Knowledge (PMBOK) The PMBOK, published by the PMI, is a compilation of the project management guidelines to be adopted...
%d bloggers like this: