Discussion on:

The roots of agile project management

The points in the article are all valid.

Ideally one wants to design the back end data structure and programs to meet the needs. A great program and data design can quickly turn into a bad design when functionality changes and these are patched in fast.

I believe that a lot of large spec changes are preventable. The problem is finding good designers to pull out of the users the best possible design the first time. The notion that users know how to spec a system is just crazy. If they knew what they were doing they would not change their minds. We wind up paying enormous amounts of money to provide educational user experience in how to fail at designing systems.

You're right about End Users not knowing how to spec a system... however I would add that Developers have no idea either... until the End Result is agreed-upon... and the Business unit is well-informed prior to their decisions... meaning we need to do a little bit of education and guidance through the Business Requirements phase, and not simply to document the request word-for-word.

For the sake of abstract simplicity, I'll use mathematics.

Say you have two systems: We'll call them "3" and "4". The Business unit says they want to combine systems 3 and 4.

So you ask the End User whether 3 + 4 = 7 is what they want, they say, "Yes". Ah. But if you stop here, then you're just asking for trouble.

The End User may not know about 3 x 4 = 12, which would be a far-more productive solution. They come back to you later and say, "I want 3 x 4 = 12", and from their standpoint, it is no different than the original 3 + 4 = 7 request... but this now results in a Spec change on the IT side... simply because we did not ask the question:

You're asking for 3 + 4 = 7... would 3 x 4 = 12 be a better solution for you?

Far too often that gets interpreted as not bother with the change and then give them something they don't want.

If (who are we kidding, When) functionality changes durng the life time of a project. If you are Agile, you present a choice. You can keep going this way and muddle through till the next version, you can encompass the change instead of these, you can extend the deadline and the cost, you can even bodge at a cost to phase N + 1. If that isn't what is happening then you are not agile, you are simply leaping about putting fires out.

Damn

Sorry bin caught fire

Right where was I.

Agile project management requires agile business management.

I suspect only part of the problem is that users don't know what they want until they see it. We do a lot of upfront analysis to know what questions need to be answered and that drives the data. As far as the form layouts, those are 1) easily changed and 2) can be mocked up quickly.

To me, the real reason specs change is because reality changes. If you are trying to meet a market need or a future need, it will probably have changed by the time you get there, so you need to be able to change things almost as fast as reality changes. That's the real use of agile and also signals its lack of acceptance--only businesses that wish to meet reality on its terms find benefit of agile. For everyone else, it seems like you're asking too many questions too often and are being insolent to the wise managers who initiated the long death march project in the first place.

It's all waterfall or it's doomed to failure. You can call it anything you want, but you are still planning, gathering requirements, doing analysis, desgin, development, testing, deployment. You may do it one time or six, you may spend more time on one than another, but you're still doing it all.

Where IT people add value is the applying valid engineering princles to software and system engineering that allow us to replicate success.

Call it whatever you like.

.

Waterfall is not the steps in the process, it's that each one must be complete (effectively) before the next is started!

Try to keep up.

Rick, excellent posting. You make some really insightful points on the nature of requirements and how they invariably change and the customer never really knows what he or she asked for until they get hands-on. Agile methods are essential for projects that follow a critical path or have a high degree of human interaction. A hybrid approach, melding traditional project management methods with an Agile approach still have value in providing the context for the overall project.

during my past 12 years of experience: no matter how early we encounter the users to the projects, they would still fail if we didn't have highly skilled and experienced developers. The "skilled" here I am talking about is the skill to design the software flexible enough to be modified in a very short period; and "experienced" is the experiences to work with those clients who ALWAYS hand out useless ideas and material and create the mess during the development. In Taiwan, most of the clients tend to consider themselves highly intelligent but in fact knows nothing but creating bigger confusion on the business model. If we don't have the experienced developers who are capable to shut them up, no project can be delivered successfully.