In our most recent Agile blog, Building Agility through Individuals and Interactions, we described how the Agile model, if executed with the right mindset, will enable team members to drive execution and communication inherently within the process, without leadership mandate. We hope you found this concept to be insightful, but now you are probably looking for some tangible ideas to bring the concept to life. So let’s talk about some tips for implementing this culture within your development teams.
Organization and Buy-In
The first step in achieving this mindset is to organize your teams properly. The Agile Scrum practitioners of the world strongly recommend an ideal team size of 7. Studies have shown that you may go +/- 2 from that ideal. Any more than 9 or less than 5 and you start to lose efficiencies, simply due to team size.
There are many reasons why we’ve seen this to be the most efficient, but being the math guy that I am, I’ll speak to my favorite: Pathways of Communication. Pathways of Communication (POC) is a term for how many unique communication ‘pipes’ exist within a team. The more people on a team, the exponentially higher the number of POCs result. For example, if you insist on having a 12 person team, you will have 66 POCs! That results in a lot of meeting time just to make sure everyone is on the same page. Or, teams can run the other direction and start cutting people out of the discussion. This leads to trouble as good communication gets left behind and things start to fall through the cracks. The mathematical formula behind this theory is POCs = n*(n-1)/2 where n is the number of team members.
Once you’ve got the right team size, run an inclusive culture where everyone feels bought-in and accountable. Hierarchy stunts collaboration and innovation so no one should be ‘above’ anyone else. If every team member feels that that are on an even playing field, then the team will naturally adopt ‘Individuals and Interactions’.
In terms of execution mechanics, inclusivity starts at ideation and continues through story creation and grooming. Invite the developers, while clarifying your upcoming features and stories. They will feel more involved and will provide feedback that will save you headaches during sprint execution time. In a similar vein, inviting the entire team to the estimation session is a MUST. We find that if the entire team participates in the estimation session, then they feel far more bought into the amount of effort they need to put in to deliver on time.
In the world of software development, instant gratification and correction is now a reality. We have found the quicker we are able to give feedback to our teams, the quicker they work while producing higher quality. Even better, the more likely they are to reach out to each other and discuss issues and ask questions.
We put as many feedback loops in place as possible to encourage this sort of behavior amongst team members. Many of these mechanisms is commonly referred to as Continuous Integration. Continuous Integration is a simple concept; the moment a developer checks something in, the code is compiled, built, and tested (both in terms of quality and function). Results are recorded and displayed to the team. These results provide immediate feedback and informs both the developer and team if the code quality was increased or decreased. This immediate feedback mechanism instills an innate sense of accountability and drive to make things better. If a developer checks something in that fails a test, the entire team is going to discuss because they should not continue coding progress until the checked-in code passes.
Now, our team is asked to build a business feature that will make millions of dollars if we get to market quickly. When building a story, we have a choice; do we create 1 story for each layer of the cake, or do we create a bigger, ‘vertical’ story that include all 3 layers?
Some Agile teams may be tempted to create a story for each layer for this feature. This way Anton, Brian and Shawn could each have their own stories and go on their merry way coding up a storm. In reality, what ends up happening is they check their code in only to find out that their schema definitions don’t match. They didn’t quite line up the boundaries of each story; some things overlap, some things are missing. They have to go back and rework. Frustration ensues and as this problem snowballs, deadlines are missed. So much for making millions of dollars!
On the flipside, if we create a vertical story that incorporates all layers, nothing actually changes in terms of what needs to be delivered. However, there is a strong psychological impact as Anton, Brian, and Shawn feel the need to work in stride for their respective parts to complete the story. They get together to lock in the scope of each other’s work before they go off on their own (we call this “Just-in-time Design Sessions”). When they check in this time, there is no need to go back and rework. Milestones are hit and all is well!
In summary, these 3 ideas are cornerstones that we rely on to bring a culture of Individuals and Interactions to life. There are many more ideas that are well-publicized, such as pair programming, daily stand-up management, and other collaboration tools (such as VersionOne, Rally, Jira, AgileZen, Trello) that are very helpful. We encourage you to look into those further as well.
As you can tell, we are passionate about focusing on Individuals and Interactions. We have gained a lot of experience in what works and what doesn’t in this area and we have seen some magnificent results when it all comes together.
For more information on our Agile development process, contact us.
Written by Eric Hanson, Senior Agile Practitioner