The first task that must be accomplished in the Agile methodology is to come up with a list of product features that must be delivered to customers. In Agile, this list is called a product backlog, thus, once the DTCC Learning staff completed Agile training, each of the three DTCC Learning domains set out to accomplish this task.
Creating a product backlog is typically accomplished by meeting with the product owner or customers, having them articulate their vision for the product, translating that vision into features and then prioritizing the features. This, of course, is how it is articulated in the world of software development, so while the approach sounds simple and straightforward, accomplishing it in a training and development space proved a little more difficult. Each of the three DTCCL learning domains found that they faced a common set of challenges when they attempted to create their first product backlog. The challenges were as follows:
- How do we translate a language and approach that was meant for software development into something that makes sense for learning solution development?
- What do we do with work that is already in progress?
- How do we handle work that is not specific to any one line of business?
- How do we engage all of the numerous product owners that we need to support?
- What do we do if a specific skill set is missing from one of the development teams?
Old habits proved hard to break, and the team members (at least initially) continued to look to their managers to provide the answers. To the credit of the leadership team, my direct reports continued to challenge each of their teams to come up with plausible solutions to these challenges. My role was to ensure the organization that I did not expect that things would be perfect overnight, and that it was OK to make mistakes. I walked the floor more frequently and encouraged individuals at every opportunity. I began sending weekly video podcasts that highlighted the good things that were happening in the organization. My directs constantly reintegrated that the Agile approach that we adopted here at DTCC must be unique and specific to the challenges that we faced here. Ultimately, each of the teams was able to come up with solutions to the common challenges that they face.
1. How do we translate language and approaches that were meant for software development into something that makes sense for learning solution development?
As the teams became more familiar with Agile, translation became a non-issue. They simple started to substitute language that made sense in a learning development environment for the words that were more appropriate in software development.
2. What do we do with work that is already in progress?
The three learning domains were well positioned to address work already in progress. Since the teams were largely comprised of individuals that previously supported the lines of business that the domain was aligned with, much of the “in progress work” immediately moved under the responsibility of the corresponding domain. The team members agreed that when there were exceptions, the individuals who had started the work would see those projects through to completion.
3. How do we handle work that is not specific to any one line of business?
Team members agreed that as cross functional requests came into the organizational backlog, the team with the greatest capacity at the time would be responsible.
4. How do we engage all of the numerous product owners that we need to support?
There was no universal approach for this challenge. Each learning domain adopted an approach that worked best for that domain and the lines of businesses that the domain supported. One learning domain set up a series of consecutive meetings on one day of the week. Another domain set up meetings with representatives from groups of businesses.
5. What do we do if a specific skill set is missing from one of the development teams?
The team members from each of the domains agreed to provide cross training where there was a skill deficit as well as lending other domains expertise as required.
Within two weeks, each of the learning domains had met with their customers, established a prioritized product backlog, established operating procedures and was prepared to begin their first “sprint.” What made this effort different and rewarding is that all of these activities was driven and accomplished by the team, not the manager. If no other positive were to happen as a result of our adaptation of Agile, the fact that the teams and individuals were beginning to feel empowered was making this decision pay off.
In my next blog, I’ll discuss what happened when the teams began their first sprint.
