Brave new world?

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

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

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

2. Higher possibility of building the right product

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

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

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

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

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

Advertisement

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

Good question!

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

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

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

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

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

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

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

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

Reverse Viennese Syndrome

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

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

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

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

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

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

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

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

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

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

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

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 .

Strictly left footed right wing striker

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.

Developers are people too!

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

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

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

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

What can be done when the PO isn’t empowered?

A fairly common situation in organizations is the presence of a PO without authority. It is common for a BA to play this role, and mainly due to the mistaken belief that functional knowledge is  the only criteria for a PO. Also the term ScrumMaster suggesting an all important person in a move to Scrum, contributes to this thinking. As in many things the best course of action is to preempt this situation by educating the rest of the organization (before) the start of Sprint about the roles of SM and PO. Once the realization set in, that the SM is not responsible for the delivery on a sprint to sprint basis, and in terms of delivering the product to the customers, people outside will turn to the PO. The PO will then slowly take on a stronger and more meaningful role, suffused with responsibility.  In my experience, coaching project teams and organizations, this take some time. The first level of understanding come about in 3 to 4 sprints, but deeper understanding typically takes a release or two (maybe 3 to 6  months). What one can do to make this more visible:

1. Re-iterate that Scrum is a radically different system of running software projects.

2. Encourage interaction between team and PO, as well as PO and external customers/client.

3. Explain to all concerned that while the team is largely responsible for “building the system right” every sprint, the PO is reponsible for making available “The right system”. While the team is collectively responsible every sprint, the release to the customers is the responsibility of the PO.

4. In addition for a release the PO is ultimately responsible for delivery of the “right system right”, in other words the appropriate system which is shippable (i.e of high quality)

Sprint Review undone: Part-II

Please see previous post for the context.

Lack of prioritization (within Sprint).

The overall result (certainly from a PO view point) is nothing delivered. Many teams see this in a very different way. This reminds me of a story: Mike was looking for his shoes,  and his servant who was responsible for taking care of them was trying to find them. All the while Mike’s irritation was increasing, after some time  the servant said in a voice where consolation and triumph were nicely blended “Well here’s one shoe!”. To which Mike replied “What’s the good of one shoe, you duffer!”.

Well, what of the poor PO. What did (s)he get for the patience? Nothing!

The team has worked and actually done(on the average) about 80% of each item!

This statement demonstrates the inherent weakness of the traditional means of assessing s/w development progress.  In other words percentage done. In the Scrum world we should strive to get a story/item ‘done‘ unambiguously in accordance with a strong DoD.  But I digress somewhat….

So the vital point is that: it is better to complete 80% of the items 100% (ie ‘done‘), than do 100% of the item 80% (ie, none are done). This is possible if the priority of items/stories chosen for a sprint is   considered and acted upon. So the higher priority stories must be taken up first, and all efforts must be made to complete these, before focusing on the completion of the lower priority items. This consciously applied pretty much ensures that the PO gets at least a couple of items. Moreover they are very possibly the highest priority items! So the PO can potentially derive value out of them sooner. The SRM cannot be viewed as a disaster, an important benefit.

Handling changes in Scrum

Srinivas is the co-author of “Essentials of Scrum practice“- a mini-book
currently in a draft stage. This is an extract from the book.

 

All s/w development projects have greater or fewer changes to be incorporated after the start of development. So how are changes handled in Scrum? and more importantly why are they handled in the manner described/recommended by Scrum?

Basically in Scrum the top few items of a product backlog (the highest priority ones) are chosen for any given sprint. The remaining items, can be modified by the product owner as he/she pleases at any time. As an aside, there has been some recent talk about the backlog not being prioritised, but ordered. I’m less than impressed by that explication.

Since Scrum is supposed to take care of changing functional/non-functional needs over time, the germane question is “How do we handle changes within a sprint/iteration?” in other words “how do we handle changes to the sprint goal?”. This is a recurring question, and the answer lies in correctly understanding the intent of Scrum.  Scrum’s intent is to provide a means, an island of stability where a complex project can be run smoothly, even though the environment around is in flux. This island of stability  is ensured by the “NO CHANGE RULE”. Which means no change in duration, goal or team for any given sprint.

See the following post for the reasoning on keeping the team fixed. Here I’ll essentially cover how and why of keeping the goal fixed.

There are two cases which cover changes to sprint goal

1. Urgent bug-fixes which may turn up at any time, hence cannot be foreseen at the time of the Sprint Planning Meeting (SPM)

2. Change requests to the selected product backlog items

These two cases are to be handled in radically different manner. For the first case the team can inspect and adapt to choose a means of dealing with bug fixes, by either keeping a percentage of available time (say 10 to 15%)  aside as contingency or by rotation having one or two team members on stand-by to handle the bug-fixes as and when they turn up. In other words this is being prepared for the unpredictable. The second case is severely discouraged and is  handled by not taking it up in the current sprint! This may seem extreme, but there is sound reasoning underlying this approach.

First and foremost, if change requests are allowed at any time within a sprint, there is no line drawn as to how much of change is allowed. Given human nature this will result in any amount of change being allowed any number of times with any sprint. What is the implication of this on the usefulness of the SPM? We are very possibly on a slippery slope by allowing a change in sprint goal, mid-sprint. Essentially, by having this rule, we are creating an island of stability.

Secondly, the reason we have sprints with items being pulled into any given sprint, is to accommodate change. This means at a project level change to functionality is handled in an orderly fashion as well as a welcoming manner.

Thirdly, and this will be difficult to stomach for some stakeholders,  a significant amount of change is due to lazy thinking early on. In other words quite a few of the change requests are a result of not thinking through what is needed. While it is recognized that the PO/customer cannot always know everything that is required in detail, up-front, what this rule does is encourage reasonably detailed analysis of the items which are at the top of the backlog. When the PO is confronted, with a situation where he/she/it (How PC am I becoming!?!) has thought of a change and has to wait till the next sprint, this is a stimulus for more careful thinking before and during the following SPMs.

The encompassing principle above is that Scrum is a system that encourages corrective behaviour from the stakeholders, while maintaning a balance between accommodating change and reducing avoidable waste due to lazy change.

Two further points:

1. Scrum does NOT need (in fact discourages)  to have the functionality described in every detail at the starting of the sprint! Then, how in the blue blazes are we supposed to keep change at bay, as clarifications are made during the sprint!?! There is another simple rule in play “If in doubt, it is the team that decides whether it is a change or clarification”. In case of clarification the team simply implements, in case of change, it gets put away for following sprints.

2. What if there is an utterly, unavoidably, compellingly, the-sky-is-falling-on-our-collective-heads, URGENT change of sprint goal, in the middle of the sprint!?! Either a change to an item picked in the current sprint, or an altogether new item added.

Well, indeed if it is THAT important, follow Scrum by the book!

i. Terminate the sprint

ii. Inform all stakeholders

iii. Immediately start a new SPM for a sprint, of what-ever length, that makes sense for the explosive circumstance. Does one need to do a full SPM (of 4 hrs?), not really. Exceptional circumstances can mean that just the new/changed item is to be dealt with in the planning.

Any loss of time/money/delay due to this decision is made in full knowledge by the PO.

Again note, that this is a highly disruptive, but necessary change, and is widely visible. Not to be undertaken lightly. After all if there is a serious earthquake, the sprint goal will change.

Commitment Under Pressure

Srinivas is the co-author of “Essentials of Scrum practice“- a mini-book
currently in a draft stage. This is an extract from the book.

Pressure pushing down on me
Pressing down on you no man ask for
Under pressure that burns a building down
Splits a family in two
Puts people on streets
It's the terror of knowing
What this world is about
Watching some good friends
Screaming let me out

The hidden hobbler of Scrum teams: Pressure

One common problem Scrum teams face is in the difficulty of meeting their sprint goals, followed by increasing pressure, which seems never-ending. Such teams don’t see sustained significant improvement and can quickly fall into a death march mode, or a jaded plodding with longer hours but no end in sight. Such situations are due to their choosing sprint goals (targets) under duress in some form. The ill effects of such commitments are not easy to understand or link to the cause. The inviolate Scrum principle in this regard is that the team chooses the extent of the backlog which it’ll deliver. Team requires to have a fair shot at making an independent, free commitment for their sprint, after all they are the ones who do the work. Mainly managements are worried that the teams will under commit. Hence they may treat the whole affair as a negotiation game.  As entertaining explication of such games is provided by Rob Thomsett. Software development is very commonly done under pressure, and this makes it seem as though this is very normal, and possibly the only way to work. A good anti-dote to such thinking can be found within Tom DeMarco’s entertaining “Slack”.

What do we do when the pressure to finish is so much, that there is no choice left to the team.
Don’t buckle under pressure, and stick to the Scrum principle (i.e make an independent and genuine commitment), however this is much easier said than done. Many projects have deadlines in some form, based on a marketing wish or executive fiat. Since organisations need to make plans, what upper management wishes for, may be necessary. Trouble is in the making, when this wish is widely out of line with reality. What organisations do poorly, is handle the difference between an original high level plan (based on executive wish or even a high level estimate) and the reality as the devil in the details appear. The Scrum approach is to do planning in small bits (2 weeks) and improve continuously by ‘inspect and adapt’. In our experience, far too many projects and managers are worried about the success of any given sprint and don’t give a chance for the team to learn and improve, hence endangering a number of future sprints and ultimately the entire project. A difference is made if a couple of steps were to be taken before the sprint starts:

1. Get an agreement from management that the team be free to choose the extent of work they commit to; offer to be transparent regarding why such a choice is made.
Essentially this means that the details of the sprint planning meeting is made available to the larger organisation. Management also needs to support the Scrum Master in his/her task of protecting the team from any external pressure. Now the Scrum Masters job is easier, if he/she also provides transparency into the Sprint Planning Meeting, by highlighting significant events in a MOM, as well as, circulating the sprint backlog/plan itself after the meeting. Normally the sprint backlog, with estimated hours for each task totaled and compared with available time, will give a realistic view of what is within the realm of possibility for the team to take up.

2. Explain the distinction between a real commitment that the team makes, believes in, as well as is serious about, as opposed to a perfunctory commitment made under duress.
Pressure to finish fast exists in most organisations. However, better the protection a team can be provided, to demonstrate to the team that their honest views are truly valued, better the commitment from the team and the teams attempt to meet this commitment. Fair and transparent planning will mean that team will not knowingly under-commit. Once a true commitment is in place the team, they should be supported by the Scrum Master and the management will do all in their power to meet the sprint goals. An unrealistic deadline imposed may make the team work harder, but they are unlikely to learn and also this will not be sustainable. In fact there is a very good chance that team members will take a fair stab at pretending to work hard. What the Scrum Master and the management can do is replace pressure with motivation. Any pressure must only be peer pressure, generated naturally, not imposed from higher up.

An intangible, but important effect of an open transparent sprint commitment made freely, is that the team sees it’s opinion valued even by management. They are being treated as professionals. I’ve yet to hear of any one, however powerful, saying to a surgeon “You have to do my gall bladder operation in 45 mins, now! and not take 3 hours as you say it’ll take”.

Further more, if after all this discussion we still have a situation where pressure cannot be held off, either due to the unwillingness of people to be open, or the unwillingness of management (briefly glossing over the fact that management also consists of people, of  a sort) to accept bad news, then the Scrum master must present the actual versus the hoped for amount of functionality delivered after the sprint in a neutral communication as a means for the organisation to learn. Many organisations take time to learn so this can be a long drawn out process. Remember Scrum Masters can do this easily, if they are not directly responsible for the success of any and every given sprint, which is typically the case with a project lead. It is well worth noting that a ScrumMaster is not a new glorified label project lead, but an enabler and protector of a team, which alone is responsible for delivery.

Finally, a thought on how breaking the Scrum principle leads to long term undesirable side effects. When the team members realise, that management just wants unrealistic results and is unwilling to listen and act upon information provided in good faith by the team, their motivation drops. Also they have no further incentive to provide bad news ahead of time, and the slide to micro-management is fast. This also means they stop caring for the project as professional pride is buried. Therefore they will go through the motions; not the most inspiring and driven crew, who will be apathetic at the best of times or even hostile.

Pressure pushing down on me
Pressing down on you no man ask for
Under pressure – that burns a building
down
Splits a family in two
Puts people on streets
It’s the terror of knowing
What this world is about
Watching some good friends
Screaming let me out