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 AcceptanceThe 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 differenceScenario 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)