Agility and robust processes

One thing that Christopher said once that I always find funny is that I read obscure publications so that people like him don't have to. Recently, I started getting the magazine Public CIO, for information technology workers and policymakers in government.

The current issue has two articles that are fully relevant to the topics of the creation and delivery of transformational programs, iterative planning and development, and robust processes as they concern government, more broadly than only the IT sphere, even though the magazine is about information technology.

The article "Agile Development Speeds Government Software Development" discusses a more iterative process for developing software. From the article:

Specifically agile development:

• Stresses collaboration and communication. Team members, customers and other stakeholders work together.
• Is highly iterative. Teams work in short development cycles -- perhaps two to four weeks -- and deliver a functional, tested software module at the end of each cycle.
• Is self-organizing. Agile uses formal processes but allows teams to govern themselves as much as possible.
• Emphasizes customer value. When customer requirements change, that's a normal part of the process, not a nuisance. Success is measured in value delivered, not in days ahead of schedule or dollars under budget.
• Encourages continuous improvement. After each development cycle, team members reflect on what went right and wrong, and propose improvements.

Agile development contrasts sharply with the development model known as "waterfall." Under that traditional approach, developers finish one project phase completely before moving to the next, cascading from requirements to design, implementation, verification and maintenance.

Waterfall development doesn't work well because humans can't predict every function and feature they will need in an application, said Scott Ambler, worldwide practice leader of agile development with the IBM Software Group. When customers see how software is shaping up, they refine their ideas. "If we go against human nature, we actually increase the risk," he said.

The other article,"Gopal Kapur: Six Secrets to Information Technology Project Management Success," is applicable to project management generally. The six skills are:

1. Process;
2. Skill;
3. Techniques;
4. (having) Tools;
5. Accountability;
6. Discipline.

You can imagine I like what the article says about process:

Process: It's a particular method of doing something that generally involves a number of steps or operations that result in a predictable outcome. The implication is that the actions have been tried and tested and have consistently resulted in a desired, successful outcome. Examples are financial due diligence before acquiring a business, the doctor's pre-op patient examination, the pilot's preflight check and the chef's proven recipe. Having access to a well defined process significantly improves the odds that a project will be completed successfully. Therefore, it's important that your project managers have access to a well defined portfolio- and project-management process that is followed diligently.

The specific steps involved in achieving a high process utilization rating are:

• define the process;
• communicate the process;
• educate key stakeholders;
• train project managers;
• check process utilization; and
• improve process utilization.

I think the weaknesses in planning (land use, transportation, parks and recreation, schools, libraries, capital improvements, health and wellness care, emergency services, etc.) that I write about ad infinitum in this blog result from a lack of appropriately focused and developed processes. It's not just a problem in DC, although the weaknesses in DC planning processes help me understand the broader problem.

(My joke is that working on planning issues in DC is comparable to dog years, each year is like seven...)