Innovation and Corporate Culture - Part 2

In Part 1, I promised I would get back to you on the results of a meeting I attended with the Oregon Innovator's Forum. As mentioned, the topic was "Innovation, Corporate Culture, & Getting Out of Our Own Way". Here is just some of the discussion that took place (thanks to Jon Marshall for providing the notes):

"Silos are a huge factor in this conflict of culture vs. innovation. I’m sure that silos must serve some function or they would have collapsed a long time ago. Is change happening in the appropriate place in the organization, and if not, how do we enlighten the organization or help the organization understand the need for the change to happen across the organizations?"

"Our company went from a startup to having silos. My perspective is that at some point in time, you can’t play that role of doing everything – there’s just too much going on. There are functions in the business and silos serve to organize and encapsulate these functions."

"I think there is specialization that you need to have. But what gets lost is that people lose the perspective that there is a cross functional aspect that you can’t have silos for . So we have to have a function that makes sure the right people continue to get together so that we can make the right decisions. I don’t know how you do it in a larger organization: we’re struggling with 100 employees. We have to remember to go back to not just saying IT will handle it because they’re the technology part, but that all of the employees can be a part of INNOVATING THE COMPANY."

"Have you had experience with that cross-functional piece?"

"When I came on board, the software projects were my department – we were the product development team. Yet we needed marketing involvement, we needed sales involvement, we needed technical support, we really needed every other area of the company to be a part of the product development process. What we found is maybe we did a really good job of releasing our product, but then the other pieces weren’t ready, we had some disconnects and things really weren’t working well. What we decided to do was we transformed our projects to work across the organization. That works for us because we have a cross functional team that’s not an outrageous size. This really worked because it broke down a lot of the barriers."

"So is there some generalization from that experience that you would offer to us?"

"I think innovation has to ultimately become an organizational cultural attribute. It’s not just IT or marketing, but the whole company has to be involved in creating innovation. The companies that have discovered that are successful at doing it."

"I’m interested in physics and in cosmology, the theory is the universe is expanding increasingly till it starts to rip into parts.The big rip. I think this is a great metaphor for what happens in companies as they grow. When you’re small, the average distance between any two employees is relatively small. As the company grows, if no one is paying attention, eventually you will form silos as essentially different pieces rip off of the whole. Like the model of the BIG RIP of the universe where communication ceases between the parts, the silos rip out of the whole and effective communication stops in many key areas. No one has to do anything to cause this, it is just a manifestation of growth where it becomes too much trouble to try to communicate across an increasing distance. When communication stops, the other parties essentially cease to exist for any given silo. One of the things I’ve been involved with is to repair these rips in the fabric of companies. Eg, the quality assurance department is not talking to the development department any more. They only see each other at the weekly status meeting. You always hear excuses on why that is. Too hard, too many meetings, too much work, too few people on our team.
But in reality, the communication in lining up the departments is almost THE most important thing. It doesn’t matter if your team comes in early or late if no one else knows what’s going on. Everyone else needs to be flexible to your improvements or your failures. Without that your going to fail as a team because someone in the fabric is going to fail. But if your organization remains in good communication and when one area starts to fail another group can pick up the slack, then you can survive the inevitable local failures."

"About the project team BEING the cross functional facilitating entity. Apparently companies are using project teams to be the thing that carries information across company silos and serves as an integrating force. But as you both were talking, it was occurring to me to suspect that we don’t have the right teams in a lot of cases. In other words, we’ve taken the minimum number of people we think needs to be on that team to get the project out the door, not realizing that secondary function of going across the silos; it may be that we need to significantly broaden out the teams.
One of the things we’re struggling with now is sales says “we’d like to help, but I need to get back to my job”. What we’re finding is that maybe we have to redefine what the sales position is."

These were some of the things said in the meeting around the challenges of innovating in the corporate culture.

By the end of the session, we realized that you cannot force culture to change. However, that doesn't mean that cultures can NEVER change. It just takes time. Where do you start? Changing the language. Telling stories. Getting people on board through small wins. It may take some time but before you know it the culture will change and people may not even realize it in the process. Get people to talk about innovation. Educate people on it.

By the way, if you are in the Portland area and are interested in attending the next session, please send me an email. The next session is scheduled for April 18th. I will be the moderator for this session (lucky me!). The topic will be on "Tools and Techniques that Drive Innovation". For more information, go here.

Going to a Lean Development Course - Update!

Next week, I will be attending a 2 day course in Seattle on Lean Software Development. The course is being conducted by Net Objectives and led by Alan Shalloway. I have enjoyed reading Alan's contribution to the Lean Development Yahoo Group and can't wait to learn more. Here is a synopsis of the class taken from their website (you can learn more by going here):

The software industry is looking for ways create quality code in an effective, efficient manner that is rapid, repeatable and reliable. Attempts such as CMMI and Agile methods have found some success but also seem to have some inherent drawbacks.

Of the many methods that have arisen to improve software development, Lean Software Development is emerging as one that is grounded in decades of work understanding how to make processes better. Lean thinking focuses on giving customers what they want, when and where they want it. It provides a way to maximize value while minimizing waste.

The varied background and history of Lean makes it very valuable to practitioners. However, the varied perspectives available from which to look at Lean sometimes makes it a challenge to learn how to apply it. This course takes four prominent perspectives of Lean and integrates them, creating a consistent, comprehensive view of how Lean can be applied to software development. These perspectives are:

Lean Manufacturing from Toyota (from Taiichi Ohno of Toyota)
Lean Thinking (from Womack and Jones’ work)
Lean Software Development (from Mary and Tom Poppendieck)
Lean Product Development System (from Toyota, as described by Michael Kennedy)

The course centers on how to create a fast, flexible flow of customer value-add. Principles of Lean that facilitate this are:

Eliminate Waste
Create knowledge
Respect people
Build quality in
Defer commitment
Deliver fast
Optimize the whole

The course teaches how to manifest these principles within the context of software development as product development. This is one of the distinctions of this course over mere agile training. Agile project management focuses on managing a single project and perhaps coordinating several projects together. However, true software development should be focused on the products these projects relate to. Selecting products, scheduling projects for the products, balancing product loads, are business perspectives that Lean addresses while agile methods do not. The focus of this course is on the mindset of Lean and the Lean-Agile Software Development process. The issues of architecture and how to evolve designs is only dealt with at a superficial level.

P.S. I found out about Net Objectives through subscribing to their Lean-Agile Straight Talk podcast. If you want to learn more about how Lean and Agile work together, visit their site. But just promise to come back here to learn more!

Update: If you are trying to implement Agile or Lean in your organization, you NEED this course! Though there are plenty of books on the topics, Alan did a great job of blending various experts and ideas out there and be able to understand the big picture. This isn't your typical training course however. We were able to have a lot of discussion among the group about our own experiences so far. Alan, being an Agile/Lean coach as well as trainer, provided a lot of good ideas for us to take back. It was like getting free consulting/coaching along with the cost of the course (which, by the way, at $1000 is a fantastic bargain). Check their web site for more details on the next courses as well as other courses in the area of Agile.

Values, Principles and Practices

When I was creating this blog, I wanted to make sure I had a tag line that accurately reflected what the focus and goals of this blog were to be. Here's what I came up with:

A manager's quest to improve his organization through Lean and Agile development values, principles and practices.


Technoetic had a post awhile back that I found to be a great representation of the overall goals - values, principles and practices. While some use these terms somewhat interchangably, I truly believed that each of them represented a particular piece of the whole. The author of this post apparently agreed with me and came up with perfect definitions of each of the parts. Here they are:

Values - A description of preference between alternatives. Often the alternatives represent candidate courses of action and the value guides the selection among the alternatives. Sometimes values are basically axioms. They can be irrational in the sense that we might not be able to explain them intellectually or they might be primarily based on emotions.

Principles - Statements describing a model. A scientific principle is a statement describing an aspect of physical reality. Principles might also describe a model of social activity, for example. Principles can be fundamental or logically derived from fundamental principles. It’s commonly believed that principles are derived from values, but sometimes people have certain values because of specific principles. For example, the “value” of communication can be derived from the principle that communication improves cooperation and coordination effectiveness. This circularity between values and principles can be confusing at times.

Practices - A pattern of activity that can be repeated to achieve goals within a context. A person defining a practice is applying principles within a framework of their values (preferences). A related collection of practices might be called a process or methodology.

To make it even simpler, I could summarize the difference between these as:

Values are the feelings of what the right things are for us to do.

Principles are the guidelines of how we are to demonstrate those values.

Practices are the actions of what we do to support those principles.

As I write future posts, I will refer to these terms frequently to describe the parts of both Lean and Agile. Before I went there, I thought it would be good for us to have the same context going forward.

Innovation and Corporate Culture - Part 1

This afternoon, I have been asked to join a group of 15 other innovators in Oregon to meet as part of a monthly Oregon Innovator's Forum. While I am honored to play a part, I am the first to admit that I'm not one of the top innovators in Oregon. That doesn't mean I don't have a lot to talk about in the area of innovation and my experiences around it.

I call this Part 1 because I hope to gain a lot of knowledge from the meeting to share back to this group (which of course will be Part 2). I believe that innovation can play a significant part in making Agile and especially Lean successful.

The topic for this session is called "Innovation, Corporate Culture, & Getting Out of Our Own Way" Here is a description of what will be talked about:

Have you noticed roadblocks to innovation that defy remediation?

Are you working around counterproductive business practices or systems?

Do you find that you can’t even talk about these roadblocks and awkward practices because the topics are taboo?

Then you’ve probably stumbled upon some immutable corporate cultural icons!

Please join other Oregon innovators for an informal discussion on how we can evolve the seemingly inflexible aspects of managing businesses so they better support the actual results the business hopes to achieve. The process of defining these stubbornly unyielding business practices can be difficult because your culture, like the water around a fish, is invisible. As participants in corporate culture, we do something a certain way because we think it is the only way, the right way, or at least the familiar way. These practices and systems then resist change when the business climate demands innovation.

Cultural inertia resists the changes that innovators attempt to invoke.

It's true that cultural inertia can provide certain advantages: No one wants to try to survive in a culture that is constantly changing—it would be too stressful and confusing. But here's the problem: when the “pain” associated with the current status quo becomes great enough, cultures look to their innovators for ideas on how to improve the situation. However, this hope for positive change often comes with an unconscious expectation that the “improvements” will only require minimum alterations to what we value in the cultural status quo: A “you can’t change that!” mentality.

Corporate culture thrives on the myth that issues which affect the entire company can be “thrown over a wall” to be fielded by people who will somehow handle the details by “fixing” things only on their side of the wall, with small impact anywhere else in the company. Unfortunately, that rarely works. One example where it doesn’t work is in the area of incentives for project teams. There is a growing body of evidence which indicates that providing incentives to teams produces more manageable and successful projects than providing incentives either to individuals or managers. But is your corporate culture is ready to hear that??

How do we turn this cultural Titanic around?

What are some corporate cultural icons you’ve bumped up against in the course of your travels and how did they need to change? How have you dealt with them, or how do you wish you could have dealt with them? How do we get out of our own way?

Bring your victories and war stories and let’s see if together we can shine a light on some of those change-resistant areas of corporate culture which might be blocking our paths to innovation.

I would like to hear from my readers on this topic. Please share via comments either your victories or war stories and I'll compare it to our discussion later today.

An Agile Approach to adopting Agile

Several years ago, we started our quest towards a better way to develop software. In the process I discovered Extreme Programming or better known as XP. Though I liked many of the concepts that I was learning about, I definitely had my reservations on parts of it. However, the largest reservation I had was that it seemed that the founders and proponents of XP were requiring that this methodology was an "all or nothing" type of approach. If you didn't incorporate all of XP, you really would not benefit from the results that others have had with XP. In fact, some would say that you might actually experience worse results than Waterfall with a partial implementation.

This worried me greatly because I knew that past attempts of trying to implement an entire methodology had failed. Why? Too much to take on too fast. What I found interesting is at least for XP they were taking a Waterfall approach to adopting Agile. Instead, why not take an incremental and evolutionary approach to the adoption? Start with the highest priority items, incorporate them, get feedback on their adoption, and made improvements as needed. Continue this process at a pace that your organization can handle. Ultimately deciding how much agile is enough for your organization at any point of time.

At the same time this was going on, I had an interesting discussion with a colleague. He had told me he hated the idea of methodologies. Why? Because it makes the assumption that you can go buy a tool belt full of tools and assumes that you will not only use all of the tools but will know which tool should be used for which purpose. His approach? Find the tools you need that resolves the issues you need when you need them. To better find the tools you do need to spend the time understanding what tools are available and how to use them. However, it is important to note that knowing and using are two different things. Just carry the minimal tools that you need to get the job done. His approach was much more Agile in my opinion and one based on adopting a set of Best Practices than adopting entire Methodologies.

I eventually found the answer to our problems. One of the "founders" of Agile, Alistair Cockburn, had a "methodology" called Crystal Clear. Unlike others, it really wasn't a methodology but a discussion on what practices are available from XP, Scrum, FDD, and others. He truly advocated the "cut-and-paste" approach, find something that is close to what you need and put it into your own processes. Then, make it your own! He also advocated the incremental approach, at least start with SOMETHING than it will take a life of its own. He focused more on educating the reasons behind each of the practices, and being able to sell it to others through your own adoption.

This approach allowed us to explore all other methodologies as Best Practices to find the right set of tools for our tool belt at a pace where it can be learned and truly understood. If you are struggling with Agile, chances are you are going too fast and taking on too much. Slow it down and take the Agile approach. Do only the minimum of what it takes to address the highest priority issues you are dealing with. Then tackle the next one, and the next one, and so forth.

What's funny is that the founders of each of these methodologies took the same approach. They started out with something, then realized that something else was needed until they came out with a set of "somethings" that worked for their particular situation. They found a pattern as they continue to implement in different companies, and thus they developed their particular methodology. They took the incremental and evolutionary approach. They customized it through constant feedback and changes to make it work for them - for their cultures, their people, and the technologies and products they were developing. You have to do the same thing in your journey towards adoption!

Though this approach, we have grown to appreciate what each of the methodologies bring to the table. However, we had to learn what we were missing to truly appreciate what we could get with each of the Best Practices. In other words, we had to realize that we needed a particular tool to accomplish the job much better than the tools that we currently had in our possession. Bottom line, most implementation of processes fail because of lack of understanding. Either understanding of why they are valuable or understanding of how they can be used for your particular needs. If you don't know how to use a hammer, and you don't know why you would use a hammer, you probably aren't going to find the hammer that useful. Think about that for a moment!

The Anatomy of a Manifesto

Though different forms of Agile processes have been around for many years, they lacked a common voice. There was even a debate on what to call these various methodologies - iterative? lightweight? evolutionary? agile? Many of the founders of these methodologies realized this several years ago and set out to settle differences and go forward in the same direction. Thus, the Agile Manifesto was born. According to the website, here is some of the history of that event:

On February 11-13, 2001, at The Lodge at Snowbird ski resort in the Wasatch mountains of Utah, seventeen people met to talk, ski, relax, and try to find common ground and of course, to eat. What emerged was the Agile Manifesto. Representatives from Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, and others sympathetic to the need for an alternative to documentation driven, heavyweight software development processes convened.

While the Manifesto provides some specific ideas, there is a deeper theme that drives many, but not all, to be sure, members of the alliance. At the close of the two-day meeting, Bob Martin joked that he was about to make a "mushy" statement. But while tinged with humor, few disagreed with Bob's sentiments that we all felt privileged to work with a group of people who held a set of compatible values, a set of values based on trust and respect for each other and promoting organizational models based on people, collaboration, and building the types of organizational communities in which we would want to work. At the core, I believe Agile Methodologists are really about "mushy" stuff; about delivering good products to customers by operating in an environment that does more than talk about "people as our most important asset" but actually "acts" as if people were the most important, and lose the word "asset". So in the final analysis, the meteoric rise of interest in and sometimes tremendous criticism of Agile Methodologies is about the mushy stuff of values and culture.

So, let's look at each part of the Manifesto in more detail. (You can read the entire Agile Manifesto and other related information at agilemanifesto.org).

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Just like the act of creating software is a discovery process, so is figuring out how best to develop that software in the first place. Agile recognizes that there is a constant need for improvement - not just in the software itself, but especially in how you get there. Through constant feedback from the team, and acting on that feedback, the team can own the process and make it better over time. This really goes against conventional thinking that management should control those processes to ensure that others follow them. The team owns how they do the work, the customer owns what functionality they want produced, and management owns how are we going to get there.

Individuals and interactions over processes and tools

There was a discovery that processes were becoming too heavy and that people were hiding behind those processes and the tools to manage those processes. Contrary to what some have thought about Agile, processes and tools in some form are used by all Agile teams. It's important to note that those should be in place only if they help the team produce better software more efficiently. In other words, they help you do your job better and with higher quality than without it. However, NO tool or processes should keep people from talking and working together. Project managers can't hide behind Gantt charts, they need to work with the team and talk about the progress of the project. Developers can't hide behind their tools as well, such as email, when their other team members are within distance to talk about things. The fastest and most effective form of communication is face-to-face, yet people tend to forget about it and use less effective forms.

Working software over comprehensive documentation

The goal for any software development should be to get the product out to customers as quickly as possible assuming that the level of quality meets standards. Just like tools and processes, if you are spending too much time on documentation when you could have the end product "speak for itself" than you are not meeting that goal. The code should be the documentation as much as possible. Conventional wisdom would say that customers should review and sign off of designs before product is developed, so that time is not wasted on being product the customer does not want. However, customers don't always know what they want until they see it. Paper cannot take the place of something more tangible. Once they see it, customers want to play with it, mold it and make it their own. Therefore, release often and early and provide the ability to respond to the customer using the working software product as the tool. We aren't talking throwaway prototypes here or "smoke and mirrors", we are talking software that works for the functionality that has been provided at the time.

Customer collaboration over contract negotiation

Think about past projects that you may have been involved in. How was the relationship with the customer? How much were they really involved throughout the project? Too much? Too little? Wish they were there? Wish they weren't? Most people would say that the relationships have usually been strained at best. Traditionally, most customers are involved primarily at the start and end of the project. At the start, they are asked to provide specs whether or not they understand software and how something should or could work. They are asked to provide EVERYTHING they can think of because the scope will be frozen for the remainder of the project. They are asked to SIGN IN BLOOD before the team will start development of the product. They are asked to refrain from any changes because they will cost the team especially late in the project. However, that is when most customers finally get a chance to see the real results of the project. Because many of these projects are already late, the customer "lives" with the end result most of the time (even though they know it isn't meeting their needs). Ultimately, either functionality is never or seldom used or there are future projects to redo a major portion of the developed product. And the vicious cycle continues...

Would it be better if the customer felt part of the team instead of on the other side of the table? That they felt they were being heard and were allowed to react to the product while it is being developed? Wouldn't it be the best interest of the customer to know what is going on since they are investing a lot of money into the effort? Wouldn't the team want to make sure that they are producing product that the customer will REALLY use and meets their needs? Of course!

Responding to change over following a plan

If we are to let the customer "mold" the product, we need to allow changes naturally to happen. If the customer wants something, why shouldn't we provide it to them? After all, they are buying our product! If we aren't providing something of value to them, why would we even work on those things in the first place. Traditional thinking says it is important to stay on time and within budget. Agile thinking manages the scope of the project and takes time and budget out the equation. If you are building the highest priority things for the customer, let them decide when the product is ready to be used. Why should we decide it for them?

That is, while there is value in the items on
the right, we value the items on the left more.

Critics seem to miss this last statement, and it's a VERY important one! Agile isn't saying that documentation, processes, tools, and planning is bad. If fact, you will find a little of all of these things on a typical Agile project team. However, it is recommending that a little goes a long way and not to lose site of the things that are most important to be successful (which are the items on the left). Remember to do the things on the left first, then make sure the things on the right are necessary to further support the left.

Video introduction to Lean

The following video was presented by Mary Poppendieck on December 2006 at Google. It is called "Competing on the Basis of Speed". She presents many of the Lean concepts as it applies to software. I will dive into how I got into Lean thinking later, but thought this would be a good starting place for those unfamiliar with the concepts.