Agile Thinkers

Q1 - Glen Alleman

Q1 - Hi Glen.  I think I first met you either via a comment you put on my blog or on the newgrange project management email list.  Anyway, it's been a long time but since we live worlds apart, we've never met.  Here's what I think I know about you - you're a big hitting PM, with a strong history in aerospace; you live somewhere sunny; you like cycling; and, you're a fast typer.  How close is that and what did I miss?  Can you tell us a bit more about yourself?

I do work in the aerospace and defense business, but those domains have large IT projects associated with them as well. Our firm – Lewis & Fowler - provide delivery services to commercial as well as defense clients.  Our approach to managing projects is called Deliverables Based Planning ® and is based on the principles of Integrated Master Plan / Integrated Master Schedule found in the US Department of Defense. This approach defines and measures progress through Accomplishments and their Criteria measures as 100% or 0%. Either you did what you said you had planned to done during these period or you didn’t. No partial completion. No almost done, or “I’ll catch up in system test.”

While I personally work in the defense side of software development, ERP, CAD, application software for ground systems, flight systems, and on orbit operations are common. Software development is still a large percentage of most defense and aerospace programs. But I also work in commercial domains. Mostly with ERP and Enterprise applications. These two domain have similar attributes – mission critical development, distributed teams, rapidly changing requirements, emerging technologies, and inconsistent funding sources. Agile as a principle provides a framework for “managing in the presence of change,” rather than the more conventional approach of “trying to manage change.”

One critical aspect of my work is the separation of “managing projects” from “developing code.” Many might say these are the same, and I actually held that view at one point. But it is not the case. The management of projects involves aspects that are not found in agile software development activities. The primary missing attribute is the discovery of the business value. Agile development assumes the “customer” can articulate this business value and use it to prioritize the work for the next iteration. This is usually not the case for larger projects. Therefore some form of Business Capabilities and the associated Requirements Management must take place. The next attribute is resource management. If there is truly a single team in the same room with the customer, then resource management is self managed. In the absence of this “ideal” world, someone needs to plan for the allocation of resources.

Q2 - Glen Alleman

Q2 - Our worlds collide in the Agile PM space where you work on BIG systems.  A lot of people reading this will, I suspect, struggle to understand the scale of the projects you've worked on and how they've influenced your thinking.  Can you tell us about some of the more interesting projects?

BIG likely has no real definition. What is BIG for a 300 person energy company here in Denver is small for NASA in Houston. What is small for that same energy company may be large of the 4 person wireless antenna company our neighbor owns.

BIG usually starts with multiple customers and multiple development streams. This usually means some type of Enterprise projects. Something used by everyone – or most everyone – in the firm. A Claims Processing system, an ERP system, a Document Management system. This also can mean that the “customer” is not really a person, but a process. The Land Management System in a mining company requires that all documents be managed according to the governance policies of the firm. “Customers” of Land Management have some, but not much say in how the system will work. Enterprise system are not Personal productivity systems. They belong to and are defined by Governance frameworks.

So when BIG is used, it may not just be the size of the code base, or the number of developers. But rather the impact on the firm’s ability to conduct its business.

For product development, Big usually means some kind of “system,” with multiple moving parts. A product where managing the interfaces between these parts is more important than the contents of the individual parts. The individual parts are important as well – of course. But if they don’t “play nice” together the product doesn’t work. This is the basis of the Systems Engineering view of software development and the management of that development.

Q3 - Glen Alleman

Q3.  Tom Gilb says a lot about "Systems Engineering".  So do you.  Can you tell us more about Systems Engineering and why it's been so influential?

Systems Engineering as defined by the International Council on Systems Engineering -  an interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem of operations, Cost & Schedule, Performance, Training and Support, Manufacturing, Test, and Disposal.

This paradigm integrates the management of the product or service with the development of the product or service. Product architecture and Program architecture are interconnected. Systems Engineering looks at the interfaces between the components first. This is a natural paradigm for discussing Coupling and Cohesion.

For Project Management and especially the management of agile software development projects, systems engineering provides the language and tools for making connections between the elements of a product in ways not found in the convention approaches.

The “tradeoffs” between system elements is the language of systems engineers. This implies the collective ownership, the shared code base, the “emerging” requirements now exist inside a larger “systems architecture.” Making it better – refactoring code – must consider the systems impact. The impact on the components that live behind the interfaces. So managing the interfaces – be they software or process – is critical to keeping the system moving toward its goal of being “done.”

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.