Agile development not only benefits businesses that work with agile development teams, whether internal or external, it also benefits the teams. Here are the top 5 reasons to keep the team agile.
More involvement with the customer
Our team agrees that this is the #1 benefit of agile development. Damien told me, “…so you both gain a better understanding of how the app will work and be able to resolve issues and design adjustments quicker.” I couldn’t agree more. When I was playing the middle man role of PM I found that my translating back to the team wasn’t always 100%. When the team can interact directly with the customer, asking questions, getting clarification, discussing ideas, then there is a greater likelihood that what is produced is what the customer wants. This will, in our experience, work out well if the following is in place:
- The scrum master trusts their team
- The project is using scrum
- The customer understands scrum
- The customer understands that once a sprint begins it cannot be changed, unless they decide to prematurely stop it, and have meeting explaining why
As I said in my post about the business benefits of agile, I had heard this term thrown about without explanation. Let me explain it here. With scrum, the product owner (a.k.a. customer) puts stories into the backlog, and then controls the development by prioritizing the stories, with the most important on the top. At the beginning of each sprint at the sprint planning meeting, the team determines what they will commit to over the next 10 business days. They write out the tasks that make that story happen, and development begins. Each day there is a scrum, where the team and the scrum master get together. The team reports on the following:
- What did you do since the last scrum?
- What are you planning to do until the next scrum?
- Is anything holding back your progress?
In the daily scrum, the scrum master is a leader, leading the team through the process. While the scrum master can offer advice, he does not tell the team how to go about their daily development activities. It is up to the team to decide the best course of action. They are empowered! What a novel idea, empowering the people that are doing the actual work. That is what is meant by self management: the team manages the “how” rather than a project manager telling them. For us, this is a no brainer. There is literally no way for me, as a manager, to be involved in the code as deeply as the development team, so why not have them make their own decisions? I trust them, and we all learn from our mistakes.
Centralized controls fail in the face of increased complexity
Another step in removing the bureaucracy of the past is to delegate decision making to the feet on the ground people, in our case the development team. This becomes increasingly important as complexity grows. Should the understanding of what “done” means for a particular story, the team is the best equipped to determine impact, to decide what changes are necessary, and to put the changes in place.
Increased team participation
According to Ken Schwaber in Agile Project Management with Scrum, “optimally, a team should include seven people.” Schwaber is obviously referring to larger projects, as that would involve our entire team. The point here though is that the larger the group, the less overall communication you have. I will use my senior project class as an example. We had 21 people in the class and started out using a waterfall methodology (due to the teacher creating the groups – UI, database, etc.). When we were all together as a large group, the dominant personalities stood out and only they spoke. When we broke into our smaller groups there was a lot more interaction and everyone had a chance to speak. Perhaps there is something intimidating about large groups that cause many to shy away from speaking…
Happy developers == productive developers
Moving to agile development and scrum, empowering our team to make their own decisions, and removing the communication barrier between our team and our customers are definitely the best decisions I have made in regards to our development methodology. Our entire team is very happy to be using agile, and love daily scrum; we look forward to it every day. The team knows that they are trusted to make their own decisions, and don’t have to check with a manager before implementing them. They are happier developers for it, and are many times more productive, as they are left to focus on producing the highest quality product that the possibly can.
Using agile development with scrum can require a fundamental shift in the way project managers think and approach software development projects. It requires one to be more of a leader than a manager. It requires a great amount of trust; however, if you don’t trust those you work with then there is a fundamental problem that cannot be addressed in this post. Ultimately, in my experience, the result is a happier customer who is getting what they want – a high quality product that is what the envisioned. If the customer is happy, then we have been successful.