Agile Zone is brought to you in partnership with:

I've been a zone leader with DZone since 2008, and I'm crazy about community. Every day I get to work with the best that JavaScript, HTML5, Android and iOS has to offer, creating apps that truly make at difference, as principal front-end architect at Avego. James is a DZone Zone Leader and has posted 639 posts at DZone. You can read more from them at their website. View Full User Profile

Agile Methodology Mashups

  • submit to reddit

When it comes to how you approach software development, you don't get anything better than adopting an agile software development process. But how to apply this in your process can sometimes confuse people.

About two years ago I wrote an article describing the agile culture which contended that the main point of being agile was in the culture, rather than the process. With another two years of software development behind me, I still believe what I had to say back then.  After all the agile manifesto states people over process as the first principle:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotition
Responding to change over following a plan 

With that in mind, I believe that creating your own Agile Methodology Mashup is the best way to form some type of process around how you develop software.  If you're looking for inspiration on what agile methods are best to follow, there's no shortage of choice for agile methodologies. The most popular methodologies I have seen are eXtreme Programming, feature-driven development, scrum and lean software development.

A few years ago to be agile meant to follow XP - these days the fashionable approach is lean software. One thing they all hold in common is that they bundle a set of agile principles together, but there's nothing to stop you creating your own process from these. 

Speaking from my own experience, the practices that I have bundled together are as follows: 

  • Pair Programming
    Often frowned upon as a waste of people, there's no doubt that getting 2 people working on a problem gets a better quality solution out there as fast.  Technology has moved on since the idea of pair programming originated - the ECF project provides a way to collaborate remotely using real time shared editing.
  • Daily Scrum/Standing Meeting
    Another really simple practice is to have a 5-10 minute meetup every morning to monitor progress and to communicate across the entire team.  It's best to fit this is as a part of your day rather than consider it just another meeting. One person takes charge of the meeting to make sure it doesn't spiral off topic.
  • Kanban/Burn Down Charts
    It's good to mix in a visual indicator of development progress into your daily meeting. Typically all the tasks for the week are listed on cards on a board, broken down into categories. As the card completes one phase, it moves onto another. The category here is anything that makes sense to you - it could be the development stage (unit tests, design, coding, complete) or weekdays. Once things move along each day and you see some movement on the board, you know you're doing it right.

    It can also be useful to add in a color to indicate the status of a task or the entire project. For example, red could signify that the project is in trouble. If you use the indicators, visible to everyone else in the company, maybe someone else will dig in and help your project out when you're in the red.
  • Test First Development
    This almost goes without saying - but test driven development is the most effective way to develop software. You get the advantage of thinking through all the cases before you start writing code, and you have a suite of tests ready to validate your code against. This saves a huge amount of time in bug fixing, and typically will create well designed code (as testable code is usually modularised well).

In the end, I think your process should be a mix and match of different agile methods that enable you to develop quality software quickly and allows you to adhere to the agile manifesto. Do you have a particular set of practices you use in your process? Or do you follow one agile approach rigidly?




Kevin Rodrigues replied on Fri, 2010/01/29 - 12:04pm

Have followed the daily Scrum and Burn Down charts method. Having your tasks placed in a visual manner surely helps to check up on the progress and take action than having it on your computer.

Victor Nakoryakov replied on Mon, 2010/02/01 - 4:10am

Completely agree, James. There is no big deal in taking, say, SCRUM and defining it as holy grail with no rights to change. Introducing different practices one by one is much more easy among people who inherently avoids/afraids/resists changes. So agile development in a company could be introduced in evolutionary, not revolutionary way.

Alex(JAlexoid) ... replied on Tue, 2010/02/02 - 7:34pm

Agile is a culture not a process:

Kanban board and burn down charts are quite different concepts actually.

And on a side note, kanban is less restrictive and allows maintenance of released product in a more flexible way. SCRUM is a rather rigid approach, witch is good when developing a new product. There is a good comparison minibook of kanban and SCRUM on InfoQ (

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.