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.

 

Agile software, continuous delivery and passionate users

Rowly Emmett, a test consultant who lives here in Queensland, Australia, recently dismissed agile software development in a blog post titled “Agile Recipe“.

“…there is no difference between Agile and Waterfall”

“The thing is, if people followed the (rigourous software methodology or waterfall) process correctly, then they wouldn’t need to try out Agile.”

Rowly says it’s not really about your software development approach, but how rigorous you are in your chosen approach. One of the things that Rowly wrote that stood out to me was:

“I believe the process should adapt to the conditions of the project and the needs of the application.”

But that’s what agile is about isn’t it? Adapting and evolving solutions through collaboration.

Rowly finishes by listing some of the conditions for a project moving to agile, which included:

“Is the domain ABSOLUTELY clear (does the customer really know what they want?)”

But I’d actually say that’s one of the reasons I have seen agile software development methods work over other methods, in that customer needs can evolve iteratively, rather than having to be specified upfront which is more likely to produce something not needed at the end.

I would say my biggest criticism of Rowly’s article, and why I disagree with it, is he’s looking at it from a pure methodoligical viewpoint, rather than what it does differently and what that can ultimately deliver. Sure, a project will fail if it’s done poorly, no matter what methodology is used. An agile project will probably fail sooner, but if done correctly can ultimately deliver better outcomes. Not just that, it’s increasingly anti-competitive to use non-agile methods to deliver software. So it’s no longer a choice, but a mandate. I’ll explain in a bit more detail using a case study.

Google Docs and how they deliver software

I have no idea what methodology Google uses to develop its Google Docs product, but I know they must use iterative agile techniques. How do I know this? Because I am a passionate Google Docs user and I subscribe to the Google Docs blog. Every couple of days Google Docs releases some new functionality into Google Docs, and they write about it on their blog. They couldn’t do this using a waterfall methodology. They’d release new functionality every few months, or years. Compared to Microsoft who bring out a new product with lots of bundled enhancements every couple of years (Office 2003, Office 2007, Office 2010), Google release some enhancements every couple of days.

How does this make me feel as a user? Passionate. I love that there’s new functionality every couple of days, as it allows me to master it and kick ass. As I recently tweeted:

http://twitter.com/alisterscott/status/22256071870

 

Which is exactly how you want your users to feel. As Kathy Sierra explained during her great Business of Software presentation: you don’t just need users who think you’re company is awesome, or your product is awesome, but rather that they’re awesome, when they’re using your product. Like when I showed the expenses app I built with Google Spreadsheets and forms to my wife, and because she was so impressed I felt awesome. Like all the tweets I saw about the Gmail Priority Inbox, something that was delivered immediately, iteratively, not through an ‘upgrade’.

If Google Docs was developed using a rigorous software methodology, it may have only just been released, or it may have not even been released yet. And I certainly wouldn’t have had an opportunity to get excited about all the incremental improvements I have seen over the past years.

Moving beyond the Project into Continuous Delivery

The Google Docs case study highlights a bigger point, that Google Docs is a product, and not a project. As Evan Bottcher (a Thoughtworker from Melbourne) recently wrote on his aptly titled blog post: Projects are evil and must be destroyed, we need to move beyond looking at things as a project that are eventually handed-over to BAU, and move towards “form(ing) long-lived teams around applications/products, or sets of features”. Like the Google Docs team, who continually develop and deliver functionality to Google Docs users (and write about it). There’s a name for this concept, it’s continuous delivery, and a fellow Thoughtworker Jez Humble recently published co-published (with Dave Farley) a book about it, titled Continuous Delivery.

My bugbear with Continuous Delivery

The only downside I see to continuous delivery is when it’s used in an environment that needs to be actively upgraded by users; it’s no point pushing out new functionality daily if your users have to do an upgrade daily. One place I see this happen prevalently is iPhone apps, how many apps need updating every time you check? Too many in my opinion. In a web environment, such as Google Docs, continuously delivery rocks! In a non-web environment, such as iPhone apps, browser, firmware and OS updates, it sucks. As Michael Neale recently pointed out on Twitter.

 

Firefox are doing some work in this space around passively delivering (minor) updates, but there’s still a lot of work to do in this space if we’re going to have continous delivery of non web applications.

Wrapping Things Up

I started off by disagreeing with Rowly in his views on agile software methodology in that it doesn’t matter. I believe we no longer have a choice, we’re at a point where it is increasingly uncompetitive not to be agile, as we need to deliver soon and the way to do this is through iterative and incremental development and continuous delivery. This is even more important for environments where the domain is unclear and the customer doesn’t know what they want. Delivering software this way is also great for creating passionate users who feel they can master what you give them and kick ass.

My thoughts on Brisbane ANZTB SIGIST: September 2010

I went along to the ANZTB SIGIST last night, at the Hilton here in Brisbane. It was probably the best one I’ve been to, both in attendance, and caliber of presenters. There were five presenters all up, which is a lot to squeeze into two hours including drinks and conversation. It’s no surprise then that the last presentation by Craig Aspinall was a little bit rushed, which is a shame because I would have liked to ask more questions than time allowed (apparently the Hilton would kick us out if we stayed longer).

Craig Smith and Rene Masten from Suncorp began with an excellent presentation on Agile Testing. Craig was awesome in both presenting his extensive knowledge (he’s a coach) and his slides were also very cool (minimal text and no bullets!).

Craig’s main theme was about how to make testing cool: ensuring people say “that’s cool” when you tell them about your testing. He talked about what makes up an agile team, the techical divide between devs and testers, ATDD, ensuring you deliver, and how there is currently a great opportunity for testers (who want to be bothered). Rene followed by talking about organizational change, training and coaching, communicating what you’re doing (internally and externally) and building quality in.

Craig finished with a great motivating style of emphasizing it’s all about passion and craft, “who’s awesome!”, and not being afraid of technical challenges.

The other presenters were Ben Sullivan and Brent Acworth, both also from Suncorp, who gave a demo of BDD using JBehave and Hudson. I enjoyed the talk but there wasn’t much I hadn’t seen before or didn’t know.

The final presentation was by Craig Aspinall and was unfortunately squeezed into a small time slot. It was about what Craig dubs “Automated Black Blob Testing”, the rationale being testing is not black box as a box has a predefined shape, it’s more of a blob.

Craig’s approach looked solid, although I was slightly concerned when he mentioned the project being a SaaS solution and how much effort was being put into automated testing.  I’m not criticizing what Craig did tehnically, I am just concerned about the prevalent practice of the onus of testing SaaS solutions being put onto the customer. I believe if you buy a SaaS, you should get a working SaaS, minimal, if any at all, testing required. But that’s just me. Otherwise, a great talk, besides Craig using Java when Ruby and Watir would have done the trick. ;)

A great ANZTB SIGIST, and hopefully more good ones to come!

Craig Smith’s Slides

Some of my photos

This slideshow requires JavaScript.