Look around you and you'll find that many organizations claiming to be Agile or "doing Scrum" are actually doing something else. I call it W-agile. They dress up the work in the trappings of XP and Scrum but really work in nested mini-waterfalls focusing on one big delivery at the end of the project. Often, developers are working in isolation from their business stakeholders which misses the original agile vision.

For example, this week I ran a class on Planning with User Stories. Questions asked (see pic) by the people on the course hinted that they were working in a W-agile world. They want to know: "Who writes the stories?" "How can I get the developers to read the story details?", etc.


Well, I learned how to work with user stories 10 years ago at Connextra applying the 3Cs mantra: Card, Conversation, Confirmation. The answers in an XP team are simple. It doesn't matter who writes the card because it's written as part of a conversation with the customer. The team talk to the business people and write as much detail down as is useful. But that answer won't help this class.


I drew this picture up to show the class how what they were doing compared with waterfall and agile. I explained they are looking for an approach to analysis and design for mini-waterfall projects where the "team" are working out of step. User stories may not be the answer because the proper context for using them is a co-located team of XP developers with an on-site customer. I see a tension when you attempt to apply XP user stories in the context of Scrum because the confirmation part of the story tightens the scope and pushes some of the Scrum cross-functional team to work ahead on grooming the product backlog. Back when I learned Scrum, scope of product backlog items was loose to allow some flexing within the sprint of how the features were implemented.


Take a closer look at my w-agile example (above) and you'll see that user stories are being written by analysts and designers who act as an interface to the developers. The development team has minimal face-to-face conversations with business people. The only part of the workflow which is visible is the development tasks. Testing and putting the code live doesn't feature in the sprint plan. It doesn't seem to matter because the deadline that the business cares about is some months away. Great news that Kanban has stepped in to help make the end-to-end workflow visible.

I do appreciate why w-agile arises. Agile is seen as a project management approach for IT to get software out of the door. Doing w-agile is likely to be more beneficial than waterfall but to succeed with w-agile these teams may be better off applying DSDM than relying on XP for analysis techniques.