Making sense of agile

This will be a two-part blog post to illustrate why companies should consider adopting the agile way of working more readily and thoroughly. This first part is a bit more theoretical while the second part will feature a real-life example of a team’s journey to maximise the potential of working in an agile fashion.

The larger companies are, the harder it usually becomes to switch from classical management styles to agile. My ambition is not to answer all potential questions that such a transformation would inevitably trigger, but rather to illustrate what the agile mindset entails and why it can bring value both at company level and to individual human beings.

If you’re already a convinced agilist, this isn’t really targeted at you, but I hope you’ll still find this article useful 😊 If on the other hand, you are sceptical of all things agile, then please read on!

When do we need it anyway?

When you’re an avid fan of all things agile it’s easy to lose sight of this fundamental question: when is the agile way of doing things preferable over more classical ways of doing projects? The mere fact that one enjoys and prefers the agile approach shouldn’t blind one from the fact that there are indeed still circumstances where an applying waterfall is a valid option. However, as we’ll show below, this domain is rather limited when considering the key determining factors.

Enter the Stacey matrix. Professor of Management Ralph D. Stacey is an authority when it comes to complexity analysis for better understanding of human organisations and their management. He developed a matrix model to approach complex situations in management settings which is useful for selecting appropriate management actions in complex adaptive situations. For a quick primer on the basic model, see here.

The model can also be of use when pondering whether agile or waterfall methodology is more suitable for a given quadrant. This is done by replacing agreement with (agreement on) business requirements and certainty with technological tools.

Requirements capture WHAT solution must be built and Technology unveils HOW to provide the solution. The dimensions range from the clear or known, to the vague or unknown. The quantity of people involved gives a softer, yet third dimension that also directly increases the complexity.

This brings us to the following adapted overview as created by Terrence Metz from MG Rush Facilitation.

So basically you need to evaluate what your business environment looks like and which quadrant best represents your specific situation. In my opinion, delimiting your relevant environment also matters a lot. The above diagram deals with the company level, but the larger your company and the more isolated your place of operation in it, the more relevant it may become to apply this classification specifically to your (smaller) frame of reference.

What’s that smell …

For many people who haven’t had hands-on experience with agile, there’s still the smell of “project management hype” associated with it. This is unfortunate for a number of reasons.

First of all, “agile” is not a project management methodology or framework, unlike many of the more classic methodologies like PMI/PMBOK, PRINCE2, Waterfall or CPM which have dominated most industries for many years. It is rather a mindset which conveys several core values and principles as guiding concepts.

As it happens there are many frameworks and methodologies which conform in varying degrees to this agile mindset and they all offer guidance in working differently from the classical project management methodologies mentioned above. Where the classic methodologies heavily rely on the command and control style and strict process control to steer the course of a project, agile methods like for example Scrum, Kanban, Lean or XP will stimulate human interaction and cooperation (both within teams and with the customer), adapting to changing requirements and frequent self-reflection to foster continuous improvement in the team’s way of working. The higher goal remains to deliver value for the customer early and continuously while working at a sustainable pace.

This capacity to adapt to changing requirements while continuously delivering value is what attracts businesses to the agile way of working, because the swifter they can steer their product deliveries to market, the better they are placed to serve their customer’s needs. When their less agile competitors finally get their competing products and services to the market they may find out nobody’s waiting for them anymore because there’s another party already serving their needs and continuously upgrading their products and services. So, the more competitive your market, the more efficient you will be forced to become in pleasing your customers or risk being forced out of the market by competitors who do it better. Customers vote with their wallets!

The human factor

There’s also another dimension to agile which makes its adoption in companies almost natural when done right. This is the explicit intent of agile to work with motivated individuals in a suitable environment and trusting them to get the job done. This is a never to be underestimated basic agile principle: empower teams to grow as mature human beings who are happy to do the best they can and take responsibility for both their steady delivery of added value and their continuous evolution towards ever more capable human beings. For many people this different approach between command and control versus trust and shared responsibility will be the deciding factor on how (and where) they want to work as professional human beings. In agile every team member has equal opportunity to contribute, to experiment with ways to improve the team’s way of working, to sometimes fail but learn from the experience. There is no way to self-improve without taking risks and doing small, well motivated experiments. I’ve yet to see a Gantt chart which can capture this as a continuous self-improvement effort which benefits the entire project delivery.

Naturally, this may prompt questions on how budgeting is done in agile projects, but I’ll leave that for another blog post. Suffice it to say that when going agile it’s important to not just try cherry-picking but rather go for the entire set of values and principles if you expect the best return on investment. After all, what good is visiting a physician if you aren’t prepared to follow the professional medical advice you’re given to cure yourself?

In the next part I will talk about a sample team’s agile experience within a company that’s still largely using command and control as its generally preferred way of working, so stay tuned.