Chaos, Discipline, and Agile

Last week, I discussed choosing a workflow approach for a project with a business stakeholder. Yes, this is still a topic worth discussing, and the choice may not be obvious (you may want to read our previous post on engineering workflow choices). In this case, I was leaning towards the Agile methodology, but the stakeholder countered by saying that she fears we will not be able to meet tight deadlines if we adopt such a chaotic approach.

This is not the first time I have encountered the perception that Agile is chaotic (in fact, in my opinion, SAFe is purely a monetisation of that perception). While it would be easy to dismiss this as business stakeholders not understanding Agile, I don't believe that's the reason.

Why Agile Is Perceived Chaotic?

I believe that the ones to be blamed for Agile being perceived as chaotic are us - engineers. Does any of the following sound familiar to you?

• Q: When will the future X be delivered?
  A: We are Agile, we will get there when we get there.

• Q: Can I see your architecture documentation?
  A: We are Agile, we don’t keep it up to date because it’s changing too fast.

• Q: What is your design for the changes required by future Y?
  A: You don’t design upfront in Agile.

Yes, this creates the perception of chaos. In fact, it reminds me of the joke about the empty wheelbarrow:

At a busy construction site that had fallen behind schedule, a worker was found running around with an empty wheelbarrow. The foreman stopped the worker to ask, "why are you running around with an empty wheelbarrow?"

The worker replied, "we're in a rush, there's no time to load it!"

That’s acting fast, but it doesn’t get you there fast. This is an important but hard-to-spot difference. When you’re observing something that is getting there fast it may look from outside that there is a lot of acting fast and it can look chaotic. This is because you can see lots of different activities happening rapidly. However, if you were to slowly dissect the process, you would notice that this is possible thanks to discipline. That’s what Agile is all about. Allow me to explore this further in the context of Scrum.

Agile Is About Discipline

I often ask tech leads what they think the two most important Scrum ceremonies are. Many of them will answer without hesitation: planning and retrospectives. In that case, my second question is whether there are any repetitive conclusions from the retrospective. The most common answer is that “planning was incorrect”.

Planning should be a short and simple activity that involves reacting to current priorities (this is how you can be agile). For this to be possible, there is one precondition - you must be disciplined about maintaining an up-to-date backlog. This means being disciplined when it comes to grooming. From my experience, grooming is one of the most dreaded Scrum ceremonies. This is because grooming involves talking, drawing and writing (all of which are activities that produce artefacts other than code). There is an easy way to avoid this, you just need to allocate a number to an item. It really requires discipline to resist that temptation. The second reason why teams often loosen discipline around grooming is that it can utilise a lot of the entire teams time. That’s because the teams are not disciplined enough to use another tool that will free the time to perform other activities and make the grooming activity a lot more efficient - spikes. You can create a dedicated backlog item for exploration, research and design. Of course, these have their own requirements around discipline - to avoid getting lost in them, you need to have simple heuristic on when to use them, time-box them, and adhere to the time-box regardless of the outcome. Disciplined spikes will allow for disciplined grooming, disciplined grooming will lead to disciplined backlog, disciplined backlog will enable short and simple planning, and that will result in getting there fast. Still for business stakeholders that may look chaotic, which brings me to the second most dreaded thing in Scrum.

The second most dreaded aspect of Scrum is probably the Definition of Done, as it enforces discipline around all the artefacts and activities that go beyond coding (have you noticed a pattern?). However, it is these artefacts that have the greatest impact on how business stakeholders perceive the delivery process. They are also there to preserve knowledge and serve as a basis for future work. So you need that discipline to ensure that “you getting there fast” doesn't appear chaotic.

Yes, Discipline Is Usually About What You Dread

Yes, we engineers are to blame for the way Agile is perceived. This is because we avoid what we dread, which results in us stripping Agile of discipline. Without discipline, Agile is perceived (and often really ends up) being chaotic and no longer has the promise of getting you there fast.