Agile Forest

There is a world of misinformation out there about Agile. Even I have probably created some misinformation once or twice (not deliberately).

There is probably too much wrong to fix, but I saw a tweet recently that I wanted to tackle. It was originally linking to the Segue Technologies blog:

http://www.seguetech.com/blog/2015/11/03/waterfall-vs-agile-infographic

Naturally some people in the Agile community responded and it is fair to say their response was one of confusion and disbelief. Many thought it was a joke, but I suspected that the creators of the information felt it was a reflection of what they believed to be true and not intended as a joke. I tried to seek clarification to which I got a response:

We develop for a wide range of customers. This is a high level info on 2 different methodologies to show non-developers that there are different approaches.

So it was an honest attempt to educate and provide value. Okay. So let me try to give an honest attempt to re-educate on what I perceive to be some of the errors in this infographic:

 

Agile Pros:

• Customer approval during all stages:
  Probably just a minor clarification, but approval is a little strong for me. They are involved throughout – what that means is that they agree to the work to be done just in time prior to starting it, then they get to see it when it is nearing completion. In essence, there is a greater focus on building the right product.
• Great for quick launches:
  Okay, but maybe more importantly, Agile is great for getting a product out quickly and getting feedback immediately from customers to know whether you are on the right track. You can continue to build on this product through subsequent iterations.
  I want to take a moment and comment on the usage of the term “customer” through the infographic – I am concerned that it is referring to a customer in the business as opposed to a real customer who uses the product. Also there is a lack of distinction on project and product throughout.
• Prioritised by business value:
  Business value is important and should definitely be used as one means of prioritisation, but there are often other considerations used in Agile – Weighted Shortest Job First is a classic example of this. For me, in Agile, prioritisation should include consideration of business value, risk (either technical or implementation), cost, cost of delay and learning value.
• Customer involvement makes project user focused:
  So customer is now distinguished from users (who are the real customers). It may be a little concern of mine, but I do feel the strong focus in Scrum on the Product Owner role detracts us from making greater efforts to get to know the real customers. Yes teams can work hard to ensure they hear the voice of the real customer, but there is nothing like using only customer data to drive your decisions.

Waterfall Pros:

• Early agreement on deliverables:
  The natural risk here on early agreement on deliverables (and I think they mean scope rather than deliverables) is that as you learn things through development, the agreement is moot. Build the right product, don’t just build the product that you agreed to that meets no ones needs.
  If the interpretation truly was deliverables and not scope, there is nothing stopping you from having a great understanding of what needs to be done upfront with Agile. Many teams that I have worked with do an activity prior to going into iterations called “Inception”. The purpose of this activity is to have a common understanding about everything that needs to be done (as best could be understood with so much uncertainty in the complex world of software development).
• No need for customer involvement during development:
  I read this like ‘In software development there is never a need to clarify anything or to get feedback on anything’. Yeah, like that happens, or like that works out to be a great solution. In the early days of Agile when I heard this twelve years ago my response to the business when they said they couldn’t afford to have an ‘onsite customer’ was “okay, then if this project isn’t one of the most important ones for us to focus on as an organisation, that it isn’t critical to invest business experts in for, then it sounds like it isn’t critical enough to invest IT experts in.” The response was always swiftly met with the provision of a good SME.
• Full scope known in advance:
  Never in the world of software development has scope always been fully known in advance. This is just a fallacy and it should be stopped being used by Waterfall appreciators.
  We never build the same thing twice. As a consequence, software development is not a production line, it is a process of discovery.
• Known deliverables reduce chance of “piecemeal” effect:
  There are so many great tools out there for dampening the “piecemeal” effect of Agile – let me name just a few: Inception, Story Mapping, Impact Mapping and Feature Parking Lots.

Agile Cons:

• Disadvantages when team is dedicated full-time on the project:
  Firstly, I am pretty sure there is no rulebook that says teams should be dedicated full-time in Agile. I won’t disagree that it is common practice, nor will I disagree that in almost all instance it is a good thing.
  Secondly, I have done some waterfall projects. People were full time in those too, so it isn’t an Agile thing.
  Thirdly, we have lots of great scientific evidence around the benefits of having team members full-time on work – it reduces context switching, it focuses on getting the work done sooner, thereby delivering value to customers sooner, thereby earning money for the business sooner. If you are interested in learning more about the science take a look at “Product Development Flow” by Don Reinersten. Another good book is “Slack” which talks about the misconception around being 100% utilised.
• Customer may not have time to be involved:
  I guess the project isn’t very important then.
• Customer may redefine scope:
  That sounds like a pro rather than a con. Especially if it means we deliver the right thing rather than waste money on building the wrong thing. The biggest waste as described by Lean is building the wrong thing – in software development this accounts for 64% of features developed.
  Edit: in trying to be accurate on this statistic I discovered it was based on a sample of 4 projects. Those sample numbers are definitely not enough to prove anything. Well at least I learnt something new.
• Quick launches can cause incomplete tasks:
  I don’t know about ‘quick launches’. If this means getting a product to a customer can cause unimplemented scope to occur, then yes I agree it can, and that is a good thing – because we can get value and learn from it. It doesn’t mean that we won’t continue to work on the product, just that when the cost of implementing new features exceeds the benefit then we are probably going to stop. That sounds pretty sensible to me.
  Often in Agile environments we try to automate “launching”. The process of automation inevitably should result in better quality of deployment over time (due to the removal of manual errors) rather than creating more incomplete tasks.

Waterfall Cons:

• Customer only sees final product and could be unhappy:
  In the waterfall projects I have been on with limited customer involvement the ‘could’ has occurred in 100% of instances.
• Customer has trouble visualising project in early stage:
  This happens with either approach. We don’t know what we just don’t know.
• Late changes cause going over project budget:
  Again could happen with either approach. Agile projects should reduce or dampen this effect by delivering the higher value work sooner. But I have to be fair, in my experience most projects I have seen (be them Agile or Waterfall) have had overruns of time (not in production delivery necessarily, but overall effort expenditure). Going over project time often means going over project budget. I feel however our focus on budget/time as indicators to success are sub-optimal, but maybe that is a blog post of the future.
• Late changes extend project timeline:
  As above.

What should factor in your decision – customer preference, project size, customer budget, time to market, customer availability:

• No, you should just always use Agile. I know this sounds dogmatic and like I am a cool-aid person, but when it comes to mitigating delivery risk there really is no alternative to Agile. If you want to deliver with greater success, less risk and with the greatest chance of getting the outcome you want you need to use Agile, it just really is that simple.