Another View of Lean Leadership

Joe Little from Agile and Business has an excellent post today called "Leaders, Managers, Bosses and Administrators". Actually, he focuses on what leadership means in the Lean and Agile world. He refers to the Poppendieck book, "Implementing Lean Software Development: From Concept to Cash" (If I had to pick one book to understand Lean as applied to software, this would be the one!). Here's his take on leadership after reading the book:

They [Poppendiecks] raise several excellent points.

1. A team needs leadership. Which is to say, vision. Someone to inspire and someone to help them put their hearts in the game. And keep it there.

2. The project needs decisiveness. If the team has too many leaders, and the leaders squabble about decisions, then the team wastes time. The team needs to know how it will make decisions. There is a trade-off between making the right decisions, and making decisions quickly.

3. Generally, the team needs to learn to make decisions only at the last responsible moment. So, much of the decision-making is about when to make a decision. At what point have you learned enough to make a good/better decision?

4. The project needs business decisions and technical decisions. This is very true. So the team needs business people and needs technical people who are ready and able to make those decisions. And, preferrably, business people who understand technology and technology people who understand business (and the customers).

5. And there are many other types of decisions to be made too. People decisions. Decisions about whose insights to go with on specific areas. Process decisions. Decisions about who is working effectively and who is not. Decisions about how to get the team to communicate better and learn faster.

6. In Scrum, we have ScrumMasters and Product Owners. These roles are endowed with certain leadership aspects. This is different than the leadership of the Chief Engineer, which is a role Toyota uses.

7. Project managers have also provided leadership. (And we have the whole PMP, PMI thing, too.) PMs have also provided managership, bossiness, administration and other things.

8. We know that no bosses are wanted. We want all the best from every person, and a boss will only inhibit that. A boss wants to command others, and thinks he knows all. These are not helpful traits in a learning situation. (So, semantically, we are using "boss" here to represent all the bad things that a boss can be. Of course, few managers or leaders are as bad as a boss, but we all can be that way sometimes.)

Read more in Joe's post.

Growing Your Leaders

Alan Shalloway from the Net Objectives Thoughts blog challenges how Agile has viewed management and leadership up to this point in his post "The Need for Leadership in Scrum". Here are some highlights:

There underscores the notion that self-managing teams and direction from the top are somehow opposed to each other. In practice, this may be. But that is because in practice, leadership is missing. Direction in the form of command and control is bad. Direction in the form of vision and matching people to their abilities is not. This points to one deficiency I have seen in the general Agile community, and one that, I believe, is a serious impediment to having the Agile community have success at the enterprise level. I am referring to the fact that most Agilists do not trust management to do what is right – they feel the team must be protected from management. I have heard this opinion voiced in several books and from several leading agile consultants/practitioners – and I disagree with it.

Unfortunately, this attitude has been pervasive from the beginning of the Agile community. Given the heavy focus on over-bearing process that has gripped this industry for years, this is not surprising. However, it is time to include leadership and management in the transition to agile methods. We must see how we can marry respect for people (and hence the team) along with process. This requires leadership and proper management.

Buckingham, in his excellent book, The One Thing You Should Know describes leadership as the “ability to create a solid vision of a better future for those people he/she is leading. ” A leader must have a compelling desire to move towards that vision. Buckingham defines management as the “ability to match people’s tasks with their skills. ” A good manager is liked a skilled Chess Master. As opposed to checkers, where all the pieces (until one gets kinged) are the same, in chess, different pieces have different strengths. A good chess player knows how to use these strengths. A good manager knows how to maximize the strengths of his staff. Hence, leadership and management are not opposed to each other – they just have different functions.

Keeping Buckingham’s views in mind, the role of leadership and management then is to create the vision for the Scrum teams to be effective and to staff the teams with the appropriate resources. But just creating the vision is not enough. Leadership and management must help create the structure within which the team works to assist the team. This is something Scrum teams cannot do on their own. Ignoring this issue is what often has Scrum teams feel they must protect themselves from the organization when what they need to do is help the organization see how to better support the team.

If Scrum can’t help us here, what can? This is where Lean Thinking comes in. In a nutshell, Lean Thinking tells us to set things up so we can have fast-flexible-flow. That is, we can get customer requests in and get business value out – quickly and repeatedly. At Net Objectives we base our entire software development philosophy on this (which is why we call it SPeeD: Sustainable Product Development). The issue is – “how can I develop software quickly now (to deliver business value quickly) while retaining the ability to add business value quickly in the future.”

Read more in Alan's post.

In the book The Toyota Way by Jeffery Liker, one of the 14 principles outlined says "Grow Leaders Who Throughly Understand the Work, Live the Philosophy, and Teach It to Others". At the beginning of the chapter, there's an excellent quote that parallels Alan's frustration mentioned above:

Until senior management gets their egos out of the way and goes to the whole team and leads them all together...senior management will continue to miss out on the brain power and extraordinary capabilities of all their employees. At Toyota, we simple place the highest value on our team members and do the best we can to listen to them and incorporate their ideas into our planning process. -- Alex Warren, former Senior VP, Toyota Motor Manufacturing, Kentucky.

In summarizing this principle, Liker says:

If we look at all of the great leaders in Toyota's history we see they share several common traits:
1) Focused on a long-term purpose for Toyota as a value-added contributor to society.
2) Never deviated from the precepts of the Toyota Way DNA and lived and modeled themselves around this for all to see.
3) Worked their way up doing the detailed work and continued to go to the gemba - the actual place where the real added-value work is done.
4) Saw problems as opportunities to train and coach their people.

This doesn't sound like the ol' command and control type of manager works in this paradigm does it? However, managers are needed to provide Agile teams this kind of guidance. To do so, managers must respect team members as well as the other way around. Each have their place and need to understand their interdependencies in order to be a successful organization.

Go to the Source

In Lean, a key practice is one called "Go to the Gemba". Here's a brief description according to Wikipedia:

Gemba is a Japanese term meaning "the place where the truth can be found." Others may call it "the value proposition."

A Gemba visit is often simply called a customer visit. The hallmarks that make it uniquely useful are:
1) The purpose is firstly to observe, occasionally to question, rarely to guide or direct.
2) The visit occurs in the context where the product or service is used, which allows direct observation of problems that arise, workarounds that are applied, and capabilities or services that are never used.
3) Sometimes the customer (or client or user) is asked to describe what he is doing while he is doing it; this provides insight into the thought processes, which often reveal differences between the customer's mental model and the model of the developers or providers of the product or service.
4) The customer will often express wishes or needs while working in context that would be forgotten or suppressed in a different context such as a structured interview or sales meeting.

Common cases for a customer visit include:
1) Enhancing the features or usability of products (especially software) or devices (especially ones aimed at very broad or very niche consumers).
2) Improving processes or tools.

I think this describes the primary use of this practice, but I can see other uses as well. Here are some other sources that should be considered as a manager:

Individual Worker - Look at each person. Do they have a significant role? Do they understand their role? Have they developed the right skills for the role? As a manager, it is your job to ensure that each person understands their purpose in the organization. It is also your job to encourage that person to continually improve how they do their work as well as increase their value to the organization. Management should make sure that the culture is such that each individual once they understand their role, have autonomy to improve it as they see fit.

Development Team - How is the team functioning? Are the processes and tools supporting the team or getting in the way? Are they communicating well? Working well together? It is crucial that the team are working in a way that work flows smoothly, there is little or no waste and everything the team does goes towards providing value to the customer.

Management - Does your management style support Lean? Do you understand what Lean is all about? Are you establishing a culture that compliments Lean? Are you a champion of Lean? Are you helping others understand it? As a manager, you need to be the experts of Lean and do all you can to understand what it takes for an organization to become Lean. If things are falling apart because people don't understand what they are doing or have gone back to their old ways, it is up to managers to educate and instill the self-discipline each person needs to have to make it successful.

This is an area that we are still struggling with but realize that it is critical to our success moving towards a Lean organization. We must "Go to the Gemba" and find the problems (and solutions) where the root source is to properly address. Otherwise, we are making a lot of assumptions that may not prove accurate. As the old saying goes, "When you assume, you make an ass out of you and me." It's important to base decisions on real facts than assumptions. Going to the source will get you to the right place to identify the facts. It's then up to you to figure our fact from fiction.

Early observations around projects

As my previous post may have indicated, we became focused on heavy processes around software development and project management. We tried to manage these processes around tools. We did have moderate success around projects. However, we also had some fantastic failures. Here were some early observations that I had with those projects. At the time, I didn't know how to resolve them but I was able to find some interesting patterns. Here is the list of my top 10:

1) Traditional Waterfall assumes that you can figure out as much as possible early in the process. What's ironic is that we also understood the Cone of Uncertainty, which states that the reliability of estimates will become greater as you move through the process. We learned that we couldn't plan or predict the unexpected. We could prepare somewhat through risk management but not necessarily prevent things from happening.

2) Shorter range projects (less than 6 months) were more successful in meeting deadlines than larger range projects. It seemed the larger the project the harder it was to stay on track.

3) Projects that involved internal resources outside of the Development group were more successful than projects that didn't. These resources included Sales, Marketing, Technical Support, Customer Training, etc.

4) Projects that involved some interaction with outside customers were more successful than solely internal representatives.

5) Changes were harder and more resistant to make later in the process because it meant reinvesting a lot of time going upstream in the process. The process assumed that you wouldn't have to do a lot of that. Because of this, we would deliver functionality that the customer really wanted something different with the promise that we would look at it in the future (but rarely did).

6) Because of that, customers and/or customer representatives would ask for anything they could think of whether or not they really needed it because there was no other opportunity to do so.

7) Most of the projects involved managers who felt they had to have control over the project - control over what each resources worked on, control over what the customers could have, control over what stakeholders should know. However, on those rare projects where the manager was more transparent, more accommodating, and empowered the team to determine how they do the work and what work they should do; we found that everybody was happier, more motivated and produced better results.

8) Tools to manage projects became harder to use because it assumed that the work breakdowns, dependencies, resources allocated would hardly change and that the only thing that would change is time. That was rarely the case, and project managers found themselves managing the tool instead of the project itself.

9) It was assumed that estimates were reliable from those that provided it. Therefore, all milestones were expected to be hit by the stakeholders even though how we had figured out the milestones was very uncertain. Projects that were similar to those in the past fared better than those that were different. Most projects fell into the latter category and involved either domain or technical experience that was new to at least one member of the team at any time.

10) Though we had documentation for things such as requirement specification, technical design, etc, we found that as the process moved along those didn't reflect reality. It became too time consuming for people to go back to the documents. Therefore, the working solution and code behind it were the only thing that people could count on. We had thought that documentation were be used as a reference for future projects, but instead weren't used. Also, the documentation wasn't always developed by the team but many times passed around. Therefore, there were many disconnects because of misinterpretation of the documentation. These disconnects caused many of the bugs and incorrect solutions that caused much fix and test cycles as well as go back and fix the incorrect solutions sometime after the solution has been provided to the customer through a production release.

Even though we saw these patterns, and knew that something was wrong with our processes and approach to both software development and project management, we assumed that we were using the processes or tools wrong. It took us some time to finally figure out that perhaps the processes and tools were the culprit.

We started to look around to see if others were experiencing the same thing. And, that's how we discovered Agile...

When processes were my passion

It's interesting what others will say when you start something new or describe who you are and what you do. I have really appreciated the support so far and thank those that have mentioned this blog. One of them (who shall remain nameless) referred to this blog being more about processes than people. Actually, as you will discover as we go along, while processes are talked about the emphasis will be more about what is around those processes. In other words, processes will not be the core of the discussion.

However, there was a time when I was a process junkie. As I have found with many managers in my industry, I came up the ranks. I started as a programmer, and my manager saw some leadership qualities in me and was looking for a manager to handle daily operations while he spent time focusing on future initiatives. One thing led to another, and I began my journey from the programming world into management.

I didn't know how to be a manager at first, so like I did with programming I looked to others for advice. I didn't go to school and learn about management. So, I looked at what others were using as "tools" in the industry. As I had done with programming, I had assumed that if I just find a framework it will get me much faster to becoming a good manager. So, I went looking for a framework.

After some searching, I found some frameworks out there that seemed to be prominent at the time (this was in the late 90s). In particular, I found SEI's Capability Maturity Model (now CMMI) for software development and PMI's Project Management Book of Knowledge (PMBOK). These were THICK books full of processes. I had thought I had died and went to heaven! I couldn't wait to take this framework and apply it right away. And I did just that.

In later posts, I will get into more details of how I think about these frameworks now. For now, let's just say it didn't go well. I quickly learned that you can't just push process on people, especially if you don't really understand the concepts, values, and principles behind those processes. I was looking for process as a short-cut as well as a way to have better control of things as a young manager establishing myself. Instead, I came off as a young, cocky manager who had no idea of what he was doing and in the process making life miserable for those around him. People who used to like me as a programmer thought that the manager job had gone to my head. And you know what? I started believing it myself.

I know there are other managers who believe that if you put heavy formal processes, procedures, policies, etc. that you will be considered a great manager and that things are so structured and disciplined that anybody can do that job. These are the managers who talk in terms of subordinates. I quickly learned that I didn't want to become that kind of manager. It really wasn't my style, and I needed to find "tools" that supported what my strengths were as a manager. While at the same time, allowing those that I manage to play to their particular strengths. Also realizing that whatever was to be in place for processes needed some flexibility for the unpredictability that the future brings and would provide an environment that would not stifle creativity and innovation.

So, am I the "process guy"? Not anymore, I'm proud to say. If you could put any label on me, I guess you could call me the "enabler guy". I figure out how teams and individuals can become better. If they are better, my job is easier. If they are better, the company is more successful. Now why wouldn't I want those things as a manager?