Mary Poppendieck

author
+ Follow
since Oct 04, 2006
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Mary Poppendieck

Jim Collins makes the point in his book "How the Mighty Fail" that when a company is in decline, the decline can be reversed, but ONLY by a new and visionary person at the top. I would imagine this applies to most organizations.
Lean is as much a management philosophy as anything. Some people use it as a silver bullet, and then it actually doesn't do much good. It has to change the way people think about what's important, about cause and effect, and so on.

Where you start almost always depends on where the organization is now.
Hi Latha,

I don't quite see why one should have to choose between quality or process. I think of process as the way you currently do things (not the way you wish you were doing things - the way you actually do things). Hopefully your current way of doing things produces high quality; if it doesn't, it needs to be improved. As you gain experience, you should constantly improve the way you do things; the way you know that you have been successful is that you have increased quality.

Quality is experienced by the customer; process is what you do to deliver that experience. In lean, customers are the center of the decision-making process. If doing something differently delivers more customer value, then that is the thing to do.

So, what are the main qualities to hire people to work in lean, or agile companies...or what agile team members should have in common in terms of professional and personal qualities.. how do i feel sure i'm getting the right people on board for my agile environment



In Fremont California in the early 1980's, GM had a terrible plant - so bad they closed it and laid everyone off. Two years later, Toyota and GM opened a joint venture called NUMMI, and they hired back basically the SAME people. But they changed the management style - dramatically. The plant went from having the worst quality and productivity in the industry to having the BEST quality and productivity in the US. Absenteeism (a measure of morale) and grievances just about vanished.

The people were no different - the MANAGEMENT simply had a different attitude. SO before you worry about what kind of people to hire, worry about providing good management.

I had a boss who told me this: "Hire for intelligence and attitude, and everything else will fall into place." That's about the best hiring advice I have ever heard.

what i meant by Traditional people in our context was Traditional workers, who do not want to know new approaches like lean or agile and terrified of changing anything they used to do in some way to another.



If people are terrified about changing their approach, either they believe that it is working spectacularly well and no other way could be better, or they are convinced that their management (or their system) will somehow find a way to punish them for attempting to do things differently. I would bet that to change an approach, the overlaying management expectations will probably have to be addressed. In other words, I am not willing to say the people doing the work are the problem in your scenario - the real problem is much more likely to be the overall work environment and the kind of behavior that it rewards.

Since you mention incentives, can you provide some thoughts on what you've found to be positive incentives?



I am not really talking about bonuses and pay plans when I mention incentives. I mean something more like what kinds of messages are telegraphed to people by the behavior of management.

Here's an example. On an aircraft carrier, a newbie sailor alerted his team lead that he had lost a wrench. A stray wrench is a dangerous thing, so the message was relayed up, and the entire deck was closed to take-offs and landings until the wrench was found. You can imagine how this made the newbie sailor feel! The admiral of the carrier called all hands on deck later in the day. He called the sailor who lost his wrench up to the mike, and then shook his hand and congratulated him for having the courage to report his missing wrench. He had the whole ship give the newbie a round of applause. You can imagine how THAT made him feel. And you can imagine that if another wrench was ever lost, every sailor on the carrier knew exactly what to do about it. That's what I mean by incentives.

Managers telegraph by how they respond to incidents how they expect people to behave. People know whether they will get kudos or punishment for doing something, and will act accordingly. It's these unspoken expectations that create the positive environment that you find at SouthWest, and that also create the negative environments that you saw earlier.
I believe that when you are developing a complicated software-intensive product, two kinds of leadership are essential - someone has to really understand the customer ans someone really has to understand the technology. I might call this market leadership and technical leadership. The leadership roles can reside in one or two people. One company I know of always pairs a brand manager with a technical lead when developing a new product. Another company has a senior technical person who also understands customers lead development efforts.

If there are two people providing market and technical leadership, they have to be "joined at the hip" so to speak. They must work very well and closely together. If there is one person, then that person really has to have both deep customer understanding and deep technical understanding, or find a partner to help out in the area where they don't have strengths.
On the contrary, Chapter two looks at a lot of software "fads", only to conclude that precursors of TDD and Continuous Integration have been around for a very long time, and these are most certainly NOT fads. We find that project management practices have come and gone over the years, but solid technical practices such as TDD and Continuous Integration have never gone out of style - and I don't expect they every will. Tools will make good technical practices easier over time, and they might go by different names and have slightly different implementations, but techniques to be sure you know you are building the right thing at all times are pretty fundamental to software development, I think.

A large portion of Chapter 2, including the section on fads, has been released to be posted on TechTarget’s SearchSoftwareQuality.com, but it hasn't been posted yet.
Hi Jeff,

For a developer who wants to know more, Jim Shore's book would be a good one, but Leading Lean Software Development is one to recommend to the managers in an organization which is starting off (or even well along) with an agile implementation. It tells them what is expected of them to help make the agile implementation successful. These managers don't need to know much about lean, agile, or even software development (although that would be helpful!) to get a lot from the book. If you have an environment where agile is working at the development level and you need to get more support from managers and customers, this is a good book for them.
Hi Jeff,

The introduction to the book can be found here: http://www.poppendieck.com/pdfs/LLSD_intro.pdf
Chapter 1 can be found here: http://ptgmedia.pearsoncmg.com/images/9780321620705/samplepages/0321620704_Sample.pdf

Jim Shore's book is a very good book, but it is aimed at a different audience - it has great advice for developers, teams, and team leads. Leading Lean Software Development is aimed at organizational leaders. Books you might compare it to would be "Outside-in Software Development" by Carl Kessler and John Sweitzer, and "Freedom from Command and Control" by John Seddon.

Mary, you said, Agile teams ALWAYS improve things, i see that agile teams or people should have certain qualities to be selected with to be with specific attitude and behavior to apply, or can the change be applied for normal traditional people and still give positive results in being agile team member?



I'm not sure what (or who) you mean by "traditional people". In my opinion, 95%+ of all worker show up at work every day wanting to do a good job. If the system they work in prevents them from doing a good job, or worse, actively keeps them from doing a good job, then they will shut down their internal enthusiasm and just do what they are told. The way to tap the internal dedication of people is to acquire a deep appreciation for the way the current system actually incentives people to behave, and change the way that system works. In the end, as a former boss once told me, "People do what you expect and what you inspect."

That being said, successful lean companies are very careful to hire the kind of people with the kinds of attitudes that they expect in their company. Southwest Airlines looks very hard for people that are outgoing and love helping other people. Toyota hires people who love cars and are dedicated to achieving the goals. And so on. It helps to have the right kind of people, but for the most part, if people seem to be acting in an unhelpful manner, I'll bet the structure of incentives is creating the problem.
If a project manager is an administrator who assigns work and tracks tasks, the role would not be necessary in lean development. Instead, a leader who understands the reason for developing the software and takes responsibility for delivering value that will be appreciated by customers is very important. A leader who helps the development team understand the purpose of their work and make good decisions at a detailed level is also very important. For many years, good project managers have provided this kind of leadership, and these project managers will continue to be relevant and will also know what to do to help ensure the success of the teams they lead.

If I take architecture as a tool to manage risks the user stories should define how much architecture I need in a Sprint.



I don't understand this. I would want architecture to precede thinking about what should be done in a sprint. I think of architecture at quite a bit higher level. What happens in a sprint is design, and there should be a lot of it, but a story would not generally "call for" design. Good design should be part of the professional competence developers brings to their jobs.

I'd be happier if the effort on producing bloated up-front system-level design (not architecture) was expended on better understanding of existing business rules, domain-level modeling, and transformation of needs into acceptance test specifications. Inability to communicate exactly what we should be building (and what we have!) is a far bigger crime in many places.



I'm with you on that. I believe that design of the code must happen throughout development, and should be done by the development team. There's a case to be made that xUnit tests are not tests at all, they are the detailed design of the code. Class-level design is certainly not architecture - architecture is an overall view of - as you say - high-level decisions that will be costly to change in the future. And even in this case, the more costly a decision is to change, the longer you should wait to make it. These kinds of decisions are often best done by maintaining two or three options for as long as possible and learning which one is best as the design unfolds.

I think of it this way: Several times I have had some new tile laid on floors in my house. Each time I call the same tile guy, because he is a really good designer. He looks at the floor, knows where to start laying out the tile so that it ends up centered in the room, with neither too large nor too small a partial tile on the edges. He knows just what to think about and what doesn't matter. In a short time with a bit of measuring and placing lines on the floor, he gets to work. I am always amazed at the result - the little details that I would not have considered all come out exactly right. This is hardly the architecture of the building, or even the room. But it is certainly design - and because I had a good designer lay out the tile, I can always see when I look at tile whether or not any design went into the tile laying.

Mary suggests that you define criteria how a request "is written". Those criteria have to ensure that a request is understandable. You need rules that ensure that requests are written this way. So, you can reduce the amount of communication.



Right. Some other group is handing off some information to you, and you are supposed to do something with it. What you are looking for is test-driven handovers. By this I mean that when someone hands something over to you, they know what they need to supply in order to make your part of the job possible. This is the "test" that the information must pass. If it doesn't pass the test, then you work with the other party to clarify what it is that you need from them to have actionable work requests. So instead of clarifying one instance of incomplete information coming to you, you clarify how information should look so as to be adequate.

As an example, Mike Cohn has a suggested format tor user stories. When stories are written in this format, teams generally find them actionable. If you get random or garbled information, then you would work with your information source to agree upon a format (maybe a user story format, a spreadsheet matrix, whatever) that will have the information you need to proceed. If you get a request in a random format, it fails the test, and you help your information supplier modify it to the agreed-upon format. At that point, you should have what you need to proceed. If not, maybe the format needs some improvement.

So the idea is not to fight fires every time you get confusing information, it's to create an environment in which fires are much less likely.