Powerpoint from my speak at Agile ME 2017, about how to optimize your agile process, by having an agile approach to your process as well as your product.
Uncommon Grace The Autobiography of Isaac Folorunso
Agile ME 2017 - Pimp my Agile
1. Agile ME 2017 - Rasmus Runberg
Pimp
my
Agile
Rasmus Runberg
2. Agile ME 2017 - Rasmus Runberg
Sponsors & partners
Sponsors & partners Bronze sponsor
Supporter
Media partners
3. Agile ME 2017 - Rasmus Runberg
People
Rasmus Runberg
• Product Owner
• Working agile for more than 6 years
• Background as classic Project Manager
Fellow
• UAE based community of people being
passionate about agile software
development
4. Agile ME 2017 - Rasmus Runberg
Why the title?
“Pimp my Ride” where a MTV TV-
show from 2004 to 2007, where
people’s old rusty cars where
“pimped” into cool rides.
5. Agile ME 2017 - Rasmus Runberg
What’s the goal?
Empowered employees
• Happy engaged employees
• Better solutions and better
quality
• United teams
• Etc.
Ability to evolve and adapt
• MVPs and frequent deliveries engages
the client and creates transparency
• Feedback to the team(s) creates
understanding and purpose
• Ability to change with an ever changing
world
• Etc.
6. Agile ME 2017 - Rasmus Runberg
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
+ Twelve principles
The Manifesto
11. Agile ME 2017 - Rasmus Runberg
The Manifesto
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
+ Twelve principles
Individuals and interactions over processes and tools
Responding to change over following a plan
12. Agile ME 2017 - Rasmus Runberg
Modern agile
Safety is both a basic human need and a key to unlocking high
performance. We protect people’s time, information, reputation, money,
health and relationships
You can’t make people awesome or
safe if you aren’t learning. We learn
rapidly by experimenting frequently.
We make our experiments “safe to
fail” so we are not afraid to conduct
more experiments.
This includes the people who use, make, buy, sell or fund our products
or services.
Anything that isn’t delivered isn’t
helping anyone become more
awesome or safe. In modern agile
we ask ourselves, “How could
valuable work be delivered
faster?”
14. Agile ME 2017 - Rasmus Runberg
So, what is the “Agile Process”
Is being agile only about our Product
Development?
If no, how do we apply the Agile Product
development to our process?
15. Agile ME 2017 - Rasmus Runberg
So, what is the “Agile Process”
16. Agile ME 2017 - Rasmus Runberg
So, what is the “Agile Process”
What would be your Minimal
Viable Process?
Focus on deliveriesWorking software
Collaboration
Open to changes
17. Agile ME 2017 - Rasmus Runberg
Be agile about your process
Key Stones in
Agile Software Development
• Deliver running software
• Learn fast
• Interaction and collaboration
• Welcome changes
Create your Minimal Viable Process:
• Focus on delivering value
• Make learning and experimenting
part of your daily routines
• Facilitate team communication
• Use the feedback!
18. Agile ME 2017 - Rasmus Runberg
… And then you can add to
the process
Be explicit about your additions
Run it as experiments
Get feedback!
Learn and adapt
If the additions or change doesn’t create
value, stop doing it!
19. Agile ME 2017 - Rasmus Runberg
Experiment examples
Sprint length
SCRUM vs. KANBAN
Review
Backlog refinement /
User story grooming
Retrospectives
Planning
Backlog management
Process Tools
20. Agile ME 2017 - Rasmus Runberg
Experiment examples
Sprint length
SCRUM vs. KANBAN
Review
Backlog refinement /
User story grooming
Retrospectives
Planning
Backlog management
Process Tools
How long should your sprint be?
Should length of the sprint be the same
every sprint?
21. Agile ME 2017 - Rasmus Runberg
Experiment examples
Sprint length
SCRUM vs. KANBAN
Review
Backlog refinement /
User story grooming
Retrospectives
Planning
Backlog management
Process Tools
SCRUM or KANBAN – Or SCRUMBAN?
When can KANBAN be a better option
than SCRUM?
Do I need to strictly follow one
or the other every time?
22. Agile ME 2017 - Rasmus Runberg
Experiment examples
Sprint length
SCRUM vs. KANBAN
Review
Backlog refinement /
User story grooming
Retrospectives
Planning
Backlog management
Process Tools
How should I facilitate reviews?
The usual “board meeting”?
What brings value to your stakeholders?
Who are your stakeholders?
23. Agile ME 2017 - Rasmus Runberg
Experiment examples
Sprint length
SCRUM vs. KANBAN
Review
Backlog refinement /
User story grooming
Retrospectives
Planning
Backlog management
Process Tools
When do you do your refinement /
Grooming?
Who’s in charge of this work?
How well should a user story be
groomed?
24. Agile ME 2017 - Rasmus Runberg
Experiment examples
Sprint length
SCRUM vs. KANBAN
Review
Backlog refinement /
User story grooming
Retrospectives
Planning
Backlog management
Process Tools
Are the purpose of the Retrospective the
same every time?
Should the agenda then be the same?
Are Retrospectives always at the end of
the sprint?
25. Agile ME 2017 - Rasmus Runberg
Experiment examples
Sprint length
SCRUM vs. KANBAN
Review
Backlog refinement /
User story grooming
Retrospectives
Planning
Backlog management
Process Tools
At planning do you take one item at the
time from the top of the backlog?
Who do the actual planning?
26. Agile ME 2017 - Rasmus Runberg
Experiment examples
Sprint length
SCRUM vs. KANBAN
Review
Backlog refinement /
User story grooming
Retrospectives
Planning
Backlog management
Process Tools
Who creates your user stories?
- The PO?
- The Developers?
- The Client?
How many items do you have in your
backlog?
27. Agile ME 2017 - Rasmus Runberg
Experiment examples
Sprint length
SCRUM vs. KANBAN
Review
Backlog refinement /
User story grooming
Retrospectives
Planning
Backlog management
Process Tools
What backlog tool do you use?
Jira? - Trello?
- And why?
28. Agile ME 2017 - Rasmus Runberg
Be careful, it’s my
experience
Keep
your DS
Involve
the team
Not everyone loves
changes
N
Please
don’t
Great statements but it isn’t really a process - It doesn’t truly say anything about “how”. So what do we do then?
SCRUM - Most people try to follow the SCRUM process. It has been the default “Agile” process
Kanban - Great alternative to Scrum, and w
So if you would like to scale, LeSS is in my opinion a great way to get started
Very complex and strict process - But is it an Agile process?
So how do the process or frameworks we have just seen match with the Agile Manifesto?
If we strictly follow either of them, are we then truly Agile?
Individuals and interactions over processes and tools tells us that we should do the exact opposite. We shouldn’t just follow a process!
And if we shouldn’t follow a plan, should we then follow a process?
Modern Agile (I can truly recommend to read more about) actually takes it a step further. They talk even less about process, and much more about people and the value.
And much much more. It’s important that you identify what is the core values of your team!
Focus on delivering value: So the process should support frequent deliveries of user value? - Not focus on tech?
Learning and experimenting: Safe to “fail”fast? Innovation? Spikes?
Team communication: So it is important that we talk! Alignment, pair-programming etc.
Feedback: Evaluate and adapt!
Make sure everyone understands that we are testing a specific change
In experiments it’s okay to fail and it isn’t permanent
Listen
Evaluate
If you can’t prove a value - Stop doing it!
Almost every part of your “process” can be changed and/or removed according to your specific situation.
KANBAN is very useful if you con’t have a clear velocity (for an example during holidays) and when you have many small stories - Or when you have a new team where velocity is unknown.
And combining the two is great - How many open stories should you have at the same time during your sprint? KANBAN helps focusing on closing user stories.
Value cafe?
Market place?
If you have different stakeholders should you keep it as one or several meetings?
Mike Cohen says 5 - 10 % works should be spend on this - But does that apply to all teams / products? Where are you in the product lifecycle? - In the beginning of a new product you usually have more unknowns.
Rule of thumb says that 2/3 of a stories tasks should be known.
And when do you split your story into smaller ones?
Try to do it differently - Main goal is usually to make sure everyone is being heard
If no one speaks up, use “Jimmi cards” / Inspiration cards by Lyssa Adkins
(Everyone draws a card with a question, like: Who helped you the most this sprint and why / What where the most difficult task this sprint and why .. etc.
If you only take from the top, how do you make sure there are synergy in your tasks?
Do you set a sprint goal?
How do you balance tech depth, maintenance, developer wishes and new features?
Is the PO present all the time?
