Pair Programming Economics by Olaf Lewitz describes three activities in programming: typing, problem-solving and reading code. How does pair programming help? By making the balance between those three activities better.
Pair Programming Economics by Olaf Lewitz describes three activities in programming: typing, problem-solving and reading code. How does pair programming help? By making the balance between those three activities better.
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!…
Thanks everyone for feedback, comments and suggestions for my new book, Agile Advice – Creating High Performance Teams In Business Organizations. It is available for purchase (only $2.99) on lulu.com (that’s where the link goes). Here is the blurb about the book:
Agile Advice is a collection of brief articles and longer essays about Agile methods and their principles and practices. Agile Advice articles come primarily from the popular AgileAdvice.com blog which has been in the top 50 of Agile blogs since its inception in 2005. The book has three never-before-seen essays including “Agile Mining at a Large Canadian Oil Sands Company”, “Crossing the Knowing-Doing Gap”, and “Becoming a Professional Software Developer”. Agile Advice also has a whole section on choosing an Agile method. The author, Mishkin Berteig, has been working with Agile methods such as Scrum, Kanban, and Extreme Programming since 1996.
Once you have read it, I would love to hear your feedback and reviews here. I will try to publish updates quarterly over the next year to make it even better! Thanks again for your support.
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.
Agile Advice was started in 2005. In ten years, we have published over 850 articles (an average of just about 2 per week!). Here are some collections of the ten “best” articles. I hope you enjoy looking back at (or discovering for the first time!) some of the things that have made this such a great joy for me.
Ten Most Popular Agile Advice Articles
Ten Most Commented Upon Agile Advice Articles
I also want to acknowledge that there are a number of other contributors to Agile Advice besides me (Mishkin). These contributors are all experts, all have great experiences, and all are fantastic people to know. I’m grateful for their contributions since they have all made Agile Advice a better place to browse!
Five Most Frequent Contributors (of Articles, besides Mishkin)
Plans for the Future – Five Top Ideas for Series
Often in my classes, I’m asked for a clear comparison between the various traditional roles and the new roles in Scrum. Here is a high level summary of some of the key responsibilities and activities that help highlight some important differences between these four roles:
|ScrumMaster||Product Owner||Project Manager||Team Lead|
|NO||Define Business Requirements||PARTICIPATES||NO|
|NO||YES (Deliveries)||Define Milestones||NO|
|YES (process and people)||YES (business)||Risk Management||PARTICIPATES|
|Organizational Change Agent||NO||NO||NO|
|NO||Accountable for Business Results||RARELY (just costs)||NO|
Of course, there are many other ways we could compare these four roles. What would you like me to add to this list? Add a comment with a question or a suggestion and I will update the table appropriately!
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?
Agile methods and the culture behind them focus on teamwork, safe environments, motivation, technical excellence and lots of other things that are easy when business is good. But when business is bad, and you simply can’t afford to keep everyone around, what do you do?
… UPDATE …
Interesting: this tiny post has generated a lot of traffic… but no responses. Please feel free to offer suggestions or ideas or questions in the comments.
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.
Leaders of Agile Transformations for the Enterprise need to have good sources of information, concepts and techniques that will guide and assist them. This short list of twelve books (yes, books) is what I consider critical reading for any executive, leader or enterprise change agent. Of course, there are many books that might also belong on this list, so if you have suggestions, please make them in the comments.
I want to be clear about the focus of this list: it is for leaders that need to do a deep and complete change of culture throughout their entire organization. It is not a list for people who want to do Agile pilot projects and maybe eventually lots of people will use Agile. It is about urgency and need, and about a recognition that Agile is better than not-Agile. If you aren’t in that situation, this is not the book list for you.
These books all help you to understand and work with the deeper aspects of corporate behaviour which are rooted in culture. Becoming aware of culture and learning to work with it is probably the most difficult part of any deep transformation in an organization.
This set of books gets a bit more specific: it is the “how” of managing and leading in high-change environments. These books all touch on culture in various ways, and build on the ideas in the books about culture. For leaders of an organization, there are dozens of critical, specific, management concepts that often challenge deeply held beliefs and behaviours about the role of management.
Agile at Scale
These books discuss how to get large numbers of people working together effectively. They also start to get a bit technical and definitely assume that you are working in technology or IT. However, they are focused on management, organization and process rather than the technical details of software development. I highly recommend these books even if you have a non-technical background. There will be parts where it may be a bit more difficult to follow along with some examples, but the core concepts will be easily translated into almost any type of work that requires problem-solving and creativity.
These books (including some free online books) are related to some of the key supporting ideas that are part of any good enterprise Agile transformation.
The Scrum Guide – Ken Schwaber, Jeff Sutherland, et. al.
The OpenAgile Primer – Mishkin Berteig, et. al.
Priming Kanban – Jesper Boeg
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.
We have already written about how Leadership and Delivery Teams operate in a Real Agility Program. It’s time to look at our Recommendations component: getting started on the right path for Real Agility.
Recommendations = Assessment + Playbook
In the assessment portion of the Recommendations component, we gather information about the current situation at an organization. This includes everything from detailed practices, processes and tools, to strategies and organizational culture. This assessment work is designed to help everyone understand the organization’s current gaps, and what strengths it has that will best support it to cross those gaps to Real Agility. The Assessment includes an online portion, an on-site portion and an off-site portion. The assessment work naturally leads to the development of the playbook.
The online assessment requires that each person throughout an organization complete an online survey about corporate culture. It includes three major sections: existing challenges, sense of urgency, and level of teamwork. This cultural survey is the foundation of understanding how to be successful with Real Agility. Managers and leaders are also asked to complete an additional questionnaire about the current environment at the organization. This includes high-level information about the structure of the organization, client and vendor relationships, and staff. Additional surveys may also be administered to understand other aspects of the organization. For example, in an organization that is struggling to use Scrum, we will often use the Scrum Team Assessment.
The onsite portion of the assessment combines in-person interviews and workshops with staff and managers. Interviews explore aspects of the corporate work environment in more depth and include questions about familiarity with Agile methods, and obstacles that people might see to adopting Agile. The workshops gather data around current challenges and strengths, success criteria for projects, situational analysis for teams, and existing metrics (or lack thereof). Typically we need a meeting room committed to our consultants for doing interviews.
The offsite portion of the assessment is used for us to evaluate and analyze the survey, interview and workshop results. We also use some time to review any relevant documentation such as process templates, org charts, governance requirements, etc. We may also use some of this time for follow-up phone calls or emails to clarify aspects of the assessment results. Finally, this offsite work is also where we do the bulk of the development of the recommendations in the playbook.
Several aspects of our assessment are based on the OpenAgile Catalyst Assessment Tools which are open-source and can be found online. We also have a number of proprietary tools.
The playbook maps out a path to a successful Real Agility transformation. It is a road map that helps leaders, managers and team members make good business decisions as they strive for Real Agility. The playbook aids the organization to effectively and appropriately launch Real Agility teams: management teams, project teams, and operational teams. The Real Agility Program playbook includes analysis of the assessment results, recommendations for work that the organization can do on its own and suggests outside assistance that enhances Real Agility results. Two critical questions that are answered in the Playbook include:
We deliver the recommendations in the form of the playbook and an executive summary slide deck in an iterative and incremental fashion so that stakeholders can give us early feedback and so that we can adapt our assessment agenda as we go along. The recommendations include ideas about organizational structure, staffing, governance changes, departmental relationships, tooling, and many other aspects of how an enterprise can best become and Agile enterprise.
Following the Recommendations in the Real Agility Program playbook results in huge time-to-market improvements, 200% (or better) productivity boost for delivery teams, and extremely satisfied customers and staff.
I am currently working with a relatively new Scrum team (5 Sprints/weeks young) that needs to rewrite their Personal Development Plans (PDPs) in order to better support Scrum and the team. PDPs are still the deliverables of individuals required by the organization and likely will be for some time. The organization is still in the early days of Agile adoption (pilots) and they are large. So, instead of giving them a sermon on why metrics for managed individuals are bad, I am going to help them take the step towards Agility that they are ready to take.
I’ll follow up with another post to let everyone know how it goes.