Ten Suggested Practices for Applying Agile/Lean Software Management Principles to Other Knowledge Work

Introduction
Recently, I’ve been asked to help some teams apply lean/agile/Scrum/XP-like project management practices to non-software development knowledge work.
These organizations have seen agile methods produce huge benefits in visibility, productivity, quality, empowerment and motivation in their software teams. They naturally 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,

“a knowledge worker is an individual that is 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 have been developed primarily to unleash software development knowledge workers from the constraints and bounds of the existing, deficient software process, management and governance models. Given that they are proving to work so effectively, could these models, while designed for a different purpose, apply equally well in other knowledge work activities?

The answer is YES, these techniques can indeed be applied. However, it isn’t a simple, off-the-shelf application, as many of the agile practices, such as those around software coding practices – continuous integration, coding standards, test automation, pair programming and the like – may not be relevant in these contexts.

Therefore, in order to effectively apply these practices, we must make some modifications and simplifications. However, before we do so, it is important to first return to the underlying agile principles. If they are relevant, we will have a proper foundation for the agile/lean project management practice set that we can hopefully apply to general knowledge work.

Intended Benefits

Lets start with the motivation for making such a change – nothing less than 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 do that?

Principles of Agile – The Agile Manifesto

I must admit that a few years back, I got bored with the mom-and-apple pie nature of always beginning with the agile manifesto (www.agilemanifesto.org) in any orientation to agile and I started to skip over it. That was a mistake, as 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. That caused unnecessary friction and roadblocks, based on unexpressed differences in philosophy.

These principles are still the foundation for all agile development today and I believe they apply equally well to other knowledge work. If we start with the manifesto itself  and make only a one-word substitution (solution for software), we get:

“We favor:

•    “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 (noted in italics), we get the following:

“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.
•    Simplicity–the art of maximizing the amount of work not done–is 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, no problem whatever for general knowledge work, assuming of course that the subject enterprise really believes in these principles!

Principles of Lean

As if the agile principles weren’t enough to drive knowledge work, we have the entire body of lean to apply as well. Based on my experiences  in lean manufacturing as well as lean software development, I suggest that the following lean principles apply directly to managing other knowledge work.

Ten Suggested Practices for Applying Agile/Lean Software Management Principles to Other Knowledge Work

Based on this background in agile and lean development, I’d suggest the following ten practices that can be applied directly to knowledge work development.

# 1 – Develop and empower, self-organizing, self-managing teams. Energize with vision, mission and time pressures. Provide requisite creative chaos, care and support.

# 2 – Plan work in short (one or two week) iterations. Teams plan together and commit to value delivery objectives in these increments.

# 3 – Focus on value delivery. Apply user story form (“as a <user role>, I can <do something> so that I can <business value>) to help assure value delivery.

# 4 – Develop, single prioritized backlog of work for the team. Establish product owner (or product owner team equivalent) roles to manage and prioritize backlog.

# 5 – Apply, daily 15 minute standup meeting as a primary form of communication and commitment. (What I did yesterday. What I’m doing today. Whether I am blocked or not.)

#6 – Minimize work in process to increase productivity. Develop work in process limits to task and stories. Minimize multiplexing within time boxes.

#7 – Plan for delivery of larger enterprise initiatives in larger (release) time boxes. Engage stakeholder in periodically (approximately quarterly) planning, visioning and commitment setting. Make vision, objectives and commitments visible and public.

# 8 – Provide total, real time visibility. Build big visible chart to show work in process and individual and team responsibilities. Speak directly to facts and issues. Publish iteration and release objectives.

#9 – Develop shared knowledge. Institutionalize knowledge by pairing on tasks, projects and stories. Avoid over-specialization so work force can flex to backlog and resource bottlenecks.

#10 – Apply work physics and agile planning. Estimate and track time completion by story and task. Establish and apply team velocity (capacity of work achievable in a time box).

Summary

In this post, I’ve posited that most of the core principles of lean and agile software development apply equally well to other enterprise knowledge work projects and activities. As a basis, I recapped many of the agile and lean principles with a bit of a knowledge work-spin. To get things started, I’ve also provided a set of ten suggested lean and agile practices that an enterprise can apply to non-software development, knowledge work activities. I believe that you will find them to be unambiguously good, and will help you achieve many of the benefits – including improved productivity, quality and morale – that every enterprise covets. Feel free to “try these at home”.