Taking agile one day at a time.

The most significant moment in any project is the ribbon cutting or product launch.  It features executives, politicians, and other VIPs cutting a ribbon or giving a splashy PowerPoint presentation before a crowd of adoring fans.  Many people do not understand that those moments of public triumph required many days of sacrifice, frustration, and suffering.  Technology is hard work, requiring focus, intelligence, and unhealthy concentration levels.  As an agile coach or scrum master, navigating these long periods of grinding work is challenging.  Today, I want to take some time to discuss how an agilist can navigate this period. Author Lewis Carroll labeled between the idea and reality.  

One of the most important books a technology professional can own is Fred Brooks' "The Mythical Man-Month." It outlines some principles of project management that remain applicable today.  It includes Brooks' Law, which says late projects become later if you add more people.  Brooks talks about the importance of architecture in software development and how the division of labor between specialists makes it harder to lead a project.  The most significant insight was that a project falls behind schedule one day at a time. 

Each day, the team attempts to get its work done.  The task is straightforward if you are digging a hole in the ground.  Software professionals look at problems that resemble getting square pegs to fit into round holes.  Data from one system must be displayed differently on a mobile device than a web browser while traversing multiple data points to obtain meaning.  Each day, engineers, developers, and project professionals slog through those problems and more.  It creates pressure that builds over time because many of these problems that need to be solved do not have easy answers. 

Chicago Sports columnist Bob Verdi would joke weekly when football injury reports were published.  A famous player is often listed as day-to-day.  With a comical tone, Verdi would tell his radio audience, "… aren't we all." As technology professionals, we all live day to day, solving problems and building solutions.  It means that we should not concentrate on where we are in the project's overall life; instead, we should focus on what we need to finish that day.  It makes the emotional ups and downs less severe.  

Taking the work day-by-day allows you to filter out the politics around projects and the petty displays of status you see in corporate environments.  When problems linger, you gather together with others to find solutions.  It is hard to do because the people who begin enterprise-level projects are not around when they finish.  It is why you look at each day as a single unit and judge your success or failure on how you meet the goals of that particular day.  You build up good days and attempt to shrug off the bad ones to create a body of work that meets the project's long-term goals.  Brooks is correct; projects do fall behind day by day, but they also succeed daily.  

If you are a coach or scrum master, instill this notion in your team.  The team is building big things, but they create many small items, adding up to something spectacular.  Improving one percent a sprint means an improvement of over twenty-six percent over a year.  Improving team performance like this often gets people promoted in corporate environments.  It makes working on the team more satisfying and lowers everyone's stress levels on the project.  

Lewis Carroll said, "…between the idea and the reality lies the shadow." Taking work day-by-day allows you to handle better the darkness which occupies the shadows of your project.  It is not easy, but nothing worth doing is. 

Until next time.