Humans are thought to be social animals but of a special kind. We love to meet people, talk to them, have fun with them but somehow, we don’t get along and work together as a group. It doesn’t matter whether it’s an extended family, a commune, a small firm or a big corporation, most of the times we fail to deliver together as a team. In the early 1990s software developers Jeff Sutherland and Ken Schwab identified that teams weren’t delivering on their potential. They found out that it wasn’t about work ethic or the right supply of competitive juices, it was the way people were working.
Charting success
It’s a problem that has been with us for a long time. Henry Gantt came up with his unique solution to address this challenge. He invented his famous Gantt Charts around 1910 and propounded that for success all the work needed to be done on a massive project should be laid out for everyone to see. These charts were very successfully used by Chief of Ordnance General William Crozier during WWI to enhance the productivity and distribution of the ordnance to US Army.
Gantt Charts were later adopted heavily by most US major firms for planning purposes. Most corporations had lots of intelligent people working for months, figuring out what needed to be done. Then they spent more months planning how to do it. They produced beautiful charts with everything that needed to be accomplished and the time it would take to complete each and every task. Then, with careful colour selection, they showed each piece of the project cascading down to the next like a waterfall.
With the advent of personal computers in the 1980s making it easy to create these intricate charts – and to make them really complex – they have become works of art. Every single step in a project is laid out in detail. Every milestone, every delivery dates. These charts truly are impressive to behold. The only problem with them is that they are always wrong.
It’s just so tempting: all the work needed to be done on a massive project laid out for everyone to see. In many companies there are dedicated teams of people whose only job is to update that Gantt chart every day. The trouble is, once that beautifully elegant plan meets reality, it falls apart. But instead of scrapping the plan, or the way they think about the plan, managers instead hire people to make it look as if the plan is working. Essentially, they’re paying people to lie to them.
Sutherland and Schwab had worked on number of these big ‘waterfall’ projects that inevitably failed to deliver and started looking for an alternative framework to manage teams. And through tons of research and experimentation and looking over past data Jeff realised that we all needed a new way of organising human endeavour. Around 20 years ago they came up with a new approach called Scrum. None of it is rocket science; it’s all been talked about before. There are studies going back to World War II that lay out some of the better ways that people work. But for some reason people never really put together all the pieces. Over the past two decades Sutherland and Schwab tried to do just that, and now this methodology has become ubiquitous in the software development. At giants such as Google, Amazon, and Salesforce.com, and at small start-ups, this framework has radically shifted how people get things done.
At its root, Scrum is based on a simple idea: whenever you start a project, why not regularly check in, see if what you’re doing is heading in the right direction, and if it’s actually what people want? And question whether there are any ways to improve how you’re doing what you’re doing, any ways of doing it better and faster, and what might be keeping you from doing that.
Scrum has its roots in Japanese thought and practice. In Japan Scrum isn’t seen as the latest work fad. They regard it as a way of doing, a way of being, a way of life.
Life experience
Scrum, like the Tango, is something that you can only really learn by doing. Your body and your mind and your spirit become aligned through constant practice and improvement. In the Japanese martial arts, there is a concept called Shu Ha Ri, which points to different levels of mastery. In the Shu state you know all the rules and the forms. You repeat them, like the steps in a dance, so your body absorbs them. You don’t deviate at all. In the Ha state, once you’ve mastered the forms, you can make innovations. Put an extra swing in your step down the dance floor. In the Ri state you’re able to discard the forms, you’ve truly mastered the practice, and you’re able to be creative in an unhindered way, because the knowledge of the meaning of the tango is so deeply embedded in you, your every step expresses its essence. Scrum is a lot like that. It requires practice and attention, but also a continuous effort to reach a new state – a state where things just flow and happen. If you’ve ever watched great dancers or gymnasts, you know that their motion can almost seem effortless, as if they’re doing nothing but simply being. They seem as if they couldn’t be anything else but what they are in that moment.
In Japan this approach to work was widely used in production lines of multiple conglomerates. Work doesn’t have to suck. It can be an expression of joy, an alignment toward a higher purpose. We can be better. We can be great! We just have to practice. Toyota was an early pioneer of this approach and Taichi Ohno detailed this philosophy in his classic book Toyota Production System.
One of the key concepts that Ohno introduced is the idea of ‘flow’, that production should flow swiftly and calmly throughout the process, and, he said, one of management’s key tasks is to identify and remove impediments to that flow. Everything that stands in the way is waste. Eliminating waste must be a business’s first objective. For Scrum to really take off, someone in senior management needs to understand in his bones that impediments are nearly criminal.
Another thing management needs to keep focus is on ‘value’. In software development there is a rule, borne out by decades of research, that 80% of the value in any piece of software is in 20% of the features. Making people prioritize by value forces them to produce that 20 percent first. Often by the time they’re done, they realise they don’t really need the other 80%, or that what seemed important at the outset actually isn’t.
The most important component of the Scrum is the ‘team’. Teams are what get things done in the world of work. There are teams that make cars, answer phones, do surgery, program computers, put the news on, and burst through the doors of apartments occupied by terrorists. Certainly, there are artisans or artists who do work by themselves, but teams are what make the world go ’round. And they’re what Scrum is based on. Everyone knows this, but in business we all too often focus solely on individuals, even if production is a team effort. Think of performance bonuses or promotions or hiring. Everything is focused on the individual actor, rather than the team. And that, it turns out, is a big mistake. Managers tend to focus on the individual because it makes intuitive sense. You want the best people, and people are different, so focus on getting the best performers, and you’ll get better results, right? Well, it’s not quite the New England Patriots of the Tom Brady era or Barcelona of the early Messi era. When those teams were on, it seemed as if they were playing a different game than everyone else. That absolute alignment of purpose and trust is something that creates greatness. We’ve all seen those teams. Some of us have been lucky to be on one – or more than one – over the course of our lives. Some teams change the world, and others are mired in mediocrity? What are the common elements that truly great teams have? And, most important, can we reproduce them? These are the questions that kept Jeff awake at night, in his ongoing research he came across a seminal paper The New Product Development Game, by Professors Takeuchi and Nonaka where they described the characteristics of the teams they saw at the best companies in the world:
Transcendent: They have a sense of purpose beyond the ordinary. This self-realised goal allows them to move beyond the ordinary into the extraordinary. In a very real way the very decision to not be average, but to be great, changes the way they view themselves, and what they’re capable of.
Autonomous: The teams are self-organising and self-managing, they have the power to make their own decisions about how they do their jobs, and are empowered to make those decisions stick.
Cross-functional: The teams have all the skills needed to complete the project. Planning, design, production, sales, distribution. And those skills feed and reinforce each other. As one team member that designed a revolutionary new camera for Canon described it: “When all the team members are located in one large room, someone’s information becomes yours, without even trying. You then start thinking in terms of what’s best or second best for the group at large and not only where you stand.”
The Japanese professors compared the teams’ work to that of a rugby team and said the best teams acted as though they were in a scrum: “…the ball gets passed within the team as it moves as a unit up the field.”
Jeff spent a lot of time pondering over the paper and went on to create a framework to form such high performing teams that aims for a higher goal, organizes itself, and constantly feeds off each member’s skills? After all, you can’t just yell at people to be more self-organized and transcendent; the motivation has to come from within. Imposing it will kill what you’re trying to do. Might there be a simple set of rules that encourage the formation of magic? During the 1990s he worked with Ken Schwaber to formulate the scrum framework, a move that culmunated in what became known as the Agile Manifesto. It declared the following values: people over processes; products that actually work over documenting what that product is supposed to do; collaborating with customers over negotiating with them; and responding to change over following a plan.
Working in sequence
Scrum works by setting sequential goals that must be completed in a fixed length of time. In Scrum we call these cycles ‘sprints’. At the beginning of each cycle there is a meeting to plan the sprint. The team decides how much work they think they can accomplish during the next two weeks. They’ll take the work items off that prioritized list of things that need to be done and often just write them out on sticky notes and put them on the wall. The team decides how many of those work items they can get done during this sprint.
What Scrum does is bring teams together to create great things, and that requires everyone not only to see the end goal, but to deliver incrementally toward that goal. It’s management’s responsibility to set the strategic goals, but it’s the team’s job to decide how to reach those goals. Management didn’t even have to manage. Instead, team members managed themselves. Best teams are unselfish, autonomous and also cross-functional, they can get the whole project done. In Scrum there are no handoffs, Jeff had realised early on that whenever there are handoffs between teams, there is the opportunity for disaster.
But just because cross-functionality can achieve great results, you shouldn’t play Noah and throw two of everything into a team. The team dynamic only works well in small teams. The classic formulation is seven people, plus or minus two, though it has been seen that teams as small as three function at a high level. What’s fascinating is that the data shows that if you have more than nine people on a team, their velocity actually slows down. That’s right: more resources make the team go slower.
Also Scrum teams are self-managed but in practice Jeff noted that all teams needed someone whose job it was to make sure the process itself was effective. Not a manager – more of a servant-leader, something between a team captain and a coach and is formally known as ‘scrum master’. He or she would facilitate all the meetings, make sure there was transparency, and, most important, help the team discover what was getting in their way. The key part of that was to realize that often the impediments aren’t simply that the machine doesn’t work or that a team member is a jerk – it’s the process itself. It was the scrum master’s job to guide the team toward continuous improvement – to ask with regularity: “How can we do what we do better?”
Time is the ultimate limiter of human endeavour, affecting everything from how much we work, to how long things take, to how successful we are. The relentless one-way flow of time fundamentally shapes how we view the world and ourselves. And so, in Scrum framework a Scrum Master embarks on what we call ‘sprints’. These are called sprints because the name evokes a quality of intensity. The idea is that team is going to work all out for a short period of time and then stop to see where they were. Scrum Master will facilitate task tracking through a board divided into a few columns: Backlog … Doing … Done. Each sprint, team members put into the Backlog column as many Post-its as they think can get done that week. As the week goes by, a member of the team will take up one of those tasks and move the sticky to Doing. When it’s finished, it’ll get moved to Done. Everyone on the team can see what everyone else is working on at every moment. An important point: nothing gets moved to Done unless it can be used by the customer. sprints are what are often called ‘time boxes’. They’re of a set duration. You don’t do a one-week sprint and then a three-week sprint. You have to be consistent. You want to establish a work rhythm where people know how much they can get done in a set period of time. Often that quantity surprises them. One crucial element of an individual sprint, though, is that once the team commits to what they’re going to accomplish, the tasks are locked in. Nothing else can be added by anyone outside the team.
The Scrum Master, the person in charge of running the process gathers the team every morning into what is known as ‘daily stand-ups’ and asks each team member three questions:
- What did you do yesterday to help the team finish the sprint?
- What will you do today to help the team finish the sprint?
- What obstacles are getting in the team’s way?
That’s it. That’s the whole meeting. If it takes more than 15 minutes, you’re doing it wrong. What this does is help the whole team know exactly where everything is in the sprint. Are all the tasks going to be completed on time? Are there opportunities to help other team members overcome obstacles? There’s no assigning of tasks from above – the team is autonomous. There’s no detailed reporting to management. Anyone in management or on another team can walk by and look at the Scrum board and know exactly where everything stands.
When Jeff and Ken began Scrum in 1993, there was no product owner but there was of a leadership team which had a bunch of other responsibilities besides figuring out exactly what the team should do in each sprint. The problem was, after the second sprint velocity went up 400% in the next sprint, and the team finished in a week what they thought would take them a month. There was no more backlog for them to work on. The difficult part wasn’t figuring out what you to accomplish, it was figuring out could be accomplished. The key is prioritising the work. In Scrum we call the person that fulfills that role the ‘product owner’. The product owner decides what the work should be. He or she owns the backlog, what’s on it, and, most important, what order it’s in. The scrum master is the how and the product owner is the what of Scrum.
There are four essential characteristics that make a successful product owner:
The product owner needs to be knowledgeable about the domain. By this it means two things: The product owner should understand the process the team is executing well enough to know what can be done and, just as important, what can’t.
The product owner has to be empowered to make decisions. Just as management shouldn’t interfere with the team, the product owner should be given the leeway to make decisions about what the product vision will be, and what needs to be done to get there.
The product owner has to be available to the team, to explain what needs to be done and why. While the product owner is ultimately accountable for the Backlog, there needs to be a constant dialogue with the team.
Four, the product owner needs to be accountable for value.
What Scrum does, by delivering a working increment, is give the product owner the ability to see how much value that increment creates, how people react to it. Then, based on that information, product owner can change what the team will do in the next sprint. This sets up a constant feedback cycle that accelerates innovation and adaptation, and enables the product owner to measure how much value is delivered. Everyone works toward the same goal and with the same vision: deliver real value as fast as possible.
No hidden agendas
One element of Scrum that’s often a prelude to achieving autonomy, mastery, and purpose is transparency. The idea is that there should be no secret cabal, no hidden agendas, nothing behind the curtain. Far too often in a company it isn’t really clear what everyone is working on, or how each person’s daily activity advances the goals of the company. Because the team knows what has been done and what still needs to be done, they can regulate themselves. They know what they have to do, they can see if a colleague is in trouble, if a story has been in the ‘doing’ column too long. The team can self-organise to defeat problems that become obvious once everything is transparent. the more connected people are to other people at work, the happier they are – and, apparently, the more productive and innovative as well.
Scrum is not only about refining the team processes but also about changing the team mindset. Psychologists, including Harvard’s Ben-Shahar, say that one way to analyse how people approach the world is by asking whether what they’re doing makes them happy today, and whether it will make them happier tomorrow. This is a useful lens to look at people in work environments. People tend to fall into four types according to Ben-Shahar. The first type, the ‘hedonist,’ is someone who is doing what makes them happy right now. Tomorrow? Let tomorrow worry about tomorrow. I’ll just enjoy today. This kind of behaviour is seen a lot in start-ups: a bunch of people in the figurative garage just making stuff, because it’s cool and it’s fun. But there isn’t a lot of attention paid to creating a sustainable product. Very little mental energy is channelled into how this thing will be working in a month, let alone a year down the road. And what usually happens is that the investors in these guys get worried. So, they hire a bunch of managers to ride herd on the hackers. And, suddenly, the hackers find that the world they enjoyed so much now sucks. There are now all sorts of rules and tests and reports. It sucks today, and they think it will suck forever. Call them now the ‘nihilists’. Then there are the guys who were brought in to run the place. They’re the ones willing to put in eighty-hour weeks (and willing to whip others to do so), because they think they’ll get promoted later, and they’ll be happier. Of course, when they do get promoted, they just have a new set of headaches to contend with that require more time. They enjoy the rat race.
The fourth type of person is the one that Scrum tries to identify and encourage – the individual who is working at stuff that is fun today but has an eye toward a better future and who is convinced it will be fun forever. This sort of person rarely experiences burnout or disillusionment. He’s spared the negative feelings toward work suffered by the hedonists, the nihilists, and the rat-race-addicted managers who strive to make everybody toe the line. What Scrum does is promote a single, galvanizing mind-set. By having everyone work together, the team helps the hedonist look ahead, convinces the nihilist there is a future without whining, and tells those managers stuck in an unending rat race that there actually is a better way.
Scrum accelerates human effort – it doesn’t matter what that effort is. It does so because it’s an effective way to work but more so because it’s a happier way to work.
Tarun Rattan is an engineering manager at Wells Fargo
Subscribers 0
Fans 0
Followers 0
Followers