Tuesday, September 01, 2015

Shepherding Feature Flow Across a Program Team Kanban Board

Suppose we have the flowing Feature Flow for a kanban board representing a program or product owner team. A team that is responsible for filling the need of product owner for several delivery teams.

Feature States
The facilitator of the kanban is the shepherd of features across the kanban board for the program team. They govern the stately flow of features, control WIP, and clearly communicate the state of the program commitments at all times in the system and out of the system.

The core beliefs of the Kanban Lead are:
1. Transparency
2. Stability of the system
3. Batch Reduction to achieve flow
4. Throughput balanced with quality
5. Choosing flow above bottlenecks and wasted time
6. Choosing value over flow

To live by these principles kanban facilitator govern each state to maintain consistency.

Kanban facilitators should maintain flow as appropriate to produce the highest level of predictable value. They should know the definitions of done for each state by heart. They should internalize the system over the daily goings on.

Friday, August 28, 2015

Creating a Pull System for Product Development to Demand DevOps

Friday, May 01, 2015

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: <http://www.investopedia.com/articles/financial-theory/11/corporate-project-valuation-methods.asp>.  

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 http://www.TeamWorldVision.org/6k.

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.