How to Help Your Team Overcome Failure.

Software development is a tricky business.  The nature of the work is changing so rapidly that what worked eighteen months ago could fail today.  The mercurial world of software development is the reason why the agile reformation got started.  We do an outstanding job teaching the basics of agile to others.  Unfortunately, we take these essential skills and rub up against the reality of working in a contemporary business environment.  It is a recipe for disillusion and frustration.  As coaches and scrum masters, we need to do a better job helping people who join the agile reformation navigate the hills and valleys of the business's fallen world.  

I say failure is the ultimate teaching tool.  Each day, a business person confronts failure.  It humbles a person.  It pushes them forward to do better.  Finally, it educates in a way no success can.  We need a way to look at our failures dispassionately to create future success.  When the team fails, the best place to address it is the retrospective.  Create a safe and secure environment for people to discuss the challenge.  It also helps to remind everyone about the retrospective prime directive created by Norm Kerth,

"Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources, available and the situation at hand."

Talk frankly about what happened and how the team could have done things differently.  It is crucial to develop an action plan to address the things that the team can control. 

The next thing a team should do is ask if they are facing a constraint with the organ
ization.  For instance, if network services must schedule a time to promote code to production servers.  It is a classic constraint according to Eliyahu M. Goldratt's book, "The Goal." Understanding the condition of the network services team, the developers can devise ways to exploit the constraint and find ways to mitigate it later.  The process of exposing and mitigating constraints will empower the team and give them a sense of control.  

Finally, please write down your experiences and review them.  A coach or scrum master should keep a daily log of what they do.  It should feature the high points of each day and the low points.  Look it over each week.  It also serves as a contemporaneous memo you can provide your leadership to remain updated on your progress.  Over time, looking over these reports provides an oral history of the project, and you can apply the theory of constraints to help challenges you see recurring.  

Business is a fallen world.  As a person, you face failure and disappointment regularly.  Your team is going to disappoint you.  We do not say this enough in the agile world.  What defines a team that succeeds over one which suffers, in the long run, is the ability to recognize and overcome previous adversity. To deal with these disappointments, use the power of the retrospective.  Have the team apply the theory of constraints.  Finally, keep a journal of contemporary events to track progress and learning.  

Frustration and disillusionment are natural by-products of leading change.  Do not let that stop you.  The fallen world of business can get better, but only if coaches and scrum masters learn to face challenges with an approach that helps them improve. 

Until next time.

 

Five simple steps.

Constraints matter.

I have been involved with Agile for nine years.  One of the greatest discoveries of my agile journey is the realization that I am learning new things and continuously improving the way I conduct my servant leadership.  I was encouraged to read Eliyahu M. Goldratt’s, “The Goal,” and it exposed me to the theory of constraints.  Now that I have finished the book I have a few thoughts on the subject.

I have written about the theory of constraints in the past.  The main gist of the book is to identify bottleneck or limitations in an organization.  Once you find a restriction, work can be done to mitigate the effects of that obstacle.  It seems common sense, but in the rush and frustration of our daily jobs, we often miss these common sense approaches.

Goldratt shows his most revealing insight. The mitigation of constraints follows a clear and easy to reproduce the process. The process is as follows:

1. Identify the system's constraint.
2. Decide how to exploit the system constraint
3. Subordinate everything else to the above decisions
4. Elevate the system constraint
5. If in the previous steps a constraint have been broken return to step 1, but do not allow inertia to cause a system constraint.

Five steps and it does not matter if you are working in a machine shop or managing a bunch of creative professionals, a person can improve the efficiency of a process.

I have been struggling with the notion of exploiting and subordinating a constraint.  Fortunately, the theory of constraints has plenty of academic support and an excellent blog about these five steps.  I look forward to using them at my firm.

Until next time.

Food Trucks and the Theory of Constraints.

The food truck can teach us about theory of constraints

In the global economy, events are moving at the speed of light.  An order placed in Singapore triggers a cascade of events in Tokyo and then at the corporate headquarters in Chicago.  Technology makes this kind of speed and accuracy possible.  To many people who use this technology, it is like magic.  To people who build and maintain these systems, it is hard work.  So the biggest challenge of our time is how to balance the desires of people who think technology is magic with the reality of innovation being hard work.  This week an introduction to the theory of constraints and what it means to a scrum master.

I have been reading a book entitled, “The Goal: A Process of Ongoing Improvement,” by Eliyahu M. Goldratt.  It puts the reader in the shoes of a plant manager of a failing company.  His wife is unhappy with all the responsibilities he has which keep him away from his family.  His boss threatens to shut down his plant in 90 days.  He is also dealing with his children and his aging parents.  It is a trifecta of stress which would grind down any person. 

The main character has to juggle these competing demands on his time and energy while confronted with the collapse of his marriage and loss of his job.  He decides to concentrate on saving his job to provide for his wife and family.  Over the course of the book, the protagonist learns about the theory of constraints and how to use it to save his plant.  I will let you find out for yourselves if his marriage survives. 

I am personally surprised that I did not get exposed to this idea sooner in my career.  In layman’s terms, the theory of constraints posits that a system can only operate at the speed of its slowest sub-unit.  For instance, if you have a food truck, you have someone taking orders, someone doing food preparation, and someone plating finished products and delivering them to customers.  I realize that this example features a crowded food truck but stay with me.  The cashier can take an order every two minutes.  The owner can prep food for about 10 minutes per items on the menu.  Plating and delivering food takes five minutes. 

In this simple example, it is clear the slowest part of the process is preparing the food.  If there are ten items on the menu, it takes 100 minutes or almost two hours.  If done in a just in time fashion, then it takes 10 minutes.  So, a busy developer visiting the food truck outside of the office has to wait almost 20 minutes to get a meal.  This kind of service would put the food truck out of business.  The bottleneck is food prep.  Most food trucks avoid this issue by doing food prep in advance.  It reduces meal time from 20 minutes to seven. It is a major improvement, and it might keep the food truck in business. 

As a scrum master, it is important you recognize the bottlenecks which slow down the flow of value through the organization.  Are product owners not writing stories?  Are developers not doing test-driven development?  Maybe the release process is taking too long.  A good scrum master will figure this out and try to smooth worth through the system. 

The theory of constraints contains plenty of mathematics and ways to measure flow through the system, but the general idea is to find the slowest part of the system and maximize it to find the slowest part of the system and maximize its output while preventing work from stacking up before the bottleneck and slack gathering behind it.  Like many discoveries in science, engineering, and project management it is pretty simple once we understand it. 

Until next time.