Monday, December 11, 2017

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. 

Monday, December 4, 2017

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.


Monday, November 27, 2017

Experience Matters in a Scrum Coach

Leadership experience is not pretty but necessary
Plenty of issues crop up in the day to day life of a scrum master.  Impediments need to be resolved and each day you are a living example of how Scrum is supposed to work.  As a fellow coach, Ryan Ripley remarked on how some individuals with little experience with agile are marketing themselves as coaches.  Ryan feels pretty strongly about the subject, and so do I.

There are two lines of thought about leadership.  The first school is called the “great man theory.”  This school firmly believes that great leaders are not made but are born.  This notion has been used for generations to support monarchs and other forms of tyranny.  For each leader born into greatness, there are numerous counterexamples of individuals who fall woefully short.  There is also an elitism and snobbishness associated with this school of leadership which says that only specific groups can aspire to leadership.  I also find this type of thinking has plenty of sexist and racist baggage associated with it.

The second school of thought is the notion that leadership can be taught just like any other skill.  I am a firm supporter of this idea.  When I was a teenager, I benefited from leadership training from Boy Scouts of America and Marine Corps Junior Reserve Officer Training Corps.  I had the Boy Scout Law ingrained into my personality at an early age.  The outdoor activities forced me to learn to help younger scouts cope with being alone and away from home for the first time.  Being caught in a rainstorm surrounded by wet and tired twelve-year-olds is a good measure of your leadership skills.

Marine Corps JROTC taught me self-discipline, my left form my right and that leadership is more about credibility than shouting at people.  I met some remarkable people.  David Ogle was a survivor of combat around the Chosin reservoir and a USMC boxing champion.  He served in Vietnam and became a Sergeant Major.  Richard Weidner was a company commander in Vietnam and taught me about the less than glamorous things leaders have to do.

Together, Boy Scouts and Marine JROTC gave me a good foundation from which to build.  I took that knowledge with me into the sales profession, the casino business, radio, and finally into technology.  I am entering the fifth year of being a scrum master.  The experience of shipping software at the end of each sprint changes a person and their style of leadership.  Working with offshore teams changes how you relate to others.  Those experiences make you a better scrum master and coach.

We can teach leadership, in my opinion.  I also feel experience acts as a multiplier of leadership skill.  A good leader does not ask someone to do something which they would not do themselves.  That means if you ask a developer to write a unit test you better be willing to write a few of your own.  An agile coach who has not led a retrospective or shipped code is not a coach because they lack the practical skills to make agile successful.  They are faux coaches, and you should steer clear of them.  An agile transformation is like performing a heart transplant on a person running a marathon; you would not trust that job to a first-year medical student.  Anyone can call themselves a coach, it takes time and experience to be a valuable coach

Until next time.



Tuesday, November 21, 2017

A Little Gratitude this Thanksgiving.

Mmmm Pie!
If you are working as an agile coach or scrum master you spend plenty of time working in negative situations.  Continuous improvement means finding things which are not working and helping others fix them.  It is an often a thankless process filled with personal and professional frustration.  This week I want to take a step back from my day to day struggles and reflect on the things which make me grateful.

I am grateful for the people who work with me.  I have developers spread over two continents, and they are smart and hardworking individuals who make my day easy.  The team accepts my faux cheerfulness in the early morning during stand-up calls.  The team also put up with my grumpy admonitions to follow good code practices.  The development teams I work with are a pleasure to work with, and any scrum master would be honored to work with them.

Next, I am deeply grateful to LSC Communications for allowing me to lead agile initiatives.  It has to be strange having an entrepreneurial person in your cubicles asking awkward questions and shaming individuals to do better work.  You embrace my enthusiasm and flakey nature to help make the organization better.  The world of business moves at the speed of the internet, and I am glad you allow me the opportunity to guide the firm in that direction.

I have an understanding group of friends.  I do not spend as much time with them as I should.  We play cards, board games and plenty of military simulations.  They keep me grounded.  They keep me clean and sober.  They have supported my professional decisions, and they have been there for me throughout the inevitable ups and downs of my career.

My family generates a fountain of gratitude.  As my parents have grown older, I have become close to them.  They show me the kindness and support that is sorely lacking in the other areas of my life.  In the aftermath of my divorce, they have prevented me from wallowing in loneliness and made sure I bought groceries.  I wish I were half as good as my parents.

In spite of all the difficulty of my career, I have a lot to be grateful; my colleagues, my company, my friends, and family make life worth living.

Happy Thanksgiving until next time.


Monday, November 13, 2017

The tribalism hurting your agile practice

My Agile Practice has changed over the years.
It has been a strange year.  Last year, I was talking about comfort food and sleeplessness.  Three hundred and sixty-five days later, I want to share a little wisdom I have gained along the way.  This week how disappointment can make you a better scrum master. 

I have deliberately not discussed politics on this blog.  The internet is filled with plenty of places on the political right and political left to discuss current events.  I have plenty of strong opinions myself but do not share them here because they are not germane to the discussion of Agile, Lean, and Scrum.  The world of business transformation is hard enough; injecting partisan political views seems counterproductive to me.

I come from the world of college debate and forensics.  It is a community centered in the “reality-based,” zones of academia, science, media, and government.  It is a skeptical community which relies on empiricism and rhetoric to persuade others. These same institutions are referred to by political conservatives as pillars of deceit.  A year ago, my smug self-assurance in my expertise took a severe beating. 

Over the last year, I have gotten much wiser.  I have rededicated myself to my profession.  I shut down my internet startup.  I even made an effort to listen to Nickelback to see if there was any merit to their music.  Suffice to say; it was the audio equivalent of eating chocolate frosting out of a tub with a spoon; including the stomach ache. 

The most significant notion revealing itself to me was the concept of epistemic-tribalism.  I felt that if you are “reality-based,” and gave people the facts of the situation, they would eventually come around to your point of view.  If this formulation was good enough for Socrates, then it was good enough for my agile practice.  I now realize this was naive.  People have deep emotional and political biases.  Stating the facts is not good enough.  When confronted with facts that contradict their worldview or place in the world, some people will reject those facts.  It is similar to the ideas of Wittgenstein who explained language was a construct and subject to games.  Furthermore, two people can look at the same object and see two different things.  The neat and tidy world based on objective reality and evidence fell away replaced by an effete world of conjecture resembling a postmodern literary theory class.  It was disorienting. 

If epistemic tribalism can happen in the realm of national politics, it is not too far of a stretch to see it manifest itself the cubical of an office.  Personal relationships are more important than sales.  Countless Quid Pro Quo agreements bind the office together and harm customer service.  Tenure with the organization is more important than accomplishment.  Finally, being likable is more important than getting work done.  It became clear to me that these things were happening.  I counted on the better angles of others instead of understanding the tangled webs of motivations.  To be a successful scrum master or agile coach, I had to accept office professionals could be nasty and brutish. 

So this last year for me, the political became professional.  Reason and empiricism are less useful tools for change compared with understanding the motivations and prejudices of my colleagues.  Epistemic-tribalism is a real thing, and you need to understand it in your organization.  Finally, it takes disappointment for you to set aside your prejudices and view your surrounding differently.

Until next time.

Monday, November 6, 2017

Agile is about Deadlines

I have nothing on Martin Luther
but I know a little about software development.
Five hundred years ago a German monk named Martin Luther hammered 95 theses to a church door.  He was calling attention to corruption inside the Catholic Church and started the events which created the protestant reformation.  The agile manifesto is only sixteen years old, but it has produced a transformation in the business world.  I consider myself one of the evangelists spreading the word.  With every reformation, there is a counter-reformation, and today I would like to discuss one of the principle objections used by opponents of agile.

There is an excellent blog post written by the Wall Street Journal called “9 Myths About Agile.”  I strongly recommend it.  One of the most durable myths about Agile is the preconception that deadlines do not matter. Work gets completed, and deadlines are not necessary.  I wish to argue that deadlines are an essential part of the agile process and provide an example of how it works.

The most central feature of Agile and Scrum is the time box of the sprint.  For two to four weeks, the development team completes goals.  If they do not finish the stories in that period, then the sprint is considered a failure.  Failure is not a bad thing it is a learning opportunity for the team can to do better next time. Scrum relies on deadlines to focus effort and drive improvement.

Skeptics would then argue that sprints are well and good, but there are not firm due dates to communicate to upper management or the people paying for the work.  My reply is that with a sprint backlog following Roman Pichler’s DEEP model, it is easy to forecast when work will get completed.  The backlog is detailed to show the volume of work.   The backlog is estimated because it allows the product owner and the business to predict when work will get done.  The backlog is emergent so it can adjust to changing conditions as a project moves forward.  Finally, prioritization allows the firm to say what matters and what does not.

I am now going to provide a simple example.  The marketing department needs to incorporate social media into its website.   The works need to be accomplished by November 1st. The product owner gets to work, and come up with a list of features.  It should look like this:

  • Milestone: Social media on corporate website (Due Nov 1st)
    • Feature: Facebook
    • Feature: Google+
    • Feature: Twitter
    • Feature: Pinterest
Now it is up to the Product Owner and development team to write stories.  After a week or two of effort the backlog looks like the following:

  • Milestone: Social media on corporate website (Due Nov 1st)
    • Feature: Facebook
      • Set up a Facebook account.
      • Create Hooks into Facebook API.
      • UI for Social media on the page.
      • Create log internally when pages are shared.
    • Feature: Google+
      • Set up Google+ corporate account.
      • User Google tools to allow sharing of stories from the website.
      • UI for Social media on the Page.
      • Create log internally when pages and shared.
    • Feature: Twitter
      • Set up a corporate Twitter account.
      • Use Twitter API to post content.
      • UI for Social media.
      • Create log internally when pages are shared.
    • Feature: Pinterest
      • Set up corporate Pinterest account.
      • UI for Social media.
      • [Spike] prototype how to use Pinterest API.
      • Create a log when pages are shared.
The backlog looks typical to a scrum master or anyone on a development team.  The Vice President might understand what the group plans to do. The group estimates with story points because business people treat hours estimates as quotations of work.

  • Milestone: Social media on corporate website (Due Nov 1st)
    • Feature: Facebook
      • Set up a Facebook account. - 2
      • Create Hooks into Facebook API. - 3
      • UI for Social media on the page. - 3
      • Create log internally when pages are shared. - 13
    • Feature: Google+
      • Set up Google+ corporate account. - 2
      • User Google tools to allow sharing of stories from the website.- 3
      • UI for Social media on the Page. - 3
      • Create log internally when pages and shared. - 13
    • Feature: Twitter
      • Set up a corporate Twitter account. - 2
      • Use Twitter API to post content. - 3
      • UI for Social media. - 3
      • Create log internally when pages are shared. - 13
    • Feature: Pinterest
      • Set up the corporate Pinterest account. - 3
      • UI for Social media. - 3
      • [Spike] prototype how to use Pinterest API. - 8
      • Create a log when pages are shared. - 13

The estimates from the team point out severe risk and ambiguity.  Also, the team has not worked with Pinterest, so they are going to do some experiments to understand how it works.  The sponsor of the product might get frustrated at this point and ask, “When will it be done? Can I have it by November 1st?”

The scrum master should be able to answer that question.  According to the backlog, there are roughly 91 story points of work.  The team can do 21 story points a sprint and each sprint is three weeks long.  It will take roughly twelve weeks to do the job. It is good news if it is June but bad news if it is September.

So a process of negotiation begins where stories get prioritized, and others ignored.  If the company sells food products, Pinterest may be more critical than Google+.  A media company which relies on breaking news might ignore Pinterest and focus on Twitter.  The product owner might notice that each social media site has its analytics suite and that an internal log is not necessary.  Fifty-two story points fall off the board.  We have 39 story points of work which we can get done in two sprints or six weeks.  If we begin in August, we will hit our due date.  The final board looks like this:

  • Milestone: Social media on corporate website (Due Nov 1st)
    • Feature: Facebook
      • Set up a Facebook account. - 2
      • Create Hooks into Facebook API. - 3
      • UI for Social media on the page. - 3
    • Feature: Google+
      • Set up Google+ corporate account. - 2
      • User Google tools to allow sharing of stories from the website.- 3
      • UI for Social media on the Page. - 3
    • Feature: Twitter
      • Set up a corporate Twitter account. - 2
      • Use Twitter API to post content. - 3
      • UI for Social media. - 3
    • Feature: Pinterest
      • Set up the corporate Pinterest account. - 3
      • UI for Social media. - 3
      • [Spike] prototype how to use Pinterest API. - 8

So in this brief and simple example, I have shown there is a quantitative and drama free fashion to discuss projects where deliverables get negotiated, and deadlines get met.   Agile and Scrum can help people make educated decisions about what work can get done and when it will get done.  All that is required is a conscientious product owner, a dedicated development team, and a scrum master who will speak the truth to decision makers.

Agile is about deadlines, and I am willing to put my career at risk to prove it; just like that German Monk from five centuries ago.

Until next time.

Monday, October 30, 2017

It is time Agile crushes magical thinking in business.

Working in Technology is like taming a dragon.
In the contemporary business world, one of the things which surprised me the most is how divorced people are from the technology which their careers depend upon.  Arthur C. Clark, the author of “2001: A Space Odyssey,” said, “…and sufficiently advanced technology is indistinguishable from magic.”  Today, in a world moving at the speed of the internet, tens of millions of people are wandering the world behaving like magicians.  I want to talk about what this means for you the scrum master or agile coach. 

At the click of a smartphone, a human being can summon a ride, book restaurant reservations, order clothing, and find potential romantic partners.  News and gossip travel around the globe.  We can even live in virtual spaces reshaping our bodies ignoring concepts or gender and aging.  Thanks to the world of technology and algorithms we can live in a curated rich world where there are no opposing opinions and everything is quick and convenient.  It is a seductive world. 

The world I describe is the product of millions of hours of labor and the application of fifty years of merciless engineering to make systems better, faster and cheaper.  It is the application of silicon wafer technology, advanced mathematics, and smart people doing smart things.  It is the unwritten story of our time.

Now imagine people who live in the magical age who want to implement a new payroll system or create a better way to get products to customers.  Since they are accustomed to systems which are quick and compliant, they think it is possible to spin up systems which behave the same way with the speed of downloading a phone application.  These magicians take it for granted that the data will always be correct and they do not need to proofread the work. 

This is not the reality of technology.  Developers need to get involved, and they need to be managed, so the code is clean and scalable.  Data needs to be placed on Oracle or Microsoft SQL servers.  Network accounts need to be created, and all of this costs time and money.  It is not magic.  It is hard work.

As a former web developer, it always troubled me when people told me how they expected a website to look and behave without understanding a lick of HTML code.  It is my experience these individuals rise in organizations and get budget authority.  So you have the ignorant paying the bills while someone more ignorant is giving orders to the development team.  It falls to a technology lead or scrum master to transform ignorance and magical thinking into code.   It is just as disheartening as it sounds. 

It is also why so many technology projects fail because the people involved do not conceptually understand the labor it takes to get the job done.  A construction project is easy to understand compared to a software project because the people paying the bills realize what is happening.  A typical business person does not understand the difference between Java-script and JAVA; so how are they going to know what it takes to successfully construct a web application.

As a scrum master, it is your responsibility to crush magical thinking.  Tell the truth about how long it is going to take to get something done.  Show people work in progress and ship code periodically so if adjustments need to be made they can happen in a timelier manner.  You will have to say no, and you will have to create trust between the development team and business.  This means enforcing one of the central tenants of Agile; their business sets the project priorities, and the development team says how long it is going to take.  If this social compact is not upheld, then any agile implementation will collapse into dust. 

So in this magical world, it is up to the scrum master to create a much-needed dose of reality.  Otherwise, you are confronted with an evil magic act which does nothing but disappoint. 

Until next time.