Losing my Agile Pixie Dust

About 3 months ago an event occurred that I will not soon forget. It was a typical Seattle evening: 4:00 pm and already pitch black outside and raining. I was looking around the office and feeling dissatisfied. Something was amiss and I needed to give it a good old fashioned agile fixin’. So what was it going to be? Should I impose pair programming? Perhaps I should mandate TDD? Maybe we should all sit down together and have a retrospective (and hold hands singing campfire songs)?

Hmmm…No. The team didn’t need any of that. Pair programming is great, but it wasn’t immediately apparent how mandating it would make the world a better place. TDD is great (yeah that’s the ticket!), but the team’s bug count was already super low – so why bother? A retrospective wasn’t going to reveal anything dramatically new since our last retrospective 3 days ago. So what is an agile coach supposed to do? They pay me an embarrassing amount of money to be agile – so I’d better deliver the goods.

I found myself desperately digging about in my bag of agile goodies looking for some agile pixie dust to sprinkle on the team – and coming up with bupkiss. That’s right, I had nothing. Nada. I cast a surreptitious glance around the room. Everyone was working hard on delivering features. Nobody needed anything in particular from me. Maybe I should try something lean like Kanban or concurrent development? No, the situation really didn’t call for it. This was bad. I was starting to break into a sweat.

What was the team asking for? The team had complained about poor requirements, but I really didn’t have an agile tool for that. Of course we had user stories, but they weren’t enough. I can write user stories with the best of them, but improving the user stories wouldn’t revolutionize their world. They weren’t asking for better user stories. The team was asking for more information. More than you could ever put in a user story.

What they desperately needed were better requirements. But that’s not agile, right? OK, every team needs good requirements. And that’s what my team needed – some well thought out requirements. They didn’t need any agile pixie dust from my pouch of agile consulting magic. My pouch was empty. I didn’t have any agile cure-all to give them. Some poor sod needed to go out and dredge up the requirements (or drag someone into the room who knew what they were). No agile magic there – just good old-fashioned requirements analysis.

Gradually it began to sink in: this team didn’t need any agile pixie dust at all. What they really needed was somebody to do some serious, hands-in-the-dirt requirements analysis. Nothing would speed up this team more than decent requirements. They were begging for it. They just needed somebody to listen.

Now I realize that I put some of this description in terms that might seem funny or entertaining, however it is an honest portrayal of my feelings at the time. I literally could not think of any agile solution for the problem and it was a crisis for me. It was like someone had pulled the rug out from under me. No agile solution would work. The only thing left to do was to listen to exactly what the team was asking for: more information.

More information is not an agile problem. We’ve been dealing with that challenge for decades. You can break it up a number of different ways (user stories, use cases, etc.) but one thing is inescapable: the team needs this information.

The more I looked around the room, the harder it got for me to see the agile bits. I was slowly getting a case of agile blindness! I couldn’t see any cross functional team – instead I just saw people working together. Nothing new there. Where once I had seen “information radiators” I now could only see project status charts!

I’d like to tell a story here where I somehow redeem myself. It would be great to wrap up with how I managed to find more agile pixie dust. Perhaps how I managed to regain my agile vision. Unfortunately that’s not the case. I still just see competent teams working hard and communicating with each other. Teams with problems that need to be solved – problems that have nothing to do with agile.

At first I fought this sensation – I think of it as my gradual descent into agile blindness. I really hoped it would all wear off. I would just wake up one morning and see agile solutions to all of the team’s problems again. But as time wears on I’m afraid that’s not going to happen. I see the same plain old problems every day. Problems that an agile prescription (or any other methodology for that matter) won’t fix.

5 Responses to Losing my Agile Pixie Dust

  1. Andrey says:

    Why don’t you just add business analyst to be a part of the team? That person will gather and document requirements for the next sprint. BA will be responsible for functional requirements (what needs to be done), developers – for technical part (how it should be done). As a result, by the end of current sprint you will have documented features (change requests) for the next sprint… so next sprint will go smoothly (everything is already discussed and well estimated). Such approach works pretty well for my team.

  2. Tom Perry says:

    Andrey,

    You are absolutely correct – adding a business analyst would solve the problem. My point was simply that the solution was not one that I would pull from my holster of silver bullets (sorry about the mixed metaphor). Adding an analyst to the team is just a plain old solution to the problem at hand. It’s not Agile, it’s not Waterfall, its just the right thing to do. Ultimately, I think that we all need to keep this fundamental perspective in mind. It’s not important was we call the solution, just that we provide the right solutions to meet the needs of the team at the time.

  3. Andrey says:

    My point was not only in adding a BA, but also what exactly BA needs to do. BA needs to work (together with dev team and PO) on NEXT strint requirements (key point, dev team is also involved). This process is going in parallel with development activities for this sprint. But at the end of the sprint you need to “join” them. And output of a sprint will be: 1. working application, 2. discussed, agreed and estimated requirements for the next sprint (with enough documentation level). There are a number of advantages in this approach: 1. the team is very focused on development tasks in this sprint (as how to implement features was discussed in prev. sprint and team has a solution for most of the issues), 2. Time-boxing for requirements specification (so you can drop and not include into next sprint requirements that were not documented), 3. Very predicted results of development part (as there is very low possibility of spending a lot of time on searching for a solution or discussing a feature that has been scheduled for current sprint)

  4. I think that organisations come to Agile because they are desperate for improvement. They think the problem is to do with poor software delivery, but I believe the problem is poor requirements (or if you prefer poor ‘user stories’). Which suggests that Scrum/XP solves the wrong problem. There is no real issue with talented developers delivering code. The problem is the business being unable to state what they want clearly. Scrum/XP skirts around the issue of user story management. I think where we go from here is we split into an Agile Requirements practice (ARP) and an Agile Delivery practice (ADP). ADP works well. ARP doesn’t. Jacobson’s view of the essential issues of concern in software engineering echos this approach. i.e. requirements don’t belong in delivery, rather requirements are a formal input to delivery. http://www.ivarjacobson.com/process_improvement_technology/essential_unified_process_software/

    I’m a BA working on ideas for making stories better by the time they get to the Sprint planning meeting so planning poker can be done with enough information to have confidence. I do this using a requirements pattern language I’ve been using it since 2003 and it works well. The pattern language works for transactionally-oriented database applications and includes patterns for driving out common personas, minimal persistant representation, data maintenance, lifecycle class, and management information.
    The application of the pattern language ensures the upfront requirements work does not take longer than it should. A first cut of the requirements hierarchy tree is always available within a week. The whole set of ‘conversations’ around each candidate user story is almost always done within five weeks – then the sprint planning meeting can start, and it is guaranteed to be short and sweet.
    The implementable story hierarchy has project stories at the top. These are akin to ‘Jacobian’ use cases in that they represent the achievement of the user/actor/persona goal. They are the top level of the requirements ‘tree’ and act as the basis of the requirements table of contents. The project stories decompose into release and iteration stories. The entire hierarchy can be traced back to all the business inputs from interviews and workshops. The approach introduces a new definition of ‘epic’ to no longer mean ‘a big story’ (not that helpful) to a more interesting definition that includes:
    • Enterprise stories
    • Back stories
    • Project stories and tests
    • Release stories and tests
    • Iteration stories and tests
    • Constraints
    • Implementation tales
    • Non-functional requirements
    The definition of ‘epic’ shows how all these elements fit together and is supported by graphics and spreadsheets. This approach is really useful early in the project lifecycle. It can be applied during feasibility, and in ‘ideas management’ where management has to decide which projects to fund in the first place.

    I’m interested in:
    • how to bring the PMO onboard
    • how to reconcile the need for ‘governance’ with Agile
    • how to give senior management confidence
    • what to do when the customer isn’t full time available
    • reconciling enterprise stories, project stories, release stories, iteration stories, constraints, acceptance criteria etc. into a big picture
    • how upfront requirements/stories can still be Agile (keep it simple, but no simpler than it needs to be)
    • a synthesis of Agile modeling and the best lightweight aspects of UML

    I’m blogging at masterstoryteller.co.uk. I also write at princelite.co.uk.

    Thanks Peter

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: