Agile or W-agile?

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.

Comments

[Machiel Groeneveld]

Keen observation. Some Scrum teams now explicitly use two Scrum teams per project. One doing the analysis and requirements (Requirements Team) and the other the coding (Developer Team). Apart from the fact whether this works well in some situations, you run the risk of detaching the developers and degrading them to mere 'coders'. Anyway, true XP user stories will not be used here, if only as a token, because there will be quite a bit of documentation made available by the Requirements team.

[Vasco Duarte]

I disagree with the statement that Kanban can do anything to help the W-agile teams.

Kanban is just "another" method. Sure it requires a different "mindset", but so does Scrum.

Scrum also requires people to think about the whole value chain, it is just that people don't do that.

My experience is that what you describe as w-agile is just the very first stages of learning for a team/company. They will go through the process of having separate requirements and testing groups, and later recognize (if they do retrospectives) that the separation actually affects their capacity to deliver working code at the end of each iteration.

When they recognize this they will start to change their way of working, first integrating the BA's in the Sprint, then later asking the QA people to join and eventually (if they are really good), they'll even bring in other functions (IT, operations, etc.).

I'll be talking about this and other anti-patterns in a local conference in Finland http://www.turkuagileday.fi/. In this talk I'll expand this problem, what you mention is a real problem, but really only step 1 of a larger Agile adoption over the whole company.

BTW: what you call w-agile I call RUP (yes, I've been there ;)

[Rachel Davies]

Vasco, You say "I disagree with the statement that Kanban can do anything to help the W-agile teams." I find this an odd thing for you to say and wonder if this is a gut reaction or based on experience?

I have seen Kanban help make the end-to-end workflow visible as a first step to improve those invisible parts. I don't see doing that as incompatible with Scrum.

I also don't see w-agile as equivalent with RUP. RUP is very artifact/role based but I see w-agile teams who don't have any documented process for the pre and post development activities.

[Andrea Pinto]

"The only part of the workflow which is visible is the development tasks." Why do you conclude this? I work as a BA, being the main source of requirements for the development and test team also, and the workflow is visible to the entire team. The requirements are not just pushed to the team, they are presented and validated with the team before being developed. We also generate periodic releases to the client (not just a big one at the end), and weekly internal baselines were we test what was implemented and what was impacted with the new developed features / requirements/ use cases, whatever the name. I agree we do not follow the original agile vision, but in our situation the customer is not willing to be physically allocated in the project and most developers really like to keep the focus on the solution and not the problem.

[Mick Maguire]

Rachel, interesting article but what about the Scrum PO? Would you say having a Product Owner proxying the stakeholders / customers means the team is kind of W-Agile? Are you saying it would better to have the devs work with the stakeholders at story creation time along with the PO? Or is the PO working along with stakeholders good enough (after all the PO is on the Scrum team)?

Not challenging what you are saying just asking for a little more to help me understand and apply better.

Mick...

[David Draper]

Rachel,

Funny how the same patterns keep coming up. I often cringe when I'm asked "who writes the user story?" it's certainly indicative of a different mind-set to that which we try to introduce. Last time I heard it I found user stories spanning multiple pages of A4.

I thought you were against named clouds I kinda like w-agile :)

While I've worked with teams for whom this model is a great leap forward I do agree that the logical next step should be to expose some more of the workflow. Not necessarily Kanban but certainly expose what is happening in order to look for options to improve.

regards

Dave.

[Rachel Davies]

Andrea, You misunderstand me. By workflow, I meant the activities of people working on the project not the workflow of the system. Often, the tasks which a BA does to refine the requirements is not show on the team board because they are working ahead of the team.

From what you describe about the way the work on your project is organized, I'd say you are doing w-agile. This is not a criticism. I assume that the way you have chosen to work is appropriate in your context and the constraints in your organization. My point is that if you are doing w-agile then you need more than agile practices.

[Rachel Davies]

Dave,

Yes, I don't like arguments about which is the best named cloud (see previous post http://agilecoach.typepad.com/agile-coaching/2009/06/agile-like-a-big-fluffy-cloud.html - that's not what I'm trying to do here.

When we have a name for something, we can start having conversations about it. So I introduce the term w-agile to help clarify why some agile practices are being used out of intended context and that's why they're not a great fit.

[Rachel Davies]

Mick, here are my answers to your questions about the Scrum PO role and w-agile: no, yes, and maybe. A lot depends on your context. Face-to-face conversations help us build an understanding of user needs and provide an opportunity to ask questions so we can build better solutions. These conversations can compliment any development process.

[Vasco Duarte]

@Rachel

I published a bit longer explanation of my point in my blog: http://softwaredevelopmenttoday.blogspot.com/2010/03/we-continue-to-miss-point-it-is-not.html

The point about RUP was the marked role distinction which you refer to in the post (who writes the User Stories?).

[software testing consulting]

While the argument around the new term: w-agile is the best way to describe a new way of working and synchronizing details in a process of work, I must say I find this term rather fits the scenario. Great post.