A few years ago, to explain what goes wrong for many organisations that “go agile”, I wrote an article called “Putting the Kart before the Horse” [1].
Go-karting is where most of the current Formula One racing drivers first learned the basics of race-craft. Antony Marcano, a former kart racer himself, recounts a father-and-son racing experience that helps him explain what goes wrong for many organizations that adopt Scrum as their first attempt to “go agile.”
In this article I explained how novice drivers try to go as fast as possible rather than trying to master the racing line:
At the open practice session my son and I attended, novice drivers seemed to approach their first lap as if it really were as easy as experienced drivers make it look. They floored the throttle and flew down the straight only to crash—painfully and expensively—into the barrier at the first hairpin turn.
I went on to liken this to how many teams adopt agile…
Organizations starting their transition to agile methods with Scrum are much like the novice drivers trying to go fullthrottle before learning how to take the corners. Before being able to truly bend and change their software with speed and ease, they fly into short iterations and frequent incremental product delivery—crashing painfully into the barrier of hard-to-change software.
It was my son’s first experience in a go-kart. We started by driving slowly with him following me to learn the racing line. We gradually went faster and faster. Soon, we were the quickest drivers on the track.
Since then, he has gone on to advance further and further in his racing. Back then, we were in slow, 35mph go karts. This year he started racing for a team in race-tuned karts (see photo). The driver-coach in the team watched him driving on his first few attempts in his new high-performance machine (70+ mph, super-car acceleration). While he was reasonably quick, he wasn’t smooth.
Damani Marcano driving his 2013 Mach1 Kart for MLC Motorsport
His coach told him “slow down”. His coach said “whatever speed you can do while still driving on the ideal racing line is the speed you should be going”. My son went out again. Initially slower than he was before, his speed progressively built… we watched his lap-times improve dramatically.
Yet again, we relearned this lesson: slow is smooth–smooth is fast.
For some reason, I see teams who are novices in agile development make the same mistake, however, not always feeling like they have a choice. Kanban might make it easier to start from where you are and gradually improve but it’s ok if you’ve decided to start with Scrum. When starting with Scrum, start slow, focus on doing fewer things well first then progressively improve. On a course I gave recently, one of the attendees said “but how do you get management and marketing to back-off enough to allow us to slow down?”
My answer: avoid going faster than you can. But if you feel compelled to go faster, make it a business decision. Help them understand that there is a risk that whatever time you save now will cost you more in the future. Help them understand all the effort you’ll spend repairing the damage that going too fast will cause. Pretty soon you’ll be spending so much time fixing problems and struggling to adapt hard-to-change code that there will be little capacity left to add new features. Essentially, incurring a “Technical Debt” .
As a general rule, I always try to start something new, slow and steady. I only go as fast as I know I can while predictably and sustainably delivering. I’m mindful of business pressures but experience has shown me that by focusing on “making things right” we can deliver smoothly,build trust and progressively become faster.
UPDATE [11-12-2013]: Damani Marcano finished his first ever season 3rd in the Hoddesdon Kart Club Championship Junior Rotax Formula at Rye House, the track that started Lewis Hamilton’s career. This achievement is significant since, as a novice license holder, Damani had to spend the first half of the season starting every heat from the back of the grid. Find out what happens next season by following his story on Twitter and/or Facebook. Who knows, by adding to his ‘likes’ / ‘followers’ you may become a part of his story by helping him become more attractive to a potential sponsor.
Recently, I had cause to ponder the values I hold as a member of a software development team. Values that, alongside other values I hold, drive my choices and behaviours. They sit behind the things I do and how I do them. They underly my thinking when considering how we can improve as a team and as an individual contributing to that team – for example, during retrospectives. This is not a manifesto of what I will value. This is an articulation of the things I do value.
In what I do and how I seek to improve as a team member, I have found that I value:
Throughput over Utilisation Effectiveness over Efficiency Advancement over Speed Quality over Quantity
While there is value in the items on the right, I care about the items on the left more.
Note, that I say I ‘care’ about the items on the left more. I actually do care. I know that I care about these things more because it actually annoys me if I’m being asked to focus on the items on the right (probably because I know that they will be at the expense of the items on the left). I also know because I actually have a positive feeling when I am being asked for the items on the left (probably because I know that, over time, we’ll get the items on the right for free).
So, what do I mean by these ‘buzzwords’. Stick around and I’ll tell you in a series of upcoming blogposts. Some of these apply in ways that go beyond the obvious.
Acknowledgements:
You probably noticed that I used the same format as the Agile Manifesto. This is because it happens to provide a structure that I believe most clearly and concisely communicates the idea.
I’d like to say a special thank you to Andy Palmer and Matt Roadnight for the awesome conversations that helped me find the right words to express these values and ideas.
Let’s say you own a restaurant. Quite a large restaurant. You’ve hired a manager to run the place for you because you are about to take the fruits of your success and invest in opening three more around the country. You leave the manager with a budget to make any improvements he sees fit.
After being away for a few weeks, you return to your restaurant. It’s very busy thanks to the great reputation you had built for it. The kitchen has some new state of the art equipment and you can see that there are a lot of chefs and kitchen-staff preparing meals furiously. Obviously, with a restaurant this full you have to prepare a lot of meals.
Too many chefs?
But then, you notice that there are only a few service staff taking orders and delivering the meals to the customers. Tables are waiting a long time for their meals. You notice the service staff spending a lot of their time taking meals back to the kitchen because they have gone cold waiting so long to be served. You also overhear several customers complaining that the meal they received was not the one they ordered, increasing the demand for the preparation of more meals. You call the manager over and ask him what’s going on… he says “because we need to invest more in the kitchen”. You wonder why. He tells you “because there are so many meals to prepare and we can’t keep up”.
At this point, it’s quite obvious that the constraint is not through lack of investment in the kitchen. Instead the lack of investment is in taking the right orders and getting the meals to the customers. To solve this, I think most people would increase the investment in getting the order right and in how the meals get to the customer not by investing more into the kitchen.
Obvious, right? Despite this, time and again, I see organisations happy to grow their investment in more programmers writing more code and fixing more bugs and all but ignore the end-to-end process of finding out what people want and taking these needs through to working capabilities available to the customer. Business analysis, user-experience, testing and operations all seem to suffer in under investment. If it takes you four weeks to write some code for several new features and then another four weeks for that to become capabilities available to your customer, hiring more programmers to write more code is not going to make things any better.
Sushi and Hibachi
So, how would you advise the restaurant? In the short term, you can get some of the chefs to serve customers while you hire more service staff. Another solution is to invest in infrastructure that brings the meals closer to the customer, such as in hibachi restaurants where the chef takes the order and cooks the meal at the table or in sushi restaurants where meals are automatically transported via conveyor belt.
In software teams, we can bring the preparation of features closer to our customers. We can involve a cross-functional team in the conversation with the customer (such as the chef being at the customer’s table). We can also automate a large proportion of the manual effort of getting features from a programmer’s terminal into the hands of the customer (as in with the conveyor belt). And, there is so much we can automate.
Integration, scripted test execution, deployment and release management can largely be automated. Since speeding up these tasks has the potential to increase the throughput of an entire development organisation, it seems appropriate to invest in these activities as we would in automating any other significant business activity – such as stock-control or invoice processing.
Cooking for ourselves
Why not ask a good number of our programmers to take some time out from automating the rest of the business and automate more of our own part of the business? Taking this approach seems to be the exception rather than the rule. I see organisations having one or two dev-ops folks trying to create automated builds; and similar number of testers, with next to no programming experience, trying to automate a key part of the business – regression testing. And then asking them all to keep up with an army of developers churning out new code and testers churning out more scripted tests.
Serving up the capabilities
Instead, let’s stop looking so closely at one part of the process and look more at the whole system of getting from concept to capability. Let’s invest in automating for ourselves as much as we automate for others – and let’s dedicate some of our best people to doing so.
In short, it’s not just about the speed at which we cook up new features. It’s as much about the speed at which we can serve new, working capabilities to our customers.
“Few would think that Special Forces tactics bear any relation to software project teams. But Antony Marcano draws a surprising parallel between the dynamics of modern Special Forces “room-clearing” methods and the dynamics of modern software development teams.”
My thinking has moved on slightly since then. Recently, several people have expressed an interest in the article.
So, here is an updated version, based on my more recent thinking and with some additional detail that had to be omitted from the original due to word-count restrictions of publishing in printed form…
Please note – The comparison with military and police armed forces is purely metaphorical and specific to the message I hope emerges about roles and titles.
Lessons Learned in Close Quarters Battle
I’m at the door, heart pounding so loud I’m sure everyone can hear it. Four silhouettes are flat to the wall. I’m point man, stuck to the edge of the door we’re about to breach. The team lead whispers through a covert radio mike, “Alpha 1 in position.” Silence… tense anticipation… then, after a thirty-second eternity, my earpiece crackles as control responds, “Standby… Standby… Strike! Strike! Strike!”
The method of entry (MOE) man, on the opposite edge of the door frame, kicks in the door; behind me, the team lead throws in a stun grenade. BANG! As point man, I enter immediately—followed by number two—and five action-packed seconds and three targets later, we’re able to call out “ROOM CLEAR!”
Instantly, we move to the next room. The MOE man is nearest to it, immediately becomes point-man. The man on rear cover follows taking up the MOE position, becoming the MOE man. Meanwhile, the original number two and I are exiting the room.
I’m the first out and, seeing that the number two position on the next door is yet to be filled, I fall in behind the point man, becoming team lead. I am now responsible for calling the next breach and for throwing in the next flash-bang. The former number-two drops in behind me to provide rear cover. Each of us instantly switches roles, and with a deafening bang, the next door is breached without hesitation.
This might sound like a scene from an action movie but, no, it was a close quarters battle (CQB) training session I attended with the rest of The Foundation:Special Operations Group—a top UK Airsoft team. Airsoft is a skirmishing sport similar to paintball but with more realistic looking equipment and no mess.
In this training session, run by a private security contractor, we were practicing the latest CQB techniques taught to police and military armed forces. In CQB situations, armed forces don’t have time to shuffle around to get team members into the position that an individual’s job title might dictate. Lives are at stake (or points in Airsoft). The team must be able to adapt instantly; there can be no waste in the process.
Fixed Roles are accompanied by Waste
Historically, CQB dynamic entry (room clearing) was, and still is in places, taught with fixed roles. Instead of each person reading the situation and falling into the position that maximises the flow of the team from room to room, each person had a fixed role.
Prior to practicing the dynamic role-switching, or ‘read system’ we also tried the fixed role position. This was noticeably slower. Instead of the team-members outside the room falling straight into the position on the next room, they had to wait for the number 1 & 2 (and sometimes number 3) to exit the first room and get into position covering the next door. Only then could the MOE specialist move to the door allowing the last team-member to move up to continue their role providing rear cover.
The extra time it takes waiting for each specialist to be in position can take 10-30 seconds longer per-room. This time adds up to several minutes of wasted time when you have a whole series of rooms to clear. This fixed-role system not only puts the same person at the greatest risk as point-man on each room, as was highlighted by a British Army CQB instructor I trained with last year, but reduces your flexibility or can even halt the operation—especially when one of your team-members is injured (or worse).
If everyone is a specialist, you need more people in those specialist roles to deal with the risk that one of them could be taken out at any time. We don’t have quite this concern in software teams, however, people do fall ill or need time off work for personal reasons.
We Still Need Experts
Indeed, there are experts within a dynamic team. For example, our MOE expert might tackle the especially tricky entries or advise the team on entry tactics before the game, but we all are capable to some degree in MOE. Each of us is capable of dynamically switching roles, quickly adapting to changing circumstances. This is a perfect example of a truly cross-functional team of generalising specialists [1].
Skills Demands are Constantly Changing
This dynamic role switching is almost the opposite of your typical software organisation where each person has a job title that fixes his role—business analyst, programmer, tester. These job titles make complete sense in phased-development approaches (e.g. waterfall) where the work is divided up as if it were a production line: Business analysts pass the outcome of business analysis to developers who pass the result of development on to testers and so on. These job titles make less sense when using agile approaches that integrate these activities so tightly that they are all but inseparable.
More significantly, however, the balance of skills needed during each iteration (or time-box) and even for each user-story fluctuates depending on the nature of the features being implemented. One change may involve more refactoring (changing internal and not external behaviour) and be largely protected by pre-existing automated tests. Another change may involve limited coding and much more exploratory testing. There are endless variations on how the emphasis on each skill-area will change as the work flows through our value-stream.
Like the Airsoft (or Special Forces) team going from one room to the next, software teams must seamlessly go from one story (or feature or business-value-increment) to the next. It’s simply too wasteful for progress to be halted while we wait for a fixed-role specialist to finish his previous task.
Everyone on the team must constantly adapt so that we continue to maintain a constant and efficient flow of value… Fulfilling our shared responsibility of frequently delivering working software.
History Repeating?
An increasing number of organisations seem to recognize this, creating a demand for multi-skilled people. Interestingly, however, history seems to be repeating itself!
Up to the mid 1990s, high- and low-level software design was performed by systems analysts and then coded by programmers. Perhaps due to the demands of rapid application development, the roles later combined and the multi-skilled analyst-programmer emerged. Subsequently, this became the norm and analyst-programmers were thereafter known only as “developers.”
Today the title of developer-tester (or tester-developer) is emerging in response to the flexibility demanded by agile teams—kind of an analyst-programmer-tester. As the uptake of agile methods grows, this demand is only going to rise! If history indeed repeats itself, the developer-tester may, too, become the norm—negating the need for the “tester” suffix that differentiates them. Yes, the “software tester” job title, one of the few remaining titles derived from phased-development methods of old, could suffer the same fate as Ye Olde Systems Analyst.
This wouldn’t mean that software testing as a discipline will disappear altogether—just that many of the testers and developers of today will need to leave their comfort zones to become the developers of tomorrow.
Acquire ‘Tags’ or Badges – not a Job Title
Fixed, specialised job titles alone could be part of the problem. Maybe we need to stop linking specific roles to job titles. So often at conferences people ask the audience, “put your hand up if you are… analysts… programmers… testers… designers…”
I notice that many people will only put their hand up when one of these is called. You may notice me put my hand up for each of these roles. I think of these labels more like tags than titles. I feel I can tag myself with all of these roles and switch between them (to varying degrees of competency) as the situation demands.
Maybe they’re not so much like tags as badges. In some forces and certainly in the cadets and even among scouts and brownies, as you demonstrate new skills, you are entitled to wear new badges.
The difficulty with fixed-role thinking is that for many, their very identity is attached to their job titles. The challenge becomes showing people why they would want to broaden their thinking. I’m not sure I have time to address that in this particular post.
Maximise (your) Value
I can tell you what’s in it for me, personally. The tasks most relevant to my job-title may not be relevant to the team’s current story or goals. By dynamically switching roles, I am able to do the task that is the most relevant and valuable to the team at that time, within the context of the project’s goals, rather than just the tasks of most relevance to my job title. I am then able to accelerate the speed at which the team can clear each story, as the CQB team clears each room.
I recognise that this isn’t always immediately practical. Some teams are very protective over access to source code… but this is a matter of trust. There are many ways you can earn this trust… It may be that you need to demonstrate your abilities to manage your own git, mercurial or subversion repository before you’ll be given access to the relevant project repositories. It may be that you can demonstrate that you are able to build an open-source code-base using similar technology on your own. You may simply need to be able to talk about the right things while asking another team-member with a different area of expertise for help – demonstrating that you’ve at least understood the basics. So, one of the things outside your job-title that may add value to the team might be learning how to do something that the team will soon need doing.
So, hold on to your job titles and stick to your job descriptions if you choose. Personally, I’ve chosen to develop my individuality, embrace new skills and acquire new ‘tags’ & badges—bringing to the team more value, flexibility, throughput and opportunity.
References: [1] Ambler, Scott. “Generalizing Specialists: Improving Your IT Career Skills.” Agile Modeling, 2006. www.agilemodeling.com/essays/generalizingSpecialists.htm
To find out more about Airsoft or to take your colleagues on a similar journey to this article, check out http://firefight.co.uk. Tell them that this article sent you their way… they know who I am and have already taken one of my client’s teams on a similar journey.
“I don’t think people have the same passion about their jobs. They just want more money.”
Johanna goes on to say:
I, of course, disagreed. The reasons people want money is that organizations have broken the implicit social contract to be fair with their employees […] That means there is strictly a financial contract between the employee and the organization.
There is, however, even more to this topic that I’d like to share.
The Business Incentive
There is a business incentive to paying more per employee that gets hidden by typical “per-unit” cost-budgetting.
Chapter 2 of Dan Pink’s book “Drive” references research (funded by the United States Federal Reserve Bank) that showed that monetary incentives for cognitive tasks will actually have the opposite of the desired effect – perhaps because cognitive capacity is wasted on thinking about what happens if the criteria for the financial incentive are met/not met.
So, financial incentives actually result in poorer performance for cognitive tasks.
Instead, Dan recommends paying enough that money just isn’t something that the employee ever thinks about. This frees up cognitive capacity to focus on the work at hand – thus increasing performance.
As a result, the total output of fewer employees who are paid more can be greater than having more employees who are paid less. This assumes that all the people in these two situations are of comparable levels of talent.
Add to this the fact that a company that does this will not only attract and retain the best talent, the performance gains through increasing the organisation’s “talent-density” can be even greater!
Even if your total salaries budget was the same in both cases and you just had fewer employees, each paid more but delivering the same as the scenario with the larger number of employees – there are still savings to be made on accommodation costs, management overheads etc.
Understanding Drive & Motivation
In Part Two of Drive, Dan Pink explains the three elements of motivation:
Autonomy
Mastery
Purpose
Many of Johanna’s suggestions mostly fall into the “Mastery” category – conferences, book-allowance, etc. Some of her suggestions imply autonomy – such as more flexibility in working hours and holiday/vacation.
A great example of this is Netflix. They started with old-fashioned holiday limits, but eventually…
…some employees recognised that this arrangement was at odds with how they really did their jobs. After all, they were responding to emails on weekends, they were solving problems online at home at night. […]
Since Netflix wasn’t tracking how many hours people were logging each work day, these employees wondered, why should it track how many holidays people were taking each work year?
Netflix no longer tracks holiday time taken by their employees. Despite this, Netflix offices aren’t deserted with everyone on a permanent holiday and its people have made Netflix so successful that they (arguably) played a role in driving a much larger, more well established provider of blockbuster movie rentals to bankruptcy.
Dan delivers some compelling arguments that motivation and getting the best performance from people comes from giving people autonomy, the opportunity to master what they do and a clear purpose (beyond just making a profit for their employer).
Choosing the right incentives
We can take Dan’s “Three Elements” to inspire ideas about what incentives will motivate our people. Or, we can take these ideas completely to heart.
Rather than telling our employees that they have a book allowance and a conference/workshop budget and so on, we could simply give individuals (or teams) a “Mastery” budget and give them autonomy in how they spend it. Or, we could just pay it directly to the employees (like many companies do with a car allowance) and trust that they’ll spend it wisely.
Realistically, there may be taxation benefits to not giving the money directly to the employees. It may also offer more flexibility, say if a team, wanted to combine some of their budget for coaching or bringing a trainer in-house rather than individually going on the same public course.
The biggest fear some will have is that employees will abuse this freedom. If this happens, we can consider the misspent cash as an investment in discovering the people in our company who we might not want in our company anymore.
Some may argue that this is too much of a risk, but you know what they say… the greater the risk, the greater the rewards.
Many of the things I mention in this post can be heard in Dan Pink’s 10 minute talk on “Drive”…
I’ve recently given some time to think about company values on behalf of a client. In my research, I have looked through the stated corporate/business/company values of several organisations, I’m not convinced that many of them are really values.
I’ll take Zappos company values (as they were at the time of writing this) as a perfect example of what I’ve been seeing:
I love the spirit of these statements and Zappos have a culture that seems to reflect them. These statements, however, are not really ‘values’. Instead, these statements are more like ‘behaviours’.
Behaviours are the things we do. Values are the things we care about.
What are the things we care about?
The things we care about are the things that cause an emotional response – such as when we get angry or frustrated at something someone does, shame at something we do or feel joy and pride when we or someone else does something.
For example, if we care about delighting our customers, we may feel frustration when we see a colleague act with apathy towards a customer complaint or we may feel pride when we or a colleague does something wonderful that our customer didn’t expect.
We may see these responses towards in our clients too. For example, if we value Compassion and Empathy and our customer intentionally delays payment because it helps with their cash-flow we may get frustrated – or if they pay well before the final due-date we may feel positively towards them. But the issue of ‘choosing the right clients’ is perhaps beyond the scope of this article.
When we see our people reacting in these ways, we know that we have an organisational culture based on shared values. We know that we care about the same things.
Why do we want ‘company values’?
For some companies, it’s more about branding – a display of the type of company they think future customers or future employees would want to buy the products of or to work with. It is something that appears on the face of the company but isn’t necessarily reflected in the actual behaviours of the people, as we can see from this article about Enron’s company values. The journalist makes the point that all company values are much the same and really are little reflection of the reality:
I know one writer who, while struggling to draft one of these corporate credos, threw up her hands in despair and observed: ”Why not just come right out and say it? ‘We will strive to make as much money as we can without going to prison.’ ”
She was joking, of course.
What I want from stating our company values is to understand what kind of company we want to be and to guide – even drive – what we do, who we hire and who we fire. I want to see that people in our organisation (and even our clients) have shared, or at least compatible, values. I want to see a negative emotional reaction to situations that go against these values and a positive emotional reaction to situations that are aligned with these values. I want to see the people I work with instinctively do ‘the right thing’ based on our shared (or compatible) values without having to be told what ‘the right thing’ is. I accept that ‘the right thing’ for one person and another may be different – and this is where shared or compatible values are the key to a consistent experience of what we do – for the people inside and outside the company.
The things we care about drive us to act, instinctively, based on the situation at hand. If our people share these values, we’ll act reasonably consistently with each other – delivering a consistent service to our customers.
A Code of Conduct?
When we list our values as the things we do there is a danger that these statements become, to all intents and purposes, a code of conduct. Why does this matter?
A code of conduct, in some ways the ‘laws’ of a company, tells people what to do and what not to do. If we need to tell our people what to do and what not to do (i.e. what is ‘the right thing’ and what is ‘the wrong thing’ to do), I believe, we are compensating for having hired the wrong people.
“Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws.” – Plato
Codes of conduct are a way of constraining freedom. In a society where we have no choice as to who is a member of it, this may be necessary. In an organisation where we do have a choice over who is a member of it, the only reason we would have to reduce freedom is if we compromise on the ‘quality’ of the people we hire.
From slide 38 of this presentation from Netflix, they explain how many companies curtail freedoms as they grow and why they aim to increase freedoms. Hiring the right people is key to the success of this approach.
Many companies try to grow more quickly than they can find the right people to do so effectively. They hire the least-worst from the available candidates in order to grow quickly rather than hiring the best. Netflix have chosen to grow no faster than they can find the most talented people who share in their values.
The people in such an organisation can simply be trusted to do the right thing, in any situation, even if that situation isn’t one we’ve thought of previously. A code-of-conduct and its loopholes is then redundant.
RiverGlide Values
We spent a lot of time thinking about our company values when we first created RiverGlide. We (Andy Palmer, James Martin and I) discussed, explored and refined our understanding of what we cared about and reflected that in our stated values. We learned more as time passed. We added to them (quite recently) because we realised there were many more things that we cared about. How we state our values continuously evolves as we deepen our understanding of what matters to us and what we think differentiates us. These values are not the values we aspire to or the values we want to impose on others. They are the values that reflect what we actually care about. They are the values we see in the people we want working with us.
We originally found ourselves wording our values like this:
<the thing we care about> – <how we reflect that in our behaviour>
Now, I think we’ll be experimenting with this subtle change:
<the thing we care about> – <how it makes us feel when…>
For example:
Trust and Transparency – We feel great when we know you trust us through our extreme levels of transparency.
Integrity and Courage – We would be unhappy if we told you what you wantedto hear if that was not the same as what you need to know.
Innovation and Personal Growth – We get a buzz from learning new things, developing skills, trying whacky ideas and cultivating outside-the-box thinking.
Compassion and Empathy – We love what we do when you love what we do. We are as passionate about your people and products as we are about our own.
Joy and Creativity – We are inspired by fun and creativity – whether it’s in what we do or what we help you do.
Behind these values is a single purpose to our company – we make things easy – hence our tag-line “flow without friction“.
Your Company Values What?
So, what does your company appear to actually value? What values does the culture of your organisation reflect through how it rewards, recognises and respects the things that people do? How do you feel when people act in a way that is aligned or against these values? How does all of this match up to what your company says are its core values?
Why does any of this matter? It matters to me because I am happier when the people I work with are happy – clients, contractors, employees and colleagues alike. It matters to me because I want to trust that the people around me will ‘do the right thing’ and that we’ll all generally agree that what they did was the right thing (even if sometimes we have to have a discussion to understand why). It matters to the people in the company because we know we’ll share in a vision of what kind of company we should be and be motivated to make it a success together – from the most skilled & experienced craftsmen to the smartest and passionate intern.
For us this was relatively easy because we figured out the essence of our core values early in the life of our company and it has formed the foundation of all our working relationships. For you, a legacy culture may not be so easy to redefine. But, if you have a vision of the culture you want to inspire in your organisation or team… If you understand what matters (or should matter) to you and your people and what will bring your company, and the people within it, success… I think you’ll have a great starting point to begin the harder task of spreading those values throughout the culture of the people in your company and teams.
One of the key characteristics of how we coach our clients’ teams is that we help them start from where they are and introduce small, frequent changes that help them progressively achieve their goals.
Each incremental change is driven by a problem the teams recognise they are facing. We then help to find a small change they are happy to introduce as an experiment. This change must be a solution or a step towards a solution to the identified problem. Sometimes this experiment will be limited to a single iteration. Sometimes it’s limited to a single user-story in a given iteration.
Based on the outcome of the experiment, the team decides what to do next. They may continue the experiment, introduce the change beyond the limitations of the experiment or even abandon that change and try something else.
This has two distinguishing factors.
1. Solving Problems: We focus on solving problems not introducing solutions
1. Solving Problems: For example, we’ve often been contacted to ‘introduce TDD’ or ‘transition a team to Scrum’. Usually, we find that behind these solutions are problems that our client instinctively understands are there but articulates them as these kinds of solutions. Sometimes they want to reduce the amount of re-work, or get early visibility of achievable scope within a time-constraint. Other-times it’s a solution for solution sake.
By solving the problems the people in the organisation recognise as holding them back, they are bought into each change. Sometimes our job is to help them recognise the problems. Retrospectives are a great way of achieving that.
2. Continuous improvement: When helping an organisation to solve the problems they face they expect large and significant change. Instead we help them make a continuous series of small, team-driven changes. This allows them to continue to deliver with the net effect of gradual and continuous improvements in productivity.
We generally find ourselves taking this approach because for most of our clients, big-bang change is not practical simply due to the impact on productivity. We can understand this using the Satir Change Model (explained very well by Steven Smith).
In this simplified and slightly adapted representation, you can see that with a large change there is a period of net-negative productivity. Once the improvement starts to take hold, performance increases take productivity back into the black.
On rare occasions when an organisation’s software reaches critical mass (it’s more expensive to change than to replace) big-bang changes might be necessary. We’ve worked with a client that had exactly that problem. They took the brave step of ceasing delivery while they redefined how they did things and coached their teams in how to do it. This worked out positively for them. After about 6 months of intensive coaching and 3 months of implementation they delivered a revenue generating system to replace something that had been previously worked on for 18 months and had remained incomplete.
Most organisations would find it difficult to take that step and need to continue to deliver whilst transitioning from how they work today to how they want to work in the future. It is for this reason that we find ourselves employing small incremental changes, eliminating the things that add friction to their process – one problem at a time. Doing this with small experiments helps the organisation limit the risk and achieve continuous delivery and continuous improvement.
A way of understanding how this works is with the same Satir Change Model. If we take the curve shown above illustrating big-bang change, shrink it so that each change represents a much smaller alteration to working practices and then repeat, what we end up with is a much healthier looking series of changes.
Yes, each change can slow productivity temporarily but the impact is dramatically reduced and quickly offset by the improvements gained.
The area under the graph is productivity. If the changes are small enough there is never any period of net-negative output.
Another reason this works well is that it reduces the amount of cultural resistance that you have to deal with. Instead of a lot of resistance from many people for complex reasons, you tend to have only a few people resisting the change. Because the change is driven by a need to solve a recognised problem you have more people in favour of the change. Because change is frequent, people get used to change. In fact, they become experts at it and no longer resist the mere idea of change.
Commercially, it also gives you much more flexibility and allows you to adapt your vision continuously as you learn more.
Julian Davies, a developer at one of our clients, likened this to sailing. To travel from point a to point b in sailing you do so in a series of direction changes, called tacking. This is necessary when point b is against the wind.
You could, theoretically, do this in two long legs with one direction change. However, this leaves you vulnerable to changes in wind-direction potentially taking you significantly, perhaps even catastrophically, off course. Tacking is generally done with a series of small diagonal legs where each leg allows you to adapt to the changing wind. These frequent opportunities to read the context, i.e. the wind and currents, means that we will only ever be slightly off course with plenty of opportunity to recover.
Julian likened it to agile development in general but I think it applies equally to what I’m talking about here today.
With big-bang changes, what happens when we’re in the deepest trough of the curve and an opportunity arises? It is much more difficult to change course. With small changes we can put the latest experiment on hold to capitalise on that opportunity. When the wind changes on our projects, say when someone leaves or half the team is ill with a winter flu bug, we can quickly respond to those changes.
Acknowledgements: Thanks to Andy Palmer for reviewing this article and providing the snappy title.
Thinking through writing… on innovation, business, technology and more
