Skip to content

Leading Agile
Syndicate content LeadingAgile
Agile Training | Agile Coaching | Agile Transformation
Updated: 1 hour 52 min ago

Agile Metrics: A GQM Approach

Wed, 05/24/2017 - 21:22

When undertaking an Agile transformation, there is a need to collect data to demonstrate progress and show improvement, but where does one even start? Common Agile metrics approaches do well at measuring team velocity and throughput but can sometimes overlook the requirements of executive sponsors, product management, and other key stakeholders. This problem is often rooted in a lack of understanding about what business goals are driving decision making throughout the organization and what questions we should be answering with the metrics we collect.

The “Goal-Question-Metric” (GQM) approach is a proven method for driving goal-oriented measures throughout a software organization. With GQM, we start by defining the goals we are trying to achieve, then clarifying the questions we are trying to answer with the data we collect. By mapping business outcomes and goals to data-driven metrics, we can form a holistic picture of the Agile environment and clearly articulate how we are doing across the span of the enterprise.

The GQM Approach to Agile Metrics: John Tanner #AgileDayATL

— LeadingAgile (@leadingagile) May 19, 2017

During this session, we will explore the GQM approach and show its effectiveness in identifying the key information your enterprise needs to know at the Executive, Portfolio, Program, and Delivery tiers. We will provide example metric sets for each tier and explain the goals and questions that drove us to them. At the end of this talk, the audience will understand, not only how to ask the right questions, but specifically what metrics can be used to answer them.

Agile Analytics: A GQM Approach to Enterprise Metrics from LeadingAgile

The post Agile Metrics: A GQM Approach appeared first on LeadingAgile.

Categories: Blogs

Staying on Course With Agile

Wed, 05/17/2017 - 23:22

You may have heard that agile is just a bunch of cowboy programmers doing whatever they want; there is no rigor or discipline and best of all…NO more documentation. You may have heard about the agile zealots and that teams are full of these so called “agilistas” just spewing out code with no concern for quality and that you never know when anything is going to get done. You may have heard that others have tried some form of ‘agile’ and that “it” doesn’t work. Well fake news is everywhere these days, and misinformation about what agile is, and the notion that agile doesn’t work is a prime example.

The emotional reactions to agile can range from ‘meh’ to a vitriolic ‘it’ll never work here’. But, for organizations that are enthusiastic about making a transition and infusing more agility into their businesses, it is important to filter out the hyperbole. The facts can set you free. Becoming more agile is a journey rather than a destination, and in many ways, the path can be non-intuitive and overgrown with detritus.

Clear requirements have traditionally been an important first step to understanding the solution space and, just as importantly, an idea of how long it will take to implement it. There is a bit of hubris in this approach. Experience has shown that trying to nail down requirements at the beginning of a project—when we know the least about it—is the worst time to do so. What teams need instead is the ability to learn what a customer is trying to take care of throughout the project and make course corrections based on that emerging knowledge as it grows. Engendering the skill of making course corrections is one of the keys to the agile kingdom.

Experiments, and designing for discovery helps teams stay on course and produce better outcomes than big requirements documents and a lot of up front design. A well-groomed backlog is essential, but it does not mean that every detail is understood and articulated up front. Determining how to implement the details of a solution at the last responsible moment is encouraged because great solutions are based on the most up to date information about what is really needed rather than what we thought was needed at the outset of the project. Balancing when that information is captured and converted into team knowledge is a big differentiator between “doing Agile” and being agile.

That does not mean we don’t do any up front planning and certainly does not mean “No Documentation”. Themes, Initiatives, Epics and Stories all need elaboration and some form of memorialization so that teams can gain some collective knowledge around the outcomes that are going to be most important to customer. That documentation may be concise, and it may continue to be elaborated throughout delivery, but it should be captured in some way that communicates both the what and the why of the effort. The outcomes a customer is after is more valuable to understand than features or functionality. Requirements documents historically focus on the latter.

Far from the misperception that agile lacks discipline, done well, it is actually more rigorous than traditional approaches. Prioritization around value is not just the first step to a series of predetermined steps, but rather an ongoing guiding force as we continually refine our course toward the ultimate destination. Like an airplane navigating to Tokyo, pushed off course by winds and sometimes circumnavigating around bad weather, constant course correction produces a better result than setting a direction and hoping nothing changes along the way.

In a way, IT Leadership reminds me of my flying days. From checklists to navigation charts, pilots need documentation too. They need to know the radio frequencies with which to communicate and the protocols for doing so. And the good pilots are rigorous; they are disciplined. Now, there are some cowboy pilots out there who eschew the rules. Sometimes, unfortunately, they end up serving as a cautionary tale for others. There is an old saying about pilots, and I think it applies to IT leaders as well.

There are old pilots and there are bold pilots, but there aren’t any old, bold pilots!

So, rigor, communication and even documentation really are necessary. The best pilots have a lot of airtime and experience. They are most likely to get you safely to your destination. Indeed, for IT leaders, with large IT projects, there are similarities to flying a plane. Communication as well as both the skill of navigating and course correcting—are essential.

There are both cowboy pilots and cowboy agilistas out there. IT projects and flying can be inherently dangerous, and like so many failed IT projects, there are a plethora of failed agile experiments too. My recommendation in both cases is to look for experience. If you are considering agile, don’t listen to the “fake news”. Find a seasoned agile guide; someone with an approach that considers your environment, your business model and your customers and flexes to help you make the most of your transformation. Experience matters and the success of your journey may just ride on who you’ve chosen to help you navigate the course.

The post Staying on Course With Agile appeared first on LeadingAgile.

Categories: Blogs

Cost of Delay. What Does It Mean?

Wed, 05/10/2017 - 14:29

Oftentimes when I ask Product Owners how they choose which projects their teams focus on first, they don’t have a technique for prioritization.  Cost of Delay is a concept that a lot of organizations are using and that has gained traction over the years. Unfortunately, many people are still struggling with the concept of Cost of Delay, so I want to put it down in laymen’s terms here in this blog.  Ultimately, the Cost of Delay is a concept that helps you decide—if you have two or more efforts—which order to perform them.

“Cost of Delay” in layman’s terms is the Cost of Delay“Well “Duh” you say … doesn’t really help to define the term using the term itself!  Thanks a lot!” You’re absolutely right, so let’s look at it from a pragmatic vantage point. The cost of delay can mean the loss or deferment of a benefit/value due to the delay and/or incursion of some sort of penalty.

For example:  we have all experienced the “cost of delay” getting out of the house late to go to work.  In Atlanta, a 15-minute delay getting out of the house could result in a 30-minute commute becoming an over-hour nightmare.  Couple being late with the “penalty” implications of missing an important meeting, and you can clearly visualize the “cost of delay”.

In business, we do projects to accrue some expected benefit from the result of that work.  Delay the realization of that project by a quarter, and you’ve incurred a “Cost” of a quarter’s worth of that benefit this fiscal year.

project value over time

Miss an expected market window of opportunity, and the Cost of Delay will include an even greater penalty.

project missed the market window will equal greater cost of delay

In Principles of Product Development Flow, Don Reinertsen speaks extensively about Cost of Delay.   He leverages a model that visualizes projects as rectangles with their vertical axis as the Cost of Delay and their horizontal as the time it takes to implement them.

Leveraging this model enables us to determine which order to do the projects to minimize Cost of Delay.  We can visualize this by plotting the projects on a waterfall diagram as shown below:

minimize cost of delay by accelerating projects early

The first project incurs zero Cost of Delay, because it was begun immediately.  The second project’s Cost of Delay can be visualized as it waits to begin.  Likewise, the third project’s Cost of Delay can be envisioned as it waits for the others to complete.

Therefore, doing the projects in the order on the left diagram incurs less cumulative Cost of Delay than the order indicated on the right diagram.

You don’t want to prioritize your projects to start slowly and accelerate at the end. You want them to ramp up early and taper off to minimize the Cost of Delay.

see your ROI sooner by implementing cost of delay to your project

Think of this in a different way …  What if we plotted value (above) rather than Cost of Delay.  Wouldn’t you rather have 83% of your money in the bank halfway through the time-period vice only 12.5%?

One thing to keep in mind while prioritizing projects is: overall value is not just money.  Nor is all cost paid in dollars.  Certainly, you’re looking for return on investment; however, you also need to consider what will happen to your market share, customer loyalty, and brand integrity as you make tradeoffs to meet or delay deadlines. For example, if you choose to delay a project and your biggest competitor releases their version of your product, what will that do to your market share?  On the flip side, what if you rush to market and release buggy software? How will that impact customer loyalty and, perhaps, overall sales? Will it detract from your brand integrity? These nuances should be saved for another blog post, but I’d be remiss if I didn’t mention some of the less obvious, but ultimately tangible, costs associated with delay.

Remember, too, that the value placed on projects is an expected or anticipated value.  Companies do projects with the hypothesis that they will result in a certain benefit.  What if that hypothesis is incorrect?  Wouldn’t you rather have more time to adjust (so you can hit the overall goal) than less time?!?  How many times have you or your executives bemoaned “I wish we’d known that sooner!!!”   There is certainly a “cost” associated with late feedback!

I hope that this overview of the Cost of Delay is helpful.  For far greater detail, please read Don Reinertsen’s book The Principles of Product Development Flow in which he goes to extensive lengths to describe the Cost of Delay.

The post Cost of Delay. What Does It Mean? appeared first on LeadingAgile.

Categories: Blogs

Live from Agile and Beyond: Agility Infusion 101

Fri, 05/05/2017 - 19:00

Gaining agility is different than “doing agile”, particularly at scale. This session will start with how agility makes a difference for the business and for the teams adopting it. We will look at the business structures that are needed for agility to thrive, how teams are organized and the new measures that will redefine success. With agility, one size does not fit all, but there are proven solutions, and this session will look at success stories as well as the dead-ends every organization wants to avoid.

Agility Infusion 101: Agile & Beyond from LeadingAgile

The post Live from Agile and Beyond: Agility Infusion 101 appeared first on LeadingAgile.

Categories: Blogs

Live from Agile and Beyond: An Executive’s Guide to Leading a Large Scale Agile Transformation.

Fri, 05/05/2017 - 16:00

Edit: Live Stream was swapped out for a recording since the internet connection at the conference was unstable.

Join us as Mike explores the change management and engagement techniques necessary to make sure you are building meaningful organizational support as you engage the enterprise. He’ll discuss how to build and execute a change management strategy to keep everyone safe and informed throughout the transformation, how to sustain and improve the changes over time, ultimately creating an organizational ecosystem where business agility is part of the fundamental DNA of the company. The goal of this talk is to show you how to systematically and planfully introduce agile into your organization.

The Executives Step-by-Step Guide to Leading a Large-Scale Agile Transformation from LeadingAgile

The post Live from Agile and Beyond: An Executive’s Guide to Leading a Large Scale Agile Transformation. appeared first on LeadingAgile.

Categories: Blogs

Takin’ it to the Streets: Agile Day Atlanta 2017

Wed, 05/03/2017 - 16:13

What if—for one day—you could get some of the most brilliant minds in Agile to share their best ideas for solving tough problems facing your business today? That’s what Agile Day Atlanta is all about: getting those minds together, so you can “take it to the streets” in your company.

We’ll kick off with an expert panel of executives who’ve already led the charge in large-scale Agile transformations. Facilitated by our CEO and Founder Mike Cottmeyer, this panel will explore high-level challenges and give you perspective on how to handle tough issues. Have your questions ready.

Next, whether you’re focusing your energy on transformation, metrics to measure progress, or improving the Agile environment, Agile Day Atlanta has a track for you.

If your plans are centered on transformation, pick the Traffic Planning track to boost your efforts. You’ll learn from speakers like:

  • Danny Presten, from Equifax, who will highlight time-and-effort-saving lessons learned in transforming a 100-year-old, Fortune 500 company.
  • Melissa Oberg, from Fiserv, who will discuss the value in creating model transformation teams that can be duplicated throughout a global enterprise.
  • Tonya Mompoint, from CareerBuilder, who will present a case study of how CareerBuilder used a unique Lean approach to scale Agile.

If your transformation is in place but you need smart tools for measuring team health, progress, and results, go for the Traffic Calming track. You’ll get the heads up from speakers like:

  • John Tanner, from LeadingAgile, who will explain how to use goal-oriented measures (GQM) in software organizations.
  • Rob Gordick, from Daugherty, who will teach you about everything from coaching techniques to Agile core values to Lean and Agile approaches (like Scrum, XP, and Kanban) to the healthy psychology necessary for Agile to be successful.
  • Daniel Vacanti and Prateek Singh, from Ultimate Software, will show you new methods for accurately predicting project completion in the real world.

If you’d like to learn about using best practices and avoiding pitfalls, choose the Traffic Patterns track to fine tune your Agile processes. You’ll find out all the nitty gritty from speakers like:

  • Mike Clement, from Greater Sum, who will introduce you to Mob Programming, techniques critical for its success, and irrelevant practices you can toss.
  • Jeremy Kriegel, from BzzAgent, who will divulge the secrets your customers wish you knew and teach you how to construct a repeatable framework for finding and addressing your biggest risks.
  • David Laribee, from Nerd/Noir, who will present about the most productive testing models in use today and illuminate their various nuances from personal experience, real world example, and case study.

This non-profit, volunteer-driven event is sponsored by LeadingAgile, VersionOne, and CareerBuilder. Proceeds will go to the Atlanta chapter of Power My Learning, a national non-profit committed to empowering underprivileged children in their education.

And, when the tracks are done, plan to kick back with us at the VersionOne offices with BBQ, drinks, and live music.

No matter where you’re heading in Agile, this one-day extravaganza (held in lovely Cumming, GA, northeast of Atlanta proper) can help you get there better and faster.

Seats are limited so be sure to sign up soon!



The post Takin’ it to the Streets: Agile Day Atlanta 2017 appeared first on LeadingAgile.

Categories: Blogs