Comments on: Remove Finish-to-Start Activities on Agile Projects

By: Lanooba

Lanooba — Fri, 19 Feb 2010 21:52:50 +0000

Hi Mike:

I am experiencing the exact same issue as a SM for a product that touches all others in the enterprize. Because we don’t have a pre-defined EA, I’ve been advocating starting small and progressively elaborating. The problem is – the team vehemently disagrees on the definition of “small”
In other words, it’s quite difficult to define what just enough means. And it certainly doesn’t help that we’re starting from stratch and have time constraints.
I certainly don’t have the technical aptitude in that area to define it for the team, so the argument continues.
As much as I don’t want to, I’m considering EUP (Enterprise Unified Process) – a spin on UP, as a potential solution. But I feel like this step will regress us into Waterfall…sigh.

By: Mike Cohn

Mike Cohn — Sun, 10 Jan 2010 15:46:01 +0000

Hi Sameh–
You’re absolutely right about the human brain. I’m no cognitive scientist but a sequential approach to work seems to fit our brains. I want to think about what needs to be done, then I want to design a plan for doing it, and then I’ll do it. If our brains work this way, it’s only natural that we would have for years tried to force a sequential process onto software development.

By: Sameh

Sameh — Sat, 09 Jan 2010 14:27:23 +0000

I think the activity-based sprints approach resembles Water-fall. The hand-offs from skill set to another is done across the sprints.

The traditional V-model parallels the QA activities with those of analysis and development. QA is for defects prevention rather than after the fact quality control. Having this in mind, I think we can blend QA, developers and analysts to work on same user stories in the same sprint.

QA can work in making conditions of satisfaction of the user stories more comprehensive. This itself help to gain better understanding of the requirements and better estimation for sizing.

Human mind tend to think sequentially. The approach of Inter-leaving work and concurrency on same story is not easy to visualize and cannot be managed by traditional management.

Thanks Mike for raising this interesting subject.

By: Mike Cohn

Mike Cohn — Fri, 08 Jan 2010 20:55:30 +0000

Completely understandable, Rob.

What I’d suggest is picking a time when everyone feels up for an experiment and see if you can bring more cross-discipline work into the sprint and see what that does to communication. My usual recommendation (for any experiment like this) is to try it for two sprints before making a decision about how it’s working. By all means, do a retrospective after the first and see if you can think of tweaks to what you tried but don’t give up after one sprint. A lot of changes feel weird in the first sprint doing them. Good luck.

By: Rob Godfrey

Rob Godfrey — Fri, 08 Jan 2010 20:44:22 +0000

Hi Mike,
I was trying to make the point, probably poorly that “just enough analysis” might take quite a bit more time to perform than what might be typically assumed given a story is commonly described as being quite lightweight (i.e. something like a story card, some acceptance criteria and maybe a UI design). I completely agree that “just enough” is very dependent on the context as you describe, and also that process shouldn’t trump interactions within the team.

My team have settled on performing the analysis one iteration ahead, which I think works quite well for the majority of our story development. I think there is also something to be said for having a degree of predictability and rhythm to a process.

I’m finding thinking of activity-specific sprints as bad practice a little difficult to digest at the moment, probably because a) this is what my team currently do and b) there are far worse ways to develop software in my view. Time to ponder and reflect I think.

By: Mike Cohn

Mike Cohn — Fri, 08 Jan 2010 19:37:28 +0000

Hi Rob–
You might be misinterpreting what I consider “just enough.” You say your team might do analysis for several days. I’ve worked with a team that was fantastic that had to do up to 6 months of analysis before programmers could start. (This was a bioinformatics company and the analysts were dual-Ph.D.s in math and genetics. They would prototype an algorithm in Mathematica and then hand it to the programmers. The prototyping though was really lots of deep thinking to find a new way of looking at data that would be meaningful in the product.)

This is why I never define how long “just enough” is. It depends completely on the domain, application, team, and other contextual factors. What I don’t want to do though is have a company say “all backlog items are analyzed six months in advance” just because some need to me. We don’t want to institutionalize things like that.

By: Rob Godfrey

Rob Godfrey — Fri, 08 Jan 2010 18:34:22 +0000

In my view “Just enough” is very dependant on how cheap a system is to change should an analyst change his or her mind mid iteration, and how much slack a schedule has to accommodate this work. Developing production ready working software to explore options can be an expensive activity. I’m not denying that learning may have occurred during this exploration, but there are often cheaper ways than coding to explore and home in on a good solution.

My team work with analysis occurring one iteration head of development and it works for us. However due to the nature of the work, developers often assist with the analysis effort using spikes, prototypes, etc before we commit to an actual approach that is developed as production ready software in the subsequent iteration. So in our context “just enough” for a complex story could be several days analysis and several days prototyping effort. Just enough might not be as small as you might think.

By: Mike Cohn

Mike Cohn — Thu, 07 Jan 2010 18:03:43 +0000

Hi Terry–
Websites make great *first examples.* Even if someone has never coded a website, they’ve used enough to have an idea of what’s involved (certainly by now!) But, for an argument to be compelling into broader applications, it does need to go beyond, “Suppose you’re building an eCommerce site…”

By: Mike Cohn

Mike Cohn — Thu, 07 Jan 2010 18:01:46 +0000

Hi Alex–
Your example of the mockup stapled to a card is perfect. When I train on this topic I usually hold up an index card and then hold a few pieces of paper behind it and say that “sometimes we staple additional information to the story card. It can be a screen mockup, a workflow diagrammed in Visio, etc.” I give examples of mathematical algorithms worked out in Mathematica being stapled to the card for the team to convert into Java code and so on.

WIth the user interface example, I make the point that what is stapled to the card does not need to be (and should not be) pixel perfect. The designer could attach a screen design saying, “Make it like this except for this little region here on the screen. I’m still working with some users to figure out how best to do that. But I can do that during the sprint and you’ve got plenty to get started on the rest of this.”

By: Terry McKee

Terry McKee — Thu, 07 Jan 2010 15:36:02 +0000

Nice post Mike. I have seen this tendency to have requirements working two sprints ahead, architecture working one sprint ahead and testing working one sprint behind. I think there is something more dangerous than the finish-to-start relationships that you talk about. The main problem is that the process you describe decreases communication and builds up walls between traditional disciplines. (You hit on this with your comment on the “lack of whole-team responsibility.)

By the way, I really liked Jarkko’s comment. Websites are often used to illustrate agile techniques. While website development has its challenges, there are many other types of projects that are far more complex. Sometimes with these more complex projects, applying some of the very basic agile techniques can be a challenge (like simply identifying user stories that provide business value).