Today, I was having a chat with a few others. It was long and rambling but the conclusion was kind of nice. We realised that every single issue we were talking about really started with how we prepare our stories. We often have bad stories that make it through and then we have to deal with the problems in the sprint, which is terrible for everyone concerned.
So we came up with 3 ways of spotting a bad story rather than trying to decide what a good one would look like. All have to pass for this to be a story that we should do. The vision was that the team can 'test' a story before allowing it to be worked on ensuring the team have the final call on responsibility.
1) Does it have any assumptions or risks?
No.... none? Don't believe it. It would be a truly exceptional story that has neither of these. If there are no risks then I would bet that this is either too small or there is no value in the story. Neither are good. The most common reason is that we simply didn't think or come up with any, which is not the same as there not being any.
If there are some assumptions and risks then we should find out if we are happy with them. Can we mitigate the risks we have identified? Are there any experiments we can run to find out some more? Are the risks worth it and we are happy with the trade off (which will probably be longer delivery time)?
Spotting assumptions in a discussion is actually very easy - "Well, IF we did this...", "What about..." or the clanger "Assuming....". Stop, ask for it to be a sentence and write it down!
Risks require a little more effort. We have some questions we can asks "What is likely to take the longest?", "What have we not done before?", "What is only known by a few members of the team?". Using Liz Keogh's scale for estimating complexity is a nice tool too which should help you uncover the risks of key parts of a story.
2) Do we all see the same thing?
I was introduced to a great game in a workshop with Tobias Mayer. You create a character by each person in your group adding one feature at a time. When you can no longer 'see' the character, the next person has to explain how the character makes sense to them - this is to help you see it.
At the start of your story or during planning, you can call out what you need to do for a story in order one person at a time. If anyone does not see the same thing you can challenge by saying that you cannot 'see it', allowing you to spot if things are missing. When we cannot think of anything else to add, we can check that we all 'see it' and move on.
You can also do this using diverge and merge if you task out stories. This where everyone creates tasks and then we merge these together to see where we agree or have different ideas. Both are valuable - similarities suggest something we should definitely do whilst singular tasks merit conversation since we might have missed something.
If we don't see the same thing, we need to spend a bit more time making sure we do. Doing this with the people who will actually develop the story is absolutely required. Extra points if you are using the 3 Amigo's for this conversation.
3) Will this take longer than...
Yes, estimates suck. This isn't quite that. You pick a line in the sand and you decide that stories should not take longer. This is your stories delivered and everything that entails. For my team, at time of writing we are trying to get everything into production in 5 days or less. We are miles off but that is our line in the sand.
To reach the hallowed land, our stories need to be smaller and the line in the sand helps us recognise stories that do not fit the goal.
You need to take constraints into account. We know our path to live is not a super smooth highway so we take that into account and ask, "Will I be done with development in 3 days?". If not, then we need to break this story down, it is too big.
You can also use the awesome "No busllsh*t" cards from Lunar Logic, which approaches this from a different angle.
Tuesday, 14 March 2017
Wednesday, 25 January 2017
Agile with Mum: MVP
Working with a range of people, you end up with a growing list of things you steal. One of my favourites is from Helen Meek who often asks people to think of explaining to their Mum. So if we are saying we want a 'simple' interface, we might think of our Mum using it. This means no long words, no technology, no three letter acronymns - you get the picture.
Just recently, I was trying to get across the thinking behind an MVP and eventually imagined this metaphor which I thought I would share. This also covers the basics of Story Mapping and I hope it can be explained in under 5 minutes.
Imagine we are planning our ultimate holiday. This is our once in a lifetime, no expense spared, lifetime-memory-creating sort of holiday. This is important and very expensive and you have decided to plan this a little so that everything goes according to plan and gives you the best possible experience.
You realise there are certain stages to making sure this goes off without a hitch. You start to write them down and you end up with something like this:
Preparation -> Journey Out -> Enjoyment -> Journey Back
Each of these are not just one thing, they are each a series of things you need to do. So you start to list them out. Some of these are really important and some are not - this is the ultimate holiday so you want to remember everything that will make it awesome. We want to remember and think about all the little details.
You write your list of things and then order them so that the most important are at the top and the least important are at the bottom:
Preparation
Check Visa Requirements
Tell neighbours and give spare key
Change Money
Stock up on sun tan lotion
Buy beach books
Buy new swimsuit
Journey Out
Turn off heating
Remember Passport!
Remember Wallet!
Book Taxi
Pack Suitcase
Charge Phone
Enjoyment
Book excursions
Get Trip Advisor Recommendations
Tell Hotel about fish allergy
Journey Back
Book early wake up call for flight
Money for pressies at airport
Charm stewardess for seat upgrade
Book Taxi
You then start to look for your holiday.
The unthinkable then happens. You find the deal of the century. I mean a true "oh my god it can't be true" sort of deal that is totally legit. It's got everything, the ideal location, a superb hotel, all inclusive booze, transfers - the lot. All for a teeny tiny price.
But there's a catch. You have to leave in 15 minutes to get the flight.
Fortunately, you have your plan and you realise that since you have already ordered everything by importance to the ultimate holiday goal, you can use this to work out what you need to do to make that flight.
So you go down each list and stop at something you can leave out - everything above it is a must have. So in Preparation, you stop at "tell neighbours and give spare key" - don't need that, so everything below it must be not required too. In Journey Out, you stop at "Book Taxi" - we are just getting out of here right now so that's not required either. In Enjoyment nothing makes the cut, all that will have to wait until we get there. Journey back doesn't make the cut either since it doesn't effect the minimum we need to go on this holiday.
So what are we left with?
Check Visa requirements
Turn off heating
Remember Passport!
Remember Wallet!
This is the minimum viable product.
Just recently, I was trying to get across the thinking behind an MVP and eventually imagined this metaphor which I thought I would share. This also covers the basics of Story Mapping and I hope it can be explained in under 5 minutes.
Imagine we are planning our ultimate holiday. This is our once in a lifetime, no expense spared, lifetime-memory-creating sort of holiday. This is important and very expensive and you have decided to plan this a little so that everything goes according to plan and gives you the best possible experience.
You realise there are certain stages to making sure this goes off without a hitch. You start to write them down and you end up with something like this:
Preparation -> Journey Out -> Enjoyment -> Journey Back
Each of these are not just one thing, they are each a series of things you need to do. So you start to list them out. Some of these are really important and some are not - this is the ultimate holiday so you want to remember everything that will make it awesome. We want to remember and think about all the little details.
You write your list of things and then order them so that the most important are at the top and the least important are at the bottom:
Preparation
Check Visa Requirements
Tell neighbours and give spare key
Change Money
Stock up on sun tan lotion
Buy beach books
Buy new swimsuit
Journey Out
Turn off heating
Remember Passport!
Remember Wallet!
Book Taxi
Pack Suitcase
Charge Phone
Enjoyment
Book excursions
Get Trip Advisor Recommendations
Tell Hotel about fish allergy
Journey Back
Book early wake up call for flight
Money for pressies at airport
Charm stewardess for seat upgrade
Book Taxi
You then start to look for your holiday.
The unthinkable then happens. You find the deal of the century. I mean a true "oh my god it can't be true" sort of deal that is totally legit. It's got everything, the ideal location, a superb hotel, all inclusive booze, transfers - the lot. All for a teeny tiny price.
But there's a catch. You have to leave in 15 minutes to get the flight.
Fortunately, you have your plan and you realise that since you have already ordered everything by importance to the ultimate holiday goal, you can use this to work out what you need to do to make that flight.
So you go down each list and stop at something you can leave out - everything above it is a must have. So in Preparation, you stop at "tell neighbours and give spare key" - don't need that, so everything below it must be not required too. In Journey Out, you stop at "Book Taxi" - we are just getting out of here right now so that's not required either. In Enjoyment nothing makes the cut, all that will have to wait until we get there. Journey back doesn't make the cut either since it doesn't effect the minimum we need to go on this holiday.
So what are we left with?
Check Visa requirements
Turn off heating
Remember Passport!
Remember Wallet!
This is the minimum viable product.
Thursday, 8 December 2016
Story Cards 2.0
A while back I was exploring some other options for story cards. In a previous blog, I mentioned that making it super easy to create stories was not necessarily a good thing.
So, I bought a few things and started some experiments.
My first cut of this was to laminate a card, the idea being that I could re-use them. 1 pack of A6 lamination pouches later and I had something that looked pretty good!
The first stumbling block was what to write on them with. In my first cut, I used OHP marker pens which are 'semi-permanent'. I eventually found out that meant they could be wiped off with a damp cloth - which sounded perfect! Or so I thought...
The problem is that OHP markers smudge like crazy. My test bunnies complained that they ended up with black smudges over the cards and their hands.
"Can't we use sharpies instead?". Hmmmm.
After a bit of Googling, I found that standard sharpies can be wiped of with Isopropyl Alcohol - useful to know if you have habit of writing on whiteboards with them! Having a bottle of this kicking around the office did not seem like a good idea but I found you can buy Isopropyl Wipes pretty cheaply.
So we have now have a re-usable card and something to write on them with and wipe it off again. In my experiments, I also found chalk pens were a viable option but they don't come in black so it would depend on your card colour. I like both sharpies and chalk pens but sharpies win since we have tonnes of them laying about the place. Chalk pens are a bit pricey but are hard to rub off once dry.
We started with just using good ol' fashioned Bluetack to stick these to the board but I hated the way they often ran out of stick and then fell off, so I looked for an alternative. I have experimented in the past with Scotch Restickable Dots which are pretty good but also eventually run out - they can also be too sticky, making it hard to move things.
We started by using magnets which worked great but looked terrible - you obviously need a magnetic board, which might be a problem. After a bit more Googling, there have clearly been many innovations with magnets since I was a lad - I found rolls of self adhesive magnets, which could be cut to size. This allowed me to make the cards self sticking by adding these to the back:
So now we have stickable, movable, re-usable, templated story cards. I created a few in different colours to denote different work streams and the team started using them. We also used the magnets on the avatars and our other icons we use to show items that are blocked, paused etc.
By making the cards 'hard' to create we can easily tell what we planned to do and what we decided to add to our board during the sprint. We can then use this information in the retro and find out what is wrong e.g. prioritisation, support issues, emergencies, rogue work items.
A side effect of the cards being hard to create means that there is a finite stock of them - you can't keep adding them. This got absorbed into our process and we try to get the stories as small as possible so we can re-cycle the cards during the sprint for another story - the side effect of which is that the work in progress is also limited.
So there you have it, story cards 2.0 - have you tried anything similar?
So, I bought a few things and started some experiments.
My first cut of this was to laminate a card, the idea being that I could re-use them. 1 pack of A6 lamination pouches later and I had something that looked pretty good!
The first stumbling block was what to write on them with. In my first cut, I used OHP marker pens which are 'semi-permanent'. I eventually found out that meant they could be wiped off with a damp cloth - which sounded perfect! Or so I thought...
 |
| Version 1.1 - getting there! |
"Can't we use sharpies instead?". Hmmmm.
After a bit of Googling, I found that standard sharpies can be wiped of with Isopropyl Alcohol - useful to know if you have habit of writing on whiteboards with them! Having a bottle of this kicking around the office did not seem like a good idea but I found you can buy Isopropyl Wipes pretty cheaply.
So we have now have a re-usable card and something to write on them with and wipe it off again. In my experiments, I also found chalk pens were a viable option but they don't come in black so it would depend on your card colour. I like both sharpies and chalk pens but sharpies win since we have tonnes of them laying about the place. Chalk pens are a bit pricey but are hard to rub off once dry.
We started with just using good ol' fashioned Bluetack to stick these to the board but I hated the way they often ran out of stick and then fell off, so I looked for an alternative. I have experimented in the past with Scotch Restickable Dots which are pretty good but also eventually run out - they can also be too sticky, making it hard to move things.
We started by using magnets which worked great but looked terrible - you obviously need a magnetic board, which might be a problem. After a bit more Googling, there have clearly been many innovations with magnets since I was a lad - I found rolls of self adhesive magnets, which could be cut to size. This allowed me to make the cards self sticking by adding these to the back:
 |
| Self Sticking magnetised story cards |
By making the cards 'hard' to create we can easily tell what we planned to do and what we decided to add to our board during the sprint. We can then use this information in the retro and find out what is wrong e.g. prioritisation, support issues, emergencies, rogue work items.
A side effect of the cards being hard to create means that there is a finite stock of them - you can't keep adding them. This got absorbed into our process and we try to get the stories as small as possible so we can re-cycle the cards during the sprint for another story - the side effect of which is that the work in progress is also limited.
So there you have it, story cards 2.0 - have you tried anything similar?
Tuesday, 8 November 2016
Agile or just common sense?
A while back I was at a sort-of reunion with some people I used to work with at a previous company. Most of the people there had gone their separate ways and were doing new and exciting things.
One girl that was in my team had gone freelance and was working as the lone wolf on a project that sounded pretty cool.
"Much better than that agile s**t you were making us do".
How encouraging, nice to see I make a difference. I was intrigued, so I asked a little more about what she was doing.
She started by explaining how she worked with the customer.
Each week she had a regular meeting with the customer where she showed what they asked her to do last week. They often took her work and played with for it for a bit, giving her some feedback on bugs or problems. If it did what they wanted then they would make it live and start using it.
Hmmm. That sounds familiar.
Then she explained how the customer would give her work based on what they wanted it to look like and a bit of background on what they were trying to achieve. She would then work out what she thought she could do in a week and agree it with them. She would talk about this at the same weekly meeting.
Hey, that sounds familiar too.
She said the work was a mix of front and backend work, essentially taking data out of a database and providing visualisations for that data. She was enjoying the mix of work and because it was just her it was easier to provide estimates or suggestions that she felt she could stick to.
That's spooky. I'm sure I've heard something like that before.
How about managing the work? Backlogs etc, how does that work:
"Nah, we talk about that stuff when we meet each week. They have a list of stuff they want to do but I just work on the one they are in a tizzy about."
Interesting.
So, I asked about the changes she was making. Where these big pieces of work - how does she fit these into each week? She focused on changing a specific bit based on what they said they wanted to achieve. Each weeks work didn't tackle the whole idea but just something specific that worked towards it.
I asked why she did it that way:
"I wanted to show progress so I wouldn't have problems when I charged them for my time each week. We agree what they are going to get and I show them that work a week later - I don't want any hassle and I work from home so this is great for me, I don't want to f**k it up!"
No arguing with that. These sound like the perfect customers! She was pretty quick to respond:
"God they are a pain! They change their minds all the time. Each week, we seem to go further and further away from what they said they wanted. Each week they have a new 'idea' that I have to work on!"
Definitely hitting a 9.0 on coincidence meter now. I'm sure I've heard this before.
Despite her previous remarks, if we ran a check list of the agile manifesto she would have been following the ideas of the manifesto 100%. As an 'agile hater', I pretty sure this was not her plan!
Each thing she did was to solve a problem for her customer. To her, the approach was just common sense. I wonder how many of us get tied up with the rules and doctrines and forget this too...
One girl that was in my team had gone freelance and was working as the lone wolf on a project that sounded pretty cool.
"Much better than that agile s**t you were making us do".
How encouraging, nice to see I make a difference. I was intrigued, so I asked a little more about what she was doing.
She started by explaining how she worked with the customer.
Each week she had a regular meeting with the customer where she showed what they asked her to do last week. They often took her work and played with for it for a bit, giving her some feedback on bugs or problems. If it did what they wanted then they would make it live and start using it.
Then she explained how the customer would give her work based on what they wanted it to look like and a bit of background on what they were trying to achieve. She would then work out what she thought she could do in a week and agree it with them. She would talk about this at the same weekly meeting.
Hey, that sounds familiar too.
She said the work was a mix of front and backend work, essentially taking data out of a database and providing visualisations for that data. She was enjoying the mix of work and because it was just her it was easier to provide estimates or suggestions that she felt she could stick to.
That's spooky. I'm sure I've heard something like that before.
How about managing the work? Backlogs etc, how does that work:
"Nah, we talk about that stuff when we meet each week. They have a list of stuff they want to do but I just work on the one they are in a tizzy about."
Interesting.
So, I asked about the changes she was making. Where these big pieces of work - how does she fit these into each week? She focused on changing a specific bit based on what they said they wanted to achieve. Each weeks work didn't tackle the whole idea but just something specific that worked towards it.
I asked why she did it that way:
"I wanted to show progress so I wouldn't have problems when I charged them for my time each week. We agree what they are going to get and I show them that work a week later - I don't want any hassle and I work from home so this is great for me, I don't want to f**k it up!"
No arguing with that. These sound like the perfect customers! She was pretty quick to respond:
"God they are a pain! They change their minds all the time. Each week, we seem to go further and further away from what they said they wanted. Each week they have a new 'idea' that I have to work on!"
Definitely hitting a 9.0 on coincidence meter now. I'm sure I've heard this before.
Despite her previous remarks, if we ran a check list of the agile manifesto she would have been following the ideas of the manifesto 100%. As an 'agile hater', I pretty sure this was not her plan!
Each thing she did was to solve a problem for her customer. To her, the approach was just common sense. I wonder how many of us get tied up with the rules and doctrines and forget this too...
 |
| Common Sense? Yeah, I've heard of it.... |
Tuesday, 4 October 2016
The Sarcastic Scrum Master
As a Brit I am unbelievably sarcastic at times. Some might say uncontrollably, which can cause problems.
Just recently, I have been trying to channel this urge for good. I do this using my new favourite start to a conversation, "If Only...". This is the setup for my call to action, delivered with a sarcastic punch.
Here is an example:
Frustrated Developer: "GOD! What is going on with communication in this team? Nobody seems to know what is going on, everybody is running around like headless chickens - it's soooooo frustrating!"
Sarcastic Scrum Master: "Oh, that is SOOOO true! If only there was a point in the day when we are all gathered, in receive mode and trying to actively organise ourselves. That would be a great time to share knowledge or highlight a conversation that might need to happen."
Frustrated Developer: "What? Like the standup...."
Sarcastic Scrum Master: "OMG! I had forgotten about that! You're right that would be a good time to share things with the team. You would need to remember to say something of course, maybe we could add some sort of cue for you to let the team know something important...."
Frustrated Developer: "Erm. Like when you say 'Is there anything else that we need to share?"
Sarcastic Scrum Master: "Hey! You're right. I DO say that everyday.... what a ninny. That would be a super time to let the team know anything that they should be aware of."
It would be so easy to just say "That's what we have the stand up for" and be done but there is no learning attached to that.
Yes this is gently mocking and I know it works in my team with the relationships I have built. Your distance may vary.
Just recently, I have been trying to channel this urge for good. I do this using my new favourite start to a conversation, "If Only...". This is the setup for my call to action, delivered with a sarcastic punch.
Here is an example:
Frustrated Developer: "GOD! What is going on with communication in this team? Nobody seems to know what is going on, everybody is running around like headless chickens - it's soooooo frustrating!"
Sarcastic Scrum Master: "Oh, that is SOOOO true! If only there was a point in the day when we are all gathered, in receive mode and trying to actively organise ourselves. That would be a great time to share knowledge or highlight a conversation that might need to happen."
Frustrated Developer: "What? Like the standup...."
Sarcastic Scrum Master: "OMG! I had forgotten about that! You're right that would be a good time to share things with the team. You would need to remember to say something of course, maybe we could add some sort of cue for you to let the team know something important...."
Frustrated Developer: "Erm. Like when you say 'Is there anything else that we need to share?"
Sarcastic Scrum Master: "Hey! You're right. I DO say that everyday.... what a ninny. That would be a super time to let the team know anything that they should be aware of."
It would be so easy to just say "That's what we have the stand up for" and be done but there is no learning attached to that.
Yes this is gently mocking and I know it works in my team with the relationships I have built. Your distance may vary.
Thursday, 8 September 2016
My case for why story cards deserve a bit of love
I am an avid user of Post-its, which I commonly call 'stickies' since I am not a brand junkie even if I secretly compare my Brand X to Super Stickies.
I give you exhibit A:
The stories on my board are represented by stickies and they have traditionally been extremely low rent. Creating a new story takes seconds and have always thought of this being a good thing. The format usually persists and easily adaptable so I have never done it any differently.
Just recently I have noticed that the simplicity of creating cards also means new ones are created often which I am not sure is a good thing....
Are we facilitating the idea that changing items in a sprint is quick and painless? Maybe even that it's a fringe benefit and does not cost anything?
If our goal is to form a set list of work for a sprint then we should be only creating stories once. We can afford to spend a little bit of time on them.
The card should reflect the effort that the team has already expended to get them into a state that we can create software with, which could have had many hours spent on it in refinement and planning by various members of the team.
Does a sticky really represent our investment in that story? Throwing away a sticky does not 'feel' serious but it might represent a significant investment in time and ultimately money.
So I have a new theory: Story Cards should be difficult to create and fantastic to look at.
Whilst my team think that glitter, funky calligraphy and lamination is maybe a smidge too far (I disagree) printing them off using a nice template and font's would make them easier to read whilst making them just too difficult to create ad-hoc or without a good reason.
Is our work really best represented by a dog-earred stickie written in questionable handwriting? Doesn't it deserve just a little bit more?
I think story cards should embody our view of our work and deserve just a little bit of love.
Maybe allow anything that was not part of our sprint planning be a sticky so we can see just how flexible and accommodating our team really is, which is often overlooked by the wider business.
I give you exhibit A:
 |
| Definitely a 'C' for effort - could try harder! |
The stories on my board are represented by stickies and they have traditionally been extremely low rent. Creating a new story takes seconds and have always thought of this being a good thing. The format usually persists and easily adaptable so I have never done it any differently.
Just recently I have noticed that the simplicity of creating cards also means new ones are created often which I am not sure is a good thing....
Are we facilitating the idea that changing items in a sprint is quick and painless? Maybe even that it's a fringe benefit and does not cost anything?
If our goal is to form a set list of work for a sprint then we should be only creating stories once. We can afford to spend a little bit of time on them.
The card should reflect the effort that the team has already expended to get them into a state that we can create software with, which could have had many hours spent on it in refinement and planning by various members of the team.
Does a sticky really represent our investment in that story? Throwing away a sticky does not 'feel' serious but it might represent a significant investment in time and ultimately money.
So I have a new theory: Story Cards should be difficult to create and fantastic to look at.
Is our work really best represented by a dog-earred stickie written in questionable handwriting? Doesn't it deserve just a little bit more?
I think story cards should embody our view of our work and deserve just a little bit of love.
Maybe allow anything that was not part of our sprint planning be a sticky so we can see just how flexible and accommodating our team really is, which is often overlooked by the wider business.
Friday, 26 August 2016
What if it was your money?
A while back I wrote about my adventures with making a pizza oven. I built a prototype to test if I would actually use one, which went OK. I refined my prototype based on early feedback, adding insulation and investing in a laser temperature gauge so I could measure the impact of any changes to my design. I managed to cook some pizzas and other yummies but it was never really big enough to cook anything other than experiments.
This year I decided to build one for real. This involves a whole level of commitment higher than I put into my prototype, both in terms of money and time.
I spent a few months looking at how to go about this, reading articles and blogs from all over the place. If you boil it down an oven really had 3 key ingredients: the base, the skin and the insulation. There is lots of discussion about the shape but I think the dome shape really wins and the math is pretty well understood (there is a mathematical relationship between the height of the door and height of the oven).
The decisions are largely technical and there is great advice all over the place. I made my decisions based on what I could get hold of locally and my budget. The key decision was about the actual dome and I opted for one made in clay.
I chose clay because I had a pottery supplier nearby who sold clay that was premixed with sand specifically for pizza ovens - the thought of having to mix and muddle what would be about 75 kgs of clay did not appeal. I had previously purchased a bag of the clay in question so I knew what it was like to work with and decided that it would be more pleasant that working with a refractory cement, which was the other option.
The building of the base went well as did the dome and I stood back and looked at my creation with a bit of pride. Everything had gone according to plan and actually within my time estimates too. A for execution.
Then it all went wrong.
This was the first time I had worked with clay and everyone talked about leaving it for a few days before firing it for the first time. I waited for 2 but very quickly realised this was no way near long enough. I came to this conclusion when I saw some cracks forming. Frantic searching about this revealed it was nothing out of the ordinary and to be expected in some cases.
I slowed the fire but the damage was done. The cracks continued growing and once it was all cooled I realised the scale of the problem was pretty big.
Time to find a happy place.
So my sprint went well but what my team had put together did not meet expectations. The team had done all they could to know just enough to get started - we ask teams to have courage as well as be transparent when problems arise. We need a retro to find out what happened.
"What went well this sprint?"
The techniques we used worked well. The clay dome came together quickly and was structurally sound. The base retained heat well too.
"What didn't go so well?"
When we fired the oven, cracks started to appear. By the time we cooled the oven down the cracks had grown significantly, one of which is very wide. We did not factor shrinkage into our design either, so the dome is smaller than we thought it would be.
"What caused the problems we experienced?"
The big problem was that we did not wait long enough before firing oven. The guides were very loosely worded which we never questioned - our clay needs a lot longer to dry before being fired! By firing too early, the water in the clay formed too much steam which had to escape forcing its way out by creating cracks. There is a good chance we created too big a fire, too quickly. In conjunction with being too eager to complete the dome, these combined are probably the root cause. The sand mould we used should have been bigger to take account of shrinkage, which was not something we considered.
"What could we have done to stop this happening?"
If we had done some black hat thinking we would have found out about what happens if you fire to early. Searching for cracking and repairs would have given us the information we needed. We could have talked to someone about what a "series of small fires" actually is, which is very subjective! We should have talked to the pottery people more, who suggested that we should not be too eager to fire the dome. We could have quantified this with them - I thought a couple of days WAS enough! The shrinkage could have also been quantified with the pottery people.
Now thinking like the PO, I still need to realise the value in work we have done. What are our options?
The engineers view is that the dome is bust. There is a stonking great big crack in it. We can patch it but it will never be 'right'. We know how to do it better, we should kill it and start again. If we don't fix it then doing the insulation layer would be a waste of money - if the dome fails then we will have to destroy the insulation layer to get to the dome, wasting more money.
The shrinkage is not a large problem but there is a gap between the dome and the arch which will need to be addressed.
The insulation is definitely a problem, well described by the engineers.
In this case, we still don't know if we can make pizza in this oven since we have never tried. In software terms this is like throwing away code because you suspect it will not handle live load due to it's design without actually testing it.
Thinking like the SM, we need to generate some options. If we are unsure about the dome, is there an alternative to the insulation that requires less investment? Is there a way we can return some value from our oven without investing more into it?
If we did the bare minimum and made 10 pizza's this weekend before the dome failed would that be better than investing more but delivering a 1000 pizza's over a much longer period of time? Would we loose anything by patching what we have? What could we learn by doing this and how long would it take?
A more interesting question: What happen's if don't do anything? Do we know the dome will fail or suspect it will? Could we add more insulation at a later point if we find out what we have is actually OK?
We are often divorced from the money when we do this for a living but if you behave like it's your money then maybe your thinking is different. Seeing the sprint as an investment and asking what gives the best return is often a great way of getting people to think about it differently. I often use this with teams in retro's instead of using dot voting.
In this case I am the engineer, the PO and SM. And it's my money on the table. An I still don't have yummy pizza! As much as I hate the mistake I made, I can also see a half way house that allows me to get some value from what I have along with some more learning without additional investment. I might have less options in the future but I get some value now, which is a compromise I am happy to accept.
If I have to make another one, you can bet it will be awesome.
This year I decided to build one for real. This involves a whole level of commitment higher than I put into my prototype, both in terms of money and time.
I spent a few months looking at how to go about this, reading articles and blogs from all over the place. If you boil it down an oven really had 3 key ingredients: the base, the skin and the insulation. There is lots of discussion about the shape but I think the dome shape really wins and the math is pretty well understood (there is a mathematical relationship between the height of the door and height of the oven).
The decisions are largely technical and there is great advice all over the place. I made my decisions based on what I could get hold of locally and my budget. The key decision was about the actual dome and I opted for one made in clay.
I chose clay because I had a pottery supplier nearby who sold clay that was premixed with sand specifically for pizza ovens - the thought of having to mix and muddle what would be about 75 kgs of clay did not appeal. I had previously purchased a bag of the clay in question so I knew what it was like to work with and decided that it would be more pleasant that working with a refractory cement, which was the other option.
The building of the base went well as did the dome and I stood back and looked at my creation with a bit of pride. Everything had gone according to plan and actually within my time estimates too. A for execution.
Then it all went wrong.
This was the first time I had worked with clay and everyone talked about leaving it for a few days before firing it for the first time. I waited for 2 but very quickly realised this was no way near long enough. I came to this conclusion when I saw some cracks forming. Frantic searching about this revealed it was nothing out of the ordinary and to be expected in some cases.
I slowed the fire but the damage was done. The cracks continued growing and once it was all cooled I realised the scale of the problem was pretty big.
Time to find a happy place.
So my sprint went well but what my team had put together did not meet expectations. The team had done all they could to know just enough to get started - we ask teams to have courage as well as be transparent when problems arise. We need a retro to find out what happened.
"What went well this sprint?"
The techniques we used worked well. The clay dome came together quickly and was structurally sound. The base retained heat well too.
"What didn't go so well?"
When we fired the oven, cracks started to appear. By the time we cooled the oven down the cracks had grown significantly, one of which is very wide. We did not factor shrinkage into our design either, so the dome is smaller than we thought it would be.
"What caused the problems we experienced?"
The big problem was that we did not wait long enough before firing oven. The guides were very loosely worded which we never questioned - our clay needs a lot longer to dry before being fired! By firing too early, the water in the clay formed too much steam which had to escape forcing its way out by creating cracks. There is a good chance we created too big a fire, too quickly. In conjunction with being too eager to complete the dome, these combined are probably the root cause. The sand mould we used should have been bigger to take account of shrinkage, which was not something we considered.
"What could we have done to stop this happening?"
If we had done some black hat thinking we would have found out about what happens if you fire to early. Searching for cracking and repairs would have given us the information we needed. We could have talked to someone about what a "series of small fires" actually is, which is very subjective! We should have talked to the pottery people more, who suggested that we should not be too eager to fire the dome. We could have quantified this with them - I thought a couple of days WAS enough! The shrinkage could have also been quantified with the pottery people.
Now thinking like the PO, I still need to realise the value in work we have done. What are our options?
The engineers view is that the dome is bust. There is a stonking great big crack in it. We can patch it but it will never be 'right'. We know how to do it better, we should kill it and start again. If we don't fix it then doing the insulation layer would be a waste of money - if the dome fails then we will have to destroy the insulation layer to get to the dome, wasting more money.
The shrinkage is not a large problem but there is a gap between the dome and the arch which will need to be addressed.
The insulation is definitely a problem, well described by the engineers.
Thinking like the SM, we need to generate some options. If we are unsure about the dome, is there an alternative to the insulation that requires less investment? Is there a way we can return some value from our oven without investing more into it?
If we did the bare minimum and made 10 pizza's this weekend before the dome failed would that be better than investing more but delivering a 1000 pizza's over a much longer period of time? Would we loose anything by patching what we have? What could we learn by doing this and how long would it take?
A more interesting question: What happen's if don't do anything? Do we know the dome will fail or suspect it will? Could we add more insulation at a later point if we find out what we have is actually OK?
We are often divorced from the money when we do this for a living but if you behave like it's your money then maybe your thinking is different. Seeing the sprint as an investment and asking what gives the best return is often a great way of getting people to think about it differently. I often use this with teams in retro's instead of using dot voting.
In this case I am the engineer, the PO and SM. And it's my money on the table. An I still don't have yummy pizza! As much as I hate the mistake I made, I can also see a half way house that allows me to get some value from what I have along with some more learning without additional investment. I might have less options in the future but I get some value now, which is a compromise I am happy to accept.
If I have to make another one, you can bet it will be awesome.
Subscribe to:
Posts (Atom)