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)

 

Advertisement

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.

Management 7.0

You might have heard of management 3.0 or was it 4.0 !?! … in these inflationary times, I just have to bring you the latest.

The trigger for this post was the panel discussion at India Agile Week (IAW), 2014 event held in Bangalore last week. I was part of the panel discussions, sharing space (and the mike) with Mr . Tathagat Verma (aka TV), Mr Manish Mishra and Mr Raj Stanley.

We discussed a variety of topics and issues. The exchange was interesting and informative. At some point,  the role of  managers came up and TV remarked that managers are rewarded for doing (more of) the same tasks/activities. They do not have an incentive to innovate.

TV could not have put it better. This is how it is. This view of the manager’s role is so trite, that such a mode of working and the resulting work environment is seldom questioned,  let alone overturned.   Nevertheless a more mature view of management (and one that Scrum espouses) is that “Managers are not there to make the inevitable happen”. A well- written explanation of the manager’s role is at http://www.goodagile.com and much material on related ideas can be gleaned from http://www.stevedenning.com

At the conference, there was a comment/question about the lack of conclusive answers as to how team appraisals can be conducted as well as redefining the role of  managers . In such a case, due consideration must be given to long-term  planning and changes  needed in “agile”.

Lack of time precluded a detailed explication. However, the Scrum community has had some well- formed answers to these Questions for sometime. Briefly,  appraisals are team based (with 360 degree feedback) with the manager providing a conducive environment for self-organised teams to flourish. Long- term planning is done based on an aggregation of current team capacity to deliver working software increments. Each of these can be the topic of a post in itself, and I intend to share my views and information in the coming weeks.

 

 

 

 

 

 

Event report

A bit late, but I did attend the event  mentioned in the previous post. It was time truly well spent. So here is the report, with a bit of opinion thrown in.

The highlights were the talks by Dr Wintersteiger and Mr Tathagat Verma.

Dr Wintersteiger gave a very interesting talk on the landscape and development of this whole Agile business, around the world, including India. One of the key points is how the management approaches are still very 20th Century, while the behaviour as well as aspirations  of organisations, teams and indeed the younger generation of people is very different. How seating and office ambience is very different. This got some people thinking and there were questions during the panel discussion I’ve mentioned Lynda Gratton’s recent book. This discusses the changing nature of work and makes some predictions (not all of them brand new) and offers a sane way forward. Worth a read, even though I think the LBS fraternity generally tends to provide examples from large pedestrian and traditional companies. Q n A session at the end of Dr Wintersteiger’s talk was absorbing (yours truly asking many questions)

Tathagat’s talk was very interesting. Generally when people talk about/of Agile, I tend to go into an semi-slumber, often punctuated by mild irritation and sometimes dislike.  For a change it was a an enjoyable and informative talk. Excellent examples, context setting and explanations. Not common at all these days. I even learnt something very useful. He (With help of Linda Rising) explicated what is meant by mindset and what a mindset constitutes of. This word is used commonly but without a lot of understanding (A bit like ‘agile’, eh?) .  He compared the fairly opposing mindset of companies/people. This understanding is actually very critical. I hope everyone is better for this.

The rest of the conference was fairly decent, with Mr Nitin Dhall giving a very nice talk and honest (hence useful) QnA at the end. I’ve not attended a lot of other talks (which may very well have been wonderful) as I was busy talking to people whose interests overlap with mine.

Ciao

 

P.S: I’m about to give a talk at an internal conference and have half a mind to report on this as well.  But then I think enough of general reports, I’ll see if I can write on a particular problem/area soon.

 

 

 

 

 

 

 

Interesting Event brewing and opinion

Disclaimer: I normally avoid pure opinion, but here goes.

 

There is a conference brewing in Delhi. On 29th Jan, Unicom is hosting a conference on “Agile in Business“. It promises to be interesting, particularly the first two sessions of Wintersteiger and Verma. I’m certainly curious about what will be presented on the Indian Landscape-past, present, future.

Curious I certainly am, since my first real immersion in XP in 2001 in Ireland (one of the first larger XP projects in Europe),  it has taken a really long (about 10 years) time before any of these new wave approaches have gained currency in India. Only a couple of mid sized companies in India, even into the late naughties, did anything like what we did back then. I still meet far too many people here (India) who do Scrum badly and then say “oh we know/do Scrum”. Fortunately there is a minority which is interested to really learn this well. Now most people have heard of these methodologies…

However, the point is, at least as far as Scrum is concerned, far too many people are all too ready to say they do it. Most organisations gravitate to ‘scrum-but’ all too readily. The last couple of years has seen much dilution in the in-depth understanding of scrum. More and more discussion takes place around how Agile adoption fails, or how to do “Hybrid” or some such. All this at some level assumes that teams and organisations really understand how to use Scrum as a framework for delivering the best possible results in projects. There is no such evidence. I think Ken Schwaber’s estimate that only about 30% of teams will learn and use Scrum to achieve success. I’d say here in India the percentage  is smaller still.  I look forward to these sessions and hope to report later on.

 

 

 

 

 

 

 

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.

Case for starting with longer sprints

At last something reasonably sensible here, from a big Indian services company regarding Scrum. I say reasonably, because the conclusions arrived at are largely correct, whereas a couple of points made in support reveal an underlying thinking which is slightly questionable. I shall proceed to answer the Q of an “ideal” sprint length before returning to take apart the article referred to above.

Most Scrum teams use two week sprints and a few even one week sprints.  In some organizations where iterations have been about 3 months, or more in length or even worse a classic waterfall (Before Scrum) teams have a real problem starting with two week sprints. Much of this is in the mind. It is common for people in such projects to feel (or even ‘know’) that nothing can be achieved in two weeks. So, there is considerable reluctance to pick a two week sprint. Now the question is what should be the length of the first few sprints?

Something of a storm in a tea cup, is how I see it; There is no doubt in my mind that a two week sprint (with suitably small units functionality as backlog items) is what the doctor ordered. However in these times of diminished authority, quite a few people seem to duck clinical instructions, let alone heed good advice. So, a logical (at least superficially) decision is made where in a much longer sprint length is chosen.  If it were of four weeks, that is still within the rules of Scrum, but not a good choice. I’ve even seen a two month sprint taken up as how to proceed with Scrum, which  really is a marvelous illustration of how NOT to do Scrum. Basically the underlying problem is once again the lack of realisation that Scrum is really a rather radical departure from the traditional waterfall way of completing projects. Not an embellishment of the old ways of working with the latest jargon, minus the real intent, which in turn simply results in Scrum-but.

So why is a long sprint three weeks or more a problem?

1) Loss of feedback (course correction opportunity): Essentially there are fewer opportunities for the PO and functional stakeholders to get to know the growing system and provide feedback.

2) difficulty of holding on to the “NO CHANGE RULE”, particularly the part where the sprint goal has to be held fixed; i.e no changes to the stories picked up by the team at time of SPM (sprint planning meeting) are to be allowed, is increasingly difficult to maintain as the length of sprint increases.

3) Effectiveness of retrospective: One of the most important environmental conditions for a good retrospective is that people should remember what happened during the sprint. The only other even more important condition is openness and assurance of safety. Most people cannot recall many (unremarkable, but important) details beyond last week. That’s a two week span. So once a sprint is longer than two weeks, we have a memory retention problem, unless the team maintains a detailed activity log. Yeah right!

4) Reduced planning effectiveness: As the time horizon increases, it becomes more difficult to plan for the entire timebox. It is substantially more difficult to plan a longer period of activity realistically than a short one. A weakness of long term planning ability exists in most software project groups.

In fact all the above means, it is imperative that teams improve their ability to plan (a major underlying factor is estimation, but that is another long story), make progress, correct and then build upon what has already been achieved.  Basically do the “inspect and adapt”. So in a way more opportunities the better. Hence a shorter cycles are better.

OBERVATIONS on the Cognizant article

(Overall I think the article is well written and has many aspects covered well)

Pl refer to table in the article.

A flawed line of thinking here is “Adaptation to uncertainty in story creation”, which talks about stories crossing sprint boundaries. This assumes that stories are going to be large. Actually they can be quite small. Short cycles can be handled if the organisation and team learn to break functionality into sufficiently small blocks (here is an interesting thought on this matter). This is a skill that needs to be developed, and time after time many people have discovered that the most complex application can be broken down into block that need a couple of people to work on it for a couple of days. So ideally for a two week sprint a team of about seven people about 8 to 15 stories (or sub-stories, if you prefer) can be picked up.

An argument made by armchair planners against short sprints is that the overheads will take up a greater percentage of time as a whole (as possibly being hinted by the above article; see 32,16,11 and 8 days). However for shorter sprint the planning, review and retrospective times will also come down;  Of course time spent arranging for these meetings may go up, since number of meeting per month will increase. However this is a matter of habit, if everyone soon gets used to weekly meetings (each meeting of shorter duration) this will actually be a negligible overhead, with a tremendous amount of learning and correcting being generated. So a shorter sprint is better than a longer sprint.  So item 1 “Ceremonial days” in the table isn’t quite right.

The other (more worrying) point made is that about procrastination;  Use of sprint burndown chart correctly will actually circumvent this! In fact very long sprints may just increase pressure on the team since there is a real possibility that team will struggle to meet sprint goals towards the end of a sprint. There is a real danger of falling into a serious waterfall mode every long sprint. Teams don’t seriously examine their way of working and change to get as far away as possible from the waterfall. In fact in this matter the article seems to lie on a resource (read people) utilization perspective and the worry that people are not going to be busy all the time, easily confusing activity for progress; which is fairly anti-Scrum in approach.

Another issue with the article is the point about “minimum number of days spent testing”! This is really puzzling.  Is less “testing” days better, or worse!?! I’ve no idea what this article considers better, let alone what the thinking behind this is. In reality it depends heavily on the context of the project, the abilities of the team members,  automation involved (rightly or wrongly)… so many ifs and buts. In fact Scrum does not even attempt to prescribe this.

So the main root point in favour of a long sprint is the comfort of the team and managers involved coming from a waterfall habit! This is really a question of willingness, understanding and realization of the people involved in the project. Not something to be sneered at, maybe a coach can help.  He/She must show sensitivity to this, and do all possible to show the team how to break down user stories into smaller blocks of functionality.

In closing…everything else points to shorter sprints. A two week sprint is strongly recommended and indeed used by many, many successful Scrum teams.

PS: The points made above may seem like a merciless slating of a deeply flawed article, but not so, the article itself makes many good points from a certain level of Scrum understanding.  I think it analyses the various factors of making the sprint length decision fairly well. Here I am simply attempting to provide a deeper understanding of how to think through this matter.

Retrospective: The driver for change.

Ensuring that the retrospective makes a real difference

This post is only partly in response to an observation made here that retrospectives were found to be generally useless. Having said that the practical tips in the above post are valuable.

I think the feeling (or even reality in some places) that retrospectives are a distraction is due to a few factors

1. The software development organisation, as a rule, doesn’t have a culture of self-improvement (neither developers nor managers)

2. Many teams struggle just to get to the sprint end date meeting the sprint goals and lose stamina by then (an important tip is covering this). Oh, yes I’ll not be in the least surprised if the cause of this is organisational pressure applied onto the development team. Similarly this pressure will lead to ineffective retrospectives.

3. Poor visibility, hence support for getting action items done (also mentioned and dissected here)

Retrospective is the driver for change generated by the team (and possibly anything that the SM points out). So after the lovely discussion how do we actually make the change? Hopefully the Scrum Master and the team have identified action items (not always easy, not always correctly done), but even so, some of them will be straightforward.

It is all a matter of perspective: Encourage all concerned to view the retrospective as a driver of change; and I think it’ll have a very different effect. At some point (ideally the beginning) of the project, or when the team is getting stuck, floundering etc., it has to be said “There are things that are not quite right around here. We need to change, bit by bit; Let’s use the retro”. Wonderbar! but how?

TIP: Suppose these action items were to be put into the Product backlog. This is an extension of suggestion here. A bit radical, eh what!?! as normally the product backlog is reserved to deliver something for the PO or external stakeholder.

caveats: Some action items need a lot of work/effort to be made and teams tend to drop these items from their to-dos, so these could go into the product backlog. Not all action items need go into the product backlog, as some can be done by the Scrum Master, some by the development manager (hopefully) and some are simple to do.

Coming back to the suggestion: What is the effect of putting retrospective items into the product-backlog? It certainly gets attention (visibility), and these items also get budgeted. More importantly a lot of careful thought based on experience WILL get acted upon. But there is something of a dilemma here, as then the PO gets to prioritize the action items! How would a PO react? What does the PO’s reaction tell us? Something of a litmus test, as to how well the whole team, SM and product owner understand the principles and imbibe the ethos of Scrum. This may often mean that the coach/Scrum Master will have some convincing/cajoling to do. However, while it may take time, eventually the team and organisation around it can see the effect of doing/ignoring retrospective action items (as there is greater visibility). Yes, it also gives the Scrum Master a great handle to encourage improvement via these action items.

WHEN NOT TO RETROSPECT: (ideally a separate post, but I’ve the first quality of a programmer)

I’ve as a coach often observed  teams which struggle to meet the sprint end deadline and led and facilitated their retrospectives. A team that takes it’s commitment seriously is at a disadvantage, as they have been working overtime for the last few days (nights!!?!). This usually means that their sprint review meeting, in such circumstances doesn’t go like a bomb, (don’t bother this link if you are from the UK/antipodes). By the time they are done with the review they are tired, somewhat dispirited and possibly uninterested. TIP: Give the team some recovery time. Don’t hurry into a retrospective under such a sepulchral atmosphere on the same day. Don’t hurry the retro to get on with the next sprint. You almost surely will be failing to learn. An ineffective hurried retro is time wasted, a longer one with sensible action points (which get acted upon) is valuable learning and a “velocity+morale” booster. If you must, hold a 30 min debrief. Especially, if the next day is a working day, people will be late, and the retrospective must be conducted well. So the main body of the retrospective should be around lunch the day  and concluded after lunch. This is to give team members time, discuss formally(during meeting) as well as informally (over lunch). In case the sprint ended on Friday evening, we can conduct the retrospective on Monday morning (with a long coffee break in between). But do make sure that at least three action items are identified and people commit to acting upon them (maybe put them into the product backlog). There must be visible progress over time, else each following retrospective would become more useless than the last (ironically, the reverse result for the retrospective itself, opposed it it’s intention for the project).

I’ve generally seen teams benefit from decently conducted retrospectives. As time passes and the retrospective action items become larger and more difficult this improvement slows down. This is where higher visibility (as suggested here) and perseverance will pay dividends. Good luck and God speed.

An extended entertaining tete a tete

I had the pleasure of meeting Jeff McKenna last weekend. I took him around the city a little bit and had lunch with him as we chatted about various things, with discussions about Scrum taking up about half of the time. He was very engaging. He started programming in the sixties as a young teenager and talked about a seven pass compiler! Blimey! Glad I didn’t have to go through that wringer. Must have been fun in someways, but surely not pure joy when an error was thrown up on the sixth pass. He was also among the vanguard of the Smalltalk community. That is why meeting him was also a privilege. Such a spectrum of experience! He has I’m sure a store of stories to narrate and observations to make, only a small portion I could listen to.

In any case, one of the points he made really well was how you can always break a seemingly big story (feature) into much smaller parts. Many people who come from a traditional background seem to struggle with the idea of taking a functionality from description to implementation in just one sprint.  They think “well, our application is complex (glossing over the fact that complex and complicated are different) and we can’t implement anything meaningful in a two week sprint”. Indulging in some levity he makes the point thus “you can break it down to a few keystrokes!” Touche! But the point is serious. You can take it from people who have seen a really wide range of computer software applications, many times more that the average Mac, that one can always, always break functionality down to a couple of days of work. Surely within a development environment this is possible. There may be other organisational barriers that mean that the implementation cannot be taken into pre-production (or whatever) within a two week timebox, but the point of Scrum is to remove as many of these barriers as possible.

More on this later .

The VOC, but who is the customer?

A recent post encouraging proactive steps to gather the VOC leaves the issue of “who is the customer?” well alone, since a generic answer would be vague, it is heavily context sensitive. Many good ideas are presented here.

An intriguing point made here is that, these are solutions to a situation “…particularly where there is little time to do any early user research”. You must consider what is underlying such a train of thought carefully.   I hear this sentiment sometimes and it is almost surely leading to building of the wrong product! So lot of activity will ensue, but progress in terms of generating ROI may is certainly not ensured! In other words it is a case of leap before you look. This is not to say what’s written in the above mentioned post is wrong, or that it is recommending ignoring user research. It just is trying to work around a poor decision.

As usual since my blog is about Scrum,  here I’ll try to relate this situation with the product owner’s role. To cut a long story short, it’s the PO’s responsibility to bring the VOC into the project. Identifying and engaging with customer(s) or potential customers and the difficult balancing act that may be needed is in the PO’s court. Again it is difficult to provide general advice that is practical but it certainly helps to make as much activity around this as visible as possible. The transparency of such interactions will mean a very significant reduction in dysfunctional behaviour. So as far as the teams are concerned the PO is the customer, albeit,  one who follows the rules of Scrum.