Managing client expectations of agile in commercial software projects
•Télécharger en tant que PPTX, PDF•
2 j'aime•1,751 vues
The word ‘agile’ has become one of those software development buzzwords that people use but do not fully understand. So how do you manage expectations for clients who are new to agile or do not fully understand the agile methodology? And, does agile work for every project? This session considers how to define an agile project methodology that fits client needs and will deliver project success. This presentation was first presented by Steve Adams at Agile on the Beach.
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (19)
Similaire à Managing client expectations of agile in commercial software projects
Similaire à Managing client expectations of agile in commercial software projects (20)
Dernier
Dernier (20)
Managing client expectations of agile in commercial software projects
- 1. Managing client expectations of Agile in commercial software projects Steve Adams Project Delivery Manager MSM Software @msmsoftware MSM Software www.msmsoftware.com/blog
- 2. MSM Software MSM specialise in taking complex business problems and turning them into workable and intuitive software solutions for corporates, charities and companies looking to achieve growth.
- 3. About me
- 4. The UTMB – Waterfall or Agile? ”Keep putting put one foot in front of the other, and you will reach the finish line”
- 5. Setting the scene Successful agile examples are typically in-house / internal deliveries But we are an external supplier bidding for client projects against an RFP The RFP is typically risk-averse, requiring a fixed price for a fixed outcome. How do we overcome this fundamental obstacle to Agile delivery?
- 6. The main areas of focus for today
- 7. The main areas of focus for today Identifying Agile fundamentals that are challenged by commercial realities Understanding what it is clients actually want from Agile delivery Identifying how to satisfy client’s Agile expectations despite the challenges Examples of projects delivered successfully using Agile techniques
- 9. Agile Manifesto Requirements Cost & schedule Budget & schedule Requirements Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
- 10. Pure agile and pure waterfall Waterfall Agile Requirements Cost & schedule Budget & schedule Requirements
- 11. What do our clients want? Client Requirements & Cost Agile Waterfall Agile Requirements Cost & schedule Budget & schedule Requirements
- 12. Why do clients want agile? They’ve heard that it delivers better results They want the flexibility to absorb change They want visibility of progress They believe they will get something that better meets their needs They want the option to implement features early
- 13. Why does a supplier want agile? The chance to deliver better solutions Lowers commercial risk Foster long-term client relationships It’s more interesting and engaging for developers Shorter iterations are more rewarding
- 14. How to manage client expectations
- 15. 1. Agile delivers better results “We’ve heard that agile delivers better results. Everyone is using it…”
- 16. Understand exactly what aspects of agile they like the sound of and why Explain that not all projects (or companies) suit an agile process Explain opportunities for using add value agile techniques within any process Recommend an appropriate approach based on their needs Include agile techniques within standard internal processes (build quality in) 1. Agile delivers better results
- 17. 2. Flexibility to change our minds “We want the flexibility to add change requests. Isn’t agile all about being able to add changes within the budget?”
- 18. Ensure the client involves the right stakeholders early and consistently Reduce the risk of change by effective analysis Continue collaboration and visibility during design and development A relationship based on trust will make the client feel comfortable to accommodate a contingency budget from the start 2. Flexibility to change our minds
- 19. 3. Visibility of project progress “We want to track and have visibility over how the project is progressing… ”
- 20. Regular, clear and meaningful progress updates Breakdown project into releasable iterative deliveries Maximise face to face meetings, collaboration and review sessions Ensure the client is kept aware of importance of their deliverables Use a collaborative web-based project tool such as Trello or Smartsheet 3. Visibility of project progress
- 21. 4. Solution that better meets needs “Agile development will make sure we get a solution that better meets our needs…”
- 22. Ensure the client involves the right stakeholders early and consistently Continue collaboration and visibility during design and development Provide opportunities for early beta testing Breakdown delivery into iterative releases 4. Solution that better meets needs
- 23. 5. Implement features early “We want the option to implement features earlier during the development process if priorities change…”
- 24. Break down the development into separate or incremental deliverables Ensure there is a willingness to adjust the plan 5. Implement features early
- 25. Delivering successful software projects
- 26. Assess each project delivery approach on a case by case basis. Don’t revert to pure waterfall just because it cannot be pure agile. Always take advantage of value-add agile techniques to provide the client with increased collaboration, visibility of progress and better outcomes. Always use agile techniques internally to build in quality and automate processes. Accept that client engaging in a pure agile approach is a longer term journey. The following examples demonstrate these ideas. No ‘one size fits all’
- 27. Client was looking for a local supplier to develop their fleet management system in collaboration with their internal IT team. Agile worked because: There was a strong desire to build a good relationship with regular face to face communication They knew fixed costs would limit the potential for shared development work They came with no documentation They accepted evolving requirements and wanted us to run their workshops Pure agile client
- 28. Westfield needed a bespoke web-based booking system and front end portal to replace manual processes. A hybrid approach worked because: Despite fixed requirements, the client was used to a flexible way of working outside of IT Trust and rapport initiated from the very first face to face meeting We were able to educate the client that with a flexible budget, as change requests emerged, we could safely accommodate them Westfield used an external designer so the ability to adapt quickly was key A creative client
- 29. We carry out regular developments on QBE’s high profile risk management system which is used globally. We persuaded them to adopt agile techniques: Due to the relationship built over many years, Delighted the client by providing early beta demos before development even went into testing We able to demonstrate an understanding of requirements Delivered an overall improvement in quality A waterfall client
- 30. The UTMB – Iterative approach ”Keep putting put one foot in front of the other, and you will reach the finish line”
- 31. In Conclusion
- 32. Any agile is better than none at all Where can agile add value? Project needs Supplier needs Client needs
- 33. Questions or talk to me afterwards @msmsoftware MSM Software www.msmsoftware.com/blog
Notes de l'éditeur
- The philosophy of the company is to provide quality individual business solutions through bespoke software. MSM’s engineering process and focus on quality combined with our belief that user experience is paramount enables us to forge long-term strategic partnerships with its clients. Established in 1998, MSM Software has since expanded its reach with offices in London, Bristol and Exeter so are there when you need them.
- At work I am responsible for the delivery of all projects by the technical team… But, my greatest interest is running, most recently ultra running. Here is a photo of me last weekend halfway through the Ultra Trail Mont Blanc. For those of you unfamiliar with this race, it is an iconic 104 mile running race around the Trail Mont Blanc – a walking trail of the peaks and cols around the Alps, starting and finishing in Chamonix. It took me 36 hours, running through two nights.
- I originally intended to incorporate my race into this presentation as a simple analogy for a ‘project’ that had to be delivered using the waterfall process - on the basis that the requirement is fixed (success is all or nothing) with the variables being cost and schedule. However, on closer scrutiny the actual running of the race is done using an agile approach – for a start it is broken into legs (iterations?! But not sprints!) of around 10 miles each, and each leg can be broken down further into an uphill, with checkpoint at the top, and a downhill. In each iteration there are lessons learned for the next one – getting the correct pace for one-hour uphills and leg-crunching downhills, drinking and eating the right amount between each leg, wearing the right clothes for warm valleys and ascents but cold mountain-tops. I could take the Agile thinking down to an even more granular level than this, but suffice to say, when I was going through any bad patches I repeated a mantra to myself I had recently read in an running biography – “If you keep putting put one foot in front of the other, you will get to the finish line”.
- Internal does not require a formal commercial contract or procurement process. Procurement departments are typically not familiar or comfortable with the idea of unfixed deliverables. They are used to agreeing contracts to pay a fixed amount for a fixed deliverable. It is deemed the lowest risk. To do anything else goes against the grain. But as a supplier we are not normally in a position to question this logic, and normally neither is the client department looking for the project.
- The Manifesto statement most challenging to address with a new client in the commercial world is highlighted. This is primarily due to the need for clients to have commercial certainty in their commercial engagements. This is primarily driven by the remit of a procurement department, which demands a clear set of tangible deliverables for a specified. This is commonly known as Fixed Scope/Fixed Price!
- Agile - Rather than constraining requirements, we instead constrain the cost and the schedule. Based on the provided cost and schedule, we then estimate the requirements that can be delivered. This allows us to prioritise the requirements, as it is understood that more or less than the estimated requirements might be delivered and we need to know in advance what decision to make. For comparison: Waterfall - Based on the requirements, we estimate the cost and schedule it will take to deliver those. This could be the ‘must have’ requirements only. There is no advance plan of what to do if requirements cannot be met within the estimated cost and schedule.
- Our clients want 2 things: 1. A set of requirements to be delivered (often immovable) and 2. Committed costs upfront But they also often tag on a request for an Agile development process This is out of sync with Agile methodology. So why do clients want agile? What appeals to them about it……..
- Why do clients want agile? What appeals to them about it? They’ve heard that it delivers better results eg BCS (Chartered Institute for IT) research shows that agile projects are 3 x more likely to succeed. 63% of companies said there was a quality improvement and it was ultimately cheaper and delivered fewer defects. Plus it’s the latest trend – sometime everyone wants what everyone else is talking about. Or what they think they should have because it’s the latest software buzz word. They want the flexibility to absorb change – a large complex project could take 12 to 18 months to develop. A lot can happen in that time which could impact the business and their project. They want visibility of progress – in the age of social media, Trello and Smartsheet, clients expect to be kept informed regularly They want collaboration with their software partner – with often business critical systems, it’s not easy to let go and handover to a new supplier. Clients want to be involved and responsible for driving forward successful ways to improve their businesses They want the option to implement features early – some functionality could be a higher priority or become more critical during the project
- Grand ideas, grand results
- In summary, some agile is better than no agile. So if the commercial, technical or business constraints dictate that it cannot be a pure Agile project, then the supplier needs to assess each project opportunity on a case by case basis and propose the inclusion of agile techniques where they add value and are feasible. In addition, agile techniques can be used within internal development practises, regardless of the over-arching project methodology.
- Returning to the UTMB analogy. I was previously in a quandary as to whether this illustrated waterfall or agile process. It appeared to be waterfall on the outside but agile in the detail. So, in fact similar to the scenarios described earlier. So if the real world example of a running race is comfortable being waterfall on the outside, but with agile iterations inside, why shouldn’t we be comfortable with the same scenario in a software project.
- Regardless of the commercial or project constraints, there is no project where at least some agile techniques will not add value