First Iteration with Scrumban and Pull Workflow

We planned an iteration dedicated to learning for the DMS team. The goals were to begin working through the thinnest slice of the business data warehouse project to gain process and technical experience from touching all areas of the project, use the pull workflow the team designed and lastly to have no or minimal support work, which we are now considering support work to be any task that is not for the business data warehouse project.

Acquiring a product owner proxy has helped the work get split to smaller stories, prioritize work and move from working on silo-ed work-streams for each individual team member to the team working through a horizontal slice of the project using all their new tools and technology together.

Board at Beginning of Iteration

The iteration focused on technical work related to data discovery but is setting the foundation to begin working on stories for data consumption. The team planned 13 project tasks across two stories and 7 support tasks. By the end of the week 14 project tasks were done, 1 story done and 14 support tasks completed and the backlog of tasks grew by six for the story in progress. The team focused on prioritizing new support work coming in and pushed 10 support tasks to the next few weeks.

The stand-up conversation had also shifted to what is impeding us, what is the flow like, and how can we improve. Stand-up is more often under fifteen minutes and post stand-up is non-existent most days.

A major change the team implemented is to swarm and pair on project tasks and pair on support tasks being transitioned to the Database Services team. I also introduced the team to huddling anytime a blocker arises.

Below is the day by day run down.

Day 1: The team began pairing on support work, swarming on project tasks, and huddling when blocked was introduced. At the end of the day 10 project tasks and 3 support tasks were completed and 1 task was blocked.   

Day 2: The team continued pairing on support work, they did not swarm or pair on project work until they worked together to confirm the blocker from the day before was fixed, and they huddled to remove another blocker a team member was working on solo. By the end of the day 2 blockers were resolved, 3 support tasks were completed and 4 support tasks were in progress.   

Day 3: The goals for the team was to continue pairing on support work, pair on project tasks, and swarm on project tasks with whoever was available; however, no swarming occurred, and for the second day no project tasks moved. However, 5 support tasks were completed and the team realized they need to rework a data model and create new tasks related to the change.   

Day 4: The team was able to push additional support tasks to next week or beyond, pairing on support continued, pairing on project tasks occurred and 3 more support tasks were completed and 4 project tasks were done.   

Day 5: We had an iteration review, retrospective and planning for the next iteration.

Board at End of Iteration

So what did we learn?  We learned support tasks are greatly impacting the teams availability to work on project work. They spent a little over half the iteration on support. The good thing from this is that support work was now more visible with using a physical board to management. Previously it was not known how much the DMS team was inundated with support work and when they were blocked despite work being represented by tickets in Jira. This in part was caused by Jira tickets not having a consistent size. A ticket could represent 1 hour or it could represent 1 month!  Simply beginning to transition support work to the Database Services team by pairing, was also a win this iteration.

Many in the office stopped by to look at what was going on with the team, by engaging with the board throughout the day or grabbing me to talk about our new pull workflow and the board. We were now gaining visibility into the support work as well as our project work!

It is also worth noting that when the team was not swarming or pairing, project tasks were not being worked on nor was traction being made on project work. During the retrospective, swarming and pairing were identified as something the team felt was good about the iteration and made evident by a new working agreement being adopted in their retrospective to swarm on all project work while they are in this learning phase.

Experiments

During the retrospective, we also took time to take a closer look at the pull workflow and the team decided to not make any changes at this time. We then reviewed the transformation canvas and discussed how organically the experiments are being pulled into play and they felt the documented wins were valid and a great representation of the incremental progress they were making as a team.

Wins

There is some concern that not much was accomplished this first week which may be representative that it is difficult for the individual to recognize learning as an accomplishment right now. However, the team seems to understand the value of working through a slice and how it is helping them reach the goal of delivering a potentially shippable increment.

Follow me on Twitter @_AprilJefferon