Q4 - Glen Alleman

Q4 - You suggest Q4!

When I think of “being agile” it’s not about writing code. I did write lots of code at one time. FORTRAN, ADA. Realtime control systems, flight control systems, radar and sonar systems. Lots of enterprise system integration systems. But I moved on to managing groups and departments that did the writing. They were better at it than me. What I learned over those years, starting back in the late 70’s was that writing code and managing projects that write code are not the same thing, once you move beyond a room with your 4 best friends and the customer. There were projects in the defense business in those days, where the customer and I (two people) were in the same room. I wrote FORTRAN and he looked at the results and said, “nope that’s not it, try again.” But those kind of projects are rare now.

What became obvious after awhile was that the design-code-test process was flawed. Not because of the steps, but because of the granularity between doing something and getting feedback. I designed and built control systems early in my career. These systems control some piece of machinery that flies our swims. They use feedback to decide what to do next. The sample rate for the control loop needs to be designed to not under control or over control the device. Too much control and the device “oscillates.” Too little control and it gets lost. The design of the sampling rate is an engineering problem.

The design of the sampling rate for feedback in software development is an engineering problem. Two weeks in XP or 4 weeks in Scrum appears to be a sweet spot. But it is highly dependent on the problem being solved.

Our approach is based on getting feedback at the right intervals to “control the loop” within the error bands defined by the problem domain. But the critical aspect “being agile” is that the control loop and the data must have high fidelity. In order to have high fidelity, you must have accurate data. When someone says “oh I’m making good progress on that Oracle integration section of the project,” what does that mean? It’s meaningless. “Good” and “progress” have no units of measure. So the way out of this is to define what “done” looks like before you start working towards done. That’s what project managers do. They build a description of “done.” One that can be meaningful to all the participants. This doesn’t have to be a details plan. In fact it should not be detailed beyond your ability to define “done.” But “docking at Hubble, changing the wide field camera and connecting the auxiliary battery cable” is a description of DONE.

When the “agile” term “emergent” is used it is usually an excuse to not trying to define “done” in some analytical term. This is the key to success in deploying agile for project management. Never to confuse effort with results. In order to do that, “done” needs to be defined in some way that is measureable. The path to “done” can emerge, but if the state of “done” itself is emerging, then you’re on the “death march” project we’re so familiar with.

The unit of measure of “done” is the deliverables from the effort. This is why Scrum is a natural fit as a framework for developing software and managing the efforts of developing software.

The final concept of agile project management goes back to the core process of the Project Management Institutes Knowledge Areas. It’s a “test question.” If someone says “we’re doing agile project management,” then ask how are you managing: integration, scope control, time, cost, quality, the people resources, communications to and from the customer, technical and programmatic risk, and any procurement activities?” If the answer is something like “oh we don’t do that, we do Scrum.” Then they’re not managing projects they are developing software. They are not the same.