Kanban, Lean and Agile mysteries
Mattias Skarin
Sources of bug list misuse
May 23, 2013 – 11:47 pm
Bug lists have the potential to consume a lot of your organizations effort. Bugs drive re prioritization, dispatching, reporting, followup - even though they might be of one time nature and random occurrence. Whenever I encounter a huge bug list is to I ask which of these the organization will fix the upcoming release and then why they care about tracking the rest.
Over the years I have gotten a number of different answers to why the huge bug lists is maintained. I’ve found that many answers are really confusing the original purpose (to fix it) are with something else. An example can be mixing the purposes of “learning what provides a top notch service from the eyes of the customer” , “fixing the damn thing” and “tracability” – then attempting to provide answers to all of these above from the same tool.
I’ll share some of the dual purposes with you to provide you with some simple litmus tests. Each the well intended purpose below have better solutions.
- For keeping track of product limitations
- Awaiting and aligning prioritization (to be done later since organization units use different prioritization schemes)
- For reporting without action
- For maintaining traceability although we do not intend to fix it (ever)
- For dispatching to the right team
- For learning about frequent reoccurring sources of problems (this can be done outside the bug list)
- For pleasing every customer/user (some have marginal value)
- For maintaining pressure on the organization (political motives)
Hope it helps!
/mts
By code thou shall present! ITAKE
April 18, 2013 – 4:10 pm
Kanban and Scrum – now in Swedish translation
March 20, 2013 – 9:02 pm
Kanban and Scrum book is now available in Swedish translation, you can download from InfoQ here
Thanks to Johan Natt och Dag!
Addressing critical in deliveries from subcontractors
February 25, 2013 – 5:21 pm
In software, one of our favorite tool to deal with uncertainty is iterations. But is it always the better option?
The last week I’ve got the question two times of how to address critical in deliveries from subcontractors. For example: hardware, preparation of land, machinery, buildings or third party platform updates. How can these be addressed? Do iterations hold the answer? Are there better options?
Let me introduce lean flow thinking and show how it can be used to improve the outcome of critical third party in deliveries in your projects.
Facilitating a future vision @ Crisp
February 7, 2013 – 3:15 pm
Every organization needs to find it’s path, where to go next. Or it can choose just go “wherever” 
But let’s imagine your want to grasp the state of your hope, dreams and future of your creative people to understand what opportunities to grasp and which to let go of. Let’s imagine you need to do that among a group of self going free radicals, working in different places that does not regularly meet. Wait- that sounds like Crisp Let me share how we grasped our future vision.
Vad innebär agila kontrakt? – slides från Meridiumdagen
December 3, 2012 – 6:00 am
Sammanfattar i min presentation från Meridiumdagen ett antal Agila kontrakt som är i bruk idag och vad man bör tänka på när man använder dem.
—————— For the English reader:
What does Agile contracts really mean? - I walk through a number of real contracts that are in use today (presentation was given in Swedish)
—————–
Det jag upplever genomgripande saknas i alla agila kontrakt är en mekanism genom vilken kunden och leverantören snabbt kan upp ett bygga förtroende. Har man det sedan tidigare är det sällan ett problem, men frågan är hur man gör om kunden och leverantören är nya för varandra. Det finns dock en enkel lösning.
Som upphandlare väljer jag ut två leverantörer. Dessa får sedan bygga en prototyp motsvarande första iterationen av produkten. Leveranören som inte får kontraktet, får betalat för iterationen. Den andra leveranören som får kontraktet.
Knepet i utvärderingen är att du måste lyfta under huven på produkten för att se ingenjörsmässighet bakom. Det är där du ser skickligheten. Glömde jag nämna att Crisp gör sådant?
Using continuous improvement in product development
November 26, 2012 – 7:00 am
If you prefer this as an article – you can download it here.
What is continuous improvement?
Continuous improvement always starts by observing previous results. That is our baseline for improvements forward on. We strive to improve steadily, a little at a time – 10% is great! But first step is always to accept the facts, regardless if we would have liked it to be better. It is way too easy to sweep failed projects under the carpet rather than used as a baseline for improvements forward on. A mistake easily made is to base improvements on dream targets rather than previous results, it is hard to learn something from failure to meet those targets.
