Check out our first video “Kanban Basics”.
Michael Badali is a Kanban expert with years of experience in Kanban and other Agile methods including nearly 2 years working as an internal coach at HP in China and the UK.
This value is the hardest to do well.
In IT and high-tech, there is a “natural” prevailing culture that makes this first value incredibly difficult. This difficulty is rooted in traditional “scientific management“, but made even more so by a critical additional factor that is mostly invisible: techies solve problems with tools.
Management wants to define processes with clearly described activities, clear inputs and outputs, and clear sources and recipients of the activity (see the description of SIPOC for an explanation of this thinking). Techies build tools to automate these well-defined processes to improve their efficiency, quality and reliability.
Management creates organizational roles with detailed descriptions, detailed goals and detailed performance measurements (see the description of RACI for an explanation of this thinking). Techies build tools to carefully constrain people to these detailed roles to improve efficiency, quality and reliability.
Management has money. Techies want some of that money. So they build the tools to help management get what they really want: a completely automated organization of computers, machines and robots.
The culture of technology is to solve problems with individuals and interactions by introducing processes and tools. The culture of technology is (almost) inherently anti-Agile.
The culture of technology is to solve problems with individuals and interactions by introducing processes and tools. The culture of technology is (almost) inherently anti-Agile.
Individuals and Interactions
Let’s look at the first part of this value in a bit more depth. When we think about work, most of us work with other people. We bring our unique skills, personality and interests to work, and we work with other people who also bring unique skills, personality and interests. In a high-bureaucracy, high-technology work environment, it is easy to forget about all this uniqueness and instead objectify people. When people sense they are being objectified, mostly they feel bad about it. We want to be acknowledged as thinking, feeling, unique beings with agency. Objectification, no matter the source or the rationale, is depressing and de-humanizing. The Agile Manifesto implicitly recognizes this concept and asks us who follow the Manifesto to try to shift our value-focus.
There are many aspects to this concept of humanizing work. Some things that come to mind immediately include recognizing and encouraging people’s capacity for:
Processes and Tools
This side of the value is also interesting. Processes and tools do not have agency. They do not improve on their own. Instead, processes and tools only either remain the same or degrade. Processes and tools are forces for stasis: they encourage maintenance of the status quo. Only humans introduce new processes and tools.
Technologists live in a philosophical double-standard: we build processes and tools for others to use and which we frequently would not like used on ourselves. (We will discuss the cases where me might both build and benefit from processes and tools in a bit.) This is one of the challenges of the type of work we do in technology, but it also applies to many other types of work. So how do we solve this conundrum? I would assert that the principles of the Agile Manifesto and the various Agile methods and techniques are all answers to this question. They show us possible ways to implement this value (and the others) without getting stuck in processes and tools.
Only humans introduce new processes and tools.
What are Processes Good For, What are Tools Good For?
Some processes are good. Some amount of process is good. How do we determine what is good? Well, it largely depends on context. Some examples:
If a close family member is living in a distant location then the advances in communication tools are extremely helpful: the telegraph, the telephone, the cell phone, email, Skype. These tools create connections where otherwise there would be little or none.
If a great deal of data is created while running a marketing campaign and needs to be stored and manipulated, then computers are amazing tools for this. Computers are much much better than human minds and manual record-keeping for this sort of work.
If you create a fantastic new soup, from scratch, for some special occasion and you want to remember how to make and even share how to make it with others, then you document the process in a recipe.
Context, Emphasis and Crisis
Context here is important. The value of Individuals and Interactions over Processes and Tools is basically a statement that given the right circumstances we can use processes and tools, but that our default approach to work and problem-solving should be to focus on individuals and their interactions. Depending on the state of your work environment this is easier or harder.
For example, a startup company founded by three long-time friends who have not yet employed anyone else is almost certainly going to solve most problems that come up through discussion amongst founders and through the development of their skills and capabilities. As a company gets larger, however, there is pressure to adopt more and more processes and tools. This pressure comes from a deep source: lack of trust. At about 12 people, you reach the limit of the number of people you can have and still have anyone do anything (this limit is referred to obliquely in “The Wisdom of Teams” by Katzenbach and Smith). After 12 people, it becomes harder to avoid role specialization and some basic forms of processes and tools. In other words, bureaucracy starts growing as the organization grows. Even at this size, however, it is still relatively easy to have a very strong emphasis on individuals and interactions. There is another important limit: somewhere around 150 to 200 people, any hope of 100% mutual trust among the members of the organization is lost. This is the point at which processes and tools “naturally” start to truly take over. (This transition can happen even in much smaller organizations if the culture does not emphasize trust-based interactions.)
In small trust-based organizations, crisis is usually addressed by the mechanisms of mutual respect, skill development, informal agreements, and strengthening the interactions between people. In a large organization with low trust, crisis is almost always addressed by the creation of new bureaucracy: sign-offs, audits, traceability, procedures, policies, processes and tools.
The true test of the an organization’s commitment to the first value of the Agile Manifesto is, therefore, how it responds to crisis. When someone makes a mistake, can we help them develop the skill and the support networks to avoid the mistake in the future? Or do we put in place even more restrictive constraints on what that person does and how they do it?
In a large organization with low trust, crisis is almost always addressed by the creation of new bureaucracy.
Beyond IT and High-Tech
For now, all that needs to be said is that this particular value of the Agile Manifesto does not in any way directly refer to software or software development. As such, it is pretty easy to see how it could be applied in many other types of work. However, there are some types of work where processes and tools really do take precedence over individuals and interactions. If we want to apply the concepts of Agile universally (or near-universally), we have to examine some of these exceptions. I will leave that for a future essay.
In the next few articles, I will continue to look in-depth at each of the values of the Agile Manifesto. If you missed the first essay in this series, please check it out here: The Agile Manifesto – Essay 1: Value and Values.
What is Agile?
In 2001, 17 people got together for a world-changing discussion about software development. They tried to find the common values and principles by which people could do better at the work of software development, which was in a terrible crisis (and still, to some extent is). They were successful in that they created a list of 4 values and 12 principles to guide people trying to find better ways of developing software: the Agile Manifesto was born.
Now, nearly 14 years later, Agile software development has become well-known (if not well-practiced) throughout the business world. In fact, the concepts of Agile software development have been extended through to many other fields as diverse as mining, church management, personal time management, and general corporate management. In the process, there has also been a growing recognition of the relationship between Agile values and principles and those of Lean thinking.
It is time to think about the concepts behind the values and principles. To acknowledge that the Agile Manifesto (for software development) can be re-stated at a much deeper level. To abstract Agile software development to Agile work in general. This is my goal over a series of essays about the Agile Manifesto.
Let’s start with an analysis of the values of the Agile Manifesto in relationship to the concept of “value”.
The Agile Manifesto Values
In the Agile Manifesto we can read the four values:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
While a few of these already are quite general, let’s dig a bit deeper by starting with the second value, “working software over comprehensive documentation”. What does this value really refer to? Why do we care about software over documentation. Why “working” vs. “comprehensive”? This is where Lean thinking can help us. The notion of “customer value-added” or just value added work is any work that changes the form, fit or function of that which you are delivering and simultaneously is work that a customer would pay for independently of all the other activities and results you may be spending time on. In this specific example of software and documentation, we can try to imagine what it would be like to say to a potential customer, “we can give you documentation for our software, but we won’t be able to give you the actual software itself… but we’d still like to be paid.” I’m sure it will be clear that it would be a very unusual customer who would agree to such a proposal. Thus, we see that the value of software development activities is in producing the software itself, and the documentation is by necessity of secondary importance.
But what if we are writing a book of fiction? Surely this is documentation! But, it is not. To make the analogy to the type of documentation mentioned in the Agile Manifesto, we would sell a book not just with the story itself, but also with in-depth instructions on how to use a book, how to read, how to interpret our feelings as we read, etc. And not just that, but we would also provide a set of notes to the publisher about exactly how we wrote the book: the time and place of each paragraph written, our original outlines, our research including much that was thrown away, all our conversations with people as we struggled to sort out various plot, character and setting elements, and possibly even all our edits that we had thrown away. This is the documentation to which, by analogy, the Agile Manifesto is referring.
Perhaps now we can look at a connection between the first value and the second value of the Manifesto: that documentation, tools and processes are all much of the same thing. They all belong to the same abstract category, namely, the means used to achieve a particular end. Of course, we all know that both the means and the ends are important, although we may not all agree on their relative importance. Nevertheless, we can probably agree on some extreme outliers that will help us come to the point I wish to make. For example, we can agree that killing someone merely to get to the front of the grocery store line and save a minute or two of time is an extreme case where the end clearly does not justify the means. Likewise, we can also agree that refusing honestly given help out of a desire for independence when it ends with the death of our children by starvation is putting means too much in the fore. Balance is required, therefore. The Agile Manifesto acknowledges this balance by its epilogue to the values, “That is, while there is value in the items on the right, we value the items on the left more.” The other two values of the Agile Manifesto which mention contract negotiation and following a plan are similarly pointing out activities of the means that are non-value added, in Lean terms.
The Agile Manifesto, is stating four values, is, quite directly, pointing to those things which in life are fundamentally of value as ends, not just as means. Individuals and interactions, working software, customer collaboration and responding to change, are all valuable. In order to abstract away from software, then, and create a more general statement of the nature of Agility, we need to explore the idea of value.
The Idea of Value
If we are in business, determining value, while possibly complicated, is not usually too obscure an effort. We look at exchanges of money to see where the “market” agrees there is value. The price of a product or service is only representative of value if someone will actually pay. Therefore, businesses look at return on investment, profit margins and the like to determine value. Similarly, in other types of markets such as the stock market, value is determined by an exchange of money. But underlying this exchange of money is a decision made by an individual human being (or several, or many) to refuse all the other potential uses of that money for the one specific use of making a particular purchase. This choice is based on all sorts of factors. In economics, we talk about these factors mostly in rational selfish terms: what sort of benefit does the purchaser get from the purchase. Factors such as risk, short-term vs. long-term, net present value, trade-offs, etc. certainly can play a role in such decisions. But in business (and in particular marketing and sales), we know that there are also lots of non-rational forces at work in deciding to spend money on a particular something. Value, therefore, has a great deal to do with how a particular person both feels and understands the current proposed “investment” opportunity.
Feeling and understanding arise from many specific factors, as discussed, but what can we say generally about feeling and understanding? They are internal states of a person’s mind (or heart, if you like). Those internal states have been the subject of much discussion in the realm of psychology, sociology, economics, and philosophy. But quite simply, those internal states are greatly determined by perception. How a person perceives a situation is the immediate general factor that determines those internal states. Of course, perception is a general term that includes sensory perception, but also the kinds of prejudices we have, the categories into which we place things conceptually, the internal language we use to describe things, and our existing emotional and mental constructs. So, fundamentally, value is perceived depending on all these perceptual factors.
The Agile Manifesto authors, therefore, had (and perhaps still have) a perception of value which places individuals and interactions, working software, customer collaboration and responding to change all in a position of more value than those other items. But this perception of value may not be in alignment with other people’s perception of value. Still, we can see already in 13 short years that there is broad, if not universal, agreement on these statements of value. Why is this? Why has Agile become so popular over a relatively sustained length of time with a trajectory that still seems to have it growing in popularity for years to come?
Agile values address a deep need in people in the software development discipline and indeed, by analogy, into much of the work world.
In my next essay on the Agile Manifesto, we will take a look in more depth at the first value of the Agile Manifesto: Individuals and Interactions over Processes and Tools.
Some links to commentary on the values of the Agile Manifesto while you wait for my next essay instalment!…
The Real Agility Program is an Enterprise Agile change program to help organizations develop high-performance teams, deliver amazing products, dramatically improve time to market and quality, and create work environments that are awesome for employees.
This article is a written summary of the Executive Briefing presentation available upon request from the Real Agility Program web site. If you obtain the executive briefing, you can follow along with the article below and use it to present Real Agility to your enterprise stakeholders.
At Berteig Consulting we have been working for 10 years to learn how to help organizations transform people, process and culture. The problem is simple to state: there is a huge amount of opportunity waste and process waste in most normal enterprise-scale organizations. If you have more than a couple hundred people in your organization, this almost certainly affects you.
We like to call this problem “the Bureaucratic Beast”. The Bureaucratic Beast is a self-serving monster that seems to grow and grow and grow. As it grows, this Beast makes it progressively more difficult for business leaders to innovate, respond to changes in the market, satisfy existing customers, and retain great employees.
Real Agility, a system to tame the Bureaucratic Beast, comes from our experience working with numerous enterprise Agile adoptions. This experience, in turn, rests on the shoulders of giants like John Kotter (“Leading Change”), Edgar Schein (“The Corporate Culture Survival Guide”), Jim Collins (“Good to Great” and “Built to Last”), Mary Poppendieck (“Lean Software Development”) Jon Katzenbach (“The Wisdom of Teams”) and Frederick Brooks (“The Mythical Man-Month”). Real Agility is designed to tame all the behaviours of the Bureaucratic Beast: inefficiency, dis-engaged staff, poor quality and slow time-to-market.
Studies have proven that Agile methods work in IT. In 2012, the Standish Group observed that 42% of Agile projects succeed vs. just 14% of projects done with traditional “Bureaucratic Beast” methods. Agile and associated techniques aren’t just for IT. There is growing use of these same techniques in non-technoogy environments such as marketing, operations, sales, education, healthcare, and even heavy industry like mining.
Real Agility Basics: Agile + Lean
Real Agility is a combination of Agile and Lean; both systems used harmoniously throughout an enterprise. Real Agility affects delivery processes by taking long-term goals and dividing them into short cycles of work that deliver valuable results rapidly while providing fast feedback on scope, quality and most importantly value. Real Agility affects management processes by finding and eliminating wasteful activities with a system view. And Real Agility affects human resources (people!) by creating “Delivery Teams” which have clear goals, are composed of multi-skilled people who self-organize, and are stable in membership over long periods of time.
There are lots of radical differences between Real Agility and traditional management (that led to the Bureaucratic Beast in the first place). Real Agility prioritizes work by value instead of critical path, encourages self-organizing instead of command-and-control management, a team focus instead of project focus, evolving requirements instead of frozen requirements, skills-based interactions instead of roles-based interaction, continuous learning instead of crisis management, and many others.
Real Agility is built on a rich Agile and Lean ecosystem of values, principles and tools. Examples include the Agile Manifesto, the “Stop the Line” practice, various retrospective techniques, methods and frameworks such as Scrum and OpenAgile, and various thinking tools compatible with the Agile – Lean ecosystem such as those developed by Edward de Bono (“Lateral Thinking”) and Genrich Altshuller (“TRIZ”).
Real Agility acknowledges that there are various approaches to Agile adoption at the enterprise level: Ad Hoc (not usually successful – Nortel tried this), Grassroots (e.g. Yahoo!), Pragmatic (SAFe and DAD fall into this category), Transformative (the best balance of speed of change and risk reduction – this is where the Real Agility Program falls), and Big-Bang (only used in situations of true desperation).
Why Choose Transformative?
One way to think about these five approaches to Agile adoption is to compare the magnitude of actual business results. This is certainly the all-important bottom line. But most businesses also consider risk (or certainty of results). Ad-Hoc approaches to Agile adoption have poor business results and a very high level of risk. Big-Bang approaches (changing a whole enterprise to Agile literally over night) often have truly stunning business results, but are also extremely high risk. Grassroots, where leaders give staff a great deal of choice about how and when to adopt Agile, is a bit better in that the risk is lower, but the business results often take quite a while to manifest themselves. Pragmatic approaches tend to be very low risk because they often accommodate the Bureaucratic Beast, but that also limits their business results to merely “good” and not great. Transformative approaches which systematically address organizational culture are just a bit riskier than Pragmatic approaches, but the business results are generally outstanding.
More specifically, Pragmatic approaches such as SAFe (Scaled Agile Framework) are popular because they are designed to fit in with existing middle management structures (where the Bureaucratic Beast is most often found). As a result, there is slow incremental change that typically has to be driven top-down from leadership. Initial results are good, but modest. And the long term? These techniques haven’t been around long enough to know, but in theory it will take a long time to get to full organizational Agility. Bottom line is that Pragmatic approaches are low risk but the results are modest.
Transformative approaches such as the Real Agility Program (there are others too) are less popular because there is significantly more disruption: the Bureaucratic Beast has to be completely tamed to serve a new master: business leadership! Transformative approaches require top-to-bottom organizational and structural change. They include a change in power relationships to allow for grassroots-driven change that is empowered by servant leaders. Transformative approaches are moderate in some ways: they are systematic and they don’t require all change to be done overnight. Nevertheless, often great business results are obtained relatively quickly. There is a moderate risk that the change won’t deliver the great results, but that moderate risk is usually worth taking.
Regardless of adoption strategy (Transformative or otherwise) there are a few critical success factors. Truthfulness is the foundation because without it, it is impossible to see the whole picture including organizational culture. And love is the strongest driver of change because cultural and behavioural change requires emotional commitment on the part of everyone.
Culture change is often challenging. There are unexpected problems. Two steps forward are often followed by one step back. Some roadblocks to culture change will be surprisingly persistent. Leaders need patience and persistence… and a systematic change program.
The Real Agility Program
The Real Agility Program has four tracks or lines of action (links take you to the Real Agility Program web site):
Structurally an enterprise using Real Agility is organized into Delivery Groups. A Delivery Group is composed of one or more Delivery Teams (up to 150 people) who work together to produce business results. Key roles include a Business leader, a People leader and a Technology leader all of whom become Real Agility Coaches and take the place of traditional functional management. As well, coordination across multiple Delivery Teams within a Delivery Group is done using an organized list of “Value Drivers” maintained by the Business leader and a supporting Business Leadership Group. Cross-team support is handled by a People and Technology Support Group co-led by the People and Technology leaders. Depending on need there may also be a number of communities of practice for Delivery Team members to help spread learning.
At an organizational or enterprise level, the Leadership Team includes top executives from business, finance, technology, HR, operations and any other critical parts of the organization. This Leadership Team communicates the importance of the changes that the Delivery Groups are going through. They lead by example using techniques from Real Agility to execute organizational changes. And, of course, they manage the accountability of the various Delivery Groups throughout the enterprise.
The results of using the Real Agility Program are usually exceptional. Typical results include:
Of course, these results depend on baseline measures and that key risk factors are properly managed by the Leadership Team.
Not every organization needs (or is ready for) the Real Agility Program. Your organization is likely a good candidate if three or more of the following problems are true for your organization:
Consider that list carefully and if you feel like you have enough of the above problems, please contact us at firstname.lastname@example.org. or read more about the Real Agility Program for Enterprise Agility on the website.
In 2005 I had the privilege to participate in the first occurrence of this fantastic technique for organizing large numbers of people into Agile teams. It happened at Capital One in Richmond Virginia and my colleague of the time, Kara Silva, led this successful experiment. The problem was that the “teams” that management had set up didn’t make much sense from an Agile perspective. They were functional teams (e.g. a team of testers). But to do Agile well, they needed cross-functional, multi-skilled teams that could work well together to deliver great results each iteration. So Kara and a few other senior people got together all the staff in the department into a big room with a big whiteboard and facilitated a 3 hour meeting to sort out who would be on which team. Everyone was involved – all the people who would be on the teams were in the room. Those teams stayed together with the same membership long after that meeting.
This “team creation event” was a fantastic success for that particular department. What made it a success?
In the Real Agility Program, the team creation event is used to launch a Delivery Group. The key people at the meeting include all the potential team members as well as the three Real Agility Coaches from the business, from technology, and from process/people. Depending on the number of people involved, the team creation event can take anywhere from two hours up to a full day. Longer is not recommended. For larger Delivery Groups, we recommend that the team creation event be held off-site.
Facilitation of the team creation event is usually done by the process/people Real Agility Coach. If you wanted to use this process with other enterprise Agile frameworks such as SAFe (Scaled Agile Framework) you would have the “equivalent” person such as SAFe’s Release Train Engineer as the facilitator.
The team creation event should only be done when the business is ready to get a Delivery Group started on actual product, project or program work. If there is any significant delay between the team creation event and the launch of the Delivery Group on it’s work, then the teams can fracture and you may need to run the event again. A few days should be the maximum delay.
One client we worked with ran the team creation event but had some significant problems afterward because they weren’t really ready. In particular, they still had to make staffing changes (primarily letting go of some contractors, hiring some new full-time employees). As a result, the teams created in the team creation event were not really properly stable. This caused a great deal of disruption and even significant morale problems for some teams. It is essential that the Leadership Team be committed to keeping the team membership stable for a significant period of time after the team creation event. That includes any necessary means to encourage people who are thinking of leaving to reconsider. It also includes a commitment from leadership to respect the self-organizing choices made during the team creation event unless there is an extremely urgent problem with the results.
So, to make it systematic, here are the steps required to run a team creation event:
TEAM CREATION EVENT AGENDA
Have you experienced an event like this? Did it work? What was different from what I described?
Although Agile methods are very popular (particularly Scrum), there are still many organizations or departments which may not yet have official support for adopting Agile methods formally. In some cases, management may even be hostile to the concepts and practices of Agile methods. If you are interested in Agile, you don’t have to give up hope (or look to switch jobs). Instead, here are some tips to start using Agile methods even in hostile environments.
Some Agilists claim that the retrospective is actually the key to being Agile. In some ways, this is also the easiest practice to introduce into an organization. Start with “easy” retrospectives like “Pluses and Deltas” or “Starfish“. These are retrospectives that can be done in 15 minutes or half an hour. Try to do them with your team weekly. If you are are a team lead or a project manager, it will be easy to include this as part of an existing weekly status meeting. If you are “just” a team member, you might have to get some modest amount of permission.
So why would it be good to do a retrospective? Because it’s a high return-on-investment activity. For a few minutes of investment, a team using retrospectives can become aware of dramatic opportunities for improvement in how they are functioning. Here are a couple more articles about the importance of retrospectives:
Although I strongly recommend starting with retrospectives, sometimes that’s not the best way to start. Myself, my first formal Agile environment, I started with the Daily Scrum. Another time less formal, I started with Test-Driven Development. In both cases, starting with a single practice, done well, led to adding additional practices over a relatively short period of months. This gradual adoption of practices led, in time, to attracting positive interest from managers and leaders. This is the practice-by-practice approach. Start with a simple Agile practice that you can do without asking anyone for permission. Make sure it is a practice that makes sense for your particular environment – it must produce some benefit! If you are technical contributor on a team, then practices such as refactoring or test-driven development can be a good place to start. If you are more business-oriented, then maybe consider user stories or one of the Innovation Games. If you are responsible for administrative aspects of the work, then consider a Kanban board or burndown charts.
It is important to get the chosen practice done consistently and done well, even when the team is struggling with some sort of crisis or another. If the practice can’t be sustained through a project crisis, then you won’t be able to build on it to add additional Agile practices.
Sometimes you get an unusual opportunity: a project that is funded but hidden from the bureaucracy. This can happen for a variety of reasons, but often it is because some executive has a pet project and says (effectively): “make it so”. This is an opportunity to do Agile. Since there is little oversight from a process perspective, and since the overall project has a strong executive sponsor, there is often a great deal of freedom on the question of “how do we actually execute.” There can be challenges as well: often the executive wants daily insight into progress, but that level of transparency is actually something that Agile methods can really support. In this case, there is no need to ask anyone on what method to use, just pick one (e.g. Scrum or OpenAgile or XP or Kanban or Crystal or…) and go for it. Don’t talk about it.
The “just do it” approach requires that you have some influence. You don’t have to be an influencer, but you need connections and you need charisma and you need courage. If you don’t have at least two of those three, you shouldn’t try this approach. You have to do things and get away with things that normally would get people fired – not because they are illegal – but simply because they are so counter-cultural to how your organization normally works. Here are a few comments on Stealth Methodology Adoption.
There’s nothing like working with a band of rebels! If you can find one or two other people to become co-conspirators in changing your organization, you can try many lines of action and see which ones work. Getting together for lunch or after work frequently is the best way to develop a common vision and to make plans. Of course, you need to actually execute some of your plans. Having people to work with is really part of the other tips here: you can have co-conspirators to help you launch a practice-by-practice Agile transformation, for example.
But, like any rebellion, you really need to trust those you work with in these early stages. Lacking that trust will slow everything you do possibly to the point of ineffectualness. Trust means that you have, for some time, a formal vow of silence. Not until you have critical mass through your mutual efforts can you reveal the plan behind your actions.
Read “Fearless Change”
I can’t recommend this one enough! Read “Fearless Change” by Mary Lynn Manns and Linda Rising. This is a “patterns” book. It is a collection of techniques that can be applied to help make organizational changes, where each technique has its own unique context of use. Lots of research and experience have gone into the creation of this book and it is a classic for anyone who wants to be an organizational change agent. Patterns include basics such as “Do Lunch” to help build trust and agreement with your ideas for change or “Champion Skeptic” to leverage the value of having systematic, open criticism of your change idea.
Don’t Call it “Agile”
This isn’t really a “tip” in the sense of an action item. Instead, this is a preventative measure… to prevent negative reactions to your proposals for change. The words “Agile” or “Scrum”, while they have their supporters, also have detractors. To avoid some of the prejudices that some people may hold, you can start by _not_ calling your effort by those names. Use another name. Or let your ideas go nameless. This can be challenging, particularly if other people start to use the words “Agile” or “Scrum”. By going nameless into the change effort, people will focus more on results and rational assessment of your ideas rather than on their emotional prejudices.
A minor variant of this is to “brand” your ideas in a way that makes them more palatable. One company that we worked with, let’s call them XYZ, called their custom Agile method “Agile @ XYZ”. Just those extra four symbols “@ XYZ” made all the difference in changing the effort from one where managers and executives would resist the change to one where they would feel connected to the change.
Get Some Training
Okay, some blatant self-promotion here: consider our Certified Real Agility Coach training program. It’s a 40-week program that takes about 12 hours/week of your time for coursework. The next cohort of participants starts in June 2015 and we are taking deposits for participants. This training is comprehensive, top-notch training for anyone wishing to become an organizational change agent focusing on Agility.
The voting for re-introducing the five values of Scrum into the Scrum Guide is heating up with some great discussion (debate?). One person, Charles Bradley is providing some interesting arguments about why “commitment” should not be included or even changed to a different word. I have posted a response. I strongly believe that the word “commitment” is the right word. Here’s the first paragraph of my response:
Hi Charles, although I appreciate your concerns about the word commitment, there is still huge support for adding the five values back to the Scrum Guide, including using that “bad” word. I would like to present to you an argument for the use of the word commitment by telling a story.
A long time ago I had a really good friend….
Check out all the discussion on the five values of Scrum and please comment or vote (or both!)
Hi Everyone. A Scrum Alliance colleague of mine mentioned that in a conversation with Jeff Sutherland (one of the authors of Scrum), Jeff suggested that the community could request and vote on a change to the Scrum Guide (the official description of Scrum) in order the add the values back to the guide. The values are normally listed as focus, commitment, courage, openness and respect. Please go and vote (and / or discuss) this on the Scrum Guides User Voice page. Voting is super easy – you just need to sign in with Facebook.
I was thinking about the concept of becoming excellent at something. My son is a budding artist. He and I had a conversation a few months ago about talent or aptitude. I said to him that I felt that aptitude is only latent: you need to put effort into something in order to expose your talent. He was concerned that he didn’t have any aptitude because he had to work so hard to become better at drawing. I compared him to myself and my brother, Alexei: when we were growing up, we both put a lot of effort into drawing. Quickly, I fell behind my brother in skill. He clearly had aptitude. But he also put in a lot of effort into exposing that talent. I was reminded of all this because my son is struggling with math. He has aptitude, but he hasn’t put much effort into it. I was wondering why?
Then I realized that aside from aptitude and effort, two more things need to be in place to achieve excellence: willingness and confirmation.
Willingness is the internal drive, usually motivated by an unconscious set of factors, but sometimes also coming from a strong conscious decision. Willingness can come from unusual combinations of circumstances. I was extremely willing to learn mathematics in my youth. This came from two experiences. One, in grade 2, was when my teacher told me that I shouldn’t be learning multiplication (my dad had taught me while on a road trip). I was upset that I shouldn’t be able to learn something. Then, in grade 3, I had a puppet called Kazir (a gift from my babysitter who told stories about space adventures with Azir and Kazir the Baha’i astronauts). I brought Kazir to school one day and while doing math problems, I pretended that Kazir was helping me. Suddenly I found math easy. These two events plus a few others contributed strongly to my desire, my willingness to learn math.
Confirmation is the set of environmental factors that helps keep us on a path of learning. These environmental factors are sometimes mimicked in the corporate world with bonuses and gamification, but these are really distant shadows of what confirmation is really about. Confirmation is when the stars align, when everything seems to go right at just the right time, when the spirit inspires and moves you and the world to be, in some way, successful. The trick about confirmation is that success is not usually about monetary success. It’s usually about social, relational or even sacrificial success. As an example, when I was in grade 7, I was chosen with a small group of people in my class to do accelerated math studies. This was a great honour for me and was a confirmation of my interest in math.
In organizational change, and in particular in changing to an Agile enterprise, we need to be aware that excellence requires that these four factors be in place. Aptitude is, to some degree, innate. We can’t trick people to have aptitude. If someone is just fundamentally bad at a certain thing, despite vigorous educational efforts, then that person likely doesn’t have the aptitude. Effort is about both having time and resources, but also, then about willingness. And willingness, in turn, can only be sustained with confirmation. Too much discouragement will break a person’s willingness. The Agile enterprise requires a great number of skills and abilities that are not normally part of a person’s work environment prior to attempting to adopt Agile. Keeping these four things in mind can help people in an organization to reach excellence in Agility.
Among the great things I learned last week in London UK at the Scaled Agile Framework (SAFe) Program Consultant training is the concept of using the Weighted Shortest Job First method of prioritization for backlog items. The concept is similar to the Relative Return On Investment (RROI) that I teach in my Certified ScrumMaster and Certified Scrum Product Owner courses, but adds a bit of sophistication both in the background theory and in the actual application.
Weighted Shortest Job First is a numerical score where the larger the score, the sooner the job (feature, product backlog item) should be done. Scores therefore give a sequence to jobs. The score is based on the ratio between two estimates: the estimate of the “cost of delay” and the estimate of the “duration to complete”. The cost of delay is a more sophisticated version of business value in that it takes into account customer needs, time criticality and risk reduction or opportunity cost.
In SAFe, the WSJF is calculated at the level of the team’s backlog on user stories through estimates of effort by the team and estimates of the cost of delay that are done by the product owner in collaboration with program management and business owners. The effort estimate is considered a reasonable proxy for the measure of duration, but there is explicit acknowledgement that this may not always be a reliable relationship.
The SAFe SPC training last week taught me quite a few interesting and useful new things. In reviewing my class materials, I noticed this little acronym: ROAM. The way it is used in the SAFe training is that it is a mechanism for categorizing risks that teams identify as they are doing release planning. ROAM stands for Resolved, Owned, Accepted, Mitigated. The members of an Agile team or Agile Release Train identify risks and collaborate to decide how to handle them. These risks are then place on a visible grid that has each of the four categories marked. In this way, the whole Agile Release Train and their various stakeholders can have an open discussion and shared understanding about the risks to the Program Increment that they are planning. Cool!
I’ve proposed a session called “Agile Manifesto and Enterprise – Rant and Rave” for the Toronto Agile Community’s conference “Toronto Agile and Software“. The session is based loosely on my earlier article “The Agile Framework: Agile Values and Principles, The Agile Toolkit, The Agile Organization“, as well as some of the things that I do in the 2nd day of my Certified Scrum Master training session. If you are thinking of coming to the conference, I would greatly appreciate your votes or feedback on my session proposal!
When I am speaking with executives, ScrumMasters and other leaders of change in organizations, I often present a simple 3-layer model to understand the relationship between the various moving parts in the Agile Framework:
All of this is summarized in this graphic:
The Agile Framework [PDF]
I sometimes also call this the “Agile Ecosystem” since it is a constantly evolving set of ideas (processes, tools, resources) that does not have a clearly defined boundary. For example, the technique of Value Stream Mapping comes from Lean manufacturing but has also be broadly adopted by Agile practitioners.
Another fantastic article by Mike Caspar: Sprint Retrospective vs. Lessons Learned (a Generalization)
Consider reviewing these differences in your environment to determine if you are getting benefit from your Sprint Retrospectives and following their intent.
You probably already use an Agile Estimation technique such as the Planning Game or the Bucket System, but surprisingly few people understand the underlying principles of Agile Estimation. This lack of understanding often causes confusion or stress for the people who try to use Agile Estimation techniques. The discrepancy between traditional estimation techniques and Agile techniques is large and it is hard to bridge that mental gap without understanding the principles involved. There are three fundamental principles of Agile estimation:
Principle One: Collaborative
Agile estimation methods are collaborative. This means that multiple people work together to arrive at estimates for work in an Agile project or product development effort. Traditional estimation techniques (such as those related to bottom-up or top-down) tend to focus on individuals estimating the work that they are responsible for doing and “trusting” those individual estimates. Collaborative estimation means that most estimation is done by people in formally facilitated meetings where people are present in-person.
Collaborative techniques are generally used where there is some expectation that multiple minds are better than a single mind in discovering some new knowledge or solving a problem. Teamwork and groupwork are based on this concept. This idea of collaboration for problem solving is also applied to Agile Estimation and it has some interesting ramifications.
The most radical consequence of collaborative estimation methods is that there is no possibility to trace a particular estimate for a particular item to a particular individual person. This lack of traceability is important to create a sense of safety on the part of participants in the estimation effort. This safety is necessary to allow participants to be fully honest about estimates even if those estimates conflict with expectations of powerful stakeholders. Another way of stating this principle is that no individual can be punished for a bad estimate.
Many Agile estimation techniques take this principle beyond just mere collaboration to the level of consensus-building techniques where everyone in a group doing estimation work must agree on the final estimate for each and every item being estimated. This strengthens the idea of safety to the point where no participant in an estimation effort can ever say “I didn’t agree with that” and thereby leave other participants “on the hook” for a bad estimate.
Principle Two: Relative Estimation
Imagine you are shown a glass bottle with some water in it. You can see the water sloshing around. Someone asks you, “how much water is in the bottle?” You might, at first, think about the overall size of the bottle and respond by saying “it’s 1/3 full.” Or, if asked to provide a measure in units like millilitres or fluid ounces, you might mentally compare what you see in front of you to some container (e.g. a measuring cup) where you know the quantity. In both cases, you are doing a relative estimate of the amount of water in the bottle. You are comparing the amount of water to a known quantity.
Imagine a counter-example: someone walks up to you with a red pen ask asks you “what is the wavelength of the light being reflected from this red ink?” If you are like most people, you have probably forgotten (if you ever knew) the wavelengths of light in the visible spectrum. You have no basis for comparison. You might take a wild guess, but it is just that. Going back to our relative measure, you might be able to easily say if it is darker or lighter than another red colour, or you might even be able to tell what hue of red it is. But those cases are, again, relying on our inherent ability to see relative differences.
So instead of ignoring this capacity, in Agile estimation techniques, we leverage it. When estimating effort, we start by setting a clear baseline for what we are comparing: another piece of work. The baseline piece of work is often given an “estimate” that is arbitrary and in some non-standard units. For example, it is common to use “points” when estimating the effort for Product Backlog Items.
When doing relative estimates it is very important to ensure we are comparing “apples to apples”. Both the piece of work to be estimated and the comparison piece should both be work items that are not yet done! If you have already completed one of the pieces of work, you have prior knowledge that you don’t have for the work to be estimated.
This last point is subtle, but important. If you have already done something, you know much more about it. If you try to compare to something you haven’t yet done, you will be tempted to assume that the two things will be more similar than they may be when you actually get to work on it. By comparing two pieces of work that you have not yet done, you become much more conscious of the risks of comparing, and that consciousness will help you make better relative estimates.
It is important to note that one side advantage of using relative units for estimation is that it makes it much more difficult to use estimates as a baseline for either measuring performance or for tracking schedule variance, both of which are essentially meaningless in a good Agile environment (which should be almost entirely results-oriented).
Principle Three: Fast
In Agile estimation we don’t care (!!!) about accuracy nor about precision of estimates. Whoa! Why is that? Because estimation is waste. You can’t sell estimates, and estimates don’t affect the “form, fit or function” of the thing you’re building. Therefore, both Agile and Lean concur: do your utmost to eliminate that waste. There are actually lots of Agile practitioners who think estimates are evil (and they have some good arguments!)
In order to do Agile estimation in a maximally non-evil way, we need to make estimation fast! Really fast!!! Many of the Agile estimation techniques allow you to estimate a product release schedule lasting as much as a year in just a few hours given a reasonably well-crafted Product Backlog.
There are really only two modestly good reasons for doing estimation in an Agile project or product:
As a business stakeholder, one can do a simple mental exercise. Ask yourself, “how much money would I be willing to spend to accomplish those two objectives?” Whatever your answer, I hope that it is a very small amount compared to what you are willing to spend on getting results. If not, perhaps you haven’t really embraced the Agile mindset yet where “the primary measure of progress is working software” (the Agile Manifesto).
Bonus Principle: We Suck at Estimating
Most people doing estimation in traditional project management try to measure in units like person-days or dollars. There is no doubt that these units are useful if you can get good estimates. However, most of the people doing estimation are fundamentally and irredeemably bad at it. How do I know? Because they are not wealthy… and have thereby proven that they cannot predict the future. If you can predict the future, even just in limited circumstances (like estimating effort or revenue), you can leverage that to generate almost untold wealth. Given that, it is fruitless and wasteful to try to get better at estimating. Instead, the principles of Agile estimation help us focus our attention on the right things: collaboration, comparative estimates and doing them fast so we can get to the real work, and most importantly: delivering valuable results now. Understanding these principles helps teams overcome many of the struggles they have in using Agile estimation techniques.