As I have worked on Scrum teams in companies that were traditionally waterfall, I have observed how the various team members struggle with the concept of the collaborative, cross functional team. Ken Schwaber describes the tendency to resist these changes and fall back into old habits as “muscle memory”. When a traditional project manager was brought onto our team as our Product Owner, he asked several questions and received answers he was not expecting:
Question: Where is the functional requirements documentation?
Answer: There is none. They are in the Product Backlog as User Stories.
Question: Where is the architectural and design documentation?
Answer: There is none. It is in the code itself.
Question: When do I get status reports?
Answer: Never. Every day we have a Daily Scrum and update our tasks in the Sprint Backlog.
While I am not a true agilist, I do believe that relying on static documentation and periodic status reports to keep track of a project is what I call “managing from afar for plausible deniability.” Being a part of a Scrum Team means accepting a large level of responsibility. Product Owners cannot simply stroll in occasionally and rely on one-off status reports to gauge how well a project is going. Everyone is involved and it is not an opt-in process. No one on a Scrum should ever be able to use the excuse “I did not know…”
This does not only affect the Product Owner. The most resistance I have gotten in the past is from Quality Assurance. Typically they are used to detailed specifications to create detailed test cases that they execute after the development process is over. In a Scrum Team, the QA testers are peer members just as much as the developers. I’ve had the complaint before that all QA was given at the start of a Sprint to create their test cases were User Stories and Conditions of Acceptance. My response is “You’re right, but that’s all I have to go on too and I have to write the code!” The best way to get QA on board in my experience so far has been to have them at every Daily Scrum and in any design or requirements gathering sessions the developers have. This means getting your testers out of their section of the office and in the thick of the development team. They can use the User Story as a starting point and then flesh out their test cases along with the developers as the functionality is created. They can perform dry runs on code that is nearing completion so that at the end of the Sprint the goal would be that all code has been QA tested at least once.
Developers are not immune to this ailment either. Some junior or less disciplined developers may become vapor locked when they have to start coding without a detailed specification. You cannot go code in the corner and be fed requirements and Jolt cola through a slot in the door. You should not turn to the Scrum Master when you have finished a task and ask “What next?” The excuse “That’s what it said in the spec” is no longer valid. Team members must rely on constant collaboration to make sure the developed solution meets the user’s needs as well as the team’s technical standards.
I must admit the teams I have been on have experienced these problems and we still struggle against old habits. We try to make good use of the Sprint Retrospective to adjust each iteration to make the process better. Our Scrum Team has met every date, encountered very few QA or production defects, and has made our stakeholders consistently happy. We have done this through constant collaboration across all members and by evolving our process. There have been very few late nights and no death marches. And I have to say that the experience had made my statement of not really being an agilist less true each time I say it.
No comments:
Post a Comment