Tuesday, July 29, 2014

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

Tuesday, July 22, 2014

Why I Stopped Facilitating Stand-Ups and Participated

Do you desire a more effective stand-up? Is your team struggling to find value in stand-up? Are stand-ups taking to long? Is the team addressing solely the scrum master, product owner, analyst, tech lead, manager, coach instead of the team? Are stand-ups becoming just status reports?

To address these behaviors with the team I decided to stop facilitating stand-ups and participate as a team member to initiate change. The stand-up is for the team to have a conversation. The team is comprised of development (programmers, testers, UX, etc.), a product owner and a scrum master. Light-bulb! I could participate. Behavior is learned and by me participation as a team member within the stand-up change could be initiated by my example. The team began to pickup on and emulate positive behaviors. Worried who facilitates? Actually the team began to self-facilitate with one another naturally. As a result, the team moved one step closer to being a self-managed team by learning to self-facilitate.
With a new teams I do seem to always have something to say such as updates on impediments and things the team may need to be aware of that could impact them, remaining transparent by sharing what I am working on to help visualize their work, sharing feedback, etc. 
As the team progresses the stand-up becomes more around how they are progressing towards the goal of the iteration, an opportunity to communicate struggles and wins, as well as, inform other team member of information they need to be aware of. I find that this comes with having small stories, small tasks, and  because the team is interacting with the board at frequent points throughout the day; therefore, awareness of what is done is already known
If you want to experiment participating instead of facilitating then remember to try not to be the one that goes first or last in stand-up to avoid coming across as authoritative. Use post stand-up for coaching opportunities if needed or discussions on how to improve stand-up which team members will begin to initiate.
I have run this experiment for improving stand-up on agile teams in different departments and organizations. This is not the only way I have went about improving stand-ups for teams with success but is just simply one way.
Follow me on Twitter @_AprilJefferon

Wednesday, July 16, 2014

Road to Team Transformation: My First 30 Days

My first week at University of Michigan Medical School with the Data Management Services team was spent observing, asking questions and taking notes. The management and the team had previously worked with multiple agile organizations and people but found their approach heavy handed or not a good fit for what they were doing. Through conversations with the team and management there appeared to be a lack of big picture communicated to the team, a culture of blame existed (with team members, customers, management, and consultants), work was not visible, change was dictated, agile practices that were successful failed by the wayside with the loss of a project manager, the team was not empowered or self-managed and as a result the team lacked ownership and was not delivering.

A lot was going on and what was initially set forth for my first 30 days here was only achievable if I were to ignore everything I learned, continue down the path that plagued the team before and desired to simply put on a superhero cape. They needed to go slow to go fast. To be successful and for the team to reach there full potential we needed to do something different. The answer was not in some methodology but through allowing management and the people doing the work to work together to figure it out. So I recommended we experiment with a lean change canvas and was given the go-ahead.

Why Transformation Canvas?
My experience with lean change canvases were with using it for discovery, transparency, visibility and alignment on the big picture and for guiding the conversations between organizational leadership and it's teams. However, I was going to run this experiment at solely a team level with management. The hypothesis of this experiment is that with management and the team creating a shared vision, goals and collaborating on change experiments that a self managed and empowered team who delivers quality that can be trusted in short increments would be molded.

To begin I commandeered a wall and created the shell of a LEAN change canvas in the open which included an improvement strategy canvas that would be populated by change agents (i.e. executives and management), a team canvas, change options to be proposed from both change agents and the team, a kanban for the change options/experiments that are in play, and an area to capture wins. Lastly, I posted a sign that stated that this was a transformation canvas and it is a "thingamajig to iteratively transform the Data Management Services teams collaboratively".

So instead of jumping in and populating it I talked about what it was, what we could learn from it, and how to engage with it to the team, management, and all those who asked. Spending time socializing this was the first step to being transparent, inclusive, and getting people bought in.

I then set the stage for change by giving an interactive talk on removing blame, becoming solution focused, and providing them with tools to do so.
This was a session I did at self-conference in April; however, I made a few modifications to allow the team to work on real issues and leave with actionable items and solutions.
In the session the team and management were able to bring to light behaviors within their corporate/team culture they would like to change and come up with ideas collectively to try to change it. The feedback was quite positive.
Feedback will also be something I solicit throughout this process. Gauging sessions on a scale of 1 to 5 where 1 needs work and 5 is awesome but if less than a 5 they need to state what would make it better.
Improvement Strategy Canvas
It was now time to build the strategy canvas for the next six months. This was done at the wall in the open with management. Powerful questions were asked and responses stayed away from solving solutions. Now visible to all was the vision of the change agents, what puzzles they felt needed to solve, what concerns them, and what success truly looks like to them. Possible change options were also identified. This was something we could now socialize to the team.

In a workshop the team reviewed the strategy canvas, discussed what stood out for them, what worried them and then built their own team canvas. The team canvas included what is supporting this change, what is working against this change, how the team can contribute to the vision of the strategy canvas, and what was the team's vision for the next six months, and their own change options.

Team Canvas
The team also decided to give Scrumban a try to help manage their workflow using agile and LEAN principles. I led an exercise with them that showed the benefits of a pull versus a push workflow using the LEAN dot game. They created a kanban for a pull workflow and rules on how they would use it. We have now established a cadence which will include iterations reviews and retrospectives. Reviews will give more visibility to their work with stakeholders and change agents. Retrospectives will include time for the team to refine the pull workflow and revisit the canvas.

The canvas will change with further conversations and input of the team as they evolve over the next six months. The team canvas and the response to the strategy canvas has already been socialized to the change agents. Stories are being pulled to play that will give the team more insight into their role in the big picture of the organization. We are currently working to transition all scheduled work to the support team so they can focus on project work. Up next we will build a story map for a project roadmap/plan, build a backlog of similar sized stories for the next few iterations and start using that kanban just built to move to a pull workflow.

Feedback Driven Change Process

Excitement is brewing about the transformation canvas. I have been approached by many to walk them through what we are doing. There is some desire for me to introduce this to other teams and others see promise at an organizational level.

Follow me on Twitter @_AprilJefferon

To learn more about lean change management visit leanchange.org.

Workshop slides available on Slideshare: http://www.slideshare.net/AprilJefferson/dms-workshop

Change Options
Experiments
Wins