A critical path for Agile software applications

Teams changing from waterfall development to a more agile approach are often struggling with the iterative and incremental development. Agile software development can be compared with building a pyramid. If you build your pyramid with the waterfall model (the classic way), the chance exists that the pharaoh dies before the pyramid is completed. If you build your pyramid on an incremental and iterative way, no matter when the pharaoh dies, he will always have a pyramid. The pyramid will not be completed like planned, but at least he has one.

Agile like pyramids

Agile like pyramids

The mindset/rule here is: make sure that if the project ends earlier then planned, you have at least something to give to your customer.

In practice

How would you do this in practice? Let’s say you have to develop a chain of screens with an interface to the backend (database, mainframe). For example a web store.

If you would apply the rule described above in this situation, at any moment in time, you need a partial delivered application which your customer can use. With a chain of screens is more difficult to stick to this promise. You cannot start with building your first screen and, when finished, the continue with your next.

When we look at the teachings of project management, we can learn that the critical path describes the longest path of planned activities to the end of the project, and the earliest and latest that each activity can start and finish without making the project longer. If we apply this principle to our chain of screens that need to be developed, we can select the screens on the critical path of the application: which screens (and according mainframe interactions) need to be finished first? When priority is given to the development of these screens, we know that in case of project mayhem the customer will have a solution he can work with or further develop.

What about work preparation, prestudy, analysis and design?

The principles of iterative and incremental work can also be applied to assignments other then actual software development. If you would need a prestudy, you can also execute it on a iterative and incremental way. The same applies for your analysis.

In this case, if the pharaoh would die earlier then expected, you would only have the blue prints of the pyramid. You cannot bury him, but let’s be honest: you have to start somewhere.

Tagged , , , , ,

2 thoughts on “A critical path for Agile software applications

  1. […] inspirational talks, blogs etc. For projects we create project charters, planning schemes, critical paths and status reports. For looking at results we create data, charts, interpretations and more […]

  2. […] can also be used to test the end project. With the Agile technique for example, they can be used in user stories, that is possible scenarios about the […]

Please share your thoughts!

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: