Tuesday, November 08, 2016

Stable Teams - Predictability Edition

Today I am addressing a key component to help teams succeed. Stable Teams.

Stable Teams Defined

I find that many people interpret those two words in many different ways. Here's my definition.

A stable team is a team that stays together for ideally multiple releases or quarters. They have a few characteristics:

     1.Individuals on the team only belong to one team.
     2.The Team has one backlog.
     3.The backlog is formed by a consistent entity.
     4.The team stays together for multiple releases or quarters barring life events like illness, HR issues, etc.


Stable teams can be applied at any level in an organization. Communities of practice, agile delivery teams, programs and portfolios all have a backlog.  


Plenty of studies have been done on the appropriate size of the team or how productive the teams can be if they are stable. Here are the key points:

     1.Teams that stay together have a higher throughput.
     2.Teams that stay together are more predictable.
     3.Teams that stay together are happier.

The Softer Side

Our community is multi-dimensional in how agile is implemented.  I implement a structure first approach. Some implement a cultural approach so that they change the mindset of the organization. Still others implement a practices approach where practices are taught and the teams are responsible for the outcome.

The reason I choose a structure approach is fairly straightforward. It's not that I don't care about culture and practices, but it's out of respect for the longevity of the team, the culture, and the practices. I am intentionally creating a container that protects the team.  Protects them from what you might ask?


With a cultural approach, the worst thing I can do is teach accountability, self-organization, and how to be a generalist and have that subverted by team members being swapped off of teams. Teams that stay together figure out how to use each others unique strengths over time. They can be responsible for their own outcome and held accountable for it too. They can figure out how to best do the job at hand. If I pull someone out of the team, that kills accountability and their self-organization is blown to bits. Go ahead and try to hold them accountable. They will hate you for the long hours they pull trying to get the work done.  Respect the structure, and seek to change culture after protecting the container.


With a practices approach. The container for the team to take those practices and run with them isn't created. The team may not be able to effectively create a working agreement or retrospect to come up with new ways to improve or implement the practice. They can attempt to self-organize, but it's beyond their control much of the time.


So I turn to structure. If I structure the team, protect the team, and support them, they have the best chance for success. Not all teams will succeed. Some will improve slower than others. But they have a shot at changing their own culture. We can hold them accountable for their outcome because we have enabled them to do so. They can become generalists over time so when life events happen, the team can cover and prop up their team member. When attrition occurs, the team can absorb the change more readily.

Assuming that all made sense, what the heck is preventing stabilization of teams?

To list a few:

     1.  Focus on individual utilization.

Some organizations focus on maximizing individual utilization, they even overbook. In large PMO organizations that focus on utilization of individuals there is a sense that team members aren't always working. This just isn't accurate. While in the short term a team member or two can be underutilized, that is a maturity of practice issue that can be overcome. Utilization can indeed be improved. Not only that, but those people managing how much individuals are used across the organization can focus on something else because utilization is stable too. Knowing how much capital investment you have vs opex is much more valuable than scheduling someone's percentage of work on a feature.

     2.Side Projects

Kill them with fire.   Actually no… some side projects make great candidates for the backlog of the organization. Providing a single source of truth gives clarity to teams. Tech Debt can be prioritized along side of features. Teams need to be able to quantify the value. That's generally easy to teach them. In the end, they will find that they get much more done. On another note, if the team is receiving work from the side. On the down low. That needs to stop. It's an impediment to Team Stability. Find the source, figure out why it's happening and eradicate it. That’s not simple, people have side projects for a reason. They are trying to solve a problem. Figure out if it's an education issue, an alignment issue, or otherwise.

     3.Dependencies on other teams 

Dependencies are always a truth and cost of doing business in my opinion. There are some really cool things we can do to get rid of them, but in the meantime we need to shoot for the most capable team with the fewest dependencies on other teams that we can. Capability modeling can be a life-raft to help with this. Structuring around your existing capabilities and enabling the teams by putting what they need to take care of those capabilities is critical to predictability. Dependencies still need to be managed, but not as much if we are smart about how we staff the team to enable them and figure out capability ownership by the team.

Stable Teams are a non-negotiable part of a predictable system.  Sure, their are outliers, but by and large, stable teams are one of the biggest ways you can help yourself and your organization.  If you can't figure out how to do it or are not empowered, get help.  And remember, this isn't just about Scrum teams, it's about teams.

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.