Agile Development, Project Management and Step 3 of 3 [Build]

Agility is not about doing complex things fast, it’s about doing simple things well. That’s why there are only seven days in the previous step (Design); it keeps people focused on the most important system features and requires them to come up with elegantly simple (instead of devilishly complex) designs that can be built in the 13 days available the Build step. Designing an elegantly simple combination of UI screens, processing logic and data model is the hardest part of developing most systems, not the programming.

In the first few days of the Build step a little fine tuning of the system screens and data model are often needed. The better the fit between the screens and the data model, the less code you have to write to manipulate and display the data, and the easier and faster your system is to build. This is because most business applications just do CRUD (create, read, update, delete) on a database of relevant information. So the built-in functionality of a relational data­base already gives you much of the functionality you need.

Apply Two Core Techniques to Get Things Done in the Build Step

When you know what the data model looks like and what the system screens and technical architecture looks like then you can design the software components (or objects) that will drive the system. A core technique called object oriented design and programming guides developers in designing the system. System designs specify the services each object performs and the data passed back and forth between the objects. An object can be a module of code written from scratch or it can be software brought in from a code library or it can be a whole other system.

Estimate the time to develop each module or object. Objects that are pulled in from other systems or code libraries don’t take any time to develop and objects coded from scratch should take between half a day to two days to program and unit test. If they take longer than that it means the object is a composite object that needs to be further broken down. Any object that takes longer than two days is just too complex. I’ve not yet found the need for such complexity nor have I seen a case where complex objects actually delivered the value they were supposed to provide (quite the opposite). The only exception is where an object is a whole other system – but that isn’t really an exception because that other system is itself composed of many smaller objects that have already been tested and debugged (this is services oriented architecture – SOA).

While some team members are drawing out the software object model another group is setting up the development and test environment. This supports use of the other core technique so critical to success in the Build step – system test and roll out. In addition to making sure all developers have access to the relevant hardware, operating systems and programming languages, there is a need to set up a test database using the logical data model and populate it with appropriate data. There is also a need to write test scripts. If you know how the system screens operate and what the data model looks like then you can write stories or scripts that put the system through its paces and test its functionality (this is test driven development - TDD). As objects pass testing they also get copied into a production environment so the entire system is already moved into production by the time

Continue Reading