Sunday, December 6, 2015

You, too, can increase agility!

Individuals stuck in a classic waterfall organizations often ask "How can I be agile here?" - and quickly conclude, "I can't". This, however, is untrue. You can be agile. You will never be as agile as someone working in an agile organisation, but you still can be agile.

There are different levels at which agility can be realized in an organisation:

Agility affects all of these levels.

You can always influence some of these things, but you can not change all of them. If you are working at organizational level, agile practices are beyond your scope. Likewise, if you work as an individual developer, the structure of the organisation is beyond your scope.

Here are just a few pointers on how you can increase agility on your level:

Practice Level

Every developer is in charge of their own work. Agile engineering practices, such as for example Clean Code, Refactoring, Test Driven Development and Emergent Design are completely up to you.
While developers can not expect a traditional Project Manager to give them freedom for completely refactoring your 12m LOC legacy code or add unit tests to everything, there is nothing stopping you from writing better code today.
As a developer, you can increase practice level agility and convince others by results. Even if others are not convinced, you will be more agile than if you do not heed these practices.

Your primary constraint will be the scope of your work. You must accept that you alone can not save the Whales and that unless your organization supports wider practices like Scrum or Continuous Integration, you can only improve your own work.

Team level

Depending on how agile your organization already is, you may have "agile teams" already - or you may be led by a team lead. Assuming you are in either of these positions, the entire structure and practice of the team is up to you.
Even if your Product/Project/Line manager dictates the work items and their deadlines, you still can practice additional agility with your team.
Continuous Integration, Pair Programming, Standups, Retrospectives and Reviews are just examples of good agile practices that will all increase the quality of your work and the credibility of your team.
As a team, you can do all of this - as a Team Lead, you can direct your team in this direction to increase team level agility.

Your primary constraint will be the Product/Project context. You must accept that agile teams will not make unrealistic expectations more realistic and and that wrong plans do not automatically correct themselves.

Product Level

Gaining the freedom to develop an entire agile product is a large step in many organisations. To be agile at product level requires a lot of discipline and dedication.
Product level agile practices include working with a backlog, prioritizing and delivering by value, building increments, permitting room for learning and feedback in the product delivery cycle etc. Additionally, you must build your teams and processes around your product rather than vice versa.
As a Product Manager / Product Owner, you can institute all of this with the backing of your developers.

Your primary constraint will be that you need practice and team level agility, to succeed with product level agility. You must also accept that if the outside organization is still arranged in silos, you will still not build the optimal product and be fighting many political battles.

Organisation Level

Working with an entire organisation to increase agility is the best way to remove global impediments. However, you can not simply declare, "From tomorrow, we will be agile". Command and Control mindset will most likely still be ingrained within your organisation and silo structures will be rooted much deeper than org charts.
Organisation level agility can be supported by top management and can be stepwise instituted by middle management, but this level is very slow and requires much patience. 
As upper/middle manager, you can encourage higher agility and remove impediments during the Agile transformation. You can provide training, get coaching for yourselves and agile practitioners - but then that's about it. As an agile manager, your responsibility is not telling others what to do - but to provide freedom to make decisions and learn from mistakes. However, early on in the transformation, your responsibility is also enablement to make informed decisions and deal with ignorance.

Your primary constraint working on an organisation level is the current state of the organisation and the mindset of the workforce. You must accept that by doing things and making decisions for the teams, you are quite likely being counter-productive - so your biggest impediment is actually the entire non-agile organisation and everyone who is stuck in a traditional mindset. 


Regardless of where you are, you can do something to be more agile. Taking small steps is actually easier and faster at practice level - but the "big wins" are made slowly on organisation level. For maximum effectivity, all four must go hand in hand.

The "engine" of agile transformation

Everyone can do something to be a little bit more agile tomorrow. You can take small, thoughful steps: Grind the gears, but consider the whole picture. Moving too fast in one place might break the entire approach. Have patience.

No comments:

Post a Comment