Thursday, April 23, 2015

Agile Process Coach, Really?


Agile is not a process... Here's an Agile Process Coach to help you understand that. :-)

It shocked me the first time I heard that title.

Of course, when I am honest with myself, I know that I fallback to being a process consultant instead of a coach when I hit certain impediments.

Tools and Techniques are Process Consulting

I am seeing way to much of agile IS:

Doing 1.5 hour retrospectives using the 5 stages as defined in the book by so and so.

Stories are written in the format in that book by that other Scrum dignitary.

The ideal team size is...

The ideal planning cycle is...

The best tool for this practice is...

blah, blah, blah...

There is nothing wrong with these things. These are tools and techniques, often good ones, and they are not agile.

They do not generically combine, without context, into an agile process.

The Easy Way 

The easy and minimally effective way is to use this tool, technique or process.

Do it this way and it will solve all of your problems.

Standup is asking these 3 questions.

Here is the correct tool, technique and/or process.

You must use Scrum or Kanban or XP or or or

I have the answers for you.

Making people bad and wrong.

If you do not use so and so's 5 steps for retrospective you are doing it wrong.

Defining the right process outside of doing the work as if there is a generic context.

Release planning IS all of the stories organized by team and by sprint for the next n Sprints.

There is nothing wrong with these things, they may be helpful at times. These things are process consulting, not coaching and not agile.

The Hard Way

There is a more powerful way based on being compassionate, inquiring, being curios, discovering and being generous. You might call this leadership.

This is hard and it will require uncertainty and fear to be dealt with.

Getting comfortable with what is happening.

Getting comfortable with entering into an inquiry with curiosity and learning.

Developing our ability to discover and uncover better ways of working by doing and helping other do.

Discovering what people are committed to. What are they out create or do?

Helping them see when their level of performance in achieving the things, they say, they are committed to, versus measuring how agile they are, or how well they follow the defined process.

These things are not more right than the easy way. They are more powerful at allowing people to uncover and discover for themselves who they are and what they are out to create.

These things will enable people to become profoundly aware of what they say and what they actually do.

A coach will do this with compassion remembering what they had to discover.

A coach will be someone who remembers how painful it was for them to admit, to themselves, that they say one thing and do another.

A coach will remember how often they judge people on a standard they do not follow.

Where am I

I know I struggle with going back to the easy way.

To often, I encounter a situation where I sell out.

I turn back to being nice outwardly and thinking inwardly how bad and wrong you are.

When I see that in me, I simply acknowledge and get back up and go again... Often with help of my own coaches.

Where are you?

Tuesday, April 21, 2015

Manifesto for Blame Driven Development

Manifesto for Blame Driven Development

Performance Improvement Plans and Firing People over Resources and Interactions

Bug Triaging over Working Software

Personal Agendas over Customer Collaboration

Endless Debates over Responding to Change

That is, while the items on the right will give us a chance to succeed,
we value covering our ass over a possibility to do something meaningful.


Principles behind the Blame Manifesto

Our highest priority is to deflect blame for all problems
through early and continuous failure of others.

Welcome changing requirements, even late in
development. Blame processes harness change
for opportunity to delay commitments.

Deliver non-working software infrequently, from a
couple of quarters to a couple of years, with a
preference to the longer timescale or not at all.

Business people and developers must make
vague and incomplete requests of each other 
daily throughout the project.

Build projects around depressed resources.
Give them judgement and punishment,
and watch them squirm.

The most efficient and effective method of
conveying information to and within a development
team is domination and intimidation.

A high bug count is the primary measure of progress.

Blame processes promote sustainable employment.
The sponsors, developers and users should be able
to maintain employment for an indefinite period 
regardless of their inability to honor commitments.

Continuous attention to technical incompetence
and poor design enhances blame-ability.

Simplemindedness — the art of maximizing the amount
of useless conversations—is essential.

The best straw men architectures, incomplete requirements and aimless design
emerge from withholding information.

At regular intervals, the team reflects on who
needs fixing, then tunes and adjusts this person’s


Here is a blog post with an example of implementing Blame Driven Development.

Saturday, January 10, 2015

Accomplishment and Satisfaction Over Happiness

“Great things are done when men and mountains meet.” 
― William Blake

“You may not control all the events that happen to you, but you can decide not to be reduced by them.”
― Maya Angelou

The Challenge Accepted

Wow! No one had asked me about that tool in over a year. I was sure that no one was using it anymore, I thought to myself as I read the request to review a set of changes and update requests. A bit excited that something I had created was still interesting to others; I decided to take on the work of reviewing changes and updating the tool.

I was satisfied with the tool after I created it. Over time, my skills and the available tools have improved and the code looked very inadequate. That is me trying to be easy on myself. Of course, the inadequate area of the code happened to be the area I needed to update due to a deprecated API.

Continuing despite how I felt

It took me a day to recreate my desire to update the code after looking at it and feeling frustrated about it's state. I was definitely not happy!

Once I started working on the code, I was sure things would get better quickly and I would have it back to a state that made me smile. Nope! After an hour of working, I had completely obfuscated the code. So, I reverted it back to the original state to get the test working again. At this point I was feeling angry with myself and I definitely was not feeling happy!

This unhappy state was not due to an oppressive working environment. It was not due to anyone around me not doing their job and dumping all the hard stuff on me. It wasn't even due to terrible, buggy code, this code only had one defect reported by users and that was for a test case that did not exist when I released it. It was simply the emotions I felt as I went through relearning and dealing with the state of something that was not easy to deal with, mostly due to time.

Accomplishment and Satisfaction

The next day, I set all of those feelings aside and worked on updating the code. The first I noticed was there were things I did not need. The code that needed updating came from someone who required features I did not need so I deleted those parts. That made it much easier to deal with and understand.

The person who asked for the update sent me a link to a document that described updating from the old style to the new style and this turned out to be simple with the unused parts removed. After a couple of hours I was done and all the old tests still passed. I accomplished what I set out to accomplish and it was satisfying. I was happy for a while, as well.

Wes, why do you write this simple story?

It was been relatively popular of late to recommend people measure happiness to see how well teams and people are performing, especially in the agile community.  It generally works by asking question like the following:

  • How happy are you? (on a scale from 1 “very unhappy” to 5 “very happy”)
  • What makes you feel best right now?
  • What makes you feel worst right now?
  • What would increase your happiness?

NOTE: The implementation of the happiness index at Crisp had very specific intentions and a better wording than the generic one about. e.g. How happy are you with Crisp? vs. How happy are you? Though still using the idea of happiness, they also state in the blog post that "The important thing is not really the content of the A3 sheets. The important thing is how they were created, how they are used, and the fact that we now have an explicitly defined identity & strategy, which makes it easier to criticize and iteratively improve over time."

I have strived for happiness, and still do at times and seeking happiness in and of itself is never satisfying. If happiness was what I really wanted, I would not take on many challenges. The example I gave is quite a simple one that involved a few hours over 2 days. In other words, it does not compare to most of the bigger challenges in life I take on.

The intention people seem to have with the happiness index or metric is not my concern. The intent is usually related to creating an environment where people can achieve mastery, autonomy and purpose.

I have the same concern for an environment that allows people to achieve mastery, autonomy and purpose. In my experience happiness does not represent those achievements. This could be a simple definition problem for many using the term. e.g. languages other that english tend to have a broader selection of words that are incorrectly translated to happiness. The first meaning of happiness, from Merriam-Webster is:


 adjective \ˈha-pē\
: feeling pleasure and enjoyment because of your life, situation, etc.
: showing or causing feelings of pleasure and enjoyment
: pleased or glad about a particular situation, event, etc.

Maybe others are different than me, but my feelings, i.e. emotional states or reactions, change throughout the day and usually minute by minute. These feeling are always with me and often affect my actions, yet they do not tend to cause actions that lead to outcomes that move me towards mastery, autonomy, purpose, accomplishment or satisfaction.

In my experience, my feelings often lead me in quite the opposite direction of my intentions. They lead me to stop taking on challenges. They lead me to not do things I thoroughly enjoy. I get to the end of the day and I question why I wasted so much time, feeling sorry for myself, watching TV or reading social media, instead of playing the ukulele, writing down what I have learned today or creating something that solves a problem I saw.

I am not trying to call happiness, and my other feelings, good or bad, that is a bit irrelevant as they are always with me and I must deal with them. I am saying these are not the things to measure.

In order to keep happiness high or more likely return it to some 'acceptable' level, I will need to constantly input some type of stimulus.

I propose we replace the happiness goal with goals for:

Accomplishment: to achieve what we set out to achieve.


Satisfaction: fulfillment of our intentions

As with those experimenting with the happiness index, I am aware that these in and of themselves are not complete. I can easily see someone with destructive intentions using these incorrectly. The very definition leaves room for people to 'fail' because they do not define what we are out to achieve nor what our intentions are.

In my experience, the possibility of failure is required for me to achieve those deeper intentions beyond my own happiness.

I have shared some of my experiences and I do not ask you to apply this to yourself. What would be much more interesting would be for you to look at your own experiences, which will differ from mine, and answer the questions:

Is happiness what helps you verify that you are heading towards your intentions or purpose?

Do accomplishment and/or satisfaction come closer to allowing you to adjust your path towards your intention and purpose?

Maybe there is something else?

Sunday, March 9, 2014

Shu-Ha-Ri Applied

Shu-Ha-Ri  Applied

edited: 2014-03-10 - grammar issues

The Issue

Shu-Ha-Ri and the Dreyfus model are very helpful tools I have used to help understand the point of view of a person I am working with and guide me in how I coach them. I am seeing a use of these models that concerns me and appears to hurt our ability to change more than help. These models are quite helpful at the individual level for a specific skill. Shu-Ha-Ri seems to always be described, in its initial context, as a relationship between teacher and student. Applying it beyond that without potentially significant changes appears to be an abuse of the model.

I intend this article for experienced coaches, change agents and change organizations and think that other individuals and groups with a global, enterprise or other large scope will find benefit in thinking about this subject. This article is focused on when these models are applied to a software organization moving towards Agile and Lean.

More background

Articles, such as this one by Rachel Davies have implied the models are wrong to apply for forcing someone to do agile practices. I tend to agree with Rachel on this issue and would like to expand on where I see the problem. The biggest issue I seen is when applied in a larger scope of people, team or organization, they seem to be misleading and guide us to treat knowledgeable people as overall beginners. The danger here should be obvious, smart people treated as beginners will be put off at best and likely fight against us.

Interestingly, when I read Alistair Cockburn's article, where he introduced Shu-Ha-Ri, he applied this to training courses. These can be targeted at individuals at a specific level. Books and articles as well can easily target and let people know who the intended audience is. Many people have no problem reading beginner material or attending a introduction class to start understanding a new skill or topic. These are all targeted usages of the models that allow the individual to choose to be a part of.

Jeff Sutherland also uses shu-ha-ri in guiding Scrum implementations. Notice that this is also a shu targeted at the Scrum Master. In the shu state, the ScrumMaster sets up the process, helps the team get to a sustainable pace with known velocity and uses the
Retrospective to introduce change that improves velocity. I disagree with the velocity target but I will use it as an example goal. In this description the scrum master is looking at the team, though the article seems to mix abstraction levels between Scrum Master level and team level. Sutherland could have said the Scrum Master doesn't allow them to vary the process but he does not. He does not say the Scrum Master tells the team to do practice X. Instead the Scrum Master guides towards achieving goal Y via retrospection. He might recommend a practice to help achieve goal Y if the whole team cannot identify a possible practice to improve the current situation but the Scrum Master does not dictate the practice.

Looking for guidance in helping an organization change

I think Sutherland starts to imply a difference in applying the shu-ha-ri idea in a larger context beyond the individual, we target goals and outcomes to a less mature group and guide them towards that. This is not the same as you do exactly the one practice taught by the teacher. I believe it is a bit more than simply a goal. I like the way Don Reinertsen states a similar idea, "decentralized control with decision rules". See the video LSSC12 : Decentralizing Control: How Aligned Initiative Conquers … 

Based on my experience organizations fight back against the absolute one way given by a enterprise or global level group. They often do so with the right intention. The group fighting back knows their context and see weaknesses in the one practice for beginners. Having the organization work at the shu level as a directive is where we lose supporters. We are not talking about people new to software development, shu in Aikido is someone completely new. It is a rare circumstance that we are talking about people that have not delivered software in the past. Agile and Lean are not the goals or at least should not be. They are mechanisms to help us think about the situation and see it more clearly. If we are guiding a team or organization we should be guiding them towards the goal. Let's assume for example, in the rest of this post, that the goal is delivering value more often to our customers and other stakeholders.

What does team level maturity look like 

I think I have jumped a bit far ahead and assumed we are ok with the idea that there are no shu level teams and organizations where the teacher gives them the one rule, way or practice to follow. So let's back up and look at what is implied by a team or organization being shu level at their primary tasks.

If the shu fits we are in big trouble

Maybe a shu level team is one that all members are at the shu level. Can they be at the shu level for their primary tasks of delivering software? Maybe, but this would be for such a short stage that by the time someone is invited in to help they have already left the shu state. If they stay at this state for any time at all they will no longer exist because the organization, product or team would fail in a way to bring a drastic change to the team or it would cease to exist. This seems like such a bad state to be in that it would be rare and could not last long. We really should not assume all teams are at this level and dictating the one way is not likely to fix this team. The team has to be changed in a more drastic way.

This state does not match my experiences. I have seen a team that really could not deliver but the organization caught this mistake relatively quickly and fixed the problem. I say team but it was an organizational problem where people were hiding the real state to protect themselves and it failed relatively quickly. In this state, they also did not ask for help. It was not until they had failed and realized the problem that they asked for help. They also realized most of their issues and it was clear they were not a shu team. When they admitted the failure the true level of people who were being silenced by the system came out and they new how to fix their issues with very minimal encouragement and guidance.

Maybe a shu level team is a team where all team members are at the shu level for a specific new practice. Would that make them a shu level team? Meaning, a team which we treat as beginners because they do not know a practice we believe would make them more effective. I am thinking of practices like TDD and Uncle Bob's idea of a foreman. My experience matches more with Jason Gorman's. It just will not work to impose these practices. In my experience teams will meet any metric you impose to verify it and will actually make themselves even less effective. If we want to call them a shu level team we will have very little success. I am proposing they are not a shu level team. They are likely far from a Ri level team but they are not shu. They have some experience and success at delivering software and we do damage by treating them as beginners. They are likely shu at TDD and they likely need to be challenged to improve their capability to deliver. In my opinion, this is different than being a shu level team.

Maybe a shu level team is a team with so few ri/ha team members that they cannot successfully guide the shu level members and keep them from doing more harm than good. This seems more likely than the first example of all shu level members. This team actually has an advantage and solves the problem faster than the mythical all shu members team above. The few ri/ha team members make this visible quickly out of fear of their own failure if nothing else. I have seen this team get the problem fixed relatively quickly.

For me the real issue is having a shu level team or organization is never what we need to solve. That shu level team or organization gets eaten alive by the market, internal or external, or they fix the beginner problem so quickly that we would never be asked to come in and help. If you think your organization is at the shu level ask a few questions about it. Do people know where they, the team or organization, is not very effective, at least in some areas? So far I have not seen any organization where people could not answer this question to some degree. Enough people to know that change was necessary at a minimum. All of these organizations are currently delivering software. I would put them at the compotent state in the Dreyfus model at least. They need and benefit from someone looking at what they are doing and reminding them of the goals. The need and benefit from someone pointing them to solutions they have not tried and influencing them to think about them. The need and benefit from someone guiding them in practices they do not have experience implementing. They usually need to choose those practices based on the goal discussion first. 

At this point I may not have convinced you that shu level organizations and teams are not who we are asked to work with. If I have not convinced you; then please keep testing to see if the one way is causing more good than bad and is change truly sticking. 


If I have at least convinced you that it is possible there are no important shu level teams and organizations, or at least you are not working with or for one, let's continue. Ri level organizations and teams are probably very rare and frankly unimportant. If you are competing against one you will not likely be in business long, unless of course you have the cash to buy them in which case you probably should. So let's not even worry about that.

Most of teams and organizations are at the ha level or Competent level. These are the ones that see the need for improvement. They likely have asked you to help them by using Scrum, Kanban, Lean, XP or some other change to make the more effective. Likely, they have even asked you to teach the one true way. There are ha level organizations it seems to me. Interestingly, they often even state in contradiction to their request to you, to teach
the one way and be consistent across all teams in the organization, that they do not want be prescriptive. What would lead them to say this? Maybe it is the fact that they see multiple activities and in many cases teams and groups with a poor vision of the goals behaving in a way that they want to put structure on. They often see that being prescriptive is not likely to work and yet they ask for it anyway. They have not seen how to achieve similar goals in different ways while dealing with conflicts between groups that deliver together. These are ha level teams and organizations that need to be aligned to a goal before any of these ways will make sense.  Once they have that, then they can be guided to practices and may even be willing to try a practice they are at a shu level to see if it helps.

We, as coaches and change agents, need to help them understand the goal and make that clear from top to bottom. Once we do that we can help them see with some minimal guidelines where they could improve to meet the goal. They will also see when they have a goal that is different and start pushing back on the system that is giving conflicting goals. Interestingly, until they see this conflict teams and organizations do not push back openly in a way that can get the conflict resolved. It is usually not politically safe to do so. They push back in a politically safe way that continues towards their conflicting goal while meeting a metric, in number but not value, that is meant to show direction towards a goal they are not trying to achieve.

When we start treating people like they are successful and knowledgeable, by asking their input on how to achieve the goal, we will find a better way to achieve these goals. We will often be asked how can that be done and give us the opportunity to introduce a new practice that helps them. They are more likely to be open to the new idea sooner if they have asked for help achieving the goal. They are more likely to spend the effort it takes to learn the practice than simply fake the metric. They are even likely to help choose a metric that helps them determine if they are getting better. The first XP team I worked on was this way. We had the opportunity to try something and we started seeking ways to do it even better. We learned metrics that helped guide us. We started to understand weaknesses and strengths of our own metrics. Teams that were forced to do the XP practices did not get the same benefits. Their builds were often broken, their test coverage went up in unimportant areas but met the targets. 

Most organizations will not allow Uncle Bob's foreman to control the code, it would have appeared significantly slower. They are still a ha level organization hiring more and more developers to fix a problem more developers will make worse. However, it probably would require a foreman to check everything in this forced 'treat the team as shu level' environment. Treating the team and organization as though they are a ha level team and they will start to see the trusts and reciprocate by helping the organization see the problems and find practices that help improve them.

Summing it up

When a team or organization has experience at their primary tasks it is wrong and dangerous to treat them as beginners. It is wrong because they are not. They need some time to choose the practice that moves them closer to a goal and learn that practice they are beginner at. They also need to see the goal in the bigger context. 

I really doubt you are working with or for a shu level organization or team. Is it possible, that we as change agents and organizations, due to our own level of HAness, are treating teams and organizations as if they are shu when they are not? Should we make sure we
are not teaching the one way because it is easier than dealing with people and helping them understand the goal? I know I need to think about this more often based on my past mistakes.

As always, I am seeking your feedback more than agreement. Please leave your comments and help me improve.

Friday, February 7, 2014

Who gets value

I was in a discussion earlier this week about user stories and one of my colleagues states that 'as a' was about the actor and I had an immediate allergic reaction to that statement. 'As a' should point to who is getting value no matter who or if they are anyone else is performing a specific action. As a user of many products, way to many organizations think I am actually interested in entering data or performing some action and have not thought about my need.

Give me something for nothing

Let me start with an example.
In order to respond quickly to my friendsAs a Facebook userI want to be notified when someone comments on my status

This story is hoping to benefit the person whose status is being commented on. The person acting in this case is a friend leaving a comment. The person getting value did not have to take an action to get this value. 

However, what if it is not what they wanted...

I don't want to use your form or enter data

Sometimes getting value does require the user to take some action. Most of the time the user does not want to act or wants to do as little as possible to get the value. Let me give another example on the same situation.
In order to avoid silly interruptionsAs a Facebook userI do not want notifications from certain people

In this case it is likely that this user will need to take action. Actions is not what they want however, it rarely is. They want to avoid getting certain notifications.


It is my experience that focusing on the actor often leads to solving the wrong problem or solving the problem in a poor way. Reminder: The user rarely wants to enter data. 

How many of your stories are thinking about the actor? Try rewriting your story to think about who the primary beneficiary is and see if that leads to a better solution.

It is also value not format

The format we are talking about is not very important. The important thing is are we thinking about who gets value, whose problem are we solving and are we solving it in a way that is simple and straight forward.

Sunday, January 26, 2014

Starting with Teams Requires Fixing the System

Being a part of Agile transformations since 2001 I have listened to and participated in several discussions about teams vs system changes. However, I am not sure these two things in and of themselves are different. If you start with teams, as most Scrum and XP transformations do, it is a system change in many organizations. Teams don't just magically happen because you put people together and tell them to self organize many changes to the system must take place.

Teams that stay together will be an early system change for an agile development environment to succeed. Quite often, this means financing has to change. Financing happens for projects and long term teams that last for the lifetime of a product or service is a system change that is likely to be met with resistance. Budgets are made to support x number of people for y number of months to deliver scope z. An organization must ask how is it going to maintain that software? How are we going to adapt that software to changing needs of it's customers? Who is likely to be most effective at maintaining that software, those who created or the junior maintenance team?

Teams that are cross functional are required in order to complete work every two weeks or less and is likely to run into several system issues. Teams in many organizations are dependent on design decisions from people outside the team, such as technical leads and architects in a global architecture team. Their ability to make decisions are slowed by late reviews and feedback leading to incomplete work each iteration. Teams in many organizations rely on a long lists of specialists such as architects, technical leads, database specialists and official build and deployments teams just to lists a few. The system will have to change to allow the team to do builds at will and deploy them to different environments. An organization will need to trust teams to build the software in a consistent manner? They will need to overcome the resistance of those teams currently doing that effort trying to protect the perceived loss of responsibility and the fear of losing their jobs. They will need to solve the problem of global architecture concerns and shared direction among teams that deploy into common environments while allowing the team to learn and adjust to the needs of the customer. All very difficult system changes.

After cross functional team are created it becomes clear that further improvement will require reducing the frequency that specialists are needed. This will again require a system change that requires overcoming fear of losing control and influence from those specialists. The benefits are good for everyone as each person gains a broader set of skill the organization becomes more agile. However, this apparent loss of control and influence is difficult to overcome in most organizations.

Teams that are focused on value versus projects focused on fixed budget and scope is another system change that is required in many organizations. Traditional systems are setup to expect a fixed budget and scope setup in advance. Agile says fix the teams and the budget and adjusts the scope to adapt to current needs and learning. The system will fight against and undermine the team making good decisions if it is not changed. An organization must honestly ask itself, with my fixed budget and scope projects in the past, did I get the things I wanted, needed or even originally planned? If not why? How long did we spend in discovery and analysis? When did we learn the most information that disagreed with our original assumptions? What do we do that really does have a fixed dates, such as compliance requirements, and how much of our work consists of these true fixed dates? Is software changes the only way to meet those fixed dates? This type of openness and honesty is also a system change in most organizations.

Teams that deliver as often as possible versus those who hand over testing at the end with n cycles of bug fixes is also a system change. Most organizations do not believe it is possible to deliver quality software quickly. Their experience likely backs up the assumption that software is very buggy early on. They may never have experienced a team that is focused on high quality rapid delivery, a team that is automating most or all normal checks of the system freeing time to dig deeper into possible limits of the system, a team that is collaborating so closely that all parts of the organization know what is being delivered and understand each direction change. They have experienced miscommunication, lack of trust and finger pointing between product, project management, development, testing, marketing and sales to look for who is to blame for the latest failed project. My experience says this trust is very difficult to overcome and will hinder teams until they can get quite a few wins under them. Wins that the system is, unintentionally, fighting against.

Teams are a system change in most organizations. Teams are not an evolutionary system change that you get in a Kanban environment, instead they are a chosen from the beginning system change that will bring fear and disruption. Don't fool yourself that you can start with teams and wait on system changes later. Creating teams will point out and magnify each of the systemic issues before teams become effective at delivering quality software. Start dealing with these issues before you create teams or you will likely lose many of the people who have the most knowledge and experience about the system and can help you fix those issues.

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?