Analysts aren't managers

Continuing from my last blog, Managers who aren’t managers, I need to say a bit more about people who aren’t managers but get talked about managers.

This is a group of people who aren’t managers and wouldn’t consider themselves managers but programmers and testers consider to be managers. I’m thinking specifically about Business Analysts but there are others.

To a programmer, who rolls in at 10.30am wearing old jeans and a t-shirt to spend the whole day communing with a machine, well, a Business Analyst looks like a manager. The BA is smartly dressed, they meet “customers” and “stakeholders”, they write documents, they tend to keep business hours - because thats when the people they need to speak to are available!

OK, I’m pandering to the stereotypes but you get the message. In my experience a lot of programmers and testers wrongly consider Business Analysts to be Managers. They are not.

Interestingly if you hang around with Business Analysts and listen to them you will find that most of their concerns are the same as the programmers: not having enough time to do their job properly, being overloaded with work, not being listened to by their managers, and so on. But the two groups often end up antagonising each other.

What I’m getting at is this: there are a lot of people who are mistakenly thought of as “Managers” in a software organization.

This is important because when we start talking about self-managing teams and teams without managers these specialists often seen as part of the general problem with “managers.”

There may even be some people who are happy to make this mistake: some programmers I have know think they can do a better job than the business analysts or product manager they are working. Some of them may be right - they should switch professions. And a few of them would see these specialists wiped out at the same time as whip-cracking managers.

If we are to remove product managers just because these requirements specialists have the word “manager” in their title, and remove business analysts just because they dress smartly and go to lots of meetings, then why aren’t we removing JavaScript specialists too? For that matter database specialists and anyone who doesn’t write in the chosen language should go!

True, software development tends to work better when people are prepared to do what is needed - coding, testing, requirements gathering - rather than stand on demarcation lines and declare they won’t test because they are a programmer.

Staffing a team with people who have multiple skills, who are multi-functional and do what is needed to help the team is great. But…

It has its limits.

Few C++ programmers have the skills (or want) to code JavaScript and even fewer JavaScript programmers have the skills to code C++. The same is true when it comes to Testing, Business Analysis, Product Management and a host of other skill sets.

Just because someone’s skills set means they hold a job where they don’t code does not make them a manager.

Managers who are not managers

I’m continuing my theme of management from my January blog (“It takes an engineer to manage engineering”) we need to clear up some terminology.

I often hear form people at Agile conferences that we should get rid of managers but they offer up no definition of manager. Let me suggest that the title “manager” is thrown around quite lightly these days, its probably just title inflation but it causes a lot of confusion. When people say “get rid of managers” I think they are usually referring to “people managers” specifically “managers” who take on positions of authority over others.

The problem is an awful lot of “managers” aren’t managers in this sense. Putting the word “manager” into a job title has a habit of making it ill defined. The same is true in code, a “SecurityManager” class or “LogManager” tend to be a dumping ground for all sorts of vaguely related functionality. Those who truly manager often find their job is a lot of vaguely related bits and pieces, thats the nature of managing.

But the title a lot of the people we call “manager” could more accurately be called “Specialist”. So you might have a “Product Specialist” or a “Release Specialists”

We have Product Managers - they don’t manage people they “manage” products. That means they talk to customers, analyse the market and, after some magic, decide what to build into a product. Its become a bit of a catch-all role. These people could better be called “Product Specialist” or still “Product Analyst.”

The same goes for “Release Managers” who don’t manage people, they administer release processes and do release engineering. They might be better titled “Release Specialists”, “Release Engineer” or “Release Administrator.”

Then there is that vague role of “Iteration Manager” I know they don’t manage people and frankly I don’t know what they do. The role only seems to exist at ThoughtWorks and former clients of ThoughtWorks but I bet it could be better called “Iteration Specialist” or “Iteration Administrator.”

To put this graphically: we can think of the set of all the people called “manager”, of these a significant portion aren’t really managers, they just use the title “manager.”

Specialists like this exercise power and make decisions not because the organization has endowed them with power but because their specialist knowledge and skills makes them the best person to do so. (Well, thats the theory, I’ve know a few who exercise power because the organization has endowed them rather than because they are particularly knowledgeable or skilled.)

Correctly naming these roles would help. Alternatively it might also help to abolish title altogether. I’m told that at the old AT&T Bell Labs everyone had the title “Member of Technical Staff.”

Harmonising title - “Team Member” or “Engineer” - appeals to me, it would break down some of the demarcation lines which inhibit people from doing what needs doing.

However people like job titles because titles form part of their identity, it describes how they see themselves and adding “Manager” to the title makes it sound more important, ones career has advanced when one has “Manager” in the job title!

(I’ve blogged about identity before, in the dim and distant past, but the two entries stand up “Who are you? - identity and change” and “The Dog and Duck is closing”).

Titles help people mark out the area they work in and the tools they bring to the job. It indicates who they associate with. However it sometimes seems that people are more concerned about proving that people in their role can save the day (another old blog “What you need is a…”).

So in summary… it is complicated, the title “Manager” does not mean someone manages anyone, anything or has any authority. Once again, look beyond the label.

Podcast with about Business Analysts in Agile

Alex Papworth runs a Facebook group (closed) called “Be a Brilliant Business Analyst.” He recorded an interview with me a few weeks back which is now available online.

Agile and the Business Analyst role

I should also point BAs and aspiring BAs at Alex’s newsletter.

And it would be a miss of me not to mention the “Agile for Business Analysts” course I’m running with Learning Connexions next month.

It takes an engineer to manage engineering

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

Why not?

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

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

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

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

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

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

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

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

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

My logic is this:

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

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

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

The thing is…

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

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

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

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

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

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

You see: it takes an engineer to manage engineering.

Summary

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

The staffing pyramid

When I see development teams I expect to see more programmers than requirements people (BAs, Product Managers, etc.), and I expect to see even fewer management types. Think of it like a staffing pyramid structure:

Programmers (and often testers) should form the largest group, without programmers there is no software, and while in an ideal world there is no need for testers the reality is the absence of testers is usually a sign of problems, though not always, I’m not the only person to have observed high performing development teams where there are no testers but these are the exception.

Although you occasionally here stories of IBM or Microsoft employing more testers than programmers I’ve never seen this situation the nearest I’ve come to it is teams with 1 tester for every 2 programmers. The number of testers to programmers should be a function of the initial quality produced by programmers but it more often than not a function of how seriously management takes testing and the regulatory environment the company operates in.

Anyway, programmers - the people who produce the raw produce, source code, should be the largest group. Testers are a little way behind but together these two groups should form the bulk of the development team. After this I expect to see some requirements people (Business Analysts, Product Managers, Product Owners, Requirements Engineers, what ever titles they go by.) There may be some other people in this mix: customers, business sponsors and so on.

(Conceptually user experience/design people are the same layer as programmers but usually they are there with requirements people. Either way, you don’t expect to see many of them and they certainly shouldn’t outnumber programmers on a team.)

On top of this there are a few management types, whether these be project managers, development managers or some other type of manager is not important. I know some people want to remove all managers, I don’t agree with them but I do agree there shouldn’t be many.

In a healthy team there are lots of doers (programmers, testers, UXD), fewer people feeding these people (requirements) and even fewer people managing everything. Requirements people and managers act as a multiplier to programmers (doers), these guys lay the golden eggs, by organizing them well, and asking them for the right golden eggs the value of the golden eggs should be higher.

By the way, when I talk of people I’m thinking absolute numbers, not “full time equivalents” or even “full time dedicated staff”; the people higher up the pyramid may well be multi-tasking. Whats important here is not the time devoted to a piece of work buy the number of voices who have a say in what happens, the number of people who have a finger in the pie. So part time people, those with dotted lines, those with responsibility and concern but no responsibility, they all count in the pyramid numbers.

And then…

Periodically I meet companies who have an inverted pyramid: this is almost always a bad thing, a really bad thing.

In the extreme there is one programmer at the bottom, no testers, and lots of people who have an interest in what is being created. Lots of people who have views - they have Product Owners AND Product Managers AND Business Analysts AND Subject Matter Experts AND Business Partners AND Requirements Experts, Project Managers AND Development Manages AND (maybe) Team Leads.

These pyramid seems to come from a mentality thats says:

Software development is really expensive, and really slow, and really painful, and so we must absolutely do as little as possible and

Many of these people who have a finger in the pie of “what is built” are part time to the work, they have the right to interfere but no responsibility for what happens. Work takes years to get started and never seems to finish - perhaps the developers are split between projects.

When I see the inverted pyramid I feel these companies are scared of their own shadow. I’m reminded of the old Woody Allen joke about the two old women at a restaurant:

First lady: The food here is so awful

Second lady: Yes, and the portions are so small

To be brutal - and to repeat something I said in Business Patterns: when you are developing software there is only one role which you absolutely must have, programmers. All other roles are optional, or perhaps context specific. (Even if you outsource the actual coding there is still a programer, if there is no code there is no program, with a programmer somewhere it is not software development.)

The programmer is the role which makes the product, they are the ones who lay the golden eggs. If you have no one to lay the golden eggs then it doesn’t matter how well the other people push paper there is no value creation. (For Hitch Hiker Fans: programmers are on the C Ark, everyone else is one the B Ark.)

Agile adoption by numbers - and some problems

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

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

My answer went something like this:

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

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

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

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

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

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

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

Not here: From diseconomies to economies of scale

Just a note to say my latest ramblings “From diseconomies to economies of scale” were blasted out to newsletter subscribers yesterday. If you are not on the newsletter list you can read a copy on the Software Strategy website - or better still subscribe to the newsletter and you’ll be among the first to hear.

Right now my writing energies are going into the newsletter, Little Book of Requirements and User Stories and 50 Shades of Scrum, so this blog will be quiet for a little while yet. Sorry.

Dear boy, have you ever tried programming?

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

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

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

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

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

To which Olivier says:

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

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

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

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

“Plans are worthless, but planning is everything.”

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

“No plan survives contact with the enemy.”

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

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

So let me say:

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

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

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

Book of the Year

I’ve been asked by several people lately - mostly for their own blog posts! - for my book of the year. Well thats easy…

From a professional point of view, that is, if you are asking me as someone who advises software developers and teams, and is well know as an “agile supporter” then my unreserved book of the year is… drum roll…

Scarcity: The True Cost of Not Having Enough by Mullainathan and Shafir

I wrote longer review of the book back in June, “Scarcity, not Slack.”

#NoProjects: videos + Q&A

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

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

I have also been directing my efforts at another Beyond Projects endeavour: the Managing without Projects one day workshop which I will be holding in London (Bloomsbury) next month (Friday 15 Jan). I’ve got a few people signed up for this and I know a few more bookings are in the works but the more the merrier so please come too!

Blog readers can get a 10% discount on this workshop with the code BlogDec15 which is good for the next week (until 14 December.)

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

Q: Isn’t “No” rather negative?

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

For a while I preferred the name “Beyond Projects”

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

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

Q: Is #NoProjects actually #NoEstimates?

A: No

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

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

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

I should expand on this another time.

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

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

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

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

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

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

Q: What about Project Managers?

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

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

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

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

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

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