How to make Agile successful?

After I wrote Why Agile Didn’t Work (which to my surprise, has been one of the most popular articles for up to six months in InfoQ), naturally I want to understand how to make Agile work. I thought really hard on the question, I observed and tested ideas, I researched on books, forums, eventually, my thought went into So, How Do You Make Agile Successful?

 

It is a big relief to me, because now I am no longer confused by the sham coaches/Scrum Masters trying to sell me Agile (I am amused really J). While I am mourning the irresistible winkles starting to creep up my eyes, I am glad that with age comes with wisdom and experience. 

In essence, I think Agile has two levels: one is on product level, which is trying to figure out what has value; one is on delivery level, which is trying to deliver the value quickly. Delivery level and product level are intertwined, delivery level may produce prototypes to product level for quick verification, although innovative product owners may come up with cheaper ways to verify their ideas. 

I run into this document Dual-Track Agile: Why Messy Leads to Innovation, which has the same idea as I. And better, it shares an example, so it is more interesting than my article.  

This “dual-track Agile” approach has one pragmatic usage. In So, How Do You Make Agile Successful? I listed many bad things about “Scrum”, but I forgot to mention one worst thing: Scrum is a process, a rigid one. It is easy to become so focused on the process, and forget what the process is for. Process can be both deceitful and comforting: it deceives you to think as long as you follow the process to the last detail, you will be ok (this is the trick by sham coaches/Scrum Masters); it is comforting because you’ve conducted daily stand up meeting, planning meeting, retro meeting, and you have beautiful charts, surely things are going well. 

I have met program managers who spend a lot of time gathering story points from teams so they can produce burn up/down charts at the end of sprint, so they can point at the charts to demonstrate how successful they are. 

Introducing a little bit of chaos into the process with “dual-track”, is perhaps not a bad idea. Software is inherently messy, because it requires disruptive innovation, expecting a rigid process to fit it in is absurd. 

While I am on the topic of criticizing Scrum, I want to discuss another deceitful thing about Scrum:  story breaking-up. In my opinion, the purpose of breaking a big story up is to facilitate the understanding of the story and to figure out the best way to build it; it is not to break up the story so that pieces of it can be fit into a sprint, so that at the end of each spring, something/anything can be demoed! 

Building software is not like assembling bricks, which are all of the same dimension, and can be simply layered up. Good software requires a good architecture. A good architecture is like a house, in which racks, shelves are already built up, and everyone knows where to put what; utility stuff like electric pipes, water pipes are laid out in a way, that you simply just have to turn them on without worrying about a thing– if the pipelines are messed up, and everyone has to drag these pipelines through obstacles to use them, it is time to do a big makeover (major refactor), otherwise everything is going down the hill. 

The idea of having something demo-able at the end of each sprint is appealing, but people tend to forget that it requires much more advanced skills: You have to have an eye for the overall structure, while breaking down a story into small pieces. Human mind is not wired towards system-thinking, so we are at a disadvantage to begin with. Having a process with the sole goal of breaking things up may lead to even more myopic thinking. How many times have you heard in the retro meeting that “stories are too big, product owners need to break them down into small stories”? – that is a tell-tale that your process is going wrong! 

System-thinking is important in any kind of job, but because Scrum (and other Agile framework) simplifies software process to such a degree (whether intentionally or unintentionally), it is even more important to practice it. Ask your Agile coach if they can at the same time provide a system-thinking coach.

There are other tell-tale clues that your Scrum might be running badly, which will be the topic for another blog.