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.

Integrity

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. 

Delivery

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.

Conclusion

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.

Friday, February 1, 2013

Moving Visibility and Measurement Up the Ladder

More visibility up the organization ladder

A couple of the benefits Agile has given us is adding visibility into team work and moving us away from individual measurements, as our primary way of measuring progress, issues, etc. For example we replaced individual tasks estimates with team velocity for forecasting completion. This visibility into the teams work and measurements of that works helps change a teams focus to how do we improve our ability to deliver value to our customer as often as possible. Measures of a team are not enough to help most organizations transform and learn how to deliver value more often. What we need to solve this issue are visibility to how the organization/system works and measurements that help management see where the system has issues so they can make these visible to the the teams to help guide them to make good team adjustment. This is where I see a great benefit in concepts, principles and practices from Kanban, system thinking, theory of constraints and Lean.

Agile visibility

Scrum/XP/iterative planning help a team visualize many aspects of their work. By looking at trends and collaborating closely teams can make incredible improvements. This type of working can also improve communication up and down the business hierarchy. However, many problems are outside the teams control and though the impact of those problems are made visible the exact cause and full understanding of them are not made visible. Management needs visibility and measurements to help them see where the system is causing organization and team problems.

Another issue is a team improving, yet not understanding their impact on other teams. Sometimes a team improving can slow other parts of the system down hurting the ability of the organization to deliver value sooner. It is also possible that management does not understand the impact a 'lower value' product has on a higher value product. Due to the 'lower value' of the product on its own a lower level investment in the product may actually slow down a higher value product. Management needs visibility and measures that help them improve how they manage the system. It is a change for much of management from managing people to managing workflow (paraphrase @alshalloway or @agilemanager??? sorry could not find the original tweet on this idea).

This visibility will also help teams understand what they need to do differently as well. If I do X it hurts team Y. How can we deliver and reduce the burden on other teams. How might we help other teams such that the organization can deliver value sooner.

System visibility

Kanban, system thinking, theory of constraints, and Lean ideas are a good way to see this higher level.

A Scrum team may see that their velocity is inconsistent which indicates a problem. Maybe that problem is something the team can fix, unavailable product owner, missing/weak skill set, no automated safety net, etc. However, when these are not the issues they may not know the full cause and more importantly managers do not have a good view to the cause of the issue. Add a visualization of the workflow across teams with WIP limits and now management can see that a team is waiting on another team. They can see a team is producing work that another team cannot integrate with until much later causing a lot of rework and defects for both teams.

Scrum teams may be effectively delivering each iteration/sprint but they cannot always see the effect of their work on others. If managers and teams are looking at the cycle time of work that goes across multiple teams they can make decisions to improve how the organization delivers.

Conclusion

Too often managers are pushing teams to improve some metric that is outside their control. This causes frustration and gaming the metric. Scrum gave the team transparency but the work of the manager needs to be made transparent as well. @agilemanager recently tweeted "I'd like to end focus on process and refocus on management (training).  is a management method not a process" Agile/Scrum/XP have visualization mechanisms and measurements that help teams see issues they control and effects of things outside their control and Kanban adds visualizations and measurements that help managers see what is the cause of the problems outside the teams control. I would also like us to move away from focusing on process to focusing on managing the work and finding the best way to deliver value. Lets move past just making team work transparent and measuring teams and make workflow and system issues visible to everyone and use the measurement trends to move us towards a common goal.

Monday, January 28, 2013

Collaboration Not Compromise Or Control

Why aren't we seeing the value we expect from our agile implementation?

Many of the agile implementations I have seen struggle with achieving the value they set out to achieve. One of the big reasons is we replace collaboration with compromise, control or some combination of them. Collaboration Not Compromise or Control could be another way of stating the agile value of People and Interactions over Process and Tools, I am not sure, this is a work in process in my mind. I believe collaboration is that 'thing' we are striving for that will give us the best chance at achieving the outcomes we are seeking. This wording comes from thoughts and ideas I have been reading from @alshalloway, @flowchainsensei, @drunkcod and others. Being that this is work in process please help me work this out and smooth the flow of this idea.

Most would agree control is not collaboration (I think)

Control is violence against the individual. It assumes the worst in others and seeks to minimize the effects of the persons expected 'badness' by limiting the individual as much as possible. @flowchainsensei has a great set of blog post on the ideas of non-violent communication at http://flowchainsensei.wordpress.com/.

Sometimes command and control can have some good outcomes but they are becoming fewer as complexity continues to grow. I believe it is also wrong to look only at one outcome and not its effects on people. Outcomes must be good to and for individuals if they are going to be sustainable. 

Compromise is (usually) not collaboration either 

Compromise is often the majority acting violently against the majority. A recent tweet by @drunkcod made the statement "Compromise is Latin for 'everyone loses'". We usually want compromise when we are not in control so that we get some say in how things are done. Compromise also means you give in to my ideas.  Compromise is someone giving in to someone else or someone else's ideas. Compromise is violence imposed on another person with the use of nice words. Putting it in another way, compromise is control via manipulating others to go along with you.

Control and compromise are not the same thing but quite often lead to the same poor results and are usually bad for people, individuals.

So what is collaboration?

I think collaboration can be explained in a couple of examples. I take the first example from an @alshalloway tweet, which occurred during a conversation about coming up with a set of practices that fit your context, "I've been saying this for a long long time. XP, Scrum, Lean, Kanban, hybrid (5>2)". If a team has the experience from all of these methods they are likely to be able to find a process that fits their needs and context. This is the type of collaboration we need, not only creating the right system to work in but also making other decisions. It is not compromise, though potentially someone with a strict we must do these practices this way may think it is.

The second example of collaboration comes from a common goal and set of principles. Collaboration is difficult to come to by when we only understand a set of practices. In the midst of the same conversation which turned to fixing dogmatic implementations of Scrum, @alshalloway made the statement "we don't (fix them) -they fix themselvs once they understnd what they need 2do. following practices not as good as understandin(g)".

It also requires the idea that we are going to make some prediction about the expected outcome of a certain set of actions and then adjust when we are wrong. When we are only implementing a set of practices, a few things hinder us from collaborating. The first is we are closed to other ideas. Secondly, everything that is not practice X looks like compromise to us. Thirdly, we have trouble looking at the outcomes critically and leaving open the fact that the practice we believe in is part of the problem.

Conclusion

Collaboration is where we can achieve good things. Don't get me wrong, it does not guarantee good things but enhances the possibility of good things happening. Collaboration is also a much better place to be in as a team member.  Collaboration requires me to give up control. It avoids violence by being open to learning from others, taking all ideas, experiences and knowledge and turning the combination into something better. It avoids the violence of control as well.

Thoughts?