Friday, March 20, 2015

A Little Risk Goes A Long Way

Risk is a big topic, but generally for beginning agile teams (or any team) it can be calculated in a minimalist way as dependencies.  To me, dependencies represent a binary probability.  Either they are resolved or not.

When paired with value, risk becomes super important to look at because it can tell you how much of that value is in danger.  Specifically, we can use it to make informed decisions about investment.  

Regarding value

For now, I will take a look at value through the lens of Net Present Value (NPV) because the program I am currently coaching was already using it.  I am not advocating for NPV, just meeting the program where they currently stand.  Boiling it way down... Net Present Value is used in capital budgeting to represent the profitability of an investment over time.  In agile, this might be an investment in an epic or a feature or a capability, etc.  You also might use story points as a super simple starting place until you figure out what value means in your organization.  Net Present Value and a few other valuation methods can be seen here: <>.  

Risk-adjusted Net Present Value (rNPV) has been used in pharmaceuticals to determine if a capital investment is worth pursuing.  The basic reason for they use this method is that new medications are expensive… Expensive expensive.  Like $2.5 billion expensive to get one for which the market approves.  There is a high probability that drug trials won't work out and the drug won't make it to market on time or at all.  For that reason, risk of failure is assessed and applied to the valuation.  That can lead to investment decisions in large capital projects.  

How About Doing That In The Small?

With proper breakdown of strategy, I  encourage organizations to do some form of analysis for the next three months at a tactical level to make sure that they inform themselves of the level of risk so they can determine the likelihood that they will realize a return on their investment.  The risk exposure is smaller than NPV is usually concerned with and we may be willing to take on a larger risk profile, but the problem is the same.  If you have a relatively significant investment, you want a reasonable shot at realizing your return.

Looping in Agile

Take a look at programs and portfolios.  Sure there are plenty of risks that can prevent projects or features from succeeding, but to keep it simple, I am focusing on the binary dependency.  It is done or not done.  Therefore, the probability of the risk being removed is 50%.  Continuing the math for a bit, for each dependency on the outcome we target, we have a factorial of possibilities… or in English:

If we have two dependencies, we can have four possible outcomes.
For Example:

  • Resolved | Resolved
  • Resolved | Failed
  • Failed      | Resolved
  • Failed      | Failed

That makes the probability 25% that we will have an outcome of Resolved | Resolved.

If we have three dependencies you can have 8 outcomes and thus a 12.5% probability and so forth and so on. 

So now forget about NPV.  We don't care.  We need a way to make good investment decisions for things that will actually come true.  We also need this method to be lightweight.

Given 100 points are in a release and we have 2 dependencies that need to happen in order for us to release the features.  We have  a 25% probability that we will release 100 points.  Your risk to point value that you can count on is 25 points assuming that all points are blocked by those dependencies.  Granted, that's not a value assessment, it's a point assessment.  But that's an ok place to start.

So Now What?

With this new information, there is a definitive incentive to remove risk early.  Really early in the release.  As a matter of fact, I want relatively new teams that are just starting out to plan a release that has an 80% certainty of delivering it's value.  That means that before the release, we need to remove most of the dependencies.  I have been toying with capturing this as a risk burndown.  Here's a quick wireframe of it. 

In this Figure, we are burning down the percent of the release that is impacted by risk.  Like I said, I like relatively new programs that hit 80% of their value delivery.  We can use the percent impacted to drive risk points down to below 20% before the start.  It's a pretty simple, good way to look at the probability that programs and portfolios are making a responsible commitments and have the math to back it up.  Speaking of math... this stuff can get a ton more complex.  A great goal is to keep it simple so we can all relate.  I know this is a little off math wise, but it's enough to inform and get people started toward developing reliable release plans and roadmaps that mean something.

Wednesday, March 04, 2015

Join The Cause: 6K for World Water Day

Join me on World Water Day (March 22, 2015) as I run/walk Team WorldVision’s virtual 6K for Water in North Atlanta.
6K is the average distance that people in Africa have to walk for water. On World Water Day, thousands of people across neighborhoods, city streets, and country roads will be walking and running 6 Kilometers (3.72 miles) for children in Africa.
When you sign up, Team WorldVision will send you a t-shirt and a race bib with a photo of a child that will get clean water from your registration. This is your chance to invite your whole family to make a difference regardless of age.  If you are in Atlanta and want to join myself and others look for the “North Atlanta – Big Creek Greenway” team when you register at

Tuesday, February 24, 2015

Before You Start: Agile Change Management... In a prezi

An agile change management model.  Before you begin your journey in agile, consider the larger broader context of support that you will need to be successful.  There are many angles to agile with delivery being just one of them.  Check out this prezi for some thought around different angles and how to manage a transformation via change management.

Photo credit: Anxious Athlete Waiting at Starting Line, by CS productions.

Wednesday, February 18, 2015

Time To Up The Accountability Of Your Agile Teams

Time To Up The Accountability Of Your Agile Teams

In my last entry, I talked a bit about what accountability means to me. Check it out to create a shared understanding between us before reading on…

In this continuation, I will begin to dive into structures that support accountability at scale. For now, there seems to be enough material at the scrum team level and then subsequently at the scaled level. Here’s the delivery team level for ya.


Most of the companies I have worked with in the past several years are in the small (multi-millions) to very large (multi-billion) dollar range. Complexity, maturity, and age of the organizations were all drastically different. One of the steps I need in order to move the accountability needle forward in these organizations is the formation of teams. That’s the start of my scale. Good delivery teams.

More and more I am demanding that teams be an encapsulated cross-functional group of people with a purpose. It just works. I don’t need or want parts of people or percentage utilization… we do, in fact, need the whole person to make a whole team.

So what am I after with regard to accountability?

Most orgs I work with don’t have a great sense of accountability. The culture is all wrong to ask a developer to suddenly care about a product or capability. My approach to culture is to enable it to emerge. Ultimately, I’ll ensure the team is encapsulated and can be accountable for producing working, tested product.  It I don’t do that, a culture of responsibility won’t stand a chance.

Encapsulating the Team

By encapsulating a cross-functional team, I am enabling a more robust culture to emerge. I am able to hold the team accountable for the outcomes they generate. Given that my primary focus for scrum teams is to make and meet commitments that deliver working, tested product, holding them accountable for making and meeting commitments enables me to focus in on guiding the culture of the team toward a shared responsibility. Retrospectives become more meaningful as responsibility grows. This is the basis for my prototypical scrum team. A no-excuses team that owns their commitment and get’s better over time.

What is holding teams back from a responsible state?

When teams are encapsulated the problems become more obvious. Here are some examples:

- Teams don’t understand the problem they are trying to solve and simply take on work
- Taking features or stories with dependencies into a sprint
- Not making a credible sprint plan by tasking out stories in a thoughtful way
- Collaboration: i.e. Trouble adapting to doing work in public

As a coach, I draw the private moments into the light. Teams likely haven’t thought through how to deliver product and the team/person can be rightfully shy about not knowing about a subject. Getting used to collaborating in public is a great step towards taking responsibility. It may seem harsh to some, and it may not sound happy-go-lucky, but a lot of people are essentially sick and need some medicine. My empathy is like that of a doctor, in order to get the desired outcome, you will need to take this medicine and go to physical therapy… a lot.  It’s my job to prescribe, it’s theirs to do the intense work involved in the physical therapy.

By encapsulating teams and holding them accountable for not making and meeting their commitments we are enabling (demanding even) that the culture change. That requires respect for the encapsulation of the fixed team. Movement of team members during a release, allowing side projects, percentages of people, playing utilization games, forcing work through the system are all undermining the encapsulation and ultimately the predictability and commitment of teams. If you can’t form teams, get help.

Changing Value Systems for interdependent teams

In order to promote even more predictability, the new shiny team needs a dependency free, clear backlog. That’s where the traditional Product Owner or more likely for me, the Program Team comes into play.

To accomplish this and achieve accountability, I use working agreements and definitions of done and ready for delivery teams. Via workshops, teams define working agreements, ready, and done at the beginning of forming a team and continue to refine them at each review or retrospective during the first few months. This hardens the accountability and responsibility of the team to each other and allows me to promote a servant-leader attitude for the team.

Working agreements and definitions of done and ready are powerful tools for accountability. They give the team a known state that they can be held accountable to…. If they don’t make and meet commitments, then we need to review the definitions of done and ready and figure out how they can further solidify them to become predictable as a team. This does not mean beat the team with a stick, but rather being respectful of the capability of the team to deliver. I respect that and expect it too. Say what you are going to do. Momentary lapses of meeting a commitment aside, no team should devalue the importance of their commitment. As a result, organizations can grow frustrated with the lack of predictability in the organizational roadmap. It’s important stuff and there should be a dual respect of the organization and the people.

Next time

I’ll take it up a notch. We’ll discuss program teams and scaling this structure up. I’ll give some tangible examples of accountability of program teams and even list out exactly what one program team said that solidifies the notion of letting culture emerge. A sneak peak… “It’s ok to accept change, in this system change can be embraced” – My new favorite BA when asked what she would tell other BA’s about moving to agile.

Thursday, February 12, 2015

Are You Practicing Agile Accountability Responsibly?


I started out this blog post writing about shared accountability for agile program teams. Accountability is an interesting, large topic that gets skipped over quite often in our agile community. In fact, I found, in my writing, a realization that we don’t have a great track record for defining it. So here’s my take.

Caution! I am trying to pair down my mindmap of points to discuss in this blog. Apparently, I am not doing a great job, and I’ll own that. The way that I’ll own it is by committing to write to conclusion about:

All right, let’s go for an accountability walk.

If I asked you, “What are teams accountable for?” what would your answer be? Go ahead, and take a minute. Picture the team in your mind. You may want to write it down to refer back to later.
Would your answer include: make and meet commitments, to break down work effectively, or to have a great design or architecture? Would it be to create revenue or an effective marketing campaign? How about “the teams are working hard?”

Definition – Mine, not by the book

Accountable – adj. – A need to explain to an asking authority the actions or decisions made

And in addition,

Responsible – adj. – The state of mind or being that owns the duty of taking care of something or someone

Clearly, there is a relationship to responsibility baked into accountability. The nuances of that relationship are argued over. I am not interested in that argument.

Individual accountability, to me, ideally matches with individual responsibility. That is–in order to be accountable for something–you will want to be responsible for that very same thing as well. Otherwise, you may only be accountable…which would be fine, but it wouldn’t produce the same results that both will.

I love the way Chris Avery describes his responsibility process. This is a very personal process and a great way to understand your own decision-making as to how to move forward toward taking responsibility. If you can move yourself to a responsible state (and, again, Dr. Avery’s work is a great reference), then you can hopefully match up your accountability and responsibility.

I had a unique moment lately when I was running a responsibility exercise with a team that I believed were in a shared denial state–which is really common. Here’s what it looked like:

I gave a set of teams an epic that they failed to deliver and asked them to fill in the following sentence on their own and to not show anyone. I also told them that we would rip up the sheets at the end and they would not have to share the information.

“The epic failed because _____”

I gave them the following choices to fill in the blank.
1. They
2. He
3. She
4. It
5. Me
6. You
7. Us
8. The Business

I didn’t survey the audience, yet I made the following point:

If you are looking at your sheet and you see, “They, He, She, It, You, or The Business,” then you are in a dependent state and not taking responsibility. You have given control to someone else to ensure that you can have a successful outcome. Not a good place because you do not have control of your outcome due to your state of mind.

If you answered, “Me,” then you are at a state of being responsible for your own actions. In this scenario, you have to get the job done and correct the issue.

If you answered, “Us,” then you are at a state of shared responsibility assuming that everyone else that falls under “Us” also answered, “Us.”

Later, I read the classic, “7 Habits of Highly Effective People,” and the idea of dependent, independent, and interdependent relationships resonated the same tone that I was trying to capture. For more info on that just pick up the book. It’s a great read if you are ready for it.
My challenge to the group was similar to the book’s challenge. Basically, if you find yourself dependent, try to move to independent (me), and then consciously try to move to interdependent (us). To do this, you’ll require an inside-out approach. First, you take responsibility and become accountable for yourself to yourself. Then you consciously move the group toward a shared responsibility that matches the accountability of the group. You’ll find that everything doesn’t need to be a shared responsibility, but that’s the goal at the macro or team level. Otherwise, you are little more than the sum of your individual parts.

You may indeed find your team impaired by a lack of organizational enablement. Organizational enablement, to me, implies that teams may not be formed in a way that they can control their own destiny. In scrum, for an individual team, this looks like the team. They may be getting pulled onto multiple teams, have dependencies, etc. In a scaled environment, that includes program and portfolio teams as well. For instance, the program team may not have the architectural capability to support fast release cycles. Many times, I have found that blame has been pushed all the way down to the individual level, and the organization lacks the capability to take responsibility. If this is the case, both managers and subordinates in the dependent state can form a learned helplessness where they are unable to move no matter the incentive because they are not taught to do so. More often, in corporate America, I see it manifest as a complaining, learned helplessness. When agile comes in, we, coaches, bring the therapy couch. However, before we bring the couch, we need to bring the proper structure and governance to enable the helpless and promote a responsible environment.  Ultimately, we have always had accountability. Someone always answers to someone else. A clear line of site of the accountability paired with responsibility is a win/win situation for all.

I’ll talk more about what that “win/win” looks like in the future as we discuss what the pull of accountability and the response of responsibility looks like at the team and scaled team levels. For now, I leave you with the need for any team to address how responsible they are being as it applies to how accountable they are being held. If there is a mismatch. find it and march toward responsibility together.

Wednesday, February 11, 2015

Redefining Heroics


This blog was co-written by my bud and fellow Agile Coach, Isaac Hogue.

Recently, while working with one of our customers the topic of heroics came up… okay, this comes up all the time :)

It seems hard to argue with heroics, from the time we were young we’ve heard stories of heroes in our family tree or national history. The term is attributed with acts of valor and selflessness.

Upon closer examination, frequently we find that the heroics that are being described in many enterprises could be better attributed with undisciplined, or even un-intentional delivery….

How do you define a hero in your business?
How does your business define a hero?
How do you reward the heroes?

A bunch of companies define a hero as someone who swoops into a project to save the day. They work a ton of overtime and get the job done by slaying the vicious dragon. They are capable of quickly stitching up a troubled problem just enough to get it to market.

It’s time for this paradigm to change.

When transitioning to agile there is a high value placed on one of the 12 principles of agile development, the indefinite, sustainable pace. Given the traditional “hero”, we immediately have a conflict. So let’s change the definition of the hero.

Heroics Redefined
  • What it is not:
    • working overtime
    • being the goto guy
    • taking over for others
    • saving a project at the last minute
    • the number of bugs you find
    • the total lines of code you write
  • What it is:
    • Sharing in successes and failures with the team
    • Practicing commander’s intent by helping the team generate new ideas of how to achieve a goal with an unknown path.
    • Demonstrable selflessness in self promotion
    • Creating a new team option by developing a new Generalist skill
    • Reducing team cycle time

Friday, February 06, 2015

Self Improvement on Agile Teams


“There is nothing noble in being superior to your fellow man; true nobility is being superior to your former self.” -Ernest Hemingway

A developer once told me that in Scrum, "I feel like I can never have an off day". After digging underneath that facade (developer joke!), the underlying issue was that the developer wanted  an "off day" to work on "technical architectural things". He felt that the way to keep up-to-date on his skill set was by introducing the latest technologies into the product we were producing.

This portrays a larger issue regarding self-improvement on agile teams that frequently impacts agile teams.  It can be an underlying reason individuals at the team level are resistant to an agile adoption.  There are a number of ways to "solve" this problem. Some, including me, might create communities of practice. Spotify created chapters and guilds. My focus today is at the immediate team member level. Here is my challenge for them so that they can create an immediate way to get those "technical" items in the backlog.

Agile For Business

It's very easy to relate agile to a business.  What business does not want early ROI, predictability, and increased quality?  But the "what's in it for me?" or WIIFM question often holds individuals and teams back from adopting agile. So how can we move forward knowing that the business wants value for the business and the team member wants value for themselves?

Agile Self-Improvement Case 1: I can't do the technical "stuff" that I want to do

Let's delve into the root cause using a bit of the 5 why's variation...

Programmer - "I want to work on technical stuff"

     Coach - "Why can't you?"

Programmer - "No one cares about technology. Every time I bring it up the product owner just stares at me."

     Coach - "Why should they care?"

Programmer - "Without the technology change, we can't do all of these cool things like giving the website a real-time response feel"

     Coach - "Why do you want to do that?"

Programmer - "That's what competitors are doing"

     Coach - "Why does that matter?"

Programmer- "We will loose money if they go"

     Coach - "Alright, work with your product owner to find out how much we are loosing and the trend"

Programmer- "Got it, but that sounds hard to quantify"

     Coach - "I'm not saying don't do it, but you have to make it important for the business to do.  What is the value of you doing it?  If you know that, you have something we can prioritize.  If you have something we can prioritize, you can work on that technical stuff."

Relate it to the Business

So the point is to relate the technical issue back to a business driver.  What is the ROI for improving technically?  What is the improvement in quality?  What about predictability of the team?

If you can’t do this, then you are blindly improving.  Improve with intent and it will be more rewarding for you and your organization.


I hear variations of this all the time.  Here are some additional ones I have heard or felt myself over the years.

Agile Self-Improvement Case 2: I don't want to test.  I shouldn't have to do others jobs... etc.  

Anyone that can do multiple disciplines well is of high value.  If you are silo'd in an expertise, just think back to the last time that you learned a new language.  How marketable are you?  Learning a new skill such as automation frameworks for QA or as I found on my last programming gig, Angular, were critical for me gaining a large picture understanding of development organizations.  It also gave me the confidence that I can do anything.  Talk about empowering!

Agile Self-Improvement Case 3: I can't find or don't have the time.  

We find time to eat because it sustains our life.  We find time to take out the trash because it's of high value that the house doesn't stink.  Find the things that add value to you.  View yourself as a business that serves your business as the customer. What are you going to spend your R&D budget on for your own infrastructure?  You have to believe in the value of your study of craft enough that you believe that you will ultimately go faster and do more.  The key is to own it.  Don't ask, just do it.  If you don't turn out better results own that too.  Understanding craftsmanship and committing to things like practicing your craft with katas or researching and digesting the SOLID principles are gateway drugs to self-improvement that is meaningful, long lasting, and sustainable.  You will never ask for another "off day" again because you will be in the drivers seat.

I would like to explore some more cases with you. As I said, I hear variations of the same issue all the time but seldom write them down. What are some that you hear?