Brave new world?

Leave a comment

Organisations should be interested in Scrum adoption, because there is something to gain. Incidently 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 brave new world, if we can get there.

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

2 Comments

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

5 Comments

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

4 Comments

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

3 Comments

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.

 

 

 

 

 

 

 

Strictly left footed right wing striker

2 Comments

Background: The Pune vodQA 2012, where I was involved, but not entirely committed(A frivolous reference to Scrum lore, about commitment, chicken and pigs) in more ways than one, was interesting instructive and illuminating! Read about it here.

Mr Chaitanya Nadkarny, a senior member of Thoughtworks consulting gave an opening talk, covering among other things which factors are going to affect the lives and careers of testers. One point he made was with regard to how testers can be generalizing specialists, or specialising generalists. It took some time for the audience (at least I did take time) to get it’s collective head around this.  Mr Nadkarny’s point here was that

One could be a performance tester (specialist), but also interested in expanding capabilities (therefore generalising) to do general functional testing, manual etc.

OR

A tester (generalist) now wants to be more skilled and focus on an area of testing, for example usability (specializing).

MAIN POST:

Since I see the world through Scrum tinted glasses, I’ve been struck by how Nadkarny has put in a nutshell the possibilities of how people develop, become more valuable and competent. Many years ago a programmer was doing most if not all activities in relation to developing systems/applications, including testing. As the field developed people became more and more specialized. Eventually in the noughties, we have extremes of specialisation. Even being a tester isn’t enough of specialisation, one is now a manual tester or an automation tester, or a performance tester. The side effect of the industry moving in this direction is that people are squeezed into ever narrower roles, even though this isn’t required and actually creates inefficiencies. Finally we have the equivalent of a striker who can only play on the right wing,  kick with his left foot, but will not head the ball into the net, even if the ball is at eye level, straight ahead and the keeper is out of position!

This attitude is so entrenched  and pervasive in some places that even managers have often fallen into the trap. People are type-cast and given no opportunity to learn new things. The Scrum team, essentially being cross-functional, would struggle to succeed if a group of super-specialists have to work together, even if they are initially willing to collaborate. Why so?

Firstly: There is little understanding of what the other person does and needs.

Secondly: Load balancing at different points in a sprint is a nightmare, as work of a given type isn’t evenly loaded throughout the duration of the sprint.

Thirdly:  Majority of work in any organisation is done by generalists, because much of the work doesn’t need a too much of specialization. How often have you visited a general practitioner vs a specialist?

Lastly and very importantly: it encourages the continuation of waterfall habits.

Time to generalize. A cross functional team would need generalizing specialists.

On the other hand, once they get there, they might then need to be specialising generalists, as well… and so it goes.

Sprint Review undone: Part-I

1 Comment

I was recently present at an attempted Sprint Review Meeting for a team I was coaching. They were struggling to get finished by the time of the meeting, and by the appointed time could not get the functionality ready. The problem was that they had picked eight items, and could not even demonstrate one item, and this was their second sprint! They had earlier done a sprint zero, with many of it’s attendant problems which are described here. Now my overall  analysis of how this situation came to pass is at two levels:

1. Poor habits carried over from the waterfall days.

2. Lack of prioritization within the sprint.

Over and above this is the matter of a somewhat diluted DoD (a separate topic in itself) which is bad news being stored for the future. This team was working with a weak DoD, which was seemingly clear to them (For some one who reads tea leaves in his spare time, this is an ominous sign)

In this post I’ll explain the  first point. Within the sprint, each story was done strictly in a waterfall manner, including hand-offs. This not withstanding all the training the team and managers were given. Which meant, that the burndown chart, while warning about bad news, actually did not quite manage to reveal the really bad news. That nothing was actually ‘done’ ( this does not mean the team did not do anything). Suddenly towards the end of the sprint 4  user stories  were 90% done, and as the old saw goes, the remaining 10% takes the other 90% of time. The other 4 items were in even lower levels of completion. However what was the actual completion is moot.  Even more importantly, trying to find out the true completion percentage is missing the point. The team at the time of the sprint review, should try to keep the done/undone as binary as brutally as possible. Try to see it, standing in the PO’s shoes.

So what is to be done? Avoid waterfall. How? Especially given that the team is already facing too much change for comfort (One reason why many teams don’t see successful sprints early on).  Assuming they haven’t changed their technical practices yet (very common for teams starting off on Scrum), the first step is to try to break-down user stories to even smaller units of functionality, whose completion should be staggered across the sprint. Another approach that can be simultaneously used is  to write acceptance tests as the stories are picked up. This means that the team can test the stories (to some extent) at a very early stage, hence testing early and (hopefully) often.  A very good idea.

The above ideas are a reason why teams aiming to succeed have to change their ways of working and learn to breakdown stories and change the approach to testing among other things.

In the next post I’ll explain the other practical step to take (if you haven’t guessed already).

What is the one legged stand-up for!

2 Comments

Forgive me. I didn’t have time to write a shorter letter.”

We are not talking necessarily about uni-dexterous people.

The basic idea of a stand-up is for the team to synchronise itself and self-organise around the sprint goal. However it is not uncommon for this understanding to be missing in practice. As an aside the difference between “not uncommon” and “common” is that the former is saying that  something is not rare, but not necessarily common and the later is taking about something that is common and it’s occurrence should be almost a given. Of course the phrase “not uncommon” can be used in a situation where someone is trying to be polite, or not give offence. Now John Major,  according to some sources (however questionable) took this to an art form, but there might indeed be a point in his manner of communication. Similar to Rumsfeld’s much pilloried “known unknowns….”, which actually had a very valid point, and even said so fairly directly, cannot provide certainty of not being misunderstood. Now, “not being misunderstood”, in light of the current discussion may seem to be different from “understood”, but the difference is difficult to discern. Indeed the only thing I can think of is that, “being understood” precludes obvious confusion, while “not being misunderstood” doesn’t. However where was I… ah, and maybe this is  one way in which someone speaking at a stand-up can meander all over the country. Indeed if you have senior managers present they feel even more inclined to blabber.  If you think all this is blabbering, then you are to be easily forgiven.. now, where was I? Ah…The stand-up, as people debate the recent developments and blocks and next steps, sorry they were not meant to debate, only discuss, or maybe just describe briefly during the stand-up. So coming back to the point, team members are taking in whatever information is being aired and are reacting to it. This manner of stand-up, especially if the prevailing corporate culture is wallowing in being politically correct, will invariable mean a lengthy discussion even as a part of the formal stand-up.

In case the team sees the stand-up as a pure status reporting, then mostly each person will provide a quick monologue to some extent in a forced or resigned manner, and not uncommonly,  even guarded; Now, I need not point out to an intelligent bystander, that “not uncommon” is not the same as “common”, however returning to the subject under discussion…such a team’s stand-up will be mostly pointless, and useful only to the manager/supervisor, if at all. So a short stand-up is not necessarily a good one! I must also caution that a pure status report generally places a strong temptation for people to look good, especially if senior management is present. A good case, for senior management to only rarely attending stand-ups or even better not at all.  In case the team is not too disengaged, there may be instances where impediments are aired but a bit late.  Now “not too disengaged” is different from engaged, something we’ve been discussing and defining but not debating. The engaged team is a different animal, but it could be a mixed blessing….

… especially if everyone is eager to show how good they are! Then they’ll talk and talk and not shut up. This is particularly true of Indians (As you can see from the writing above also as the saying goes “Put ten Chinese in a room, and you’ll never get any one to speak up, put ten Indians in a room, and you’ll never get them to …”

This is where the one-legged stand-up comes in: The team member speaking has to give his update standing on one leg. Of course he is free to choose which leg, as long as he is not one legged.

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. (However I’d caution against productivity becoming the MAIN/ONLY goal of adoption.)

Manager! Leave the team alone!

3 Comments

We don’t need no disruption
We don’t need no time control
No breathing down the neck in the server room
Manager, leave the team alone.

What do we do if a senior manager is asking for a ‘resource’ from within the team, in the middle of a sprint, to deal with some urgent matter?

As with a lot of things, this is better preempted, by informing as much of the surrounding organisation as possible before the start of a Scrum project, that we have to keep a team constant for at least the duration of a sprint. In other words the organisation should understand that the ‘NO CHANGE RULE’ is critical and central to the Scrum way of working.

However, senior managers may not pay sufficient attention to this or feel that whatever is occupying their minds at the moment is of utmost importance, and they can pull ‘resources’ (actually people) out without too much consideration. It is the Scrum Master’s job to protect the team, and as such does throw the Scrum Masters into a very difficult situation. The organisation culture will be a dominating factor in how people (SM included) behave. In many organisations the hierarchical structure combined usually with a command and control culture means that Scrum Masters are either powerless in face of such disruption or get into a downward spiral of de-motivation. This effect should be highlighted after the sprint end, to the management including any effects on how the team struggled to meet the sprint goal.

The Scrum Master in such circumstances should talk to the team and PO, and if applicable to the PO’s manager (who could be the senior manager in question) about the side-effects of pulling someone out mid-sprint.

Organisations where everyone is well-educated about Scrum, will seldom face such a situation without being able to make corrections and recover fast. This situation is particularly difficult in organisations which are largely ignorant of Scrum and the attendant principles. So it is important to respond to this situation without using jargon in such settings.

Speak in terms of disruption, de-motivation and relative importance of the sprint goal versus the work the pulled out ‘resource’ will do, versus the importance of adhering to the rules of the game. Such a conversation should also guide the persons making this decision to think in terms of ramifications of such requests and induce an inclination for senior managers to talk to the PO and SM before making any such requests/orders to pull out people, in the future.

All this engenders a culture where disruptions are kept to a minimum and only for good, genuine reasons. A relevant point here is the case when in response to a management edict coming from much higher-up, and in essentially a knee-jerk reaction, someone is pulled out even before it is really clear what exactly needs to be done. In other words the person pulled out cannot really begin work, since certain clarifications are still being sought. In such cases the useful practical steps to take consist of the Scrum Master taking a close look, spending sometime to discuss this with relevant team member, so they are prepared, wait till the end of the Sprint, so there is minimal disruption. Then after the sprint ends, the team can be reset, with a freshly updated backlog, which may include this ‘urgent’ piece of work; alternatively the person in question will not be part of the team for the new sprint, and works independently.

Older Entries