why agile - ing bootcamp
DESCRIPTION
This is the presentation I used to inspire a group of highly motivated people at ING about the agile mindset.TRANSCRIPT
WHY > HOW > WHATAn agile approach to business
Who am I
Agile/Scrum - Lean/Kanban Trainer and coach...Software craftsman and technical coach...Motivation 3.0 enthousiast...Passionate father, musician and gamer...
Erik Talboom
@talboomerik
In/talboomerik
Why start from the why?
Easy Problem 1 stakeholder
1 request of 240 person days
12 member team
1 month
A harder problem 3 stakeholders
3 requests of each 240 person days
12 member team (3 sub-teams of 4ppl to allow focus)
3 months
What is our stakeholder thinking? Why does something that used to take 1 month, now take 3?
I’m willing to pay for 240 person days, why do you want me to spread it over 3 months?
What are our business managers thinking? Now you want me to forecast 3 months instead of just 1?
Look, the market changes a lot in 1 month as it is!
What are we managers thinking? Well, this is complex stuff...
UI, middle tier, dataflow, enterprise data, security, use cases, business rules, workflow, object-oriented, SOA...
It would be more efficient for me if we reorganize the work a bit... Break it down into skill area’s
So we come to...
Which becomes...
And now?
Matrix Resources to ProjectsProject 1 Project 2 Project 3 Project 4 Project N
How did we get to be Agile?A bit of history…
Computer Programming
Software Engineering
Agile Development
1950
1960
1970
1980
1990
2000
2010
The Agile Manifesto
No process needed
Tools aren’t important
Processes and tools to help you, not stand in your way
Processes and tools as a means, not a goal
Improvement through interaction
Talk about things, don’t just roll over and play dead
No documentation
Documentation should have a purpose beyond existence
Documentation is not customer value added work
Documentation supporting software
No contracts or written agreements
Let the customer figure it out
No release planning
Build trust working together with the customer
Share the product vision
Be transparant to your customer
Don’t plan
Block all change
Understand reality: things change
Make sure you can incorporate change as easy as possible
Make your customer aware of the reality of change
Force Field Analysis
Individuals & Interactions Processes & Tools
Working Software Comprehensive Documentation
Customer Collaboration Contract Negotiation
Responding to Change Following a Plan
Powerfull tool = scientific learning method!
Plan Do Check Act
Deming CycleLean - Kaizen
Agile - Scrum
Iteration Plan
Iteration ReviewRetro-spective
Scientific Method
Hypo-thesis
TestObservationAnd Inference
Confirm,Modify,Discard
Planning
AnalysisArchitecture, Infrastructure
Coding
Design
Testing
Performance
User Acceptance
Pilot
Live
Feedback cycles
Why so much on learning & feedback?3 Things we wish were true…
The customer knows what he wants
The developer knows how to build it
Nothing will change among the way
3 Things we have to live with…
The customer discovers what he wants
The developer discovers how to build it
Many things changes along the way
Iterative waterfall
© Jeff Patton, all rights reserved, www.AgileProductDesign.com
1 2 3 4 5
Incrementing calls for a fully formed idea.
And, doing it on time requires dead accurate estimation.
Gradually refining the product
© Jeff Patton, all rights reserved, www.AgileProductDesign.com
1 2 3
A more iterative approach allows you to move from vague idea to realization making course corrections as you go.
4 5
It’s not about speed
It’s about flexibility
Erik Talboom
@talboomerik
In/talboomerik
http://agilemanifesto.org
http://pmdoi.org
http://manifesto.softwarecraftsmanship.orghttp://blog.co-learning.be