[Srijan Wednesday Webinars] How to Deal with Emergencies in a Lean/Scrum Team

How to Deal with Emergencies on a Lean/

Scrum Team

Mr. Avienaash Shiralige @agilebuddha

Blog: www.agilebuddha.com

Content Copyrights Owned By Agile Buddha - www.agilebuddha.com

http://www.agilebuddha.com


Copyrights Protected - AgileBuddha


!• I have 18+ years experience in IT Product & Service

companies in various leadership roles !• Agile Transformation Consultant, Trainer and Agile Coach !• I share my opinions and experiences of applying Agile and

Lean thinking in transforming organizations on my blog: http://www.agilebuddha.com !

• Consulting clients in Australia, Europe, US and India !• Developer, Tester, Dev Manager, Product Owner, BU head,

Director..... !• No-schooling my daughter, Organic Farming, Natural

Birthing, No Vaccinations etc are my interest !

• I live in Goa, India

Me - Avienaash Shiralige - Founder, Writer - Agile Buddha


http://www.agilebuddha.com/


Problem Context

• Traditional waterfall projects

• Development team never had to deal with maintenance - had a separate team to handle this

• Maintenance team had to deal with the non-sense developers created - “Developer had all the fun without hangover afterwards”

• Agile projects

• Teams start delivering early and often

• Maintenance/Enhancements starts post couple of sprints

• Planning becomes hard for the upcoming sprints



The Problem

• Production incidents and other unplanned mayhem consume team’s time and hence team unable to achieve sprint goal



The Goal

To absorb a reasonable amount of uncertainty, striking balance between robustness and speed.



Approach 1 - Perform Triage - And Reject

• Is this a real production emergency? Many times they are not.

Examples of non-incidents:

• Sales team coming with “the deal of the century”

• Stakeholders upgrading normal requests to production emergencies in an attempt to bypass backlog negotiation

• There may be a genuine need, but that does not make it classify under production emergency



Strong Product Owner

• Is this is a genuine production request? Fix it.

• More often issues require very strong triage and hence strong, decisive PO who can convince stakeholders

You can always wait for 2 weeks to get a new feature.



Approach 2 - Perform Triage - And Defer Fix Until Next Sprint

• Some issues are there in the system for a long time, but when they are found, needs a immediate fix

• Such issues can be pushed to later sprints and having short sprint duration can be very useful in such negotiation

• If you can defer the problem to the next sprint, then team will pick it up as per regular process

• Next to the decision of reject, a good PO will make sure everything that can be deferred will be Deferred.



Approach 3 - Reserve a Buffer To Deal With Unexpected Issues

• If you have done Solution 1 and 2, whatever left are real issues that have to be fixed ASAP.

• Reserve a buffer of points or time for unplanned work

• Start with 80% capacity - planned work and 20% - unplanned emergency work



Buffer Rules:

• If buffer is more than 1/5 of velocity, then it will leave big gap in the capacity planning. Keep it small.

• Buffer is NOT for backlog items

• Buffer needs to be protected from unintended use(Stakeholder smell a workaround in the regular process). So perform good triage!

• Buffer overflow/underflow: Measure how much buffer is used to plan upcoming sprints/releases



Approach 4: Fix Root Causes, Improve Quality

• Solution 1/2/3 are in logical order to control damage

• Fix issues so they stay fixed, build-in quality so that you don’t have emergencies at all!

• If you overflow your unplanned emergencies buffer, then you have no business in continuing the sprint. Abort Sprint!

• Instead, use the sprint to fix the root cause



Tip: Size The Team Right

• Small team performs better as it has less overheads, but it is less robust against losing members

• 10 person team losing 1 person is 10% productivity loss

• 3 person team losing 1 person is 33% loss!

• Sweet spot is 7-9 people - Small enough to absorb overhead, large enough to absorb some loss



Approach 5 - Swap Not Started Items

• Apply MoSCoW principle

• Include all “must haves” and some “should haves” in a sprint

• Hence “should haves” become your buffer

• PO decides if emergency is more or less important than a “should have”

• Swap with not started similar size item



Approach 6: Consider Using Kanban

• If team is doing more maintenance than new features, then Kanban

• Scrum Board - long term features

• Kanban board - short term changes, maintenance, support etc.



Conclusion

• All these tricks are dependent on context

• Have a broad range of options to chose from

• If it is a large team working on the product, then you can try to break them into

• Scrum team - Working on strategic long term features

• Kanban team - Working on tactical short-term changes



Product is in Pivot - Business Emergency

• Product has to go through a course correction in terms of vision, market segment and features

• Product team must be very good with product discovery

• Ability to-do as many iterations of idea as possible before you run out of money or patience

• The challenge lies in figuring out who cares about your incredible new product

Few famous business pivots - Twitter, Flickr, Groupon, Nokia, Star Bucks, HP, Instagram

http://www.forbes.com/sites/jasonnazar/2013/10/08/14-famous-business-pivots/


http://www.forbes.com/sites/jasonnazar/2013/10/08/14-famous-business-pivots/


Lean Start-up: Build - Measure - Learn

The primary measure of progress during discovery isn’t delivery velocity, it’s learning velocity.

When you’re doing discovery right, it could look a little like this team at the Nordstrom Innovation Lab.


https://www.youtube.com/watch?v=szr0ezLyQHY


Product is in Pivot - Engineering Impact

• Engineering teams also need to make course corrections to deal with this uncertainty

• Stop developing new features without validating markets

• Prototype new ideas with quick turn-around

• Sometimes building more demo-able Over shippable features

• Prefer “speed Over perfection” in engineering

• Engineering teams need to re-look at few practices like

• Automating tests for new features

• Hard coding Over building generic solutions/frameworks

• Product lacks roadmap during this stage. Hence moving to short sprints or to Flow model like Kanban helps reduce Build-Measure-Learn feedback loop.


Mr. Avienaash Shiralige @agilebuddha

[email protected] www.agilebuddha.com

Thank You!

Take this conversation online by tweeting using the hashtag #SrijanWW

mailto:[email protected]


Technology

[Srijan Wednesday Webinars] How to Deal with Emergencies in a Lean/Scrum Team