Friday, May 01, 2015

Public Draft: Who the Heck is "The Business"?

As a VP of technology your day is going along fine and then boom... priorities shift from product and marketing moves the date up. A big presser is now being formed and you have to adjust and communicate the change down to your teams to proceed forward. The following week, sales dials you up and announces that they have the trump card, $300k in sales are on the line. You have to stop what you are doing and get the release you were working on out of the door pronto. The teams below you are stuck at the perceived whim of a madman. Who is the madman they perceive? That "madman" is the variety of demand coming from Sales, Marketing, and the Product organization. It's tough to prioritize in a way that makes everyone happy. So we can intentionally choose not to do so. There are plenty of problems in organizations. Sometime plans don't exist. Some people are in fact yes-men. There are 10 stakeholders. These, and plenty of other things, happen in the real world. So when forming portfolio and program teams, the general sentiment of the crowd when I walk into the room to begin coaching is one of frustration. I repeatedly hear "the business" from anyone and everyone. It is truly a point of deflection, representative of years of abuse. The statement will come from all parts of the organization. Sales, marketing, IT, product, operations, no one is exempt. However... After forming a proper portfolio team, the first thing to come out of a portfolio is a business-facing Epic. The portfolio will intentionally begin to prioritize work so that demand is focussed and the next best thing. This is followed by another Epic, and another. They start prioritizing epics against each other and making credible, pragmatic business decisions around what they will do in the next few months. They begin to visualize a roadmap of epics. The roadmap will likely change and when it does this group will have a way to prioritize those changes against the current plan. The biggest plus is that it is all transparent. The teams above, below, and around the portfolio will be informed. The voices are calm and the team is now dealing with the rational single voice of the portfolio. In a short time, the portfolio and teams that they coordinate can see that they are "the business".

Tuesday, April 28, 2015

How to Start to Solve the Problems of Your Product Development Organization

I have been thinking a bit about organizations and in particular, where I need to engage organizations to be most effective at helping them solve the problems of the overall business.

To better understand what has shaped my thinking I’d like to start with a bit of history around my background and life experiences. I initially started as a networking administrator within an old school ISP service organization and then my career progressed away from support services and into shared services and eventually product development. My experience in a variety of roles provided me with a set of perspectives around service and product development organizations. 

These two key organizational types have distinctly different engagement models for me. If you have read some of my other work, I have a solid perspective on solving problems, and you’ll know that I don’t implement agile to be “more agile”. Agile is a large tool in my toolbox and tends to assist in solving a core set of issues that affects organizations: time to market, predictability, cost reductions, and quality to name a few. When I enter organizations, these two organization types are patterns that I look to identify to help me solve their problems.

The Service Organization

A service organization is generally an enabler of a real business function like sales of human capital or, put in a nicer way, staffing. Thinking back to my history with a big player in the healthcare staffing space, IT was a function of the business not the business itself. We typically did things like CRM development and website development that facilitated lead generation and the like. The business makes a pull for a new service to be available to the real product Sales. In this type of organization, I find it useful to transform in IT unless I am encapsulating the entire value chain from initial contact to opportunities for converting and through to conversion of the sale and possibly beyond.

For that reason, the IT group is there to make the life of the sales organization more efficient, or restated, to enable more and higher sales and generate more money. IT is an enabler for sales. In these organizations, I am fine with an IT implementation of agile that gives lead times to the organizations and that can make reliable commitments to delivery. The overall goal is to enable generation of more leads and to close more sales buy providing services that enable the organization.  The goal would be to reduce cycle time through automation of processes.

The IT failure would be if they are the bottleneck in the cycle time or if they are elongating it.  Beginning with IT allows me to focus on a predictable delivery of capabilities to an organization with the goal of enabling the real customer of IT, sales. Sales in this case would be to both the businesses wanting a staff augmentation and the person that wants a job. They are split out in organizations depending on the size of the staffing company, but those are the two basic products. 

The Product Development Organization

I find product development organizations to be a little bit different and I'll warn you, I don't share the same sentiment others do. Product development organizations are fundamentally broken most of the time. I hear "the business" a lot… and in truth, I hear it in service organizations too. Nevertheless, “Us and them” is the prevailing attitude in sales, marketing, product, and IT in many organizations. In my experience, product and development are one and the same most of the time if you use the 80/20 rule. They share the same agenda. Get products to market that improves the bottom line while excelling in the market. 

Sales heavy organizations will tend to favor contract fulfillment, market penetration, and customer retention.

Market based organizations will tend to favor consumer behaviors, finding new markets, and trends.

Either way, you develop product to help you fulfill those needs. In both cases, I foster or create the partnership between product and IT organizations. That's one reason why I look to solve the problems of the CEO or VP of a division. The person sponsoring the change needs to be a part of the organization that can ensure the bond does not break.

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.