In my experience while working for different companies, I have seen that some organisations are learning to be agile while some pretend to be agile and others are not agile at all. While we are not here to talk about the last category (assuming they have a very good reason for not wanting to go agile), I would like to put down some challenges for organisations who are on their journey to becoming agile and for those who think they are agile but are possibly not. In this article, I am going to talk about my understanding of the plausible reasons why some organisations struggle to make it.
Multiple releases
Organisations who are too used to the waterfall way of working, are conditioned to spend a large amount of time in planning, designing, developing, testing and implementing. This gives them enough cushion to rectify mistakes without affecting the business which often results in pushing the go-live date.
There is possibly a pressure factor there because more frequent releases means we need to be really watchful for mistakes. “We can’t release something with errors” is a common reason for fearing Agile. The way to lay off that pressure is to understand that the key lies in breaking down the user stories to a good level of detail. The better the user stories are broken down, the more confident the delivery team will feel. They have a relatively simple package of work to deliver to the business, which can be achieved with ease. Moreover there are ways to ensure you have less errors in production by running automated tests (regression and progression).
Flat organisation structure
Agile is about a team of high performing individuals coming together to create magic. The first thing that organisations need to do (to be agile) is to let go of authority (yet not abdicate its accountability) within the project. This is often an unacceptable thing to do for most organisations and more widely in certain cultures. They are too married and committed to the concept of hierarchy and reporting lines.
The important thing to remember for organisations is that although agile teams will still come under the overarching organisational hierarchy, authority is something that will still be applicable for the individuals outside the team (as line managers, etc.) and just not within the project (as project managers).
Wrong or half knowledge of how agile works
Half knowledge is more dangerous than no knowledge. Organisations often use right words like Agile wall, daily stand up, sprints, MVP, user stories among others but don’t understand the holistic agile approach at all. I have seen Agile walls with cards, but the cards don’t have user stories, instead the name of project itself. While it might be a good wall for executive management to understand where each project is at, we need to have a similar wall for each project which dwells at a much deeper level of detail. After all, an agile wall can be designed for the audience.
I have seen organisations split up waterfall projects into sprints and achieve tasks based on an SDLC approach. Organisations believe that if we do sprints, we are on our way to be agile.
I attended an agile conference where I came across this diagram by Henrik Kniberg, which I thought was the perfect example of how organisations get it wrong in this respect. Henrik Kniberg explains this in detail in his article “Making sense of MVP (Minimum Viable Product) – and why I prefer Earliest Testable/Usable/Lovable” (Retrieved from: http://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp)
Source: (Henrik Kniberg: Making sense of MVP (Minimum Viable Product) – and why I prefer Earliest Testable/Usable/Lovable)
This is only a representation of how we get Agile wrong. One could argue that I wanted a car and all you have given me is a skateboard. This is what agile calls a walking skeleton.
A Walking Skeleton is a tiny implementation of the system that performs a small end-to-end function. It need not use the final architecture, but it should link together the main architectural components. The architecture and the functionality can then evolve in parallel. Source: - Alistair Cockburn.
Notice the smiley face is not really smiling after receiving a skateboard but is certainly on its way to what it really wants.
Too fast paced
This links back to my first point. Multiple releases puts a lot of pressure on the teams to perform. Since teams are constantly moving from one set of user stories to the next, it might seem like you are constantly working and can also seem fast paced. While it might not be too far from the truth, the true joy lies in working in collaboration with a team of like-minded experts. When great minds come together (minus the ego), great things get created.
Myths about agile
There are already too many articles out there to debunk various myths about Agile. I am not going to go into that but my recommendation would be to understand the purpose of Agile and not make any assumptions on what it is about, before jumping straight into committing yourself and your organisation to Agile.
If you do this, you only end up pretending to be agile with half knowledge. It’s a lethal combination.
Author: Arvind Arcot
Arvind brings over 20 years of professional experience, including 13 years as a Consultant and Business Analyst. He has extensive Banking, Finance and ICT sector experience, rounded out by experience in Government (Australian), Transport, Petroleum, Higher Education and Retail. He has been deployed on numerous consulting engagements throughout the Asia Pacific region, enabling him to engage in highly varied client organisations.
Arvind is a passionate BA leader and has established and run various BA practices in his career. He also has a passion for writing and publishing white papers/articles to document and share experiences, learning and observations from his professional career. Arvind is also a nationally recognised industry speaker and has spoken in various BA conferences in Australia. He is the Melbourne branch chair of IIBA, Australia Chapter.