Wednesday, November 5, 2014

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.

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.

Follow me on Twitter @_AprilJefferon

Friday, October 24, 2014

Organizational Change with Transparency and Inclusion

The deputy CIO heard about my session on removing blame and requested that I facilitate the session with the management team. During the session I had the management team surface blame that existed in the organization. The responses were grouped and through dot voting we prioritized what should be focused on. They then got into small groups and worked on perfecting an idea for change on the highest-ranked topics. The session was well received. The group wanted more time to create action plans to implement the ideas, but we ran out of scheduled time and the deputy CIO wanted to share the results of the employee satisfaction survey.

The survey results showed that scores for one area was very high and another very low, most enjoyed their teams but management was failing at communication and many would leave for just a little more compensation. The next steps were for managers to share the results with their staff and find out more so action plans for improvement could be made. I subsequently asked how would this be done to foster safety? The deputy CIO then requested I partner with her to do this.

My recommendation was for me to facilitate workshops since I was not a part of leadership for each survey group. The workshops would exclude anyone who has a direct report but we would have a separate session for managers. The workshop would be designed to share what we learned from the surveys, get insight on what concerned employees, and identify what change employees wanted to see.

I advised the deputy CIO to open the workshops so employees understood that this initiative was supported from the top and that they were intimately involved and invested in this learning exercise to help bring about positive change that is of value to employees.

The deputy CIO summarized for each group what was learned including the positives and the concerns of employees; informed the groups the purpose of being there; and outlined the session goals and next steps.

I was introduced as the facilitator and the deputy CIO departed. I armed them each with a pad of sticky notes and a marker and let the group know that I would ask them "powerful questions" aimed to gather insights into where they are unsatisfied and what keeps them happy. They were asked:

  • What does better communication look like? Describe how that would look.
  • What do you need from your manager in order to feel supported?
  • What keeps you here?
  • What makes you want to leave?

I had the group "silently brainstorm" by writing one thought per sticky note and then collectively group the like thoughts for each question, name the group, and share the patterns.

Lastly I inquired "What would make things immediately better for you?" and  had them perform the same exercise. They got into self organizing groups for each improvement category then created a proposal for change which each group submitted before departing. It was also reiterated that their proposals for change will be reviewed for common themes among all workshops with leadership and we would let them know which ones were chosen in about a month.

After each workshop I immediately recorded the feedback for each question with the category the groups placed them in, as well as, the proposals for immediate change. The sticky notes were all shredded and recycled for anonymity.

I reviewed the individual feedback for each question and the proposals from each small group for each session with the deputy CIO. Upon this review and with the knowledge that each group desired more inclusion, it was decided to share all actionable proposals with participants from all workshops and to have them collectively vote on if a proposal should be implemented. Like proposals were then grouped with a small team that had the delegated authority to determine if a proposal was actionable. The proposals that were not actionable were set aside. Duplicate/similar proposals were combined.

I used the site Tricider to post each proposal as options to adopt. Votes were allowed to be cast with their real name or a pseudonym. Participants could vote for as many as they desired, post arguments for or against each proposal, and add additional proposals. Some proposals that were not actionable reappeared but we left them up there and the employees debated them by adding arguments. In the end there was a clear top four proposals which we would not disenfranchise voters by choosing something else but wanted to continue our quest for transparency and purposeful change by inclusion.

At the management forum I summarized what has been done and identified the top proposals which covered roles, salary, training, and communication. I then had them self-organize into committees to develop action plans for each proposal which everyone wanted to make sure employees were involved in its development. Subsequently, the deputy CIO communicated to all staff that action plans would be developed for the top four voted proposals and committees have been established for each of them which they could join if interested.

Up next is to communicate early and often as the action plans progress, as well as, to do all we can to make sure employees are involved in the development and execution of them.

The beginnings of a cultural shift has occurred in these five weeks. Management has become aware of the value of including employees in decisions which will increase transparency, alignment, trust, and communication. Employees are sharing that this process felt safe, has been therapeutic, and how they felt they have a voice. I believe most would characterize this as positive change thus far and it will be exciting to see if the culture of collaboration by partnering with management is adopted.

Follow me on Twitter @_AprilJefferon

See the posts below for more on transforming organizations and teams.

Friday, October 10, 2014

Transforming a Dysfunctional Team: Has it only been 6 weeks?

The DBA team was collocated with the Data Management Services (DMS) team to help build a closer relationship between the two teams and to encourage conversation, collaboration, and pairing so support work can be transitioned in time and without impacting customers.

After one-on-ones with each team member, I quickly realized that the relationships within the DBA team were more than strained and had been this way for a long time. So much so that it was an unhealthy work environment for team members, it impacted the progress on project work and support work; moreover, it affected the quality and speed of customers service.

I consulted upper management with my recommendation that the team not be ignored but instead we take time out to assess the team and its management to see if they could be salvaged with coaching. Since I was already currently busy coaching another team and did not have the bandwidth to coach another team full-time, they paired me with an internal senior manager, Steve. Steve had a history of successfully coaching dysfunctional teams. He collocated with the team and we spent the next week observing, asking questions, and taking notes with the team and management.

The culture of blame overwhelmed this team and management so much so that it was impeding progress of work, relationships were fragile, team ownership was non-existent, team members and management frequently quarreled, the team was not empowered, work was micromanaged, work was not prioritized, work was not visible, there were no WIP limits, a team member was not working at a sustainable pace, there was a lack of communication with team members, and new team members were not on-boarded nor was work transitioned.

In the end we recommended that the team return to a time where all the DBA's were equal to help nurture a team environment along with guidance from coaching and management. I would coach the team on playing to win and being solution-focused, aligning change with canvases, and agile practices to help improve their processes. Steve would pair with me coaching around team dynamics and he would maintain the delegated authority as a interim supervisor for priorities and HR issues.

To allow the team to start owning change, transition meetings for the work from DMS, that the DBAs will now manage, would include all of the DMS and DBA team members.

To set the stage for this transformation Steve and I paired on presenting my session on removing blame with the DBA team. It was difficult to discern how much they retained but we felt there was enough buy-in to share our intent to introduce the concept of a lean transformation canvas to the team and for me to begin developing the strategy canvas with the change agents.

The change agents included their interim manager Steve, other senior management, directors, and the deputy CIO. They collaboratively created, with my facilitation, a shared vision of the DBA team for the next six months with an improvement strategy canvas.

We then designed an interactive workshop with the DBA team to share this strategy canvas with them, get feedback from the canvas, create a team canvas for the next six months, and initiate process improvements through exercises focused on prioritization, pulling work, and visualizing work.

Due to resistance throughout the workshop, one day was spread across three days because of frequent attempts to derail conversation, reluctance to collaborate, and frequent participant disengagement. The team was hobbled by reservations about whether they would have a voice in REAL change and if progress could be made with team dynamics. Despite the struggles, Steve and I remained patient, took the time to answer each question and encouraged when someone tried to disengage.

We believe this contributed to the team walking away with a bit of curiosity, some working agreements, criteria to prioritize their work, a mechanism to visualize their work, a clear vision, and a commitment to try to foster a team environment by the end of the workshop.

For this to actually happen we reiterated that they must own this change and that we will be there to help facilitate conversations to initiate collaboration; however, the goal is for them to self-facilitate, to self-manage, to be solution focused, and to function as a healthy team without oversight.

The team had to commit to taking the time and putting forth the effort to foster these changes. Team dynamics, the culture of blame, dealing with imposed priorities, and process improvements were not going to change overnight. We were going to do this incrementally. Implementing facilitated retrospectives, stand-ups, backlog grooming and planning, and reviews were options the team agreed to learn to help get them there.

Retrospectives allowing the team to start a dialogue about what is working, what's not working, and how can they improve began yielding team agreements despite the persistent resistance of a team member to participate by contributing ideas.

Stand-ups helped the team to start having daily conversations and bring visibility to their work. Moreover it has grown to them pulling work, establishing pairs for work when needed, discussing priorities, bringing visibility to WIP for each team member, identifying items for escalation, focusing on project work, swarming on project work, and discussing process improvements in-time.

The state of the backlog was unknown and many tickets were open for over two years without action. There was no process on how work was pulled and requests got ignored. Planning has helped prioritize work, share ownership of scheduled/repeatable work and identify project stories ready to play next. Those stories came from the story map we built for a project that started a year ago that had not progressed. Grooming the backlog has closed outstanding tickets that were actually completed, estimated and identified tickets that were really projects that should be prioritized and approved, reassigned tickets to appropriate groups, removed 2/3 of a team member's WIP (45 assigned tickets), estimated open support tickets, and reduced the entire backlog by over half.

We have made many incremental changes that has led to small wins. These change experiments only move from a stage of learning once it is a part of the team's culture of how they work.

Still plaguing the team is team ownership of work is not yet accepted and understood, WIP is reduced but limits are not set, and not having a digital kanban board in place to visualize work in-time with a remote team member. There is also a lack of trust due to the history of blame and conflicts among team members which is demonstrated by the spirited confrontations that occur almost weekly.

The team has the potential to flourish and build a reputation for quality service and practices if they desire to move beyond the past, become solution focused, begin to trust one another, and truly commit to work together. The potential is there for this team to become one that other teams desire to emulate.

Follow me on Twitter @_AprilJefferon

For more on transformation canvases go to or checkout my post on Road to Team Transformation: My First 30 Days.

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.

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.

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

Workshop slides available on Slideshare:

Change Options

Sunday, June 8, 2014

The Roles and Tasks of a Scrum Master

May this list be used to guide and answer questions of what is the role of a scum master and what do they do but not seen as a definitive checklist.

Special thanks to Ron Quartel, Angela Harms, and Srinivasa Badrinarayanan for helping perfect this list.


  • Facilitate Daily Scrum
  • Facilitate Retrospectives
  • Facilitate Sprint Planning What
  • Facilitate Sprint Planning How 
  • Mediate conflicts 
  • Backlog creation and grooming


  • Alert for learning opportunities
  • Provide feedback to team members
  • Reinforce agile principles
  • Reinforce  agile values
  • Encourage collaboration
  • Foster team self-organization
  • Challenge team with adopting agile best practices
  • Challenge team with adopting technical practices
  • Be courageous to deliver bad news early 
  • Relay single coaching message to team 
  • Relay organizational message to team
  • Mentor team members one-on-one
  • Help team inspect and adapt definition of done
  • Help team inspect and adapt working agreements
  • Help team learn to self facilitate
  • Respond to managements needs

Servant Leader

  • Protect scrum team from distractions
  • Help remove impediments as needed but help team self-organize
  • Be contact person for all things
  • Radiate project status visually to management, stakeholders, and team
  • Ready to work as a team member to support the process
  • Help maintain tools (backlog, metrics, radiators etc.)

Team Member

  • Execute PO and DEV tasks when able
  • Help create product roadmap
  • Help groom backlog 
  • Help write user stories
  • Help slicing user stories
  • Help write acceptance criteria
  • Help prioritize backlog
  • Help task stories
  • Help write sprint goals
  • Help wherever possible
  • Collocate with team


  • Introduce best practices at relevant time
  • Exchange experiences with other process and technical coaches within the organization
  • Encourage agile technical practices within development team
  • Help further agile community within the organization
  • Provide learning opportunities to organization (talks, workshops, etc.)
  • Retire irrelevant practices as necessary


  • Learn everything agile continuously through conferences, user groups, blogs, books, etc.
  • Visit other agile adoptions
  • Be coachable by other coaches

Follow me on Twitter


Thursday, June 5, 2014

Smaller Stories as a Super Power

Is your team struggling with estimating stories because of unknowns? Has forecasts of work to be done in an iteration become guesswork? Do you find stories ready for review going back in progress because of an unclear definition of done? Are low priority features being developed?

All of these problems were persistent in a team I coached. Of course there were multiple options for incremental change but the option with the lowest investment but greatest impact was coaching around smaller stories to the team.

I observed and received feedback that challenging the product owners and development to adopt smaller stories for two iterations impacted planning, development, morale and trust positively.

The product owners changed how they prioritized work with small stories. Stories were pulled to play horizontally not by vertical chunks on the story map. They were able to discover that development could now play stories with the most value first and the business would now see a slice of the product across features.

The guesswork of estimating stories was removed with smaller stories because there were nominal or none unknowns. The acceptance criteria for the stories were minimal and meaningful conversations around it occurred that provided clear understanding to development on what it meant to be done.

Achieving the goal of defect free stories became attainable with small stories and technical practices. Confidence in code quality strengthened between development and the product owner with the ability to close multiple stories daily. The product owner was now able to see progress early and often.

Tracking the cycle time of the smaller stories was described as an adrenaline rush for development as they saw themselves going faster.

As a coach I surely had butterflies when the team decided to change their working agreements so that they would only play small stories; as well as, the team requesting more coaching on how to split stories.

Up next the team moving away from pointing stories and basing forecast on past performance of the number of stories delivered.

I am sold that small stories are a super power!

Connect with me on Twitter


Tuesday, June 3, 2014

It's Your Fault Retrospective

Retrospective of "It's Your Fault" session at the 2014 Self.Conference in Detroit

Immediately after our self.conference session "It's Your Fault", Gerry and I took a few moments to discuss the session feedback, what went well, what we could do better, and what we would toss out if we were to do this talk again.

Participants rating of the session was about 4.7 out of 5. Some things that helped make it successful that I would do over is . .
  • communicating learning objectives early in the session
  • capturing participants thoughts on key topics instead of feeding them all the answers
  • allowing the audience to apply techniques we introduced so they feel as if they can utilize them immediately
  • annotating the session Kanban stickies with approximate time we should get to that topic to help us monitor time
  • incorporating music as participants walked in, during activities, and leaving the session to set the tone for a relaxed an open atmosphere
  • soliciting participant feedback on how to improve with a rating of 1 needs work to 5 awesome with suggestions of improvements
  • investing the time to create an engaging slide deck
  • creating a blog article and posting before the session so participants can immediately access session details and additional information
But there was still room for improvement. The session was fast paced and jammed with a lot of information and exercises to keep within our 50 minute time box. Therefore the session felt a little bit rushed and if we had more time we would of loved to provide . . .
  • more time for the audience to get settled in
  • more examples of real experiences
  • little stronger connection/tie-in of the learning objectives with session activities
  • demonstration of the perfection game for participants before they tried it out
  • more time to answer audience questions
  • a recorded session for participants to refer back too (the slide deck received over 350 views in an hour after posting but I wonder how beneficial it was without the details recorded)
I look forward to the opportunity to do this session again.

Read the original blogpost on the session here:

Follow me on Twitter


Wednesday, May 28, 2014

It's Your Fault

Presented at the 2014 Self.Conference in Detroit on Friday May 30th with Gerry Kirk

Is your team pointing the finger at one another? Does development hold responsible the business and is the business accusing development? Is everyone too busy pointing the finger to address the problems? Discover how to recognize blame and move beyond it to foster a safe culture. Discover ways to change culture and leave with tools to help you initiate change immediately.


Blame Culture

To put it simply the impact of blame is that it can become viral, contaminating individuals and organization and quickly establishing a culture of blame. Blame may discourage feedback thus crippling learning. It discourages leadership which could stifle innovation and encourage a workforce of followers who do what they are told and agree with who wields the power. Focus is shifted to what does not matter instead of fixing what does. In the end what results is time, energy, and money invested in a temporary solution with no long term gain.

The Blame Mindset

When individuals embrace a blame mindset, they are focused on self preservation and focuses on the individual; therefore, what is considered is "WHO DID IT". The who did it thought process fosters fear that responsibility brings on the weight of sole accountability. It becomes difficult to listen if you are guarded and defensive and one can become hurt quickly. One can fear doing something to fix a problem despite having ideas for a solution.

The Responsible Mindset

The responsible, resolved mindset's concern resides with the system, organization, or customer and focuses on fixing what is wrong; therefore, what is considered is "HOW TO" resolve the issue. Team members listen and are emphatic because they understand that people make mistakes and that no value comes from blame. One trusts and accepts that there is shared ownership and that we fail and succeed together. It is understood that value is on the solution and with cooperation, collaboration and partnership it is attainable.

Empowered Environment

Characteristics of a low blame environment are an empowered workforce with a high morale, mutual trust and respect of team members, collaborative conversations, collaborative solutions, pairing accountability, quickly coming to agreements, and being solution focused where the norm is not "WHO DID IT but "HOW TO FIX IT".

Techniques to Explore

Changing mindsets and removing a blame culture can be done with a desire to evolve and curiosity. Exploring the following techniques will help you begin to change the culture of blame by fostering listening, understanding, allowing discovery and focusing on real solutions.

After trying these techniques for a while you may notice some changes. Keep with it and don't get discouraged if it fails the first time. Behaviors are learned, so rejoice in incremental improvements.

Remember Change Starts with You!

    1. Desire to Improve
    2. BE CURIOUS and listen
    3. Use what you learned here

        Follow us on Twitter