let your tasks flow like water!
TRANSCRIPT
Apr 2016 - Antonio De Marinis, Michael Norén
TASKMAN TRAINING
Let your tasks flow like water!
Training agendaMotivation - our success storyIntro to Agile methodologiesAgile at EEA: FlowTips and tricksTaskman roles, who does whatTaskman featuresIDM2 setupLet’s do it - Exercises
Motivation
Motivation
MotivationLost tasks in emails and excel sheets, avoid chaosProject tasks vs private tasksStay in controlBetter prioritizationClear who is doing what, no more ambiguityVisualise workMeasure progress, find bottlenecksLess meetings neededLess documentation overheadBetter feedback loop = better output
Motivation
Within any shared system we need framework and policies to avoid chaos and the depletion of the common resources (Tragedy of the commons).
The tragedy of the commons is an economic theory of
a situation within a shared-resource system where
individual users acting independently and rationally
according to their own self-interest behave contrary to
the common good of all users by depleting that
resource.
Motivation
Share lessons learned and best practices
Some definitions
Motivation - our success story
83 days
47 days38 days
17 days
Tasks got faster and faster like turbocharging our team!
28 days26 days 19 days
The process has high impact
Note the IDM2 A-Team lead time (~9 days), much shorter compared to other software teams. IT Helpdesk has the shortest (< 7h) due to the specific kind of work (non-software development).
How did we achieve this?
Motivation - our success story
🏁 Stop starting, start finishing
🔞 Limit work in progress
⏰ Fast feedback loop
Main policies:
Motivation - our success story 🏁 Stop starting,
start finishing🔞 Limit work in progress (WIP)
⏰ Fast feedback loopProject A
Project B
Finish A
Finish B
Start
Start
12 months
Project A
Project B Finish B
6 months
Finish A
6 months
Start
Start
+ task switching time
Imagine resource available: one fte developer. Work on 2 projects.
Option1
Option2
Motivation - our success story
Little’s law*:
Average lead time (LT) = Average WIP (WIP) / Average Throughput (TH)
* Little’s law was found in 1928 by John Little (Prof. MIT) in the discipline of queueing theory
It implies that increasing WIP leads to a higher LT and vice versa - check to reduce WIP to increase LT
in order to get stuff done faster, you need to work on less (on average)
🏁 Stop starting, start finishing🔞 Limit work in progress (WIP)
⏰ Fast feedback loop
Monitor WIP-limits in TaskmanGOOD BAD
Motivation - our success story 🏁 Stop starting, start
finishing🔞 Limit work in progress (WIP)
⏰ Fast feedback loop
To-do list
time
WIP = 1
Needs FeedbackArea
Motivation - our success story 🏁 Stop starting, start
finishing🔞 Limit work in progress (WIP)
⏰ Fast feedback loop
To-do list
time
?
Needs clarifications
Startnew ticket
WIP = 1
Needs FeedbackArea
Motivation - our success story 🏁 Stop starting, start
finishing🔞 Limit work in progress (WIP)
⏰ Fast feedback loop
To-do list
time
WIP = 1
Needs FeedbackArea
Motivation - our success story 🏁 Stop starting, start
finishing🔞 Limit work in progress (WIP)
⏰ Fast feedback loop
To-do list
time
WIP = 1
?
Needs clarifications
Startnew ticket
Needs FeedbackArea
Motivation - our success story 🏁 Stop starting, start
finishing🔞 Limit work in progress (WIP)
⏰ Fast feedback loop
To-do list
time
WIP = 1
Needs FeedbackArea
Motivation - our success story 🏁 Stop starting, start
finishing🔞 Limit work in progress (WIP)
⏰ Fast feedback loop
To-do list
time
WIP = 1
Needs FeedbackArea
?
Needs clarifications
Startnew ticket
Motivation - our success story 🏁 Stop starting, start
finishing🔞 Limit work in progress (WIP)
⏰ Fast feedback loop
To-do list
time
WIP = 1
Needs FeedbackArea
Motivation - our success story 🏁 Stop starting, start
finishing🔞 Limit work in progress (WIP)
⏰ Fast feedback loop
To-do list
time
WIP = 1
Needs FeedbackArea
Startnew ticket
Feedback given
Motivation - our success story 🏁 Stop starting, start
finishing🔞 Limit work in progress (WIP)
⏰ Fast feedback loop
To-do list
time
WIP = 1
Needs FeedbackArea
Startnew ticket
Motivation - our success story 🏁 Stop starting, start
finishing🔞 Limit work in progress (WIP)
⏰ Fast feedback loop
To-do list
time
WIP = 1
Needs FeedbackArea
Startnew ticket
Feedback given
Feedback given
Motivation - our success story 🏁 Stop starting, start
finishing🔞 Limit work in progress (WIP)
⏰ Fast feedback loop
To-do list
time
WIP = 1
Needs FeedbackArea
Startnew ticket
Motivation - our success story 🏁 Stop starting, start
finishing🔞 Limit work in progress (WIP)
⏰ Fast feedback loop
To-do list
time
WIP = 1
Needs FeedbackArea
Startnew ticket
Now WIP = 4Task switching will kill performance?!
Motivation - our success story 🏁 Stop starting, start
finishing🔞 Limit work in progress (WIP)
⏰ Fast feedback loop
To-do list
time
WIP = 1
Needs FeedbackArea
Startnew ticket
Now WIP = 4Task switching will kill performance?!
These are stuck hereThese tasks will have to wait much longer now
Motivation - our success story 🏁 Stop starting, start
finishing🔞 Limit work in progress (WIP)
⏰ Fast feedback loop
To-do list
time
?
Needs clarifications
Startnew ticket
WIP = 1
Lesson learned: Don’t start a new ticket too easily. Chase after feedback first.
Feedback queue in Taskman
Agile methodologies
Waterfall
Agile(Scrum, Kanban, Lean)
VS
project methodologiesWaterfall = Space mission Each step takes months/years with little flexibility to change
project methodologiesWaterfall = Space missionScrum = Cruise ship Sprints of 2-3 weeks each= mini waterfalls
Sprint 1
Sprint 2
Sprint 3
project methodologiesWaterfall = Space missionKanban = RaftingKanban = Motorboat
EEA Flow process
Product Owners,Stakeholders
Idea / Requests
Meetings
Emails
Usability tests
Stakeholders
Users feedback
Product Strategy
External factors Team
Manager,Developers
Developers Product Owners,Team Manager
Developers
EEA Flow process - multi-projects
EEA FLOW PROCESS - detailed view
Implementation at EEA: Flow
ideas
Epics (XXL/XL user stories)
Contextual prioritised list(L/M/S user stories)
Product Owner +Stakeholders (product team)
Product Owner + Team
Product Owner + Team
GREEN PRODUCT
Delivery Team(cross-functional)
Delivery Team Manager /(System Owner)
queue analysisin progress testing demo to deploy
FLOW
ideas
PRODUCT BACKLOG
TASKS BACKLOG
TEAM QUEUE
VISION BACKLOG
WORK IN PROGRESS
BLUE PRODUCT
Live
Roles and permissions
Product Owner / Delivery Team Manager: Represents the stakeholders (internal EEA product owners) towards the developers and make sure the WIP-limits and workflow policies are respected.
Manager: This is a senior developer (IDM/contractor), that supports the Product Owner and further co-ordinate the queue and work in progress, also known as Scrum Master.
Developer: This role is given to the resources that are implementing the tickets, it is mostly consultants and EEA IT-staff.
Reporter: This is given to all stakeholders and EEA internal product owners that are allowed to report new tickets. Being a Reporter means you will request- and give feedback on work to be done.
Suggested reading...Free downloadhttp://www.infoq.com/minibooks/kanban-scrum-minibook
Key points summaryhttps://goo.gl/MwO1MK Thank you for
your attention