Reverse Viennese Syndrome

2 Comments

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!

1 Comment

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

Leave a comment

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)

2 Comments

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.

Follow

Get every new post delivered to your Inbox.