Saturday, October 26, 2013

Formative Organizations - Introduction

Update: removed Deming comment that was out of context.

Formative Organizations

Building a Foundation on Integrity, Delivery and Learning

The Problem

There are many articles, like this one in Forbes, talking about the life of organizations becoming shorter in one dimension or another. Does this idea of creative destruction have to be outside an organization? How might we increase our organizations likelihood of adapt to an unknown future? It seems like a worth while

The Direction

We are taking this idea of flexible foundations and starting to build user interfaces that are not bound to what we know today. That is, we are not designing to only handle resolutions and browsers that exist now but to scale, both up and down in size and capability, as they change. We are starting to create distributed architectures that can take advantage of cloud computing to grow and shrink our infrastructure to meet changing needs. Our organizations, however, are stuck in a rigid unbending system that hinders us from adapting, growing and developing to meet the fast changing market we are in.

I don’t think this requires a great new framework to scale Lean or Agile. As Arlo Belshee, @arlobelshee, tweeted recently, “These days I wouldn't say don't scale. I'd say make shipping easy, then solve the few remaining problems.” We don’t need to scale agile, we need to make our organizations scale. However, let's not fool ourselves that the solution is simply a technical one. The solution starts with people! We can use frameworks but we should be very careful with them and not bind ourselves and our thinking to them. Tight coupling to frameworks makes code difficult to change. Tight coupling to agile frameworks makes organizations difficult to change.

After starting the book Lean Solutions, I have not completed it yet, I also think Arlo has stated an incomplete view of the problem. It is not simply shipping, though shipping is clearly the early part of the value chain, it is a full circle of customer need or want, known or unknown, possible solution by someone, learning and supporting the customer and other 'stakeholders' and continuing to solve the changing needs in the future. Supporting this full cycle is what I would like to be apart of refining.

The Formative Organization Idea 

Set a vision and create a goal to deliver that vision fast with integrity, learning and adaptability.

Merriam-Webster gives the second meaning of formative as an adjective as:

capable of alteration by growth and development; also :  producing new cells and tissues” Merriam-Webster

The basic idea is creating the ability to grow and improve leading to new ideas and solutions that improve and/or replace the existing ones. To do this I think we can combine several sets of overlapping principles and practices that allow an organization to give people the view they need to adjust what they are doing to support this full cycle. Obviously, my idea is not completely unique and dreamed up by me, not even a significant portion of it. 

The primary source of principles and practices for creating Formative Organizations 

  1. The Antimatter Principle"Attend to folks' needs." Bob Marshall, @flowchainsensei
  2. Lean Startup - Eric Ries
  3. Continuous Delivery - Jez Humble, David Farley
  4. DevOps - Gene Kim, Kevin Behr, George Spafford 
Combining these principles and practices appear to start us heading down a path towards a more complete system view. A view of this cycle often referred to as creative destruction.

I am not sure the implementation of these ideas have fully dealt with all areas though I think the principles might. They clearly show how we bring together customers, idea people, delivery people, support and operations people and a few of the roles like risk and compliance. The idea of a formative organization must bring all roles together to understand the current vision and goals and knowing when that vision and goal should change.


I put the Antimatter principle first on the list of guiding principles to indicate the importance of people. This idea that we all must think about others and how we affect others and work together to move that positive for everyone. I think the agile idea of cross functional teams is headed in the right direction. Many implementations are limited in application. All people must be involved and have their needs considered. 


Many agile teams limit the idea of cross functional teams to business, development and testing. Though small teams need time to focus, a real need, quite often others need to be involved often. I think that the other 3 sources of principles support this idea of broadening the basic agile cross functional team to include all value adding people; business, customer, development, facilities, finance, HR, operations, testing, etc. 

This may be more of a group than a team if you use size to determine the idea of team but somehow this larger cross functional organization of people are required to meet that full cycle and each must know and learn how they effect the others.

Learning and Adaptability

Learning must happen along several different paths. The first is understanding how we all fit together and affect each other. It is a focus on how we move a vision and goal forward and allow it to change as needs change and as abilities to meet those needs grow. If we do not have this down all other learning is likely to hurt us more than it helps us.

Once we know how we affect others we can continue to learn how we deliver as often as possible. Of course the primary goal of having the ability to deliver often is continued learning about how we affect others. Specialized skill learning is very valuable and a must if we are going to deliver our solutions often. We must remember that most of the specialized skill training information we use to learn from does not take into consideration our primary learning of how we affect others. Part of specialized learning is learning how to apply it in a beneficial way. This is almost always adaptive in nature. This adaptive process depends on the integrity side. We must be transparent about what we know, what we project is likely with this new learning and what we have no idea about. 

This process of continuous learning is the driver of continuous improvement. It is also the driver of vision and goal changes. As we all learn we start to see a better future together and adapt to that future.


Early on I mentioned a single vision and goal but I do think the larger an organization gets the more uselessly generic that is likely to become. It is likely multiple cross functional groups are will develop. This may be simply changing the structure of silos versus removing them. Frankly, I'm not sure if this is good, bad, indifferent, more risky or less risky but it is the direction I am exploring.

Each of the sources of principles I have listed are people focused. It seems this cannot be said and strived for enough. We must be realistic that this is the hardest part. It is easier to focus on process, methods and practices and likely always will be. I just have trouble seeing how a process that is not focused and understanding peoples needs is likely to meet them. 

I have some hope that this is more than just a bigger idea of cross functional teams and self-organization but I also have some doubts about that. I am theorizing that if we can have a broader focused set of people we can increase our ability to alter and develop our organizations that creates new cells faster than old ones die.

Please leave me your thoughts and ideas for improving this? Is it worth continuing to pursue?

Friday, October 4, 2013

Is The Product Owner Role Hiding a Bigger Issue

Is the Product Owner/On Site Customer role in Scrum and XP potentially hiding a bigger inventory problem? My thought on this started with a blog post from @duarte_vasco. (please stop and read this to gain context) It also fits with several experiences I have had. But first let me show an example that actually makes the problem visible.

At a company I was working with they could not agree on a single product owner type role. This caused them to create a product owner team for each scrum team. These product owner teams had people from the business, IT and user experience groups from the organization. Of course for many with a Scrum or XP background this clearly brings to the forefront the likelihood of several issues cropping up, multiple priorities given to the team, slowness in agreement on direction, stories that are really small requirements documents, etc. Not surprisingly, that is the case. However, that problem is very visible! The visibility has lead to discussions on how to improve that. I am not completely confident they will create a solution that is significantly better on their first attempt to fix the issue but as long as they keep making it visible they have a chance to.

Other teams I have worked with had this same process happening in the background. The product owner role hid the issue though. Months of work were happening in the background trying to define features, get funding, get buy-in, etc.

The problem is not with the Product Owner role. The problem is we are creating a role without focusing on the real goal, how do we improve the organization's ability to deliver more quickly, understand customer needs and adapt more quickly to market demands.