Agile has been around for over 20 years. It has shown a lot of benefits to software development and improved quality to what clients/users want. Yet in discussions with peers and reading a lot of 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 fairly 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 wikipage):

  • 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 easy, 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 I did not like it. It seemed too much cowboyish than structured. It didn’t feel right. Then I started to look into it more and more. My feelings towards it started to change and at the same time that was happening I noticed that I actually was following the methodology in the late 90’s 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 a lot of 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 actually did. Well the reason I didn’t do that was because 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 team to meet the goal
    • Helped each other
    • We still followed process
    • We still used tools
      • The last two we were more focused on the first three points than the last 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 is completed
    • Ensure test results were documented
      • This was done in a bank so test results are an audit-able document. So we needed it.
      • What we did was understand what is needed for an audit and ensure we were compliant. They were focused on one set of results. So we ensured that the last run of cases were 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 really 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 go over it and figure stuff out then get the approvals. We just planned on the spot and go from there.

So back to the purpose of this post: Why is it so hard to go Agile? 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 literal and fear of loss of control.

Taking things too literal is an easy one to talk about. Basically people take a look at the Manifesto and basically treat it as gospel. This is where the cowboy comment from earlier came from. 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 complete understanding of what impacts there are to adjust. Taking work out of a sprint so not to impact capacity, move it to the next sprint as it is not as critical as initially thought or prioritize for future releases.

Or the teams will just throw in a lot of work in the sprint without properly ensuring they are effectively pointed or they don’t really understand their velocity. What happens with that is usually the Burndown chart looks more like a city skyline then a slope with a huge drop at the end because incomplete tickets are moved to the next sprint. From there it just snowballs out of control. This then impacts everyone in the team. The sad thing is it becomes the norm and people become complacent.

It is not a matter of throwing work in and seeing what comes out. Speed is great and eventually a good running team will be able to accomplish great things on a faster schedule. It is about setting a good foundation of to get there. Getting speed for the sake of it will lead down a road that will not end well for anybody involved.


The fear of change is powerful. Normally humans don’t like to do something different. As long as they are comfortable they are good. “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 how work is done?

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 actually did it, and two education. Reading, courses, and talking to others have given me the insight to see the benefits and how to apply good change management to get others down the path.

This post didn’t really go into a lot of QA or testing, hopefully you can see the implicit message of how QA is involved.




Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.