As part of my Dell Agile coaching work, I comparing notes with another coach about a project was talking with collegue today about a team that was going into “scramble mode.” In addition to being behind, they had a new manager without Agile experience.
My suggestion: Use Weekly Sprints!
You should consider short sprints in the following cases:
- New Team / Learning Agile (more time working together)
- Uncertain Requirements (more feedback from marketing)
- Behind Schedule (more delivery points and visibility)
- Prototypes / New Technology (more feedback from engineering)
- QA / Hardening Phase (more intergration points)
Shorter sprints (this team is on 3 weeks) have a proven record for boosting productivity, increasing teamwork and getting more accurate results. As an additional benefit, the new manager gets to experience 3x more planning meetings and become more familar with how the process works.
The reason is simple: more planning means more feedback.
For many, shorter sprints seems contradictory to being more productive. This aligns with my personal experience. A team that plans in frequently generally plans inefficiently: long meetings, vauge committments, fuzzy tasks and poor estimates. In many cases, the team simply does not remember what was planned by the last week!
Shorter sprints, while a lot of work to manage well, are generally much shorter. Reviews cover less ground, retros are more concise, and planning has less ground to cover. Weekly planning for a practiced team should be less than 4 hours.
Next time your team stumbles with Agile, consider shorter sprints as a way back to your normal pace.
We’re hiring new managers and developers into my team and its important (to me) that we find people who will embrace our Agile processes.
Sadly, many people experience with the fluffy Agile decorations and not its core disciplines; consequently, interviewees will answer “yes, I’ve done Agile” and not really (IMHO) know what they are saying.
So I wanted to craft some questions that will help identify good Agile candidates even if they have no experience (or negative experience) with the process.
- Explain a time that you did not agree with a design decision that was being made. [Good candidates will tell you that they had a healthy debate about it, made sure they were heard, and then supported the team decision. Excellent candidates will give you a specific case where they were wrong and the outcome was better their suggestion.]
- How have you handled the trade-off between shipping quality software and getting a release done on time? [Good candidates will be pragmatic about the need to release but own quality as their responsibility. Excellent candidates will talk about implementing TDD and automation so that quality can be maintained throughout a release cycle.]
- How have you made changes to your work habits based on retrospectives? [Good candidates will tell you about items where they had to acknowledge other people’s suggestions and change their behavior. Excellent candidates will be excited about having ownership in their team’s continuous improvement and can give examples.]
- Why are sprint reviews important? [Good candidates will say that it’s important for a team to show progress to other groups. Excellent candidates will tell you that it’s how a team shows that it is meeting its commitments and getting feedback to improve the product.]
- Is it possible to achieve the objective to be “ship ready” at the end of each sprint? [Good candidates will say that ship ready is a great target but only practical in the last sprints before a release. Excellent candidates will explain that being ship ready is a core driver for the process that ensures the team is focused on priorities, quality, and breaking work into components.]
- Tell me about the best performing team that you’ve been part of. What made it a great team? [Good candidates will tell you about having quality people or a very tight focus. Excellent candidates will tell you have the shared goals of the team and how people gave up individual recognition to accomplish team objectives.]
- What does it mean to for a team to be transparent? [Good candidates will talk about status reports and documentation. Excellent candidates will talk about being willing to take risks and fail fast.]
If they can’t pass theses questions then go buy a lifeboat. You’ll want it for that that waterfall you’re going to be riding down shortly.