I Management Heuristics

“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 1975)

“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 1995)

“It should be noted in conclusion that management has a much greater impact on both companies and projects than almost any other measured phenomenon. The leading-edge companies that know this, such as IBM, tend to go to extraordinary lengths to select managers carefully and to provide them with adequate training and support once they have been selected.” (Jones 2008)

There are those in the Agile community who argue that Agile working removes the need for managers. They may be right, although while I see how some Agile practices may reduce the role of managers I agree with Brooks and Jones: management makes a great impact. Management may well be the single biggest differentiator in the performance of software teams, for better or worse.

I believe much of the dislike, even distrust, of managers in Agile community (and wider software development community) is not a reaction to management itself but rather to poor management. At times it appears managers and programmers are locked in an existential struggle: managers long to automate programming while programmers hope to self-organise managers away.

Teams might well be better off without any manager rather than with a poor manager. After all the bulk of the work is technical, the engineers are clever people and self-organization can be very effective.

The challenge for those who aspire to manage software development work is to ensure they make a positive contribution and do not get in the way.

Nor should one make the mistake of thinking management is only done by those with the word “manager” in their title. Many of those who work in software development take on management work and management responsibilities but they may go by the title of Team Leader, Architect, Technical Lead, Senior Developer, Senior Tester, Release Engineer, Scrum Master, Business Analyst, or some other title.

I am sometimes reminded of the military differentiation between commissioned officers and non-commissioned officers - corporals and sergeants. The commissioned managers (with manager in their title) may nominal hold responsibility but without the, usually more numerous non-commissioned officers the organization would not work day-to-day.

While managers do at time seem to make more work for more managers removing managers altogether does not remove the need for management work. Indeed the work that remains must now be undertaken by a broader group of people, all of whom need to understand management and who need to co-ordinate about their management responsibilities.

1. Management focus on teams

This book focus on teams because teams are a major part of management work: deciding what teams there should be, who should be on the team, how the teams should be tasked, organised and so on. Teams are the central unit of work in an Agile processed. As it says in the title: the means of production.

Managing modern software development is to manage teams. Creating a large piece of software demands one, if not many, teams.

This book attempts to set the management philosophy about teams. By implication this sets the management approach to individuals - they are team members. And by placing teams, and team members, - not projects, budgets, or anything else - centre stage much else either falls.

Why place teams at the centre? Because the team is the means of production. Getting teams right creates stability. In an ever changing world managers need points of stability around which they can manage. This is not to say teams and team structures never change, they will, but that when do right there is more stability here than anywhere else.

Agility comes not from having ever fluid resources but from effective units of production, teams.

Managing around teams allows managers to concentrate on bigger issues. Gather than finding their time taken up by never ending resource discussions they can focus on those things that are not stable, where their skills, experience and authority can have the most effect.

This book is concerned with the organization and tasking of teams, in other words the structure of teams and the organization they exists in. This book does not concern itself with interpersonal issues within teams and between team members. This is not because these issues are not important, they are. Rather this is because I feel the structure and organization of software development teams is a neglected area. There is more than enough to say on this topic to fill on book.

2. Managers or management?

However removing managers and removing management are two different things. Whether a team or company has managers or not there are still things to manage - or at least administer. Some Agile practices may reduce the amount of management work to be done but, paradoxically perhaps, without managers more people will need to engage in management work.

Removing the specialist - the manager - will itself only remove management work in so much as managers create work for other managers -not always an insignificant amount of work! Without specialist managers the work that remains will fall on a wider set of people.

Consequently more people need to be versed in management - the skills, considerations and decision making mechanisms which would otherwise be concentrated in the specialist manager. When management work is distributed there is a greater need for shared understanding and shared learning because more individuals need to be involved in making decisions and execute consistently.

Since more people will be engaged in some way with management work the danger of poor management multiplies. More people need to understand management, understand how a team works and share the common understanding.

Therefore whether one believes managers are needed or not in an Agile environment there will still be people who need to engage in management type thinking. This volume is intended both for the dedicated specialist manager and for the far large group who need to understand management of software development.

3. Management is not strategy

There is a surprisingly wide spread view that managers should, even perhaps do, spend their time above the daily grind. They should/do spend their time planning, formulating strategy, engaging in high-level directing and co-ordinating.

Indeed managers - particularly new managers - own belief that this is what they should be doing leads to plenty of guilt, angst and cognitive dissonance. While there may be a few managers who can elevate themselves away from day-to-day fire-fighting, decision making and daily grind the overwhelming majority do not.

Those who have taken the time to study and research just what managers do find there the difference between what non-managers think managers do and what manager do. There may even be a difference between what managers - particularly new managers - think they should be doing as managers and what manager actually do do.

One of these is Professor Henry Mintzberg of McGill University who has spent much of his career trying to understand just what managers actually do. If I may quote from one of his more recent books:

“Henri Fayol saw managing as controlling, while Tom Peters has seen it as doing … On Wall Street, of course, managers ‘do deals.’ Michael Porter has instead equated managing with thinking, specifically analyzing … Others, such Warren Bennis, have built their reputations among managers by describing their work as leading, while Hubert Simon built his amoung academics by describing it as decision making.”

“Each of them is wrong because all of them are right. Managing is not one of these things but all of them: it is controlling and doing and dealing and thinking and leading and deciding and more, not added up but blended together.” (Mintzberg 2013)

Those who are still tempted to see managing as above the fray would be advised to pause and read on of Mintzberg’s books: Simply Managing is probably the place to start (being a summary of his earlier Managing (Mintzberg 2009)). But for those who still believe managers engage in strategy planning The Rise and Fall of Strategic Planning (Mintzberg 1994) represents a tour de force destroying the myth of planned strategy.

It is because managers are part of the daily work that they can think about formulating strategy - prospectively or retrospectively. Strategy and action are not to disjoint activities. It is by being involved in action - decision making and such - that informs strategy.

More importantly strategy can only be executed by day-to-day involvement. Only by being in field, in action, in the detail, can managers have any hope of ensuring that “big decisions” actually get en acted.

4. 1000 decisions a day

Managers do engage in strategy planning, or at least strategic thinking. They do, from time to time, make big decisions. However much that is written about management tends to focus on the few occasional “big decisions.” In reality managers make hundreds, if not thousands, of small decisions every day.

It is these small decisions which constitute the guts of managing.

“the job of managing is significantly one of information processing, especially through a great deal of listening, seeing and feeling, besides just talking” (Mintzberg 2013)

It is the many small decisions which implement the few big decisions.

It is the small decisions which cummulatively make the big differences.

True, a few big decisions can be helpful to ensure that the small decisions are aligned, that they collectively make sense and are consistent. But perhaps even more important it the managers’ own beliefs, values, philosophy and logic which inform these decisions - some of which need to be made under extreme pressure and without the benefit of hard data or time to think.

5. Why management heuristics?

Management occurs within a context. It is not based on a set of if…then rules, or rather, management might be ruled based but the number of considerations, forces, pressures and constraints which must be examined is so large as to be beyond comprehension.

This then is an environment in which heuristics, rules of thumb, can be helpful. Such rules of thumb should guide decision making but they should not bind it. The heuristics should bring about consistency but they are not complete. Judgement and intuition need to be applied too.

There are so many variables in management work that it is rarely possible to formulate firm and fast rules. Indeed the time required to do so would probably make it a never ending task.

However there are common variables, common pressures, common forces and common environments. Within a software development environment there are decisions which crop up again and again.

Management cannot be programmed. It is not possible to give invariant rules but it is possible to give heuristics.

And, perhaps more importantly, it is possible to share ones own philosophy in the hope of educating another. At the very least the stories and heuristics in this volume should help those who practice management reflect on their own decisions.

6. Why Xanpan?

I have chosen to name this book “Xanpan Book 2” I could easily have named it “Agile Team Management Heuristics” or just “Heuristics for Managing Software Teams.” Instead I have chosen to make an explicit link to Xanpan. While this has certain marketing advantages the main reason for doing this is to provide a base for the book. By building on this base I can avoid digressions into discussions of iterations, quality, etc.

Many of the issues which I intend to discuss in this book have already been discussed in one form or another in “Xanpan: Team Centric software development” (shortly to be renamed “Xanpan Book 1”). This book builds on that base.

Although it is not essential for the reader to be familiar with “Xanpan Book 1” those who are not may find themselves needing to reference it from time to time - the alternative is for me to repeat myself.

Indeed I believe many of the heuristics presented here about managing software development are applicable whether a team is following Xanpan, generic Agile, Scrum, XP, Kanban or even a traditional “Waterfall” type development process.

That said, those who already “think Agile” will find the book easier to read; and those who “think Xanpan” will find it easiest of all.

7. Finally: Heuristics and philosophy

This volume strives to offer a set of heuristics for anyone involved with managing software development. These heuristics might not be the most important - although I hope they are. These heuristics might not address the most common areas - although I think they may well do. These heuristics are drawn from the conversations I have again and again with managers of software development.

Heuristics are useful, however the first heuristic for anyone charged with managing software development must be:

Develop your own philosophy of software development.

My own philosophy has already been laid out in Changing Software Development: Learning to be Agile (Kelly 2008). Those who have yet to develop their own philosophy are advised to read widely and reflect personally and with others.

8. References

Brooks, F. 1975. The Mythical Man Month: Essays on Software Engineering. Addison-Wesley.

———. 1995. The Mythical Man Month: Essays on Software Engineering. Anniversary edition. Addison-Wesley.

Jones, C. 2008. Applied Software Measurement. McGraw Hill.

Kelly, A. 2008. Changing Software Development: Learning to Become Agile. John Wiley & Sons.

Mintzberg, H. 1994. The Rise and Fall of Strategic Planning. FT Prentice Hall.

———. 2009. Managing. San Francisco: Berrett-Koehler Publishers Inc.

———. 2013. Simply Managing. FT Publishing.