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.



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).

Software Engineering Revisited

August 31, 2009

A friend of mine from college recently sent me this article by Tom DeMarco (co-author of classic book Peopleware) about rethinking the importance of controlling projects.

Some of the more relevant passages:

  • I’m suggesting that first we need to select projects where precise control won’t matter so much. Then we need to reduce our expectations for exactly how much we’re going to be able to control them, no matter how assiduously we apply ourselves to control.
  • Your job is to go about the project incrementally, adding pieces to the whole in the order of their relative value, and doing integration  and documentation and acceptance testing incrementally as you go.
  • I still believe it makes excellent sense to engineer software. But that isn’t exactly what software engineering has come to mean. The term encompasses a specific set of disciplines including defined process, inspections and walkthroughs, requirements engineering, traceability matrices, metrics, precise quality control, rigorous planning and tracking, and coding and documentation standards. All these strive for consistency of practice and predictability.

If I read this correctly Mr. Demarco is accepting that there is a class of software that can evolve incrementally with minimal downside.  When Controlling Software Projects was written in 1982 they way software was written was very different.  There was an Internet but it was a very different place.  Software was invariably written, tested, and shipped mostly on diskettes and tape.  Today with the advent of the web all but the most isolated systems can be updated on the web.  This means that the price to patch software is much lower.  This obviously works very well for web-delivered applications where the customer typically does not need to install anything.  Indeed there are a class of applications (safety critical, analysis, machine control to name a few) where the old way still makes sense.

Moreover, the development tools (Visual Studio, Eclipse) and languages (C#, Rails) we have at our disposal today are much richer than what was available 27 years ago.  The reality is that object-oriented programming has fully taken hold.  For example, I can query query a database, apply business logic, and bind the results to a page today in an order of magnitude less time than it would have taken in 1982.  The reason its so much easier is that all of the components to do the plumbing have already been built for me.

I am personally a big fan of Agile, however, I’ve seen a tendency to cut corners particularly on the documentation end in the name of expediency.  Its always a good idea to get alignment between the developer and business owner.  That doesn’t mean that a 50 page specification needs to be written but there should be that contract.  I’ve seen business requirements be captured well in PowerPoints, emails, and photos of white-boards.