Instructions
The standard disclaimer is followed by instructions, which illustrate a few basic applications of the tools. Here we give instructions for applications of the lean toolkit within individual spheres of influence, in different size companies, and for different types of work. |
The 22 tools in this toolkit should be used to translate the seven lean principles into agile practices that will work in your organization. Many books and articles describe alternate agile practices and techniques in some detail. How you use these will differ depending on your sphere of influence, the size of your company, and the type of work you do.
Sphere of Influence
Lean principles break down barriers, and thus they work best when a senior leader champions them. However, they can be adapted and applied to any level of an organization. Senior management support helps, but it is not essential for lean principles to work. Instead of waiting for lean thinking to descend from above, use it to change your corner of the world. Practice the Art of the Possible.
Understand lean thinking.
Develop a clear idea of how the lean principles might work in your environment and what kinds of improvements they might bring about.
Create a coalition.
Find like-minded souls, especially among your peers, and form a study group. Create a group consensus about how to translate the principles into agile practices that make sense and will have an impact on your problems.
In the face of resistance, address the fear. Resistance indicates a perceived threat to a largely unconscious belief system, one that has no doubt successfully guided the organization in the past. A organization's belief system leads to actions that reinforce the beliefs, creating a self-fulfilling prophecy that tends to blocks out new ideas. Resistance is a sign that you have triggered a fear. This isn't all bad; it means you have injected a new idea into the system, which is the first step to changing the belief system. Recognize that resistance is a symptom, and the cause lies in the belief system that is being threatened. You need to uncover and address the belief system that underlies the fear. Of course, this isn't easy, because the belief system has no doubt led to success in the past, so it will fight back with many varieties of self-fulfilling prophecies. You have some help these days, because the belief in the fundamental validity of sequential software development is being called into question and has already been dismissed in highly successful product development organizations.
Accommodate with minimum waste.
If you can't eliminate unnecessary documentation and reports, do them at as high a level as possible. Try to keep your plan at the release level�you have to do that much planning anyway. Write summary documentation�if you write things that ordinary people can comprehend in a short time it might help keep people out of your hair. Write design summary documents for maintenance support only after you have finished your coding�otherwise you're going to have to write them twice.
In the face of indifference, get started.
If you are facing indifference rather than resistance, you might take this as tacit approval and simply start using agile practices in your sphere of influence. Or, if you have a small coalition of like minds, the group might develop a good story about how agile practices can benefit your organization, get a hearing, and ask for a chance to try things out on a larger scale.
In the face of support, act.
Don't let your sponsor down. Get moving!
Think big; act small; fail fast; learn rapidly.
Once you actually get started, use lean principles to implement lean principles. And good luck.
Large Company
If you work in a large company, you probably have an improvement program or two to deal with: Six Sigma and CMM are but a couple of examples. Realistically, these programs are probably not going to go away, so instead of fighting them, try to leverage them. No doubt these programs were put into place to cure yesterday's ills, and if they are causing you problems, it's probably a case of overcompensation.
Exploit Six Sigma.
There are two different flavors of Six-Sigma programs: one for production and one for development. The production flavor focuses on reducing variation; the development version focuses on ensuring fitness for use. Make sure your program is the one focused on development, and if it isn't, build a coalition and lobby hard to get it changed. Once you are using the right program, bring your development approach in line with customer expectations, emphasizing that change tolerance is a key customer expectation. Turn your local black belt loose on getting unlimited access to real customers, on assisting the customers to define and communicate what is really critical to quality, and on improving your testing capability. Find out how your Six-Sigma program incorporates the GE Work-Out concept and exploit that to move the focus of decision making to the development teams.
Work with CMM.
If you are dealing with CMM, recognize that each key process area (KPA) in CMM addresses a factor that has caused problems in some software development project in the past. Agile approaches effectively address virtually all of these factors in some way, and therefore a competent assessor should recognize a well-implemented agile ecosystem at CMM level 3 or higher. The approach may not be traditional, but it works. CMM is not supposed to dictate approach, but only assess if the existing approach addresses known software development failure modes.
Be wary of CMMI.
CMMI is slated to replace CMM by the end of 2003. Unfortunately, it is designed to cover many areas beyond software development, and thus it is based on a more general set of underlying fears, mostly ones that have arisen in the course of military procurement.
If you are faced with CMMI, we suggest you learn about the struggles of the U.S. military acquisition organization to become more agile. Over the past decade, a series of directives and regulations have attempted to bring the same lean thinking to DoD acquisition, which makes U.S. military logistics among the best in the world. In late 2002 Deputy Secretary of Defense Paul Wolfwoitz canceled earlier attempts and tried again to "…create an acquisition policy environment that fosters efficiency, flexibility, creativity, and innovation." He lists 30 principles and policies behind the new defense acquisition system. At the top of the list are many of the principles and tools found in this book: decentralized responsibility, processes tailored to each program, learning and innovation, reduced cycle time, collaboration, a total systems approach. Incorporating lean principles into the military procurement system practices has proven to be a daunting task. However, by tracking the efforts, you can come up with a good set of justifications for adopting lean principles in your organization.
Be careful with PMI.
The Project Management Institute (PMI) sponsors a certification program for project managers. PMI's teachings are based on the same theories as CMMI: namely, that work should be decomposed and tasks managed individually, that creating and following a plan is the essence of project management, and that scope control is fundamental. This view of project management tends to encourage local suboptimization. As noted in Chapter 2, "Amplify Learning," it often creates a downward spiral in managing the scope of a project: The harder you try to manage scope, the more scope customers require. While many good techniques can be learned in the course of obtaining PMI certification, its theoretical foundation tends to be incompatible with lean thinking.
Small Company
If you work for a small company, you probably are wondering how to put disciplines in place and where to find the time to do it. Discipline is fundamental to good software development, but the traditional disciplines of software engineering and project management are not necessarily the most effective approaches. Don't bring in a cure that will be worse than the disease.
Start with hygiene.
First of all, make sure that you have basic professional software development practices in place: a version-controlled code repository, coding standards, build automation, comprehensive testing, etc.
Hire the right people.
Hire for skill and experience. There's no substitute for capable people, especially if you work in a small company.
.Focus
Do not try to do too many things at once or to improve everything at the same time. Find the one unique thing that you can do better than anyone else and focus all of your attention on doing that very well. Collaborate with others to provide breadth.
Use Work-Out.
The original intent of GE Work-Out was to deal with the very problem you are probably having�not enough time. People usually know what is wrong with their work areas and how to fix things, but they don't have the authority or encouragement to make changes. Managers with the authority don't have the time. Work-Out is a forum that gives people the encouragement and authority to fix their work processes themselves.
Special Work Environments
Not all work environments are alike, but some pose more challenge than others. Here are a few ideas for adapting lean principles to some special environments.
Government contractor.
Government contracting is subject to public scrutiny. The benefits of lean approaches are often counterintuitive and difficult to prove to skeptics. These two facts make it challenging to use agile practices in government contracts. However, there is hope, because the U.S. military acquisition organization, along with several of its European counterparts, has come to realize that evolutionary procurement is a better approach. (See previous section on CMMI.) We can only hope that as iterative development becomes acceptable in military contracting, it will become more acceptable for other government agencies at the regional and local levels.
When failure is not an option.
Sometimes software can kill people if it malfunctions, and when that is the case, there are many regulations on how to assure the software is failsafe. However, even safety-critical systems can be improved with agile software development approaches. Generally a process that encourages safety evaluations periodically throughout development will be superior to a process that depends upon a one-time safety evaluation at the beginning of a project.
Embedded software and hardware control.
Whether safety-critical or not, software that controls hardware presents a testing challenge because the hardware is being developed at the same time as the software. Three strategies should be used for this kind of software. First, always build a hardware simulator to test the software as it is developed. Consider the simulator part of the software deliverable. Second, adopt concurrent engineering practices. Develop frequent prototypes involving both hardware and software early and often throughout development. Third, use set-based development, described in Chapter 2. Set-based development works like a funnel: Early in development there is wide tolerance for experimentation; as development proceeds the tolerances are gradually narrowed. This is particularly appropriate for embedded software, where tolerance for change will narrow as the hardware design is finalized. For embedded software, it may also be appropriate to increase process formality as development proceeds.
Global development.
Development teams will not always be located in the same room, in the same company, or even in the same country. Global development is a fact of life, and agile approaches must adapt to this reality. In Chapter 2 we discuss various methods of synchronization that maximize the communications in dispersed teams. When agile practices are used with global teams, use the frequent milestones of an iterative development cycle to keep people from drifting apart. Invest in collaboration support tools such as shared source code repositories and build systems, collaborative IDEs, and video conferencing. Instant messaging is very useful, but may require some adjustment of work hours when time zones are far apart. Finally, there is no substitute for getting people together in the same room, so plan on team member rotation, focused especially on sharing tacit domain knowledge.
Maintenance.
Agile practices rule in software maintenance departments. In fact, these folks are wondering why it took the rest of the software development community so long to figure out how to develop production-ready software.
|
No comments:
Post a Comment