Merry Christmas

It is Christmas day.  This year has been a whipsaw of emotions.  In that time, I have shared the wisdom I have gathered.  Thank you for reading along and joining in the conversation.  I am going to take some time off away from the office and spend it with family.  The New Year is going to be filled with excitement and I look forward to sharing it with you. 

Have a happy Christmas and until next time. 

Some Thoughts About the Holiday Rush

A little holiday rush

It is the final rush of 2017.  The business is pushing to squeeze as much profit out of the holiday season while the technical professionals are scrambling to bring on-line systems promised by the executive team.  It is a busy time and filled with pressures both personal and professional.  I find it hard to cope with this strain.  You spend time keeping the commitments of others and struggle to use the difference supporting family and friends.  This week I want to make sense of the holiday rush. 

For as long as I have been a business professional, the one motivation I have seen in business is fear; visceral, cold, unforgiving terror.  It is the anxiety that you are not hitting your sales figures.  It is the panic of the payroll system not interfacing with the accounting software.  It is a shame that comes with a sixty hour work week not being enough to deliver what your manager promised. 

The reason I became so enamored with agile and scrum is I wanted to work without fear.  I have been fired the week before Christmas.  My spouse left me because I finished up a consulting contract early.  Each meeting with quality assurance or my manager triggered spasms of fear.  There had to be a better way.  Agile and scrum provided a means to do things differently and escape that fear.

I have been in the agile practice for eight years.  I have had tremendous successes and bitter failures.  I have lost countless hours of sleep and overeaten junk food.  I have struggled against organizational inertia and corporate indifference.  I would not change a thing because the changes I have made mean that one less developer is living in fear.  That makes it a worthy goal. 

So as I fight crowds to get my shopping done and stay up late to ship software on time; I understand the sacrifice and frustration I put in for 2017 is worth it.  There is a little less fear in the office.

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. 

That awkward talk about scaling

Portrait of a Scrum
Master as a young man.

When the signatories of the agile manifesto got together sixteen years ago, they had no idea what they created would be the basis for a reformation in the business community. I have been part of the agile movement since 2009.  I am a short timer.  During my brief agile practice, I have noticed a trend.  Software projects are getting bigger, and it is becoming increasingly difficult to lead these projects.  This week I want to talk about scaling agile as software eats the world.

When I first learned about agile and scrum, I felt like the apostle Paul on the road back from Damascus.  It was like being struck by lighting and seeing the world for the first time.  The team did work in sustainable chunks.  Stakeholders would receive rapid feedback about how the project was going.  If something was wrong, it could be escalated quickly up the chain of command.  The ability to create software would become more sane and human.

I was deeply deluded.  I did not count on the ingenuity of my fellow software developers to avoid work.  I was blind to the inertia which exists in the modern corporation which rejects new approaches to solving problems.  Finally, executives and financial professionals see agile as a threat because it undermines their need for command and control.  Confronted with these realities, agile and scrum became a means to help small teams ship software promptly.  As individual groups became successful, management began paying attention.  Soon entire Agile consulting teams sprang up offering Scrum Masters and developers who could rapidly bring software to life.  For three years, everything was going well, until enterprise software application attempted to be agile.  It was 2012 and agile hit awkward puberty.

Software teams would be sprinting at different cadences.  Some teams would be sprinting every three weeks while others would be on a two-week cycle.  Network teams were not even sprinting and would treat requests on a first in first out basis.  Finally, the marketing team would be making promises which others would have to keep.  I and others would ask, how do you scale Agile across multiple groups and projects with hundreds or thousands of developers?

The answer has fractured the agile world into three camps; scaling with scrum, SAFe, and LeSS.  I have received formal training in scaling with Scrum and SAFe.  I am looking forward to attending LeSS training in the new year.  Each camp is involved in a friendly rivalry with each other.  Each approach seems to be dealing with project scaling differently.

My first exposure to scaling agile was called, “scaling with scrum.”  The approach was very organic.  As an organization grew, the backlog of work would splinter into smaller backlogs.  These backlogs would then be delegated to teams and completed. In the end, these smaller backlogs would bubble up into a “master backlog,” so that leadership could track what was happening.  I liked it, but it did require plenty of administrative work.  It also assumed that everyone was in perfect communication with everyone else in the organization.

My next exposure to scaling came from the world of SAFe.  This framework has caught on with more prominent organizations because it has a command and control structure which is very familiar with executives.  Scrum Teams bubble up into release trains, and those trains have particular departure dates.  Networking, Software, and Hardware all obey scrum or a Kanban approach to work.  Leadership over three or four sprints then witness a “product increment” and inform what direction to take next.

I like SAFe.  It feels like a good marriage of agile and corporate structure.  I see three principle drawbacks.  First, executives can maintain a top-down approach to innovation and control of the software process.  Next, SAFe depends on quality Product Ownership, and this is the weakest area of the agile movement.  Finally, working in a SAFe development environment feels like being a cog in a giant wheel.  If we can figure out how to mitigate these issues, then SAFe might be the future of agile.

As an agile coach and scrum master, I have borrowed liberally from the scaling frameworks.  One of the tenants of the Agile Manifesto is, “…responding to change over following a plan.” So I found it necessary to incorporate elements of SAFe which work with those which can wait.  I use scaling scrum with scrum all the time in my agile practice.  I also rely on the suggestions and directions of my peers and management to get software shipped out promptly.

In my opinion, we are still in the awkward years of the Agile Reformation.  We are very good at shipping software from small teams, but when we try to scale to large multi-national corporations, we still have plenty of work to do.  Software is eating the world, and if we are not careful, it will consume agile and scrum.

Until next time.