Sharing Success

A recent project in which I was involved in was done in an Agile manner, which included getting in ThoughtWorks devs and BA’s as mentors and coach for the team. Just recently there was a PIR (post implementation review) and I thought it was worth sharing the results.
In a nutshell, the project was a success. The significant failures occurred in the up-front processes by trying to be too predictive (initial estimates were poorly done, giving incorrect information about project cost/benefits) and some of this filtered through to the rest of the project.
These were the general findings from the project:

  • Use of the Agile Methodology within the project was successful and well received by business customers.
  • End user involvement throughout the process meant that there were no surprises and the application was well received.
  • Daily stand-up status meetings supported open and effective communication within the project team.
  • Agile testing practices, such as the use of automated testing tools were affectively adopted by the project team.
  • Final code was of a high quality.
  • Successful knowledge transfer of J2EE coding and Agile development to Bangalore resources assigned to the project.

The following selection of quotes came primarily from the business sponsors and some of the technical review components of the project. It shows that doing a project well, even done technically well, can be observed by many stakeholders.
Some quotes have been edited which I felt were sensitive to my organisation, I’ve not done any creative editing to change the meaning of the quotes, just to sanitise for public consumption
“The project was very good at identifying and managing risks. Constant communication of these risks was imperative to the success of the team….”
“The use of Agile techniques, particularly test-driven development and full automation of testing allowed the project to deliver very few bugs and fewer design errors. Use of experienced Java developers and automated Java style checking tools … allowed quality to be measured. The same metrics collection occurred at each increment for defects. This project was outstanding from a quality perspective….”
“Due to the high level of business-technology interaction throughout the entire project, the quality of the final product was extremely high. There were no surprises to any of the key business stakeholders or the technical team.”
“Using user stories, and delivering them in two week development cycles meant the project had a very good understanding of how they were tracking, and what could be achieved in the timeframes. The project regularly made adjustments to either scope or resources to ensure that would meet the mandatory requirements by the fixed deadline.”
“Throughout the life of the project, the use of user stories made scope management a perfectly manageable task. It gave ownership of the project scope and deliverables back to the customer for prioritisation and delivery.”

Advertisements

7 thoughts on “Sharing Success

  1. Its good to know that yr Agile knowledge has done wonders for yr bank (employer)… 🙂
    As i have found agile is only suited for projects which have change of requests very often.
    But agile doesn’t suit for already predefined set of requirements where change of requirements are not anticipated, like a fixed price project. Which means waterfall model is fine and if there is some change of requests, than have some iteration cycles in addition to that. (Which i call Agile + Waterfall = Iterative).
    What will be interesting to know from yr experience is.. what was the size of team amd their development experience. Because one cricticism of Agile is that it doesnt scale well if team members are more than 10-15 ie; with large teams and requires senior developers (becuase design is not upfront and is evolving by each iteration…. and junior developers cant have that much insights).
    Vishal

  2. Agile is perfect for a set of “fixed” requirements. For 2 reasons. First, they will change whether you think so or not. Secondly, small increments give much greater understanding of the current state of the project.
    Waterfall model is a long way from fine for me. If you want to spend time doing up front design and documentation that _rarely_ survives the project, then more power to you, and I hope you work for my competition.
    Size of team was about 20 total people, many different areas for development, deployment, networking, hardware etc. The development team size was about 8-10. _Most_ of the developers were very junior. This caused significant problems (as it would with any project), but because we were doing an Agile, iterative project we were able to catch it very early (1 month in) and adapt by bringing in experienced resources to make the deadlines.
    One of the challenges for this project was that it faced a “hard deadline”. The business was removing a system, and this was part of that process. If this was held up, or delayed for any reason, then the costs to the business were significant.

  3. Hey Jon,
    Interesting read, although I do have a couple of questions that come about after reading that.
    First, how long did the over all project last? How much time was spent in design, construction and deployment phases?
    What are some of the problems that junior engineers cause to the overall project? Are these avoidable points or does it only come with experience?
    You state that the initial estimates were poorly done, were the costs benefits too well defined? or not enough defined? How does this filter through to the rest of the project?
    A good read for me, it is great to see from the point of a software engineer rather than a lecturer point of view 🙂
    ~Brendan

  4. Project was about 6-8 months start to finish.
    There was an initial 2 month “requirements” phase which was largely wasted due to changing business requirements/sponsors etc and I arrived at about this time.
    Design and construction were done every day. Normally there was a 1-2 day set of design sessions every 2 weeks (not full day, but team involved over those days) where design issues were sorted out, then the remaining 8 days were spent implementing those designs.
    Deployment at the bank is a laughable exercise in futility. It’s the single barrier to rapid deployment that I have. It’s in my sights to change in the next 12 months. We could build, deploy, unit test, system test all in an automated fashion in about 10-15 minutes for the entire system.
    All initial estimation was poorly done. The business case for the project was somewhat driven by external forces that I can’t really talk about. Needless to say there was compelling reasons to perform this task, almost regardless of the cost. The way this filtered through the project was an intial lack of trust in the development team as the early estimates were viewed as “gold”, and it took some time to re-educate the business that as we went further, estimates became more accurate.
    That’s always a political exercise.

  5. Yeah. I worked on that project and I totally agree with Jon’s comments. When the project started, I said to everyone that were are “Doomed to succeed because we are using Agile”. Given the tectonic shifts in scope during the project Agile saved us.
    Agile works. But you have to work to make it work. There’s a lot more to be done: junit, emma, cruisecontrol, checkstyle, selinium, refactoring etc. IMHO waterfallers are less disciplined than Agilistas because they get get away without these disciplines. (Leave testing to the end, right).
    Agile is all about discipline. Displipline in scope management, in increment management in dev and test.
    But the rewards are correspondingly greater.

Comments are closed.