This post originated from an RSS feed registered with Agile Buzz
by Mark Levison.
Original Post: It’s not Scrum if…
Feed Title: Notes from a Tool User
Feed URL: http://feeds.feedburner.com/NotesFromAToolUser
Feed Description: Thoughts about photography, software development, reading, food, wine and the world around us.
The rules of Scrum are simple, but too often people forget that to actually do Scrum requires spirit, passion, engagement – and involving the whole team. This is a lighthearted list of some of the many things I’ve seen going wrong. It’s not Scrum if… Problem Why it’s a problem An alternative …the team is told what their velocity is. Velocity is a tool to help predict when you get a certain number of features complete and to plan for the next Sprint. It’s not a proxy measure for productivity. Allow the team to discover the rate at which they complete their work. …a burndown, burnup or cumulative flow diagram is confused with reality. All of these charts are models that give you an idea what is happening. They only measure quantity, not quality; nor what has been completed. All these charts are useful. Instead of looking for better charts, try “Genchi Genbutsu”:Go See for Yourself. Visit the team and see what Features are complete as part of Sprint Review. …you’re using the Scrum Task board to micromanage team members. I hope this is self-evident. Scrum is focused on the success of the team. Allow self-organization to have a chance. Teams need to learn for themselves how to work most effectively together. … you enforce Best Practices. No matter how good the practice (i.e. Test Driven Development, Unit Testing, etc.) enforcement breeds resentment, and compliance without understanding.Scrum is trying to harness the diverse ideas and opinions of the whole; not just an anointed few. Allow each team to grow/evolve its own practices. Provide them with support and the best information available. They will often find better options locally. Focus on outcomes, i.e. working software shipped every two weeks and not practices. Create community of practice to socialize and share. … the membership of teams changes frequently. Creating a high-performance team requires stable team membership. Create stable Feature Teams. …you treat your Product Owner as a Business Analyst with a better title. The Product Owner needs the ability to see the big picture with a product, and the authority to make decisions that cost 1-2 team Sprints (perhaps $150,000) without having their choices overruled. Find dedicated people who understand the Product area, give them basic Scrum Training. Trust them to make the right decisions at the Feature level. …you magically turn all your Project Managers into Scrum Masters. Many Project Managers don’t want to be Scrum Masters. Ask people what role they want to play going forward. Give them a short period of time to play that role and see if it’s a fit. Don’t make assumptions based on their current title, role, etc. Finally, remember not all people are compatible with Scrum. …your existing organizational structure remains the same. Scrum Teams require less formal organizational structure and more coaching. Agile organizations typically become flatter and more flexible over time. …you spoon-feed teams their User Stories or Features. When people aren’t engaged in creating the Stories/Features from conception to deployment you reduce understanding and engagement. Co-creating knowledge is more effective than knowledge transfer. Involve the team in creating the Product Backlog. …you break the Stories down into tasks for the team. Same as above; you’re detaching people from the Story they’re building. …you maintain your existing roles, i.e. Developer, QA, BA, and Usability. Formal roles create bottlenecks and foster individual work. In addition, they encourage handoffs. Scrum wants collaborative work. At the team level, ignore all formal titles. Our goal is high quality working software, not handoffs. …your Impediments Backlog remains unchanging. Scrum is about improving the way we do work. An unchanging Impediments list/Backlog signals that no one is engaged in making things better. Select one or two Impediments per Sprint; find something small to improve related to them. Practice true Kaizen (a continual dissatisfaction with the current state). Often the smallest improvements have a huge effect on morale. … you have phases – Requirements, Design, Development, … There are no separate phases. Scrum Teams are expected to produce working products in the first Sprint. In practice this is hard to achieve at first, yet remains the goal. In addition, we don’t have separate phases within the Sprint. The most effective teams find ways to create Acceptance Tests before starting the Development work. …you keep repeating the same actions and getting the same results. Scrum is intended to challenge the status quo. When you create a new status quo, Scrum challenges it again. Scrum invites a true Kaizen mindset – Congratulations! We’ve achieved a great improvement which allows us to see an even greater improvement just ahead. …you focus on the tools and not the people. Remember: Individuals and Interactions over Processes and Tools Tools are useful but they’re not our focus. Use these tools if the teams feel they’re helping them succeed; not because management requires blow-by-blow reporting on tasks. …your team members don’t feel professionally challenged and fulfilled emotionally. Scrum should be fun. See the above list that leads to disengagement, etc. Remember, it took years to get people into this state—it will take many months, if not years regrow lost spirit. From all of these rules, remember that Scrum itself isn’t the point. The point is to deliver high quality working software, which we do most effectively by creating High Performance teams. Scrum is a tool to create teams, no more. Thanks to Neil Killick, Neil Johnson, Amy Neil and Marc Andre-Morriset for their suggestions, which are represented in spirit, if not exact copies of their tweets. What are your “It’s not Scrum if…” stories?
Previous Topic
