TLDR: User Stories are integration points, not slices.
Provocative title, yes? Well, give me a moment to explain and I think you'll understand.
In the lore of Agile there is the notion of the "thin slice." The idea is that you build just what's needed to implement the current user story. You "slice through" each level of the solution architecture and implement the user story.
I've had real problems "thinly slicing" the solution architecture along user story boundaries. The primary problem is that the user story is focused on functionality delivered to the user, but there is a lot more than providing user-visible functionality needed to complete a modern project.
Software development is typically 15% to 25% of the project budget. This often strikes developers as unbelievable - especially the prima donnas. But it's historically been true and it certainly doesn't sound far off to me. Let's be generous and say 25% of the project is software development.
If only 1/4th of the project involves software, then having a software development methodology that focuses on the user stories may not serve you best.
"But if we don't focus on the software we'll create waste!" Okay, let's get waste off the table. A lot of the non-software things are NOT waste, even on a "software" project. Creating copy, content, assets, plans, budgets, resourcing, marketing, photo shoots and processing, and infrastructure are NOT WASTE. You cannot play the waste card just because you are software-centric.
One way to avoid waste is to constrain the choices available for a solution. This is true for many projects, not just software. In software, the primary mechanism for constraint is called, "architecture." You specify a list of constraints and structures and goals which create the context in which you're going to build the software. Many Agile projects don't bother to architect their solutions.
If you don't bother to architect your solution, you are essentially "cutting slices" out of thin air. What exactly are you slicing thinly? An Agilist would say something like, "You may be thinking of it wrong. You are not 'slicing' so much as only building what you need for this story.'" But in software we learned long ago from Parnas (1972 in fact) that if you don't control the structure of your software (the architecture) it will come to control you. Spaghetti code is tangled precisely because there were too few constraints, too little architecture to keep the code in line [and of course clean code requires some developer discipline].
Agilist often skirt the architecture issue by saying things like, "the user story is a container for a conversation" and point out that through having these conversations you will discover what needs to be done for your thin slice. I don't buy it. The people having the conversations - the developers - are not trained architects experienced in the modularization that Parnas discussed.
The user stories are analyzed too late in the process to properly discover and plan. The user story is too focused to reveal the commonality required for modularity to be identified and the structures created.
Typically user stories are assigned to software developers or sprint teams that are focused on the software. Software developers often have disdain for project planning. Putting software developers in charge of protecting the project plan (and all of the non-software related activities that are required) is what author Alan Cooper called "letting the inmates run the asylum."
Producing the project plan based on the list of activities spanning the entire project helps create a comprehensive plan that involves everyone and shows the true demands placed on the team at large. This plan should show the activities listed in the order of their dependencies, including the software activities and the non-software activities. This produces the so called, dependency graph of activities for a project. It tells you your critical path and the order in which the activities need to be completed.
Provocative title, yes? Well, give me a moment to explain and I think you'll understand.
In the lore of Agile there is the notion of the "thin slice." The idea is that you build just what's needed to implement the current user story. You "slice through" each level of the solution architecture and implement the user story.
I've had real problems "thinly slicing" the solution architecture along user story boundaries. The primary problem is that the user story is focused on functionality delivered to the user, but there is a lot more than providing user-visible functionality needed to complete a modern project.
Software development is typically 15% to 25% of the project budget. This often strikes developers as unbelievable - especially the prima donnas. But it's historically been true and it certainly doesn't sound far off to me. Let's be generous and say 25% of the project is software development.
If only 1/4th of the project involves software, then having a software development methodology that focuses on the user stories may not serve you best.
"But if we don't focus on the software we'll create waste!" Okay, let's get waste off the table. A lot of the non-software things are NOT waste, even on a "software" project. Creating copy, content, assets, plans, budgets, resourcing, marketing, photo shoots and processing, and infrastructure are NOT WASTE. You cannot play the waste card just because you are software-centric.
One way to avoid waste is to constrain the choices available for a solution. This is true for many projects, not just software. In software, the primary mechanism for constraint is called, "architecture." You specify a list of constraints and structures and goals which create the context in which you're going to build the software. Many Agile projects don't bother to architect their solutions.
If you don't bother to architect your solution, you are essentially "cutting slices" out of thin air. What exactly are you slicing thinly? An Agilist would say something like, "You may be thinking of it wrong. You are not 'slicing' so much as only building what you need for this story.'" But in software we learned long ago from Parnas (1972 in fact) that if you don't control the structure of your software (the architecture) it will come to control you. Spaghetti code is tangled precisely because there were too few constraints, too little architecture to keep the code in line [and of course clean code requires some developer discipline].
Agilist often skirt the architecture issue by saying things like, "the user story is a container for a conversation" and point out that through having these conversations you will discover what needs to be done for your thin slice. I don't buy it. The people having the conversations - the developers - are not trained architects experienced in the modularization that Parnas discussed.
The user stories are analyzed too late in the process to properly discover and plan. The user story is too focused to reveal the commonality required for modularity to be identified and the structures created.
Typically user stories are assigned to software developers or sprint teams that are focused on the software. Software developers often have disdain for project planning. Putting software developers in charge of protecting the project plan (and all of the non-software related activities that are required) is what author Alan Cooper called "letting the inmates run the asylum."
Producing the project plan based on the list of activities spanning the entire project helps create a comprehensive plan that involves everyone and shows the true demands placed on the team at large. This plan should show the activities listed in the order of their dependencies, including the software activities and the non-software activities. This produces the so called, dependency graph of activities for a project. It tells you your critical path and the order in which the activities need to be completed.
Let's say that you have an activity graph like this one:
In this graph, activity A2 depends on activity A1. Activity A3 depends on A1 and A2 and so on. So that A12 depends on A11, A10, A06, A04, A03, A02, and A01. We know that we must complete A11, A10, A06, A04, A03, A02, and A01 before we can finish A12.
Suppose that this graph contains all the identifiable activities for the entire project and that when you get to the bottom the project can be considered done. If that's true (and I think it is) then we can think of user stories as the integration of the finished activities required to complete a user story.
That vision of the project would then replace the notion of the thin slice with the dependency graph as shown here:
That vision of the project would then replace the notion of the thin slice with the dependency graph as shown here:
The graph of activities is NOT the same as graphing the tasks identified within a user story. It simply doesn't work that way. Too many of the activities in a project (75% of them) are not related to software. If you take a software-centric view you will be missing much of the picture.
There are several things to note about this dependency graph with user stories.
First, as I've drawn this the user stories are bottom heavy and the activities are top heavy. That does not mean you need to complete all the activities before finishing the user stories, but it is likely to be the nature of things that more and more stories will be developed toward the bottom.
Second, we have now sliced the functionality required for each user story without focusing on the so called "thin slice." Anyone that has tried to do "thin slices" on a real project (with a budget and a deadline) knows that it is deadly to productivity because it forces too much rework. Talk about waste! Even very clever teams get bitten by rework. In the graph above, US1 (user story 1) is a combination of A8, A6, and A10. Your "thin slice" is to detect when A8, A6, and A10 are done and confirm that the story can be closed.
Working on a project in this manner also allows you to identify the critical path and resource accordingly - something that is extremely difficult, if not damned near impossible, if you take a user story focused view of your project.
Last, this is how the work happens anyway, only we fight it. And we lose valuable information by not acknowledging the relationship between activities and user stories. When we start an Agile project we usually have to fight against desire to do "technical sprints" or a humongous and overloaded "sprint 0". This is because we naturally want to fill in the top half of the dependency graph. We can embrace this notion without becoming top heavy and "waterfall."
Using the above method, the user stories become integration points - but be careful. Proper integration points are the integration between architectural components and services. Do not plan your project according to the user story integration points. This is a technique for showing the user stories in the big picture of a professional project plan, not the other way around.
No comments:
Post a Comment