October 2009 Archives

The challenge we see in many Enterprise IT shops is that it is hard to get everyone across the business who touches application development 'on board' with an agile approach.  In this blog post I want to share how the CIO of one of our customers has set guidelines which help drive agile project delivery across the business.
 
The customer is a large Portuguese food distribution and consumer goods manufacturing company, with an international presence.  With nearly 25,000 employees they are used to having huge IT projects, involving multiple departments with complex requirements, large budgets and long timelines. 

Before agile, many of these projects were delivered late, over budget and in some cases actually failed.  In 2005 they became an OutSystems customer; embracing the Agile Platform and an agile methodology. As they matured in their agile practices, the CIO saw the value and today they operate under the CIO's mandate that only projects scoped with a timeline of less than three months and a budget under 300K will be approved.

What happened before the CIO mandate was put in place?  Here's what they told us:

1. They would spend two to three months in meetings, aligning all opinions in order to create a huge requirements document;

2. When they finally started developing the systems the business team had disappeared and in most cases forgotten about the project;

3. By the time the project was ready to be tested the key users had changed, the business had changed and the project delivery team immediately entered into a lengthy negotiation phase to reconcile what was delivered versus what the business really needed.

This customer states that with the agile methodology and their new CIO mandate they improved the success rate of their projects in several ways:

1. The business team is more motivated and involved as they are able to see how the projects are progressing on a regular basis;

2. The business gets to be more responsible for the decisions that shape the project direction because they see and constantly test the application;

3. The business and IT avoid the costly, wasteful exercise of building complex requirements documents because they now fully realize that they can never document every detail in a specification;

4. From very early on in the project, IT can see if the project is really what the company needs and identify any mis-matches quickly to reduce the amount of time, dollars and resources that might be wasted.

5. Even for big projects, Agile methodology is used - and forces the team to split the project into phases. This exercise divides the scope into smaller, manageable projects with incremental releases and decreased risk.

So, both for this CIO and many others, we are finding that an agile approach to application development really helps increase project success rate and reduce risks.  Even in a company like this one that has complex application needs, lots of departments and bureaucracy - agile really works! 

What are the technical leaders in your company doing to help drive agile project delivery?  Or, what would you like to see them doing? 

Share their rules, guidelines and mandates along with your ideas!  

We have recently started playing the "Ball Point Game" in some of our informal Agile learning sessions. This is a game played by some scrum trainers. The basic objective of the game is to get as many balls through the team as possible within two minutes. Each ball must be touched at least once by every team member and must end with the same person with whom it began. After two minutes the team is allowed an additional minute to discuss the process and how it could be improved. It is recommended that the game be played a total of five times or sprints. You can learn more about the game in this Scrum Trainers blog post. 

When I was first introduced to the game I wasn't quite sure what Agile concepts I would learn about.  Was this about the importance of retrospectives; scrum meetings and communication or scrum of scrums?  What I learned were some interesting aspects of all these topics plus, what I think was the real message from the exercise - with experience comes speed and quality, and experience can be injected into the team when done at the right time!

So for those who don't know this game it is very simple and quite fun. A good team building exercise even if you are not practicing Agile. 

Watch this video now and my findings below will make more sense.
 

Mike's findings from the Ball Point Game
As you can see, the game was fun.  If you did not notice the video was from two different sessions; one session was in Lisbon, Portugal and the other in the 'sunny' England.  (I know, hard to believe it was sunny in the UK!)  Let's reflect on the four topics I mentioned above:

1. Retrospectives are really key for the delivery team to be able to adjust and improve.  They also give you a point in time to measure your effectiveness as a team.  Important if you are interested in improving!

2. Scrum meetings and communication are part of the secret sauce for agile.  It was very evident in the video.  You saw the teams discuss their performance, brainstorm ways to improve and then implement the improvements.  Of course this concept extends beyond the 'ball passers' to the whole Agile team including the business users, testers, etc.  If you don't have regular interaction across the whole team the Agile process breaks down very quickly.
 
3. For large teams the concept of "Scrum of Scrums" is critical.  Our first group was very large, there were four separate delivery teams and their Scrum Masters met to discuss the 'project' and then collaborated with the smaller teams.  While I agree this is important, it begs the question - management in Agile projects?  Of course if you read this blog regularly you already know that for Enterprise agile to be successful you need some good project management!
 
4. Experience is critical for success.  If you go back and look at the video you might notice that before the last sprint the teams get a nudge from an experienced player.  In this game's case the nudge is about 'maximizing' resources - and this meant passing two balls at once.  This would never have been considered in the earlier sprints but with a little experience to direct the teams they easily adopted the concept and really improved their performance.  A bit of a warning: a good agile coach will let their team build on their skills and not introduce a 'nudge' too early.  I suspect that if we had given the team the "two hands" advice after the first sprint it might have proven less beneficial as the teams had not progressed enough in their working approach to successfully implement this advanced concept.  Food for thought.

So, both groups improved their efficiency many times over from the first sprint.  In addition, if you would have asked them if they thought they could double their throughput after each sprint they would have been skeptical at best.
 
And the final lesson: Keep an open mind, learn from experience, and be willing to fail - just do it fast and adjust! 

Let me know if you have played the game and what your take-aways were.

You can follow me on Twitter here.