Andreas Enbohm Capgemini Sverige AB Agile in Practice

Andreas EnbohmCapgemini Sverige AB

Agile in Practice

© 2004 Capgemini - All rights reserved2007, October – Andreas Enbohm

Agile in Practice

- What is Agile and why should I care

- My experience with different Agile development methods

- B’s and C’s

- Q & A

Agenda


Why Should I Care?

2000 – 72%* of all software projects fails on deliver on time and on budget

2003 – 70%*

2005 – 52 %* of all IT Project cost 189 % of their original estimates Traditionell engineering:

Architects -> Designer ->

Constructors -> Testers ->

DONE

Why so much failure? – well software in NOT hardware...that why it is called soft...

In SW-engineering- business rules changes- new technologies (e.g. AJAX/scripting/mash-ups) arises- the marked changes rapidly- customer changes their (already) complex requirements- unclear objectives- lack of user input ...

So, it this my situation? (probably...)

* According to Gartner Group


Agile – What is it?

”In evolution, it is not the wisest nor the strongest who survives but..

...those who can respond most rapidly to change”

Agile = lättrörlig, vig

Agile – a common MIND SET for several development methods such as Crystal Clear, Scrum, eXtreme programming, AUP, Test-Driven Development, FDD, Lean ...

Agile

XP TDD Scrum Crystal Kanban



My view of Agile First some myths...what it is NOT:

- ”We’re using JUnit - > we’re Agile” - ”We’re do no document things - > we’re Agile” - ”We’re using continous integration -> we’re Agile” - ”We’re not telling our customer when or what we are delivering - > we’re Aglie” - ”We’re programming in pair - > we’re Agile” - ”We have no plan/documets/architecture - > we’re Agile” - ”We have no disciplines whatsoever -> we’re Agile”

But, what is it then?



IBM – Alistar Cockburn – Simple, light development process

eXtreme Programming (XP) was beginning to get popular, TPS/Lean 2001 – 17 sharp people met (Beck, Fowler, et al.) and founded ’Agile Manifesto’

(http://agilemanifesto.org/)

- Individuals and interactions over processes and tools - Working software over comprehensive documentation - Customer collaboration over contract negotiation - Responding to change over following a plan

(That is, while there is value in the items on the right, we value the items on the left more.)

This is the MIND SET!



Our highest priority is to satisfy the customerthrough early and continuous delivery (“gör kunden nöjd genom kontinuerliga leveranser”) of valuable software.

Welcome changing requirements, even late in development. Agile processes harness change for (“utnyttja förändring till kundens fördel“) the customer's competitive advantage.

Deliver working software frequently, from a couple of weeks to a couple of months, with a (“iterativ utveckling”) preference to the shorter timescale.

Business people and developers must work together daily throughout the project. (“verksamhetskunniga + utvecklare arbetar tillsammans dagligen“)

Build projects around motivated individuals. Give them the environment and support they need, (“motiverade individer är den främsta frangångsfaktorn”) and trust them to get the job done.

The most efficient and effective method of conveying information to and within a development (“effektiv kommunikation helst F2F”) team is face-to-face conversation.

Working software is the primary measure of progress. (“funktionalitet är främst mått på framgång”) Agile processes promote sustainable development.

The sponsors, developers, and users should be able (“jämn arbetslast och uthållighet så längre som det behövs”) to maintain a constant pace indefinitely.

Continuous attention to technical excellence and good design enhances agility. (“kunskapsdelning – aldrig shortcuts”)

Simplicity--the art of maximizing the amount of work not done--is essential. (“enkelthet – no goldplating, no solving tomorrows problem”)

The best architectures, requirements, and designs (“självorganiserande team ger bäst problemförståelse+lösning”) emerge from self-organizing teams.

At regular intervals, the team reflect on how to become more effective, then tunes and adjustits behavior accordingly. (“retrospective – ständig förbättning”)

Principles in Agile Manifesto


Agile - What is it?

How to achive this? Satisfied customer, Allow Change and Build Quality SW by

- Continous Integrarion - Test driven - Refactoring- Pair-programming (if applicable)- Skilled motivated programmers (working cross-cut (design, analys, build, etc))- Automatic code analyse tools - Involving the customer continous- Deliver SW in iterations, 2-6 week lifecycle (short better)- Code reviews

Way of Planning- Low level details plan early in the lifcycle does not often work (as the world around changes rapidly)- A new way for PM to write plans- They exist, but are more high level and easy to change (weekly plans, monthly plans)- Requires continous updating

Documents- Exist, but remember to ask yourself – is anyone going to read this? (Jmf anti Agile RUP)

- Incorrect documentation is worse than no documentation Continous Attentions

- Short meetings every day, what are you working on?- Teach other less skilled in the group, share your knowledge

Work Together

- Invite customers to meetings - Business analyst, customers, developers, testers should collaborate continuous to get feedback from each others and thereby react to problems, changes, AND adapt!


Agile – My Experience

My experiences and conclusions

- worked in several project with XP, RUP and TDD (~7 years)- various seminars and conferences- certified Scrum Master

Stand-up meetings daily (max 15-20 min) Public code review once a week Inviting customers attent to meetings Frequent releases of working software (plus feedback) Continously discussion problems with all members within the development team (pair

programming when needed) Teaching the customers about how we deliver iterative SW (this was much

appreciated). Inform him/her immediately and act! Early identify ”Spikes” (derived from XP) and early verify that the architecure holds It better to inform the customer early that we can not deliver this particular SW (within

time limit or at all), than to tell this to the customer in the end of the project Agile often requires MORE discipline than traditionel processes!

- Try to no diverge from the process (even in stressed situations)


Agile – My Experience

Use Case/User Story:

”User selects a document to check in. User writes a comment, clicks on ’Check-In”-button and the document checks in with a new version number”

This was broken down into tasks max 30 h which all together was the UC, eg.

- prepare the UI - build Applet to be able to read/write to user’s hard drive disk- authentication + authorization (is the user allowed to check in this document)- transfer custom properties to the MS Word document when applicable- write service classes to manage all these tasks

We could deliver these tasks in three iterations (2 weeks intervals) where the users could test part by part. This led to fast feedback (e.g. the GUI was changes 3 times before approved)

Easier to see the different problems when delivering in short invervals, e.g. the Applet handling the check-in/out mechanism needed to be signed with special certificates

Focus on layering (forced to do layering) because of the different people involved. TDD! Many developers could be involved in this (GUI designer for the UI, MS-Office experts

for the property handling, developers for the business logic) - > Many people got a quite good understanding on how the document handling mechanism worked

During code reviews, inconsistent logging and transaction handling was disovered (among other things)

Amazingly few bugs considering the new technologies involved


My conclusions Agile mind set works in ALL companies and in ALL project (its much about common sense) Scrum does NOT work in all companies/projects, nor do RUP, XP, Chrystal, ... Benefits

- Easier to deliver on time - More fun to work with (developer AND customer satisfaction)- More responsibility- More control and easier to respond to change- Less hiearchy- Let all developers be more involved in all parts of the system (kort uppstartsträcka)- You get to learn a lot (my fist project was with XP)- Customer could add ’free’ featues

Concerns

- Does not scale to large project? May be true in some cases but has been proven in large project (requires more of the involved people)- People are located in different sites- ’Cowboy coding’ – less rules combined with unclear mind of Agile may somethimes make the code less structured-The architecture may somethimes suffer- Difficult if the customer is always unavailable or not interested in collaboration- Important to have people well familar with in the Agile mind set - Customers not always happy to hear when a feature could not be delivered / as they expected

But how do I get the silver-bullet?

- Be aware of the problems that exist in SW dev. A change is STILL NOT GOOD- Think what Agile represents (people, software, collaboration, adaption) and what can I do to fulfill these principles- Start in small steps – what can XP offer me, what can Scrum offer me, what are ”best practices”?- Look at current situation and CONTINOUS make small adjustments

Agile - B’ and C’s


Remember – ”A fool with a tool is still a fool” – a process can never replace skilled developers


Agile – Still Sceptical?

No use listing success stories from various companies, google the Internet (there are many)

Reports show that the success rate is between 65-75 % in Agile projects (on time and on budget).

Q & A