5. Once upon a time…
70 ‘s
Waterfall
created
Scrum
createdRate of Business Change
Accelerates
2013199390’s
Scrum
Dominate
Light weight
Methodologies
arise
2001
agile
Manifesto
created
The New New
Product
Development
Game
1986
7. What was special about them?
• They were all succeeding
• What was different?
• ‘Light-weight Methodologies’
8. Exercise: Presto Manifesto
1. Define a successful project
2. Self-organise into equal-sized cross-functional teams
3. Create a list of ‘critical elements of successful projects’
4. Reach team consensus & sign those that they agree with
5. Review similarities between teams
6. Review similarities to the agile manifesto
9. Agile Manifesto – Value Statements
Process and tools
Individuals and
interactions
over
Following a planResponding to change over
Comprehensive
documentation
Working software over
Contract negotiationCustomer collaboration over
Full Manifesto: http://agilemanifesto.org/
1970 – Winston Royce paper of software engineering published, later on people started to call it ‘waterfall’
80s onwards Rate of change increases significantly in business
1986 - Hirotaka Takeuchi and Ikujiro Nonaka – The new new product development game, published, it has many elements that are in Scrum.
90s rise of the ‘light weight methodologies’ (93 Scrum) http://en.wikipedia.org/wiki/Lightweight_methodology
Feb 2001, 17 software developers created the agile manifesto
2013 Domination of Scrum
Try to inject some humour… for example the red logo with the hat is his professional logo on his web site, would you trust that?
Maybe share an anecdotal story about one of the people. Say who they are.
From top left, anti clock wise
Jim Highsmith – Adaptive Systems Development
Kent Beck – TDD, extreme Programming
Ward Cunningham – Wiki, Fitnesse
Ken Shwaber – Scrum
Martin Fowler – extreme Programming
Ron Jefferies – Extreme Programming
Alistair Cocoburn - Crystal
In the 90’s and since they were delivering projects that delighted their customers, surrounded by IT projects failing left right and centre.
1. Define outcome of a successful project.
Games from http://tastycupcakes.org/2009/06/presto-manifesto/
Timing: 10 mins
Ingredients:
Whiteboards and/or flip-charts
Markers
Recipe:
Begin by defining what success on a software development project means. Is it only about being on time and on budget? What about customer satisfaction? Divide the participants in to groups and ask them to, based on their project experiences, come up with a list of criteria that they have noticed as critical elements on successful projects. Ask them to reach a consensus within their team and have each member sign off on the criteria they agree with. Look for patterns between each team’s list and then discuss. Compare each teams list with the list that the 17 signatories of the agile manifesto came up with. You will be surprised at the results, regardless of the participants experience with agile. You will rarely see any team come up with prescriptive practices and I have yet to come across a list that did not include customer collaboration, communication, and team dynamics.
Learning Points:
The agile manifesto is a set of factors that are considered common on successful projects.
These successful factors are not entirely new to our industry.
The agile manifesto does not prescribe specific practices, reaching a wide consensus on these would be very hard.
You should know this slide inside and out.
discuss what the problem is (not the right people involved, too many people etc) and try to find a solution that involves people and how they interact vs using a new tool without understanding the problem.
Tracking working software vs tracking documentation.
Internal vs external customer. Working together and starting early.
Respond to all kinds of changes e.g. team, feedback, tooling, +ve/-ev, solutions
Agile is a great idea, but hard to follow. Most people want a simple process / guide to follow.
Agile is a great idea, but hard to follow. Most people want a simple process / guide to follow.
Ask the attendees for examples from each quadrant, helping them out as need be. The full set is revealed on the next slide.
Credit: http://lisacrispin.com/wp-content/uploads/2011/11/Agile-Testing-Quadrants.png
Agile is a great idea, but hard to follow. Most people want a simple process / guide to follow.
Agile is a great idea, but hard to follow. Most people want a simple process / guide to follow.
Agile is a great idea, but hard to follow. Most people want a simple process / guide to follow.
Agile is a great idea, but hard to follow. Most people want a simple process / guide to follow.
Agile is a great idea, but hard to follow. Most people want a simple process / guide to follow.
Agile is a great idea, but hard to follow. Most people want a simple process / guide to follow.
Agile is a great idea, but hard to follow. Most people want a simple process / guide to follow.
Agile is a great idea, but hard to follow. Most people want a simple process / guide to follow.
Agile is a great idea, but hard to follow. Most people want a simple process / guide to follow.
Agile is a great idea, but hard to follow. Most people want a simple process / guide to follow.
Agile is a great idea, but hard to follow. Most people want a simple process / guide to follow.
Agile is a great idea, but hard to follow. Most people want a simple process / guide to follow.
This is why, managers get excited about ‘agile’, they have been sold on this value proposition. This is what managers are being sold on for agile.
You should know this slide inside and out.
Reduce risk by providing quick feedback. Feedback on features, team fit, technology, other potential issues
Visibility – tracking working software vs artefacts i.e.documents
Adaptability –
Business Value – validating working software by business people.
