Join Doug Rose for an in-depth discussion in this video Avoiding "We don't plan, we're agile", part of Agile at Work: Planning with Agile User Stories.
- Sometimes with newer agile teams you'll hear them say, "We don't plan because we're agile." This causes a lot of confusion with the rest of the organization. They'll justifiably ask the question, "How can you run a project without any planning?" The truth is you can't. Agile does have planning. It's just different from traditional project management planning. The planning rules are there, but they're just much more lightweight. You'll find this is true with a lot of agile frameworks. In agile, there aren't usually very many rules, but at least at the beginning, the rules that do exist should be closely followed.
If you're the Scrum master for the team, you need to make sure that the team members don't use your agile transformation as an excuse for making their own process changes. With every project there are some tasks that team members like to do more than others. Most developers prefer to write software. It's pretty rare to find a software developer who really enjoys producing documentation. This is true with the rest of the team. Usually team members prefer to do the work as oppose to plan the work. But it's important to remember that the frameworks are about agile product delivery.
It's not about constantly changing the framework. You don't want to start your agile project by creating your own version of Scrum, extreme programming, or Kanban. Being agile means that you allow your customer to change the product. It doesn't mean that you're free to change the framework. That means if you're the Scrum master for the team you should be very careful not to let the team get too creative with how things get done. Every team needs to have a product owner. The team needs to decide the length of the sprint and then stick with it until the end of the project.
There's plenty of flexibility in the product, but there should be much less flexibility in how you deliver it. Your team shouldn't think of agile as a free ticket to work however they like. This is particularly true around agile project planning. Each planning event, like the release planning event we saw in the previous video, has a specific agenda. The Scrum master needs to make sure the agenda is closely followed. Again, it's important to not confuse the word agile with how you run these events.
If anything, agile planning events are much more formal. They'll have a set amount of time with some direct purpose. One time I worked with a team that was starting to use agile for the first time. They didn't have the people available for a full agile team, so they merged some of the roles. The Scrum master and the product owner was the same person. One of the developers also acted as a project manager. They made all these changes and declared that they were creating their own agile framework. It's important to not take this approach when you're starting out with your agile team.
Start out by following the framework as closely as possible. Only after your team is well formed should you even consider making changes to the agile framework.
- Starting with user roles
- Creating user stories
- Grouping stories with themes or epics
- Creating a project charter
- Writing your release plan
- Avoiding common pitfalls