Join Doug Rose for an in-depth discussion in this video Understanding agile history, part of Agile at Work: Building Your Agile Team.
- Many teams start out by thinking of Agile like any new tool set, almost like they're training on how to play a new sport. First, you learn the equipment, then you learn how to swing, then you learn how to catch, and then, finally, the team is playing well together. But, if you see Agile as simply a new set of tools, then you're unlikely to have any real productivity gains. Agile already assumes that each team member knows how to play the game. The key is to change how the team plays better together. They should find better harmony, and take greater responsibility for their work.
You should start to think of Agile as a shift in the team's mindset. The team should be viewing their work in a way that's much different than before. Only after the team changes this mindset, can they drive to greater efficiency in productivity. Changing how people think about their work is much more difficult than changing how people do their work. It's like that old adage, that it is much easier to give a person a fish, than to teach them fishing. Any team can change the name of their roles and meanings, but an Agile team changes the way they think about these things.
That's why you need to change everyone's mindset from the very beginning. Otherwise, the team will settle back into the way they've always done things. The momentum, at nearly every organization, is always stay the course. Your team's mindset will be the key to whether or not your organization succeeds with Agile. If you can change the way you think, then you can change the way you work. If you change the way you work, then you can become more Agile. If you become more Agile, then the rest of the organization will want to change.
So, when you think about Agile, don't just think about the new roles and responsibilities. Instead, think about the new mindset for each role. How will each team member think about their work differently? The term Agile is really just an umbrella term for several of the popular lightweight frameworks. One of the most popular Agile frameworks is Scrum. You may have also heard of Extreme Programming, Kanban, or the Scaled Agile Framework. Each of these frameworks has their own names for the team roles. Kanban is the most lightweight of all these frameworks, and has no defined team roles.
Here, we'll use the names for the roles on a Scrum team. You should be aware that these are not the only names for these roles. If you chose another Agile framework, like Extreme Programming, then the roles would be similar but the names might be different. Agile is often seen as loose when it comes to team practices. You might hear an inexperienced team say something like, "We changed our roles a bit. You know, so we can be more agile." In reality, Agile is lightweight, but not loose. The Agile team roles are very clearly defined.
So, if you're a new Agile team, it's best to stick pretty closely to the defined roles. The "agility" in agile refers to the lightweight methods, and not to flex ability with the team makeup. In general, Agile only has a few rules, but they should be closely followed. Try to remember that each of these roles has a larger purpose. The purpose is to drive the team to take on greater self-organization and courage. If the team has a traditional manager, then you won't get as much benefit from going Agile.
To be truly Agile, you need a real Agile team. So, these team roles are not just guidelines that you take into consideration, they're crucial ingredients for your Agile team. If you skip one, or change another, then you might be giving yourself too many obstacles for your Agile efforts in the future.
Lynda.com is a PMI Registered Education Provider. This course qualifies for professional development units (PDUs). To view the activity and PDU details for this course, click here.
The PMI Registered Education Provider logo is a registered mark of the Project Management Institute, Inc.
- Starting agile in your organization
- Defining team roles and responsibilities
- Letting the team self-organize
- Training the team
- Thinking and delivering like an agile team
- Avoiding pitfalls