Principles of agile development (1)

1. “Early and continuous delivery.”

Business processes are ever changing (even during the course of development) and sometimes customers don’t necessarily know what exactly they want out of the system till they see it in action. So it makes sense that the earlier and more frequent we involve customers in the process the quicker customers will be able to provide feedback to the development team, this ensures that the system in development will closely follow what the customers need and hence a high quality in the final product.

Martin carries on and says “We strive to continue to deliver systems of increasing functionality every few weeks. Customers may choose to put these systems into production…” This putting it to “Production” part makes me ponder, if the release cycle from development to production are as short as a matter of weeks, wouldn’t the team be spending a significant percentage of its time dealing with deployment? Database schema might be changed in between releases to production, a data migration need to happen each time a new release comes out and put to production. The system maybe composed of different components to be deployed to different (sometimes virtual) environments, it can be a very tedious process if not managed well and/or not automated. There could be so much work involved in making each release to production and this may or may not justify making it to production at all.

2. “Welcome changing requirements.”

I remember from an interview that Ron Jacobs did with Martin Fowler, Fowler said something along the line of “During software development, change requirement would be the most painful things, therefore we should do it more and often.” I was like huh? Now I start to realise what he really means; systems we develop are there to create value for businesses and should follow business requirement and processes as closely as possible, we welcome requirement of changes because they close the discrepancies between the true business processes at the time and the processes the system is implementing and therefore bringing the system more aligned with the business.

However, in the real world almost all the clients (the ones I’ve had experiences with anyway) would want a fixed budget, fixed timeframe and fixed scope. They do understand but refuse to accept that out of the above three dimensions if two are fixed the third must be variable. However this is somewhat understandable, in a business environment, no one wants to commit to a contract that contains uncertainties especially surrounds what needs done, when it needs done by and how much it going to cost (the above mentioned three dimensions). In the services industry, the clients (the ones with the $) tend to dictate the contract (a.k.a. arm length transaction), in which the above three dimensions are specified. This makes it really hard to abide by this “Welcome changing requirements” agile principle without running at a loss to the service provider. It’s like keeping blowing up a balloon without worrying about if it’s going to burst at some point. Inevitably, there is always going to be a trade off, development team will have no option but to cut corners somewhere and it could well be the quality of the product; code reviews, infrastructural refactoring that’s deemed appropriate over time, sometimes even testing etc. So what’s the solution here? Should we only service cash cow clients and have unfixed deadlines, or do our team developers have to live on coffee, Vs or redbulls and slave past mid night every day? Or both the clients and we have to take a step back and compromise. What’s your thought on this?

3.”Delivering documents and plans are not counted true delivery.”

I think this is arguable. Ultimately, it’s the working software that delivers true business values (if at all). We should deliver software early and frequently. There is no point of slapping the clients with bundles of documents without accompanying the working software since there is no values creation whatsoever. However, documents can contribute to business values indirectly when accompanying working software. Various forms of UML diagrams (if kept up to date) can be a very good set of tools to capture businesses process that the software is implementing and a good means of communication amongst technical, business people or any stakeholders for that matter. But documents can be very easily over prepared, documents shall only be written up to the granularity that’s required by its use and purpose. There is no point of documenting each and every methods signatures in a class diagram if it’s only designed to be used amongst architects to communicate the overall architecture of the system.

Martin’s first law of documentation; produce no document unless its need is immediate and significant.



4 responses to this post.

  1. Posted by tokes on August 18, 2007 at 9:09 am

    Sun – great post. You point out some valid points that many of Agile protagonists don’t address. You’re right to question how, in the service industry (as opposed to product development), we can apply Agile practices. One of the main reasons these questions are not always easy to answer is that the Agile movement, for the most part, was created and continues to be championed primarily by members of the development community. How often have you read a blog from a non-developer that waxes lyrical over the merits of Agile? Why, if Agile is so great, aren’t our clients asking for it? Is it really because they don’t understand any better? I recently went to a presentation on Agile where the presenter recognised there was still a way to come before we can decide how to work with vendors in an Agile manner. Looking forward to discussing this with you further…

    P.S. There’s a great couple of articles on who to engage in agile projects in a fixed price world.


  2. Regarding “Welcoming Change,” you have identified what appears to be the contradiction between welcoming change and actually delivering an application according to a schedule. The short answer is that the triangle (scope, resources, time) still applies, so disciplined change management is necessary. The main difference with Agile is that it doesn’t reject change out of hand, but rather recognizes the need for some schedule flexibility due to the fact that the business continues to evolve, new and valid requirements are discovered, etc. Yes, you have a deadline, but there are always options. That said, Agile does not condone sloppy business practices that like bad requirements and perpetual refactors that result when customer can’t make up their minds. I recently wrote an article on this topic with some complimentary points that may interest you:


  3. Posted by nicole on October 3, 2007 at 7:01 am

    hi, how s going?thanks for the commend on my space.
    and i d like to keep in touch with you. even its been a long time that we havent seen each other. im going to study graphic design at aut in the coming year, i think that suits me.well, let me know something about u…:)


  4. Posted by Idetrorce on December 15, 2007 at 5:02 pm

    very interesting, but I don’t agree with you


Leave a Reply

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

You are commenting using your 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: