Implementing Agile Projects: What's my ROI?

Last Tuesday (Jun 26th, 2011), Jim Highsmith, one of the Agile Manifesto authors and colleague at ThoughtWorks came to Dallas (DFW area) to talk at DFW Scrum.

It was a great evening (I guess around 100 people) with a good presentation and discussions - plus of course, since we are in Texas, BBQ!

I had a pleasure to talk to Jim before the meeting at our ThoughtWorks office here in Dallas discussing on various topics which was complemented by his talk later in the day.

After all the information collected and some thinking, here are some of the top points:

1. ROI

It is not simple to come with a simple way of measuring ROI when it comes to organization transformation moving from typical Waterfall (or other old techniques) project management/implementation to Agile.

I have seen numbers/stats that can justify it, but numbers is just a way of looking at the problem and they can be manipulated in the end.

There are arguments that can better support and justify an Agile transformation.

Jim gave 2 examples - which I think are excellent:

1.a. In a certain project (Agile), there was a list of 100 features to be implemented. A fictional conversation between the Agile Team (AT) and the Product Owner (PO) would go like this:

(AT) - Mr. Owner, can you give us a list of the 3 most important features?
(PO) - No, all my features are important. I want them all.
(AT) - We understand but let's begin with 3 for our first Sprint.
(PO) - Ok, let's pick features A, G, K.

During the planning of Sprint 2, the conversation continues:

(AT) - Ok Mr. 'O. First features almost there. Can you give us 3 more to implement?
(PO) - Well, now I think all of them are important.
(AT) - Right, but then again, we need the most wanted from the 97 remaining features.
(PO) - Let's do B, C and W.

After few iterations and around 25 top features implemented, the conversation would continue like this:

(AT) - Howdy Mr. Owner. Again, we need few more top features to be picked from the list.
(PO) - Oh well, I think we can stop here. The project has already the core functionalities. The remaining features are nice to have but we can live with as is for now. I have other projects that I can invest and that can bring me more return than implementing the remaining 75 features for this product.

Bang! That's your ROI. Now you can incrementally see your product and you'll stop once you reached the point where you want to stop. Plus, with Agile you'll be able to put your product in production much earlier than in a typical Waterfall (or RUP) project because at the end of each Sprint (typically 2 weeks) you'd have a working software, specially if you use Continuous Delivery (see Flickr exem ples) and you don't have to wait 6 months or a year before you have your entire book of 100 features implemented.

But maybe this still doesn't convince your CFO. Knocking the door of the finance team can be challenging if you don't have the right arguments. So...

1.b. Ask your finance team if they want 100% of the value for 100% of the cost or 80% of the value for 60% of the cost. Needless to say, the second option will be more palatable.

Also, negotiating incremental investment can be a better approach. Ask for a reserved budget but say you'll take it in parts. Then after some few Sprints, show the results and get the other part of the project financing and so on. Probably this will be much easier.

Financial responsibility is everybody's job so, collaborating and giving the right reasons to implement your project will help you and your organization.

2. Quality

One of the most interesting measurements collected from empirical data shows something very interesting while comparing typical project to the one executed using agile.

In a typical project, when adding more devs to the team the number of defects spikes - it can attributed to the chaotic code.

In an Agile project, the number of defects does not spike... it is kept under control. This gives more reasons to run projects using agile as if you need more velocity on features implementations, adding more team members properly will not crash your project.

3. Technical debt

This is a somewhat 'hidden' topic, which I don't see discussed very often but I lived it before.

As your software is developed, it needs refactoring, adjustments and bug corrections along the way.

Without Agile and Continuous Integration, one can be blind on the actual software state.

If I have a project that will run for a long time, I dedicate one Sprint after 'X' number of Sprints to deal with the Technical debt including old minor bugs, refactoring and general adjustments.

Using Waterfall or other similar approach, you won't be able to see through the implementation and the technical deficit will be accumulating until the end of the project and it is very likely that you'll have in your hands a typical "Software Monster"(I just defined this :-D ) that can be easily identified:

- Nobody wants to do maintenance on this beast.
- Needs major refactoring.
- Monolithic.
- Many features are useless, unwanted or outdated.
- If you are a dev and you're assigned to "re-factor" the Software Monster, you know it is a career sink.

So, avoid the Software Monster and technical deficit by implementing what will be useful and will bring value using Agile.


4. Features implementation and Outcome performance

Agile teams will deliver more value (working useful software) sooner. You can give the software to your customers to use as soon as you reach the minimum amount of features.

Delivering the value and the most wanted (working) features will give you the possibility to get users sooner, "test the water", get feedback and improve your product in a much more efficient way.

Perhaps you'll find that the next 'N' features to be implemented look very important to you but based on the current product usage, the main focus should be in another set of features or area that were not important to you.

5. Conclusions

Many organizations are still considering migrating their project teams to Agile and are stuck in slow, costly and old approaches.

The value of Agile is clear to me but I also recognize that there might be resistance to change because of many organizational reasons.

Overcoming this resistance and correctly implementing Agile will not come in a snap. It will take time and maybe the best way of getting beyond the chasm is taking a pilot project with proper guidance :-)

Installing Mingle on Ubuntu

This tutorial will guide you through the Mingle installation on Ubuntu. Also, I will assume that you have some familiarity with Ubuntu (Linux…); Java must be installed on Ubuntu prior to begin this tutorial.

1.     Downloading Mingle

Access the URL below and follow the instructions to download Mingle.

http://www.thoughtworks-studios.com/user/register&destination=forms/form/mingle/download

You should receive an email with download instructions. Follow the URL sent to you and download Mingle. We'll continue the installation after few previous steps.

Keep the email for later use. It contains the license information

During this tutorial we'll be installing Mingle on Ubuntu. Other platforms should follow a similar pattern.

Another easy option is to download the VMWare version. If you already have VMWare player installed, it would be a great option, as it will save you some time.

If you desire is to learn more about the details of the installation then let's continue our work.

2.     Downloading the database

Following the recommendation from the Mingle download page, we now should download one of the supported databases (Postgree or Oracle). Here we'll use Postgre 8.4 for the Ubuntu Linux Platform:

http://www.postgresql.org/download/linux

Following the link for the graphical installer, we select the desired platform:

3.     Installing the database

After the download is completed, verify if the file needs to have the permitions changed to be executed and change using chmod if necessary:

In order to run the application you'll need to use sudo, as shown below:

The installation will begin:

On the next screen, choose the location of your installation:

Here I chose to install it under my personal user folder. Observe that I created a CI folder where I want to keep all the software related to my continuous integration environment concentrated (just my personal preference).

Similarly, for the data storage, I picked my choice for the folder:

In the next step, enter the password (and don't forget it!).

Then, pick the port (here, I left the default). If you want to change it, go ahead but then again, remember it for later use!

In the next screen, I accept the default options for locale:

After capturing all the preferences, the installation will finally begin:

The installation will proceed…

Until it completes:

If you want to install other items (not necessary for this installation), keep the "Launch Stack Builder" checked, otherwise remove the checkbox selection and finish the installation.

Postgre installation usually already starts the server.

After the installation, if you're using Ubuntu, you'll find the Postgre menu from where you can start or stop the DB. Also you'll find a handy admin tool if you want to access the database directly.

We have to create a database for Mingle so, open the pgAdmin tool and login. Expand the three and on the Database node, right-click and select the "New Database" option.

Enter the database name and hit OK.

In the end, you'll find you'll find your newly created database.

4.     Installing Mingle

Now that the database is installed, let's continue with the Mingle installation.

Locate the downloaded file. It is probably a ".tar.gzip. Unzip and untar it:

At the end, you'll endup with this the mingle directory:

I'll move my Mingle directory to the same place where I have my Postgre:

Go to the Mingle directory, copy the sample properties file to the config directory. After, rename the file copied file to mingle.properties as below:

5.     Starting the server and configuring Mingle

We'll start the Mingle now and as pointed initially, Java will have to be installed. If Java is not installed, you'll get a message like:

To start the server, navigate to where the file "MingleServer" is and use the command line, as shown above and below:

./MingleServer --mingle.datatDir=/home/user/CI/mingle_3_3_1/data/ --mingle.configDir=home/user/CI/mingle_3_3_1/config/ start

The first parameter (--mingle.datatDir) points to the data directory.

The second parameter (--mingle.configDir) points to the config directory.

If they don't exist under your installation, create them if necessary.

After executing the command line, you'll find:

At this point, we're ready to start configuring Mingle.

6.     Configuring Mingle

With your server running, open a browser and go to the server's address (if you're running locally it should be http://localhost:8080 ). You should reach a page like the one below:

Check the box "The database is setup and ready to go" and hit Continue.

On the next page, fill up the form with the information used during the database setup:

Database host should be localhost (if you're running locally) or the URL (or IP number) of your database server.

The database port is default (unless you changed it before).

The database name is mingle.

The database username and password are the ones set previously.

Hit Continue.

On the next page (Step 2), it will ask to setup the database. Hit Continue again.

On Step 3, you'll have to enter the URL for the users of Mingle. If you have a network address for your server, enter it here. In our exercise here, we'll just have it set for myserver:

On step 4, you will be able to setup the SMTP for mail communication. In this example, we'll not configure this communication but you can fill up this form with the information required. Hit Continue once done.

On Step 5, you'll have the license form. Read it and if you agree, check the box and hit Continue:

The step 6 will allow you to configure the first user account. Fill up the form and hit Continue:

On step 7, hit Continue.

On the next step (8), copy the license received by email and paste on the License Key field:

After press finish and you're done!

You'll be redirected to the Mingle landing page where you can start creating your first project!

Happy Mingleing!!!

Continuous Integration and Delivery

The Continuous Integration (CI), one of the core practices within the Agile development process, has matured and became a fundamental tool for organizations aiming software development with quality, traceability and automation.

In the next paragraphs I'll be describing the components of a basic and of a complete CI system.

1.The basic system

In a minimal but complete agile environment, the CI should be integrated with other tools, including:

1.A. Story repository

This is where your story cards (or tasks) are, containing all the information about each story implemented. 

In a Agile project, one should be able to create the cards, with the necessary details (sometimes including images, documents). therefore the Story repository should be able to handle this. In addition, having states for each story card (new, in progress, etc) will enable to have the proper transition from the initial concept until the final delivery of the feature.

Good examples of story repository: 

- Mingle (by ThoughtWorks), is an excellent tool, very flexible and adapts to your Agile implementation.

- Jira (by Atlassian) is also a popular tool.

- Bugzilla, is more a bug tracking tool but I've seen some people using it as a tool to track the stories, even though it doesn't flow well.

1.B. Source control

That's where the team will put (checkin...) the source code. Usually I prefer to have every checking tied to a story card so that we can have the traceability. 

Some popular source control tools are:

- Subversion (SVN) - Very popular these days, open source.

- CVS - Was already much more popular, also open source.

- Clear Case - IBM tool, used in big enterprise environments. Can become overwhelming for some people depending on the configuration management style used.

1.C. Continuous Integration Server

This is the central piece of CI. It orchestrates the process by taking the source code, combine with the stories, run unit tests, deploy on Test environment, run automated functional tests, and finally deploy it - if desired - to a production environment. In many occasions the last step will only happen if the organization is comfortable enough with the automated tests being the "gate".

More specific about integration of the different pieces, for example, if someone is working on a (story) card with ID #2345, at the "check in" time the developer would add to the comment field the card ID tag. Later on, the continuous integration server will merge this information with the story card added on the Story Repository.

This way, you will be able to see which source files were modified in order to have specific features implemented, including the time and who delivered the source code.

There are several Continuous Integration servers but I'll mention the three main ones:

Cruise Control (by ThoughtWorkers), which is basically the first popular server. 

Hudson (Open Source/Oracle), is also a good option.

Go (by ThoughtWorks), very much aligned with Agile.

These elements together become be the basic set of tools - which is the minimum set for CI.

2. Complete CI system

In addition to these three main pieces, other elements should also be part of the CI environment, to bring more value to the solution:

2.A. Unit test

These are tests usually written by the developer to guarantee that the basic functionality of the code will not be broken during development. It tests the code for consistency, to validate if new implementations didn't break old and already working code.

Common found tools:

JUnit - Probably the most famous unit test tool for Java
TestNG - An alternative to JUnit.

Here we described tools focused on Java but for different languages you will find different sets of unit test tools. And if you find that your language doesn't have any tool for unit test, well, that's an opportunity to create something new today!

2.A.1 Code coverage


One important aspect of Unit Test is to guarantee that your code has a good coverage. There are several code coverage tools available, including:

Cobertura - Probably the most popular.
EMMA - I particularly never used it but in any case, here is a reference.

A good code coverage tool will be able to report the stats about what is being covered by the unit tests - for example, in percentage, giving the total of code covered for the entire software and per class.

2.B. Functional automated test

Unit tests are great but Functional Automated Tests will bring a whole new (and better) level of testing. With recorded functional tests, the Agile team will be able to have a greater confidence that the software created is working in its full capacity, free of functional errors.

Typical tools are:

Selenium (by ThoughtWorkers) - Very good tool!
Twist (by ThoughtWorks) - A very modern and complete tool for automated functional test.

2.C. Deployment

For deployment, there are no specific tools and most usually you'd write your own set of scripts to perform this action. Some CI tools (like Go) have plugins or embedded functionality that help this step.

3. The flow

The picture below describes the pieces involved in the whole process and summarizes the flow. The steps are described below:

Step 1: First, at some scheduled time (or every time that someone checks in code), the CI will get the latests version of the source code, merge the information with the Story repository (or tasks). A build will be produced and a list of the content of the build will be created.

Step 2: With the build in hands (war or jar or exe), the unit test will be run and the results will be collected. 

Step 3: Having the build passed the unit tests (I usually have the acceptance at 100%), it is time for the Automated functional (full tests) to run. Maybe it will be necessary to deploy the build in a test server depending on the kind of application that is being run.

Step 4: When all the tests are completed, it is time for the deployment in production. This can be automated (assuming you are really comfortable having only the automated tests results) or otherwise the build will be stored on the CI server for use at later time.

This is the basic flow of a complete Continuous Integration system.

4. Summary 

I described above, in a high level, the usual flow for a CI system. There are different variations and combinations, but in general the described solution can be used as a framework where one can add or remove pieces according to their need.

In a minimum and functional system, the three main pieces should exist (Story repository, Source code repository, CI server) but it is alway recommended to include tests, code coverage and other features to improve the quality of your software.

5. Conclusion

CI is not a new practice but its use is not well disseminated yet.

As part of the core good practices, it supports the Agile teams to advance much quicker, introducing a continuous flow of builds, tests and deployments that naturally bring more quality to the final software, saves time and eliminates (in part) the repetitive manual test.

For managers and clients, when a complete CI system is used, it will give visibility of where the team is in terms of quality, production and individual's contribution to the software.

Distributed agile

In my recent experience I'm dealing with a very big client that passed through an also big change on their corporate culture.

Without getting into names, a Company B was acquired by A and all the B's employees had to comply with A's new rules resulting on everybody working remotely - mostly from home.

I believe that this is something that will happen more and more often as companies can save big $$ by not having to keep a big infrastructure to operate.

From this concept a question comes: What will happen to the Agile methodology? Agile relies a lot on having people colocated for better collaboration and it would become a challenge for a distributed team to collaborate in the same way.

Fortunatelly some people are already thinking about this... and I'm glad I know one of them.

To get more information and collaborate with ideas about distributed Agile software development, go to http://www.distributedscrum.com/ and see how the path is being paved.

Agile and Product development

Developing sofware using the agile approach is leaving the "new" area and is moving towards the "commodity".

Not every institution embraces it. some because the approach doesn't fit their world (Military projects for example), some don't know what agile is about yet or are happy with Waterfall or pure RUP.

Anyways, each one uses the hat that fits better but based on today's reality of fast moving business, good part of the business requirements will become obsolete after months or few years. Looking into the ratio analysis and implementation/feature lifespan one can find that spending a lot of time trying to put together a solid documentation that will be the new version of the 10 commandments is just not real.

The correct use of Agile helps a lot. Having the product owner to write the requirements and the team to break down the requirements into detailed tasks seems to be the natural way of doing things - at least these days.

So, how to have many people interacting and producing something without having (m)any 200 pages document? Simple, use the right tool.

If you have the budget, use Jira. If you don't use Trac or other similar tool. Going along, to make your continuous integration smooth add Hudson. Cruise Control works too but Hudson is waaay easier to deal with. If you want to sound cool because you want to edit xml's by hand, go with Cruise Control. If you prefer to save your time for more dignifying tasks, go with Hudson.

Anyway, product development is becoming more and more focused on getting the right requirements from the product(s) owner(s). Leaving the gate open to people to add the ideas and having a pipeline in place to track the implementations is efficient and proven to work.

Several open source projects are adopting this model. It is almost like having something coming from a discussion list (forum) straight to the engineering pipeline.

Fast implementation doesn't need to be chaotic. Just be Agile ;-)

Where is the glue for real human-driven software development?

In the beginning of the software development based on models we had Booch, Rumbaugh and Jacobson - each one with their own distinct ways of modeling. This evolved to UML and more recently the XSDs.

Also, BPEL came to tie together different services but it is not much more than just wiring things with a bit of dynamics. Still, people find it useful enough to make processes workflows that can serve business in some cases.

While software development has been advancing and Model Driven Development or Architecture (MDD/MDA) are becoming more and more common - specially in Agile shops - the path to the Holy Grail seems to be forgotten in the bureocracy of OMG and by the startups.. and even more by IBM.

Bran Selic, the MDD driver left IBM for a new path - a company called Malina Software corp - which I can't find any information anywhere. This could be a new driver for things to start happening... but what exactly should we be looking for?

All the modeling techniques (with exception of BPEL) focus on the static software, in the architecture of classes and its relationship. It doesn't tell you how the information should flow for example, from the GUI to the database, it doesn't tell you how the business logic should treat the data. In other words, it doesn't fill the skeleton of the UML or XSD.

I believe something should be emerging soon in this area. This new way of coding, simply telling the software what and how it should do things does not require any super computer. Instead creativity should be the driver in this case.

So, I believe the "traditional" way of creating software will change and a new paradigm will emerge allowing people and companies to create their "logical" solutions in a way closer to human natural intuition.

I'm trying to summarize and make a structure for a project in this direction. Take a look on what might be coming: http://sites.google.com/a/antoniopaes.com/projects/application

A trap for Java and Open Source?

On recent conversations with some high level managers and directors from different companies (customers, colleagues, etc.) I have been hearing the same sad story way too often. "Java is a great framework but it is getting too complicated, too many options ..".

Java has been in the web world since its dawn and has been very successful. First with applets, being pretty much the first version of possible rich content in a browser. I can remember clearly the first applet that I coded sometime between 1996 and 1997 where I was doing a simulation of 2-D Leornard-Jones potential of a monoatomic systems.. neat little project and I'd laugh remembering the hardware configuration.

Enough nostalgia.. back to the point...

After that, java kept its pace into the web world, from Applets to JSP/Servlets, followed by Struts, JSF, Struts2, etc.

I understant that evolution must be part of the nature and within the Java nature, this evolution is becoming a bit too complicated and is giving the competitor a big opportunity. I believe Java might be getting out of the rails and instead of looking like a consistent tree log it will look more like a grape tree.

With so many possibilities to create a solution, people who are not familiar with the possible technologies and frameworks (we know how painful it is to keep up with things...) can easily get lost and high level managers will easily get lost.

Freedom is good but too much freedom might not be good and the fact is: Architects are getting very creative and finding nice solutions but people move around and the manager will have to handle the situation with new people who will have new ideas.

That's when the competitor is becoming stronger. Having a closed box might be the best solution for many people - and some of them are realizing it. The competitor is always playing the catch up and buying innovation anyways.. Johnny Lee is a good example of them buying it... nothing against it, just to point that it is easier to buy innovation when it is ready than really motivate people to do research.

It is a bad situation and partially on the different companies (Sun, IBM, RedHad/Jboss, BEA, etc) and on the Java community for not acting on it. Java might see a similar "bubble" as seeing recently in the laptop marked. Not everybody needs a dual core laptop with 4GB of memory. This month's wired magazine gives more details on this laptop bubble.

My point is. The "internal" fight between different frameworks that overlap each other many times is not contributing and I believe that a better juristriction might be benefical.

Anybody can come up with a framework, publish a book and suddenly becomes a must-be-in-a-conference guy but ... is it what we need? Another framework? Another way of mapping A to B? Another MVC2 implementation? Maybe what we need is.. better frameworks that can be taken as standards without overlapping ... well engineered and not nice-hacks-from-basements emerging all the time with a new published book on the side.

I trully hope this situation will not be a long term problem...but people who control the money are seeing it...