- To DSDM or Not to DSDM?
- The Right Way to Do It
- Lessons Learned
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
The Right Way to Do It
The other project, which was carried out for the same client by the same consultancy, was very successful. On this project, the client was encouraged to get involved in the project, and throughout most of the development process the client would visit to discuss progress on a daily basis.
A fairly thorough design was developed up front (including Entity Relationship diagrams, screen flows, graphical mockups, and written descriptions of the functionality) and the key concepts involved in the design were discussed with the client at length in brainstorming sessions.
Such discussions unearthed a number of misunderstandings about the way the client's business worked, which could have caused great problems later on in the project had they not been identified so early. This meant that some extra work was identified that had to be part of one of the iterations of development, involving creating some fairly complex scripts to enable the Web site's database to be updated by the client from his personal Access database. The design of the database was made flexible so that future client requirements, unearthed at these meetings, could be accommodated more easily.
Up front, the user was encouraged to produce a list of "desired" functionality and "essential" functionality. It was agreed that all of the essential functionality would be delivered in the first "timebox" (that is, by the first deadline) along with as much as possible of the desired functionality, and that anything remaining after that would be added to the list for timebox 2 (release 2).
It was also agreed that the first timebox would consist of several iterations of development:
-
The first iteration "proved" the technical architecture (IIS Web server, HTML, JavaScript, ASP, and SQL Server) end to end, with no graphics and little functionality.
-
The second iteration carried out a major functional requirement as defined by the client. The client came in and saw a demonstration, suggested an improvement, and then signed it off. At the same meeting, the client signed off the "concepts"—that is, the graphical mockups that the graphic designer had designed for the application, based on meetings with the client.
-
The third iteration provided a working system with the graphical mockups applied. At this point, the client was given the option of making three design changes only (to ensure that the project didn't iterate forever, and that the project did finally deliver a system). The client took advantage of this option and then testing began.
Just at this point, an organizational change meant that the client wanted more changes to be made. Because the client had already "used up" his iterations, it was very clear that changes at this point in the project would mean a deadline extension and additional payments; had the limit of iterations not been established earlier in the project, this change might have been a big issue. This was agreed upon very quickly and further changes were made to the system. The client then decided that he needed to change some of the graphics, but again this wasn't an issue because it was clear that more money should change hands—the client had previously signed off the concepts. A revised schedule was agreed upon with the client and signed off by means of a change request.
Unit testing and system testing were very thorough and very successful, apart from a few hiccups in putting the system into the mock "live" environment, due to configuration issues. However, because of the iterative approach and client involvement, the testing revealed that few changes were needed, so there was time to solve the configuration issues without extending the deadlines.
User acceptance testing found few defects but brought about a few change requests that were put down on the list of requirements (prioritized according to need) for the next "timebox" or release of the system. Testing was so successful that only two minor defect reports were raised against the system after going live.
At the end of the project, the client was very happy with his system and with the relationship he had built with all those involved on the project. He obtained all the essential functionality and all the desired functionality he had originally asked for within the first timebox, but decided to hold off on some parts of the desired functionality because the business wasn't ready for that functionality at that particular time.