Brave new world?

Organisations should be interested in Scrum adoption, because there is something to gain. Incidentally a reduction of pain, would be concomitant. So what are the common benefits?

The benefits are significantly better quality and productivity, but there  are a handful of other important benefits(possibly even more important):

1. Focus (reduced re-work/confusion, therefore happier floors)

2. Higher possibility of building the right product

3. Speeding up learning, which increases the rate by which previous benefit is accrued.

Coming back to the topics of productivity, I’ve personally helped teams increase it in the range of 30 to 60% and am convinced that those teams can do even better. So the claims of a 200% increase in productivity by some others are not necessarily codswallop. (However I’d caution against productivity becoming the MAIN/ONLY goal of adoption.)

It is surprising how few organisations are able to realise these benefits; this is often due to management not really holding teams (the WHOLE team) accountable, and, not creating an environment where quality is key and teams, SM and PO are empowered.

It’s a nice new world, if we can get there; Not simply the ‘brave’ new world.

(For those who haven’t read Auldous Huxley’s classic, ‘The Brave New World’ is a dystopian novel with prescient – I think – warnings on modern human societies, which are technologically advanced)

Advertisement

Do we need any manager at all?

“We” doesn’t include the manager set, naturally. After all managers need micro-management.

While closing the previous post, I referred to some of my acquaintances debating the need for the existence of the manager. Many seemed dismissive of the species and wanted it extinct, at least in the s/w development world. Before we go into merits of this view, please indulge me in a small digression I make into pop-psychology.

People who wish to get rid of managers, or like to have nothing whatever to do with them, suffered some traumatic experience in their third year of childhood (employment). They’ve had to weather that marvellous (in the sense of incredulous, NOT beholding a marvel) pointy-haired boss, who makes ignorance sound like a point of view. Having come across this wonder, as the initial disillusionment faded, they developed a deep-seated revulsion for managers in general. Personally I’ve been fortunate, all the chiefs I served under, with only a few fleeting abnormal blighters, knew their stuff and had my respect. However I’ve met and indirectly experienced a lot of unmitigated disasters in the past. My litany of woes would be substantial, as a consultant, one meets more than his fair share of ‘managers’. Truly, at least, in this country, we have a surfeit of this species who combine woolly headed short-sightedness, with self aggrandisement and superficiality. This is becoming something of rant, so I’ll take up a more constructive stance. Also to put the record straight, about one third of the managers, I’ve met, are reasonably knowledgeable, are able to tackle various problems competently and are positive contributors. What of the other two-thirds?

Coming to the Outrageous Q; “Why do we need managers in software development at all?”

Another line to take is that, in creative endeavours like programming, there is no place for a manager, and the teams who do the work must be self-managed. This is a pillar of Scrum. My observation is that much of programming activity in organisations, needs no more creativity than necessitated for the making of a Hollywood movie, or for that matter a Bollywood one. Of course if one doesn’t have much knowledge, and resorts to re-invent the wheel…However, retreating from this cul-de-sac and attempting to answer the original Q, some disinterested analysis is what the doctor ordered.

So we can just have self-management and get rid of managers all together?

Conceivably, yes, if you dance to the music of holacracy. Not even a long shot, if you happen to lap up the pearls cast around by management gurus. For the members of the former party I recommend “Simply managing” by that doyen of management Prof Mintzberg and for the latter Ken Schwaber’s “Enterprise Scrum”, Holocracy.org and “Maverick” by Semler. Naturally with my Scrum tinted glasses, I lean towards the latter party but make no mistake, Prof Mintzberg really knows what he is talking about, his articles/books are very edifying. Many people refer to Valve and Netflix as pioneers, but the ideas of self-management were implemented consciously much earlier in Semco Brazil.

Not everything happens in the LOO (private joke for the benefit of my friends).

If by any chance you are in the PMBoK boat  while also in the software dev boat, get out of at least one. One foot in either boat isn’t a good long term plan.

Let’s try to make another stab at understanding. It is more fruitful to separate the noun “manager”, from the verb “management”. Surely all right thinking men (or is that left leaning women) would agree management is needed, even if, for a moment we feel managers themselves are a waste of space. So the Q boils down to: “Can all management be covered by self-management?”. Stop and mull this over. It looks much less of a pragmatic option and more of a very long shot. However, it is also true (from my reasonably wide experience) that we have a lot of worse than useless managers in our industry, so why is that? Incompetent managers hire even more useless managers, who revel in their own power, however undeserved. Living in a bubble, they are unaware of various progressive views of project mangement, software development, culture, human relations, software process etc., instead such managers use a cliche driven, jargon supported approach to management.

[ True story: I’ve witnessed senior managers of a software services company describing the deletion of 10 or so source files in their entirety from the system as refactoring, BTW there was no other adjustment made in the retained code. Then adding injury to insult their teams couldn’t get the software to build. It beggars belief, but gets worse, they tell the client (who incidentally understands modern practices reasonably well) that the problem is “we can’t get back those files as they have been deleted, it’s going to take time to recreate those files ”. These wonders haven’t really met with version control. There is a version control system in place, but they understand it as well as they understand refactoring. I advice my clients to only hire bald males w/o heart conditions and low BP to oversee such vendors]

This is all a particular manifestation of a broader issue which Plato and many of his forefathers have been grappling with: “why is it that human systems result in so much travesty?”. Human organisations, by definition, will be subject to humans. So unless these humans are of unshakable virtue, all pervasive smoothness and light is but a pipe dream. BTW, even self-management is done only by humans. All very encouraging and invigorating, but then we need not lose hope, as self-management is surely a step in the right direction, even as it co-exists with other forms of good management. And for self-management to succeed it must be bounded, with opportunities for course correction combined with visible feedback, in other words an environment which encourages improvement.

In fact the only way forward is more education and transparency; both for the team members and managers. (When was the last time a senior manager spent a week learning something new in depth?) These enable better understanding and slowly induce better behaviour, at least on the average. It is a slow road, the human race progresses all the way dancing a peculiar slow dance, two steps forward and one step back.

In conclusion, we need self-managing teams who are consciously under managed from the outside, while complementary management is done by others (maybe, managers of a particular breed) keeping long term goals in view. This upper management should be continually challenged to provide a lovely work environment where everyone is in the game of doing better still than yesterday.

 

Interesting Links:

Prof Julian Birkinshaw talking about management  This may come as something of a unsettling surprise to managers in India

 

Steve Denning on Radical management

 

Incidentally both the gentlemen are part of the Stoos network(so am I)

 

Why do we need self-organisation when we have micro-management!?!

Good question!

I’ll try to explain, while avoiding a close coupling with Scrum, though some tangential references may well slip through. Let’s start by considering something which is going to be familar to the gen-X managers: Pseudo-code, a key step in structured software development (or defined s/w dev processes). As the design phase is winding down, the last level of detailing was being filled in by way of pseudo-code. Pseudo-code: a detailed description of steps of a computer was supposed to execute, but not in a programming language. This was to be simply translated into code, by a worker bee (programmer) into a computer language, viola, ofcourse we have a flawless system. The need to write pseudo-code for someone else (the worker bee/mule) is, an admission if only latently, that we are hiring dimwits. If we follow this train of thought, another conclusion looms: usage of psuedo-code is a strain of intense micro-management, and a failure to understand the real nature of programming (at least programming in the small). As an aside: devotees of big-upfront design may have diagnosed correctly, that programming in the large, brings about its own set of problems; However they have unfortunately taken the wrong pill. They can detoxify, by reading Jack Reeves thoughts on software design. BTW, the gentleman, has nothing to do with the agile jamboree, just a very clear sighted (an endangered species) thoughtful, software developer. There is nothing wrong with a limited amount of upfront design, as long as we don’t try to develop the ‘perfect’ solution, while keeping in mind that this upfront design is just a draft, which can only be final, when the software works! (testing time, anyone!?!). So, unavoidably, we have to grapple with all sorts of detail, where the devil is hiding. So who is going to do all that grappling?

This brings us nicely to consider micro-management of teams. Serious software development takes place in a far more complex and fast changing environment than ever before. The work is highly interconnected with frequent changes (and surprises) streaming in. Many competencies are involved, with many things having to come together for a a successful result. It is impossible for one manager to do all the basic thinking and detailing. Much of the simple software has already been built, and most worthy teams are left with the implementation of involved software solutions. Therefore, the manager in question has to continually re-issue instructions to the team as events occur, surprises spring, lessons knock hard and the real target (software we need, as opposed to have wanted some time ago) reveals itself. It is, I’m afraid something of a losing battle.

Instead, the manager must work more as a facilitator, who ensures that the necessary resources and tools are provided to the team, and that impediments to team deliverables are removed. Having done this, it is best for the manger to get out of the way. It is not the manager’s job to order the team around; rather, it is the team that decides on how much to commit and how to deliver (from the top of the product backlog).

Breathing down the team’s neck and micro-managing it from the outside sends a signal that the team is not responsible. It then becomes the manager’s job to commit and then worry about how to get things done. This limits productivity, innovation and creativity in the team, chokes communications and, in time, results in disengagement and apathy. Actually this state of affairs is so widespread that it is the new normal.  That is why, we should encourage self-management.

If ownership firmly rests with the team, there is greater focus, sense of responsibility and motivation to perform. Let the team manage itself. The manager’s job is to keep the focus on the bigger picture and help if the need arises. At the same time—and paradoxical though it may seem— the manager must not lose sight of the critical details (important when teams are dealing with the rest of the organisation).

So, get your team together, emphasise goals, facilitate learning, offer to help, make it clear that you are watching and then,…let go! You should rather be spending your time to prepare for a role at an n+1 level than get bogged down with the details at n-1. Potentially a depressing corollary, is that one circumstance micro-management could succeed is where the project on hand is relatively straightforward! So, maybe, that project you are so successfully micro-managing, is just a run of the mill work, where low intelligence finds a comfortable home. It would also be interesting to know what you think of the BBCs advice on micro-management. Actually if you think about it, many managers cannot even really micro-manage, but try to give the impression that they are on top of things. A waste of energy, time and in acute cases, even space.

Therefore, in general, I advise eschewing micro-management, but hold your breadth, further flutters await you….

Some thoughtful birds in my circle of acquaintances, debated over the need for managers at all (in all shapes and forms !?!). I’m all set to write about that as well, in a day or two.

Reverse Viennese Syndrome

Happening to read this, I was struck by how many people (within ICT industry)  in India have the reverse problem. As a Viennese resident remarks- “If you live here all the time, you have nothing to compare it to – and you don’t know how good you’ve got it.” or to paint a picture for a reverse problem “…. and you don’t know how bad you’ve got it.”!

I relate to this due to a similar personal experience on my first visit to foreign shores (London) when a local remarked how polluted London was. Arriving from Bombay (Mumbai), I remember thinking the poor fish lacked sense of any sort. But maybe it was me who lacked perspective.

What has all this to do with Scrum? Many, many people have no idea of how a well chosen and tended team can feel, perform and delight all. So many projects are in a death march mode or in an apathetic semi-daze for so long, that such a state seems normal! Just as the Viennese are inclined to overlook how well off they really are in their city, the s/w dev teams here are not exposed to how well (comparatively) things can be run.

Is this a plug for Scrum? Partly, but mainly it is an attempt to show that there are much better means to live within a software development project.

Is this relevant to the times? Yes, in spite of  all the huge numbers of people claiming to use Scrum, the percentage who do it properly is very small indeed. Scrum-but will not make your life better, Scrum will.

I’ll attempt to provide a sense of how one can help people see a brighter horizon. Most software development teams are under pressure to deliver on very optimistic estimates of poorly thought out functionality. On top of this teams will quickly settle into a habit of creating poor quality functionality.  All this leads to continuous rushed activity that results in comparatively little progress.  This is why people spend late nights in office. How they use their time in office is another story.  However too much overtime over extended periods will be accompanied with lower mental efficiency and strong tendency to make mistakes. Why do you think in competitive sports each team tries to put the other under pressure? To encourage mistakes of course. What are managements doing when they put pressure most of the time?

First thing you need to realise is that a normal day needn’t be tense and rushed. It can be comfortable but purposeful. Good planning to deliver a reasonable amount of functionality will provide best results.

A cross functional team results in testing being done very close to development, which means that we get a lot of feedback within a sprint. Also multiple perspectives help in detection of mistakes earlier.

More importantly we get serious external (customer/customer-representative) feedback at end of every sprint. Therefore we come to know how we are doing from a very early stage. At every step of the way we have a chance to improve at a reasonable pace. This is almost a dream in a waterfall project. Everyone pretends they are already very competent or even perfect. Then at the end, when they all are floundering, and then it doesn’t end….

Where as in a a well tended team, the support every one gets  is very enabling,  a good ScrumMaster is there to see to it. It provides a high level of ‘safety’. This supports people to very quickly get better, be open to learning from their mistakes. These may or may not be mistakes of individuals, but a culture of blaming one another is strongly discouraged.

To summarize: A good project delivery structure (delivery and feedback every sprint), a supportive cross functional team and picking up a reasonable amount of work per sprint will together result in a steadily productive, yet comfortable feel for Scrum projects. Do it properly and you’ll then realise how badly you’ve been having things for so long.

Developers are people too!

I happened to come across this absorbing article: Whales are people too! and in then the word speciesism (a one word tongue twister, say it out loud, quickly, twice in a row!)

Now, I’ve lost of count the number of managers/executives who proudly say that their organisations are doing Agile (whatever that means ) and refer to people as ‘resources’. In light of Mr D. Adams’ observation (that humans are the third most intelligent species on earth) it is possible that these enlightened managers are right after all. We are all resources.

However, on a serious note, it is worth considering, since dolphins have a strong claim to rights, if our developers also need some rights.  Also more pragmatically, always keeping  this in mind makes management effective, and true; Not a wished based glossing over the real people development and attitude issues and avoiding necessary but difficult conversations until it’s too late. A team of people, are not simply a summation of individuals, and their interactions can easily be unpredictable, someone leaving the team, could result in a productivity increase, or even velocity increase. If only developers were people.

N.B: Prima facie this is tangential, but on second glance quite central to Scrum. In this article I’m not being sarcastic, but tongue-in-cheek. (Note on N.B to some readers: These things have to be explained to most ‘resource managers’  in the ICT industry)

Scrum as a transparency mirror

My experiences of coaching teams and hand-holding organisations in taking up Scrum have revealed a curious inductive pattern depending on the type of work environment. A group which is generally genuinely responsible and transparent would take to the practices of Scrum in letter and spirit, like a duck to water. However, equally true is the case of an organisation/group wallowing in apathy and complacency. Such organisations have a very large portion of managers who are essentially set in their ways and have an overriding (but short sighted) interest in maintaining status quo.  Any change makes them deeply uncomfortable. It takes time to understand just how deeply buried this resistance is in the sub-conscious of such managers. They are befuddled and unable to view a very different future which at the same time is frighteningly unfamiliar with any enthusiasm. As someone said “the raison d’etre of middle managers is to resist any improvement”, which implies that the management layer has been set up to run a bureaucracy and not an ever improving organisation. This in itself is a very dismal revelation and an example of what Scrum uncannily exposes: Your management is less than useless, they are actually a liability. Their only use is to run things in the same chaotic manner today and tomorrow and the day after…and their weapons of choice being pressure and manipulation.  The reactions of managers who are suddenly confronted with Scrum, something that requires much greater transparency and direct execution, ranges from apathy to passive resistance to delusional arguments and even the dismissal of the entire idea of Scrum as unworkable (however without a clear line of reasoning based on knowledge).  So the questions to consider are: are you prepared to make deep, possibly unsettling changes for a better tomorrow? Will you do it by infusing a truly transparent culture? (Transparency need not mean surrendering your trade secrets; It first of all means being honest to yourself).  You will in all possibility have to catch the pig! And Scrum is an excellent means and in this manner of engendering transparency, is an end in itself.

Benefits of Scrum (jargon-free)

I just happened to read Tobias Meyer’s insightful article:  http://agilethinking.net/essence-of-scrum.html and suppose describing the results of teams/organisations doing Scrum  would be an useful addendum.

The primary benefit is significantly better productivity, but there  are a handful of other important benefits(possibly even more important):

1. Focus

2. Higher possibility of building the right product

3. Speeding up learning, which increases the rate by which previous benefit is accrued.

Coming back to the topics of productivity, I’ve personally helped teams increase it in the range of 30 to 60% and am convinced that those teams can do even better. So the claims of a 200% increase in productivity by some others are not necessarily codswallop. (However I’d caution against productivity becoming the MAIN/ONLY goal of adoption.)