The Agile Manifesto was written in February, 2001 by a group of forward-thinkers that saw clearly that “the way we’ve always done it” simply wasn’t going to work anymore.

The days where one person knew the entire product from top to bottom, when entire products where built on a single platform and architecture, when customers pretty much accepted what the “DP Department” told them could be done had ended. By 2001, product quality was suffering horribly. At the same time, development costs were skyrocketing and developers were complaining constantly about “checking the boxes” (a reference to doing more unnecessary paperwork than actual product development). The Agile Manifesto hoped to change all this.

No change is easy. Cultures, like people, acquire habits that are not only difficult to change, also begin to seem less like decision we’ve made than actions that we have to do in order to get it right. Moving from a plan-focused approach (like waterfall) to a value-focused approach (like Agile) can be extraordinarily difficult.

The most important step in transforming an organization to a mindset more in tune with Agility is to understand the concept of “being” Agile. I’ve worked with many companies in the last twenty years, and one of the most common problems I run into is that people want “to do Agile” as if it were a series of practices that, once in place, will make everything better. Unfortunately, this just isn’t the case. What I want to accomplish with this writing, is to give you the keys you’ll need to take to start your journey “to BE Agile.”

Keys to BE Agile

1: Understand that Agile is a MINDSET, not a METHODOLOGY.

You can’t DO Agile. There’s no process you can put in place. You CAN use Scrum, Kanban, XP, FDD, Prince, DSDM — these are all frameworks that honor the principles of Agile Software Development and will therefore support your effort to be more Agile.

2: Scrum, Kanban, XP, FDD, Prince, & DSDM Won’t Complete Your Journey to Agility.

No existing framework will complete your organizational journey to Agility. They will instill the behaviors you need, but it is up to the leadership of the organization to exemplify what it means to be Agile and teach, coach, and support agility amongst the organization’s employees.

3: Your Journey to Agility Won’t Be a Short One.

It’s always interesting to see an organization try to complete their transformation on a schedule. My favorite is the strategic goal: “35% of all development teams using Scrum by June 30, 2017.” By itself, there’s nothing wrong with planning a rollout of Scrum to a certain number of teams by a certain date. But that’s often where it ends. Eighteen months later, 100% of teams are using Scrum and “WE ARE AGILE!” No, you’re not. Agility is a MINDSET change. Think of it like going on a diet or quitting smoking. Neither is easy to do. When we set goals like: “I’m going to cut 400 calories a day by the end of the month” or “I’m cutting down to one pack a day by the end of the month,” we often find ourselves two months later back where we started. Just like losing weight involves behavior modification, so does becoming an agile organization. Start including goals like “Learn how to successfully modify behaviors” in your journey. Expect to make mistakes. Expect it to take a while. The good news is that, if you take on some good habits right away (and keep reinforcing them), you’ll see some nearly immediate benefits.

4: It’s ALL About the Team.

Take six people, put them in a room and tell them to work together and you’ve got yourself a team, right? NO. We seem to have forgotten the difference between GROUPS and TEAMS. Teams have clear goals they work toward. They look at work as something they do together, not something that they have in common. Groups tend to be task-focused (everyone grabs their tasks and disappears), while teams tend to be delivery-focused (everyone gangs up on the work and gets it done). The heart of Agility is the team. Telling a group of people that they are a team or, worse, not even bothering to communicate that concept and simply telling them how to do Scrum or Kanban won’t create a team. When you bring people together (remember, team size should be limited to 9 developers and they need to collectively have the skills necessary to get the job done), take a little time to encourage the development of a team. Do they want to create a team name? What are the team’s ground rules? How do they plan to work together to get things done? How will they make decisions and break deadlocks? If you want to learn more about the team, check out this blog post.

5: Stay Focused on Value.

As with any other business decision, building products is about building value. There are lots of really cool ideas out there, but only a subset of them actually create the value that is needed by the business to sustain growth or the value that is needed by the customer to encourage purchasing and using your product. Scrum, in particular, is built to focus team effort on value-generating activities (those that generate a greater return on investment – ROI). It is tempting to build features that improve the use of technology or provide a 1% performance boost or improve the extensibility of the product — but you must always temper the siren of technological relevance with the voice of the customer. A super cool product that doesn’t sell is just waste. Keep your customers involved in the development effort. Let them see what you’re working on. Get their feedback on a regular basis.

6: Experiment and Fail!

One of the most important behavioral modifications you can create in an organization is the willingness to try stuff — experiment. Innovation comes from experimentation and the best innovation comes AFTER several failures. Coca-Cola’s CEO said: “If we’re not making mistakes,” he insisted, “we’re not trying hard enough.” Amazon’s CEO said: “If you’re going to take bold bets, they’re going to be experiments. If they’re experiments, you don’t know ahead of time if they’re going to work. Experiments are by their very nature prone to failure. But a few big successes compensate for dozens and dozens of things that didn’t work.” Experimentation is NOT a waste of time and your teams should be involved in experiments on a regular basis.

7: Less Managing, More Coaching.

Traditional management activities have their foundation in the 19th century creation of industrialization and factories. Workers then were primarily unskilled (many uneducated). Management was fundamentally necessary to show employees how to do the job and to deal with problems and escalations throughout the day. Today, workers are highly skilled individuals that, while they have a lot to learn when they step into a new job, actually need a lot more coaching than they do managing. In an Agile organization, management should be limited, at most, to strategic work, while coaching should take up all of the rest of the slack. For example, it is FAR more effective to coach a team to fix a problem they caused than to manage a team to identify who caused the problem and to explain your solution.

8: Less Asking for Permission, More Asking for Advice.

One of the most effective ways for a Scrum team to become more self-organizing over time is to give them total accountability for the product (or portion of the product) they are supposed to be responsible for. This can become difficult for managers who are historically held accountable (instead of the team). More accountability can be shifted to the team by putting in place a culture of asking for advice from anyone that might be affected by the decisions that they are making. Teams should ask for advice from management, yes, but what about the people in the support (call) center? What about other teams that have had to make similar decisions? What about other teams that might have to use what we build? More communication, more looking for advice goes a long way toward making teams more accountable for what they decide to do.

Being Agile

While incorporating Scrum, XP, or Kanban practices in your organization can result in some real improvements, being Agile is far more about understanding the mindset of Agility than the practices that we adopt. If you remember the keys I’ve described above and keep reminding everyone else as you plan and execute your implementation of Agile Development, you’ll save yourself a lot of unnecessary problems.

Artisan’s CSM and CSPO training can provide an excellent start for a new ScrumMaster or Product Owner looking for direction on what it means to do the job. If you’re really into being a good ScrumMaster and want to take the next step, try Artisan’s Advanced Certified Scrum Master training. Click here to learn about all of these classes.