This is an important post. This is the ninth blog post in my mini-series on management, it is the blog post all the others have been building up to, let me recap some key points:

• When creating software there there is coding work, testing work, requirements work and some unavoidable management work
• Removing managers may remove some work (because managers make work for other managers) but there is still a residual amount of management work to do
• Management itself is a skill and requires intuition
• It takes an engineer to manage engineering; people without experience of doing software development are going to struggle
• Management decisions can make a big difference
• All who are called “Manager” are not managers, some are specialists
• There are many non-commissioned managers (NCO managers), those who manage without the title of “Manager”, frequently these people manage with minimal or little management

• Management work may be done by specific people, commissioned or non-commissioned managers, it may also be shared among team members

I’ve deliberately avoided discussion of self-organising or self-managing teams because these subjects deserve posts to themselves. The key point for me is:

• When decisions need to be taken they are best taken close to the point where they are needed
• When decisions are needed those who are staring directly at the decision are often the ones with the most knowledge about what is needed
• Taking decisions at the point the decision is needed also makes for a rapid decision
• It may make sense to get a second opinion, to talk through a decision with another person or in a team, and if the decision effects several people it probably makes sense to consult with them

One way to address these points is to use a self-managing/self-organising team and there are reasons why you might want to do that. But, that is not the only organization structure for satisfying these needs. The underlying principle is:

Devolve authority, pushing authority downwards, decentralise decision making

Whether you devolve to a team as a whole – as in the self-organizing/self-managing model – or to individuals, perhaps to NCOs the aim is to move the decision closer to the work.

Note: I’m avoiding the work empowerment, see my Stop empowering people – End disempowerment! post form last year.

Either way you do it, if you push authority down something else happens:

More people engage in management work

Yes, suddenly coders, testers and analysts who do not think of themselves as managers now need to make management decisions. Even if this is done in the setting of a self-managing/self-organising team management decisions are still being made. Indeed, if the whole team makes the decision they whole team is engaging in a little bit of management.

Everyone in the team starts to take on management attributes.

More importantly, More people need management skills, the whole team need some management skills and the intuition that makes a good manager a good manager.

Think about this for a moment.

Do team members want to go to meetings about management issues?

Do you C++ programmers want to engage in management?

If your Java programmers are now engaging in management where do they learn their management skills?

If your Testers are making on management decisions how do they develop their intuition?

If you accept that management work is a skill set in its own right, and you believe that more people should be involved in managing then you have to ask: how are these people going to learn management skills?

Then there is another side to this…

Talk to any manager about what they actually do, not what they would think they should do, or what they like to be doing but what they actually spend their days doing. You will hear them say things like:

• “I’m constantly fire fighting”
• “I’ve got tons of e-mail to answer”, “My phone is ringing all the time”
• “I never get to do strategy”, “I never get time to think or plan”

One of the characteristics of management work is that it is inherently interrupt driven. (If you don’t believe me go read Henry Mintzberg’s Simply Managing book I mentioned last time.)

So, by involving programmers, testers, analysts, etc. in management we are also opening these people up to interruptions. People will interrupt… well, potentially any team member!

Now if you are a programmer, tester, analysts or what-not please ask yourself: do I want to be interrupted? Am I willing to take the downside of management?

I’ve known plenty of programmers who would definitely answer “No!”

(There is a twist here, Mintzberg also suggests that managers choose to be interrupted. Which could imply that teams could choose not to inflict interruptions on team members but that is not entirely in the team’s gift. What Mintzberg doesn’t say how many of the interruptions would be avoidable? Do managers choose to be managers because they are interrupt driven in nature? – but we digress).

Lean folk will spot that there is a question of variance analysis here: management work has a greater variance than programming or testing and therefore needs to operate on a different cadence. The queues are different. From a lean point of view it makes sense to separate these two types of work because they have different variance and cadence.

Now here is a question.

If management requires skills and intuition (both of which need to be built in a person), and if doing management results in an interrupt driven work pattern then is management better:

a) Centralised in a few people who can be trained in the skills, who develop their intuition and who are tasked to handle interruptions, thereby leaving the majority of the team to focus on technical skills and un-interupted work (hopefully achieving flow)

b) Dispersed with everyone having some management skills (at the cost of technical skills) and some interruptions (at the cost of flow)

c) Other, please specify

For me the answer is (a) but…

If management is centralised it then becomes a question of how centralised? Over centralisation results in the model we see all too often with decisions delayed and taken by people with too little knowledge. The result is depressing and demotivating for those at the code-face.

But if management is organised as a hierarchy of managers then they make work for one another and some decisions end up traversing the hierarchy. So answer (a) is not perfect – this might be another example of dis-economies of scale.

Which brings me back to Non-commissioned managers: I would like to see more people with more management skills embedded closer to the work and working co-operatively within a team. An impure self-organising model if you like.

Any which way, there is no perfect answer. It is about balancing forces.

In my list of management work last week I left what some people will think of as a major omission: strategy and planning.

There is a school of thought that says that managers spend, or at least should spend, a lot of their time engaged in thinking big thoughts, having big discussions, creating company and product strategy. Sure thats why they need those big offices? Where else can they think deep and plan?

This school of thought would acknowledge that not all managers create strategy but since all managers think big thoughts those that don’t spend their time creating strategy are planning. Specifically they are planning how to implement the strategy set by more senior managers who do set strategy.

And since managers spend so much time planning they must also spend a lot of time communicating those plans – communicating downward that is. How else can you roll-out a strategy? How else do you implement a plan?

This school of thought is particularly powerful with people who aspire to be managers, people who want to be managers so they can think big thoughts, so they can step back and play a small part in the running of the world. Those who are fans of Michael Porter’s work on Strategy often subscribe, Porter sees strategy as conscious, inherently a top-down activity.

For those who hold this view is also follows that managers need authority: authority to decide the strategy, authority to tell others the strategy, authority to plan and authority to tell others to implement the plan they just made.

So why did I omit this important, and time consuming, aspect of management work?

I omitted it because this view of management is fantasy. It doesn’t exist.

Managers don’t spend their time planning and even fewer spend their time strategising. Sure many managers say they want to do this but very few ever find time. Thats why they feel compelled to create “offsite days” to plan and create strategy because day to day they are caught up in firefighting.

If you don’t believe me do and read the work of Henry Mintzberg, specifically read his book Managing, or the short version of the same book, Simply Managing. In these books he details his findings from following actual managers around and looking at what they do. He find they do very little planning and strategy.

Which is hardly surprising because in his earlier book Mintzberg demolished the idea of strategic planning: The Rise and Fall of Strategic Planning.

For software developers the story this book tells is oddly familiar, it starts with the idea that a strategic objective can be decided, that having decided the objective people (managers) can rationally decide what needs to be done to achieve the objective. They can then rationally allocate resources. The resources can then move them towards the objective. Sound familiar?

While Mintzberg agrees that organizations can have strategic objectives, and may even put in place plans to achieve them he shows that achieving the objectives is far from a rational planned activity. And, perhaps more important, strategy is not just a forward looking process (“We want to be the world leader in widgets!”) but an iterative process (“How can we increase our widget sales today?”) and backward looking, sense making (“Hay, our widgets are selling well, what did we do?”).

Most management work is far from planning and strategy creation. Most managers spend their days on administration, on working out problems, on applying their knowledge of a problem – a domain, solutions, history – to the problems they face today.

And if managers are spending their time engaged in strategy, planning and deep thinking then it follows that there is a lot less for them to communicate. And since the plans don’t exist there are no plans to deploy and no need for authority to order people implement plans.

Mintzberg also demolishes the idea that manager work hierarchically, that they need authority to do things. He shows how managers work without authority, they cut across hierarchy, and they work with their staff more than they direct their staff. Management is at least as much about persuasion as it is commanding.

Once you start to see managers as co-operative problem solvers they look much more like any other team member. Albeit one with some elevated status.

In fact, I’d go as far as to say: any manager who tries to work purely through authority is a) not going to be popular and b) find it hard to get things done.

Take away strategy formation, planning and roll-out from the work managers do and an awful lot of the power managers supposed have goes too.

In a software development teams an awful lot of this work can be push down to teams and the NCOs that work with the teams. Authority can be distributed to the people who closer to the problems, who need the authority.

Now perhaps it becomes easier to see managers as team members too.

It just so happens that their skills are a little different form other team members, their skills are more in administration, firefighting, working in ambiguous areas with limited knowledge and yes, to some degree organizing.

Continuing my discuss of management, broadly speaking my argument is:

There is management work to do – the same as there is coding, testing and customer understanding. To pretend there isn’t such work to do, that all software development might be reduced to rational engineering is naive.

Much of management work may be administration, we might be able reduce the amount of work, we might be able to delegate it or disperse it but there is still a rump of work to do.

A lot of management work involves decision making, and a lot of those decisions require authority.

So what is this work?

Here are some examples which I think are legitimate, possibly intrinsically, management work:

• Managing the client-supplier relationship: whether you sell your software product directly to customers or not your company will have suppliers (paper-clip vendors maybe) and customers/clients (well I hope you do, a few companies may have none but that is another problem).
• Managing expectations of stakeholders (with BAs, POs, etc.)
• Coaching staff
• Governance of work
• Information hub and firewall: information aggregation, filtering, dissemination
• Organizational structure: creating the environment for success
• Dealing with higher authority: for negotiation, for leveraging (unblocking)
• Finances: even in companies which have gone beyond-budgets there are still finances to “manage”, if anything a beyond-budgets approach will increase the amount of attention paid to finances
• and various administration issues

You do NOT have to have “manager” in your title to deal with these issues, these are examples of management work. You are a “manager” then you are more likely to deal with them – you might even attract such work.

This is not an exhaustive list — how can it be? – feel free to expand the list in the comments section below!

Some of these might be not be agreed by everyone. For example: should managers be information hub?

I’ve spoken to many developers who complain that their managers don’t tell them the full story, they selectively filter information, perhaps to retain their own power. But I’ve spoken to many, probably just as many, developers, who complain that their managers tell them too much, call them to pointless meetings to hear pointless messages.

And there are many who would argue that with modern technology (e-mail, mobile phones, etc.) that the information hub is redundant, after all messages can be communicated nearly instantly to everyone. But this cuts both ways. If message can be communicated instantly at very low cost it may well lead to more pointless messages and information overload.

So before anyone complains that they are not being told enough please check your mailbox, and mail filters, and ensure that you are not receiving too much communication.

Some of these items may be a sign of organizations in transitions from one organization style (maybe called traditional, top-down or hierarchical) to another (maybe called agile, self-organized, or holacracy). Such transitions don’t happen instantly or just because the CEO says “Lets be a holacracy”. And some organizations might simply want a little bit of “agile” in the software development teams in the basement but they don’t want self-organization anywhere else.

In any of these cases there will be management work dealing with the old-world and interfacing it to the new, and quite possibly expanding the new-world.

Some would even suggest that bring about such changes is itself management work and I don’t think I’d disagree.

Few managers will do all of the things I have listed and even fewer should do all these things! These are just a selection of the type of work I would expect to see managers doing.

What all these things have in common is they are nebulous, they deal with unknowns and unknown unknowns, they require working with incomplete information and they require a degree of intuition, some a little some a lot.

If these things weren’t ambiguous and nebulous then they could be formulated as a set of rational decisions, with known inputs and knowable options – as I described last time, lots of management work is about the fuzzy world out there. In so doing much of this work would move from the management space into the engineering space and might even, one day, be automated.

As time goes by we are finding ways to reformulate some of these issues so they can be tackled by engineers. And we are finding ways to reduce the ambiguity – the test driven techniques in Lean Startup are great examples.

Big data is another tool we are using to move decisions from the ambiguous space to the engineering/rational space. But, big data has a soft underbelly.

While this work rests in the ambiguous space then intuition is required to make decisions.

Keen eyed readers will have noted two omissions from the list and the discussion which followed. One I’ve ducked before: Leadership, the question of management leadership deserves a blog all of its own.

The second also deserves a blog all of its own: strategy. Many people have argued that one of the primary roles of management is to provide strategy, I’m not so sure. The full discussion will need to wait another blog.

I shouldn’t do this, it raises my blood pressure, I have better things to do, I have better things to blog about but I can’t help myself….

I made the mistake of opening a mail from a recruitment agent, the title: “Agile Project Manager/Scrum Master”, let me dissect it for you…

“My client based in the West Midlands are looking for an Agile Project Manager/Scrum Master for a long term project opportunity starting in May.”

Agile Project Manager/Scrum Master? – this is a pretty confused role, it is one thing or another, its one thing for a good project manager to act as a facilitator or for a Scrum Master to take on project responsibilities but to start out like this, well is just messed up.

Long term project? – there is no such thing, projects are temporary!

“The successful Agile Project Manager will be responsible for the planning, organising and managing of IT projects within this matrix resource environment. My client is looking for a technical Project Manager with strong experience in leading and managing multiple complex projects in agile environments. To be suitable you MUST have strong process and project management skills with experience in SCRUM.”

Planning, organising and managing of IT projects…? – what happened to self-organizing, empirical control?

And note “projects” not project (as it was before). Multiple project is a bad sign.

Matrix resource environment? – Matrix management, this organization has shot itself in the foot already.

Technical Project Manager? – so this person is a Scrum Master, a Project Manager and Technical, do they also make the tea and wash up?

And why all the SHOUTING? – Scrum is spelt Scrum, as in Rugby, it is not S.C.R.U.M. or SCRUM.

“As the Agile Project Manager/Agile Coach you will have ownership of the full life cycle project process, including the Software development lifecycle.”

Coach too? – as well as a Scrum Master, Project Manager and Technical? I’m not even complaining about the use of Agile and Scrum as if they a synonymous.

Ownership of the full life cycle… including the software development lifecycle, really? – except for the fact that the contract is for 6 months, the company is matrix managed, there are multiple projects and that some bastard hotchpotch process of SCRUM and traditional project management has been mandated.

In other words: you have as much ownership as a homeowner who’s house has just been repossessed by the bank.

Anyone taking this job would have their hands ties behind their back on day one.

“Key requirements:

• Demonstrable experience managing complex Projects in fully Agile environments
• SCRUM Master with previous experience of running Agile project teams
• Excellent presentation skills & competence in project management tools
• Full life cycle delivery experience
• Ensure all SCRUM ceremonies are adhered to throughout project lifecycle
• Collaborate with project teams (both on and offshore), create and maintain project plans and schedules”

Fully Agile environments don’t have projects, Scrum Masters don’t run Agile teams and “maintain project plans and schedules” sounds distinctly Gantt chart-ish.

Saying “all SCRUM ceremonies” sounds like the people doing the asking don’t actually know what the ceremonies are, just they must be “adhered to”. Anyway, Scrum isn’t a full lifecycle model so good luck here!

What is interesting here is what is not said:

• No mention of facilitation, unblocking, coaching
• No mention of technical skills (TDD, ATDD, BDD, refectoring, etc); this is supposed to be a “technical project manager”
• No mention of empirical process control or forecasting
• No mention of value
• No mention of prioritisation
• No mention of the Product Owner/BA/Product Manager

Normally I would be pleased that the recruiter wasn’t asking for a Scrum Master Certification, a Prince 2 certificate, or, heaven forbid, a “Agile Project Manager” qualification but on this occasion I read it more as a sign that the company doing the recruiting don’t actually know what they want.

Similarly, no mention of tools or technologies – Agile in PHP is very different Agile in embedded C, let alone the ERP Agile I’m working on now.

Finally,

“If you are interested to find out more, please reply…”

Should read:

If you are a traditional project manager (who used to code in the dim and distant past) but can’t get work now the world has gone agile, but think you know what agile is (mini-waterfalls) then please give me a ring, you probably know more than the people doing the interviewing anyway.

Bottom line:

1. Unfortunately this is the state of our industry, it is what many organization do and want. But it is far far from what the best teams do.
2. Don’t blame the recruiter, their industry is based on failure, most recruitment agents are failed real estate agents.
3. The organization requesting this role have such a poor understanding of what they need they shouldn’t actually be allowed to hire anyone.

Taking a break from my recent series of blogs about management, I’d like to discuss something that has come up with my current client – OK, I’m bending my rule to and blog about live events but this isn’t about the client, its about an idea.

Opportunistic salvage

Many readers will have seen this scenario before: there is an existing system, it has been developed under a previous approach, a non-Agile, an approach that didn’t give quality a high priority. Some believe that the new work, based on an Agile approach, can take the current system “as is” and build on it, maybe some patches will be needed but why throw away something that has already been built?

Something customers have? Something you’ve paid for? – they have a point.

And there are other people who believe, perhaps with good reason, the existing system has poor code quality, poor architecture, significant defects (bugs), and in general takes more effort to maintain than it would to rebuild.

As always the truth lies somewhere in between, and as always, determining what the truth is is not easy. The best that can be said is: some parts of the system are good and can be built upon, and some parts of the system bring more costs than they do benefits.

Anyone who has ever owned an old car will know the problem: you take the car to the garage and you are told “Ooo…. this is expensive to fix” – not as expensive as a new car but expensive. Nor it this the first time you’ve taken the car in, this time its the steering, last time it was the electrics, next time… the clutch? the gear box? And maybe there is rust.

You have to make a decision: should you spend the money to keep the car running or invest the money in a new car?

This is the question we face. Our solution is: Opportunistic Salvage.

We will look at each part of the system on a case-by-case basis and decide whether we can bring it across or whether we rebuild.

Critically this is driven by tests, automated acceptance tests to be specific.

Faced with a request, a requirement, we develop a series of acceptance tests – based on the acceptance criteria that go with the requested story.

These tests will be implemented in an automated ATDD fashion using a tool like Cucumber, SpecFlow, FIT or Selenium. We will then take the part of the existing system and run it through the tests.

Two points to note at here:

• Building an automated acceptance test system is needed for a proper Agile approach. So building this keeps with the new approach. (If you are not automating your tests to build fast feedback loops its unlikely you really are doing Agile anyway.)
• Some work may be required to make the section(s) of code testable, i.e. make it a module with a well defined interface. If the code is already a well defined module then good; if not then it should be. Going forward, in an Agile approach, requires good code so if an investment is needed then the investment is made.

Now one of two things will happen.

Possibly the lifted code will pass the tests, this is good and shows that the people who said we should build on the existing were right. We can take a quick look inside the code to make sure its good quality but it probably won’t need much work – after all it just passed the tests. If it happens that a bit of work, possibly refactoring is required then since there are now tests this is quite doable.

On the other hand, if the module fails the test… well, it is a good thing we found out now and didn’t leave it till later! (One wonders how the current system is working but lets not worry about that right now.)

The code has failed tests so obviously needs some work. Nobody wants to ship code which is known to be faulty.

Now we look inside the code, and we make a professional judgement: is it better to patch up this code and make do? Part of this judgement included remember the product is expected to continue for some time to come.

These decisions are made on a case-by-case basis. There is no blanket decision to move all the old system, nor is there a blanket decision to write everything from new. What is good is kept, what is OK is patched up and what is bad is thrown away.

The people to make the judgement call are the people who are going to be working on the code: not the managers, not the business analysts, not the project managers, not the product managers, not even the testers. All these people may have a view but there is one group of people who are recruited and employed because of their professional skills with code.

The programmers, aka software engineers, aka software developers.

Given a code module that is failing tests and is expected to have a long life these people need to make a professional decision on whether the better course of action is to patch and make do or to rewrite.

In making this decision we are accurately aware that sometimes writing from scratch can be faster than patching up something that already exists – faster both in the short run and in the long run when ongoing maintenance costs are considered.

This is especially true in software, especially true when the people who originally wrote the code are long gone and especially true when the original code was written without tests.

These decisions are made on a case-by-case basis. Where code can continue it is salvaged and reused. Where isn’t sensible then it isn’t.

So… no debate about legacy or new build: Opportunistic salvage driven by tests.

If those who believe the legacy product provides a solid base are right then there will be little new code written, sure you will need to write some tests but you will want to do that anyway.

If those who believe the legacy product should be rewritten are right then many tests will fail, code will be found to be crummy and it will be replaced.