Agile

[responsivevoice_button voice=”UK English Female” buttontext=”Listen to Post”]

Hierarchy, it is one of those topics which provokes a reaction.

There are many in the agile community who believe hierarchy is a bad thing. Teams – and whole organizations are better off without hierarchy. It is simply(!) a case of finding better ways of organizing which don’t involve hierarchy.

Then there are those who acknowledge that hierarchy has been with us for millennia and find it hard to imagine how anyone could organise without it.

As a general rule the supporters of agile come down against hierarchy. I’ve been known to rail against hierarchy myself but at the same time I’ve long had my doubts that it is possible to remove hierarchy altogether. Rather I aim for less hierarchy and greater independence rather than the abolition of all hierarchy. I tend to keep this view to myself because a) it is subtle and b) I suspect I’ll loose a lot of agile street cred if people know.

So when I heard about a book called Hierarchy by John Child I immediately bought a copy. This is no easy read – Child is a Professor and so the style is academic rather than pop-psychology business blockbuster. So far I’m about half way through but the book raises many interested point that I’m still thinking through.

In particular Child highlights a number of benefits of hierarchy which deserve attention and I think are too often overlooked. Right now I want to capture my thoughts so far before I get into the arguments against hierarchy. So…

The benefits of hierarchy to an organization:

• Hierarchy has benefits were there is regulation
• Hierarchy helps large enterprises bring structure to their activities
• Hierarchy tend to develop in all societies whether they are intended or not, therefore imposing a hierarchy gives an organization a chance both to impose the order they want – and choose the leaders – and rather than accepting the hierarchy and leaders that emerge.
• Hierarchy allows for succession planning
• Reduce illegal behaviour: maybe not a big issue in your twenty-first century office but this can be an issue. It can also be a particular issue when people rise to the top of a hierarchy and find the organizational controls they had before are gone: they have nobody to report to. Could this explain some of the sexual and business mis-conduct that has been in the media in recent times?

Benefits to the individual:

• Hierarchy creates psychological safety, individuals know where they fit in and what is expected of them. They know who they need to pay attention to.
• Hierarchy reduces cognitive load and fear, in part because of the psychological safety it creates.
• Hierarchy provides a career model: people know what advancement in the organization looks like and those who want advancement can map out a course to achieve that.

Benefits to a team:

• Hierarchy creates clear areas of responsibility which enables team members and creates focus within the team.
• Hierarchy provides team members with a structures and helps them accept their position. On the whole people are accepting of hierarchy and accept the position. (Perhaps because they also know how they can advance their position.)
• Hierarchy allows a mix of strong and weak personalities to work together. While hierarchy can be used by powerful formal leads to suppress weaker staff hierarchy cuts both ways. Team decision making can be improved when hierarchy facilities equitable discussion between strong personalities.
• Formal hierarchy, with formal leaders, actually puts a responsibility on the leaders to ensure balance and allow weaker personalities to have their say. (While this can be abused when it is abused it should be clear to all concerned that the leader is not upholding their part of the bargain.)
• In a recognised hierarchy the senior people have a responsibility to moderate and listen to all. Where there is no hierarchy few may feel that responsibility and a single strong voice may dominate the weak.
• Where there is no hierarchy and multiple strong personalities the result can be conflict and disagreement. Without the hierarchy it can be hard to resolve such problems.
• Hierarchy provides for decision makers, perhaps one, perhaps more. Having recognised decision makers can make for rapid decisions: people know who to go to and that person knows they have responsibility. Conversely, where decisions are made by consensus decision making can be slow or absent entirely.

Recently I observed a team which made most decisions by consensus. But as one strong personality rarely agreed with the others any decision they didn’t agree with became a battle field. Most team members kept quiet and nothing changed. Sometimes another strong personality would try and force the decision through but this was usually unsuccessful. Only when several other team members were prepared to take sides. As a result consensus became a recipe for not changing.

Of these arguments the ones I find most interesting are those which concern the emergence of social hierarchy. I’ve certainly seen this – even in organizations with a formal hierarchy. Emergent leadership and hierarchy can be a good thing. They can also be a bad thing.

I can immediately think of several teams I’ve worked with were one of the developers – sometimes a relatively junior one at that – emerge as leaders and the team adopted a hierarchy oriented towards that leader. On one occasion that leader was me and I like to think I brought an order and structure which was beneficial. But I’ve seen other occasions were the leader who emerged was at odds with others in the organization with the result of tension.

I expect the idea of emergent hierarchy is immediately recognisable to those schooled in emergent design and behaviour. The question becomes: should organizations accept this? Or should they try to guide it?

In the extreme should an organization fight an emergent hierarchy which conflicts with the aims and goals of the organization? And is it worth the effort?

So far I have more questions than answers. I haven’t suddenly become an advocate for hierarchy but I now recognised this is not a one sided discussion. I plan to write another blog when I get to the end of the book and have had a chance to think through the for and against arguments.

In the meantime I’d love to hear your thoughts and comments, just add them below.

---

Like this post? – Like to receive these posts by e-mail?

Subscribe to my newsletter & receive a free eBook “Xanpan: Team Centric Agile Software Development”

[responsivevoice_button voice=”UK English Female” buttontext=”Listen to Post”]

“Planning has rapidly diminishing returns: plan less, do more, learn more, redesign governance to kill early and often.”

Happy new year! – There is always a special responsibility that comes with the first blog post of a new year. Fortunately Tom Cagley of SpamCast fame asked me a fantasy question:

If there is one piece of advice you would give to CxO executives what would it be?

There is plenty of advice I’d like to give them, but one piece of advice?

One piece of advice which is generic and cuts across industry upon industry. One piece of advice for all those companies I know nothing about.

Tough. When I eventually came up with my answer I knew I’d have to explain it.

I had to think long and hard. I knew immediately that it would be something on the continuous digital theme. (One piece of advice for budding authors: don’t write long books, I knew this already then I mistakenly wrote Continuous Digital, that should have been four books.)

Eventually I came up with this:

“Planning has rapidly diminishing returns: plan less, do more, learn more, redesign governance to kill early and often.”

I believe this is universally true. Plan anything for long enough and you will eventually plan your way out of doing anything. When I run my Extended XP Game I regularly see teams plan their way out of good approaches to work.

Some planning adds a lot of value. But the rate of learning slows and continues to slow. At some point you aren’t learning more at all, and sometime after that your learning is counter productive. As economists say: there are diminishing returns on the investment.

A little planning adds a lot of value. But each extra minute of planning adds less value than the previous minute. Plan a little, do a little.

In our modern technology driven world two factors make this especially true.

One: learning by doing is faster with modern technology

Technology has advanced: Moore’s Law means I have over 100 times as much power in my MacBook Air as I did in the 6502 BBC Micro I learned to program on in the 1980s. That in turn had more power than the IBM Mainframes of the late 1960s.

That means our tools are more powerful: the Python I programme in today isn’t the most powerful language but it is a damn site more powerful than 6502 assembler and BBC Basic. Add open source libraries and that Python is immensely more powerful than writing in 1960s COBOL.

As a result things that tool months or years to create take hours and days. A week of planning for a OS/360 COBOL program that will take 6 months to write makes sense. A week of planning for a Python program I’ll have running in the cloud by the end of next week doesn’t.

And when I say planning I mean all aspect of planning: research, requirements, schedules, architecture designs and the rest.

Sure a bit of planning makes complete sense. I would be stupid not to make a coffee and think about what I was about to do. But planning is all about learning, is about experiencing the future a little bit. The power of our tools today means that future is a lot closer, and the most rapid way to learn about it is to create it.

Once I reach that future it makes sense to stop, review and plan again. The quickest way to learn is to alternate thinking (that is “planning”) and action (learning by doing.) Do something, see what works, then take time to reflect and learn.

Doing is learning too. The question at any given point is: what is the fastest way to learn? In the beginning that is planning, very soon doing becomes faster.

Two: cost of delay changes everything

Once you appreciate cost of delay you see the world differently (If you don’t know cost of delay look at my Time-Value profiles (Look at my article in Agile Connection or read Don Reinertsen’s Principles of Product Development Flow.)

Now remember: planning time is time, planning delays launch. Keep planning, analysing, talking to potential customers, drawing imaginary project plans or perfecting your architecture (before you start building) all delays the time you will get a product into the market.

That delay is bad because it increases risk: until your product is in the market you are at risk of creating a product nobody wants, or at least nobody will pay for.

That delay means your product will earn less money – thats cost of delay. Potential customers may have found other solutions, competitors may have got there first, or technology advances may render your product obsolete.

Lets be straight: I’m not saying No Planning. A little planning can be really really useful and valuable. So please plan!

What I am saying is: plan a little, do a little. Repeat.

Then stop, reflect, evaluate, and plan a little more before you do a bit. Alternate planning and doing. I’m not original in saying that, the Shewhart cycle (i.e. the Deming cycle or PDCA), says the same and so do half a dozen other approaches.

The problem is: many executives have been taught to plan plan plan. Nobody ever gets in trouble for planning too much and most failures can be traced back to a failure to plan more if you try hard enough. Ultimately, if you plan enough you will never have any failures because you will never do anything.

Which brings me to the last part of that executive advice: “redesign governance to kill early and often.”

Organizational governance is overwhelmingly based on the assumption that we know what we are doing. Only things that are very well understood will be allowed to start. That incentivises people to plan plan plan. And when something does get started there is a bias against closing it down (inertia and commitment escalation).

That needs to change. Since we can’t know in advance we need to be able to react once work is in flight.

Organizations need to be prepared to start work where the outcome is vague. Governance then needs to kill initiatives which aren’t showing promise. Put it another way: the early stage gates need less rigorous and the later ones more rigourous. If governance isn’t killing initiatives often then either governance isn’t working or you aren’t taking enough risk.

---

Like this post? – Like to receive these posts by e-mail?

Subscribe to my newsletter & receive a free eBook “Xanpan: Team Centric Agile Software Development”

To coincide with my new book, The Art of Agile Product Ownership, I’ve written a post which appears on the publishers website: Four Things Every Product Owner Needs.

[responsivevoice_button voice=”UK English Female” buttontext=”Listen to Post”]

Some years ago I was managing a team at an internet TV pioneer. Shortly after a release our biggest customer – ITV – was on the phone complaining about a bug. Unfortunately one set of data fields were retaining their value when they should be wiped clear. It took a couple of months before we could include a fix in the release but we were confident we would make ITV happy.

A couple of hours after the fix went live ITV were on the phone. Why had we removed the daily cache? They weren’t just “working around” the bug, they were utilising it as a feature.

Sometimes it seems the problem you think you are dealing with isn’t the problem you are dealing with. Sometimes the way to solve a problem is not to fix the problem head on. Rather the solution comes from reframing the problem so that it is easier to solve. To put it another way: the problem you are trying to solve is knowing the problem you are trying to solve.

I sometimes think of this as “go and look at it from a different place”. Whatever you are looking at – problem, opportunity, objective, way of life – looks different if you go and stand somewhere else. The more different the place you stand in the more different the thing looks.

Clearly one way of solving a problem is to define it as not a problem: “it is not a bug, it is a feature.” As the story above shows, one person’s “bug” can be another person’s “feature.”

The question is then: is the reframing acceptable to others? – can others share the reframed perspective?

By way of example, lets apply this to agile.

A big part of agile is focus: small user stories, morning stand-ups and sprint planning all help create focus. Once you decide what you are going to tackle you focus on it, push other things out of the way and do it. And do it to completion.

You might call this “eating the elephant”: don’t eat it all at once, carve off a small piece, eat and repeat.

Pushed to either extreme this approach has bad side effects. Focus too tightly or too inflexibility and you might deliver a thing but not a thing which others recognise as a solution to the problem. But taking a view too broadly, or being very flexible, negates the way of working because you don’t deliver anything, – or the solution you deliver doesn’t please anyone (the “you can’t please all the people all the time” problem.)

Reframing can be a powerful technique but it can also work against you if other’s reframe the problem.

So, how do you know, or rather how do you frame and decide what your objective is?

Deciding what the problem is requires some imagination, it requires focus and flexibility – to stare at the problem but be flexible in how you see it. It also requires understanding and then the ability to communicate that understanding to others.

While I often hear people say “we should focus on the problem” I wish we could spend more time focusing on the problem of knowing what the problem is.

Reframing the problem is an inherently human thing. While machines may now, or in the near future, be able to solve many problems there is a problem of knowing what problem to present to the machine.

A big part of human work – often managerial work – is framing problems and deciding which to solve and which not to solve. Framing can make a small problem big, or a big problem small. That is inherently a human activity.

So, how do you know what problems to address? how do you know where to look for opportunities?

Now isn’t that a problem in itself? – surely we could set that up as an objective in its own right. Again it needs defining and framing and… So how does one decide to eat an elephant? And which elephant? And even, why eat an elephant at all?

It all becomes recursive. You can’t recurse for ever so hopefully sooner or later you need to come to the top – otherwise you have just reinvented paralysis by analysis. Detailed problem thinking needs to be combined with vaguer, even oblique, thinking.

To make this very real: I’m a big fan of metrics, they help focus, they help you know if you are going in the right direction. But I detest metrics too because they are a blunt instrument which can mislead so easily.

Metrics are great for focus but they need to be combined with a healthy dose of scepticism and oblique thinking. Metrics have limitations.

Sorry no solutions today. Just awareness of the problem of problems.

---

Like this post? – Like to receive these posts by e-mail?

Subscribe to my newsletter & receive a free eBook “Xanpan: Team Centric Agile Software Development”

Check out my latest books – Continuous Digital and Project Myopia – and the Project Myopia audio edition

[responsivevoice_button voice=”UK English Female” buttontext=”Listen to Post”]

Those of us who don’t code any more, and perhaps many of those who do, need Electronic Monks to help us with software development.

There is an old Douglas Adam’s book (Dirk Gently’s Holistic Detective Agency) which features an Electric Monk. The job of an electric monk is to believe things for you. In Adam’s story people have too many things to believe so they offload all that believing to an electric monk. In my mind I’ve always considered part of the monk’s work to include worrying. I can’t remember if Adam’s says this explicitly or just implies it. (And as I no longer have a copy of the book I can’t check.)

I’m currently very engaged with one client as an Agile Coach (although I sometimes wonder if “Shadow Manager” might be a better term, more of that another day). I regularly find myself staring at the board thinking about the work it shows and worrying about whether it will be done. Sometimes my mind plays “what if games” – “If that card is finished soon, then the other one could move down and…”

The same worry plays out when looking at the backlog showing work not on the board. Or when I’m talking to the Product Owner. Or indeed when I find myself talking to middle managers and others in the company who have an interest in the work the team is doing.

Basically, there is very little any of us can do to move the work through.

Sure I can call a meeting and talk about optimising our workflow. But I’ve done that a few times already.

I could call a meeting and emphasis how important the work is to the company. I’ve seen this done many times. Some non-coders – call them “the business” – seem to think “If only the coders appreciated how important this work was then they would do it faster.” I hated this when I was a coder and I hate it when I hear others saying things like “Do they know how important this is?” Business folk sometimes seem to believe coders sit around drinking tea and coffee for most of the day.

By the way, I almost wrote “and Testers” in that last paragraph but then realised testers CAN make work go faster: they can just drop their standards, turn a blind eye to issues, accept things they wouldn’t have accepted last week. Piling pressure on Testers is a more effective route to getting work done than pressuring coders. But in both cases it is probably just piling up more work.

Pressuring people to do work faster usually creates problems which come a back and bite you pretty damn quick. As I’ve said before: There is no such thing as “Quick and Dirty” … “Quick and Dirty” actually means “Slow and Dirty”

I could go to the coders and ask “Are you done yet?” – or as 5-year olds say in the back of a car on a long journey (or just any journey) “Are we there yet?” In both cases it doesn’t change the time it takes to get to the end, the answer doesn’t usually say much but asking the question will annoy parents and coders alike.

But if I do anything – like calling a meeting or asking “are we there yet?” – which involves distracting coders from working then I am slowing work down. It is self-defeating.

Yes there are things I can do to make work go more smoothly but once a piece of work is in flight there is little I can do. Most of the change I can make are to do with the way work happens. Or to put it another way: I can influence the climate work happens in but I can’t control the individual weather events which are the work items.

All I can do is worry. Thus my desire to offload that worrying to an electronic monk. Maybe more people in and around software developerment need to recognise they are in the same position.

---

Like this post? – Like to receive these posts by e-mail?

Subscribe to my newsletter & receive a free eBook “Xanpan: Team Centric Agile Software Development”

Check out my latest books – Continuous Digital and Project Myopia – and the Project Myopia audio edition