- Ten Practices for Applying Agile/Lean Software Management Principles to Other Knowledge Work
- Ten Suggested Lean and Agile Practices for Knowledge Work
Recently, I've been asked to help some teams apply Lean/Agile/Scrum/XP-like project management practices to knowledge work that is not software development. These organizations have seen Agile methods produce huge benefits in visibility, productivity, quality, empowerment, and motivation in their software teams. Naturally, they want to understand whether these techniques can be effective in other knowledge work activities, such as managing IT projects, developing user documentation, managing and administering data server farms, implementing marketing communications, managing HR programs, and the like.
According to Wikipedia, knowledge workers are "valued for their ability to interpret information within a specific subject area. They will often advance the overall understanding of that subject through focused analysis, design, and/or development. They use research skills to define problems and to identify alternatives. Fueled by their expertise and insight, they work to solve those problems, in an effort to influence company decisions, priorities, and strategies."
Clearly, software development is a core knowledge work activity, in that it both results from and creates new knowledge. This knowledge emerges in the valuable, tangible form of code and test assets, as well as in the invaluable, intangible asset of the new knowledge gained and carried in the minds of the knowledge workers themselves.
Agile development methods are designed primarily to release software development knowledge workers from the constraints of the deficient software process, management, and governance models. Given that they're proving to work so effectively, could these models, though designed for a different purpose, apply equally well in other knowledge work activities?
These techniques can indeed be applied. However, it isn't a simple, off-the-shelf application; many of the Agile practices, such as those centered around software coding practicescontinuous integration, coding standards, test automation, pair programming, and the likemay not be relevant in these contexts.
To apply these practices effectively, we must make some modifications and simplifications. However, before we do so, it's important to return to the underlying Agile principles. If they're relevant, we'll have a proper foundation for the Agile/Lean project management practice set that we can apply to general knowledge work.
Let's start with the motivation for making such a changea desire for a step-change increase in productivity, quality, and morale of the teams, with a resulting increase in market competitiveness. What enterprise wouldn't want to achieve that goal?
Principles of Agile: The Agile Manifesto
A few years back, I got bored with the "Mom and apple pie" nature of always beginning with the Agile Manifesto in any orientation to Agile, and I started to skip over it. That was a mistake. Later in the project, I would come to learn that my clients and I were not working from the same set of assumptions and core beliefs. The result was unnecessary friction and roadblocks, based on unexpressed differences in philosophy.
The principles of the Agile Manifesto are still the foundation for all Agile development today, and they apply equally well to other knowledge work. If we start with the Agile Manifesto itself and make only a one-word substitution (solution for software as noted in italics below), we get the following statement of principles:
- Individuals and interactions over processes and tools
- Working solutions over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Certainly the manifesto itself appears directly relevant to other knowledge work, but what about the important principles behind the manifesto? Again, no problem, for with a couple of minor word substitutions (again noted in italics), we get the following statement:
We follow these principles:
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable solutions.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
- Deliver working solutions frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working solutions are the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicitythe art of maximizing the amount of work not doneis essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Again, applying these principles to general knowledge work is no problemassuming that the subject enterprise really believes in these principles and is prepared to put that belief into action!
Principles of Lean
As if the Agile principles weren't enough to drive knowledge work, we have the entire body of proven Lean software, manufacturing, and product development principles and practices to apply as well.
Based on my experiences and in both Lean manufacturing and Lean software development, I suggest that the Lean principles in the following table apply directly to managing other knowledge work.
Applicability to Managing Knowledge Work
Focus on value
Focus on value delivery to the customer or end user. Understand and optimize the entire value chain.
Reduced work in process and inventory
Reduced investment in too-early requirements and documentation.
Minimize work in process.
Minimize multiplexing among projects and tasks.
Increased delivery throughput.
Reduced process overhead, compliance checks.
"Last Responsible Moment" decision-making.
Reduced cycle times
Deliver solutions in smaller lots (tasks, user stories, use cases).
Smaller and more frequent releases put working solutions in the hands of customers more quickly.
Cell-based teamwork, empowerment, responsibility, and accountability
Self-organizing, self-managing knowledge worker teams.
Increased cross-training with pairing and shared knowledge and assets.
Collocate all team members to the extent practical.
Entire team commits to delivering iterations and releases.
Build in quality
Teams are responsible for quality.
All work (solution increments) is tested work.
Apply test automation wherever possible.
Continuous process improvement
Teams are responsible for continually improving their performance with regular reflection and adaptation.