Dean Leffingwell has a great post up with the above title. His approach and conclusions fit well with my Laws of Development. I realize I’ve never summarized them on this blog, so I will do that in the future. In the mean time, here’s a summary from Dean’s great work which is very  practical:

He offers that by replacing the word ‘software’ with ‘solutions’ in founding agile principle statements, they can apply broadly to other knowledge work like: training development, IT infrastructure administration, marketing communications, and HR management. He also recaps Lean concepts from manufacturing that apply more broadly such as: focus on value, reduce work in progress, reduce cycle time, build in quality, cell based work and continuous improvement.

He then suggests the following ten practices for broad knowledge work application:

# 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).

I’ll briefly comment on this list here, but again look for my summary of the laws coming soon. The most obvious thing I think he has overlooked as a practice is applying continuous improvement and reducing variability. Scrum uses the retrospective which could easily be added as a broad practice perhaps to #7. He combines two concepts in #6, limiting work in process and reducing variability of job functions or multiplexing. Addressing each of these head on might uncover additional value. I also believe the use of Kanban for #6 as a method for accomplishing the work in process reduction, a lean tool, is overlooked and should be considered for more multi-disciplined work. Instead he suggests a more agile approach of iterations in #2 with story point limits through a backlog and PO in #4 to limit work.