I’ve been meaning to write about the managers and Agile software development for a long time. And, apart from a few asides, I haven’t.

Why not?

Well partly because the topic is difficult, or rather large, but mostly I’ve not written it because I’m fearful of the flames that will come down on me.

You see I think managers have a role to play in Agile, but I am acutely aware that many people don’t.

So am I steeling myself, I’d love to come up with a “grand theory of management” but I’ve been trying to do that for years! I think instead I’d start blogging about my thoughts on management, and hopefully a grand unified theory of management will emerge.

Still, I expect many people will not agree with me – there is one of them I can see right now, he’s almost standing in front of me. The funny thing is, I was a professional programmer, I got interested in management as a way of ensuring I didn’t become the type of poor manager I’d worked for.

I took time out of my programming career to study management. What nobody told me was that if you study management programmers are more suspicious of you than ever, non-developer management types will always see you as a programmer (perhaps a jumped up programmer) and programmers who have fallen into management (those with no qualification and probably no time to study the subject) don’t trust you. Add in the fact that the academic community is split over management qualifications and it’s a right mess.

Unfortunately managers and programmer are locked in a decades old existential fight.

Many on the management side of IT dream of a world where programmers can be replaced by a software tool. That isn’t going to happen, all it does it move the point at which the programming happens. If you replace a programmer with a software tool the person who uses the tool is now a programmer – whether you call them a programmer, analyst, consultant or serf.

On the other side programmers dream about replacing managers with “self organizing teams.”

Both sides want victory by proving the other need not exist – at which point they will disappear in a puff of smoke. (Sometimes it seem to be the old worker-capitalist class struggle.)

My logic is this:

• Management is a skill like any other, like writing Java or like writing test scripts
• Many people who find themselves managing don’t have the skill and some don’t bother to learn
• Consequently many “managers” aren’t actually very good at managing
• While there are a few “natural” managers – like there are natural Java developers(?) – one can learn to be a better manager

The state of management in the IT world is so bad that frequently removing the manager altogether makes things a better than they were.

Oh, and the misuse of the word “manager” doesn’t help.

The thing is…

I’m an ex-programmer, I still consider myself an engineer (another controversy) and I also think management can play a useful role in engineering software development.

It took me 10 years to become a software engineer and I never stopped learning, 34 years later I’m still learning to be a better programmer.

I also hold an MBA degree, it took me a year of hard work to get it.

1 year, not 10 years and certainly not 34 years.

Actually, it has taken three generations to make me an engineer: my farther was an engineer, and my grandfather too. I was going down engine rooms when I was 7 or 8, I’ve watched engines being overhauled. I know what being in dry dock means and I know commercial considerations and engineering considerations are often in conflict, but engineers not people in suits make it work.

Being an engineer and a manager is not a contradiction. I know that because my farther and grandfather were Chief Engineers: they took years to obtain that rank, and when they did they still went down the engine room, they still mucked in sometimes, but they also spent a lot of time “managing” the work in the engine room and on deck.

You see: it takes an engineer to manage engineering.

Summary

• The general quality of management in the IT world is poor
• Management itself is a skill, one which few take time to learn about
• Managing software engineering well requires one to understand software engineering: it takes and engineer to manage engineering

I’ve done a few agile introductions in my time, in fact I’ve started to feel I could almost write a book entitled “agile by numbers”. So yesterday when this question appeared on some LinkedIn group I thought I’d give it a quick go:

“I am working with an organization which wants to explore agile adoption. What are the some of the best ways for start the process. Is it to start with agile training and then help set up with an agile agile coach to take it forward ? Or first do an assessment to understand why they want to adopt agile and than suggest the best approach : if it’s scrum, Kanban or XP.”

My answer went something like this:

First, don’t get distracted by researchershing options, don’t worry about Scrum v. Kanban v. XP v. What-Ever. Just get on and do it. (Of course I should have plugged my own book and said “Do Xanpan!”)

1. Find someone you can trust who knows about this stuff (perhaps I should have said someone like me!)
2. Get them to give an 1 or 2 hour (max) talk to interest people
3. Ask the team leads if they would like to volunteer their team or upcoming work, then talk to the people who would be involved, choose/make a small self contained team (i.e. coders, testers, product person) (Note: if you only have one team then you can skip steps 2 and 3 because you are doing to work with this team.)
4. When you have found your guinea pigs give them a day or two of rehearsal (i.e. a training session where they get to practice what they do)
5. Start doing weekly iterations immediately: no waiting for “the right time”, start while things are fresh
6. Arrange for the person who gives the training session to come back each week, then throttle back to less often when the time is right
7. Engage a technical coach/trainer and after several iterations run some technical training (TDD or BDD, take your pick). Have this person come back for some one-on-one coaching (i.e. pair programming), allow one day per coder plus time with testers if you have them
8. See what happens, review, keep going, expand

I did notice that a few of the other replies recommended teams start with coaching rather than training. I’ve done it that way, in fact thats how all the early teams did it. I’ll also say that in my experience – and yes, I’m biased, I sell training – giving people some training up front works best. Perhaps thats because the way I do training is to give people a chance to experience working in an Agile setting in the classroom, so perhaps what I’m saying is: all training is not equal.

This little recipe takes you so far. I’ve stopped with the technical stuff. The process side will get you so far but if you don’t do the technical stuff – lots of automated testing! – then you will only go so far.

The other thing I haven’t said here at all is: this recipe is only for the supply side, once the supply side starts to shape up the focus needs to shift to the demand side, those people you call Product Owner, Business Analyst, Product Manager or something like that. Thats where it gets difficult, not because these people are themselves more difficult but because you are now wrestling with the wider organization and changing a bigger mindset.

Another problem that sets in here is that companies can loose the will to change. I’ve worked with a few companies who apply this prescription but they get so much improvement the immediate pain goes away and they loose the motivation to change further.

This prescription can very quickly makes things get better. But if you want the full benefit you need to keep taking the technical medicine and supplement it with demand side medicine too. Those changes take longer to make a improvement, they are a slow burn.

I sometimes come across teams who are wrapped up in discussing what they should be building. OK, I suppose this is because I hang out with too many management types. Sometimes there are only a couple of programmer, occasionally one, or maybe they haven’t got that far.

Sometimes I come across pre-teams, people who will form a team to do some work but haven’t started yet. I guess the project folk would call this “pre-project phase” and there is a lot of discussion: “Should we do Agile or Waterfall? Scrum or Kanban?” and “Which outsourcer will we use?” and “If we are agile how will we….”

In short these people are wrapped up in agonising about what might happen.

On these occasions I’m reminded of a story I once heard about the actors Laurence Olivier and Dustin Hoffman. In the story Hoffman, who is a famous method actor, says to Olivier something like:

“Mr Olivier, I am honoured to be working with you, but please tell me how do you learn you character? I mean do you use the method or some other approach? What should I do?”

To which Olivier says:

“My dear boy, … have you tried acting?”

This is what I feel, but usually don’t, to these teams, managers, analysts, whoever:

“Have you actually tried developing and delivering some software?”

Some planning, some forethought, some agonising is good. It helps you think things through. But it quickly becomes a game of diminishing returns. Its the old Eisenhower quote again:

“Plans are worthless, but planning is everything.”

Which is a natural follow on from Helmuth von Moltke’s observation:

“No plan survives contact with the enemy.”

Peter Drucker has a similar, though to my mind better, quote too:

“Plans are only good intentions unless they immediately degenerate into hard work.”

So let me say:

“No plan for software development survives contact with the code. (Double so for legacy code.)”

“No requirements roadmap ever survives contact with the market.”

(According to wikipedia the Olivier-Hoffman exchange happened during the filming of Marathon Man and isn’t exactly true but does contain a grain of truth.)

One of the reasons this blog has been quiet recently is that I’ve been putting my efforts into video: The #NoProjects Video series.

This is now available as 16 short episodes on YouTube based on my popular #NoProjects/Beyond Projects conference presentation. If you have seen the conference presentation you know what to expect although there are some changes. My hope is that by making the presentation available as 16 short (I think the longest episode is 5 minutes) pieces the argument will reach a wider audience.

There are a few questions I’ve been meaning to clarify about #NoProjects / Managing Without Projects and now is as good a time as ever:

Q: Isn’t “No” rather negative?

A: Yes it is, I’ve had a go at changing it but attempts so far haven’t caught the same feel. Perhaps this is because “No” is so definite or because “Beyond” is 4 characters more and 4 characters on Twitter is a big deal.

For a while I preferred the name “Beyond Projects”

Lately I’ve been calling it “Managing without Projects”

But perhaps “Software without Projects” might be better still, that would lend itself to the hashtag #SW2Prjs

Q: Is #NoProjects actually #NoEstimates?

A: No

The hashtags and ideas originate with different people. There are parallels and the ideas might be symbiotic but while I know some #NoEstimates people would like to see #NoProjects as part of the same idea I don’t.

Estimates are a complex area and right now its difficult to have a rational conversation about them – perhaps it was ever so. But, I still see value in “estimates” in some context. Its all a question of “What question are you really asking?” using estimates might help or it might now.

While most of the conversation on “estimates” implies “time estimates” there is another form of estimation: “value estimates”. These don’t get anywhere near enough attention or use. I use them and I help my clients use them but I don’t see them elsewhere very often.

I should expand on this another time.

Q: Does #NoProjects mean #NoManagement, aka “Self managing teams” ?

A: No – I have no argument with management itself. I have an argument with the concept of projects which I think leads to poor management of software development.

I see management as a skills, the same as Java, SQL, Testing or Analysts. Unfortunately very few people actively learn about management or try to master it as a skill in the same way they might Python or Java.

When they do try and learn “management skills” people often start with “project management.” I sometimes thing of “project management” as “management lite.”

As a result an awful lot of “management” of technology (specifically software development) is poor. In such conditions removing management (i.e. self management) can actually improve things.

Again, I should really write an extended piece on this subject.

Q: What about Project Managers?

A: I treat each and every Project Manager as an individual. They can bring valuable skills and experience to a team. Unfortunately many of them don’t and add little. In part this is because they are asked – both by their employer and their professional bodies – to manage using a model that is inappropriate to the software domain.

So I don’t see mass redundancies of project managers, rather I see the good ones being allowed to manage properly using a better model.

Q: Isn’t this a pretty radical position when so many companies revolve around the project model?

A: Yes, my hope is to get people to talk about the issues I raise. Even if companies don’t abandon the project model completely I hope they can get better by finding their own ways to address these issues.

Besides, I’m a consultant and I’m only too happy to talk about these issues myself and give advice. Just call me.

As a consultant few of my clients actively set out to become a NoProjects company and I don’t try and make them so. They and I want them to do better. I find that if I think in a NoProjects way I can understand the client better, and if they still have projects I can then map the ideas across.

This blog has been noticeably quieter than usual over the last couple of months, and whats more, when I have posted something up its often been of the “this is what I’m doing” type rather than the “here’s something to think about” type post. Well…

In the last few months I’ve been putting my energy into other mediums, hence A little book of requirements and user stories and the managing beyond projects workshop I’ve mentioned before – the dates for the workshop has moved back to January by the way.

The big news this week is that I am serialising my #NoProjects presentation as mini-videos on YouTube. Various conference videos are already online but this is a series of short videos, check out the Managing without Projects playlist. (There are 7 episodes so far, more coming soon.)

I also added a new newsletter earlier this month and I expect this will in future carry material which would have been in this blog otherwise. So if you want the latest, freshest stuff I suggest you subscribe to the newsletter.

And here is the piece that the newsletter carried at the start of this month….

What’s next? – after Agile?

As this is the first of my new, occasional, newsletter it seems a great chance to look to the future. So lets ask that question that comes up regularly:

“What comes after Agile?”

Sometimes only asked rhetorically by agilistas to prove they have the inside track on what is really happening!

I had a go at answering it myself a few years ago with a presentation entitled “The future of Agile”. To cut a-long-story-short, I thought the next thing would be Lean. Six and a bit years on I think I was right but perhaps not in the way I thought it might be. I saw Lean displacing Agile as the predominant approach to software development, or at least the buzzword. Well it hasn’t, Agile is still the buzzword it was.

But Lean has permeated more and more thinking on Agile. If you look at Agile almost every idea can be traced – in some cases literally in other case philosophically to Lean thinking. Anyone who goes a bit deeper into Agile quickly runs across the Lean roots. Over time we’ve seen more and more Lean ideas adopted under the Agile umbrella.

My own Xanpan book is an example of that: hard core XP agile infused with Lean Kanban thinking.

Talking of Kanban…. six years Kanban was still new, and it seemed for a while that the Kanban community didn’t want to be part of the Agile community. They wanted to be seen as Lean. (One supposes they thought Lean was superior, or at least more marketable.) That seems to have changed too, I now hear expressions like “Kanban is an alternative path to Agile.” I feel there is a broader understanding that while Kanban is different to Scrum it is not so different that it isn’t part of the Agile movement.

(Perhaps the greatest contribution the Kanban insurrection made has been breaking the Scrum hegemony. Scrum is still often used as a common synonym for Agile but it is no longer seen as the only player. Because of Kanban people are more aware of differences.)

Back to my original question.

When people ask “what is next?”I usually to sense there is something else they are not saying, perhaps what they are saying is: “Agile destroyed the waterfall, what is coming along to destroy Agile?” – after all this is the tech industry were new technologies come along regularly. Cynically I sometimes wonder if these people are thinking “Maybe I can ignore Agile and get with the next thing” or even “Agile is a fad, give it a few months and the wheel will turn, we’ll be back to waterfall.”

Notwithstanding cynicism, it is wrong to think something will come along and disrupt or destroy Agile, the way Agile did Waterfall. Many more innovations build on what has gone before than destroy what has gone before. The question “What comes after Agile?” is better asked “How will Agile evolve to next?”

That is an easier question to answer because the future is here: *Continuous Delivery, Mob Programming and No Projects*. All three build on Agile and takes it to a higher level

Continuous delivery: Teams delivering not just at the end of the iteration but all the way through it. In some cases many times a day or even many times an hour.

Unfortunately for those people who were hoping to leapfrog Agile and get with the next big thing the first step to doing Continuous Delivery is doing Agile well. If your team can’t release a product update at least every two weeks then you aren’t even at the start of Continuous Delivery.

The path to the continuous delivery thing lies through Agile.

Then there is Agile’s cutting edge, the new ideas which will build on Agile and take it further.

On the technical side mob programming and BDD (behaviour driven development) continue to build.

On the process and organization side “#NoEstimates” continues to stir up controversy although I fear it does as much damage as it good.

And of course there is #NoProjects which I am closely associated with.

My thinking on #NoProjects continues to develop and it continues to be a popular conference talk. Now I want to try something different. Next month I intend to run a one day workshop on the subject to help teams explore how they may get away from project thinking. More details and how to book on EventBrite.

As mentioned a few weeks ago I’m compiling my recent Agile Connection series on User Stories and Requirements into a LeanPub book.

I’ve now released the first couple of chapters, you can get them from LeanPub right now!

I intend to add more chapters over the coming weeks. The bulk of the material will be straight from the Agile Connection series, perhaps with a little more editing. There will also be some off cuts, bits that didn’t make it to Agile Connection series either because they were blew the word limit on another piece, were too short to stand lone, or didn’t quite fit in. There is stuff you can do in a book because it is large and different.

My intention is to up the price a bit as I add chapters. Its really annoying now that the UK (and I think all of Europe) charge VAT on e-books. Seems a bit unfair that printed book don’t attract VAT but ebooks do.

If you have any comments on the book, the content or things you think are missing please let me know.

A few weeks ago I tweeted:

“Large companies trying to be Agile remind me of middle aged men buying sports cars”

I wasn’t saying large companies couldn’t be Agile – heaven knows most are trying and a few have successful software teams but on the whole the successes are few and far between. My thinking has nothing to with whether they can succeed (they clearly can, but most fail), or whether we should try and help them (yes, I’ve helped a few in my time, and I’ve seen a few failures) but rather my thinking comes from Peter Drucker:

“Large organizations cannot be versatile. A large organization is effective through its mass rather than through its Agility.” Peter Drucker, Age of Discontinuity

Peter Drucker wrote that in 1968, long before anyone ever thought of applying the word “agile” to software or business.

What I’m getting at is: for most large businesses the things Agile requires go against the grain of what has traditionally made them successful. For example…

Big businesses use economies of scale to extract favourable terms from suppliers. But software development doesn’t have economies of scale, rather it has diseconomies of scale. Applying economies of scale thinking to software development and agile hinders it.

Big businesses (to achieve economies of scale and management) often favour standardised procedures and processes: these bring some benefits but they reduce variation (not good in software development), reduce experimentation (required if you are going to try something new) and discourage risk taking. Sure standardisation brings benefits but the benefits they bring are opposite of what agile thinking would suggest.

Big businesses have lots of customers who are customers because they are customers – inertia. For example changing your bank is so much trouble and effort very few people do it past the age of 25. All that Agile talk about MVP, product management, customers and so on doesn’t matter when you are dealing with existing customers who stay through inertia. You biggest risk is upsetting them enough to make them move.

Big businesses are inherently risk averse: the risk of upsetting customers, suppliers and shareholders is greater when you have more of them. Yet many agile practices look very risky at first, even if you understand logically that they are risk reducing simply doing something your peers don’t is a risk.

For example, image a manager who buys into the logic of continual delivery (CD) and sees how it reduces the risk of releasing software. If he alone adopts CD for his team – when all the other managers stay with the annual release – and something goes wrong then he will be seen as at fault. It leads to defensive decisions and an aversion to change because change is risk

And big companies have more people so there can be a herd mentality. Consider that example again, it there are only two development managers in the company and one decides to adopt CD then half the managers do CD and half don’t. If however he has 10 peers then there are 10 who take a different decision, i.e. stick with the thing that always “worked” in the past and one, him, who changes.

Big businesses often grow through acquisition. Acquisition is often the modus operandi of big companies: buy similar companies, buy their customers, extract economies of scale, install standardised procedures and remove differences. Thats how you make a merger work if efficiencies are your goal. But those things fly in the face of what an Agile company would do.

Some big businesses have got to be big by squeezing the fat out of processes and inventories, i.e. remove the slack. But without the slack there is no room to manoeuvre – remember queuing theory, once utilisation rises delays increase and variation is bad. That makes change more difficult and also makes practices like reducing WIP difficult to implement.

One way big companies succeed is to define roles and responsibilities, indeed hand-in-hand with economies of scale goes economies of specialisation. That is, as organizations (even teams) get bigger it becomes economic to have specialists, like business analysts, in particular roles. But again this cuts against what an agile company would do. Agile companies value multi-skilled/multi-functional people who can adapt to what is required. This approach also helps deal with bottlenecks; specialisation often creates bottlenecks (even met a test manager who carefully schedules his testers so nobody is ever underused?)

I could go on but hopefully you see what I’m saying here: the things that make a company successful at being big are often the same things that make it difficult for the company to be agile and, importantly, vice versa.

Size is inherently un-agile.

Thats not to say size is bad, size brings many advantages but these are not the advantages of agile. Trying to be big and agile is an example of having your cake and eating it. The few companies manage to achieve both really are the exception that proves the rule.

Hence: a company gets big and successful, like a middle aged man who has a good job, and in an effort to reclaim the nimbleness of youth embarks on a quest for a fast car and younger wife (agile), while forgetting that middle age brings its own benefits, notably in this context knowledge and experience.

Now, the question that lurks here is: if a large company becomes “agile”, that is, if it changes many of the things that have made it successful as a large company in order to achieve agility, then: does make sense to remain a large company?

Possibly by dismantling the things that make big successful and replacing them with practices and processes which allow agile to be successful the company has turned itself into little more than a disjoint conglomerate. In which case it may find better economies, and a better stock market valuation, by splitting itself up.

And that in turn suggests that any framework for “scaling agile” has a number of challenges to overcome if it is to succeed.

Finally, I don’t mean to be critical of people who try to help large companies, in many ways these people are taking on the most difficult tasks and deserve our support.

And for completeness, I should say: if you are a big company out there wrestling with these problems please feel free to call me, my rates are very reasonable!

In the last two posts I’ve discussed some problems with of self-organizing teams and highlighted the need to be clearer about what is actually meant when talking of, that is naming, self-organizing teams. At a minimum the labels need clear definition (I suggested some definitions and I hope someone knows some better ones.)

I went further and I called for individuals and teams to be given authority so that timely decisions can be made with maximum knowledge. I’m sure everyone agreed with me up until that point and then I said we should stop “empowering” people, I said I hated the term empowerment and that probably confused a lot of people.

Now I’d better explain myself.

Actually my thinking comes directly from Henry Mintzberg so I’ll let him explain:

“empowerment [does] not change that [participation] because the term itself indicate[s] that the power remain[s] with the manager” Mintzberg, Managing, 2009

Mintzberg argues that the practice of empowerment leaves real authority, real power with the manager, when a manager “empowers” a worker he is offering him a gift, or rather a loan. It is the manager who chooses to empower the worker, by implication the manager may choose not to empower the worker or to remove the power at a later date. The very act of empowering a worker actually emphasises the lack of worker power.

Elsewhere in the same book Mintzberg makes a good point:

“Truly empowered workers, such as doctors in a hospital, even bees in the hive, do not await gifts from their managerial gods; they know what they are there to do and just do it. … people who have a job to do shouldn’t need to be empowered by their managers”

A little later Mintzberg offers a key insight:

“a good deal of what is today called ‘empowerment’ is really just getting rid of years of disempowerment.”

Its not about empowering software engineers to improve the build system, or testers to automate scripts, or analysts to do stakeholder mapping; its about trusting them to do their job right and letting them do it. These are the experts in their field, let them do what they know to be right, indeed, go further: insist they do the right thing.

So if you are a manager stop empowering people and teams, instead stop disempowering them. Give them the trust, authority and support to do their work.

And if you are a worker just reach out and take authority. One of MIntzberg’s better known peers, Tom Peters, like to quote the American soap star Rossanne Barr:

“Nobody gives you power, You just take it” Rossanne Barr quoted in Re:Imagine! by Tom Peters

Let me leave you with a classic pattern from Joe Begin, Do The Right Thing:

Things are bad. Really bad.

        •        When things are bad it is really tough and bad things happen.

        •        When things get better the bad stuff doesn’t happen any more and you feel good. Really good.

Therefore: Do the right thing. Make the bad thing better.

The result: Things are good. Really good.

Known Uses:

        •        When you were small your father would make the Monsters Under the Bed go away just by sticking his head in your room. He did the right thing.

        •        When you are really sick, eat your Mom’s chicken soup. Only your Mom’s. Only she knows how to do the right thing.

Don’t wait for someone to give you authority or empower you, do the right thing.