Agile Pitfall #1: You Don’t Know What You Don’t Know (aka Missing the 'Shu' Phase)

Many teams I worked with were 'Agile' for years. Unfortunately, more experience doesn’t equate with good agile practices. If not executed well instead of flourishing things fall apart, agile becomes a punching bag for all things gone wrong and processes reverse to old, known (and unfortunately failing) ways of working.

Succeeding in agile may be difficult if there is a loss of faith; more difficult than starting from the traditional, plan-based approach. When beginning our journey it at least seems promising. There is an alternative way of doing things - this new, exciting agile way which has a potential to solve our problems. However, what is now our alternative for agile? More often the answer is a strange agile hybrid which changes frequently, different sides pull in different directions and overall, work becomes chaotic.

Root Causes aka when does 'Shu' pitfall happen?

As we learn or need to adapt to new things, there are few phases we need to pass to master it. This is well described in Aikido martial arts with 守-破-離 [Shu-Ha-Ri] i.e. Obey-Digress-Transcend:

1. 守 Shu - obey the rules or have no deviation from your teachings
2. 破 Ha - digress or break the rules and finally
3. 離 Ri - make the rules or transcend.

For agile adoption, the problems can arise when we think to be done with 'Shu' phase. If this happens too early we never see the true colors of agile and ways to improve it. This is because we don’t know it. More problems can come if we have a poor teacher - then we can never go beyond 'Shu'. Our knowledge is either incomplete, dead-wrong or both. If we start to break rules and create new ones without Shu, our ways of working can as well be made up of thin air. Lets look at some examples where things can go wrong.

When we pancake the roles

Thinking that ScM can also be a developer, PO a ScM etc creates confusion and discord in the team. Yes, we do need full time ScM. If it seems it is not ‘doing’ enough - it isn’t and it shouldn’t. At least not as visible as development team members. This is because it is not part of development team - could this be for a reason?

When we skip the ceremonies

More often than not, ScM is like a rooster announcing that daily stand-up should start. Demo meetings are held just sometimes, and reviews every few quarters. Since agile works on the principles of inspect and adapt, without properly held ceremonies, the core values are left out.

When we don’t understand core agile values

No, ‘Working software over comprehensive documentation’ does not mean documentation is optional or non-existent. Just look at Apple or any other successful company - there are always good product guidelines.

Solutions aka what to do when you notice 'Shu' pitfall?

A good coaching answer would be: start from yourself. Make sure your Shu is well established. For this I would recommend going to a credited course or getting a certification from an established institution. (My recommendation is PMI-ACP. Even though it is not as easy, it is beneficial for every day work since it is not based on memorization but situations and understandings of agile mindset.) It is easy to fall in trap of believing that few in-house courses or experience alone is enough. Even the most experienced agilists are open to new ideas and have a thirst to learn from experts in the field.

On the other hand, if you are a ScM, Agile Coach, PO or other member of the team and notice that there are many things to be learned and unlearned AND change it within yourself, it is still not enough to solve this pitfall. Firstly, this is because we are talking about agile adoption which is much bigger than one team. Unless you are a CEO, or have the authority and support to change work of whole department, you may be the lone rider starting the journey no one follows. Rest assured that if you try to change your team without the support from your manager it will fall through. In order for organisations to change it should start top-down. This means having educated line managers with enough expertise in Agile, who are not going to give up when the going gets tough. Secondly, the change is hard because it requires consciousness. To know that there is something you don't know you need to be conscious of the fact, and since this is not related to knowledge itself it is not as easily seen or understood.

So, what do you do if you are not CEO or LM? The answer may be nothing. Alone you cannot make a change, but I wouldn’t give up just yet. If you truly care about your organisation have in-depth talk with your LM or someone who has the power to make a change. Share your observations and ideas with them. It may not make sense to them now, but they might remember it when things start to fall further apart. They might think about what you said and decide on a change. If not, the last resort is to go in the environment which is ready to implement agile and your expertise.

Refrences

1. Agile Retrospectives – Making Good Teams Great, by: Esther Derby, Diana Larsen, Ken Schwaber
2. Agile Software Development: The Cooperative Game, by: Alistair Cockburn
3. The Software Project Manager’s Bridge to Agility, by: Michele Sliger, Stacia Broderick
4. Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition, by: Lyssa Adkins
5. Agile Project Management: Creating Innovative Products, by: Jim Highsmith
6. Becoming Agile: in an Imperfect World, by: Greg Smith, Ahmed Sidky
7. Agile Estimating and Planning, by: Mike Cohn
8. The Art of Agile Development, by: James Shore
9. User Stories Applied, by: Mike Cohn
10. Agile Project Management with Scrum, by: Ken Schwaber
11. Lean Agile Software Development, by: Allan Shalloway, Guy Beaver, James R. Trott

(All References are required readings for PMI-ACP exam.)

This is my first post on Agile WOW & would like to hear what you think! All experiences and comments are welcome - let's respect our differences and learn from each other <3