How To Kill The Sprint

December 31, 2012

As users of the Agile methodology, you are all aware of the sprint. The more you do the sprint, the more you find that its usefulness is dependent on the effort that you put into it regardless of your role on the team. Below are seven surefire ways that you can kill the sprint’s effectiveness.

  • Begin with an irregular sprint schedule, or better yet change the sprint schedule in the middle of the sprint run. Allowing the workload to be dictated by someone other than the team ensures that your sprints will be on an irregular schedule.
  • To give time back to your team members, simply require an email, a tweet or text message, an entry on a spreadsheet, or even a phone call from every team member to provide an update on their status. The daily standup meeting is too tough to coordinate because the team works a flexible schedule. Good team members should be able to collaborate electronically and be just as effective.
  • Sprints carry too many deliverable products to track. Instead of requiring a shippable product from the team at the end of each sprint, just work towards the end goal. The customer can test the product as a whole when it is complete, and in the process the product owner gets to eliminate all of the overhead that comes from tracking progress. All the team needs is a deadline and requirements.
  • Speaking of requirements, once a product owner has met with the customer, they should have everything they need to complete the project. After all, once everyone agrees on the requirements, specifications, and the due date, all the customer should be concerned about is the deliverable. Once the deliverable is ready, then you can get back with the customer. No need to communicate progress or status – we all agreed on this at our one meeting.
  • Stakeholder management is just too complicated. Being able to send out a dashboard with the project status should be good enough. If a stakeholder has a question, they should contact the customer. The team is simply responsible for is creating the product, but the customer is the one who is responsible for the success or failure of the product in their organization. So in reality, the customer should be more concerned with stakeholder management than the project owner.
  • If someone on the team encounters a roadblock, they should work on clearing that roadblock themselves. The reality of today’s environment is that everyone is constantly interrupted and priorities change daily. Part of a team member’s professional growth is in learning how to deal with those types of issues.
  • Managing a backlog is another administrative task that can be eliminated. Once the requirements are set, the team has all that they need to complete the deliverable product. A good team should be able to break down the tasks and parts that need to be completed in order to ship the final product. Why does there need to be a meeting to accomplish this?

This is obviously a tongue-in-cheek look at the sprint, and members of a Scrum team would never intentionally do this. If this approach is taken, then the project likely will end up as a colossal failure. But you might find one or two here that you could be slipping into because of demands on your time or simply complacency. If so then hopefully this is a good wakeup call. Let us here at Braintrust help solve your problems! With our experienced team of Scrum coaches, Braintrust has the experience and resources to help you do Scrum in a world-class manner. Click on the Contact page to hear from one of our product specialists. Or, head over to the Services tab to find out more about our offerings.



Share a little biographical information to fill out your profile. This may be shown publicly.

More By This Presenter
Skip to content