Introduction

For those who I haven’t had a chance to meet, I’m David Hawks. I founded Agile Velocity back in 2010. I do Certified Scrum Training and I am a certified Enterprise Coach–which just means that I’ve seen a lot of different environments and companies that are struggling. This talk discusses patterns that we have seen emerge at that next level of Agile which most of these companies are trying to reach.

The Current State of Agility

This slide (above) shows how most organizations might describe their current state of agility.

Many organization are at what I would call “Superficial Agility”. They are going through the motions. For example, they’re making their work visible (which is better) but there is still a lot of carryover. Maybe they don’t have a strong Product Owner or ScrumMaster, or they’re working in silos where they’re just throwing things over the wall to each other. They’re kind of doing Scrum but not being very Agile.

“Improving Agile” is an organization that is starting to have retrospectives with meaning. The ScrumMaster is trying to coach the team to be better, work is estimated, and we have some sense of velocity (that doesn’t mean it is consistent or predictable velocity). We are starting to improve but not to the level of predictability where we don’t have very much carryover.

In “Predictable Agility”, we are breaking down work, we’re swarming, and we have whole team ownership. That is a great state to be at if you can get to it. Here, we have a predictable cadence of delivery.

Finally, you are at what we call “Fast Agility”, where we are delivering quickly. We might have Devops or CI/CD, etc. We are delivering things into production, and maybe releasing one feature at a time. Our cycle time is short, and you might even be releasing faster than the sprint cadence if you are doing Scrum.

So I would like y’all to think about which one of these you fit it. Are you in Superficial Agility, Improving Agility, Predictable Agility, or Fast Agility? (See poll results from the live webinar below.)

The current state of benefits that people are striving for with Agile are:

• Increased visibility so we can make better-informed decisions.
• Continuous improvement at a team level where the teams are taking ownership of their improvement.
• Predictability–not that we know exactly what we will deliver 6 months from now, but that we know we can get about 4-5 things done every two weeks and get them done-done.
• Potentially shippable and even potentially into production so that we are shortening time to market.

These are a lot of the things that companies who come to us say they want. How would Agile make them more predictable, faster, and increase productivity? While those are great, that is what I would call Agile 1.0. What we are trying to achieve today, and what I’m here to discuss with you all today, is the next step. What is past Agile 1.0?

The Path to Agility®

Some of you have probably seen the Path to Agility® that we put together. If you are interested, we have a separate talk that goes more in-depth on this. The top level of the Path to Agility® is aligned with what we were just talking about–learning, improving agility, predictable agility, and accelerate. What we are going to talk about today is the last stage in the Path to Agility®, which is an adaptable organization, or organizational agility. So what does that really mean?

Agile Development: A History

In order to understand this, we need to understand where we came from and what has changed. Agile was born in 1995, and Scrum was presented for the first time here in Austin at OOPSLA’95. As you can see in the picture, it looked a lot different than it does today. There was the pregame, postgame, and mid-game back then. Scrum didn’t even have Sprint Planning or Sprint Retrospectives.

I remember writing code in 1995 and shipping CD’s and software off to my customer and never being able to see how it was used or if it was ever installed. We didn’t have visibility to where the software was running. In 2001 Agile is born and we now have the Agile Manifesto that was written with contributions from the Scrum community and more. That was 17 years ago that Agile was born and we’re still implementing a lot of the core tenants the same way as they were then. That helps us get to Predictable and Fast Agility, but I think that’s not enough anymore, and that is what we are exploring here today.

In 2006, we started to hear commercials talking about “The Cloud” and we’re like “What the hell is The Cloud?” I think that really changed a lot of the dynamics around what is capable today.

Now that we have our software in the Cloud, we’re able to deploy much quicker because we are deploying in an environment our company controls versus shipping CDs and/or doing major releases with on-premise software. The Cloud has also enabled the ability for us to get analytics and metrics because we have direct access to that machine, the logs, and the information/analytics of the usage. Whereas back in ‘95, when I’m shipping CD’s, I have no idea what people are clicking on or what flow they are using. The Cloud, Techstack, and things we are using today have really changed the dynamics of what is possible for us.

The other big thing that influenced development is smartphones. These have allowed our consumers to absorb software changes at a rapid pace. Before 2007, everybody was like “Nope, we’re only going to do three major releases year because we don’t want a lot of changes”. But now we’re used to Facebook updating all the time. There are always updates coming, and we’re always getting incremental changes. Our consumers, customers, or stakeholders are now used to the fact that software is just a continuous flow of things, tweaks, changes, and improvements. That has changed people–their appetite for receiving software has increased.

Next, we’ve got this whole thing called DevOps, which has now created the infrastructure that supports our ability to push software quickly, things like feature branching all the way to automated deployment with automated tests. We now have the ability to not only deploy things quickly but to monitor if we’ve broken something in production and to be alerted before our customers see it. This allows us to respond quickly and fix bugs before anyone even notices. DevOps provided that infrastructure, which was only possible because of the Cloud and SAAS and is now sustained by our consumers’ appetite for software updates.

I think these three major areas have really changed what is possible and what we are allowed to do with analytics and the visibility that we now have. When you also think about the rate of change that’s exponentially increasing, I think about it more as a rate of disruption: the ability for any company, anybody, anytime, anywhere to create a product that can disrupt your product. This is possible because the cost to get a new product built is so much smaller.

I remember a start-up that I was a part of–the first initiative that I did on my own in around 2003. Back then, in order for me to launch a new app and new site, I had to go rent a rack at a data center. I had to buy hardware and servers. I had to buy around $10,000 worth of Oracle licenses and other things just to get going. Today with AWS, I can pay 12 cents and have a server. If I have low traffic, it doesn’t  cost me very much, so my barrier to entry is much smaller.

All of this technology can be accessed from anywhere in the world, and therefore, can be deployed anywhere in the world. Competition and choice is huge, so we now have to react quicker or somebody else is going to disrupt our market and disrupt us right out of business. With the current rate is disruption, we have to start reacting quickly or we risk being left behind.

That dynamic is what got us to this point: a state where Next Level Agility is imperative. We’ve got the infrastructure and the mindset that allow us to do Next Level Agile in a way that we didn’t have before. I’m not saying the Manifesto was wrong in 2001 but maybe it’s a little bit outdated now in terms of capabilities.

Next Level Agile

Benefits of Next Level Agility

When I think about what benefits we are really striving for with Next Level Agility, I ask myself questions like “Are we validating or invalidating our ideas as fast as possible?” and “How do we know we’re building the right thing?”

We’ve all heard the stat that 64% of the features we build are rarely or never used. We have a problem of building a lot of the wrong stuff. That takes time! If we could start honing in on building the right thing then we’re going to be able to address the market needs much faster.

How can we validate our ideas and assumptions? Or, more importantly, invalidate those assumptions as fast as possible? How do we get faster time to value so that the things we’re building are actually proven valuable things? I would assert that the finish line is no longer just “code in production”. I think now the finish line is that the code is in production and we have validated that it has solved the market problem.

That’s a very different way of thinking about it, because today, in Agile 1.0, we’re thinking about being fast. Now with Next Level Agile, I’m saying that being in production is not good enough. We have to prove that the product or code is solving the problem we validated production. I think team agility is great in Agile 1.0. However, in today’s world, we need more. We need organizational agility–agility that extends beyond the technological organization and throughout the organization as a whole.

Organizational agility is about how marketing can work in an agile way that is responsive and incremental and iterative. Or how HR can operate with agility. If the technology teams are Agile, but the rest of the organization is working within a waterfall plan driven mindset, there is going to be a lot of tension and friction. We’re still executing on a plan that has a lot of bad assumptions in it.

Organizational agility is about starting to change the mindset of the whole. We need a learning culture more than an execution culture. This allows us to have a faster response to change. We have the ability to be probing, sensing, and putting things into the market and getting validation back. If we want to be successful today, we need to be able to respond to those market changes and respond to disruption much faster, not just respond fast to delivering on a plan. That’s what a lot of Agile 1.0 Is doing, responding to a plan instead of market needs.

[Here, David asks the audience to write a Next Level Manifesto statement that embodies these benefits. What is a practice are we doing today that you think might not be the best practices? What would be the better practice? Follow this format: ______ over ________.]

Values of Next Level Agility

Here are the four values that I came up with:

Continuous delivery over incremental development

• In Agile, we talk a lot about working iteratively and incrementally and getting pieces done. We get a piece done, then move into the next sprint to complete the next piece. At this point, the entire product could still end up taking 12 weeks to push out the door. How do we actually start getting continuous delivery of value into production instead of just continuous integration?

Discovery over Execution

• I think about the learning part of it as discovery over execution–discovering more about the problem space and solution space. Emphasize the learning element over executing on a plan or executing on bad or unvalidated requirements.

Validated Market Feedback over Quick Stakeholder Feedback

• Who are we getting feedback from? Sometimes, we convince ourselves we’re on the right track because stakeholders are saying everything looks good, but they are not actually people that use the product, nor do they have customer perspective due to innate bias.

Business Agility over Team Level Agility

• Too often, I go into an organization and the leadership sees Agile as what the teams do and that they just need to help the teams be more agile, as opposed to thinking about this as an organizational or business problem.

Why Aren’t We There Yet?

What impedes an organization’s ability to achieve these higher levels of Agility? What is going on in your organization that’s keeping you from having potentially continuous delivery, a discovery kind of mindset, validated market feedback, or getting from team level to organizational Agility? [See poll results to these questions below.]

Here are some of the top impediments that I see:

Mindset Change from Execute on Assumptions to Learn Faster

• This is a complex situation. We do not have perfect information, and we need to have more of a learning/discovery mindset. That mindset change has to happen at the top of the organization down to the bottom. It cannot go from the team level up.

Whole Organization/ Leadership Transformation

• Leadership needs to be part of the transformation. It can’t just be technology or a couple marketing and HR pockets doing some Agile stuff. The whole organization or leadership has to go through that transformation alongside their teams.

Supporting Tech. Infrastructure (Test Automation, CI/CD, DevOps) in place

• Do we have test automation? Developers who are engaged in writing test automation? Devops? Are we investing in continuous delivery? Sometimes that requires some architecture of our product to be designed for testability and to be designed in a way that we can deploy modularly.

Analytics Combined with Experiment Platform

• Do we have analytics and the experiment platform to be running lots of A/B tests and things where we have a sample size? While Facebook may release every 12 seconds or something like that, they don’t release to everybody at once. When they have a change, they may release it to 5% of the market. Then, if everything goes well, they might expand that to 25%, then 50%, then 100% of their users.

Leveling Up: How To Reach That Next Step In Agility

Now let’s dig into the 6 practices that we could actually implement in order to make Next Level Agility happen.

1.Who are we serving?

I’ve seen a lot of companies shorten the feedback loop to stakeholders. We are doing sprint reviews with a bunch of stakeholders but no actual customers or users. So that means we are getting feedback from a middleman who is trying to represent the customers, but they’re making a bunch of assumptions and guesses that are bias to the features they wanted and how they thought it should be built. We don’t get feedback from the customer until they are actually using it and validating it. So we have to figure out how to shorten the feedback loop all the way to the market and customers in small incremental steps.

2. Hypothesis vs Requirements

Most people use user stories as a way of capturing requirements. While they are good at capturing certain things like the users intent, what impact we are trying to make for the user, how do we organize them in epics, features, and other things? User stories miss key elements like business objective. So if we had a story that said, “As a frequent flyer, I want to rebook past trips I take.” we’re missing the reason for building, the objective, the business goal.

I would much rather walk into a room with a team and tell them the objective and let them brainstorm on ways that we could solve that. Now the team is engaged trying to solve the right problem, we can make a hypothesis or in other words, our requirements. Then the experiment is the smallest thing that we can go build that would prove or disprove our hypothesis. On the left, we are thinking about discovery and learning (Next Level Agile), while on the right we are still thinking about execution and getting predictable (Agile 1.0).

3. Objective Decision Making vs Subjective Prioritization

Minimal Viable Product Experiment starts changing our thinking from a subjective decision to objective decision making.

For my triathlons, I use an App called RunKeeper to keep track of my run. One day a camera icon showed up. I clicked on it because I was curious. A window popped up that said, “Would you like to take pictures on your run?”. They hadn’t figured out the API or figured out how to take pictures yet. All they did was add the icon and question.

Their hypothesis was: We think people might want to take pictures on their run. So they added an icon and asked a question which was the smallest thing they could implement. It was an objective decision based on data and analytics that they used to help them find out what they should build next, also known as a data-driven decision.

4. Goal Driven Investment vs Budget/ Plan Driven

Imagine an initiative is funded with X money for X number of years. With budgets, we create a plan to spend the entire budget. My challenge would be for organizations to get out of that accounting process and to more of a finance process. If I’m talking to my CFO, the top part is talking his language whereas the bottom part is talking the language of the account. Goal driven investment would be saying, “I’m not going to give you $3M, but instead, I am going to give you $100,000 a month. However, in order for you to get the money for next month, you’ve got to come back in 30 days and convince me that we should still fund this”.

In terms of behavior, this is going to change the dynamic of what we’re going to do instead of just trying to execute on the plan in the budget. We’re going to start thinking about how do we have objective discussions every 30 days about what we’re learning and it might even encourage teams to go two months in and recommend that we don’t continue to invest in this because it isn’t working. The team is now engaged and taking ownership.

5. Release Continuously vs Integrate Continuously

With DevOps, we have to get to the notion of releasing quickly. If we are not releasing quickly, we are not going to be able to get something into production and learn quickly. We can’t just focus on continuous integration, we need to get all the way to continuous delivery. That is going to allow us the ability to respond and learn quickly. It is not just that we are moving fast, but that we are responding fast.

6. Measure Value vs Velocity

What are we measuring? Are we measuring in points? How many points were getting done? I hear too many people talking about how we need to get credit for all the work we did. That is an output mentality, and we want an outcome mentality for our teams and organization. It is not about how much code we get done, but how much of the right code we get done.

I like how Hendrick Neiberg puts in his video “It is about getting the most outcome with the least amount of output.” When I think about measuring value, I am not thinking about value in terms of dollars. Measuring value goes all the way back to the objective. Are we making an impact from an outcome perspective? While velocity is still a metric we should capture, it’s not necessarily the metric we should be focused on.

Connecting Our Values To Our Practices

On the left, we have a summary of those values and on the right, we have the six practices that I just walked through that correlate with those values.

[Here, we asked our audience: “Which of the practices on the right do you think is the most important?. See poll results below.]

 

Presentation Conclusion

Getting predictable and getting faster is what enables us to have this next level of Agility and be adaptable. We can respond to our market if we can push things into production quickly, and we can only push things into production quickly if we are able to have a predictable cadence of delivery. We can only do that if we have created a foundational culture of team ownership and team improvement.

Q&A

1.How do you emphasize discovery over execution while also adapting to change instead of just executing to a plan?

I think adapting to change is part of discovery but I do think that discovery and execution can compete with each other. As a startup, there is no execution because we are in discovery, we don’t know very much in that organization. At the other end of the spectrum, with maintenance work that is pretty well known there is a low risk that we’ve gotten it wrong. We understand it and just need to execute on it. I think most teams are more on the second spectrum but should be pushing somewhere in the middle.

As an industry, I don’t think we have all the answers on the best way to manage all of that work. One end of the spectrum is velocity, plan-driven, and predictable but in the discovery world, we don’t have that same level of predictability. We don’t have a plan that is fully laid out so we are iterating towards the target. We know we are done when we have achieved some of the objectives or have proved the hypothesis wrong. Distinguish the difference between that work and make that clear. You may have a team that is more discovery focused and a team that is more execution focused and that could be an interesting thing. There will also be teams where that is mixed. Here, the priorities should become tied to key objectives so that we can figure out how much time to allocate towards each side of the spectrum.

2. You mentioned having customers as a part of sprint reviews. How do you think a UX team who uses Scrum plays into that?

UX is really critical in this new world and can be one of the main conduits in trying to bridge the gap between the customers and the team. In Agile 1.0, I would say that I’ve always seen UX as being a representative of the team but working ahead of them, making sure the team has what they need. But in this world, they may be the person who is really helping drive production and partnering with product on the objective, the hypothesis, and the experiments that could be run. Sometimes that is classic techniques in UX, like paper prototyping and user testing.

At the same rate, I too often see folks go way too far to the right, being very analytical and research driven. I believe that the more analysis and research we do, the more we convince ourselves we are right without true validation of the market. We definitely want UX in this new world to start thinking more iteratively and incrementally and not fall into the trap of perfection. We’ve got to work in an iterative, collaborative way with the team. The team of product experts, UX experts, and technical experts together, taking through objectives and defining hypotheses and experiments. Everybody’s got their specialty they are bringing to the table but we are all working together to iterate towards the end goal.

3. What are your top three agile metrics that you would report to leadership?

It depends on your context. The metrics I would report would be less about output and velocity. If you are improving and trying to get predictable, then I would look at metrics like velocity, amounts of carryover, and predictability.

At this stage, what I would be reporting are business metrics and customer metrics. The metrics should be tied into the objective. An objective and various key results that drive towards your KPI’s. The other metrics are more internal for the team: velocity, what’s happening, owning our improvement. However, we ultimately have to think about the business outcomes.

4. If Agile 1.0 seems to be working for some of us, how will Next Level Agile become more necessary than traditional Agile?

I would say Agile 1.0 is sufficient, but not great for many companies. I think most companies and CEOs that I talk to are really challenged right now to keep up with the changing dynamics of their market and culture. The rate of the number of Fortune 500 companies that are going out of business is exponentially increasing, whereas 30 years ago if you were the Fortune 500, you expect to be in it for decades.

While Agile 1.0 might feel sufficient, it is not. That is my challenge for you today. Think about how your market is changing, and the ways in which you’ll need to adapt. If you get comfortable, you are going to get your ass kicked soon by someone else in your market. If you are not creating organizational agility, your company is going to be struggling in the next 4-5 years.

Do You Need Help Reaching the Next Level?

If you have questions or feel stuck somewhere along this Path to Agility®, we’d love to talk to you, your organization, or your leadership team about how to help you accelerate through your Agile journey. Visit our service pages or contact us at info@agilevelocity.com for more information.