Revisiting Augustine’s Laws

August 19, 2015

Augustine’s Laws is a collection of management insights first published in the mid-1980’s by former undersecretary of the Army and CEO of defense contractor Martin Marietta Norman Augustine. It contains 52 (one per week) “laws” of management that Mr. Augustine picked up in his many years working in government and the defense industry.  Each law is written in the form of a humorous vignette that is meant to stand on its own.  The book is still available via Amazon (though at a premium) and given its substantial enduring wisdom is surprisingly hard to find through the library system.

Most of the book is specific to government contracting circa late 20th century but some of the insights are just as applicable today as they day they were first written.  The canonical list of the laws are available at Wikipedia.  Here are some of the more interesting ones:

  • Law XV (aka Law of Insatiable Appetites) – The last 10% of performance generates one third of the cost and two thirds of the problems.
    • Corollary 1: The price of the ultimate is very high indeed. Sometimes it would seem that one might be better served by having a more of a little less.
    • This is very similar to George Patton’s statement – “A good plan, violently executed now, is better than a perfect plan next week.”
  • Law XXIII (aka Law of Unmitigated Optimism) – Any task can be completed in only 1/3rd more time than is currently estimated.
    • Corollary 1: If a schedule is three quarters complete only on third time remains
    • Corollary 2: When it comes to schedule adherence everything is relative.
    • Corollary 3: The sooner you start to fall behind the more time you will have to catch up.
  • Law XXIV (aka Law of Economic Unipolarity) – The only thing more costly than stretching the schedule of an established project is accelerating it, which is itself the most costly action known to man.
  • Law XXXV (aka Law of Definitive Imprecision) – The weaker the data available upon which to base one’s conclusion, the greater the precision which should be quoted in order to give the data authenticity.
  • Law XXXVII (aka Law of Apocalyptic Costing) – Ninety percent of the time things will turn out worse than you expect. The other 10% of the time you had no right to expect so much.
  • Law XLVIII (aka Law of Oratorical Engineering) – The more time you spend talking about what you have been doing, the less time you have to do what you have been talking about. Eventually, you spend more and more time talking about less and less until finally you spend all of your time talking about nothing.

The perspective of the book is that of a senior manager working on large defense programs in the late 1970s and early 1980s.  While there are certainly universal truths, much has changed in the intervening thirty years – particularly in the field of software development.  Today software is generally built incrementally by self-directed teams using a flavor of agile.  Most agile teams live by the credo that the best way to eat an elephant is one bite at a time.  Agile is popular not because the problems are any less changing – indeed application complexity is increasing not decreasing – but because it provides for predictability that simply is not possible with massive projects.

As interesting as laws are, the management observations in the last chapter are as relevant today as they day they were written – if not as pithy.

  • People are the key to the success in most any undertaking, including business.
  • Teamwork is the fabric of effective business organizations.
  • Self-image is as important in business as in sports. A corporate team must think of itself as a winner.
  • Motivation makes the difference.
  • Recognition of accomplishment (and the lack thereof) is an essential form of feedback.
  • Listening to employees and customers pays dividends – they know their jobs and needs better than anyone else.
  • Delegation, wherever practicable, is the best course.
  • Openness with employees and customers alike is essential to building trust.
  • Customers deserve the very best.
  • Quality is the key to customer satisfaction.
  • Stability of funding, schedules, goals and people is critical to any smooth business operation.
  • Demanding the last little bit of effort from oneself is essential – it can make the difference against competitors who don’t have the will to put out the extra effort.
  • Provision for the unexpected is a businessperson’s best insurance policy.
  • “Touch-Labor” – people who actually come into contact with the product – are the only certain contributors in any organization.
  • Rules, regulations, policies, and reports, and organization charts are not a substitute for sound management judgement.
  • Logic in presenting decision options, consequences, benefits, and risks is imperative.
  • Conservatism, prudent conservatism, is generally the best course in financial matters
  • Integrity is the sine qua non (indispensable and essential action, condition, or ingredient) of all human endeavors including business.



Predictions 2015: CIOs Accelerate The Business Technology Agenda

February 21, 2015

At the end of 2014 Forrester published a short research note entitled “Predictions 2015: CIOs Accelerate The Business Technology Agenda.”  (The report is $499 if you get if from Forrester but Microsoft has apparently licensed the content to make it free.)  Some of the provocative ideas in the note include:

Many CIOs have the technical expertise and cross-functional business purview to help drive digital innovation, but they are too often still seen as the leader of a cost center.

This is the truth.   Not that it is much fun for anyone but for those of us in IT budget season is a constant battle for funding.  Many times the best outcome is level funding.  Generating revenue on our own would change the game.

Both consumer and business customers increasingly expect real-time access to connected product and service information. These expectations not only define customer engagements but also ripple throughout the supply chain — shortening product cycles, requiring more agile operational capabilities, and creating opportunities for new, disruptive digital services.

Even some of the smallest businesses – appliance dealers, car services, and even dentists offer on-line access to inventory, scheduling, and account information.  Larger companies that offer primitive or worse no access to this type of information absolutely stand out as laggards. Increasingly not only is the expectation that information will be on-line and accessible organizations without a credible mobile strategy are at a competitive disadvantage.

  • Prediction No. 1: CIOs Accelerate The Business Technology Agenda

There are a ton of buzz words buried in this predication including agile development, connected products, mobile services, and customer-focused governance models.  The reality that many of us live with every day is doing more with less.  Technology is lever to these new challenges.  For example, automation of tasks previously only done by humans can lead to dramatic cost and time savings.  Better, cleaner execution, using new development techniques (e.g., DevOps, automated testing) make it faster and more efficient for development teams to get code in the hands of customers.  Cross platform development is now realistic using tools like Xamarin.  Finally, highly reliable consumption based cloud delivery platforms are available from multiple different providers.  While the challenges have never been more formidable so too the tools at our disposal have never been more powerful.

  • Prediction No. 2: CIOs Unlock Data-Driven Business Opportunities

According to CSC there will be more than 35 ZB of data generated in the year 2020 – a 4300% growth from 2009.  It’s hard to visualize that much data.  Much of that information will come from the emergence of sensor data (think connected refrigerator) that has previously never been on-line or accessible.  While there will no doubt be new unstructured data such as this, traditional web and mobile applications (Facebook, Instagram, and Twitter) will continue to evolve and grow.  The dramatic growth of information calls for new solutions to make sense of it all.  Again there is cause for real optimism that technology is keeping pace; There are powerful NoSQL / NewSQL databases such as Cassandra, analysis engines such as Hadoop, and visualization platforms such as Tableau.  Many of these technologies are open source and most of the commercial solutions are reasonably priced – often tied to consumption.  One of the primary challenges is the imperative to get technology organizations thinking differently.  For example, it is fully possible to use Cassandra like a relational database but in so doing much of the value of the solution would be lost.

  • Prediction No. 3: CIOs Make CDOs Unnecessary

The notion of a Chief Digital Officer (CDO) is perhaps a role that exists in larger organizations.  Someone, whether it be a CDO or the CIO, needs to truly own the responsibility for protecting the organization’s customer data.  High-profile security breaches such what happened to Target, Sony, the US Army, and many others have made it apparent that this huge issue.  Organizations are under near constant attack from outsiders that at best want to put an offensive message on the home page and at worst want to hold it hostage for ransom.  Protection of data starts with penetration testing, applying best of breed solutions (FireEye, Palo Alto Networks), and aggressively patching vulnerabilities as they are found.  This all will maintain the status quo.  Forrester rightfully points out that the best organizations will find ways where the Chief Marketing Officer (CMO) will be tightly aligned with the CIO to leverage technology to move the business forward.

Become leaders of digital change – or be usurped. Somebody has to be in charge of increasingly connected and dependent technology for the enterprise.  Fast-cycle, tech-based innovation drives a coherent, cross-channel digital experience is crucial to succeeding in today’s markets. …  Are all CIOs up for the challenge? No.  But in 2015, any CIO who isn’t will be replaced by one who is.

As Zig Ziglar said “Success occurs when opportunity meets preparation.”

Agile Pre-mortem Retrospectives

June 6, 2014

Failure is Your Friend is the title of the June 4, 2014 Freakonomics Podcast.  The podcast interviews cognitive psychologist Gary Klein.  Klein talks about an interesting technique called the pre-mortem.  “With a pre-mortem you try to think about everything that might go wrong before it goes wrong.”  As I was listening to Klein talk about how this might work in the physical world and medical procedures it occurred to me that this might be a nice compliment to an agile software development project.

Most scrum teams do some type of post-mortem after each sprint.  Most of the literature today calls these activities retrospectives which has a more positive connotation.  (Taken literally post mortem means occurring after death in Latin.) After training exercises the Army conducts after action reviews, affectionately called “AARs.”  For informal AARs (formal AARs have a proscribed format that is expected to be followed) I always found three questions elicited the most participation – what went well, what did not go well, and what could have been done better.  This same format is often effective in sprint retrospectives.

A pre-mortem retrospective would follow a very different format.  It asks the participants to fast forward in time after the release and assume that the project was a failure.  Klein’s suggestion is to take two minutes ask each participant to privately compile a list of why the project failed.  He then surveys the group and compiles a consolidated list of why the project failed.  Finally, after compiling the master list he would ask everyone in the room to think up one thing that they could do to help the project.  Ideally the team is more attuned to what could go wrong and willing to engage in risk management.

In concept the idea makes a ton of sense.  I can see how it would force the team to be honest with themselves about risks, temper over confidence, and ultimately be more proactive.  On the other hand a pre-mortem is one more meeting and one more activity that is not directly contributing to the project.  I question if there is enough value to do a pre-mortem on every sprint, however, for major new initiatives it could be a useful activity.  I quickly found two references on this topic.

Scaled Agile Framework (SAFe)

December 27, 2013

Implementing agile methods at higher levels, where multiple programs and business interests often intersect, has always been a challenge.  Consultant Dean Leffingwell, formerly of Rally Software and Rational Software, created a project management framework called the Scaled Agile Framework (SAFe) for applying agile principles at the enterprise level.

Scaled Agile Framework

At a high level SAFe is set of best practices tailored for organizations to embrace agile principles at the portfolio level.  Conceptually SAFe creates a framework whereby there is an integrated view and coordination between multiple different projects.  NB: The graphic on SAFe home page (see screenshot above) is clickable and itself is a terrific agile reference in of itself.

One of the best things about agile methodologies is that it is lightweight and self-directed.  High-level systems run the risk that they have more overhead than value.  On the other hand nearly every organization that has more than one product has the need for an integrated view of how projects fit together.  Indeed, it is not unusual to see senior managers disconnected from day-to-day operations struggle to see how pieces fit together or attempt to make invalid comparisons between teams such as story point velocity.

At the end of 2013 two of the market leaders in application life cycle management (ALM) are Rally Software and Microsoft.  Both Rally and Microsoft’s Team Foundation System (TFS) have wholeheartedly embraced the notion of portfolio management in the latest iterations of their respective products.

Rob Pinna of the Rally Development team has a great analysis of the SAFe here.  Similarly InCycle Software, a Microsoft Gold Certified ALM partner, recently did a webinar highlighting a customized version of a TFS template they used to demo the capabilities of TFS to support SAFe.

Thoughts on Agile best practices

August 2, 2013

I came across this article about Agile from David Starr which I thought had some really helpful insights.

  • There are a ton of agile methodologies – Scrum, XP, Kanban, lean, and the list goes on.  The best agile teams are indeed characterized by “just-enough process.” The key thing is that the team itself buys into what they are doing.  Similarly, the process needs to fit within the organizational structure.  Thrashing will occur if both of these conditions are not satisfied.
  • The three key tenants of agile are ship often, keep quality high, and solicit and respond to feedback.  In my view the trick to making this work is keeping breaking big problems down into smaller ones – just like we were taught in CS101.
  • A great question to ask is how long would it take to release just one comment in one code file to customers and how could that time be cut in half?  Extrapolating that question what would it take to cut a current sprint time in half?  Some organizations ship multiple changes per day.  Clearly that does not make sense for every organization but asking this question challenges the organization to understand what is not adequately automated.  Are there enough developer tests, is deployment sufficiently automated, are mechanisms in place to solicit stakeholder feedback built into the team’s workflow?

Thinking about what has worked for us we are most successful when / or most challenged when these do not happen:

  • Keep user stories as small as possible
  • The larger the story the more communication becomes necessary
  • Have a few metrics and reports that everyone can understand (e.g., velocity, story points, burn down charts)
  • Have regular demonstrations to end users
  • Ensure that each user story has clear acceptance criteria
  • Code reviews are done on complex functions / work done by less experienced engineers
  • Have a period of time where the end users can have hands on time with the product
  • There is automated regression testing
  • Time is allocated for keeping the code well organized (i.e., refactoring, commenting, etc.)
  • Time is allocated for prototyping new functionality or concepts

While I agree with most of what is in the article I think some of it is a bridge tool far.  For example, I fully agree with this statements.

  • Continuous integration (CI) grew from a novelty to a basic measure of professionalism. Pair programming found occasional root. Formal modeling fell into disfavor for all the right reasons.

I particularly appreciate the occasional qualifier about pair programming.  On the other hand I am not so sure that I agree with the statements.

  • Test-first practices evolved to being a de-facto design tool.
  • The understanding and use of design patterns resurged.

As I understand it test first is a component of XP which may or may not be a mainstream practice.  Similarly, while it well may be the case that design patterns are being used more frequently it may be the case that this is happening without developers actually giving it much thought.  For example, when a developer implements an Interface or an Abstract Class they are implementing the Abstract Factory pattern.  Similarly, the Observer pattern is commonly implemented in GUIs via event listeners.  Beyond the more common patterns and their implementations that are embedded in the language most the majority of the GoF patterns may primarily be the domain for architects, high-end programmers, and academics.

Best Practices for Tracking Agile Velocity Using Story Points

March 16, 2013

Scrum breakfast has a a great blog post which talks about Story Points:

  • Estimates are done by the team (if possible, the whole team) who will actually perform the work. So the team defines what a story point is. The classical approach is to look at list of backlog entries, take what appears to be the easiest, and declare that is a 2. Everything else is estimated relative to that task.
  • Story Points are usually estimated on the Cohn Scale (named for Mike Cohn, who popularized the concept): 0, 1, 2, 3, 5, 8, 13, 20, 40, 100.
  • So if we want to answer how long will it take to develop a particular software, we add up the story points, divide by the velocity, and that gives us the time.
  • Where does velocity come from? Before the first sprint, we guess. In the first sprint, the team accepts work based on gut feeling and discussion. After each Sprint, we measure the velocity. After two or three Sprints, the average measured velocity can be used to predict the velocity in the future, and thereby the completion date.

Mike Cohn’s blog on Story Points.  In this blog post he recommends that the best practice is to use both story points and hours for estimating the product backlog. 

  • I don’t use story points for sprint planning because story points are a useful long-term measure. They are not useful in the short-term.
  • Velocity is a useful long-term predictor but is not a useful short-term predictor.
  • Velocity will bounce around from sprint to sprint. That’s why I want teams to plan their sprints by looking at the product backlog, selecting the one most important thing they could do, breaking that product backlog item / user story into tasks and estimating the tasks, asking themselves if they can commit to delivering the product backlog item, and then repeating until they are full. No discussion of story points. No discussion of velocity. It’s just about commitment and we decide how much we can commit to by breaking product backlog items into tasks and estimating each. This is called commitment-driven sprint planning.
  • When a team finishes planning a sprint in this way it is indeed likely that the number of story points they have unknowingly committed to should be close to their long-term average but it will vary some. It will also be true that a team will commit to approximately the same number of hours from one sprint to the next. I use the term capacity to refer to this number of hours because velocity is reserved for referring to measuring the amount of work planned or completed as given in the units used to estimate the product backlog (which I recommend be done using story points).

Lean and Agile

June 10, 2010

I recently stumbled across a document called the “Lean Primer” by Craig Larman and Bas Vodde.  This document is based on the “Toyota Way” which strives to build a culture of that results in sustainably great products.  Although the Toyota Way is based on techniques used in automobile manufacturing I was struck by how applicable the framework is to software development.  Indeed these parallels have not escaped the document authors who wrote a book on the subject – Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum – and advise companies on applying lean thinking.

The Primer quotes the book “Inside the Mind of Toyota: Management Principles for Enduring Growth”  and states that “the essence of successful lean thinking is ‘building people, then building products’ and a culture of ‘challenging the status quo.’”  The first part of that statement sounds like it could be taken right out of Tom Peters Good to Great – first the who, then the what.

The Larman and Vodde summarize lean thinking using a “house diagram” based on a 1973 diagram from Toyota’s then chairman Fujio Cho.  The majority of the 45 page Lean Primer is devoted to explaining the house diagram.

At the top of the house is the goal of lean: deliver value fast.  The shorter the cycle-time the better.  This principle is fully transferrable to agile development which emphasizes getting working software into real user’s hands as fast as possible.   I love their metaphor of the lake and rocks.  “When the water is high (large batch or inventory size, or long-cycle time) many rocks are hidden.”

The first pillar “Respect for People” struck me as very analogous to a principle found in agile development where the manager is supports the team and allows individual engineers take ownership for their work.  In an agile world, a manager’s job is to remove obstacles, coach, and offer expertise.  It is not to micro-manage tasks and assignments, bury people in a storm of email, or unnecessarily tie them up with administrivia.  Similarly the sprint planning meeting, daily scrum meetings, and the end of sprint review replace the thrashing that can occur when requirements change in a world of big-bang releases.

The rightmost pillar of the Lean house is “Continuous Improvement” and encompasses several useful ideas.

  • Go see which reminds me of Management by Walking Around which I believe originated at HP.  In the world of software management I believe it means looking at code yourself and actively being involved in the process whether by writing small sections of code, testing, or pitching in wherever necessary.  For example, when he was at Microsoft Bill Gates was famous for actively participating in code reviews.
  • The 5 whys refers to the notion of considering the same challenging problem 5 times.  For example, why does the server keep crashing?  Often times it’s useful to visually represent the problem as a fishbone diagram.
  • The Sprint Retrospective is also highly compatible with the Continuous Improvement Pillar.  The Retrospective is an opportunity for the team to discuss what went well, not so well, and what would be done differently.  In the Army we used to call this the After Action Review.

The center pillar refers to a number of familiar concepts broadly categorized in terms of Product Development and the 14 Principles.

  • Several of the product development bullets relate to the notion of leaders that build great teams that passionately care about the products that they build, the people they work with, the customers that use the products, and are grounded in a sense of purpose.  In my view this type of leadership cannot be taught – your either have it or you don’t.  Great teams, however, can be nurtured by senior management that is committed to a people-centric culture – employees and customers.
  • The technique of having a team room and visual management is one that I have found to be particularly effective.  The notion of having visual artifacts such as progress on a burn down list, the organization of database tables, or the layout of a user experience is consistently valuable in terms of communicating understanding.
  • Cadence is the heart-beat of a regular software development life-cycle.  “People appreciate or want rhythms in their lives and work.”  Timeboxing work into short cycles where a reasonable amount of work can be done well is in my mind the equivalent of an agile sprint.

Toyota’s immense historical success using “Lean” development methods validates much of what software developers embracing agile methods have believed for some time.  The Lean Primer is a very worthwhile read and is highly recommended.