Five remedies to make you less mini-waterfall

Yesterday I wrote about the five signs you might see if you’re practicing mini-waterfall when you think you’re agile.

In retrospect, that list seemed rather glum, so here’s five possible remedies to a mini-waterfall problem:

  1. Break user stories down into the smallest possible deliverable thing: if a story takes the whole iteration to develop then it’s too big; break it down. I’ve written previously on here about the importance of breaking things down.
  2. Embed a product owner in your team: that way stories won’t become blocked waiting signoff because the product owner is around to make the decision and unblock them. If you really can’t have a product owner embedded in your team, at least have an empowered proxy who can unblock requirements.
  3. Bring forward pain points that will take time at the end of the project: if promoting to prod is painful, try releasing to pre-prod each week. If UAT is going to take 4 weeks at the end of your project, do it once a day every fortnight to get earlier feedback. By the time you get towards the end your users will be some familiar with it they’ll be much more comfortable taking less time.
  4. Empower team members to change the agile process as they seem fit: they need to be responsible for their actions and be flexible to change again if needed, but don’t let your team members live in fear of change or retaliation.
  5. Release often: this will most probably be the hardest one to change as it’ll encounter the most resistance. You can start in small steps. For example, you could agree to release your application services/database more frequently than your user interface to see how it handles in production. Or you could release new functionality with a feature switch so that it’s disabled in production to rehearse and refine the release process. There’s no point in delivering working software every iteration if you’re only ever going to release it once or twice a year.

Five signs you’re not agile; you’re actually mini-waterfall

Update: I’ve added five remedies to make you less waterfall in a separate post

I’ve noticed a lot of projects call themselves agile when in fact they’re mini-waterfall, also known as scrumfall. Here’s five warning signs that you’ll see if you fall into that category:

  1. Development for your user stories seems to take almost all of the iteration and only move to ‘ready for test’ during the afternoon of the last day of your iteration
  2. You have a whole lot of user stories that are waiting business ‘signoff’ and can’t be worked on
  3. You have a large chunk of time set aside at the end of the project for ‘user acceptance testing’
  4. Team members live in fear of changing something or moving a story card around something as they’re scared of being ‘told off’
  5. You develop in iterations but only release everything big bang at the end when everything is considered ‘done’

Improving your agile flow

I’ve noticed two counterforces to flow on an agile team: rework and human multitasking. It’s common knowledge that rework is wasted effort, and human multitasking should be avoided as it reduces velocity through inefficient human context-switching, and can increase further errors through insufficient attention to tasks at hand.

But luckily there’s two simple things I have found that increase flow and reduce rework and multitasking.

User Story Kickoffs

It is essential that just before development work begins on every user story that a kickoff discussion occurs. This is a casual discussion around a computer between the business analyst, tester and any programmer who is working on the user story.

In my experience this takes about ten minutes standing around someone’s desk where we read aloud the acceptance criteria from Trello and discuss any ambiguities. We ensure that everything that is needed for the story to be considered complete and ready for testing is listed and that it’s not too large nor will take too long to complete.

We have special children’s sticker on our story wall which we put onto a story card that has been properly kicked off.

User story test handovers/shoulder checks

shoulder checks are essential
shoulder checks are essential

It’s also essential that as soon as development is complete that the tester and any programmers who worked on the story gather for a quick ‘shoulder check’ or test handover. This often involves letting the tester ‘play’ with the functionality on the programmer’s machine, and running through the now completed Trello acceptance criteria. Any misunderstandings or bugs can be discussed and resolved before the card becomes ready for testing.

We have special children’s sticker on our story wall which are then added to a story card that has been handed over/shoulder checked. The aim is to have two stickers on every story card in ready for test.

How these two simple activities improve flow

By conducting a user story kickoff every time it means that everyone working on developing the functionality has a common understanding of what is required and therefore there is a lot less chance of developing something that is not needed or misunderstood which requires subsequent rework.

By conducting a story test handover/shoulder check every time it means that obvious bugs and misunderstandings are raised immediately, so they can be fixed quickly before the programmer(s) moves onto working on new user stories. If discovered later these cause the programmer to multitask and context-switch between working on bug fixes and new functionality.

But I’m too busy testing stories…

I used to think that, but now I’ve got a personal rule that regardless of what I am doing or working on, I will drop it to attend a story kickoff or test handover. The benefits of me conducting these activities outweigh any work that I need to resume after these activities are complete.

Bonus Time… is it essential your bugs are fixed?

The great thing about agile software development is that developing something and testing something are a lot closer together… but they’re still apart. It’s more efficient to get someone to fix a bug whilst it’s fresh in their memory, but it’s even more efficient to not fix it at all.

What I am proposing is instead of raising medium/minor bugs against a story to be tested, raise them as bugs in the backlog to be prioritized. Depending on your organization, your business may not consider these important enough to fix, and therefore this saves you both rework and context-switching so you can continue on developing new functionality.

Long live the analyst-programmer

“Getting things done means doing things you might not be interested in. No matter how sexy a project is, there are always boring tasks. Tedious tasks. Tasks that a less mature engineer may deem beneath their dignity or their job title.”

~ John Allspaw

Once upon a time, before we called ourselves agile, there lived a role called an analyst-programmer. The analyst-programmer was a generalist before generalists became cool: just as content to analyze a requirement as to write some code and implement it.

Along came agile software development and its disturbing trend towards having senior developers that are above anything but pure coding. Writing SQL scripts for reference data, analyzing what is actually required, configuring a CI build: these are all tedious tasks that take away from what the senior developer is supposedly entitled to do: just write code to meet explicit acceptance criteria. The senior developer expects a flock of paradevs to run around doing their analysis, writing their acceptance criteria, and finally testing the code that they write. Some even expect the paradev to read the acceptance criteria aloud to them, because reading themselves isn’t coding.

You’ll start to notice who these senior developers are when you hear them say things like “I get paid too much to do this”, or “why are you wasting my time having me do this?”.

One day I imagine a world where all software development roles are suitably generalist and humble, that instead of complaining that “I’m too good for this”, people in these roles simply get their hands dirty and get things done.