Agile in waterfall
8
To be agile in a waterfall setting. Some reflections from a successful case. Fredrik Wiik
description
Fredrik Wiiks presentation om sin roll som programledare hos kunden i ett utvecklings/leveransprojekt där agil arbetsmetodik framgångsrikt kombineras med fasta leveranspunkter och PROPS som projektstyrmodell. Kunden är ett av våra största företag och leverantören har utveckling både i Sverige och Vietnam. Fredrik kommer belysa ett antal kritiska framgångsfaktorer och beskriva hur man lagt upp arbetet för att optimera mot de leveransmål som satts upp och skapa en förutsägbarhet gentemot projektets intressenter. Fredrik är managementkonsult på Knowit Management och specialiserad mot skalad agil utveckling och innovation
Transcript of Agile in waterfall
To be agile in a waterfall setting.Some reflections from a successful case.
Fredrik Wiik
2
Why an agile way of working?
• Fixed deadline and clear mission statement!(Auftragstaktik, Helmut von Moltke)
• If we don`t start coding very soon we miss the deadline!
• To learn from the feedback loops is crucial when building a world class system from scratch!
• A skilled team used to agile ways of working.
3
Touch points.
• The important start.
• The interation with the waterfall process.
• Stakeholder communication.
• A dynamic approach to the product owner role.
• Take ownership over the acceptance process.
4
The important start.
• Establish trust and align forces on how to execute.
• Make sure the team understands context and purpose to release the power of these knowledge workers!
• Story mapping a la Jeff Patton, building the first slice of the system.
• Initiate the sprint cycles!
5
The interation with the waterfall process.• Project responsible for budget governed by waterfall
model, intial rough estimation from supplier.
• The requirement were kept on the mission statement level.
• Focus on describing how the project will work with requirement management throughout the project.
• For the delivery, roll-out and close down activities, business as usual (but do you really want to close now ).
6
Stakeholder communication.
”We need to run a few sprints to understand our speed.”
Bi-weekly sprint videos! Broad user group. Focus groups evolve.
Business on board!
Cooperates with steering group.
7
Our dynamic approach to the product owner role.
• Fact: Role descriptions stated who should decide upon IT requirements.
• At a minumum that person must agree on the acceptance criterias for the user stories and sign them off.
• Make sure persons with relevant input, influences how to evolve the solution.
8
Take ownership over the acceptance process.
