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.

Advertisements

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).

Older Entries