I recently introduced a small software development company to the ideas of Agile development, the culture of Agile, and of course some of the fundamentals of working in incremental steps. We focused specifically on OpenAgile.

They started their first cycle with great enthusiasm and with as much attention to detail as possible, but still ended up completing zero story points in their first cycle. Is this is a disaster ? The short answer… NO.

The company has gone through two major releases based on non-agile methods with limited success. One of the owners of the company has been a long time friend and we discussed doing some Agile training with his employees to “see how they felt” about learning about OpenAgile.

There were no commitments made to it. The idea of “Hey, let’s learn about this and see if it’s right for our organization” was the goal. All the team members were told that the company was considering (with emphasis on considering) switching to OpenAgile and would not do it if everyone didn’t feel like it was worth the effort and made sense for them. It was stressed that OpenAgile is not a silver bullet and may not be right for them. The effort was purely exploratory in nature.

As this company is in software development, Agile development easily made sense for them. They were so excited by the OpenAgile training, the developers and the owners decided to immediately abandon their existing plans for development and refactor. The fact they felt they could do this shows true management leadership and support for the process.

I have to congratulate my friend for his courage in supporting his team.

The team determined that they were working on functionality which would not provide the greatest Return on Investment and decided to adjust their priorities accordingly.

A great deal of our time was spent during the training on the ideas of Consultative Decision Making and encouraging openness between those involved in the process. All team members are encouraged to be open about their opinions during planning and if they find something wrong during the cycle, to speak out.

I find that having management and stakeholder support and encouragement in the process is almost mandatory for Agile to work. Without the understanding from the owners of the company, the culture required to make it work will inevitably cause friction “around the edges” of the Agile team.

We spent time on the concepts of ROI (return on investment) and how to apply it to estimating, planning, re-estimating, and selected work. In using OpenAgile, we want to work on the tasks that give us the biggest value over effort factor or ROI.

We followed the OpenAgile syllabus. As an OpenAgile trainer and mentor, I had easy access to material to teach in an organized fashion. Their environment is complicated by owners in multiple cities and developers in 3 different cities including an overseas component.

Openness about the potential pitfalls of remote teams made a big difference to the attitudes of those taking the training and the final outcome. Learning OpenAgile, Scrum, XP Programming, or any Agile process is difficult enough without adding the component of two remote teams and overseas development.

Many people leave their OpenAgile training realizing that it is a very effective framework and are anxious to get rolling. Because this company and the team decided to continue with OpenAgile, they started the preparations for the first cycle to begin the following week (after a long weekend break).

The cycle started, cards were created as Story Points, and the work began in earnest. They had many surprises. I had been unavailable through their first cycle and had very little ability to keep up with how they were doing because of a new Scrum Team I was working with. In retrospect, I am glad I was not there to give advice. They did fine on their own :->

In true Agile form, they figured out on their own what was going wrong and when I talked to the owner several weeks later I found out that they had already determined their mistakes.

The team was actively taking steps to improve the next cycle.

If senior managers encourage the right environment and let the team self-organize… you know what.. they likely will :->

Things that went poorly

Two days into the cycle, some of their overseas developers went “to visit family”. They did not realize at the time, this was local code for “going on holidays”. I heard from the owner later that if they had not asked why they did not get responses to emails, they would not have known the other developers were away.

The Stories were Too Big. Because of the combination of the new way of doing things and the excitement about how much could get done as an Agile team, the team bit off more than they could chew.

Attempts at Test Driven Development did not go well.

The first two week cycle stretched to 3 weeks because the team didn’t want to have Zero velocity as they felt this was a failure

One display bug crept into the first demo related to two different ways of refreshing data on the screen

Things that went well

The team talked regularly about how they were doing and worked on regular status updates to determine where they were during the cycle. This is also how they found out about the missing developers.

The owners and managers had an active involvement in helping to remove obstacles.

The team found an intriguing way to determine how many story points they could actually commit to in future cycles.

The team figured out how to deal with code sharing and peer review type issues related to being at opposite ends of the earth.

The team stayed together and focused on the goal of creating potentially deliverable product

They were able to successfully work on two simultaneous streams of work on different parts of the system.

During the demo, the team was able to demo functionality that could potentially be brought to a customer after only two cycles.

Summary

I had a discussion with the owner recently and he told me they all sat down and realized their mistakes of their first cycle. They consider OpenAgile to be a success.

The team was so worried about not completing story points, they considered it to be a failure to not finish at the appropriate time. You need to let newcomers realize that not completing all the story points of the first cycle may happen. This can be compounded by added complexities of your working environment or project.

Since they were pushing to get the points completed, they were sacrificing quality. They were rushing because they knew they had gone past the end of the cycle and it was causing more problems each day it continued. Thankfully, they stopped the cycle and decided to do the right thing and demo where they were and talk about their progress.

They simply took on too much work, didn’t account for all the other overheads of a new team setup and issues that would take place with their remote environments. This did not mean failure. They learned how to re-organize themselves for future cycles.

With the support of the owner and a little bit of moral support from myself, the team realized they had accomplished a great deal already in their first cycle.

They realized they need to put some better controls on the holiday schedules of the remote teams overseas or at a minimum find out what is expected in this regard.

The team realizes it has a deficiency with Test Driven Development and is working on plans to allocate some time for training on this very important task. Perhaps their one bug from the first demo may not have been there with Test Driven Development in place. They will continue to work toward improving this.

One of the great things to come out of their first cycle…. A potentially deliverable product within the first two cycles!

When I reviewed this with the owner he told me the completed work is already faster and better than their previous system which took 5 years to write. Considering the remote component they are dealing with, this is truly great news for them. Their first cycle has produced software which can now simply grow organically.

Some advice here which I shared with my friend.. Make sure that you have at least one story that can be finished in the next cycle, no matter how small. Consider it of huge Value to the Agile process.

You need to provide some positive feedback for the team members now. This does not mean the team should agree to less work than they think they can accomplish. Simply encourage some work that can be completed to be included in the next cycle.

For my friend, although they completed zero story points in the first cycle, they are happy to know that if they just adjust the size of their stories for more attainable results and use what they learned from the first cycle, OpenAgile will work out well for them.

The concepts of Consultative Decision Making, Continuous Learning and the Learning Circle allowed them to truly excel and will allow them to continue to do so into the future.

They are looking forward to shipping their new product in record time :->

One comment that was made to me was something along the lines of “Hey Mike, this reminds me of when we used to work together in the garage when we started the company. We all worked together on whatever needed to be done. That’s what made us successful in the first place.”…. Hmmmm.

Mike Caspar, CSM, OA2/5

References: OpenAgile – www.openagile.com