However, there is no reason to throw the baby out with the bath water. My belief is that planning and tracking are still essential to any project, regardless of the methodology.

I'm a seasoned Agile developer and PM and so I rarely use MS Project for anything other than as a very specific type of Visio.

However I still believe in a thing called Gantt …
http://blog.teameffect.com/post/Team_Effect_equal...

I welcome your thoughts on how this fits with your style of Agile management.

Regards

Jason

I thought your article was quite interesting, and as an Director IT who is trying to implement Agile development and a formal PMO at the same time, we’re definately struggling with how to pick the best tool set for managing projects in an agile context.

I have put a response on my blog (see URL) as I think that there are ways to use MS Project successfully in an agile context as long as you a) change the way you use the tooling to make it way more efficient (I have some suggestions on this on my blog); b) use GANTT charts at the appropriate level of detail (e.g. I agree that trying to put a bunch of micro-dependencies in your plan is overkill); c) use it more for macro-planning instead of micro-tracking.

See my blog post on the subject – would be interested in your experience and feedback.

All the best,
Chris Woodill

David’s suggestion is good, but let’s face it, applying this principle is strictly dark art. It requires A-plus judgment to know when “the last possible moment” is at hand or even when it’s approaching. In the fray of a complex project with team members bringing different perspectives, it’s really really hard to make those judgments well enough to achieve satisfying results. That’s my experience.

Any method (or set of principals, or whatever we call Agile) must be evaluated on its ability to produce results repeatably. When it comes to architecture, I believe that Agile is not there yet. I guess I am guilty here of pointing out a problem but not offering a solution. Heck, maybe we’re stuck; we have to accept that good architecture comes from really smart people and magical teams, and that’s it. I hope not, and I plan to keep thinking about it and looking for some effective practices.

One of the hardest things about trying to do upfront architecture well is that you are trying to lay the groundwork for solving a problem at a point in time when you understand the problem least.

Poppendieck talks about this in Lean Software Development, about having a short architectural sprint that touches enough of the application to help the team get a solid understanding of the problem space. I am in the middle of a sprint like this in my current project, and to tell you the truth it doesn’t feel as productive as my regular approach, but I’m going to stick with it.

I think some upfront architecture is frequently necessary, but extensive, all-encompassing designs are not helpful. A guiding principle in creating such architectures is to “make decisions at the last responsible moment.”

The post implies that the resulting architecture will be satisfactory — automated testing plus refactoring will take care of it, no need address it strategically. Well, from what I have seen “emergent architecture” often ends up as Rube Goldberg architecture. A little time pressure, slight team disharmonies, one or two weak team members, etc, and things can get pretty tangled up under the hood. Yet all tests pass.

I guess I agree with Julie that some strategic planning is needed. It’s not too hard to quickly grasp enough about an application to make some provisional architecture decisions and get started on some foundation and framing work.

Agile projects embrace Real Option Theory and its Lean/Toyota manifestation that says “make a decision at the last responsible moment.” So for example, resource allocation should be made at the last responsible moment and hence resource leveling in a plan is pointless.

Much of the task dependency graphing in a Gantt chart is a side-effect of resource allocation, which in an agile project isn’t done until the last responsible moment. Hence, it is meaningless to try and graph dependencies. And hence, Gantt charts are useless.

David

I appreciate the vast majority of agile principles, especially pair programming. I’m quite shocked anyone would be surprised this is not the most efficient way of doing software development. I learned OO that way (Smalltalk in fact) and still always learn something new when pairing. Even if I’m the one leading.

Refactoring is a fact of the software development life cycle. That is if you have any real size to the application.

Developing in iterations, good. Self-organization, good. Less project management, good. Fancy Gantt chart that doesn’t reflect anything actual but impresses the powers that be, good.

What I would like to argue for is some up front planning for all iterations. Drawing up building plans before laying the foundation. Not that these plans cannot be changed, but they need to be thought out in whole before beginning work.

In a game of chess, you must use both strategy and tactics. Strategy to set out long-term goals for the game. Tactics are immediate manuvers that take you toward the long-term goal. You have a plan. You’ve thought though how to get there. You are able to think through the tactics that will get you there. Of course, your opponent will throw some curves at you and you’ll need to re-adjust your strategy as you go on. But you always have a long-term plan. Your focus is never just the next move.

I guess I think of software projects the same way. You have to think it out beginning to end. As you move through iterations, things will adjust, but you have to work on the whole picture. Looking at only the requirements in any single iteration without regard for the end result will not get you where you need to go. Or at least that is the part of agile that I can’t comprehend.

For instance, I know I need to build a house. How can you start building the first floor without at least first thinking through the layout of the second floor? What if after building the first floor, we take a look at the second and find out the house needs to be two feet longer. I can refactor the first floor walls but it is going to take a lot of work. If I had just taken some time to think through the big picture, discussed and confirmed it with the powers that be, I wouldn’t have to move walls. Some up front planning and confirmation and my level of refactoring would be more like having to choose a different color paint or rearranging the furniture. Much easier and much less stressful.

In short, I argue in favor of knowing what your dependencies are up front. Because they are there. Even if you don’t have a Gantt chart to prove it.