A couple of Agile links

Here are another couple of good Agile resources. First of all, a great find from Bruce, comes a slick 10 minute intro to Scrum.



Next, there is a report on the Consideration for using Agile in DoD Aquisition via the Herding Cats blog.

This report is the result of this assessment, and is meant to debunk the prevalent myth that Agile and De-partment of Defense (DoD) practices are incompatible. Our focus is on the software development arena, basing our information on actual acquisition experience and a sampling of the relevant literature availa-ble. We will not discuss specific Agile methods beyond describing Agile and providing a list of the most common Agile methods. We do, however, provide some helpful hints on considerations that need to be addressed when deciding to use Agile in the DoD environment.

The report is a great read of how the DoD looked into Agile. As you can imagine this is a very pragmatic write up and refers to Agile as a 'Lead Bullet' rather than a 'Silver Bullet'. As with most things, processes included,  there is no one size fits all - the skill is working out what and when to use each approach.

Paper : Introducing Scrum into Government

Here is an award winning industry paper by Adrian Royce, from the Australian Software Engineering Conference (ASWEC 2009), via Rowans blog.

Here are some extracts;

This paper outlines the steps the author took in introducing the Scrum agile process into the Dept of Housing and what lessons were learnt.

Housing has now been running the ‘Scrum’ agile project delivery process for over 2 years. During that time all software projects have been delivered on or ahead of agreed time frames. ICT staff, engaged in the Scrum process, became motivated about delivering value to the client. ICT staff morale increased which led to staff retention. Feedback from business units across the department indicates that the usage of Scrum is a success.

The agile process called “Scrum” was selected over the
alternatives because it:

• Emphasized communication and collaboration, functioning software, and the flexibility to adapt to emerging business realities[1];
• Was not just relevant for developers but the entireproject team; and
• Embraced agile philosophies such as the Agile Manifesto[2].

I particularly like the summary, which highlights an often missed attribute of Scrum.

The use of Scrum was a success at the Department of Housing. However even as a lightweight methodology, it requires much discipline.

Whilst Scrum is an Agile method, Agile doesn't mean that there is a lack of discipline. In fact the contrary is true, in that Scrum and XP have a great deal of discipline. This is how higher quality software is produced. What is different from traditional 'waterfall' development is that redundant and wasteful practice has been removed.

If you are interested in such things, or how Scrum and Prince 2 integrated for this department, then go read the paper.

Scrum Intro Presentation

From ScrumMaster.com.au website is a great introduction to Scrum. The presentation covers the the roles, the flow, the theory and artefacts.

Scrum Introduction

View more presentations from scrummaster.

Agile or Not. A few links to help you decide

Need a checklist to decide if that new project should be done using Agile ?

So far the Scrum Agilitists that I've met seem to be a very pragmatic bunch, a bit like myself. They realise that Scrum isn't a silver bullet, quick fix or guarantee of sucess for every project. As part of the CSM course that I recently took, we covered when to choose Scrum and importantly when not to.

Scrum makes reference to the Cynefin Framework (developed by Dave Snowdon, the KM guru and pioneer in the application of complex adaptive theory) around leadership decision making and complexity.

You see, Scrum work best for complex projects where the scope is not well understood or agreed and the technology is far from certain - two huge areas for contention in traditional waterfall approaches. For the complex domains, 'probe, sense and respond' is prescribed by the Cynefin Framework which matches the 'apply, inspect and adapt', that Scrum uses.

Even then, if you have worked out that you have a set of suitable project, which ones are likely to have a successful outcome and are ripe to use Agile techniques. Kane Mar, a well known Scrum Trainer and Coach, has published a simple score card to get started. Agile Project Selection from a portfolio of projects, it might help to identify which projects are good candidates. Although, he notes that as you become more experienced you'll be able to identify which projects to choose without a scorecard.

Here is a bit more about the scorecard.

The Scorecard is simply a list of criteria that can be uses to assess the characteristics of a particular project. A numeric value is associated with each question, so that scores can be simply tallied up based on the total value and then used to determine if the project is suitable for “the Agile treatment.”

Lets also consider some stats.

EMA research conducted in mid-2008 determined that 80% of companies surveyed had custom software in production, a higher percentage than Enterprise Resource Planning (ERP), Customer Relationship Management (CRM), or any other application type.

They also determined that over 60% of the time, software development projects fell short of expectations which means that only 40% of budget dollars invested in software development yield business value and therefore the conclusion is that reversing this trend can yield very rapid ROI.

The CSM course cites the Standish CHAOS Reports to determine that 64% (I'm not sure the date of which report) of features are seldom or never used and therefore the case for deciding on features based on value.

So if the EMA and Standish data is right (some may disagree) then adopting a software development methodology that reduces waste and has an emphasis on value is going to be a wise choice in the current environment.

So it's hardly surprising then, given the numbers, that you will be hearing more about Agile (and Scrum) as this rapidly becomes the standard approach for complex projects - which includes software development.

Agile Contracts

I can see how Agile works for software vendors or corporates who develop software internally, but what about service companies, like IBM Business Partners, who supply software development services ? Usually client like to know what they are going to get and for how much. Fixed Price and Labour/Time and Materials contract models, with the BDUF, are prevalent method that I've come across.

So how does this work for Agile ?

Two interesting posts that contain the agile approach to the contractual obligations between customer and supplier have appeared on my RSS feed recently. They might be a useful starting point if you are pondering how to supply your services in an Agile manner and so I thought they would be worth a re-post.

Firstly, Rowan, the Scrum Trainer from my recent Certified Scrum Master training has posted the course round up, including links to further information about the Agile contract models that we covered.

Secondly, there is a very detailed description of 10 Contracts for your next Agile Software Project. Which breaks down different contract types into the following;

• How is the contract structured?
• How does it handle changes in scope (requirements)?
• How does it apportion Risk and Reward between customer and supplier?
• What model of customer relationship does it foster: competitive (my win is your loss), cooperative (win-win), indifferent (I don’t care-you lose) or dependent (heads-I-win-tails-you lose)?

Are you interested in Agile and UX together...

With 341 bloggers posting on PlanetLotus, sometimes you miss something. I'd previously missed Chris Recklings older post about Design@IBM. However, I did see his recent post about the UXDesignCast, which led me to discover the team talking about Optimized Agile Design in one session. I also found the new article An Agile Approach to User Experience and Design on the Design@IBM website.

An introduction to Scrum (plus some interesting case studies)

Here is a link to a 14 page Scrum Guide and some case studies (via ScrumAlliance.org) for those interested.

Abstract.

This guide explains how to use Scrum to build products. In doing so, it will describe how the framework and its artifacts, time-boxes, roles and rules work together. Scrum does not include techniques and processes for building products; however, it will point out the efficacy and flaws of these techniques and processes.

Scrum is a framework for developing complex products and systems. It is grounded in empirical process control theory*. Scrum employs an iterative, incremental approach to optimize predictability and control risk. Within each iteration, Scrum employs self-organizing, cross functional Teams to optimize flexibility and productivity.

Have a look at some of the case studies that were presented at the 2009 Scrum Gathering (in Orlando, FL.). It makes for some interesting reading.

Case Studies:

Scrum But
Scrum Games
Bootstrapping Scrum

Agile what is it and should I care ?

Chris has cajoled me into posting this, its been in draft for ages. I've been trying to work out if this is relevant and useful to the Lotus community, or am I the only one interested in this stuff.

I've been learning as much as I can about Agile and, in particular, Scrum. I'm a certified project manager (based on PMBok), so I was interested to understand the implications of managing software projects in an Agile way. Did I need to throw away all I knew about the PMBok. How do you manage the same things that the stakeholders need to know about risks, schedule and budget but in the Agile way.

I am also interested to find out how others tackle software development in the context of the Lotus platform. It doesn't seem to be a topic that is talked about much within our community.

There is a rising ground swell of interest and adoption of Agile software development, which is gaining credibility. Agile is now a widely accepted and valid method for managing software development. IBM Lotus Software Group and the Lotus Notes Development Team are using Agile and the fourth edition of the PMBok guide is being influenced by agile projects.

Should the Lotus community be interested ?

Is Agile (and Scrum) something that, as professional software developers, we should be interested in ? or interested enough to find out more ? We take toolkits and ideas from other technology areas and reuse them for our own purpose, so why not a development method ?

I don't need Agile, I'm using a RAD tool.

Lotus Notes has always been on the agile side of the spectrum and is often referred to a rapid application development (RAD) environment. Of course, just because you are using a RAD tool does not necessarily mean that you are developing software in a RAD way. In the same way that you can still write Java code in a procedural way and shun any form of Object Oriented techniques. I've seen the waterfall, big document up front, approach for Notes development and you end up spending more time on the document than actually writing the software.

For me developing solutions in Notes has been somewhat Agile. I started with Joint Application Design (JAD) and then Accelerate Value Method (AVM). AVM, for those who have not heard of it, was the Lotus consulting methodology from 1995 which embraced a collaborative development style with stakeholders and team. The aim was also to deliver value to the customer at the earliest opportunity through short iterations.

In fact if you did business with Lotus Consulting in Australia you would have come across a project flexibility matrix in our statements of work. I saw the same matrix recently while reading 'The Software Project Managers bridge to Agility'. We even used a documentation formatting methodology that favoured brevity and efficiency in communications.

So why should I care if I'm using Agile or Scrum ?

Simply, it gives you a common language that you can talk to other developers, clients and managers when they ask what is it that you are doing. You can point to a wealth of credible experience online and in books and say, yes we are using a software development methodology. A methodology favoured by highly respected experts, and by the way, they have produced high quality software that the users want quicker. Make no mistake, there are pit falls and traps which you will need to look out for. You will also need to assess if your team and organistion is ready and willing to try Agile.

There are also lot if misconceptions around Agile methods that have the potential to strike fear into managers and the PMO alike. "No documentation", "you'll get it when you get it" and "Agile doesn't scale" are some of the common ones. If you take the time to understand, like I have recently, you will realise that Agile has structure for dealing with the processes and disciplines that the PMBok describe. The PMBok is very general and, as the title describes, and only provides a guide to manage projects from building bridges to software development. Agile fills in the 'how' for software development and so the two can exist happily together.

I really would like to use Agile, how can I explain the benefits between Agile and Waterfall in a simple way ?

I recently attended the Sydney Scrum User Group and we worked through an exercise, which was an analogy for one of the difference between a waterfall approach and a scrum/agile approach. Rather than pinch the idea, here is my contrived story to explain the difference. Think of sandwiches in terms of software features, and a tray as a release or increment, and it might all make sense - then again maybe not.

Scenario 1. Making sandwiches the waterfall way.

Requirements.
Customer sends a fax at 9:00 am in the morning he needs vegemite sandwiches for 100 people for an event at lunch. Deliver to the office at 11:30.

Development.
You get a production line started, one person buttering and spreading the vegemite, the next person slicing and arranging on a platter. By 10:30 you've spread 75 sandwiches with vegemite, when the customer calls in to check on progress.

The customer suddenly remembers that, not everyone likes vegemite. So ask for half to be roast beef. Rather than 25 vegemite sandwiches end up in the bin the client agree to increase his order by 25 sandwiches to get the 50 roast beef sandwiches.

User Acceptance.
You turn up at the customers office, he looks at the platter and it looks a little plain then remembers that he has some vegetarians turning up who don't like vegemite! You quickly call the guys at the cafe and get them to quickly make another 25 sandwiches, this time cucumber.

Sign Off.
The customer is happy, but it cost him 150 sandwiches and you've expended 150 sandwich making effort. There is only 100 people so there is a lot of sandwiches left over that are not used.


Scenario 2. Making sandwiches the agile way.

Requirements.
Sometime later the same customer faxes another order, this time you try a different approach.
You invite him to come to the cafe and tell him he can use the wi-fi and he'll get a coffee on the house while he waits. You sit down with him and ask your usual catering questions. How many people ? are there any vegetarians ? The barista overhears - and suggests that to cater for vegans and wheat intolerance and through your many years of experience you estimate that 75 sandwiches should be enough for 100 people.

Development.
You start making sandwiches one at a time. As each tray of sandwiches is made you show the customer. You have made 50 sandwiches (two trays). When you overhear the customer exclaim - bugger!

He's just got an email. The meeting has been rescheduled until the afternoon. You suggest to him that for an afternoon meeting cakes might be more appropriate and so decide that 50 sandwiches and 25 cakes would be plenty. You stop making any more sandwiches and the and start slicing cake.

User Acceptance
The customer has seen the first tray of sandwiches as they have been made. He quickly checks the cakes as they are being arrange - all is looking good.

Sign Off. The customer is happy and pays. You suggest that he takes one tray of sandwiches to put in the fridge on the off chance that some of the attendees didn't get the rescheduled meeting notice. After all they are already made - he might as well take them.


Let me explain the difference

Scenario 1 - the customer didn't really understand what he wanted until he started thinking more about his needs when he saw the entire finished platter. He ended up with more food than he actually needed and there was a certain amount of waste. The sandwiches were all produced in great big block so there is little flexibility in changing the fillings during the making of the platter.

Scenario 2 - the customer also did not understand what he wanted, but as he was available in the coffee shop he could actively participate and give the sandwich makes feedback as his requirements changed, like when the meeting was rescheduled. There was little to no waste in the construction and as the platter was made in smaller, fully complete, chunks. In fact, so complete that the customer could actually take part of the order with him and realise that value earlier.

Summary.

You can see for the examples that when the customer is involved more closely with the production of the sandwiches that the whole team is more able to quickly adapt to the changing situation. Have smaller, fully complete, increments allowed for the customer to start using the end product quicker. The customer only paid for what he actually needed.

The trade off.

The customer/product owner has to commit to spend time working with the team. If the product owner, the person with ultimate responsibility to steer the results of the software development effort, doesn't have the time or inclination to work in an agile way then waterfall my still be the most appropriate method for your situation.

There is a lot more to agile than one post. Hopefully this post has given you a small insight and taster into Agile. Let me leave you with one last thought.

Image you have two project, one waterfall and one agile. Imagine a time of economic uncertainty. Imagine both projects are canceled half way through. Which project will be able deliver value to the customer in the form of working software.

Answers on a postcard...(or comments)