Putting the Practices to Work
Prior to beginning training, we reorganized the workspace. Instead of sitting in silo-functional groups, teams now set up in two areas. Each team is a cross-functional group consisting of business analysts, developers, testers, and product managers who represent the customer voice.
The group agreed on a different way of working and this saw the role of the product manager heavily involved in product development. Incorporation of product managers into the agile teams is significant, as they previously were part of a different group working under the marketing department. Co-located with the team, they can answer questions and provide close-to-immediate feedback. The product managers spend about half of their time with the teams and the other half in the field where they work on understanding customers’ needs and training roadshows, which is when the product manager goes out into the community and trains our customers on the products.
Each team has an iteration manager who provides leadership and guidance, facilitates workshops, tracks progress, and leads the daily standup. The iteration manager is responsible for removing obstacles, like a lack of availability of subject matter experts, and providing resources such as new hardware, software, or other tools that assist in development)to help the teams be successful.
Our teams typically work in two-week iterations. They don’t begin and end on Fridays or Mondays, because it’s more likely that someone will be away from the office during these days. One team starts on Tuesday, two teams start on Wednesday, and one team starts on Thursdays. Since the teams are independent, it’s fine that the teams start their iterations on different days.
One problem that teams identified fairly early was that they are required to provide support for the existing products while working on new projects. Teams use story cards to track work through the iterations, and velocity charts in the team spaces show progress. The mix of support for existing and new projects resulted in their being unable to meet their planned velocity during an iteration. But, this support work won’t go away.
Figure 2: Team Awesome’s Storywall
So, the team reorganized the story wall into project work and support work, with a horizontal line dividing the two sections. Once the team receives support tasks, they add them to the backlog and prioritize them along with project work during the next iteration planning meeting. There is no maintenance team, as our products have been developed in many different technologies and languages, and it’s unrealistic to expect a small team to have this diversity of skill sets.
The velocity estimates now take into account the average time spent on “below-the-line” work and are back on track in relation to actual velocity delivered. Because the story wall shows all the work that is not project related, the business customers understand why the delivery rate has slowed down. This simple change reduced tension and increased communication both within and outside of the teams.
The developers are incrementally moving towards continuous integration by building more unit tests and integrating their code at multiple time during the day. They use test-driven development for new work and some pair-programming. They have not quite reached the point of continuous build, but their understanding of the tools and techniques improves with experience.
Testing is integrated into the iteration process through identifying tests during story elaboration. This includes using behavior-driven development structures to present detailed requirements in the form of customer tests. Currently, most testing is manual, but we are building more and more automated tests.