About Agility

There's a lot of blogging about agile estimating and planning but most, if not all, that I've come across only pertain to after the project has been started.  Further, what is being estimated and planned is for the iterations.  So how does one define budget for the agile project itself, specifically a web business application project?  I mean, the cost of the hardware, 3rd party software, facilities, etc. everything except the actual software development cost can be fairly straight forward to budget. 

But what about the software development cost?  Using conventional methods or techniques is certainly an option but they do not account for the fact that agile projects tend to cost less when compared to similar projects.  So, perhaps this is not the way to go. Besides, business owners want to know what they're getting for their money and how much it is going to cost them. 

At OutSystems, we solved this by taking the following 3 steps:

1. First, we work with the business to gather and transform high-level requirements into user stories.  Stories highlight features that detail what the user wants to do (e.g., create, list, search) to specific objects (e.g.customer, store, loan). 
 
2. These features are patterns of implementation; it is the patterns that are estimated in hours based on years of experience delivering agile projects successfully and this experience is encapsulated in our OutSystems Agile Network Sizing (ANS) tool (BTW - you can see a demo video here).  The tool allows us to set various influencing variables such as number of developers, iteration size, number of user profiles, etc. that enable us to adjust the estimates based on complexity levels.  There are always unknowns during funding and these variables help provide a means to shore up those that may require more attention during the project.
3. Given the resources, we are able to calculate what we call the ideal project timeline, complete with sprints and a target go-live date.

You can probably use story points to achieve the same thing assuming you have a common baseline and have equated points to some level of effort which, in turn, equates to dollars. 

What if you get funded without this process?

Let's say your project gets funded but you did not use patterns or story points to determine your budget.  You start the project and gather your user stories, prioritize them and the size them.  You conduct your sprints and over the course of say 3 iterations, calculate your average velocity and capacity.  Having your averages, you can calculate the average cost of each iteration and thus the project itself; also, potentially determining when you will run out of budget.  Unfortunately, when using story points and a burndown chart, you still cannot predict with enough certainty when the project will be done. To most stakeholders, stating an approximation or a moving target date is just not acceptable even if you stress the benefits of going agile - early delivery, handling evolving requirements, software that meets specifications, early risk mitigation, etc. 

So what do you tell them?  How do you accurately estimate the time and cost it will take and then convince the stakeholders that the project will be done on time and within budget?   Do you give odds when answering when the project will be done?  What do you do if you run out of budget?  Are you gambling with your budget?

Here's the process we've developed:

a) We bootstrap the stories, budget, timeline, sprint definitions from the sizing tool into our project management tool - the OutSystems Agile Network Project (ANP).  The bootstrap process calculates the budget for each iteration based on the overall budget.

 
b) Each iteration is allocated a budget for development, technical debt, change requests, testing, and sprint review.

 
c) Once the information is in ANP, we review the stories with the business, prioritize them and even negotiate what goes in an iteration, just like any other agile project.

 
d) We also break down the user stories into work-items and estimate them (in hours) in conjunction with the developer(s) assigned to complete them.  It is the work-items that we commit to deliver for the sprint.  This helps us ensure that we do not exceed the iteration's budget. 

In summary, estimating based on patterns enables us to define the project budget.  Resource estimates and other influencing variables coupled with the budget enables us to provide a project timeline and target go-live date.  This information allows us to manage the project at the sprint level ensuring that we are on target while not exceeding our budget.

What method(s) do you use for estimating project budget and timeline?  What method(s) do you use to ensure you deliver within budget and on time?

Today we released a new version of the OutSystems Agile Platform - 5.0! In this version we're taking agile a step further; not only are we supporting the entire application lifecycle management for web applications, we also added support for IT teams to rapidly develop business processes using agile methodologies.

Traditionally, business process development was done at a different pace using different tools than IT used for application development. However, one of the biggest challenges facing the business process world is the integration of business processes with applications; which meant one of them was always waiting for the other.  And, in the case of our customers who already use the Agile Platform, web application development was happening faster than business processes development.

With version 5.0 of the Agile Platform, we have closed that gap! Using the new Business Process Technology capabilities of the platform, IT teams can develop business processes totally integrated with web applications in an agile manner. All artifacts that the Agile Platform provides for Web Application development - like TrueChange technology, 1 Click-Publishing, Real Time Monitoring, and so on - are also available for business process development.

To develop this new capability, the OutSystems R&D team partnered with one of our customers, Van Ameyde, to design and implement this capability. Van Ameyde uses business processes intensively for insurance claims processing and has very heavy change demands for those processes. Customer participation has been key to the development of the new 5.0 functionality, and we believe that it led to a pragmatic implementation of Business Process Technology that will allow IT teams to fulfill the needs of the business from a process perspective, as fast as they have been doing for web applications with the Agile Platform.

Along with Business Process Technology, version 5.0 includes many other improvements that will make developers a lot more productive. If you're already using the Agile Platform, check the videos of some of the improvements we made to the platform. If you want to give it a try for yourself, the best thing to do is download the (free) Community Edition and try out the new capabilities of the platform.

Of course, we could only release such a great version of the Platform with a great team! We had a lot of help from a lot of people, in particular from our Beta customers who provided such excellent early feedback, and a special thanks goes to the 5.0 team that delivered such a great product! Version 5.0 of the Agile Platform will definitely raise the bar for agile.  Give it a try, the 5.0 development team promises you that it ROCKS!

We were all very excited to hear one of our customers, Max Rayner, speak at the recent ALM Expo on how he and his team built and delivered the www.fly.com system using an agile approach. If you're not familiar with it, this is an internet application that's openly available and was built using Agile methodologies, SCRUM techniques and an Agile ALM toolset.
 
Max is the CTO of Travelzoo - a travel publisher with 18 million subscribers and fly.com is an online app that helps you find the exact match to your air travel needs. During the webcast Max discussed the problem space, their agile approach, the innovative metasearch engine, how they managed a distributed team, challenges, key learnings and reasons for their success.With all that said, I can't really do the webcast justice in this blog as there was SO much great information shared - but you can:

1) download the webcast presentation slides.pdf and listen to the podcast

2) view the full recording of the webcast here (unfortunately, you will need to register but its free and painless.)

3) or, you can download the podcast of the presentation here and listen in your own time.

BTW, the recordings include a great Q&A session that I would highly recommend listening to!  Here are some stats Max shared on the fly.com agile project:

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.

OutSystems is all about Agile - and the same applies to our internal R&D team which has been using Agile since 2002. Because we've been using Agile for so long all the principles are pretty much entrenched in our culture - but as the company and the department grew, we started to feel the need to share our Agile knowledge with newcomers to the team.

We considered several ways of doing this. We pondered doing a traditional PowerPoint presentation; we thought about assembling a mandatory reading list; we entertained the idea of adding support on our tools for some of the Agile tenets; and so on...but in the end we decided to organize a contest around Agile to help new team members learn about the methodology the fun way!

Let's play: Who wants to be an Agilionaire?

The idea is simple. Each week a question about Agile was sent to the entire team. The question was accompanied by 4 possibilities, and the contestants had to pick the right one. Everyone could reply to the question within 24 hours, and the winner would be the person with the most correct answers. You can check the questions & answers here.

This approach worked really well, and had a lot of advantages over any of the other methods - here are a few:

• People were encouraged to look for an answer. This not only ensures people are paying attention to what you're teaching, it also promotes self learning.
• The questions were picked based on the real issues we witnessed internally. This means that people were learning what they needed most, not every detail on Agile.
• We sent a small justification of the answer with references to sites, blogs, and books on Agile - and provided more bibliographical references than we could ever hope to transmit on a single presentation.
• We got an idea of people's knowledge on Agile. Now we are aware of how much people know about Agile (and the results were very good, I might add). We also have an idea of the areas where specific people need more help, and will use this knowledge to help them get up to speed.
• Everybody participated. If we had done a Power-Point presentation, I'm sure we wouldn't have had everybody raising their hands.
• It was really cheap! There was no time invested in preparing the presentation or in changing the internal tools. The only work required was preparing the questions and answers.
• It was fun! Everybody liked this idea, and we got great feedback from the team! It was surely more fun than going through a 2 hour presentation on Agile...

2 months and 8 questions later, we have a WINNER! Miguel Melo had the brilliant result of 7 out of 8 questions right, proving to everyone that he's a true Agilionaire! To celebrate the victory, Miguel was awarded a priceless handmade trophy (built and designed at OutSystems;) an adventure pack to prove he's also Agile out of office; and he gets to show up in the Agility Blog! Congratulations Miguel!

Last month our company announced its new Agility Awards - and the first set of awards were presented for five Agile projects that had been completed by customers and partners using  OutSystems' Agile Platform and employing Agile methodology.  

The question I want to pose is what are good criteria for assessing a successful Agile project? This question builds on Mike's recent post about criteria for measuring an Agile project manager's success - and we got lots of great responses and ideas in the comments.

The data points being used by the OutSystems team to evaluate whether projects are eligible for an award are:

1.    Size & scope of project: the project should be of medium to large scale (over 40,000 software units in size.)

2.    Project definition & objectives: the project should deliver significant and measurable business value.

3.    Project approach: the project should have been run based on Agile practices, following an iterative development approach with regular end user involvement.

4.    Project metrics: a baseline of project metrics must be submitted in order to measure the impact of using Agile to deliver the application.

The team then use these data points to assess whether an Agile approach was employed to deliver the project on time, on budget, with 100% user adoption and delivered true value to the business and IT.
 
Is this list a reasonable set of data points for measuring the success of an agile project?
 

BTW - Here are some examples of the results from the initial set of award winners (read more details here):

XDx - Analysis Request Management System

Time-to-market: 6 weeks + 1 for launch; Number of Agile sprints: 3

Customer quote: "This was our first Agile project and it achieved the two key business goals: avoiding tracking errors and improving real-time data consistency for our studies. Most importantly, we were able to deliver this value to the business in a record time, exceeding both developer's and user's expectations and establishing Agile as the preferred methodology for this type of development project." - Jochen Scheel, Director at XDx.

RWE - Tiger, Implemented by Atos Origin (BTW - nice blog from Atos Origin on the project & award here)

Time-to-market: 14 weeks; Number of Agile sprints: 5 + 1 tuning

Customer quote: "The Gas Portfolio Management application was implemented over a period of three months which was only possible with the OutSystems' Agile Platform and methodology. Their way of sharing information, processing activities and reviewing project deliverables with key users of RWE NL was instrumental to the success of this project."- Perry van de Goorberg, Project Manager at RWE.

OK! teleseguros - Sales Platform and Home Insurance, Implemented by Keep It Simple

Time-to-market: 13 weeks; Number of Agile sprints: 3

Customer quote: "This project was a true success as it exceeded the business's expectations in terms of objectives achieved and above all business benefits. The Agile Platform and methodology allowed the business to engage the development team and see the immediate impact and results of all project changes and decisions." - Sérgio Carvalho, Marketing and Product Director at OK! teleseguros.

In no particular order:

1. Jutta Eckstein's book - Agile Development in the Large
   
2. Mitch Lacey & Associates - for their Blog + PDF Decks
   
3. Juergen Appelo's blog "Noop.nl"
   
4. James Shore's Blog "The Art of Agile"
   
5. Google Tech Talks: Elisabeth Hendrickson on Agile Testing
   
6. Craig Larman's book "Agile & Iterative Development" 
7. Dan North's Blog "Introducing BDD"
   
8. James Bach's resources (blog, book, pdf & articles) on Exploratory Testing 
9. Last but not least, our very own Rodrigo Coutinho's video on "The Secret of Agile Speed"

You should follow us on Twitter here.

Last week's Agile2009 in Chicago was a pleasant surprise in a couple of ways.  First, in a down economy the conference attracted nearly 1400 attendees from around the globe - which is outstanding considering many conferences organizers we've talked to are reporting a 30% decline in attendance. According to the organizers 60% of the attendees were first-timers at the conference which is a testament to the quality of the event. And, there was a large international contingent - we met lots of Aussies, Kiwis, Brits and Europeans; in fact it felt like 50% of the Agilists we spoke to were from outside the US - and great to meet them all! 

Second, after four days of interacting with other conference goers we noticed two trends that were very different from last year's conference:
 
a) The majority of attendees are now actively practicing Agile and have participated in multiple projects.  Last year it seemed many people were attending in order to learn about Agile in preparation for their first project.  This year, our informal (and unscientific) survey showed 53% have been personally involved in over 4 Agile projects.

b) Sprint duration among participants has dramatically reduced from four weeks last year - to two week sprints this year.  During one of the conference sessions this year "Death by SCRUM Meetings," a session attendee told us he estimated the majority of the audience who were polled on the average length of their sprints said two weeks.  This prompted the OutSystems team to do an informal survey of the people we talked to, which confirmed the number - two weeks is the norm for sprint durations.

Agile is definitely becoming main stream. Alistair Cockburn's keynote "I Come to Bury Agile, Not to Praise It" made this point - the days of small co-located teams following the Agile Manifesto are dead and gone.  Today we have very large distributed teams tackling big problems which are changing the face of Agile as it was originally conceived.  The term Agile now encompasses so much more than just doing things faster - Agile is dead, long live agile.


I Come to Bury Agile, Not to Praise It - Alistair Cockburn
Main Take Away: Agile has grown up and no longer in the domain of the few; it has now received the attention of large scale enterprise and evolving faster in terms of maturity.  It is taking on a life of its own.  The speaker noted that he observed this to be true because Agilists are now in the "ri" stage of the "shu-ha-ri" concept.  "ri" being where an individual is now capable of inventing and blending concepts and into new approaches but still within the "Agile" umbrella.  ("shu" - learning a methodology, "ha" - collecting techniques, "ri" - inventing and blending techniques).

Introduction to SCRUM - Henrik Kniberg
Main Take Away: Scrum seems to be the most popular of the agile methods because of its ability to incorporate any technique or tool in its use. Interesting quote for us agile & tools people "Do not develop an attachment to any one weapon or any school of fighting." Miyamoto Musashi, 17th Century Samurai.

WANTED: Seeking Single Agile Knowledge Development Tool-set, Brad Appleton, Peter Alfvin  Main Take Away: Companies in very complex environments developing embedded applications, corporate applications and everything in between will continue to struggle with disparate tools.  

Agile in the Enterprise Corporation, Panel: Israel Gat, Stephen Williams, Laureen Knudsen, Scott Killen  Main Take Away: Why Agile? It's about the money!  Do feature budgeting.  Develop and maintain a release model in a business framework.  Get the organization on board within the dynamics of your specific company - collaborate.  Re-organize to Operational and Executive teams that are cross-functional and make their interaction with R&D asynchronous.

Marriott's Agile Turnaround - Jesse Fewell Main Take Away:"Agile can't fix bad strategy"
                          
First, Kill All the Metrics - Niel Nickolaisen , Chris Matts
Main Take Away: Reward and punishment results in meaningless metrics and thus not all metrics we use are meaningful.  For a metric to be meaningful, it has to measure process and not people; they need to be aligned with the objectives and strategy of the organization; and should show trends.  Metrics that measure people tend to result in unhealthy competition between team members especially in a self-regulating / high performing team.

Strategies in Replacing Systems in Agile Projects - Niklas Bjornerstedt
Main Take Away: Presentation discussed a number of patterns in replacing systems and recognizing these patterns can help in the process.  Although there are patterns that can be used to help in transitioning users, migrating data, etc.; it still boils down to a case by case basis.

How to evolve a Product Backlog - Ronica Roth, Mark Kilby
Main Take Away: The main discussion centered on following the user work flow to evolve the product backlog.  Along with that, ask questions on the 'what' and the 'why' primarily.  The 'how' questions need to focus more on the current processes and not necessarily on the future although it would be good to note that.

Agile Metrics - Dan Rawsthorne
Main Take Away: The talk was directed to organizations that are new to agile.  One of the key points is to level-set on metric-related terminology like what "done" means so that there is no confusion between team and customer.  A suggestion was put forth to create a "doneness criteria" which essentially is a checklist.  Other terms were velocity and capacity that accordingly most folks new to agile get confused on.  The speaker suggested that velocity = capacity until proven otherwise.  Capacity is what you estimate you can do and velocity is what you have proven you can do.

Mike Jones, Robert Neri, Roy Carnes and I are heading to Chicago on Monday to attend this year's Agile 2009 conference. This is OutSystems' second year at the conference and we're looking forward to a great week of Agile learning, meeting new people and community activities. If you're going to be there - stop by the booth and say Hi and join us for Happy Hour during Muzik Masti on Wednesday night - we're buying the drinks!!

Since we are representing many of the OutSystems community who can't be in Chicago next week, we thought we'd invite you to review this year's conference program and if you want to hear more about a particular session just make a request in the comments below and we'll do our best to check it out for you. BTW - we are also planning to tweet (#agile2009) and blog from the conference so stay tuned!

Here's a selection of sessions we're planning to attend with Agile disclaimer: things are likely to change ;)

Monday, August 24th
Early morning travels to Chicago and booth set-up
***also look out for an exciting announcement from OutSystems at 9am EST**

11:00-12:30 Workflow is Orthogonal to Schedule Mary Poppendieck
14:00-14:45 Enterprise Agile Transformation: The Two Year Wall Chuck Maples
14:45-15:30 Zen and the Art of Software Quality Jim Highsmith
17:30-21:00 we'll be at the OutSystems booth breaking ice!

Tuesday, August 25th
07:30-09:00, 12:30-14:00, 19:00-21:00 we'll be back at the OutSystems booth doing demos, giving out drinks tickets to Wednesday's Happy hour, mouse mats, CDs and Apple iTouches!

9:00 Conference keynote: "I Come to Bury Agile, Not to Praise It", Dr. Alistair Cockburn
11:00-12:30 Don't Sell Buzzwords to Business Leaders, Learn How to Describe Real Value R.Sheridan, J. Goebel
14:00-15:30 First, Kill All The Metrics! Niel Nickolaisen, Chris Matts
16:00-17:30 Agile Project Metrics Dave Nicolette

Wednesday, August 26th
07:30-09:00, 12:30-14:00 we'll be back at the OutSystems booth doing demos, giving out Happy Hour tickets
08:15-08:45 Mike Jones "The Power of Enterprise Agile in Action" during Take a S.E.A.T.
09:45-10:30 Performance without Appraisal: What to Do About Performance Reviews Esther Derby
11:00-12:30 The Agile PMP: Teaching an Old Dog New Tricks Mike Cottmeyer
14:00-15: Exploratory Testing (Framework) Experience Erik Petersen
16:00-16:45 Enabling Agile Testing through Continuous Integration Sean Stolberg
18:00-20:00 OutSystems & Agile Journal hosting Happy Hour at Muzik Masti, Columbus EF

Thursday August 27th
07:30-09:00, 12:30-14:00 last day at the OutSystems booth doing demo and giving out goodies.
09:00-10:30 Agile Project Management--Innovation in Action Jim Highsmith
11:00-12:30 Beyond features: How to listen to your customers & learn what they really need L. Halley, L. Hohmann
11:00-12:30 Role of the Agile Leader in Reconfiguring the Business Israel Gat
14:00-15:30 A Business Value Focused Model for Story Identification & Prioritisation Shane Hastie
14:45-15:30 Agile won't Work: Implementing Agility in Non-Standard Teams Daniel Markham