The Drencher, Humility and Leadership?

“All men make mistakes, but only wise men learn from their mistakes” – Winston Churchill.

I used to work in a well-known theatre in the West End of London. I was twenty-something, and following a dream.

Although I always wanted to be an actor, I ended up as Stage Door keeper.

For the uninitiated, the Stage Door keeper looks after the dressing room keys, incoming and outgoing calls, the backstage tannoy system, the “good mornings” and “good nights”, any visitors for the actors, most deliveries and the coffee machine.

They hear all the news, excuses, mishaps and tantrums. They hear about all the worries, the insecurities and the fragile egos. They witness the nerves, the bravado, highs and the lows. And – not being one to gossip – all the juicy gossip.

One of the principal roles of the Stage Door keeper therefore is to listen. To just be there. To be on hand, To offer an oasis of calm. To absorb bad vibes, and return a “There, there, never mind,” or a “I’m sure it will go better tomorrow.”

As Stage Door keeper, you are always on call.

You are, in fact, a Leader.

Typically, in a theatre there are those who work for the theatre itself, and those who work for the “Company”.

The Company usually comprises the actors, the Company Manager, Company Stage Manager (CSM) and Assistant Stage Manager amongst others. They are analogous to Contract Staff: once the performance run has finished, they move on to the next gig.

The theatre staff, however, are analogous to permanent staff. Once the performance run has finished, they “strike” the set, do the “get out” and prepare for the next show (the “get in”).

The backstage theatre staff fall broadly into four groups: Electricians, Carpenters, Stage Door, Wardrobe.

When I worked there, the Chief Electrician – who looked like Phil Lynott of the ’70s band Thin Lizzy – was called Phil. Handy. The Wardrobe Mistress was a Jamaican-born gay man who liked to be called “Jo Jo”. And he also liked to be called the Wardrobe Mistress. So that’s what we called him.

The Stage Door keeper was me.

The Master Carpenter – the subject of this blog – was a man called Bill. Built like a Roman Centurion, or a Centurion tank, he had worked at the theatre forever. In fact, he was the theatre. He was respected by everyone. He was calm in a crisis. Approachable. Fair. Honest. Trust-worthy. Respectful. Amusing. Quietly imposing.

With one hand, he could remove a tin of tobacco from his jeans pocket, open it, extract a rizla paper, load it with tobacco, roll it, lick it, put the lid back on and replace the tin in his pocket. With one hand.

He had a letter tattooed on each of his fingers which seemed to mean nothing, until he interlocked his hands when it read “I L O V E P A M”. Pam was his wife, who was the wardrobe mistress at a nearby theatre down the road.

Bill was hard, but fair.

He wanted people to learn. He wanted people to grow. He didn’t mind honest mistakes, so long as you didn’t make the same mistake twice. That was intolerable. He would tolerate pretty much everything, apart from a repeated mistake.  And disrespect.

He was the kind of person you want on your team.

So, what’s a Drencher?

In a theatre with a proscenium arch – that’s the frame or “arch” that separates the auditorium from the stage and from which the curtains (or “tabs” in theatre speak) are hung – there is always a safety curtain (referred to as the “iron”) which is lowered in the interval and after the show. It is designed to stop fire from breaching the auditorium/backstage divide.

But some theatres have another safety feature which is also fitted to the top of the stage-side proscenium arch (or “pross”), the name of which sounds like a villain from a Marvel comic.

It’s called The Drencher.

The Drencher is a well-named peace of kit. In an emergency, its role is to provide fire protection by creating a wall of water between the audience and the stage.

How?

Fitted to the top of the pross, stage-side, would be an eight-inch pipe running the entire width of the stage, with small nozzles in it spaced out equally, and aimed at the front edge of the stage.

The pipe is connected to the mains water supply, and kept closed or “off” or “safe” by a valve.

Activating the Drencher is simple. Dangerously simple as it turns out.

It’s activated by pulling on a handle which is usually fixed to the pross, close to where the CSM sits while he or she is running the show.

The handle is connected to a valve.  The Drencher valve.  An important value.

When someone pulls the handle, the valve is opened, a zillion gallons of water is instantly forced through the nozzles at mains pressure and hey presto!  a wall of high-pressure water.

The volume of water is immense, and as such, it is enough to keep the wall of water in place and stop a fire from hopping off the stage and making itself comfortable in the stalls. Or visa versa.

Typically, the handle is not spring-loaded, which means once pulled, it remains pulled. The water won’t stop until you push the handle back up, whence it came.

And of course, until you do, the devastating torrents of water will continue to smash down onto the stage, bulldozing its way through the set, throwing props and furniture out of the way, ripping down the flats in the wings, and tearing down anything in its way without discrimination, second thought, or care.

Many theatres have an “Orchestra pit”, often found just in front of the stage, or sometimes under it, where the show’s musicians (if there are any) set themselves up. In most cases, there is a small opening with a step on which the conductor stands, slightly raised to give line of sight to the actors on stage and the orchestra underneath.

A Drencher likes an Orchestra Pit. It can have fun there.  The devastation is biblical. The relentless deluge of water smashes its way through the pit, taking out everything in its path.

The instruments which are set up ready for the next performance are ripped off their stands and thrown out of the way, connected amplifiers are pulled off their speaker cabinets as the force of the deluge separates electric guitar from amplifier beyond the reach of the attached guitar lead.

Music stands, drums, microphones, chairs, timpani, keyboards are all scattered by the force of the flood. Everything is shoved up against a wall or into a corner, pinned there by the force of the water and the growing quantity of flotsam.

The speed at which this chaos unfolds is staggering.

Water is heavy, and under mains pressure, and in such volumes, it becomes confident. Challenging. Destructive.

Many theatres – particularly Victorian theatres – were built with the Royal Circle at street level so that the landed gentry didn’t have to condescend to walking upstairs to the Upper Circle, or worse, downstairs to the stalls. In such theatres, the top of the pross is approximately in line with Royal Circle – and consequently, it follows, the stage is below ground level.

Water, being the kind of guy it is, has a nasty habit of flowing down hill. Of finding the lowest level. In a typical Victorian theatre, as we’ve heard, the “lowest level” is under the stage.

This, then, is where the water likes to call home.

Often, this is where the carpenters’ workshops are.  It’s where the props store can be found. Spare lamps, costume rails, half-built sets, everyone’s cigarettes, half-eaten breakfast, the coffee machine, electrician’s bicycles, paperwork, paint. Everything.

If the water finds the orchestra pit, your day is ruined.  As is everything in its way.

So what?

Well. One day, I’m standing at the stage door cleaning the coffee machine, when the door opens and Bill steps inside, followed by his apprentice – who looks sixteen.

Bill does his cigarette-rolling thing, much to the amazement of Sixteen, who looks on with wide eyes.

After a while, Bill says “Is the iron in?”

“No,” says Sixteen. “I mean, I don’t know what that means.”

“It’s the safety curtain,” says Bill, “Have you lowered it yet?”

“No,” says Sixteen, shifting his weight a little nervously.

Pause.

“Then would you do so please?” Bill asks, dangerously.

Sixteen looks confused.  Bill helps him out.

“There are two handles mounted on the pross, prompt side by the pass door,” says Bill.  Master and Apprentice.  “Pull the right handle hard in the direction of the arrow.”

Sixteen nods. “Ok,” he says. “What’s the other handle for?”

“Oh, you don’t want to touch that,” says Bill….

Learning Opportunity

The show had to be cancelled for the rest of the week, while the set was rebuilt. The costumes were remade, replaced and refitted. Instruments were salvaged as best they could, most were replaced. Insurance policies invoked.

Lost revenue touched the £45,000 mark, per night.  The show was closed for five days. The producers were not happy.  Not one little bit.  And there were 225,000 reasons why they were so grumpy.

Huge quantities of water had to be pumped out from under stage to the dock doors at the back of the stage. Most of the stage props, including an Axminster carpet and long case clock, had to be replaced – beyond repair. Amplifiers, speaker cabinets replaced.

Double time for everyone to get the hit show back up and running as soon as possible, working around the clock in shifts until everything was ready to reopen.

The Health and Saftey people, the fire-brigade, SWET (Society of West End Theatres) all gave their stamp of approval to re-open.  The Marketing department and press office went to town to take advantage of the situation and drum up some column inches in every conceivable periodical and newspaper.

They reopened.

What about Sixteen?

Sixteen comes charging towards the stage door with panic in his eyes and across his features.  He barges through the stage doors looking round wildly for Bill who hears the commotion, and turns to face Sixteen.  “Drench-” manages Sixteen.

Bill doesn’t need to hear the rest.  He drops his coffee and flies out of the door like a cartoon Roadrunner.

Lesson Learned Log

A couple of hours later, Bill wanders up to the Stage Door, as if nothing has happened.  Not a care in the world.  I’m thinking that Sixteen has seen his last day in this theatre.  I mean, that’s a hell of a mistake.  It’s 225,000 mistakes.

I look at Bill, who reads the question on my face, with a glint in his eye.

“Well,” he says lighting a cigarette,  “he won’t do that again.”

I laugh at the understatement.

“I guess he learned a big lesson!” I venture, laughing.

Bill turns to face me, fully locked on, serious face.

“No, ” he said, “it was my fault. I learned the lesson. I assumed he knew the difference between ‘Stage Right’ and ‘Right’ – which as it turnd out, he doesn’t.”

Wow.

“He did nothing wrong. It was my fault.”

He wanted people to learn. He wanted people to grow. He didn’t mind honest mistakes, so long as you didn’t make the same mistake twice. That was intolerable. He would tolerate pretty much everything, apart from a repeated mistake.  And disrespect.

He was the kind of person you want on your team.

What is a camel?

Open dialogue, inclusion, collaboration are all important. Critical even. That being said, we must stay true to our goals and not let the accumulated weight of opinion nudge us off course. Unless we’re on the wrong course.

There have been many articles written, podcasts made, courses delivered, TV programs aired and books published on the topic of Leadership. And in particular, great leadership.

What makes a great Leader?

Look it up on Google. There are squillions of sites and blogs dedicated to the topic.

You’ll see sites with titles like:

“12 qualities of a great leader”, “The top 5 characteristics of great leadership” and “The 8 essential qualities that define a great leader”.

You get the picture.

If you set about reading all of these sites – apart from losing all your friends – you’d be able to distill the list of qualities to a core set of commonly quoted characteristics. Most of which have been attributed to people who have, themselves, been identified as great leaders.

So what?

Well – a particular quality that keeps cropping up is Vision. Clarity of Vision. A great leader is one who – amongst other traits – has a clear view of what they want to achieve.

Not only that though.

Critically, they have a passion for promoting this vision. Of being evangelical. Of selling their vision, and attracting buyers. Of painting a picture of what “Success” looks like (buzzword bingo alert). Getting people hooked on the idea. Bought in. Excited. Passionate.

Not only that though.

It’s all very well having a vision, but people need to believe you. Believe in you. Believe that you can deliver. Believe that you will deliver. No question. No doubt. For ever and ever, Amen.

But you can’t be a great leader – you can’t be any kind of leader – if you don’t have followers. A team. A useful team. Dedicated. Active. Productive. Engaged. Inspired. Inspired by you. A team that knows it has been inspired by you.

You need to have a team that feels it can help you deliver. That it is there to support you, be there with you. For you. That it will make sacrifices alongside you. You need a team whose members feel empowered. Whose members are empowered. Whose members know that you have explicitly empowered them. And that you have an expectation that every member of the team will use this empowerment as you would in their place.

Is that it?

No. You need a team whose members feel valued. Feel that their work is being recognised. By you. A team made up of people who value your judgement. Your appraisal. Your view. Who trust you. A team that feels your trust in them. Mutual trust. A team.

And great leaders are innovative. They want to challenge the status quo. They want Change – but only change for the better. Staying the same won’t do.

Great leaders do not have titles like “Head of Business As Usual”.

And as a great leader you need a team that feels it can have a go too. A team that feels empowered to come up with better ways of doing things. Trying things out. Trailblazing.

And what’s more, the team needs to feel that their ideas, approaches, new ways of working are worthy of consideration. Worthy of scrutiny. Worthy of appraisal – even if those ideas end up on the agenda of the “No” Committee.

But here’s a thing.

If you have ever worked for a great leader – one who empowers you, encourages you, trusts you, values you, is innovative and is passionate about their challenging and enticing vision of the future – you will know that they are also masters of decision making.

Great leaders are decisive.

Great Leaders’ Famous Speeches

“We shall defend our island, but we’ll have to monitor costs. I think we should fight on the beaches too and maybe on the landing grounds. We’ll almost certainly fight in the fields and in the streets. Oh, and probably in the hills; because I have NO intention of Surrender. But obviously I can’t confirm that at this stage.” – Not Winston Churchill.

A decisiveness, empowering, passionate, trust-worthy and honourable visionary is a heady mix.

And as a great leader you need to be able to say “No” as well as “Yes”. And you need to be able to protect your team. To be the buffer against external noise and uncertainty. To know which battles to fight, and which to relinquish.

So what is a camel?

Well, one of the mistakes that teams make when they adopt Agile (as opposed to Waterfall), is to believe that agile is easy. That discipline is old-fashioned. That leadership is shared. That as a self-regulating and autonomous team, you can offer up new ideas and features that maybe haven’t been thought of before now and that the customer is going to love.

And, that everyone on the team can have a go too. It’s self-regulating and autonomous after all. Discipline is for wimps. Agile is cool and groovy.

Hmmm. So, just a couple of administrative points, if I may:

1. Agile is not easy, and requires industrial sized discipline. It is not a playground for those who have had a great idea which the customer will love. Requirements are planned, written up, estimated. They are fixed – until the end of the sprint. And it’s not your decision anyway.

2. Leadership is not shared. There is always a leader. The leader is in the business. The leader is the business – most often represented on the team by the Product Owner. The “go to” decision maker on the team for requirements, scope and feature sign-off.

And guess what? They have to be strong. Decisive. There are difficult questions to answer. Options to consider. Benefits to weigh-up. Wages to pay.

But what if the leader is not a great leader? What if they are not decisive? Have no vision?

Well then, you end up with a camel.

Camel

ˈkam(ə)l/

noun

1. a racehorse designed by a committee.

Are we there yet?

Since, for the most part, you know where you are, and having decided where you need to be, the next step is to plot a route to get there. And then get there.

Having decided that you want your organisation to be agile (see Agile Target Operating Model?) – which in a sense is the easy bit – you then need to work out how to achieve it. You need a plan. A route. Goals. Targets. Critical Success Factors. You need to know what success looks like (let’s play cliché bingo).

You’ll need to know when you have arrived, when your goals have been met, when you can see the sea, when the kids can start shouting “are we agile yet?

And, of course, you’ll need someone to map read. Someone to make sure you’re still on target, you’re going the right way, you’ll get there in time for tea.

After all, you’re changing the way in which the organisation behaves. It’s a change initiative.

It’s what we do.

But this time, we’ll be changing the way we do things, while we do them. We’ll be trying to ride the bicycle while we’re still building it.

And since it’s a common or garden, run of the mill change initiative, we should treat it as such.

Why?

Because we want to practice what we preach, and because we believe there are wonderful benefits to behold over the rainbow in Agile-by-Sea, and because we’ve been rabbiting on about going agile for so long that we’re only going to get one shot at it, and because the leadership team is bought in, and because it’s the right thing to do, and because.

Setting out for Agile-by-Sea will have all the elements of a major change initiative:

  • Cultural change
  • Organisational change
  • Process change
  • Behavioural change
  • Responsibility change
  • Business change

… and all that goes with these usual change management challenges.

The good news is that there is usually a good feeling about going agile.

The leadership team usually likes the promise of being able to react more quickly to changing market conditions, getting their products to market quicker, reducing the gap between perceived requirements and actual requirements, and therefore fewer “that’s not what we asked for” defects.

The development teams usually love the idea of transitioning to agile, because it’s agile. Of course they do.

But, like any change initiative, we should expect challenges along the way. And so we should look out for them before hand. After all, it’s all been done before.

In my experience, there are several “traditional” areas which warrant close attention.

Areas where we might expect delays. Areas where we might expect stakeholders to struggle with the adoption of changes and new behaviours – either through lack of knowledge, lack of understanding, lack of engagement, a miss held belief that none of this would actually affect me.

These are what Accelerated Implementation Methodology (AIM) calls Roadblocks. We might call them risks which need mitigating.

Whatever we call them, there are some known knowns which we can start addressing early on in our trip.

Top 5 list of Agile transition Roadblocks

  1. Funding projects
  2. Cross-functional Scrum teams
  3. Product ownership
  4. User Story writing
  5. Discipline

Honourable mentions: feature writing, estimating, release management, continuous integration, QA.

1. Funding Projects

This is a big one. Traditionally, when Change is required, a Mandate of some sort is produced which describes high level costs, timescales, benefits, risks, etc. This is presented to the Change Board (or equivalent), who decide whether to proceed.

If they approve, a Project is spun up, Project Managers allocated, other resources allocated, and off we go. The project has a start, middle and end. It is a “temporary” piece of work, with a team specially assembled to deliver it. Once it has been implemented, the project is disbanded, and the resources float off to their respective resource pools to await further work.

Leadership get this approach, because it’s the “traditional” way of doing things. And because we are specifically allocating resources to it, we can do the maths and work out the resource cost. Something the leadership team likes to do, even though – by and large – the resource cost is based on a blended rate, and includes the Business and Contractors at the same rate, and we’ll never be able to reconcile it to invoices, and real costs, yada yada yada.

I once asked a senior leader, who was a member of the Executive Committee, Project Sponsor, and all round Top Charlie Banana:

Me: “Do you really want to see the cost of this project, measured as Hours x Blended rate?”

He: “Yes, of course.”

Me: “Why?”

He: “Because we want to know if there’s a positive cost benefit for it.”

Me: “But you’re already paying for them. They’re permanent staff, regardless of whether they work on this project or not.”

Pause.

He: “Good point. Actually, we only want to see the cost so that we can compare a project’s scale with the other projects in the portfolio.”

So really, the discussion should be about Capacity, not cost. Of course, contract staff cost real money, but ideally contract resources are best used for staff augmentation, to flatten the peaks and troughs of capacity.

In agile, the idea is that you bring the work to the people, rather than bring the people to the work (i.e a “project”), and so you stand up a scrum team, and ensure that they have a continuous flow of work (I’ll cover this off in another blog). The concept of a “project”, a “temporary piece of work”, disappears.

And so, therefore, does “project cost”. It becomes a conversation of capacity – “Do we have enough work for our scrum teams?”

And yet.

Even moving to a continuous flow of change model, where we deal in Features, Value Streams and Epic backlogs – a continually growing list of “good things to do” being prioritised and fed to scrum teams, the Leadership Teams still tends to think “Project”. And hence, CBA, and hence Cost.

Moving to agile therefore requires a paradigm shift. And not just by the delivery side of things, but also from the Leadership side.

Of all the roadblocks to agile success – this is one of the toughest, and most important, to negotiate.

2. Cross-Functional Scrum Teams

One of the central tenets of Scrum is the self-organising, autonomous team. A self-contained team which can – for want of a better phrase – crack on.

At the start of each sprint, the backlog will have been prioritised, user story estimates made and sprint goals set. The scrum team is making a joint commitment, a team commitment, to the Product Owner – and to itself – that this work will be completed within the upcoming sprint.

The Product Owner also commits to this, and also to not changing the work priorities mid-sprint. Once the sprint is agreed, it doesn’t change.

As the scrum team gets better at estimating work, their team velocity will begin to solidify, helping them to make better estimates during the next sprint. Without knowing their velocity, a team’s initial estimates tend to be wildly out.

Why?

Because they’ve never done it before. Estimates – based on User Story Points – are a complete unknown to start with, and so tend to end up as SWAGs (“Silly Wild-Arse Guesses”).

But that’s ok, that’s why we need a solid, self-organising, stable and autonomous team to grow together, get better at understanding their capacity and know how many story points they can deliver in each sprint (that’s the velocity).

But

You can only do that if you have every discipline represented in the team. You can’t make estimates about cutting code if you don’t have any code-cutters on the team. Just as you can’t make estimates of how long it will take to build a house, if you don’t have brick layers on the team.

And that’s why you need cross-functional teams. Teams that have all the skills required to deliver the sprint. Programmers, business analysts, testers, business representatives, architects, plumbers, electricians and brick layers.

If you don’t have cross-functional teams, you can’t be autonomous. If you’re not autonomous you can’t make good estimates, and if you can’t make good estimates you can’t commit to a sprint, and if you can’t do that – well, you may as well draw stumps and head back to the pavilion.

Why is this a challenge?

Because typically, each role family in a change organisation tends to report up through different silos in the organisation, based on each discipline. Project managers tend to be managed in a pool of project managers by a senior project manager. Business analysts tend to to be managed in a pool of business analysts by a senior business analyst.

This is not a bad way of doing things if your organisation is project focussed. Remember, a project is a temporary piece of work, with a beginning and an end, to which resources are allocated – usually from a pool – on a temporary basis. People are taken to the work. Someone does the planning, others do the execution.

But we’re not dealing with projects, we’re dealing with continuous flow value-streams, static teams. We want to bring the work to the people. We want a self-organising, autonomous team of cross-functional experts, where the people who do the doing, do the planning.

And the transition from the one to the other is difficult. From project to value-stream. From discipline-based resource pools to cross-functional teams. It’s a new way of thinking.

Especially as the resources allocated to a scrum team need to be 100% dedicated to their role within that – and only that – scrum team. Not like a project-based organisation where people may be working on several projects at the same time.

“Self-organising” and “Autonomous” are also challenging concepts for Leadership teams who are used to top-down control.

Cross-functional teams are essential, but difficult to achieve in transition.

3. Product Ownership

The role of Product Owner is critical. And misunderstood. And difficult to get right.

Product in this sense is the term used to describe the “produce” from the scrum team. The output. The code. The working, tested, code – which has been written to satisfy the requirements as stated in each user story.

So who tests the code?

Mid-sprint, it is the responsibility of the whole scrum team to ensure that the code satisfies the requirements. That it does what it says on the tin.

There are various methods available to help test code:

– Test-Driven Development is a technique where requirements are turned into micro-specific test cases, written up in the user story, and the code is developed using a small lifecycle to pass the new tests.

– Pair Programme is a technique in which two programmers share the same workstation. One is the Driver who writes the code, and the other is the Navigator or Observer who reviews the code as it is written. The programmers swap roles regularly.

– In-sprint QA is a technique where a member of the scrum team watches the Completed status of user stories, and walks the code with the programmer reviewing it against the requirements written up in the user story.

So that all happens during the sprint.

The scrum team had committed to completing x story points during the sprint planning, which means n user stories have now been completed by the end of the sprint. They have all been tested, to the satisfaction of the scrum team. Sprint closed. Doughnuts bought. Coffee on. Well done everyone.

So who is going to approve the work that has been completed?

Who is going to check that the “working, tested code” actually works in line with user expectations? That it does what it says on the tin – according to those who are going to use it.

The Product Owner. That’s who.

The product owner has the final say. “Yes, it does what is required.” Or “No, it doesn’t do what is required.”

Remember, the Product Owner is not interested in the actual written requirements that have been picked up by the programmers, interpreted and translated into code – per se. The Product Owner is interested in whether the code being presented does what it needs to do. That it meets the expectations of the users.

The rest of the scrum team wants the Product Owner to be happy with the functionality of the code that has been presented, and that the label on the tin matches the contents.

What if the Product Owner does not approve the code?

If there are issues with the code and the Product Owner feels that it misses the mark, then the associated user stories are put back on the backlog. At the next sprint planning session, the backlog is prioritised, each user story is estimated and the scrum team pulls user stories into the sprint plan until the total number of user story points aligns with the team’s velocity.

Who prioritises the backlog?

The Product Owner. That’s who. And who agrees the sprint plan? The Product Owner.

But here’s the thing – and this is the bit that organisations find difficult to implement – the Product Owner is part of the scrum team. 100%.

A member of the Business community working alongside programmers, business analysts, testers, business representatives, architects, plumbers, electricians and brick layers – on the same team. Together. Every day.

Unheard of.

And there’s the problem.

4. User Story Writing

The user story represents a “bucket of business value”. If the user story is implemented, the Business will reap the benefits of the value it offers.

So long, that is, that the programmer’s code actually achieves what is represented by the user story, and what the user wants. In other words, if the programmer writes code that will satisfy the business requirements, then good times.

So where are the business requirements written?

In waterfall, they are written up in wopsy-big documents called Business Requirements Documents (BRD). But in agile, since the user story represents the “business value”, the requirement and hence “a good thing that the business wants to be able to do”, the best place to specify the business requirements is the user story itself.

And that’s what we do.

There are lots of guidelines about how to write user stories, but the best way is to think about the “actor” who will be using the functionality represented by the user story and the benefit it will give them.

Example:

As an iPhone user, I want to be able to change the time zone manually, so that I can work to Indian Standard Time (IST) while in London.

Is that enough detail?

Well, that depends. Can you build it? Can you test it?

We want to do just enough work, to ensure quality and good delivery. We want to reduce defects, because they just end up being prioritised along with everything else on the backlog in the next sprint.

So we want to write this user story in the most effective, efficient, economic and accurate way possible – so long as it meets the business requirements.

Do we need to specify in the requirements, the list of time zones that the user can chose from? Do we need to specify the need for a “confirm” button? Maybe, maybe not.

Luckily on the scrum team is a member of the business – The Product Owner – and some Business Analysts who are familiar with that particular area of the business, plus a QA expert and – of course – a programmer. So together, writing the user story should be a doddle.

Remember, the agile manifesto states as one of its four values:

Working software over Comprehensive documentation

So as long as we’ve got enough information to build, test and demonstrate to the Business, then we’re good to go.

This is quite a simple example though. Imagine a more complex example where we’re providing a screen to validate new car insurance policy details. A simple statement like the one above simply won’t hack it.

Complex Example:

As a policy administrator, I want to be able to validate the current policy and highlight any errors so that I can work with the user to correct them and proceed the application to the next stage.

All very dandy, but let’s ask the same questions as we did before:

Can you build it? Can you test it?

Well, no you can’t do either. We don’t know what to code. We don’t know what the validatation rules are. So in this case, economic though it is, it doesn’t actually help us at all, other than to summarise a requirement.

We need to specify the validation rules, which can be included within the userstory – either in text, or as separate tasks – depending on the house style.

Writing user stories is a new way of thinking. Often, when teams transition to agile, the quality of user story writing is one of the main stumbling blocks for success. Not enough detail, too much detail, hidden context are the usual suspects.

5. Discipline

One of the great misapprehensions in modern-day business change and IT organisations, is the idea that with agile there is no documentation. No governance. No leader. No discipline required. It’s a method were you can just crack on. Get stuff done. Ditch it if it doesn’t work and try again. Oh, and we don’t have to do a wopsy big requirements document. Whoopy doo.

Well – Yes, you do.

No, you can’t just crack on. No, you can’t just ditch it and start again. Yes, discipline is required. Yes, there’s governance. Yes, there’s documentation. Yes, there’s a leader.

In fact, in many ways, more discipline is required to run agile effectively.

Why?

  • Because everything is condensed into two or three week sprints. Plan, analysis, design, build, test, integrate.
  • We have to bite off enough work from the backlog to keep us gainfully employed during the sprint, but not too much, and not too little – and we need to work at getting better at estimating what this looks like – so we can get better next time.
  • We need to work as a team, a cross-functional team, sharing goals and objectives, taking joint ownership, responsibility, accountability.
  • We need to get better at how we work as a team – how we write user stories, how we test them during the sprint, how we get better at understanding the strengths and foibles of everyone on the team, so we can fill the gaps, strengthen the foundations, distribute knowledge.
  • We need to get better at delivering working, tested, code the first time round – to reduce the number of defects which will just end up on our backlog another time.
  • We need to get better at getting better. Kaizen, the Japanese word for “improvement”, has been adopted by the agile world to represent not just improvement, but continuous improvement. Or as I like to call it relentless improvement. Getting better is part of agile. It is ubiquitous. Or at least, it should be. A team should always be looking at ways in which it can get better at getting better.
  • And the simple truth is, that all of that needs discipline to make it work. Lots of it. Gone are the days when projects lurch from monthly meeting to monthly meeting. Agile is about getting stuff done, quickly, efficiently. Never looking too far ahead. Never getting stuck in the now. Working together in a smart way. Adjusting, tweaking, getting better and getting better, focussing on quality over quantity, and making sure we get there in time for tea.
  • Agile Target Operating Model?

    I’ve heard many people say that their company “is agile”.   As it turns out – after a short discussion – what they mean is that their company has a software development team which uses Scrum quite well.

    And by “quite well” they mean that they are using some aspects of Scrum (like daily stand-ups and sprints) in an organisation that is about as agile as a super tanker doing a three-point turn. In a dry dock.

    Don’t get me wrong, having a single software development team using Scrum can be a good thing – there are plenty of advantages in using stand-ups and sprints – but in isolation from the rest of the organisation, they are missing out on the big bananas.

    Why?

    Because nowhere in the Agile Manifesto does it mention where a team’s work comes from, or which work has the strategic priority, or even what the overall strategic roadmap looks like. Or even that there is one.

    The Agile Manifesto “merely” states the value preferences of the “founding fathers” to be adopted by a software development team – once they have been allocated the work.

    The Agile Manifesto states:

    We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

    Individuals and interactions over processes and tools
    Working software over comprehensive documentation
    Customer collaboration over contract negotiation
    Responding to change over following a plan

    That is, while there is value in the items on the right, we value the items on the left more.

    We can see that the manifesto is not a set of concrete steps. It’s not a method. It’s a set of principles. A set of values.

    Unsurprisingly, various methodologies have arisen to put some structure around these agile principles, one of which is Scrum.

    From Scrum we get:

    • Scrum Master
    • Product Owner
    • Self organising, cross-functional, Scrum team
    • Sprints
    • Show and tell or sprint demo
    • Retrospective
    • Stand-ups

    But not:

    • Five year strategic roadmap
    • Strategic product priorities
    • Investment sign-off
    • Organisational change
    • Change management

    So whereas a particular software development team might be using Scrum “quite well” to carry out the work they have been allocated, the overall organisation is not that much better off.

    What we need, then, is a set of values, principles, behaviours and guidelines for tracking, prioritising, governing, sponsoring and planning work over, say, a five year period – before anything gets anywhere near a software development team to execute.  Or, more realistically, before it gets anywhere near one of many software development teams to execute.

    Moreover, what we need is a structured approach to help us do this.

    Why?

    Because if we’re going to be working with a five-year strategy roadmap, there may well be more than one scrum team required to execute the work.  So somehow, we have to coordinate activities across the Business, the business architects, the scrum teams, the sponsors and old uncle Tom Cobbly and all.

    So there are two things here:

    1. There is the strategic, five-year planning side of things.
    2. There is the scaled agile side of things.

    But woe betide anyone who thinks and treats these two things as separate, distinct and unrelated.

    Why?

    Because to get the big bananas, we need to align the strategy-setting team with the business teams, with the change management team and the software development teams.

    In other words, end-to-end alignment.

    And while we’re at it, we should reorganise ourselves along product lines, so that the end-to-end, strategy to delivery is a product-focussed value chain.

    In this scenario, the scrum team’s Product Owner is – guess what – a real product owner. Someone in the business who is accountable to the executive team and strategy setters, and responsible for the success of that product in the market.   Someone with skin in the game.

    And the scrum team itself is focussed on delivering that product.  And only that product.   Because that’s what they do.  And the scrum team next door, they have one too.  And the team next to that.

    Remember, we’re not talking about Projects.  We’re talking about product development. A Project is where you assemble a group of people to tackle a temporary piece of work, and when it’s complete, the people go back to something else.  The work is fixed, the people are fluid.  With a project, you must bring the people to the work.

    In contrast, in agile it’s the scrum team which is fixed.  The work is fluid.  We bring the work to the people.

    So who decides which work goes to which scrum team?   Who decides when the work goes to the scrum team?  If the agile scrum team is fixed and we’re going to bring the work to the team, then we better have a hopper of future work available, prioritised, sorted, approved, and ready to send off.

    And there’s it is.  The central point for all of this.  That “hopper” of work is the strategic roadmap.

    What we need, then, is a way in which we can pull all this together.

    • A way in which we can plan future work according to our strategic priorities,
    • A way in which we can allocate work to standing scrum teams to execute,
    • A way in which we can govern work to ensure no one drifts off piste,
    • A way in which we can coordinate dependencies across the company, and across scrum teams,
    • A way in which everyone in the business feels engaged, part of the change journey and with skin in the game.

    What we need, then, is an Agile Target Operating Model.

    Boom.

    Once that’s in place, in the way in which I have described, then – and only then – can you call your organisation agile.   If you must.

    MVP?

    What is a Minimal Viable Product?

    Although first coined by Frank Robinson, the term Minimal Viable Product has been popularised by Eric Ries in his work The Lean Startup Methodology.

    In it, he describes:

    “A core component of Lean Startup methodology is the build-measure-learn feedback loop. The first step is figuring out the problem that needs to be solved and then developing a minimum viable product (MVP) to begin the process of learning as quickly as possible.” – Eric Ries

    Just so as we’re clear, I am not casting any votes for or against Mr Ries’ methodology, that’s not what this post is about.    The important point here is the concept of the build-measure-learn feedback loop, because this implies that the MVP is designed to “get something of value out there”, see what happens, learn from it and then work out how to improve things, how to move on, how to adapt to take advantage of the market, how disrupt the market more, how to do whatever your strategy says you want to do.

    And then?

    Do it again (That’s the “loop” in build-measure-learn feedback loop). And again. And again. Each time adjusting to take advantage of current market conditions, customer needs, changing appetites.

    He goes on to say that:

    “Startups exist not to make stuff, make money, or serve customers. They exist to learn how to build a sustainable business.” – Eric Ries

    And for a Startup, that’s important. Critical in fact. And that’s why it’s important to get to market quickly, with a valuable product or service.

    Why?

    Because you want your new customers to buy what you have on offer, so that you can do the measure and the learn and then crack on with the loop. And, you don’t want anyone else to barge in on your newly carved out piece of pie. Get your customers interested, hooked and wanting more.

    There are plenty examples of companies who adopted this MVP approach: Twitter, Facebook, Amazon, Airbnb, Dropbox, Spotify to name a few. There are good write-ups of these companies, and more, available on line to those who are interested.

    But what about non-startups?

    What about companies whose change teams are developing business software applications for their own front-line staff.

    Does an MVP approach work in that case?

    Or a company rolling out a bespoke policy admin system to their own internal Operational staff. Does it make sense to use MVP for them? After all, the “market” doesn’t have a choice, the Operations department will use the policy admin system provided by the internal change team. Ain’t no choice.

    The answer is “Yes” and “No”.

    If you already know the totality of the product you want to deploy into, say, the Operations team (because it’s an “all or none”, fixed scope product, where there is no value in deploying elements of the product separately), then the answer is “No. No point.”

    If however, you’re launching an product that your customers will use online, a business portal, for example, that will grow over time then the answer is “Yes, yes, yessington, yessy, yes.”

    That doesn’t mean that the poor old Operations team never gets shiney new business applications deployed as part of an MVP. The point is that MVP works best when the product being rolled out is not a fully-conceived, fixed scope, one big lump of software. Even Back Office staff may require business applications, where functionality and scope can grow over time. And in these cases, MVP is quite the thing. Very de rigueur.

    There are lots of definitions of MVP, but a good working definition, averaged out, and maybe dumbed-down, could be:

    “The Minimal Viable Product (MVP) is a product which is launched with enough features to satisfy early adopters, and provide feedback for future development.”

    or, slightly more harsh:

    “The Minimal Viable Product (MVP) is a product with the simplest possible feature set which allows it to be deployed.”

    But there is danger here. It is very easy to fall into the trap of thinking you are deploying an MVP, whereas in fact you are deploying an unhealthy, paired-down, reduced value product.

    Why?

    Because during the initial planning and brain-storming sessions (let’s be methodology agnostic here), there is a collective feeling of wanting to promise the world.

    • The Sponsors get excited because their customers are going to love it,
    • The developers get excited because they’ll be using new technologies and gizmos
    • The change team gets excited because they’re going to espouse Scaled Agile Framework (SAFe)
    • The Executive gets excited because this is bang on strategy
    • The Marketeers get excited because they can target the next Expo for launch
    • Everyone gets excited.

    At the end of the session, the project team goes away and works out plans, provisional costs, dependencies, resource requirements, the benefit model, the business case, the cost benefit analysis (CBA).

    And Boom.

    To hit the Expo date – which by the way has now been announced as the launch date (too cynical?) – It will cost a quidzillion dollars, require all the development teams to drop all other work, and will blow the business case over a 3 year period, up the risk and generally be too challenging to contemplate.

    What to do?

    Reduce scope. Oops. Now we’re moving backwards. The MVP has now become

    “The collection of features we can afford, because we can’t afford to do everything else.”

    This is the danger, because it turns the MVP into a budget capping tool, rather than a description of an innovative, calculated feature set designed to “get value out there quickly”, and provide a basis for continuous improvement using the build-measure-learn feedback loop.

    I know many people who don’t like the concept of MVP at all, and that’s all cool and dandy.

    What I’m saying is that you should aim to deploy well-conceived, value-add, meaningful products and services from the outset – whatever you like to call it.

    %d bloggers like this: