Friday, May 27, 2016

Managers, change and strategy

In response to one of my posts on management Sergey Timanin ‏tweeted:

“the work [of managers includes] steering the organisation in times of change might be the most invisible to tech people and most under appreciated”

I agree completely with Sergey, many of the changes in and around organizations are invisible to those doing the work. Indeed much, if not most, management work is invisible to those outside the management circle. Does that make it worthless?

Programmers often just want to get on with programming, nothing wrong with that. But sometimes there are changes swirling around, left unmanaged these changes have the potential to sow uncertainty, diminish trust and disrupt work.

In my nature of management post I noted that part of the management role is to interfaced the fuzzy, unknown, unpredicted (unpredictable) world to the very predictable world of machines. This is where Sergey’s observation fits in: the world out that is in a constant state of flux, allow too much of that flux into the work environment and well… you won’t get too much work done!

Managers are sometimes described as “Firewalls”. That is, they shield workers from interruptions and uncertainties that will disrupt their work. This can certainly be true.

But, for every programmer who values their manager as a firewall there is another who believes the manager is unnecessarily filtering - perhaps even controlling or hiding - the information which reaches them and that managers should get out the way and let the information flow direct. These people see managers not as Firewalls but as Gatekeepers who (unnecessarily) restrict the flow of information.

Its easy to see how these two points of view can be simultaneously held by two individual programmers about the same manager in the same company at the same time. One man’s protecting is another man’s hiding, the distinction between Firewall and Gatekeeper is subjective. This is where managers require skills and intuition, both to know what information to hide and what to share and how to communicate with different people with different expectations.

Sergey’s tweet also hints at something another responsibility which is often laid at managers door: that of bringing about change. Particularly being about change in the work environment.

Certainly I would see this as part of a managers role but actually, I would see this as part of everyones role. A good manager should encourage the change ideas of others and help them bring about changes they want to see.

While on occasion a manager may need to discourage - or even prohibit a proposed change - managers should have a role to play in bring about change for the better. However change is usually best when it is bottom-up rather than top-down. I would see a managers role more as fanning the flames of positive change and building momentum more than rolling-out a series of changes decided on in closed rooms.

Traditionally management’s role has been seen as one creating change below in order to satisfy the requests from above: top-down change with the manager as the instrument of delivery. Certainly that is sometimes true. Those who subscribe to view that strategy is planning, that strategy is decided at the top by big brains and passed down the organization would subscribe to that view.

But I don’t.

I believe some strategy is certainly decided at the top and “deployed” or “rolled out” down the organization but, actually, much strategy is bottom-up, it is emergent, it is the result of what happens on the ground, learning at the coal-face, and how this information is interpreted higher up.

Strategy is both emergent and in many cases retrospective. That is to say, strategy is a story we tell afterwards to make sense of what happened and to align future actions. In this case manager’s role is as much about telling stories and passing strategy up the hierarchy as down.

Tuesday, May 24, 2016

Advice for managing software development?

When I started writing my management blog series one reader expressed their hope that I would give advice on how to manage software development. I’m sorry, but this series has contained very little advice on how to manage software development.

There is a good reason for that: It is hard to give specific advice to managers.

You can’t say “If X happens then do Y”, you can’t even say “If you find yourself in situation A and then B happens then do C.” You can say such things in code, and you can say such things about coding. You can say such things about testing, you can often say such things about product management. But you can’t give such rules to managers, and if you did they would cause more harm than good.

There is a branch of philosophy and logic called contingency theory which talks of such situations. When a set of pre-conditions are satisfied then a certain action is “the right” thing to do.

The problem with managing is that it is difficult to give hard and fast rules, management is not contingent. What managers do, and what decisions they make - and don’t make - is very very dependent on context.

If you were to try and codify all the management actions and decisions you would need an incredible amount of detail and an incredible number of rules. Now computers are getting more powerful and the application of artificial intelligence may render some management decisions subject to contingency theory but for most humans such an approach to decision making is not possible.

And to complicate matters, even if you did have a decision making system much of the information managers have is incomplete or fuzzy, indeed, part of their job, their reason for existing, if to manage in when information is uncertain and the world is changing. (These same factors mean attempts at contingent management, like PRINCE2, are fundamentally misconceived.)

Hence intuition and understanding of context are important. Let me repeat a quote I used a couple of weeks back from Professor Henry Mintzberg:

“Put together a good deal of craft with the right touch of art alongside some use of science, and you end up with a job that is above all a practice, learned through experience and rooted in context. There is no ‘one best way’ to manage; it depends on the situation.” Mintzberg, Simply Managing

Management is contextual not contingent, there are few, if any, hard rules.

Consequently I think the best advice I can give to managers, and soon to be managers, is:

  • Understand your management philosophy. Understand what you believe, understand how you believe the world works. Your philosophy will inform your decision making.
  • It is not enough to just understand ones own philosophy, one needs to continually reflect and build on ones own experiences.

Hence I have very little advice for managers. Well, actually… I do… my “failed” book, Xanpan 2, set out to try and decode many of the problems managers face in software development and build a practical guide to software managers. I was, perhaps, too ambitions. Xanpan 2 is available, as it stands it forms a wonderful appendix to Xanpan.

Saturday, May 14, 2016

Management for the masses?

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.

Sunday, May 08, 2016

Managing requires skills and intuition

If you’ve been reading my series of blogs on management it should be clear by now that I think some element of management is essential in software development. You might also have picked up that management, in various forms, is bigger than is commonly realised.

I also believe that good management can make a big difference to software development teams, I agree with Fred Brooks when he wrote:

“Some readers have found it curious that The Mythical Man Month devotes most of the essays to the managerial aspects of software engineering, rather than the many technical issues. This bias ... sprang from [my] conviction that the quality of the people on a project, and their organization and management, are much more important factors in the success than are the tools they use or the technical approaches they take.” Brooks, Mythical Man Month, 1995.

Tools, technologies and processes change all the time in software development but some things last. Mythical Man Month is one such, a book originally published in 1975 about work that mainly happened in the 1960s remains, perhaps because management of software development is important.

So why is it manager-less teams do so well? Let me suggest that the value that can be destroyed by bad management is far greater than the value that can be added by good management. I would venture that sometimes no manager is better than a bad management; self-organization doesn’t so much do away with management as do away with managers.

I would also venture that the quality of management in software engineering, indeed IT in general, is pretty poor. This is especially true in the corporate IT world. The standard in software producing firms (ISVs, SIs, etc.) is generally better.

Thus is seems sensible to ask: what makes a good manager? or perhaps, what makes an individual good at managing?

Well, two things.

First, management is a skill set in its own right. Managing requires skills in the same way writing Java, Testing software or Analysing requirements does. Simply appointing someone as a manager does not automatically endowed them with the necessary skills. These skills include communication, analysis, empathy, decision making and others. It helps too to have at good understanding of the business you are working in.

And as I said in my first blog in this series, it takes an engineer to manage engineering. Someone who is an engineer, understands engineering sensibilities, the thought process of engineering and engineers and knows the issues raised in software engineering will make a much better software manager than someone who does not.

Let me quote Fred Brooks again:

“In many ways, managing a large computer programming project is like managing any other large undertaking - in more ways than most programmers believe. But in many other ways it is different - in more ways than most professional managers expect.” Brooks, Mythical Man Month, 1975.

As an industry we fail to recognise that managing is itself a skill-set, and while software managers may learn more from non-software manager there it more to it than “general” management.

But managing software engineering, indeed any form of management, requires something more than skills…

Managing requires Intuition.

That might come as a surprise to some of you but it follows directly from something I blogged about a few weeks back: Management operates in the messy, fuzzy, ambiguous “real world”. Intuition allows one to work in such an environment.

Intuition also allows for rapid decision making; an engineer, especially one schooled in agile and lean startup may often prefer to set up an experiment and test options but such an approach inevitably slows things down. Sure there is a place for hypothesising and testing but sometimes speed is more important. Plus, it is not practical to set up experiments for all the the hundreds of decisions a manager must make during a day. Sometimes having a decision is more important than having the right decision.

Intuition is more difficult to teach, it needs to be built largely from ones own experiences. Some intuition comes from having done the work which is itself being managed. Intuition is also built from past management experiences. And intuition can be enhanced in various way: self-reflection and writing to name two.

This is not to say all management is about intuition, some benefits from analysis - and that requires the skills. There is a mixture here. Let me again quote from Professor Henry Mintzberg:

“Management certainly applies science: managers have to use all the knowledge they can get. But effective managing is more dependent on art and is especially rooted in craft. Art produces ‘insights’ and ‘vision’ based on intuition … and craft is about learning from experience - working things out as the manager goes along.

Put together a good deal of craft with the right touch of art alongside some use of science, and you end up with a job that is above all a practice, learned through experience and rooted in context. There is no ‘one best way’ to manage; it depends on the situation.” Mintzberg, Simply Managing

That is how I see management: art, craft, science, intuition, and context dependent.

Isn’t that a lot like engineering?

Lets try that quote again with a little change:

“Programming certainly applies science: programmers have to use all the knowledge they can get. But effective programming is more dependent on art and is especially rooted in craft. Art produces ‘insights’ and ‘vision’ based on intuition … and craft is about learning from experience - working things out as the programmer goes along.

Put together a good deal of craft with the right touch of art alongside some use of science, and you end up with a job that is above all a practice, learned through experience and rooted in context. There is no ‘one best way’ to program; it depends on the situation.”

Do you see? - Programming has more in common with management than is commonly recognised.

Tuesday, April 26, 2016

Management work: Strategy and Planning?

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.

Wednesday, April 20, 2016

What is management work?

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.

Monday, April 18, 2016

Thoughts on the nature of management work

Returning to my Management, my mini-series of blog… (Non-Commissioned Managers, Analysts aren't managers and Managers who are not managers)

Lots of Agile advocates have a real downer on Management. I think (like myself) they dislike the authority conferred on “managers”. This may be dressed up as a rational dislike of top-down reasoning - and they have a point - but this also throws the baby out with the bath water.

Look, I dislike authority as much as the next person, actually, I probably dislike is a heck of a lot more than the next person, its probably one of the reasons I find it hard to stay in the same organization for a long period. But in order to reason about management work we need to divorce management work from authority and consider such work in its own right.

At its heart management work is administration. Thats why the most prominent management degree is not a “Management” degree, sure there are “business studies” for undergraduate degrees and Master of Management degrees but the most prominent management degree is actually an “Administration” masters degree.

To an engineer much of this administration looks pointless, or needless, or counter productive. An engineer looks at administration and sees a things which can be engineered away by a rational process with rational decisions by rational people.

But… Not all activities are rational.

Not all processes can be decomposed in an analytical fashion and rebuilt.

And since there are people in these “systems” rationality often goes out the window. What is rational to ME is not always rational to YOU.

Sure, as the knowledge in society increases, as engineers understanding increases, and as our computational power increases, more an more processes and activities can be examined rationally and subjected to rational, engineered, solutions but the devil is in the detail.

During the late 1980s and into the 1990s the Business Process Reengineering movement thought it could reengineer businesses along rational, engineering lines. It was an abysmal failure. Yet remnants of this movement still exist, perhaps most clearly seen in the ERP and CRM space.

The problem is: the world is messy.

More specifically, people are messy.


A lot of what we call “management” is about interfacing the messy world to the rational engineering world. But even the rational world isn’t what we think it is. The rise of the behavioural economics has done much to debunk economists faith in homo economicus.

For me management work sits at that point where the logical world meets the fuzzy world, where binary meets analogue, where Turning machines meet non-deterministic processes, and where homo economicus and Robert Lucas meet homo reciprocans and friends The Undercover Economist, Gerd Gigerenzer, Kahneman and Tversky, Mullainathan and Shafir and a bunch utility-deniers.

“Managers” aren’t the only people in this space. By the way, Business Analysts and Product Managers inhabit the same space but their aims are different. All these roles work to make the messy, fuzzy, emotional and irrational world interpolate with the logical, rational, emotionless world of machines and deterministic processes.

Perhaps more interestingly Scrum Masters and Agile Coaches operate in this space too, that’s why I consider them managers, or at least non-commissioned managers.

I pushed authority to one side before. Many coaches and Scrum Masters - as originally defined but not always implemented - deliberately leave authority at the door. They attempt to fill a management like role but without using authority.

In some ways this is good, it brings a different approach, sometimes better but sometimes worse.

Personally I learnt a lot of my management philosophy in similar position: Branch secretary of a political party. I had very little authority - its a community of volunteers, while I did control much of the administration I could also be ordered about by the massed ranks of comrades.

And there in lies the point.

In many environments those who control the levers of administration have power, and conversely, some leavers of administration require authority to be used properly. There is some work which can be done by manipulating administration (no authority needed) but there is some work which requires authority to control administration.

Administration may decay into bureaucracy, and we all dislike bureaucracy don’t we? Except some bureaucracy may be necessary to smooth running of organizations. I recently came across this quote:

"One person’s bureaucracy is another’s empowerment." Andrew Mullinger, co-founder Funding Circle

Authority, administration, bureaucracy and management aren’t automatically bad, a little of each might be helpful to smooth operations but take too far they can be counter productive.

Now depending on the organization in question - the culture, the systems, the history - exercising administration may require more or less authority, ultimately it is not possible to administer without authority, so administration begets authority. It becomes difficult to disentangle administration from authority.

Notice I’ve said nothing about Leadership here, that is another - but related - topic.

Thursday, April 14, 2016

Agile Project Manager/Scrum Master - Wrong, so, so wrong

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.


“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.

Monday, March 28, 2016

Opportunistic salvage driven by tests

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.

Saturday, March 05, 2016

Non-Commissioned Managers

The last two blogs have all been about roles and people who are commonly thought of as “managers” in software development but who aren’t - Managers who are not managers and Analysts aren’t Managers - either because they happen to have the word “manager” in their title or because exhibit characteristics which programmers associate with managers.

Those blogs were written to prepare the way for this blog…

Non-Commissioned Managers are team members who fill a management role but aren’t usually recognised as managers. Borrowing a military term I think of these people as Non-Commissioned Managers. These are software team equivalents of a corporate or sergeant.

(I have to beg forgiveness for breaking one of my own rules: I’m making a military analogy. I’m very conscious that like so many people who make military analogies I have no direct first hand experience of the military and there is every chance I’m getting this wrong.)


These are people like: Team Leaders, Technical Leads, Architects, Scrum Masters and Coaches. Some of these people - Architects and Scrum Masters - have specialisations because of their specialisation they have some authority in a special area. Others like, Team Leaders, make the teams work day-to-day, they get a lot of the grief management do but few of the rewards. Such roles are akin to Sargent Majors of their teams.

On any software development teams there are a usually a group of people who are not consider managers but really do fill a management position. They may manage people, they may have authority, specialists skills or knowledge may give them authority and power, they may make decisions on behalf of the team, they may guide/coach/advise people who actually do the work, and they get listened to by the real management.

I’m including Scrum Masters and Agile Coaches here. There specialists skills give them some authority in particular areas. I know some Scrum Masters won’t like this but in many organizations the Scrum Masters is very much seen as the Sargent.

Last October I saw a presentation at a conference where the speaker talked of a company with just two managers - the CEO and the Sales Manager. Everyone else was some form of developer. But on closer examination, when you asked, the developers included technical specialists, team leads and others who filled a management role but weren’t seen as part of management.

This is akin to having an army unit with corporals, warrant officers and sergeants but no Lieutenants or Captains. Such units exist, they are usually small units. Larger units without commissioned officers exist too, perhaps only briefly when officers are killed in action. When commissioned officers are absent then non-commissioned offices fill the void. Even when there are fully fledged managers the NCO managers are necessary to make the teams work. They are on the ground, at the code face, with the team all the time.

On teams without a non-commissioned manager it is not uncommon to see a leader emerge, usually because of technical skills, sometimes because of charisma. In time these people may be recognised by the managers as the NCO/NCM, a kind of battlefield promotion. NCOs get some authority from the organization but most of their authority comes from the team because the team respect them.

(I’ve also NCOs imposed on teams who did not respect the chosen NCO. This is a recipe for trouble.)

Herein lies a lesson.

Very small army units, say a fire team, is commanded by an NCO. Fire teams form squads and squads too are commanded by NCOs. (I should say I’m getting this from Wikipedia, and the terms differ from army to army.)

Squads in turn form platoons, platoons are (according to Wikipedia) commanded by an officer, a Lieutenants. Platoons form companies which are commanded by a more senior officer, a Captain.

Do you see where this is going?

Command, management, is a question of scaling.

Small teams can be managed by non-commissioned managers but as you group into bigger units you might want commissioned managers. Or you might pretend that your non-commissioned manager is OK. If you do there will come a point where the non-commissioned manager will not be doing much except for managing.

One of the problems Agile has right now is everyone wants to know about “scaling” but a lot of Agile thinking and literature rejects management. This problem isn’t new…

During the French and Russian revolutions the bourgeoisie (managers) were shot at the start of the revolution. And now, like Napoleon and Stalin we now find that some of the things we want to do require managers. Without a respected command structure in place we have trouble enacting decisions and strategy.

One of Agile’s “scaling problems” is that we have a mixed up view of management.