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.

Monday, 1 August 2016

Future Trends - Part 1

I like imagining what might happen next. I'm terrible to watch films with - you tend to get a running dialogue!

Recently I have be applying this past time to my day job, imagining what might influence what I do and the teams I work in. I have a somewhat quirky, vivid imagination so some of the things I muse on are possibly the stuff of films rather than reality.

At the same time we all know that much of what ends up in films becomes real at some point too, which is the loose premise I am going to stick with for the time being.

Bold statement No. 1 - 'virtual world' development environments will become the mainstream

So what do I mean by this.... basically the VR technology we are using will be used to develop software. The virtual worlds we see in MPRG's will be used for developers to collaborate on software using avatars and systems will be represented as 3 dimensional structures in the virtual development environment, allowing visualisations of architectures. Groups of avatars collaborate by converging on a shared space to allow them to share the same view of the virtual world. People can zoom into a structure to see the code that makes it work.

Part of this thinking was inspired by a talk from Jamie Knight, who works at the BBC. Jamie is non-verbal and described how communication works in his teams. Since he uses tools to type and speak, conversations are limited by technology. To combat this, he has found that if everyone else use's the same technology then it makes the communication easier.

I started to think about the limiting factors for teams in successful companies and realised that the physical location was probably the primary one. Your staff need to be in the same area as you in order to turn up to work everyday, tales of serious competition for candidates are not uncommon as companies tend to group in local areas.

Played out on global scale, this is massively limiting. The best person to work for you might not even be in your country! When we think politically, they may not even be allowed to move to your country - with realisation of Brexit, this could impact the UK in future years.

If anyone has been working with a fast growing company, you will know the massive nightmare that it causes when you need to find (and house) a large work force. The physics becomes the limiting factor - you can't find the people fast enough and if you can, you can't keep adding people to the space you have. And we know how everyone just loves an office move...

On the flipside, anyone who has worked with a remote team or team members knows the associated issues - we see problems with communication, collaboration, ownership and culture. It is such a well know problem that we simply advocate co-location of teams since this basically gives you a massive advantage.

For me, taking the entire development environment into a virtual world actually starts to make sense:

  • Everyone would have the same level of communication and visibility, so it is up to the individuals to make this work. By giving people the same tools, we level the communication playing field - the location is no longer a factor
  • You would also be free to employ people from where ever you chose - reducing your problems to timezones and language, something which international businesses have previous experience with.
  • By allowing people to stay in their native country, businesses have the potential to offer much more competitive wages as it's actually the cost of living that they must meet
  • We know this scales massively (look at gaming) - it is only how we organise and communicate that becomes the limiting factor.

So why is a Scrum Master seemingly committing heresy by talking about such a thing?

Teams are key in this world I am describing - it is the whole reason why I have thinking about it. For starters, this would need to operate in a high trust culture - which get's me interested. It is entirely possible you may never meet the person you employ. They may also be protected by local laws that do not match your jurisdiction. That requires a level of trust that is hard to find in most companies.

Many of the interactions I take for granted can't be applied in this world - eye contact and body language would cut down my levels of feedback, meaning I would need to think differently.
All interactions with my team would now be virtual:

  • What would interactions between virtual team members look like? 
  • Would we still use boards (with virtual stickies, obviously) to organise ourselves? 
  • Would we create entirely new ways of visualising our work, leveraging our virtual world's unlimited flexibility? 
  • What would stand ups look like? Would we need them?
  • How does the communication scale - would we have virtual replacements for messaging and chat or something new?

What about the 'feelings' of our teams? In this world people who are frustrated or annoyed are easy to spot - a virtual world allows people to edit their emotions, even block them entirely:

  • How can we create a culture of trust that would encourage people to display their feelings given that this would be optional?
  • How would we build lasting relationships? Do our team building techniques travel in a virtual world?
  • Would a lack of 'real' human interaction be depressing?
  • Would it be hard to get people to work together given that they are not?
There is no doubt this could be massively empowering. Small companies could grow exponentially and we could always hire the best. Having people in multiple timezones could create a naturally longer day maybe having multiple stand ups to coordinate work between them. 

People could spend more time with their families and have greater flexibility as we build our businesses in environments that are as flexible as our creativity. Where people need to come together, they could choose to meetup at co-working spaces or any other space they deem appropriate.

Wouldn't these be the real internet companies?