Why is Agile Software Delivery so hard?
Book your free Breakthrough Call to discuss this topic or any issues you are experiencing.
Agile has been around for over 20 years. It has shown many benefits to software development and improved quality to what clients/users want. Yet in discussions with peers and reading much literature, it seems like it is something that is just too difficult to grasp. Why is that? What is it about this way of getting work done is so hard for organizations to understand?
Looking at Jeff Sutherland‘s book: Scrum – The Art of Doing Twice the Work in Half the Time, it is relatively straightforward. Especially as one of the authors of The Agile Manifesto, you would think it would be simple. Let’s revisit the values for a second (from the wiki page):
Individuals and interactions over processes and tools
Working Software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to Change over following a plan
Seems pretty straightforward, right? Wrong.
Some people I have talked to about this take the values as stated laws and not guidelines. I will be honest here, when I first started to understand Agile delivery, I wouldn’t say I liked it. It seemed too much cowboyish than structured. It didn’t feel right. Then I began to look into it more and more. My feelings towards it started to change. At the same time that was happening, I noticed that I was following the methodology in the late ’90s without noticing it.
For me, it all started on a program I was leading the testing effort. It was a pure waterfall project, and it was not going well. Based on the project schedule, it was three weeks behind before it even got to the testing phase. So the pressure was on. There were many factors at play, and the deadline was not changing. So I decided that it was time to do something different. I started daily scrums following the same principles as in Jeff’s book. Asking the three main questions:
1 – What did you accomplish yesterday?
2 – What are you doing today?
3 – What is blocking you from getting it done?
From there, I went on to get things done, and we did. We met the deadline without 1 hour of overtime needed. It was great; everyone felt that they accomplished something. I was able to apply Agile principles in a Waterfall project. Pretty impressive, and I am kicking myself for not looking into it more back then to understand what I did. Well, the reason I didn’t do that was that I didn’t know. To me, it just seemed like the right thing to do.
Looking at the Manifesto, I will go through what I did all those years ago:
Individuals And Interactions
over processes and tools
We interacted daily
Worked as a team to meet the goal
Helped each other
We still followed the process
We even used tools
The last two, we were more focused on the first three points than the previous two.
We used found efficiencies to get the work done as we went along.
Working Software
over comprehensive documentation
- Get the work done
- Ensure scope met
- Ensure test results documented
Since this was a bank, the test results are an auditable document. So we needed it.
What we did was understand the work needed for an audit and ensure we were compliant. We focused on one set of results. So we ensured that the last run of cases was documented and ensured less duplication.
The other benefit we found here was saving a lot of storage space.
Customer Collaboration
over contract negotiation
We worked with the Business Analyst to ensure what we were testing was what they wanted to see.
Shared results
There were no contracts of negotiations done
Responding To Change
over following a plan
As with any project in Waterfall, there are change requests. The team adjusted and still met dates
Although there was a Test Plan documented (it was Waterfall after all), we never revisited it. We knew it would take too much time to go over it and figure stuff out then get the approvals. We just planned on the spot and went from there.
So back to the purpose of this post: Why is it so hard to do agile software delivery? If I was able to do it without any training, why can’t some teams get it straight when there is so much documentation out there to help?
I see it as a couple of things: Taking things too literally and organizations not accepting to be utterly agile in the work they do.
Taking things too literal is an easy discussion to have. People take a look at the Manifesto and treat it as gospel. Hence where the cowboy comment from earlier came. I have seen teams that treat Agile as a free for all and that they can do whatever they want. When in actuality, Agile needs discipline.
Yes, teams will have to act fast on stuff that may come in from Business, Clients or senior executives. It is going to happen. It is how the team reacts that is key. Not every moment is a “drop everything that you are doing and work on this.” When stuff happens, it is up to the team to analyze, collaborate and ensure there is a complete understanding of what impacts there are to adjust. Taking work out of a sprint so as not to impact capacity, move it to the next race as it is not as critical as initially thought or prioritize for future releases.
Or the teams will throw in much work in the sprint without adequately following an effective and consistent pointing process or they don’t understand their velocity. What happens with that is usually the Burndown chart looks more like a city skyline then a slope with a considerable drop at the end because incomplete tickets move to the next sprint. From there, it just snowballs out of control, which impacts everyone in the team. The sad thing is that it becomes the norm, and people become complacent.
It is not a matter of throwing work in and seeing what comes out. Speed is high, and eventually, a good running team will be able to accomplish great things on a faster schedule. It is about setting a good foundation to get there. Getting speed for the sake of it will lead down a road that will not end well for anybody involved.
The organization is not set up
The fear of change is compelling. Usually, humans don’t like to do something different. As long as they are comfortable, they are right. “It has worked before, why do something new?”. Jeff said it best in his book “Change or die.” Going on a deeper level, it is evolution. We all know we can’t stop that from happening in the world, so why be so closed-minded to evolve the organization? It is more than just having teams running sprints and developing code while the rest of the organization is not in the same mindset. Think of it like two cars going down a road, and they have to go at the same speed. Now one of those cars is the new Lamborghini Vision GT V12, and the other is a 1985 Chevette. Yes, they will be able to get to the destination, just not as fast as they could go. So to partly evolve won’t help things, in the end, will only slow down the value that it could achieve while competition could pass.
I had similar fears, and I overcame them. There are some of my former coworkers that would be pretty impressed that I have become an Agilist. How did I overcome it? Well, one, as stated earlier, I did it and two education. Reading, courses, and talking to others have given me the insight to see the benefits and how to apply proper change management to get others down the path.
