I hear this a lot!  “We can’t get business buy-in to switch to Agile”

Me: “so.. you guys following agile practices?”

Person:  “um.. no.. we follow something more like ‘Scrumerfalll’… “

Me:  “hmm.. Scrumerfall.. what’s that?”

Person:  “Well, it’s basically waterfall.. with 4 week phases and daily meetings”

Me: “.. ok.. so, what makes it waterfall?”

Person:  “well.. we need to plan everything well in advance and we are measured on the plan.. we produce a lot of documents.. and we test it all at the end before it goes into production”

Me: “.. how’s that working for you?”

Person:  “Well, we’ve had to hire some top notch project manager, lots of business analysts, and we document everything to make sure we get everything right the first time.. but we are still slow to deliver and the customers aren’t always happy…  We have such a big team and lots of risk – so, we need this overhead.”

Me: “… how do you handle change?   Surely you don’t have every single requirement perfectly known up front do you?“

Person:  “Well, that’s why we have PM’s.. changes in requirements result in changes in the plan – and that needs to go through a change control process and a change control board.  We analyze the impact of the requested change, and make budget and schedule changes to reflect.  Once approved, we do a whole scale update to the project plan for the rest of the project…it’s a lot of work, and why we need the PM’s and BA’s… they really save us a lot of work because we can’t simply change the plan without knowing the entire consequence of doing so”

Me:  “.. sounds complicated.. hard to scale – and a lot of work..it even seems a tad wasteful.. “

Person: “Yeah.. well, that’s just how we do things – we’ve being doing it like this for years.”

Don’t get me wrong.  Maybe all of this “Agile stuff” isn’t for everyone.  In fact, I know Agile isn’t for everyone.  There are plenty of really great reasons to embrace waste, throw away money, bloat your project, deliver less than expected, and create an environment where success is rare rather than the norm.

I’m being silly of course.  I do know that some environments have a difficult time with Agile and Lean IT principles.  Consultancies (outsourced software development) are a perfect example.  Due, primarily, to the lack of trust between a supplier(the consultant) and a customer, suppliers of the software development services are asked to do silly things – like respond to RFP’s (to be fair to shareholders or tax payers of course) –  asked to “bid” on work based on cryptic, incomplete, and wrong requirements.  Trust, as it turns out, happens to be a key element of agility.  Generally speaking, there is a great absence of trust between business and IT.  Lack of trust typically means an increase in ceremony and “blame maintenance” ..

I think another reason that teams still do a lot of Scrumerfall is because there is comfort in having a detailed plan.  In addition, we still seem to value “conformance to plan” over “adapting to change”.  There is a lot of comfort seeing documentation that demonstrates upfront thought.  You must have a great team if they are able to produce a detailed plan for the next 6 months – take all of the complexity of a project and crunch it down into something that looks really nice printed and posted on a wall.

By the way – check out the article: “Scrummerfall: World’s Worst Software Development Methodology” by Aaron Erickson

There is still considerable resilience to even considering Agile practices in many organizations.  Companies still think that the key to delivering business value is to reduce variance.. and to reduce variance, we need control – and to have control – we must know as much as we can up front – create a plan – and stick to the plan.

Can we approach this from a logical view point?  I’m not sure since there is a lot of emotion tied to this debate.  This is actually one of the reasons I’m more of a “Lean guy” instead of an “Agile” these days.  I was actually escorted out of a building after declaring to a CEO that I would like to see his team use more Agile practices – he yelled at me saying “.. you don’t understand.. I need my developers to work for the business not for themselves.. Agile is all about making life better for the developers and not for the business.. .GET OUT!”  In this economic climate, I find it easy to start conversations with business executives about “reducing waste” and “optimizing the whole” and “building a culture of knowledge” and “reducing risk” and “pivoting” and “maximizing the flow of business value given fixed constraints” and “reducing variance to increase quality” and “business controlled value streams”  and “delivering business value as soon as it is produced”  and “rapidly adapting to changing business need” or “rapidly changing the business to respond to real and present economic conditions”.  Good heavens!!!  What business doesn’t want these things?  If that’s the case.. then what business wouldn’t want Agile and to embrace Lean Thinking?

Is waste good for your business?

I’m hoping that any person in business (in any business) can say that waste in business is not good.  They should even be so bold in thinking waste should be removed.

By the way, “removing” waste is ironically foreign to many.  A LOT of organizations I work with don’t go so far as remove the waste – but put in processes to minimize the waste or at least the impact of the waste.  This is the same as saying “We’re now more efficient at producing waste!!!”  – doesn’t that sound silly?

So, back to waste – we want to remove the waste.  This seems very much more Lean thinking than Agile (yet, Agile is very much about waste reduction as well!!).  Tachi Ohno, who firmly established the Toyoda Production System, which evolved to what we call Lean today, established 7 types of waste. Overproduction, Transport, Motion, Over-Processing, Delay, Inventory, and Correction/Defects.  This stuff has nothing to do with software development – and everything to do with business by the way.

Now.. doing some cross referencing with material written by Mary Poppendieck and Tom Poppendieck (I had the privilege of meeting Mary at the first ever Lean IT conference in Paris a few weeks ago) we see that we can map these different types of waste to software development – specifically

• Overproduction = Producing Extra Features that aren’t needed or aren’t asked for, creating more code to develop, test, and maintain for real value to the customer.
• Transport = Task Switching – task switching is really bad.  It’s hard for humans to switch rapidly between tasks – context is loss and opportunity for errors are introduced.  Did you know that task switching is bad for your brain as well? http://sethigherstandards.com/2006/10/28/dangers-of-multi-tasking/ and http://leananderp.com/?p=203 (this one talks about how multitasking every day is worse than smoking pot once per day!!).
• Motion = Collaborating instead of the traditional meetings which has been shown to erode productivity.
• Inventory = Partially done work – basically, any work not done and delivered and being valued by a customer.  Done done work.  Batch planning produces inventory… the plan itself is inventory.  Guess what.. just like apples in the back room, your plan will go bad as time progresses.  Why?  Because of change and reflection of the uncertainty common to all plans.  Requirements are also a form of inventory and should be considered goods that go stale.  Requirements should flow to downstream consumers as fast as possible as requirements have no value without implementation.  Similar to this, extensive un-developed design artifacts have NO value until they are consumed as well and thus represent inventory.  What else is inventory?  Well, lots of stuff like un-merged code.. un-integrated components, and untested solutions.

In one of my earlier posts, I talk about how Agile is about your Entire Business.  I really wasn’t kidding.  As you can see by the list of different types of waste above, Agile practices (engineering or management practices) go a long way to reduce waste.  In fact, that’s what it’s all about.. reduction of waste and the optimization of business value.

If there is one thing I can ask from any team anywhere in the world – regardless of what software development process they are using – it’s to focus on the reduction of waste.  You can only do this by truly understanding what value is.  In my humble opinion – there should only be a single heartbeat process on every project and team – one single process that begets all other practices – and that’s the retrospective cadence.  During your retrospectives, focus on how you can produce more value and reduce waste – I guarantee that this will lead you to Agile and Lean.  How can any business not want you to reduce waste and increase the delivery of business value?  Why would anyone need convincing of this?