Before getting started on any discussion of agile transition, its important to provide a description of what the authors mean by this thing called Agile. I've encountered many people that want a standard agile description, the reality is that there is no such thing, and very little value in creating one. That being said there a common characteristics, and there are common patterns, enough that we can define examples that we can aspire to, without falling into the trap of locking ourselves down into standards.
In this chapter I will present a number of examples that show what Agile can look like at. Ill differentiate these examples based on how far an organization has moved along the journey. The intent will be to give you some tools to start thinking about what Agile will look like for you.
Mindset vs Practice
Any discussion about Agile is incomplete unless we talk about Agile Mindset and Agile Practice . Lets start by bringing up the debate of mindset vs practice.
Most agile practitioners will tell you that mindset matter way more than practice, and they would be right. A focus on solely on practice results in people following rituals in a thoughtless, almost careless fashion. Nothing really changes as Agile techniques are subverted to traditional thinking. We see teams using story points to estimate requirements documents. We have 4 requirements sprints followed by 6 development sprints, followed by 8 testing sprints. We see managers forbidding the team from moving tickets on their agile board without getting explicit permission each time. We see command control driving team velocity.
Conversely I have seen really smart people declare that practice doesn't matter, its all about the mindset! I then watch these same smart people turn there nose at all the amazing agile advice and learning that has been created over the last several decades. We don't need to visual our flow, we have an agile mindset! We don't need to take the time to reflect and improve, we have an agile mindset! We don't need any kind of shared feedback loop, we have the agile mindset! How about we visualize our work? Nope we don't need any of that, our mindset will keep us humming along.
Blarghhhhh...
The reality is that people with an agile mindset will thoughtfully, gravitate to using methods and practices that increase learning, eliminate hand-offs, reduce toil, maximize self organization, and all of the other things that could increase the awesome in the work they do. A change in mindset means a change in behavior, and vice versa, and one doesn't necessarily come before the other. You are what you do. At Agile By Design, we think mindset is observed through behavior. When I take part in a discussion about an organization's Agile journey,
There are dragons in this approach, the behaviors you think are important may not be the ones that matter to your organization's context. Behaviors also come in many forms, observers are often blind to an approach they are nit familiar with. You also want to pay more attention to what is preventing those behaviors from occurring, and avoid judging people or teams based on any type of behavioral assessment. I've made both mistakes, people got angry at me. There also observations you can make on your system of work, which can often give you a much more unbiased view as to the true agility of your organization, I'll talk about those in the section on Operating with Agility at Scale
Observing Mindset through Practice
There are some really good methods out there that serve as a really good ways to get started on practicing behaviors that demonstrate an Agile mindset. Any organization serious about improved agility needs to take the time discuss these methods, and then choose some to try. There are a lot of options, and it takes a real appetite to learn them all. Start with a few, get some experience, and then expand the choices. Don't forget to ground your choices on the mindset you are trying to demonstrate. As the organization gets more used to being Agile, it will become apparent that all Agile methods and practices are variations on the same theme, and learning them becomes a lot easier.
On the other hand I find that complete, prescriptive methodologies to be a pretty toxic placebo. Methodologies are a complex, interlocking set of methods, practices, processes, roles descriptions, etc . Methodologies provide a whole description of how everyone can work together in an effective, accelerated, and safe way. Methodologies, even the methodologies that are made up of really good methods, are wrong, typically very wrong. People that write these methodologies make a whole bunch of assumptions about how your organization will work. Those assumptions are false. They are base on the experience of people that have likely have never worked in your context, and are certainly not working in your context now. Adopting a methodology that has already been written for you might seem like the faster way to adopt something new. But it is a faster road to nowhere. If your organization lacks the capability to choose how they want to demonstrate an agile mindset, than they will have very little ability to act with an agile mindset.
So, start with mindset, agree on the behavior, and try some excellent practices. This is a longer conversation than rolling out a methodology, but your entire organization will benefit.
About this Section
The content of this section will discuss mindset, observable behavior, and supporting practices.
We have made an attempt to show case how mindset and behavior can evolve as an organization moves along it's Agile Journey. We have observed organizations exhibit different characteristics depending on the progress they have made. Our team has categorized these attributes into different states, or agile archetypes if you will.
While we have presented these agile arch-types in a road-map type view, it would be a gross oversimplification to think that organizational change occurs in a linear fashion. Organizations will exhibit different aspects of multiple arch-types at the same time. They will display vastly different levels of agility based on where you look in the organization, and move backwards along the journey just as often as they go forward, often doing both at the same time.
The hope is content here will serve as a good source of discussion around where you are as an organization, and describe where you want your organization to be.
This is not to meant to be a definitive list. As you explore your agile change in your context, please alter, edit, or even throw out what you see here. Definitely add to it, than add to it some more. It is up to you to come up with your own description of what it means to be agile. Co-create it with other change agents who express the desire to do so.
That being said I really like this list, it is how I start the Agile Conversation. It avoids methodologies, and focuses on behavior, it has lots of amazing things you can try. Trying out the methods ill include in this section changed my behavior, and how I understand the world has changed as a result.
Supporting Documents
Agile @ Scale Through Mindset and Practice tries to describe the shift in mindset required across the organization. It contains a brief (very brief) overview on how we as leaders need to shift
- the way we Deliver Value
- the way we Organize our People
- the way we Fund our Efforts
- the way we Decide and Guide
Agile Mindset and Behavior "a" list of higher level behaviors that are a good description of representative of being agile. These are broken into discrete mindset statements, made concrete by observable behavior and mapped to agile practices.
For Example:
We believe the team trump role, department, or function
Leaders help organize people so that work so that it is delivered end to end by cross functional teams.
Team Members pinch hit to deliver value outside of their core job function, place in the hierarchy, or position in the organization.
Everything is categorized according to progress in the agile journey, there is an initial attempt to refine each state in the agile journey. The goal, the obstacles, and the counter measures. Definitely WIP. The states currently listed are:
- Initiate
- Foundational
- Accelerate
- Dominate (not competitive at all here lol)
Here is a blog post on the topic, it's written in a way that is a little to certain and prescriptive to my taste, that will change in the book.
A lot of the practices that map to the behaviors above are described here in an integrated way. It might come off as a prescribed methodology, apologies for that. It's not, take each piece on it's own, or some of it together. It is a good description of some foundational practices that will bring sanity to your delivery. These practices get people collaborating, and provide good feedback.
The Foundational methods / practices include training on
- Kanban
- Story Mapping / Story Grooming
- Spec By Example
- Opportunity Model Generation (like Business Model Generation, but for a single Opportunity/Idea)
- Impact Mapping
- Cost of Delay
- Scrum
