Slow Down to Speed Up – Its All About Delivery

I have given the following presentation at Cerner’s DevCon in 2014, at KCDC 2015 and most recently at the monthly meeting of KCQAA.

Youtube (Cerner DevCon):

SlideShare (KCDC 2015):

It has always been well received and is meant to help teams learn to focus on the big picture of why we develop software.  There might be some driving tips included for those that wonder what they should do when faced with merging lanes or why we have roundabouts and the double cross-over diamond exchanges.

The Value of a Coach – Agile Lessons from the World of Sports

I have spent a significant portion of my life devoted to the sport of ice hockey.

I began skating at 2, playing competitively at age 4 and continued through college.   While winding down my playing career, I picked up coaching and have spent more than 20 years teaching the game at all levels.  Prior to joining Cerner, I was also fortunate to work professionally for 3 years running the Ice Hockey tournament for the 2002 Winter Olympics managing the computer and results systems and currently volunteer with the Missouri Mavericks in a related capacity.

While watching the Sochi Olympics, I was reminded again at the similarities in coaching Agile teams and coaching sporting teams.

team canada

As a player and coach, I have been fortunate to regularly be a part of very successful teams.  I learned from my coaches and then again as a coach that winning comes from taking individual talent and putting it within a team structure that amplifies the talent of the entire team.

Each team has a unique set of personalities and skill sets.  A good coach has to know how to assess the team members and then determine how to help them come together to “win the game” on a consistent basis. Sometimes this requires teaching new skills, breaking bad habits or even deemphasizing star players to make the team better.

Teaching a new skill

At every level in sports, coaches need to teach players new skills in order for the individual and the team to be successful.  When teaching a new skill, you cannot expect that the players will be able to do it right the first time.  In order to ensure success, a coach must incrementally increase the complexity of the task until mastery is attained.

A progression that is typically used by trained coaches is to practice a new skill at 50% speed until the skill is understood, increase to 75% speed and then progress to 100% speed. Once an athlete can perform the task at 100% speed, the complexity of the task is increased with various level of defensive pressure from low to high.  I refer to this as the “No, Low, Moderate, High Pressure” training model.

defensive pressure

The athlete must go through all levels of progression to adequately learn the skill.  It isn’t mastered until it is repeated at top speed, under high defensive pressure and becomes a natural part of the athlete’s repertoire.

Using American Football as an example, a wide receiver and quarterback will run pass routes at the 50/75/100% speed in practice and then the coaches will start introducing defensive pressure in varying degrees to both the quarterback and the wide receiver. They will then place the route into a series of plays that could be used in a game situation and practice those plays in the no/low/moderate/high pressure model until it is ready to be used in a game.

Breaking Bad Habits

Most athletes have various natural abilities and learn to be successful developing and leveraging their talents.  Great athletes spend time focusing not on their strengths, but on their most glaring weaknesses to avoid developing bad habits or creating tendencies.  In most cases, they have to unlearn bad habits to move effectively to the next level of competition.

As a 2-year old, my mother taught me to skate by holding M&Ms in her hand and having me skate to her.  I found out that I could just put my left foot forward and propel myself with my right leg and get to the M&Ms quickly.  While that achieved the goal of getting to the M&Ms, it caused some problems when I started playing competitive hockey.  I could perform well as long as I primarily used my right foot, but struggled with my left.  It wasn’t until I was 13 that I had a coach that taught me to do everything equally well with either foot.  It opened up a whole new realm of skills and opportunities.  I would never have played in college if that coach hadn’t forced me to work on breaking my bad habits.

Michael Jordan would practice being able to be able to do everything equally well moving to his left or his right.  As he improved, he elevated his game to make sure that he would go to either side 50% of the time.  He would also strive to make sure that he varied his shot selection type (fade away, pull up jumper or drive to the basket) so that the players guarding him wouldn’t have a tendency to use against him.  As a defender, he would study the tendencies in his opponent and force them into situations where they had to rely on their weakest skill percentage wise to beat him.


Tim Tebow is a classic example of a player who had the skills as a quarterback to win in a certain system and be very successful at the college level.  He won the Heisman trophy in 2007 as the top player in college football and led his team to an NCAA National Championship in 2008.  Because of his larger than average size for a quarterback, his style was to run and mix in a pass as needed.  He was so successful as a runner that he never learned to be an elite passer.  Despite his talent, he has been unable to break his bad habits in order to be successful in the NFL.  For all the Florida and Tebow fans out there before I get a flurry of hate mail, he is still a great human being and a legend at Florida, just not an NFL quarterback.


Deemphasizing the Individual

As a coach, the least successful team that I ever had record-wise ironically had one of the most talented individual players.  The player however refused to put their personal style aside to make the team better. This often resulted in the star trying to skate through the entire other team with the puck to score a goal.  The other players would often stop skating and watch to see the result.  They might as well have been on the bench with me.

At the beginning of the season, we won our first several games as most teams were still playing as individuals and our star was better than any of their individuals.  As the season progressed, opposing teams learned to just focus on the one player and we became very easy to defend and went on a month long losing streak.  I knew the problem, but the team was slow to change as they had early success and thought that was the only way to win.  They didn’t realize that the problem had changed.

The breakthrough moment came when the star player missed a game due to illness. The team had to come together and played significantly better, upsetting the top team in the league.

Once the star realized that the team could succeed without them and the team realized they could win without the star, the attitude on the team changed.  They started playing together and trusting that that the other players would do their job to help the team win.

I have always found that the more complex and challenging the competition, the more important team behavior becomes.  For many professional athletes, they dominate their youth leagues and put up significant individual statistics.  When they hit college, they still periodically dominate, but learn that they have to do it within a team system and the individual statistics are no longer as gaudy. By the time they hit the pros, all the other players are as talented as they are and the only way victories come is by playing as a team.  They can still make great plays as an individual, but the team system is what enables their ability to shine.

Coach John Wooden and his dominant UCLA basketball teams are a terrific case study of how to get the best out of talented individuals within a team system.  His teams won 10 NCAA National Championships in a 12 year period, including 7 in a row.  They went a record 88 games at one point without a loss.

wooden quote

Interestingly, people tend to revert to individual behaviors when under high pressure/stress which is why some teams seem to fold under pressure in the sporting world.  They stop working within the system that brought them success.

Many wonder what happened to the Men’s’ Ice Hockey Team USA in the Sochi Olympics and why they didn’t win a medal.  In breaking down both of their losses, the answer is relatively simple, when they played the better opponents (Canada and Finland) who had their same skill level, they stopped playing within their system and lost to the teams that used their skill within their system.  Read Patrick Kane’s comments here and notice how many times he uses “I”.  I have watched him quite a bit and his play in the last two games of the Olympics was very much as an individual and not at all how he normally plays with the Chicago Blackhawks.  His Chicago Blackhawks linemate (Jonathan Toews) was on Team Canada and scored the game winning goal in the Gold Medal game as a result of playing within the system.

friendly hockey players

Agile Application

When using metaphors, I tend to not directly call out the correlations as each individual finds things that apply to them at different moments.  I do want to make sure however that a few key points are recognized.

As I have observed hundreds of Agile teams and their results, I frequently see one of these three behaviors that is impeding the team from achieving their potential.

Often a change is introduced and because of the change J-curve, it is rejected before it can produce the desired results.  Many teams adapt before they adopt and as a result, they end up getting cargo cult results or end up doing a bunch of mini-waterfalls.  They have to slow things down to understand how to do it before they can do it under full pressure at full speed.

Other times, assignments are taken by unskilled workers but the timelines to go through the learning curve are not incorporated which invariably leads to defect-riddled code and late delivery.

I have observed teams and individuals reverting to behaviors that they learned in an individual coding model like most college projects and try and apply it in complex, enterprise models. It is a little like thinking that your backyard soccer/football prowess will translate to success in the English Premier League.  As the complexity increases, the skills and methods have to change.  Global variables work really well in a hack prototype, but are not a real good idea in an enterprise setting.

Agile teams work.  A team of individuals trying to work as an Agile team does not.  Each member needs to have an attitude of it being ”more about we than me.”  When teams have individually assigned user stories, it is usually a strong indicator that they are a team in name only.  When an architect is the one who assigns the work or continually directs the other developers what to do, an individual may be overemphasized at the expense of the team.

In your next retrospective, I challenge each team to evaluate if they have some of these challenges and then make a plan to do something about it.   Reach out to an internal or external coach and see how they can help your team overcome these obstacles and perform at the next level.

Developing a Cross Functional Team

Agile methodologies often talk about developing a cross functional team but not much is said about how to do it.  In training classes, it is often said that on an agile team, “your role defines how you best contribute to the team, not how you will contribute.”  The project and the challenges the team is facing will determine what work actually needs to be performed to keep the project on track and make sure that the team builds trust by making and meeting commitments.

I am a proponent of looking at other industries to see what they do to enable a flexible workforce to deal with variable demand and see how it can be applied in development.

At stores like Wal-Mart or Target, they cross train a large portion of the work floor staff to be able to run the cash registers if they need to open additional registers based on queue lengths.  They use season trend models to determine how many of each worker type to schedule, but the cross-training allows them to account for the uneven flow of customers that can occur without degrading the overall customer experience.  It does mean that something that is less time critical like restocking shelves is subverted in the process for the more time critical process of completing the checkout and payment process.  It doesn’t mean that restocking shelves is not important, but more that a bottleneck is currently occurring at the check-out lines and therefore the store team chooses to reduce the effort temporarily in other areas to help resolve the bottleneck.  Once the flow issue is resolved (too long of lines in this case) the workers return to their original and primary job function.

In manufacturing, the cost of a bottleneck is even more pronounced.  Since most manufacturing follows a Lean model where inventories are reduced or eliminated, a bottleneck in the process can end up shutting down the entire production line after a relatively short delay within the system.  For this reason, they develop what are called “T resources” in terms of skill sets.  A “T resource” has one area of specific, deep expertise but is cross trained in the job functions for the stations immediately prior and immediately after them in the production line.  While they are not as skilled in those functions, they are capable to complete them at the required levels of quality.  The deficiency is more in speed to perform the task.  This enables a bottleneck in the system to get temporary assistance from other areas in the production line to ensure that the whole line doesn’t grind to a halt.

t resource

Stores and manufacturing are one thing where much of the work is manual in nature, but is it possible to create “T resources” on a team of knowledge workers where highly specialized skill sets are often needed?

The answer is the standard, “it depends…”

At Cerner the product owner roles tend to be trained clinicians or have deep business knowledge in a specialized area like Finance or Hospital Operations.  In some cases the testing experts are also clinical professionals which enables them to effectively understand and test the various workflows.  While developers and architects can learn their clinical domains, it would not be at the depth of the trained clinicians.  The reverse is also true.  Clinicians or testers can learn to code.  In all of these cases however, just because we can doesn’t mean we should.

I would like to propose a couple of options for teams to develop “T resources” when faced with the challenges like those that Cerner’s model presents.

The first is to model the process flow or value stream and identify how work flows through the system similar to a manufacturing line.  Once the value stream is defined, the team can identify where each member is an expert and the areas where they can develop some cross training to help if bottlenecks arise.  It may end up not being the process area immediately preceding or succeeding like is done in manufacturing.  Once the areas are identified, developing that cross functional expertise then becomes a priority to ensure consistent flow in the system.

Parameters should be set as to what portions of the specialist role cross trained members can perform.  For example, can a testing expert or architect help create functional requirements that are typically the domain of the requirements specialist?  Are there limits to what requirements they can help with?

Utilizing techniques like pairing the associate to be cross trained with an expert will enable the quality expectations (aka definition of done for the Kanban column) to be consistently met while training the associate new to the task.  This also creates an individual learning environment that web based training (WBTs) can never match when it comes to individual competence.

One word of caution here is that if an upstream specialist is unable to help with the area where the bottleneck is occurring, they should never exceed their work in process (WIP) limits to start on something else as that will merely increase the pressure on the bottleneck and detrimentally impact the overall speed of the flow through the system.  They need to find something else to do that contributes value to the team without increasing the work in the system.

The second is to look at the development stack for the team and understand where the team has created specialists within the same role.  A team or set of teams may have UI experts fluent in a specific language while the services stack or database tier will likely leverage different technologies.  The team can then to identify where development specialists can cross over the layers in the stack. Much of the variability in software is that each project will require a different architectural solution.  In some cases, the project may have heavy UI and limited services while other projects may exclusively require services work.  If we are to keep the team together that will enable the greatest team productivity, cross training will be needed across the layers in the architectural stack.  There will be limits to the depth each developer has in each area and we want the deep experts to typically work in their area of expertise, but due to the variability in the project work, that will not always be possible.

Understand that while cross training will help individuals contribute in areas outside of their own expertise they will not be as productive (speed wise) as the deep expert. A good rule of thumb is to plan for a 50% difference between the expert and the cross-trained associate.

Because of this difference in productivity, the temptation is to form teams around the different layers in the stack.  When this occurs, it prevents the development in thin vertical slices.  This leads to disconnected prioritization and multiple stories to accomplish the true user story.

release timeframe legend release timeframe

The outcome is increased waiting time in the overall process resulting in delayed or incomplete deliveries.

The other temptation is to form teams for each project based on the needs of the project.  This will actually cause even slower development cycles than the layered model as the team will have to go through the storming, forming, norming, performing sequence and actually have lower productivity than a standard waterfall model for several iterations.  This is sometime referred to as the “J-Curve” when introducing change.

j curve

It will usually take 6-12 weeks for an Agile team to become equal to a waterfall team in productivity.  They will quickly outperform the waterfall team after that point, but if they are broken up again, they have to start all over again.  To achieve hyper productivity, a team has to stay together for a sustained period of time so they learn how to work together and understand each individual’s specific talents.  Only then can the team consistently and effectively self-organize to address the projects the business requires.

To understand how to potentially tackle this situation, Spotify can be used as a case study that you can read about here. The creation of guilds in particular allows for architectural excellence at each layer in the stack without sacrificing a team that can work in thin, vertical slices.

spotify teams

So, why this push for “T resources” in software development?  If an associate is really good at what they do in a specific area, why would I ever want them to stop doing it so they can work on something where they are not as skilled?

From a Lean perspective, all work that is being done but has not been delivered is waste. The client cannot use it until it is fully delivered, so we want to reduce the time that the development is in a wasteful state.  Think of this as you can’t buy half a car at the dealership, so until the car is fully built, it is waste.  Manufacturing companies count these unfinished goods or WIP as a liability on the balance sheet, thus negatively impacting their profitability.  This means that a Lean organization focuses on how quickly things flow through the system and seek to resolve areas where flow gets interrupted as quickly as possible.

This is a challenging concept for any specialist as they want to spend their time focused exclusively in their area of expertise.  What they are really good at will eventually be needed, so shouldn’t they just keep doing it?

The answer is a resounding “No!”  This would be equivalent to trying to add another car on an already congested road.  It will just slow everyone down that much more.  Pretty soon the entire road will grind to a halt. We will start seeing road rage within our process and from the clients.

The other impact will be the potential depreciation factor that can set in on the WIP which can result in unnecessary rework prior to client delivery.  This is why push models fail to meet the same client satisfaction of a pull model system.

The reality of software development is that the client and the team are often better served that if the specialist stops doing what they do best and work elsewhere to help the team deliver when flow problems occur.  If you want to travel at freeway speeds in delivering, you have to abide by freeway principles.  To quote Scotty from Star Trek,  “you cannot change the laws of physics…”