Do it right, then Do the Right thing online

I was at the Nordic Developer Conference (NDC) in Oslo last week (well, me and about 1700 other people!). I took a risk, I spoke to the title “Do things right and then do the right thing” (now on SlideShare). I was deliberately challenging accepted management practice.

In many ways this was an experiment itself, the presentation is based on a feeling I’ve had for a few years now - dating back to the Alignment Trap - but never really sat down to argue in full. In part I was looking for people in Oslo to shoot down my argument - or support it! I’m glad to say that so far most of the comments I’ve had have been broadly supportive.

Basically my argument is this:

• It is incredibly difficult to know “the right thing”
• Therefore it is better to try something, get feedback (data etc.) and adjust ones aim; and repeat
• However, in order to do this one needs an effective delivery machine
• In other words: you need to be able to iterate.

Thus organizations need to “do things right” (be able to iterate rapidly) and then they can home in on the ultimate “right thing.”

I used the analogy of using of trying to hit a target with a gun. First you shoot, then you use what you learned to adjust your aim and shoot again. Again you use the feedback to refine your aim.

You might choose to use a machine gun, rapid fire, rapid feedback. Cover the target in approximate shots.

Alternatively you might use a sniper rifle. One perfectly aimed shot and bang! Hit first time.

While I’m sure many organizations would like to think they are using a snipers rifle (one bullet is cheaper than many) I’d suggest that many are actually using something with significantly poorer performance. An older weapon, one without sharp shooter sights, on which requires manual reloading, one which is prone to breaking.

As a result they try to make every shot count but they just aren’t very good at it.

While one might like to think that organizations make a rational choice between these different approaches I think it is more a question of history - or path dependency to use the economic term. You use the weapon you have used before. You use the weapon which your tools provide for.

I’m not saying this argument is universally true but I think it increasingly looks like the logical conclusion of Agile, Scrum and Lean Start-Up. I am also saying you need to try many times.

In technology our tools have changed: when teams worked with Cobol on OS/360 making every shot from your 1880 vintage gun count was important. But for teams working with newer technologies - especially the likes of Ruby, PHP and such on the web - then a trial and error approach might well be the best way.

Possibly the right answer is nothing to do with your organisation but rather a question of your competitors. You want to choose a weapon which will allow you to out compete the competitor, perhaps through asymmetric competition.

Of course the key to doing this is to work fast, and fail fast, and fail cheap. If you take a long time to fail, or if it is expensive then this technique isn’t going to work.

After the presentation Henrik Ebbeskog sent me this blog post via twitter which is beautiful example of exactly what I’m talking about: You Are Solving The Wrong Problem.

Then I went to the PAM Summit conference in Krakow were James Archer included a wonderful quote in his presentation:

“Faced with the choice between changing one's mind and proving that there is no need to do so, almost everyone gets busy on the proof.” economist JK Galbarith.

This adds another dimension to my hypothesis: that when we invest a lot of time, energy and/or money in detraining what the “right thing” to do it it becomes more difficult to change our mind.

For example, suppose we invest a lot in building a new feature on our website, and suppose that in the week after launch the new feature performs poorly, or at least less well than other recent new features. Those who have invested a lot in arguing for the feature, those who feel closely associated with the feature may be more prone to say “Give it another week, lets get more data” while those who are more distant might be prepared to review what is happening sooner.

In order to accept “failure” we cannot invest too much of ourselves in any feature, shot or attempt.

I’m still not completely convinced by my own argument. The management doctrine “Do the right thing, then do it right” is so strong in me - and so logical. Although I can build reasonable argument for “Do it right, then do the right thing” that I’m still uncertain that I believe it.

What do you think?

Truly, I’d love to have more comments on this.

A role for project managers and business analysts in Agile?

I was in Krakow last week at the PAM Summit of the Project Management Institute (PMI) and International Institute of Business Analysts (IIBA). I delivered a presentation entitled “Is there a role for Project Managers and Business Analysts in Agile?” - now online via SlideShare. Those of you in the London area can go even better, I’ll be repeating the presentation at Skills Matter next week. (Its free, its 6.30pm on the 24 June, sign-up on the Skills Matter website.)

For those who can’t I’ll talk through the question a little...

It is helpful to reference the “Iron Triangle” or “Triangle of Constraints” or “Project Constraints Triangle” - call it what you will, here it is again:

Many reader may have seen a slightly different version before. My version has neither cost or quality because I don’t believe these represent trade-offs:

• Cost for a software development team are overwhelmingly wages, the more people you have, the longer you have them for the more money you spend. So Cost= People x Time. And people and time are both on this triangle so you can calculate cost, or vice versa.

• Quality is Free as Philip Crosby said, or to quote Capers Jones: “Projects with low defect potentials and high defect removal efficiency also have the shortest schedules, lowest costs and best customer satisfaction levels.” If you compromise on quality (and by quality I mean specifically bugs, things requiring rework) then it takes longer, costs go up and customers are less happy. If you want a fast delivery then push quality to the max.

So my preferred version looks like this:

Which leaves Features/Functionality/“the what” as the only place where we negotiate.

Which makes answering the original question very easy for BAs. Business Analysts have skills around exactly this question. There are a number of ways a BA can help: perhaps as a proxy customer, perhaps as a Tactical Product Owner, perhaps as a detail guy, or perhaps working with testers. Every team should have one (almost).

For project managers things are decidedly more complex. Much of their traditional work around “when” is redundant, since we are aiming for stable teams and sizing work to the time work around “who” is also gone. I can imagine, indeed I have seen, small teams dispense with project managers entirely. You can be successful without a project manager.

However for larger teams there is probably a role that needs filling. At a very basic level there is administration and reporting, there might be co-ordination tasks too, they might work with the BA/Product Owner around stakeholders, and when there is a client/supplier relationship both sides will probably want some managers “managing” the relationship.

But while there is management work to do I do not see a role for “projects.”

Successful software lives, it changes, if requires enhancements, adaptations. Only dead - unused - software doesn’t change. Developing a software product is like building a company: if people stop asking for things you are out of business.

Which conflicts with the PRINCE-2 definition of a project: “A temporary organization that is needed to produce a unique and predefined outcome or result at a pre-specified time using predetermined resources.”

Successful software does not have a pre-specified end date, indeed it can be incredibly hard to determine when many projects actually began!

Successful software isn’t temporary and the organizations which support/service it shouldn’t be. They may grown or shrink with time but we should aim for stability.

And since Agile embraces change the outcome isn’t pre-defined either. Indeed since all successful software changes in ways which are difficult for the originators to see there are only short term outcomes.

To me it is obvious that software development does not, and never really has, conformed to the project metaphor. Indeed I think using the project metaphor seriously damages software:

• It leads to endless, pointless, discussions about “when will it be done”
• It leads to governance processes that attempt to finish things which are not finished
• It leads to short term thinking over things like quality
• It leads companies to disband successful, performing teams - a condition I have termed Corporate Psychopahy.

BAU - business as usual - isn’t a dirty word, it is the normal. Supporting software, adding feature, fixing bugs, enhancing products is Business As Usual, we should be proud of that.

Then if we specifically look at Agile ways of working many of the traditional assumptions of project management are invalidated:

• Teams are encouraged to self-manage: determine the details of the work to be done and decide how best to tackle it themselves
• Agile teams are inclusive and non-hierarchical
• Agile teams communicate peer-to-peer rather through some centralised communications hub (i.e. a manager)

In short Agile assume a “Theory Y” way of working not the “Theory X” which is implicit in too many project management texts.

And if you think I am radical then let me tell you I am a moderate, there are those who will go further. Look at my Scrum-Scrum-Scrum post last year and the discussion which followed, or watch Christin Gorman’s video “Adding a project manager to a Scrum team is like making cake with mayonnaise.”

The net upshot of all this is simple: Project Managers need to reinvent their role. And the reinvented role probably doesn’t include the word “project”.

For any software development team - especially one that wishes to be considered agile - the default choice is probably: no project manager. The onus is on the role holder to demonstrate how they add value to the team and to the wider organisation.

The real lessons of Lego (for software)

How many out there have hear this: “What we want is software which is like Lego, that way we can snap together the pieces we need to build whatever it is we want.”

Yes? Heard that?

Lets leave aside the fact that software is a damn sight more complex than small plastic bricks, lets leave aside too the fact that Lego makes a fine kids toy but on the whole we don’t use it to build anything we use at work (like a car, bridge or house), and lets pretend these people have a point….

We start with the standard Lego brick:

Of course there are multiple colours:

And a few variations:

Which now allows us to snap together a useful wall:

Walls are good but to build anything more interesting we need some more pieces, maybe some flat pieces:

Or some thinner pieces, or some bigger pieces:

It might also help to have some angled pieces, you know for roofs and things, and remember the slant can go either way, up or down:

I think we’re heading for a house so we will need some doors and windows:

Personally I like wheels, I like things to move, and so do my kids. So we need some wheels - different size of course, and some means of attaching them to the other Lego blocks:

If we are building a car we need to be able to see out….

Umm… my imagination is running away, we need to steer, and how about a helicopter, and a ramp to load things onto the car/boat/plane/.…

Still, something missing…. people!

Lego is not homogenous, when you say “Lego brick software” people are probably thinking of the first 2x8 block I showed. But to make anything really interesting you need lots of other bits. Some of those bits have very specific uses.

I’ve not even started on Lego Space/StarWars, Harry Potter Lego or what ever this years theme is. Things get really super interesting when you get to Technical Lego.

But there are some things that every Lego enthusiast knows:

• You regularly feel the need for some special part which doesn’t exist
• You never have enough of some parts
• You always make compromises in your design to work with the parts you have

The components themselves are less important than the interface.  The interface stays consistent even as the blocks change.  And over the years the interface has changed, sure the 2x4 brick is the same but some interfaces (e.g. wheels with metal pieces) have been removed (or deprecated?) while others have been added.  There is an element of commonality but the interface has been allowed to evolve.

So the next time someone says: “We need software like Lego bricks” remind them of these points.