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. Visit me!

Peter

So many $300 phones that are useless. That’s why people are into the iPhone: because Apple found people who’d never used the product and asked them to try and put on some music, and didn’t interpret people’s confusion as an insult.

A deathmarch like this represents a serious management issue. The question isn’t “what can a developer do to mitigate the problem” but “what can management and the team do to avoid the problem.”

Reduce scope. Institute postmortems. Look at Lean and Agile methodologies. If the developers are the only ones adding value to the project, why should management be kept on?

The first is to change the music. I know it sounds petty and makes me ever-so-precious, but I find what I listen to will impact how productive vs easily distracted I am. It also depends on what I’m working on: I recalled last week that when I’m writing a help file “Birth of the Cool” is all that. If I’m in the middle of writing a really long user story Burial provides the right amount of ambiance. When I’m testing/accepting, The White Album does the trick.

The second is the gym. Just today I was struggling with something and knew I had to get out of the office. I spent 30 minutes on the elliptical at a quick jog, listening to a sports podcast, and what I was working on became a little clearer. I wouldn’t say it solved everything, but I felt more focused about it when I got back to my desk.

I think what it really comes down to is taking myself just a little outside of the moment. It might be something trivial like brushing crumbs off my desk, looking up a nagging question in Wikipedia, or even just taking out a pencil and paper and writing down the essence of the actual problem that I’m working on. I can’t take too long, because then I’ll completely lose focus, but just re-kajiggering my context (or even doing a simple thing that gives me a sense of having done SOMETHING) helps. It’s like the old motivational poster says: Obstacles are what you see when you take your eyes off the goal.