Sharing In The Risk….

Over the last 48 hours, I’ve been engaged in some #NoEstimates conversations.   A tweet this yesterday evening re- introduced a very interesting dimension to the conversation (at least in my opinion).

What risks are we possibly concerned about here?  I can think of two related to the actual process of software development and one related to the people actually doing it, so in all 3 major risks (even though I wouldn’t be surprised if there are others):

  1. Risk of team not developing the right thing
  2. Risk of team not delivering on time
  3. Risk of team not doing their best

Getting It Right/Being On Time (Value 3, Principles 1 and 4 at least)

It is my experience that software development is largely non-deterministic and empirical.  YMMV.  (If this is not your experience, I’d love to hear about it and the software you develop). There is a significant amount of learning that occurs as the work is being done.  Just pull any developer off any team and ask if they “figure things out as they do the work?”.  I’ve been developing software long enough to remember a number of approaches to software development that tried to front-load learning via the use of documents and models of other forms.  We still found ourselves learning a lot as we actually typed lines of code.  We can debate ad nauseam as to whether our discovery process was broken and I imagine there are those who simply say that we should just get better at identifying and writing requirements. There may be some truth to that, but I’m positive it’s not the only way.

Agile as an approach to software development desires to exploit the uncertainty and learning that is inherent in software development. This post is not an Agile primer and yet a meaningful study of Agile methods/frameworks shows that the first two risks are actively being addressed all the time as the team works together to deliver working software.  Remember the team includes the paying customer.  They are part and parcel of managing the first two risks as we go along.  They are part of actually providing a solution.  If the customer is not heavily involved in the development of the solution, and yet wants a guarantee around the first two risks, then you may need another approach that lends itself to such an engagement – I’m not sure Agile is it?

So this puts us in the land of contracts.  By contracts I am referring to any agreement (verbal or written) on what is going to be delivered and when it is going to be delivered – think funding models as well.  When a team commits to delivering X scope in a period of Y, a contract has just been put in place.  The nature of the contracts ultimately impacts the behavior of your teams, which impacts how software is truly developed.  But we know contracts don’t guarantee results (think about all the prenup’s that have gone by the way side), they guarantee (maybe) a course of action when things go wrong. They can be an indicator of low trust.

This is an opportunity to go read up on what Agile contracts look like (there is no shortage of resources on this topic).  But the essence of many of them is that the buyer makes small bets while remaining part of the team.  Do they often bear a larger percentage of the risk? Possibly. They often reap a larger share of the reward as well.  What they don’t do is handoff a problem and say “see me when you’re done”.

If you thought that software development happens in a bubble, you were mistaken.  There are multiple organizational conditions that influence it directly and indirectly.  It’s not just something that those technology guys and gals are doing.  Agile software development is disruptive to the “normal” way of working. It requires the investor to be part of the team in some form or fashion.

Having a Committed Team (Principle #5)

Ok, so maybe I can leverage Agile contracts for work that is outsourced but what do we do when the team is part of our organization and is salaried?  We could be paying them and not getting results.  Well, this leads us to risk 3, the risk of the team not doing their best or to put it more bluntly, not being committed.  While we can definitely focus on getting the team to comply with internal contracts and similar instruments (such as threats), things are not often what they seem to be.  Metrics and efficiency numbers that show a team is “working hard”, “improving” or “getting faster” are not a true indicator of a teams commitment.  Maybe they are an indicator of compliance, maybe.  (If compliance is good enough for your organization – Agile is probably not a right fit). Leaders who are looking for what they deem to be “tangible” stuff should really be focused on how much value is being created and generated.

Here is a formula for committed teams: Hire great people, create cross-functional teams, give them meaningful work, share with them how their output as a team will make a difference, tell them about important dates and budget and then let them loose.  Support them by providing enabling conditions that allow them to excel.  Follow’s Drucker’s advice; see them more as volunteers than anything else.  This requires you to discard your Theory X approach to management.  It requires you to actually trust them – if they are committed they’ll share in the risk as well.

Manifestos and Things

Take a look at the Agile Manifesto (I’m sure you can find it).  If you look at it carefully you’ll see that this post has gone over some of the Agile values and principles.  This, to me, is what software development guided by the Agile Manifesto is all about. It’s not just about standups, backlogs and story points.  In fact, I consider those important but lesser.  It’s about a particular culture of developing software.  Any method that consistently demotivates or disempowers is not Agile. This is at the center of the #NoEstimates dialogue in my estimation (excuse the pun) – the culture of software development and hence the engagement models that arise as a result of the culture.  (Sidebar: I find myself continually saddened by Agile leaders in organizations and consultants who don’t get this and still claim to be leading Agile transformations.  They are doing more harm than good). Agile is not mandatory, it’s choice.

Conclusion

In Agile software development, the risk is shared and mitigated by everyone involved (including the investors) by working together in an Agile manner with a committed team.  This may or may not work for you – it does not however mean that it is not an option (or the only option).

Advertisements

About Ebenezer

culture hack. contrarian. change artiste. speaker. writer. silo-connector. entrepreneur. totally human. ff at your own risk. :-)
This entry was posted in Organizational Learning, Software Development and tagged , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s