What does it take for your software development team to be agile? Only you and your team can answer that question. I can offer my opinion about being agile but your circumstances may vary. The characteristics that one person requires for agility will be different from what someone else in a different situation requires.
For example, small teams will always be more agile than large teams. Why? Fewer communication paths. Information flows faster on small teams. Another example: A team with small customer base will be more agile than one with a large customer base. Why? Again, fewer communication paths.
Phases Can Help But Only So Much
In my series of posts discussing the use of phases in agile software development, I addressed the need to align the business and technology teams during the inception phase. When cross-functional teams are in agreement, things happen faster and agility improves.
I also discussed addressing risk areas and unknowns during the elaboration phase so that the business establishes a clear direction early in the project. When you mitigate risks and eliminate major unknowns, you’ve set up your team to move quickly and deliver often. So if your team does those things, are you agile?
The team is likely to be more agile than it was but probably not as agile as it could be. So where do you go from here? At this point, there’s a tendency to focus on process improvements. The business and the development team will look for ways to eliminate impediments and increase efficiencies. Those are good goals but may leave everyone feeling like management just wants them to work longer and harder. Tread carefully.
Top Characteristics of Agile Teams
I’m not going to refer you to the agile manifesto for advice. I assume you’ve already read it. Instead, here are my top three characteristics of agile software development teams. You’ll notice that the focus is on subjective criteria not objective actions like grooming backlogs and deploying often. Why? Because being agile is more about people mindsets than software artifacts.
1. Focus on the customer. Engineers like to focus on technology — cool stuff. So do I. But, ultimately, success or failure depends on the customer’s perspective and in most situations, the customer doesn’t care about the underlying technology.
Listen to your customers. Whatever is important to them must be important to you. Help them understand risks and complexities so you can jointly establish priorities.
2. Be open and transparent. Keep an open mind. Share information. When mistakes happen, discuss them openly so that everyone can learn and do better. There’s no shame in making mistakes. There’s only shame in burying them so they can rise again and strike someone else.
Treat every small failure as a learning opportunity and vow to do better next time. Progress is making new mistakes and discussing them openly.
3. Keep improving. Don’t stop seeking ways to do better but don’t try to change too much too fast — unless you’re willing and able to spend the time and invest in the training needed.
If you think your team is good enough, think again. You missed something. If you think your team has peaked, shake it up. Introduce new people and inject new ideas.
photo credit: Community Photography ‘now & then’ via photopin cc