The third line in the ScrumButt Test is: "The Sprint starts with an Enabling Specification."
What does this mean?
The first practical goal was to eliminate the analysis paralysis and delay associated with waiting until the specification was "complete".
But, on the other hand, too many agile teams are trying to be effective when 'no one knows what we are supposed to build'.
What is wrong with the old waterfall process? (at least in my opinion):
Well, it turns out to be a Goldilocks idea. We have some wish to make the team efficient and at the same time we know we are learning all the time. So, we advocate an Enabling Spec. Not too much, not too little; just right.
What does this mean?
Well, at a minimum it means that the business person involved (in simple terms, the Product Owner) at least thinks he understands the story (let me assume the team is using User Stories). And at least thinks he can answer all the questions. It is also a good practice for the Business Analyst (or someone) to write down a half-page or a page or two of diagrams or notes. In the course of doing that, she (the Business Analyst in this example) will ask the PO several questions, and find out that he doesn't have the answers yet, and so new learning will happen.
But the enabling spec is very short. Maybe a bunch of diagrams. The good stuff is not buried in wads of paper.
Who decides what the enabling spec looks like for a given team? The consumers. Primarily the coders, the testers and other team members who must use it. Different projects and different teams (and even different situations) may require somewhat different enabling specs.
Let me be clear. Scrum itself does not require an enabling spec. But I (and Jeff Sutherland and others) are recommending an Enabling Spec as a best practice.
Scrum does say "improve your engineering practices" and I (and many others) would suggest that one improvement area would be around "requirements", and more specifically, one would be using Enabling Specs.
Be aware that some in Agile would advocate no written spec at the beginning of the Sprint. Nothing written; just have conversation in the Sprint. This has worked, although I think it typically is not optimal (ie, the team usually could have done more if they had used an Enabling Spec). While I agree with the importance of the conversation, face-to-face with Q&A, I also think the 1-5+ page Enabling Spec per Story is also helpful. As long as there is discussion between the writer and the readers about what in it was useful or in the way, or just missing (and needed to be written down). (Answer to a question: Yes, all the Enabling Specs developed so far could be in one document, if the team found that useful.)
I would suggest that about 5% of the team's total time in this iteration should be used to prepare for the next Sprint. This includes building and discussing (at a high level) the Enabling Specs for the next Sprint.
Remember that we are always learning. Just because something got put in an Enabling Spec does not mean it can't change (if we now know better). At the same time, an unprofessional attitude about learning ("oh, I'll just let myself learn about that later") is not allowed either. We are trying to learn as fast as we can. By putting all our minds together.
{Note: To find our previous posts on The ScrumButt Test, you might search on that term in the Blogger search box at the top of this page. We have 3 earlier posts.}
What does this mean?
The first practical goal was to eliminate the analysis paralysis and delay associated with waiting until the specification was "complete".
But, on the other hand, too many agile teams are trying to be effective when 'no one knows what we are supposed to build'.
What is wrong with the old waterfall process? (at least in my opinion):
- too much delay
- a pretense that further change (or learning) won't happen
- a magical belief that the customer can really fully understand a spec (I have seen it happen maybe once)
- a magical belief that "all the questions are answered by the spec", when we know that people learn much better in a face-to-face Q&A format
Well, it turns out to be a Goldilocks idea. We have some wish to make the team efficient and at the same time we know we are learning all the time. So, we advocate an Enabling Spec. Not too much, not too little; just right.
What does this mean?
Well, at a minimum it means that the business person involved (in simple terms, the Product Owner) at least thinks he understands the story (let me assume the team is using User Stories). And at least thinks he can answer all the questions. It is also a good practice for the Business Analyst (or someone) to write down a half-page or a page or two of diagrams or notes. In the course of doing that, she (the Business Analyst in this example) will ask the PO several questions, and find out that he doesn't have the answers yet, and so new learning will happen.
But the enabling spec is very short. Maybe a bunch of diagrams. The good stuff is not buried in wads of paper.
Who decides what the enabling spec looks like for a given team? The consumers. Primarily the coders, the testers and other team members who must use it. Different projects and different teams (and even different situations) may require somewhat different enabling specs.
Let me be clear. Scrum itself does not require an enabling spec. But I (and Jeff Sutherland and others) are recommending an Enabling Spec as a best practice.
Scrum does say "improve your engineering practices" and I (and many others) would suggest that one improvement area would be around "requirements", and more specifically, one would be using Enabling Specs.
Be aware that some in Agile would advocate no written spec at the beginning of the Sprint. Nothing written; just have conversation in the Sprint. This has worked, although I think it typically is not optimal (ie, the team usually could have done more if they had used an Enabling Spec). While I agree with the importance of the conversation, face-to-face with Q&A, I also think the 1-5+ page Enabling Spec per Story is also helpful. As long as there is discussion between the writer and the readers about what in it was useful or in the way, or just missing (and needed to be written down). (Answer to a question: Yes, all the Enabling Specs developed so far could be in one document, if the team found that useful.)
I would suggest that about 5% of the team's total time in this iteration should be used to prepare for the next Sprint. This includes building and discussing (at a high level) the Enabling Specs for the next Sprint.
Remember that we are always learning. Just because something got put in an Enabling Spec does not mean it can't change (if we now know better). At the same time, an unprofessional attitude about learning ("oh, I'll just let myself learn about that later") is not allowed either. We are trying to learn as fast as we can. By putting all our minds together.
{Note: To find our previous posts on The ScrumButt Test, you might search on that term in the Blogger search box at the top of this page. We have 3 earlier posts.}
No comments:
Post a Comment