Agile and the Three Rules of Leadership

Early in my career I was taught the three rules of leadership by someone I respected very much. I won’t tell you who because it does not really matter.  And I can tell you I am fairly sure they are paraphrased from some other original source so I can’t give credit where credit is due.  But in any case here they are:

1)      Never give an order that can’t be followed

2)      Never give an order that won’t be followed

3)      Decide, decide, decide

Ever since I learned these rules I’ve tried to follow them when managing my teams.  First as part of the Waterfall process and then as part of Agile.  So, what do these rules mean and what do they have to do with the Agile SDLC?  I think that they are relevant to Agile when you look at these three rules in juxtaposition to the traditional Waterfall methodology being practiced in so many big corporate entities.

When you decide that a project is going to be run to a predetermined timeline with a “do or die” deadline in the end, you most certainly violate the first rule.  You are, in effect giving an order that can’t be followed.  This is a very common practice in waterfall.  A decision is made on how long a project should take, or more often a business stakeholder commits your team to a timeline based on some external event (conference, board meeting, sales cycle, etc.) and then the PM creates a project plan and the resources and tasks are backfilled to meet the expected timeline.  The problem with this approach is that it does not actually have anything to do with reality.  Even when you take the time to do all of the requisite  documentation from the PIMBOC point of view ( Business Requirement Document – BRD, Functional Specification Document – FSD, Detailed Design Document – DDD, etc.) you are still not dealing with reality.  Because all of your carefully thought out and meticulously written documentation will, at best, represent a snapshot in time and technology and will be about what the client or internal customer thinks they want.  In reality, what the owner of the application needs is not what they tell you they want, or in some cases what they tell you they want is not what they really, really want.  What?  Yes, the problem is that they don’t always have a complete understanding of what needs to be built or they don’t have a complete understanding of meaning and implications of what they ask you to build.  Agile, with its low volume of documentation and its emphasis of short iterative development sprints overcomes this by allowing us to really show the product owner what we’ve built early and often.  So that they, and you, can jointly determine if what you’ve built is what they actually instead of just what they asked for.

So how can you handle this kind of situation?  There are several approaches, so you will have to decide which one to tackle the problem with.

First, would be to go pure agile. Take each task a sprint at a time, plan your stories and get a good backlog going.  If you understand the ultimate deliverable your team is being asked for you can try to iterate your way.  This way when the expected timeline gets there you have the as many features as possible ready to go.   This approach works well if the product owner who is asking for this is willing to be flexible on the ultimate deliverable.  They get a product for their deadline, but they don’t have an absolute guarantee of what they are going to get.  They’ll get something, it will be good, but it won’t be complete. This approach has the greatest flexibility and allows for some iteration on features along the way

The second approach, which is more likely to be successful in an environment that is less mature in its adoption of Agile, is to compromise ahead of time on the deliverables.  In this approach you will need a good understanding of all of the features that are being asked for in the product you are developing, then the product owner would work through what the relative priority of each feature is.  I say relative priority instead of absolute priority because reaching absolute priority is going to be much, much more difficult to do!  And Agile, at its most fundamental, is the practicing art of the doable.  In this case we define relative priority as categorizing each feature as “A, B or C” priority, and absolute priority as ordering each of the 100 features you’ve identified from 1 to 100.  While in a perfect world absolute priority would be preferable, from a development point of view, you are very unlikely to be able to get a product owner who can get to the ideal of an absolute priority sorted list.  With the relative priority list generally what you want to wind up with is; you get all of the “A’s” done, as many as possible of the “B’s” and everyone understands that anything on the “C” list will most likely not get done.   In this model the product owner knows exactly what they are going to get which allows them to plan better for their big event.  The down side is that you probably won’t get an opportunity to iterate on a feature, what you do get is the opportunity to change the next feature before you start it, based on the results of the last feature that was developed.  This allows for changes in direction and approach along the way, while still affording the product owner a sense of security about what will be delivered in the time allocated.

The third is always the easiest to explain but the hardest to actually get everyone to agree to.  Just change the damned date!  But good luck with that one.

The second rule of leadership is all about getting buy-in from your team.  Because the last thing you want to do as a leader is order people to do something they will be unwilling to do.  This instantly destroys you credibility as a leader and creates a very unhappy workplace for you and your team.  So how do you know if you’ve asked someone to do something they are just not going to do?  First, see rule one above.  Did you just put a date on a calendar and just say go hit it? If you’ve done this then you are probably giving an order that won’t be followed.  Secondly, read the facial expressions and body language of your team members when you are asking them to accomplish a difficult task.  Look for that buy-in on their expressions on their faces, in the way that they hold their arms or in the way that they look away from you or what you are presenting.  Look for level of interest, are they asking questions and reading what you are handing out or presenting?  If they are not then they have checked out and you are asking them to do something they are not willing to do for you.

Thirdly, and most simply, ask your team if they think what you’ve asked them to do is actually doable.  I’ve often found that if you just ask people if they can do a difficult thing they will surprise you with what they can get done.  This third option is probably the best of the three because in this case you are not actually giving an order.  You are allowing people to set the limits of what they think they can and cannot do.  I literally can’t count the number of times I’ve been surprised by the level of commitment and effort people are willing to sign up for if you let them do it for themselves.  Often way above and beyond what I would have asked for if I had been telling them what to do.  This is also the essence of Agile.  The group commitment, the concept that everyone is a leader and able to contribute in equal parts.  The sense that we are all responsible, together, for the creation of beautiful software.  When you compare this to unrealistic project plans of waterfall, where the developers are treated as just another line item resource and their contributions to the project are boil down to one line task descriptions and milestones is it any wonder that Agile is being adopted by so many successful software development teams?

The Third Rule of Leadership, while seemingly the simplest, is actually the most difficult.  You can argue that all of the requirement gathering and documentation are deciding, but you would be wrong.  What “Decide, Decide, Decide” actually means is just get started!  The problem with the PIMBOC/Waterfall approach is that the lead time to starting a project is huge.  I’ve participated in some requirements gathering efforts that take close to a year to accomplish and in many more that are just shy of the six month mark.  With Agile the emphasis is on rapid starts, on getting hands on keyboards coding now!  Not six months or a year from now when a vital opportunity to succeed has passed you by or when a competitor has leapfrogged you to the market.  In Agile you start coding fast, with little documentation burden and an emphasis on understanding what the client/product/project needs, that Minimum Viable Product I spoke about in an earlier entry, not just on what someone is telling you they want in a set of static functional specifications.  So “Decide” to start development, “Decide” to produce a viable product quickly and “Decide” to be the team that takes the opportunity to succeed and leapfrog the competition.

So drop me a line if you have any questions, happy to answer them as I get the opportunity.