How to create and lead self-managing teams

Earlier blogs describe the foundational steps that enable agile data warehouse development. 

The next focus for setting yourself up for a best in class agile data warehouse environment is to develop and support self-managing teams.

Why are self-managing teams so important?

The word agile conveys a number of meanings. Its simple definition as an adjective is “quick and well-coordinated.”  From a project methodology perspective, agile is focused on consistently delivering high value to the customer quickly, and, at the same time, adapting to emerging situations and continuously improving performance.  Giving the development team the ability to self-manage their agile development approach, incorporating continuous improvement, leads to greater success.

Being agile is more of a philosophy than a process.  In order for agile to be successful, everyone on the team must buy into the philosophy – and be engaged.  One way to encourage engagement is through team ownership and accountability.  Gallup research shows that a team that is highly engaged has double the chance of job performance and success.  Engaged workers are more productive, profitable, loyal, and customer focused.  They are the teams that will be successful with agile development.

How do you create a self-managing team?

Self-managing teams are best formed with individuals who have different perspectives and backgrounds.  Of course, the goal is to hire “A-players.”  Each individual offers value to the team.  Through daily standups and code reviews, team members constantly collaborate with one another.  Productivity increases, and they become successful (or not) as a team.  As a leader, you will need to learn how to step back and trust that the team will make the appropriate decisions.  This is not an easy thing to do, but it can be very rewarding for you and your team in the long run.

This type of approach also encourages innovation.  In an agile approach, continuous improvement and innovation are important.  Every team is unique, and every data environment is unique.  As a result, the team should define what works for them, and not be afraid to experiment.  One thing I heard myself saying repeatedly the first time I was involved in leading agile development teams was:  BE AGILE WITH AGILE.

As my teams became comfortable with this approach, they flourished.  Every time I walked by the team area, individuals were collaborating – asking questions, reviewing approaches, and generally helping each other to develop the best possible solutions.  They started experimenting with different ways to approach their sprints. 

 Some examples of approaches they tried were:

•  4 people (the business architect, data architect, developer, and QA engineer) gathered in a war room and focused on one major effort with daily visits from the business stakeholder for 8 weeks.  This effort was dubbed the “super sprint”.
• For one solution, the data architect met daily with the business stakeholder, and together they developed a prototype that quickly became the solution, needing only QA and scheduling to finalize.
• The team started stressing about getting all of the user stories they committed to done in 2 week periods.  One team member expressed this by saying that it felt like they were in a vicious cycle that never ended.  During a retrospective, they decided to cut back on what they accepted in a sprint, and they added a “grab bag” of user stories that a developer could pull from if he finished his accepted user stories before the end of the sprint.  This ended up creating some fun competition – who was fast enough to be able to take from the “grab bag” in a sprint. 

These are just a few examples of what a self-managing team can come up with, if left to make decisions on their approach.  Some of their experiments failed, and they would revert to their previous approach, but most of them resulted in continuous improvements – one of the key benefits of an agile approach!

This ends the series on building the foundation for agile data warehouse development. You can find the previous posts in this series here.