Over the past few years, I have had the pleasure of working with multiple teams with each practicing their own flavor of Agile. This has given me the opportunity to see how processes grow and evolve based on the goals, strengths, and challenges faced by the teams. I have also been able to witness and gain insight into some of the confusion and mystery surrounding the Agile Methodology. For those who are just starting out on this path or those that are seeking a little more clarity, I offer you these three steps to help you on your way.
1. RTFM – Read The Famous Manifesto
Take the time to read The Agile Manifesto including the Twelve Principles of Agile Software. Despite how much has been written about Agile, the manifesto is quite short and easy to follow. By reading the words yourself, you will build your own understanding of them. It is that understanding that will help guide you to success as you discuss and evolve processes and methods with your team.
2. Confirm Team Alignment
Agile is not just for developers. It is for the whole team which includes developers, testers, product owners, facilitators, and stakeholders/customers. With that many roles involved, it should be obvious as to why you need to make sure everyone has clear expectations of their responsibilities and the ultimate goal of the team.
You may note that I said “roles” rather than “people” when describing the members of the team. That is because a single person may perform multiple roles on a team. For example a stakeholder may choose to also be the product owner or the lead developer may also be the facilitator for the team. No matter how many people the team has, alignment on duties and expectations is essential.
The Product Team:
- Stakeholder: Provides input about the product. May also have financial responsibilities to the team and/or product.
- Product Owner: Defines and prioritizes the project stories and tasks.
- Facilitator: Runs meetings, removes obstacles, and shelters the team from interruptions.
- Developer: Plans and writes code for a software project.
- Tester: Confirms the application functions as expected.
As part of the team alignment, it should be agreed that no one member should act unilaterally because this hinders communication and will effect the project. While each member has ownership of an aspect of the project, they should make decisions based on information gathered from both their experience and that of their teammates. Product owners are responsible for what is being worked on but they should not dictate the completion dates. Developers control the frameworks, tools, and technologies used in the product but they should consider the advise from the testers to make it easier to catch bugs.
Communication and consideration are key to building team alignment.
3. Find What Works For Your Team
Agile is not a destination. Nor is it a single skill, practice, or process. No one can provide you with a checklist or script that will transform any team or product into an Agile one. The reason for this is every team and situation is unique and as such requires an equally unique solution.
This isn’t to say that there isn’t value reading about what other teams have done. Developing a unique solution doesn’t mean you have to build everything from scratch. In fact, it’s probably better for teams to adopt some practices they learn from articles, books, or an Agile Coach when they are starting out. This will provide the team with a chance to avoid some of the pitfalls and get a jump on their progress.
The key is to not get hung up on “the right way” or “requirements” of being Agile. If your team has found that part of the process isn’t helping to achieve the end goal, get rid of it. Teams should be allowed to determine the best way for them to function. So long as they continue to communicate with each other (including stakeholders, customers, etc), are able to adapt to change, and deliver working software on a regular basis then the team is successfully implementing Agile.