Getting it Done with a Technical Work Map and Coaching
The product application manager on the DBA team disclosed that there was an outage where a data loss occurred over 3 year ago which initiated a project to upgrade the hardware for this database's server. The project, which was expected to take 3 to 4 months, had stalled and been in-progress for 2 years. The status of the project was unknown, including what work had been done. It was a high priority for this migration to happen because another outage could happen at anytime and it was predicted that the data loss would be more significant.
The interim manager agreed this project was top priority for the DBA team and I was ready to help get a project plan in place with a "User Story Map" to get it moving along. The exercise was straightforward enough and the group seemed to understand when I walked them through how we would build it despite their not participating in previous story mapping sessions.
However trying to build a story map with a DBA, product application manager, data analyst, software developer and no product owner yielded what I will refer to as a technical work map. Which for the project at hand made sense and they felt what developed was useful. Basically in the technical work map user activities were developer activities and user stories were developer stories or tasks. Colored dots were placed on the stories to show responsibility and coordination for the DBA's, PAM, data analysts and software development. Marks would be placed in the dots to identify if a story was in progress, done, or cancelled.
Project progress was not being made initially despite the map being completed. Planning was occurring each iteration for project, scheduled, and unscheduled work and direction was given to focus on project work. The team had a physical kanban to visualize their work and had a scheduled daily touch point to discuss progress and impediments. A migration date was set by the team that was more than comfortable for all. However, the team did not adhere with their own agreement on the priority of work. The cycle time for project stories and tasks estimated at hours and minutes took days. They were moving at a slow crawl as the the team struggled with jointly owning and contributing to the work, pulling work not pushing work, dealing with imposed priorities, and mitigating through team storming.
Intervention was needed to get them past their struggles and to see that this project wouldn't get done unless they did it together. The date the team set for migration which was originally forecast to be reached weeks ahead of the migration date was at risk and it appeared that that the entire project was at a standstill.
For our retrospective we revisited the transformation canvas, the vision of the change agents, the team's vision, and what the team committed to do. We had a candid conversation about project work being a reality for the team that is not going away and how it is simply ticket work that is too large for an individual to complete. In order to deliver in a reasonable amount of time as a collective they would need to swarm on it. Expectations were reiterated and discussions occurred about how as individuals they would be looked at by how they contribute to the team and that individuals don't fail or succeed, the team does.
The team finished the project on-time for the migration, while working at a sustainable pace. The migration was successful and cut cycle time in half for jobs.
This project was able to be delivered in weeks by the team adopting agile practices, becoming solution focused, and collaborating.
The interim manager agreed this project was top priority for the DBA team and I was ready to help get a project plan in place with a "User Story Map" to get it moving along. The exercise was straightforward enough and the group seemed to understand when I walked them through how we would build it despite their not participating in previous story mapping sessions.
However trying to build a story map with a DBA, product application manager, data analyst, software developer and no product owner yielded what I will refer to as a technical work map. Which for the project at hand made sense and they felt what developed was useful. Basically in the technical work map user activities were developer activities and user stories were developer stories or tasks. Colored dots were placed on the stories to show responsibility and coordination for the DBA's, PAM, data analysts and software development. Marks would be placed in the dots to identify if a story was in progress, done, or cancelled.
Project progress was not being made initially despite the map being completed. Planning was occurring each iteration for project, scheduled, and unscheduled work and direction was given to focus on project work. The team had a physical kanban to visualize their work and had a scheduled daily touch point to discuss progress and impediments. A migration date was set by the team that was more than comfortable for all. However, the team did not adhere with their own agreement on the priority of work. The cycle time for project stories and tasks estimated at hours and minutes took days. They were moving at a slow crawl as the the team struggled with jointly owning and contributing to the work, pulling work not pushing work, dealing with imposed priorities, and mitigating through team storming.
Intervention was needed to get them past their struggles and to see that this project wouldn't get done unless they did it together. The date the team set for migration which was originally forecast to be reached weeks ahead of the migration date was at risk and it appeared that that the entire project was at a standstill.
For our retrospective we revisited the transformation canvas, the vision of the change agents, the team's vision, and what the team committed to do. We had a candid conversation about project work being a reality for the team that is not going away and how it is simply ticket work that is too large for an individual to complete. In order to deliver in a reasonable amount of time as a collective they would need to swarm on it. Expectations were reiterated and discussions occurred about how as individuals they would be looked at by how they contribute to the team and that individuals don't fail or succeed, the team does.
We were delighted to see them immediately start collaborating. The team re-factored the technical work map together and was able to drop work not required and identify work that needed to happen. They also developed a map for the migration weekend. The team began pulling stories through their designed workflow and the cycle time of stories went from weeks and days to multiple stories closing each day. The team started swarming regularly and team members, even those with the most difficult history in their working relationships, paired. Cycle time boosted as they continued re-factoring, swarming, pairing, learning to say no, and pulling work throughout the weeks leading to the scheduled migration. Moreover, team dynamics had improved, one on one coaching was not happening, we were not needed to mediate conflicts, and team members began self-facilitating conversations.
The team finished the project on-time for the migration, while working at a sustainable pace. The migration was successful and cut cycle time in half for jobs.
This project was able to be delivered in weeks by the team adopting agile practices, becoming solution focused, and collaborating.
Well done, April!
ReplyDelete