tla <alt />

Are we actually managing bias?

2020-09-10T03:48:00.006-07:00

I have worked with a fair number of awesome developers. I was always stuck by how they had a deep understanding of not only what they did but the business area they worked in. They often saw things that others didn't due to that unique perspective - which you only get when you are 'in the weeds'.

With the tendency to strip things down, it would make sense that the ultimate outcome would be developers performing all the 'support' roles too - which would give them full autonomy on what they build and how.

And yet, this is not the norm. Or even fashionable.

This has been written about for decades and is a core part of Extreme Programming where the developers are customer facing and take on whatever role they need to create software be that as BA, QA, UX or UI developer or whatever acronym is currently popular.

When I think about each of those roles, I actually think of the bias they have. Each has a strong lean, which is core to that role - business analysts do lean more to business requirements and process, QA lean towards software that can be verified as working etc.

When I think about all those roles being covered by one person I realise that it's not fair.

It's not that a person can't do that but asking someone to balance all those areas and apply bias fairly or consistently is not something that we should ask from people. It can only lead to internal conflict, which we might not see or be aware of.

So yes, it's a pain to have those discussions with people. It's difficult and time consuming to find a compromise between the different members of your team, all of whom have excellent points and competing contexts.

But it's probably better that all that is out in the open. That we realise that our bias for our context is valuable in that discussion.

It might not feel like it but by having those roles, we are actually managing the biases that compete when we create software that people love to use. No right, no wrong just perspectives that need to be balanced.

Asking person to do that is unfair - only a team of people who respect each others perspective and value the context it brings to our own can figure that out. Somehow.

Changing the project language

2019-12-07T05:45:00.002-08:00

I have been struggling with the notion of projects. Everything seems to be a project. Like project is a general purpose container for getting things done. It could take a week it could take a year - surely these are not the same thing!

I have been experimenting with changing the language we use when we start something to be more descriptive and symbolic.

This starts with deciding what kind of thing we are doing - shifting the focus and conversation to the purpose and intent. There's some risk in there too :)

The language I have been playing with describes 3 type of things we could be doing - black holes, bets and bounties.

Black holes pull us off course and can pull us in. They needed to be discovered and navigated around. There needs to be a route - we don't want to stumble across one and have to suddenly correct our course.

These are the regulations we need to adhere to. These are the changes to outdated toolsets which risk being unsupported. These are the compounded consequences of doing it cheaply or quickly for too long. These are the hygiene features we need to provide for our customers.

Black holes affect our bottom line. They suck money, time and attention away from our growth and goals. They can consume us. They also don't have costs we can control to a great degree - they need to be done.

Bet's are anything new. A good bet makes us money, a bad bet looses us money. They have odds - the higher the odds, the higher the risk, the higher the potential reward and losses.

We can talk about how long the bet is for and the odds on it making us money. We might and probably should break big bets up into smaller bets. This costs us time but reduces our exposure to the risk by reducing the odds of each bet, allowing us to stop placing bets if the odds turn against us.

These are new features we have investigated and qualified. These are opportunities 3rd parties approach us with. These are pivots that we have data to qualify. These are requests from customers that sound like a good idea.

Bets swim with assumptions - some we can test, some we can't. The more we cannot know, the higher the risk that we might not recoup our stake.

If a bet goes bad, we can stop (and lick our wounds), increase the stake or hedge with another bet against an alternative outcome. These are controllable costs to us as we assess the risk and reward and aim to not get in too deep.

Bounties are decisions to do something to which we assign a fixed cost. We are explicit with our goal or it's implementation. Whoever picks up the bounty knows we only pay what the bounty is worth and no more. Bounties are not broken down - they are all or nothing.

There might be no data to support a bounty. They might be laden with risk but we have decided to do them anyway. We address the risk by assigning a cost that we are able and willing to lose.

These are the re-branding decisions. These are purchases of tools or equipment. These are one off publicity stunts. These are speaking at conferences to gain industry exposure. These are deciding to start a blog ;)

Bounties work well for talking about things we feel or think are a good idea but cannot measure. How do you measure sentiment or feeling or trust? With bounties you don't have to - you just have decide how much you can spend on trying to affect it.

The intangible nature of bounties means you have to resign to the cost being lost. It might work but you might never know.

To help people learn how to use these, here are some questions you can ask to help everyone identify what this project actually is:

1) Do we have to do this? - Black hole
2) What would happen if we didn't? - Black hole
3) Is this something we can postpone? - Black hole/Bet
3) How long do you think it would take to get our investment back? - Bet
4) What do we know already? - Bet
5) What is the main risk with doing this? - Bet
6) What gives you confidence this is the right thing to do? - Bet/Bounty
7) Under what circumstances would we loose our investment in this? - Bet
8) How could you measure the outcome? - Bet/Bounty
9) How long would we have to wait to get our investment back? - Bet
10) How much could we afford to spend on this if we assumed the worst and it would not make us money? - Bounty

In summary:
Black Holes - Upfront Budgeting, Based on Requirement, variable time frame, planned
Bets - Incremental Investment, Based on Risk, predictable/controllable time frame, planned/responsive
Bounties - Fixed cost Investment, Based on Sentiment or 'gut', fixed time frame, responsive/opportunistic

A work in progress - thought and ideas appreciated :)

Just another acronym TBD

2019-06-12T03:34:00.001-07:00

Working at scale I am constantly aware of how much we decide upfront. Before it gets anywhere near a team a lot of time goes into looking at what it is, what will change and who will be involved. In some cases, whole designs are considered before a team even see's it.

On the face of it, there is good reason. It costs a lot of money to build things: better make sure it will give a good return. Things taking longer costs even more: better make sure we know what we are getting into. It takes a lot of people to build stuff: better make sure we know who is involved so we can make sure they can actually make it.

We loose something important in doing this - our competitive edge. Every week we take in understanding the risk and cost is another week our customers don't have our product and our competitors have a window of opportunity.

Working with teams, I am aware of how much we assume. We build architectures based on our understanding at the time, which often include a lot of assumptions. I like assumptions because we can actually prove them out - but we usually don't.

We often build more that we actually need since we don't or can't prove out these assumptions. After a while of a service running, I have seen teams reduce the system in lots of different ways. This can sometimes be by removing caches, services that store data or using different scaling patterns that we discover over time.

We would benefit massively from building something small because we can see how it responds in the real world. We get feedback using monitoring and telemetry to understand what is going on and we can make better decisions on it's design and architecture based on that information.

But we need to start somewhere...... so how about we just focus on getting this data in the easiest way we can.

Imagine we took our best guess at an architecture that would suit our intended audience and built the services and deployed them. We make sure we add no logic whatsoever, only the bare minimum to allow the system to interact and we focus only on the monitoring and telemetry.

We can then load test this in a live environment and we could call this a 'best case' system. Without the logic this is the fastest it could operate - anything we add will slow it down. See it as an extreme case, where we are looking at the skinniest skeleton we could possibly get away with.

We can load the system and see what happens. We could also introduce waits in areas we can anticipate more logic and see what happens under load. We can add more monitoring where we have poor visibility. We can stub 3rd parties and make them 'misbehave' to see what happens.

Since there is not much too this, we can quickly move things around and see what happens and fix problems we can see - essentially we searching for a baseline test that we are happy with before we add anything else. We can easily remove things that don't have a measurable impact in the scenarios we are testing.

Since we don't have an logic there is no need for unit tests, meaning changes can be quick. As it does not do anything and contains/accesses no data, it is benign in a live environment so should not constitute a security risk either.

When we do start to add logic, we have a baseline we can compare to and a suite of tests that we use to monitor KPIs that we can actually monitor from the beginning. We also have an architecture that is better than a guess - it's already got some data to support why this is the right place to start.

I call this Telemetry Biased Design but it just sounds like a cool way of making sure you starting with just the right amount of architecture to solve the problem you have.

In full disclosure: at time of writing, I have never tried this. I am no longer an engineer and I work with smart people who get things done in their own way. It's just an idea.

The hidden features of Feature teams

2019-05-14T02:18:00.001-07:00

I while back I used the metaphor of booking a meeting to describe some of the problems with planning and priorities in development teams which are looking after discrete areas of a large system, which are typically called platforms.

An alternative approach is to use feature teams, which allow us to comprise a team of everyone needed to deliver a feature. You can immediately see, we don't have as much co-ordination overhead because a single team can deliver a feature end to end. We just have to task a team to deliver something and they can, making it easier to prioritise.

There are several flavours of feature teams but it really boils down to 2 types - permanent or prioritised. Permanent is exactly that, the feature team are permanent and have a stable number of permanent people. Prioritised is a team formed to solve a particular problem which are then disbanded after they have delivered the feature.

From my experience, it is when we look at feature teams over a longer term so we start to see some problems and they are pretty difficult to solve.

In a prioritised team, the immediate problem is with how people work together. It is true we often see a bounce when we form teams as we are invigorated with a new challenge. We also know this does not last forever and we know teams go through a storming phase when they are new. It takes time to get used to working with new people before we can form ways of working and finally reach our collective potential.

Depending on the length of engagement of a feature we should be sensitive to this and what the people in that team are going through. They should be fully bought into joining and working in a feature team and ideally volunteered rather than were placed. This might be difficult to achieve in some organisations and we should expect some people will not be a good fit for prioritised feature teams.

It is a safe assumption that features cut across multiple systems so these people would be touching multiple systems in order to deliver the feature end to end. You can read of the many accounts of how this can be handled and it really comes down to disciplined engineers doing things 'the right way' for their context.

I know I have seen many of these in my career but I have seen more engineers who would also start to change systems outside of the feature requirements because they did not like it or are acting altruistically and leaving it 'a better place' (Boy Scout Principle). Getting the balance is incredibly hard which is why I think the success of changing ownership from discreet systems to features is more to do with people than process.

We have to remember that software engineering is incredibly subjective so there is no one way to solve problems and coming to a consensus across 10s of engineers is hard. It's even harder with 100s of engineers, no matter how well meaning they are.

So we can mitigate some of these problems with a permanent feature team, which we can help through the forming stage and stabilise only once. They can form their own arrangements and start building things pretty effectively, getting that balance of engineering practices through evolving agreements.

There are many upsides to feature teams from a development perspective as they allow people to have exposure to multiple systems and architectures and work on differing problems which can often become stale in platforms. The counter is that without ownership you need some pretty well developed disciplines in your engineering teams that will prevent systems rotting from being constantly adapted to meet the requirements of features.

You would also need to be much better at moving people around since features typically need different systems to be delivered. So the permanent team probably is not so permanent unless you expect the team to learn the systems as they go, which might be going against the improvements in delivery you expect from less coordination.

It's operationally where I see many cracks and I call this the '2am problem'. Put simply, who do we call at 2am if there is a problem? The prioritised feature team may not be around anymore and although that problem is solved with a permanent feature team it may not be clear which team needs to be involved since you would need deep system knowledge in order to link the fault with the feature that requires it.

If we contrast with a platform team for a second. If a system had a problem, there is a clear owner for that system and that is who we call. In a feature team world, multiple features may have altered a system and when a fault occurs it might be quite difficult to know which team has the knowledge to resolve the issue.

This actually looks worse over time. With a permanent feature team delivering multiple features touching many systems they are now having to support those features as an ongoing concern if we are to preserve the very sensible mentality that the teams that develop the systems should also monitor and maintain them. Think also what this looks like to new members of the team where they have to learn how multiple features work end to end, which could well be more difficult than learning how a discreet system works and how that fits in with other systems.

You should also expect that any sort of centralisation will also be impacted as you need to allow feature teams to find their own path. If you start to force centralisation on feature teams then you again suffer from coordination problems which will slow them down again. We should expect and maybe even embrace duplication of effort as the same problems are solved several times over. To be fair this is something we also struggle with in platform teams too but I would expect it to be more pronounced in feature teams since they work across multiple systems.

A coping mechanism would be a centralised support function that we hand over support to. This feels like we are crashing out of devops thinking entirely which we have seen to improve stability and time to recovery of systems since they emphasise ownership and responsibility. It also hides the true cost as we burn time in handovers, documentation and operational procedures which extend out of the development cycle - essentially, you pay for it in the long term (OPEX vs CAPEX)

This feels like I am not a fan of feature teams, which is not true. They solve many of the coordination problems we see with platform teams but they introduce other problems. This is what forms the majority of my learning with scaled systems - you cannot win. With every change, you introduce some problems which you need to be aware of. Ultimately we have to decide which problems we would prefer to solve.

Are we expecting too much?

2019-04-30T08:14:00.001-07:00

Let's do some maths:

(67-x)/2 = y

So if I told you to substitute 'x' for your current age, what do you get for 'y'?

For me, at this current moment in time 'y' would be 12.5 since I am 42.

That is the number of positions and pay rises I would need to occupy me until my retirement age. This is based on a very reasonable expectation that I would be promoted every 2 years.

12.

Are there any career ladders that have 12 steps in them? Nope. Is the top one the 'Supreme Lead Senior Manager <whatever>'? There aren't even enough adjectives to describe these roles.

Also bear in mind I have already been doing this for 25 years so if you are just starting out you have an even bigger number.

How are you going to fill the decades of when you reach that top role and your retirement? Does the tech industry even have a track record for this? How about another game.... name the oldest person doing your role in your organisation. Are they 60? How about 50? 40? 30?

It is a probability that we will not be with our current company until we finish working. Looking across the tech sector, 3 years seems like a pretty good run. I have seen some data that suggests 2 years is more likely.

Why not be honest?

In your time with your current company, what do you want to achieve? What do you want to learn? Who do you want to be taught by? Who can you teach and what could you give back? What stories do you want to take with you? Which people will you want to keep in touch with? What great ideas will you emulate? What experiments will you convince people to run with? What improvements will you leave behind? What new habits will you form?

How long do you think that will take?

We all walk in to a company and totally ignore the end.

Expecting organisations to somehow create roles and an ever increasing pay packet is simply too much. They are often just a chapter in our total story - when we understand that our time together will end, we can choose to treat that time with the importance it deserves and make decisions that benefit both us and others.

People leaving us stronger, better, more confident is surely an outcome we should look for and even celebrate.

Clearleft had a lovely way of seeing this:

"Our passion for the digital community and our innate collective desire to make a meaningful contribution towards enabling design to thrive beyond our studio is something that continues to excite and motivate us. The success of ex-employees is one part of that which continues to make us all proud."

Lets start setting an expectation that the time we spend together will be full of mutual learning and value and when it ends we will both be better, wiser and still friends.

What we can learn from booking a meeting

2019-03-16T00:30:00.001-07:00

You have probably had to book a meeting. Tell me if this sounds familiar....

I open up the calendar, find my perfect slot and then start adding delegates.

That's when the problems start. Of my 10 people, I try to find a slot that matches everyone's availability.

Epic fail! As hard as I try, around the date I wanted there is no 'magic' slot where everyone is available.

I have an additional problem in that some people have decided to not allow anyone to read their calendar so I have no idea when would be convenient for them. Oh well, everyone likes a surprise I guess.

The only people I have success with are those people with gaps in their calendar. People who are back to back force me to look at different options.

I also notice that people who have shorter meetings are easier to fit things around. Especially if there are gaps on either side.

The only way I can guarantee everyone's availability is to move it way, way out into the future. For this particular meeting, that's really not an option.

This is where most people would probably just book their ideal slot, giving a compelling background and agenda and adding lots of bold and uppercase writing - basically saying "You need to attend this, move stuff around!". This strategy means you expect flexibility from your delegates.

Maybe you force people to attend. You email each one explain it's not optional and that they need to sort something out. I wish I were that important.

Neither of those are an option for me, so what else could I do.

I could book this out of hours..... they would be available then, right? Failing that, I could always book over a lunchtime that is something people can be flexible with. I would of course be pure evil if I did this but as long as I provide biscuits, I might survive.

So lets look at what would make this successful:

1) Visibility - the more I can see, the better the chances of being able to find something that works for everyone.
2) Flexibility - You could see this from both parties. I need to be flexible with my dates and my delegates need to be flexible with theirs. I might find something that works for most people but some people will need to fall into line.
3) Slack - Without slots anywhere in a day, you will always have to be flexible. So slack helps. People who have planned their days from beginning to end can only disappoint others when they have to change their plans or not attend. Size is a big part of this - the shorter your meetings, the more options this creates when we also introduce slack using gaps in your calendar.

In an organisation that uses a platform model, this metaphor is close to problems with planning at scale.

To build anything, you need to align your development with other areas of the business which have other stuff going on too. It is only together that you can get something to your customer.

Differing priorities for each platform required to build a new feature can reduce flexibility.

We are often transfixed with utilisation of our development people that we fail to see the side effects of this local optimisation - in this case, it makes it even harder to get something in front of our customer. Without slack in our planning systems we offer no opportunities to adjust without making a bigger change somewhere else.

Following the metaphor, we often see long wait times as we have to wait for everyone to become available to even start. This increases leadtimes as it delays when we actually start the work.

The sizes of work also play a huge part. If batches of work are in the months size then we have to lengthy waits and it makes it even harder to align all the platforms that need to contribute. If the owners of those platforms are not flexible either, the problem gets even worse as we cannot negotiate.

We always have the option to stop in the middle of batches but we need to be aware of the waste this might create - the team will have to stop work, potentially having to maintain a branch until they can work on it again as well as loose track of where they were in that work.

As much as we would like people to just switch around, the reality is this stuff is hard and a mental model of what we are doing takes a while to form. We are human, we forget. We also loose track of how important focus is to development teams - swapping and changing types of work does not help!

In a system with a platform setup, the only way to win at planning is to start to change peoples behaviours so you have visibility, flexibility and slack in their local systems to allow better planning at an organisational level.

You could force alignment but be aware of the waste this will create in your system which will probably be hidden from sight.

Or you could simply delay work until you find the 'magic' slot :)

All of this is fantastic argument for vertically aligned feature teams which promise to solve all of these problems. I will write about these soon....

Maturity measured by Retrospectives

2019-02-25T07:26:00.001-08:00

Having built up a wide range of retrospectives I can't help but notice the changes teams go through as they mature in their practices.

If you think about it, if we are continually improving our delivery of software then it follows that our retrospectives will start to look and feel different as we focus on different problems.

1) Stop, I want to get off! - I think the first stage after the euphoria and excitement of moving to an agile process, is to winge. The complaints come thick and fast and it's usually everyone else's problem. It is cathartic but does not really move things forwards. Actions are probably difficult to get. The core problem is that the team don't want to own the process - they have been used to someone else owning it and have not accepted responsibility for it (or have not been allowed to)

2) Own it - Eventually, the team accept that although there are wider problems they own a lot more than they thought they did. I use the 'Perfect Sprint' retro to reset this - showing the team that their perfect sprint is largely in their control helps us get there. They start to come up with actions that they can do but these tend to be poorly managed. The team are still not clear that they own the process and it's still someone else's fault if it isn't working for them.

3) Going through the motions - It's easy coming up with ideas but putting them into action is another problem. The team essentially go through the motions, generate actions but don't have the guts or inclination to go through with them even if they are great ideas. If nothing is done about the actions then there is little point in the retro itself. The core problem is that carrying out actions requires a change in behviour, specifically it means the team need to take responsibility for their process. They realise they own it but changing it might still seem scary or too much work.

4) This is boring :( - To me, this is symptom of the process being OK and working for the team. The actions from the sprints might be predictable and may be difficult to implement since there is nothing much they want to improve when they look at the whole process. It feels boring to the team since everything is OK and the improvements are not immediately obvious or even with the process itself, which has been the primary focus up until now. Actions are pretty well managed by they might look and feel 'samey'.

5) Dive, Dive, Dive! - This is where we look at very specific areas rather than the process. Maybe this is a specific story or problem that the team have encountered. I have looked at metrics, team values, customers and suppliers and other focused topics. These focused retrospectives usually result in actions that are more difficult to put into action e.g. influencing other members of the organisation and usually take longer to carry out. The team will usually be good at keeping track of actions at this point and holding themselves to account.

6) Can we do that? - The team are creating actions and the scope of those actions is growing into a space where they are questioning what they can change. The team starts to ask to own more from its stakeholders and possibly changing the status quo.

7) Hands off - For me the last stage of this process is when the team own the retrospectives too. They see value in the ceremony and are disciplined in keeping track of and carrying out the actions they come up with. They challenge and support each other in carrying out actions and ask for help or advice if they need it.

This is not a sequential process and regressions are common. These are the stages I have seen and think about when working with a team - the goal being for them to own their process and it's evolution whilst honest enough to ask for help if they need it.

Using extremes to help teams

2019-01-03T07:21:00.002-08:00

This is technique I have been using for a while and has a wide range of applications. If you are familiar with affinity mapping, then this takes that and expands it for use in several different areas.

Let's start off with a simple application....

Story sizes have not been working for me for a while. I love the conversations which often uncovered something we had forgotten or someone knew that nobody else did. Unfortunately differing sizes were often a catalyst for these conversations.

In my previous blog about super fast sizing, we used a different way of sizing that I think gets you the best of both worlds.

How I use this in refinement is knowing where to put more effort. 5 days or less needs no more intervention. The team I work with now even have something called a 'fast track', which is 1 day turn around which they do not refine since it would cost more to talk about than do.

More than 2 sprints means we need to spend some time looking at how we could break it down. The ones in the middle we also try to break down but can also accept the increase in risk if we want to.

Asking these questions and gauging the response from the team allows you to invite conversations as a facilitator and help the team explore the scope of the story.

You can also use this for long term estimates. When I was asked about how long a piece of work could take I used extremes to give some idea - "4 months is too pessimistic but 2 months feels to optimistic but it will be somewhere between the two. With progress on this bit of work I would expect this come in as we know more, which I can update you on as we progress". This was just enough to allow our stakeholder to plan.

I often use fist of five voting to get people's feedback on ceremonies. This again uses extremes and you can be playful to make it more fun e.g. ".... where no fingers is 'please, please never ever do this to me again' and 5 fingers is 'this is sooo cool, I think I might get in early just so we can sneak another one in before work'"

Recently, I have used extremes to challenge the status quo. When looking at staff retention, we can honestly ask what would happen if nobody left - is that ideal? This extreme stance makes us realise that the extreme is not ideal either so we can start to ask questions about what is the ideal. In terms of staff retention, we can be realistic about what to expect using the extremes to guide that thought process.

My favourite comes in exploring ideas. We had an example where we were talking about testing strategies and testing environments. We used an extreme to explore some new thinking rather than just what we had.

In this extreme, we asked what our testing strategy look like if we only had our production environment and our local development environments - no dev or integration environments. We explored what branching and releases might look like, what testing we could do and where and the risks we would face.

It's deceptively simple and you have probably be using it without realising in some areas, enjoy!

Technical Debts and Loans

2018-11-16T01:47:00.000-08:00

Yesterday I had one of those fantastic conversations where suddenly ideas crystallise and take a new unexpected form.

Talking with one of my team about technical debt we were musing on if that was the right word. There are so many ways technical debt could be created we were wondering if having a single word was helpful.

For example we may have done something that was the absolutely the right thing to do at the time only for us to learn a better way of doing it in the future. We have debt to clear up but it was not done on purpose.

In another instance we may make a decision to do something in a less that ideal way to enable something else. A common example could be to meet a deadline or recoup some lost time.

This second one, my esteemed colleague suggested sounds more like a loan than a debt. We have traded something for something else we need right now and have the expectation that it will be paid back at some point.

This trade off is a decision and these are difficult to keep track of. Someone else might not have the context of this decision - with the code alone, it just looks like debt.

Let's take that loan metaphor a little further....

If we were going to take out a loan we would definitely have a record of it. It would contain a term and conditions along with an agreement of how much this will cost us at the end of the term.

We would also be aware that this would cost us more than it would have. We have traded getting it now for a higher cost, which we have decided is beneficial to us in the short term. This ensures we are happy with this cost of this service.

We would agree payment terms too, upfront, so we all know when the loan will be repaid in full.

The amount this will cost us depends on several factors which are linked to risk. Where the risk of non-repayment is low the cost of the loan is low and we have more flexibility on the length of the term.

Where the risk is high, the cost of the loan increases and term typically shortens.

The purpose of the loan is also a factor. An investment which can cover the risk, like a house will typically lower the risk, whist something like a car which depreciates quickly will increase it.

Finally the person taking out the loan is considered. In the UK, we have a credit score system which scores your risk as an individual - where your track record on loans and repayments is taken into account.

If you have a habit of not paying loans back, you can be sure you won't be considered a good risk for future loans.

At the extreme, where loans have not be paid after several requests and warnings, collectors will be employed to forcibly recoup the outstanding amount along with additional fees to cover the hassle.

So, let's apply this to some software development!

We have the option of delivering something a bit faster if we trade off some technical area. For the moment, let's assume our stakeholder has a good line of credit so we offer a 'technical loan agreement'.

We outline what we are trading off and what the implications will be in the future. We decide on the risk of this and let that inform the term of the repayment. This term is the maximum amount of time the loan can be left unpaid based on the risk it represents to us as a development team.

We all agree this is the right thing to do and we store the loan agreement as a document which is included in the source for the project concerned. It acts as a permanent record of that decision.

When it comes to prioritisation of work, the team will expect a slice of the throughput to address the debts, which is how we make the repayment. These are refined along with all other stories and we can use forecasting to make sure the delivery of them is inline with the terms of the loan agreement.

When the loan is replayed in full, the document is removed from source but the history can still be relied on if we need it in the future.

If multiple loans are being repayed, there may come a point where this becomes unaffordable for the stakeholder - the repayments for all the outstanding loans exceeds the number of stories we are capable of delivering. The development team can refuse to give a loan until the situation improves e.g. the stakeholder could pay off the outstanding loans in full by giving all the available stories to the team.

Where the terms of a loan are not met, we have some options.

In cases where not paying loans becomes a habit, our stakeholders credit rating would also be impacted. We could only extend loans to low risk decisions limiting the options for our stakeholders. We might even stop loans being offered entirely until the situation improves. The stakeholder may have to rebuild their credit rating with us before they get what they want.

If we have to forcibly collect on a loan (after having asked nicely, many times), we would take stories away from our stakeholders until the debt was paid in full, slowing delivery and probably causing some pain in the process. This could also effect our view of the stakeholders credit rating since we had to intervene.

This may seem playful but it increases visibility of these decisions and gives you feedback which can help build better behaviours across the product and technical teams.

I have written on this subject before, check out "Debts and Credits in your backlog".

Lessons from my favourite angle grinder

2018-08-23T03:53:00.001-07:00

I am a DIY nut. I do a lot of jobs around my house and there are some tools which are indispensable.

So when my Makita Angle Grinder stopped working, a little part of me died. The switch had not felt 'right' for a while so I suspected that it had finally given up.

My beaten, battered, Makita GA9020

It is the single most used tool at the moment since I am building patios, walls and outside kitchens. All of this involves stone and brick, which always needs to be cut at some point. Usually many points.

This tool was particularly expensive. Makita tools generally are. I could have bought a much cheaper version from another manufacturer. This was a significant capital investment for me at the time. I spent more since I had previously bought cheaper tools which had then failed.

I hate throwing things away. And I still need the tool and now I have to buy another one! If I buy another cheap one then the same will likely happen since I will be doing similar if not more complex or heavy work. I can always buy a better (more expensive tool) but my total investment will be higher than it could have been.

It is a popular belief that anything can be repaired. This is not true. Many things are not designed to be repaired and the cost of repairing them would be equivalent to replacing the item with a new one. Cheap angle grinders are like this. If you can find the parts, which is hard in itself, they won't be cheap. Something like the switch might be up to a third of the price of the device. LCD TV's are another good example - replacing a panel can easily be the same or more than the cost of the TV in the first place.

There is also a noticeable difference in build quality. My Makita feels solid and weighs a tonne. It is intended to last and perform it's task even in harsh building environments. Most trades people I know wont turn up with shoddy tools. If one fails, you have lost a days pay for starters. If they do go wrong, you want to have them up and running ASAP for minimal expense.

My angle grinder did have a problem with the switch. I found a new one for under £20 on ebay in about 10 minutes. Replacing it was pretty painless - 4 screws, take off case, swap power, swap motor leads, transfer fuse unit - it took about 15 minutes and most of that was just prising off the case.

I also noted that the brushes can be replaced and the motor be taken out for servicing. The Makita is designed to be fixed and repaired, it was a part of the design. The most likely parts are trivial to replace and required only a screwdriver. It even comes with a guide on how to perform routine maintenance.

As it is designed to be repaired, parts are easy to come by. I could have got my switch for about 30% cheaper if I chose to wait for a generic part from Estonia. We see the same thing happen with car parts - if you are unlucky enough to own a car that was not popular then generic parts might not be made for it, meaning you have to buy the more expensive genuine parts from the manufacturer.

So how does this apply to software?

Good software design should not need a specialist or the original developer to fix or maintain it. Anybody should be able to figure out what to do if we need to play with it.

Investing time to make sure something can be fixed or changed easily will pay up in the future, not now. Identify where that investment is needed most - acknowledge that some components or services wont't change that often.

Making it complex does not help the next person. Making it as simple as you can is more difficult than it seems.

Understand your investment. If this were to stop working how much would it cost you? If you need it to keep working, invest in making sure it can be maintained, diagnosed and fixed.

If you are building just enough to get the job done, understand that more investment will be required in the future if you still want that service.

If you do decide to cut corners, it will end up costing you more. Understand how your whole product cycle works - from cradle to grave - so you can make the right decisions.

To help people out we can produce simple documentation that helps the next person. It does not have to contain everything but should include what we have already thought about.

Think about the components or services you are using and try to use ones which are commodities already, meaning they are well supported and understood.

Understand your environment and build appropriate for that. Building something for 100 users will not be the same as something for 100,000 users.

Routinely check your solution and make sure it is fit for purpose. Don't wait until it goes wrong to fix it.

Vote with your fists

2018-08-07T01:04:00.002-07:00

If there was a single tool I use more than any other with teams it is Fist of Five voting.

If a session with a team does not feel right, at the end I ask the group to provide some feedback. I create a scale from 1 (or 0 if you like) to 5 and give a description for the highest and lowest. I make these up every time, something like "Where 1 is 'please never ask me to do this again' and 5 is 'can we do this every day, it was so much fun'" seems to work well.

You can vary the description to fit what you are looking for. You could choose to describe the scale in terms of effectiveness or return on investment, for example.

Every one then gives a score using their fingers, allowing us to get some insight what people are thinking.

I follow up by asking anyone with a score of 3 or less to suggest one thing we can change that would improve their score. As a group, we quickly decide which ones we will try and then we call the meeting to a close.

This is such a simple mechanism but it works for a couple of reasons:

* The feedback we get from the group is at the same time as the problem they observed, making it easier to act on
* Changes are often small so they are easier to implement in the next meeting
* We encourage group ownership of our ceremonies and meetings which helps people engage and take responsibility for their success

An obvious place to try to this is in you standup. If it feels wrong, this would well get some instant feedback that you can put into practice the next day.

But.... Where do I start?

2018-07-16T03:41:00.001-07:00

I have been with a few teams now and I was reflecting on how I deal with each transition. I also paused to think how the teams I work with feel too, given we are both in a new unfamiliar situation.

So what have I learned?

1) Pause and think about where your team has been (and what they have seen)

Joining a new team, I am always interested in what they are doing. I think we should be more interested why they are doing it.

We often use the word journey and that's what I'm interested in more than the outcome. If we take time to understand how the team got to where they are, we can often understand more about what drives them, what scares them and how we might be able to help.

One team had a whole load of history which resulted in some seemingly odd behaviors. It all made sense once you understood their journey. This cannot be told by any single person - I heard several versions from several people and somewhere in there was what really happened.

Being sensitive to what the team has been through has been a key learning point for me. It has helped me tailor my own behaviors, language and coaching to get better results from the groups and individuals I work with.

2) Assume the best at all times, especially about people

Despite everything I can see and observe, I have to assume that people are doing the best they can, given the situation they are in and what they know. This is liberally taken from the Prime Directive, which is often used as a kick off to retrospectives.

To me, this applies at all times. It should be our go to place, even with people and teams we have only just started working with.

In one interview, we were doing an exercise where we show a board and ask the candidate what they can see and what questions they would ask of the team. There was an obvious issue where the same avatar was on 3 cards in the development column. The candidate went to great pains to say what the developer is doing wrong and it was not helping other problems they could see on the board.

They never once thought about why the person was doing that and that maybe they are doing things for the right reasons, given their own situation.

What if they were a contractor who was really worried about their renewal and wanted to show how productive they were? What if they had to pick up extra work because someone was on holiday and their stories had not been completed? What if the person really was working on these 3 things by putting in a load of extra hours because they were trying not to let their team down?

3) Make it all visible. Even if it doesn't look good.

At first things often look OK. It's only with transparency do we start to see the problems. Issues are often hidden away and need a bit of coaxing out so we can see the causes.

This takes some guts as people might not like what they see. It is the start of how we adapt ourselves and our processes - without being able to see the problem, you cannot start to fix it.

Transparency not only shows this to the team but also to the world outside the team. This is both a blessing and curse since you may have to deal with attention that you would prefer not to have. In my experience, the benefits definitely outweigh the problems.

4) It not about 'the' process it's about 'a' process

I like scrum. I also like kanban. Some teams need one, some teams need the other. Some teams need something else. Sometimes we need to start with 'something' so we can start to own it.

If a process is intended to evolve, when does it cease to be what it started out as? What makes Scrum, Scrum or Kanban, Kanban? If we embrace being able to adapt, our process will change as we solve problems and find new ones.

The right process is the one that helps the team build software in the best way for them. Often this is dealing with the situation they are in and the problems they face internally as well as externally. It changes over time as our situation changes.

Key to this is encouraging the team to own the process, to be invested in it. For me, a sign of a mature team is owning actions from retrospectives with the same responsibility as they have for building quality software. They are invested in both equally because combined they allow them to achieve their goal. This is built slowly over time with enthusiasm, retrospectives and responsibility.

Resist the urge to replace what the team have. Work with what you have and remember point 1.

5) Give the gift of consistency

In my experience, most things have already been tried by teams who have been around for a while.

Just because something did not work in the past does not mean it will never work. It might be that the time was not right. It is more likely it was not given a chance.

The difference between trying something and using something is consistency. You need to consistently do something for a while until it becomes habit.

These can look like rules and my goal is that these are owned by the team not mandated by myself. You know they have become habits when individuals would defend them if they were taken away.

Being consistent about applying something new is the enabler that allows this to happen. I was pretty terrible at this but I have seen the benefits of being rigorous in applying something new, so I had to learn how to do it. You know you are getting somewhere when others uphold the consistency too.

Stream or Team?

2018-06-27T07:07:00.001-07:00

I have been working in a scaled environment for a while and the addition of new teams is a regular occurrence.

Recently I have been seeing that what we call a team is actually a stream. In this context a stream is a priority of work that needs to be done in parallel with another priority of work.

Here are some tests myself and one team came up with to sanity check a new team based on our previous experience.

It's a new team if:

1) The team own their code base and can make technical decisions without upsetting, involving or discussing with anyone else

2) There is a backlog of work and the size of the domain ensures the team will have work for the foreseeable future

3) The team can deploy whenever they need to without needing to plan or consult with anyone else

So let's go through some of the learnings that led us to these statements.

The main part of this is around autonomy and responsibility. Picture a team that realises a significant change to the way they branch their code would solve problems they are having. The empowerment we want to give is that they can act on this insight and change whatever they need to change to make them more effective. It's good for them and for business since they waste less time.

Imagine now that they have to validate this change with some others. Worse they have to persuade them that this will help them too. Decisions by the team need to be backed with the autonomy to make those changes as well as accepting the responsibility for doing so.

If it doesn't work out it only affects the people who decided it and they hold themselves accountable for the decision. This is why autonomy and responsibility are twins - one makes little sense without the other.

A repeating thing I see is the call for feature teams to be spun up to focus on a specific deliverable. This often ignores the longer term effects of this decision, namely who will support this new feature once it has been delivered into production. In my opinion, this requirement is best handled by the team who created it to avoid hand offs between support or ops team that might be present in the business.

Longer term side effects could also see knowledge about the feature lost as the team is dispersed and the feature is no longer actively developed. Different strategies need to be used in terms of documentation and testing as we need to ensure we preserve the feature, do not regress it and are aware it even exists. These all problems get worse with time - the longer we don't work on something, the more it drifts in the realm of fear and 'legacy'.

Ensuring work can easily be deployed into production by a team is fast becoming a standard in fast moving organisations. Allowing teams to do this whenever they need to is a key enabler in them producing high quality software with lower risk. Inferred in this ability to deploy is the ownership of the environments that make up a teams path to live.

Any sort of sharing or gating of systems that help a team get feedback on the quality of their software is counter productive. The team need to own these too, allowing them to change their ideas and strategies in line with the problems they need to overcome. Some gates may be necessary, such as change control or regulatory requirements but they can always be adapted and tuned to help developers as much as possible.

Teams owning their area of the world and knowing there is a vision for them is a powerful thing. It helps us create a sense of purpose and belonging, along with all the disciplines we value in building and keeping this running. Forming a team around a transient feature is not the same, it feels 'different' and can miss the essential sense of ownership and responsibility that benefits the business.

Making sure the area the team work in is actually big enough is key here. Too small and any hope of keeping people challenged is going to be hard. Making it too large will also making it harder to ensure a uniform understanding across the team. Knowledge silo's form easily in larger teams and the effects are subtle. It can go unnoticed that a specific individual is an enabler for others since they are needed to start or complete specific types of work.

Following on with that thought, the architecture of what you are designing will enable or block teams from being able to form. It might not be possible to simply carve up an existing architecture and assign different parts to different teams. There are often shared components or services which do not sit neatly in your new boundaries. There is a reason why discrete, contained microservices have become more an more popular recently....

There are other strategies you can employ but they all have varying pro's and con's e.g. component ownership seems like a good idea until you cannot balance keeping the team supplied with work and building things the business wants - you cannot guarantee that every component has an equal share of new work. Making sure a team has valuable work to do is among the most basic requirements for a team, so having a team structure that does not make this easy does not make sense.

I use these tests whenever there is a requirement to add more people. There is a sweet spot for the number of people in a team but also the number of teams based on your situation. These reflect my own experiences and I'm sure there are stories that conflict. I would love to hear them - how do these tests sit with your own experience?

Retrospective: Health Check Retro

2018-06-22T04:03:00.000-07:00

Across the organisation I work with, we do a quarterly health check which is very much stolen from the excellent work Spotify did way back in 2014.

One of the problems our community of practice brought up was follow up by the teams themselves. We did this which gave the organisation this fantastic view of how we feel about the teams we work in but the teams never used the same information to improve. Odd right?

I was guilty of this and so I decided to have a retro to focus on improvements the team wanted to make before the next health check.

The setup for this retro was to get the team to vote on the areas which they wanted to see the most improvement in. This was a really quick dot voting exercise at the end of a stand up.

In the retro itself, these are the focus areas. We kick off by asking the team to list the problems they see in each of these areas. I like time boxes and gave them a whopping 7 minutes to pull these thoughts out into a flurry of post its.

I now pick on someone in the team to group the post it so we can see some themes. This is often the person who has used their phone the most or failing that a BA (since they usually have a knack for seeing some groups).

Next, we focus on just a few problem areas by dot voting. Getting them to list the problems means I can now complete the setup and ask them to find solutions for the problems we came up with, again giving them an aggressive time box to work to.

We now go through everything we have come up with, clarifying anything that is abstract (there are always a few) and asking some questions to get people thinking about what they are trying to solve:

How does this help solve the problem?
How is this related to the problem?
If you did this, what do you hope to fix?
Will this fix the whole problem?
What else might be have to do to fix the problem?

This bit is to clarify what everyone has come up with, which is important since we are going to ask people to own these.

The last part of this is the ask people to come up and choose 2 solutions. One that they put into practice this iteration and another one which is longer term. If people look like they lack enthusiasm, point out that the first people get to cherry pick the best things.... that usually helps.

They each read out what they chose for this iteration and talk about what they intend to do. We can keep on top of these in stand ups, asking what help we need to give to keep up the momentum.

Their homework is to think about how they will bring their other longer term task into action and what help they will need, which we will discuss in the next retro.

What else can you get from source control?

2018-06-21T01:43:00.001-07:00

A while back I presented at a couple of conferences with my good friend Helen Meek on the subject of feedback in organisations and teams.

We created a process you can do in your own organisation to help you score feedback mechanisms in a range of dimensions, allowing you to discover ones which are relevant to your organisation.

The site we created for this is still around, if you would like to have a look. We updated the site with the outputs from each of the sessions, giving an aggregated view of about a hundred people rather than just ours: http://swimminginfeedback.blogspot.com/

Some lucky people even got a set of cards, allowing you to quickly choose ones to look into using a few different games. Our inspiration for the format was 'Top Trumps', a card based game from our misspent youth.

We did this because we wanted to open people's eyes to the huge amount of feedback mechanisms we have in our organisations and how few of them we actually use to find, maintain and inspire improvement.

These are some ways of using your source control to help your teams see some new things, depending on what you want to do:

Changing Branching Strategy

Git has made it super easy to branch and merge. The downside of this is we can often live in a branch for too long, delaying intergation that should be verified by running our automated tests. There is a cost for CI and it is usually only run on key branches - main and/or development depending on your strategy.

Moving to trunk based development is something my team are currently working on. There is a lot of heavy lifting in our build pipelines that we need to do but there are also more subtle changes in the way we develop, which I think will take a longer time. The question I had was: how do we know we are getting better at this?

In this instance we can mine source control to show us data that we should use to help bring about this change:

How many branches have we got?
Are we nesting branches?
How long do the branches live for?
Are multiple people committing to branches?
How many commits are we doing per day?

The habits we have are often the hardest to change. Using these bits of data we can have a conversation about what is hold us back, maybe even what is scaring us from changing.

Test Coverage Strategy

Test coverage is a thorny subject. Tooling can give a skewed view of the world, so it should be used only as a guide. We should rely on developers assessing coverage using a range of techniques to build a more rounded picture of test coverage and where it is needed.

My observation is we rarely use our source control to help us decide on our test coverage strategy. At a basic level, we can draw a picture of how often different areas of the repository are changing. I would expect our need for comprehensive test coverage to be greater in areas of the code base that are changing frequently, helping us get feedback on if we have broken something.

If an area is not changing - there are always things that 'just work' - we should factor this into our strategy. In terms of return on investment, they don't have nearly as much impact as areas that are changing frequently and should be treated differently.

Blind Commits

In an ideal world, every code change should be linked to a story which describes the value and intent behind it.

We don't live there.

Most commits have some sort of link to a story. Maybe take some time to find the ones that didn't and find out why. These are invisible changes to your systems. Without a story what were the acceptance criteria? How were they tested? How were they prioritised?

Source control is a rich source of information, if you have a little imagination you find all sorts of things that identify problems or highlight possible improvements.

Accelerating product discovery using experiences

2018-06-19T09:30:00.001-07:00

I am a DIY fan. I like building things and over the last year I have had to try a load of new things since I was low on cash but had time to spare.

Recently, I have been doing some tiling and found working out where to start tiling a wall actually quite difficult. There are indeed 'apps for that' I had a look around and nothing really did what I wanted so I thought I would build something for fun.

Instead of pile straight into some code I stopped and took some of my own advice. I recently wrote a little about using experiences to help discover product features, so this seems like a good opportunity to show how this works.

So after about 7 minutes of 'work' I came up with this comic strip which is explains my experience of tiling a wall in my kitchen:

This small dialogue describes the experience I had. I call this a negative or problem story - it explains the problems I had and gives some context of why.

As product developers we can dig a little into this dialog and find extra detail in the conversation. In a problem story, this is all about what has happened so we can expect to find some observations and assumptions. The difference between the 2 is simple - one is observable, something we know is happening and the other is something we think might be happening.

For each cell of the comic strip we quickly extract some key words or maybe phrases (1 word definitely, may be 2):

Cell 1: pride, amateur, mistake, research
Cell 2: ignorance, questions, previous work
Cell 3: lesson, impact, planning, difficult
Cell 4: surprise, assumption, simplistic

Next I would create some statements for each cell which would describe our keywords in a little more detail. Some statements might cover several keywords and that's fine. I also categorise what I find as an assumption or observation:

Cell 1
"People like to take pride in their work" - Assumption
"Some jobs take a considerable amount of effort" - Observation
"People look up things if they don't know how to do them" - Assumption
"People want to learn from our previous mistakes" - Assumption

Cell 2
"Some people might not know what a good job looks like" - Assumption
"Given different jobs some people will still not be able spot the problems" - Assumption

Cell 3
"Starting correctly helps ensure the job goes well" - Assumption
"Specific problems can be avoided through forward planning" - Observation
"Knowing what to look for is not obvious to everyone" - Assumption
"Even when you know what to do, it might not be easy to do in practice" - Observation

Cell 4
"People might think they know what to do when they don't" - Assumption

I am doing this solo and I would recommend doing this in a group so there is a conversation around these experiences. By doing this by myself I am subject to my own biases but you should get an idea of how this works.

As someone building a product, a probably spending a while doing so, I am particularly interested in the assumptions I have listed. I can zero in on the one that bothers me most and tackle just that or I could list them out in order and tackle all of them. At this point it's all about visibility - given what we know now, is there anything we should test before we proceed?

As someone thinking about making something to solve a specific problem, a couple of these are troubling:

"People look up things if they don't know how to do them"
If people don't they will never know there is something that might help them! I would want to be pretty sure that people will research about how to tile rather than just doing it. If they won't seek out information they will never find something that could help them.

"People might think they know what to do when they don't"
Similar to above. Often called "unknowns, unknowns" these are things have complete ignorance about and would not think of getting outside knowledge about.

"People want to learn from our previous mistakes"
If people don't want to then any amount of information that might help them wont make any difference. They won't find out how to do it properly because they simply don't want to!

As product team just starting I would look at these as elements of risk. By proceeding without testing these assumptions, we risk our product not being fit for purpose. If we think the risk is small enough - or we feel confident about our market experience etc etc - we could proceed and convert these into risks.

The observations might help us target anything we build at our target audience a little better:

"Some jobs take a considerable amount of effort"
Helping people to not waste time or materials doing the wrong thing could help us sell our product.

"Specific problems can be avoided through forward planning"
Offering something that helps avoid common issues could also help us sell our product. "Canning" expertise and providing this knowledge in an easy to use format is something people find useful.

"Even when you know what to do, it might not be easy to do in practice"
There are some things that are just difficult. If we can solve that problem, we have something that people might want to use.

I have done this exercise with several groups of people and I am always surprised by the insight that is generated by this - we always find something interesting. It's also very fast - doing this including writing this blog has taken about 45 minutes.

You can scale this with larger groups by using a technique called "diverge and merge". Multiple, smaller groups do the same exercise and then you merge these together. Similar comic strips represent similar thinking, which is valuable since everyone is thinking the same thing. Divergent comic strips give allow us to explore our scope - we can ask if these are valid and maybe spend some time on them or we can ignore them depending on what they represent.

So far we have explored the problem, how about the solution. Comic strip conversations can be used for that to.

This time we put ourselves in the future and describe the experience we want our customers to have once we have built our product.

As I mentioned in my previous blog, asking people to imagine what they would want to hear people talking about is a great way of thinking about the experience we want to create for our customers. In NPR speak - "What would turn our customers into advocates?"

This time, we have an additional thing we can extract from the conversation: features.

Features are things we need to build in order to bring about this experience. We still have observations and assumptions but the assumptions are slightly different - these could be assumptions that are based on us building our features. So assumptions could be present now or they could be assumptions that we will only realise once we have built our feature.

Since we have already done this in some detail, I will call out the features only which are all in Cell 4:

"There is an app that someone can use"
"We can calculate the number of tiles you will need for a specific job"
"We can predict the best place to start tiling"
"Different size tiles mean different calculations"
"Different tiling patterns mean different calculations"
"Common planning problems are avoided"

All of these are features that support the experience we are describing. There could well be more but by just looking at the experience we want to create, we can focus on what will directly support or generate it.

Done in a larger group you will end up with several types of experience. You can then order these however you wish, allowing you to focus on the ones that create the impact you want to have with your customers.

As a product team, look at what we have to kick our project with:

Assumptions we might want to test or convert into risks if we decide we want to continue
Observations that support our product idea and help us find customers that will benefit from it
Features that generate experiences that we want to create for our customers

Next steps are up to you but you could take the scope from this and go straight into a story mapping session. The advantage of focusing on the experience means that the scope you have will directly contribute to what you need to build for your customer.

Did I mention it's fast?

I would love to hear your experience of using this. I have documented the method I have been using and provided templates for creating your own comic strips which you can download from here. Let me know how it goes.

Retrospective: Protest!

2018-06-12T08:31:00.001-07:00

This is my new favourite retrospective.

Emotive and simple, it encourages members of the team to voice their concerns and create a protest.

Literally.

The format is very simple. Use the PowerPoint deck to show some examples of signs from protest and then get each member of the team to come up with a protest of their own along with a sign that would explain it.

I have been curating signs from protests for a while on Pinterest. I would give the link but they contain a wide range of swearing so it does not feel 'cool' to include the link here. Contact me if you want me to share the board privately.

You can then talk about each person's 'movement':

What's the cause?
Who is the audience?
Who are your followers?
What's your ideal solution?

This is more of a way to get the team to open up about issues they feel strongly about. These might not have been addressed so this gives a direct way of the team telling you what their cause is - without having to start a real protest!

View the Protest PowerPoint

Remembering past last week

2018-06-06T01:30:00.002-07:00

We know from experience that people often have very short memories when they participate in a retro.

It is no surprise that we only usually get the problems from the end of the sprint since this is often where the pressure is. Any good things are usually drowned out by the tide of problems we discovered yesterday.

So imagine my delight at taking people back over 6 months. And not just one team - a whole bunch of teams all working on the 'Consents' programme of work which basically made our company GDPR compliant.

So here is the method I used, which worked nicely and created some good conversations and insights for the people who participated.

We first set a homework task. This is essentially the ice breaker but served a purpose too. The team were asked to bring a picture that represented the project at the beginning and one that represented the project now.

The idea is to get people to think back to the beginning. I was conscious that different people got involved at different times and that is fine. We just wanted them to take the time to think back right to the beginning to break the cycle of only remembering the last things.

I drew a timeline which represented the project from beginning to end and got people to show the pictures they chose and explain why e.g.

A picture of the lone ranger herding some cats was because that person really didn't know how to go about this project at the start, they chose a cover of George Orwell's '1984' to explain that during the project he became much more data security aware and by the end it was something he was seeking out since he was interested in it.

We heard several stories which started with this very simple beginning and end. You don't need everyone to do this (they won't) but a couple set the scene. This is usually funny and often thought provoking - I have used this as the basis for a team retro too.

Next we add some points on the timeline to give some scale. For us, we added some key sale periods and Christmas. It will always be terribly inaccurate, you just need enough to make sense of the timescale as a whole.

With about 20 people in the room, you will generate a LOT of data. The trick is to find a way of bringing out trends. Grouping will take too long so I use a colour key and an additional dimension to allow the group to talk about what happened.

With this group, we gave them different coloured post-its depending on their role in the project, there were 4 in total. The dimension we added was good/bad - if the thing they are remembering was good then place it above the timeline, the opposite for bad. The further it is away from the timeline, the more pronounced that is.

I then gave the group 7 minutes to go post-it crazy and place these insights on the timeline. I can be messy and little loud but it's only for 7 minutes!

Once finished we asked them to look at what they had created:

Next, we ask them to look for some trends:

* On balance, which group of people had the most insights? Who had the least?
* On balance, was this a positive experience or a negative one?
* Was there a specific part of the project where something was wrong? What happened?
* Which part of the project was busiest and why?
* What happened here? (point to a cluster or peak)
* Was this the best thing that happened? (point to top post it) Why?
* Was this this the worst thing that happened? (point to bottom post it) Why?

For the most prominent groups, we asked them to tell their story from beginning to end. This is often lead by and individual but they speak for a group since people tend to work together to remember what happened.

People add insights from their own perspective as each of these is told. Over half the session is just this. As a facilitator, you can ask open questions and maybe pull in individuals who aren't speaking or look like they want to but cannot break into the dialog.

At this point we collecting data, sharing perspectives. I usually ask for the high and low point from each of the story tellers, which can break them out of concentrating on a single time period. You can pull out specific cards from the wall if there are interesting ones but the purpose is not to use that data - it is just a vehicle to get people to think across the whole timeline and highlight areas that might be interesting to talk about.

To close, we want some canned insight that we can learn from. To do this I pose the question:

If you were on another project and you were working with some new people, what advice would you give them? If you could hand them a piece of paper that would help them, what would it say? What mistakes would you want people to steer clear of and what inspiration could you give based on what we have found out today?

The output is a single statement from each person. We grouped these into themes that allowed us to see where there was consensus in their experience even though their involvement and roles in the programme were completely different. As people left, we asked them to vote for their favourites and encouraged them to use this insight to improve the next programme they were involved in. We share the favourites with the more senior management and try to steer the structure of work at a higher level based on this feedback, hopefully improving each one as we go.

Experiences vs Value

2018-06-05T03:45:00.001-07:00

You have probably heard of this before:

Our customers are our number 1 priority

You probably have a variation of this in your own organisation.

Is it really that simple? What about this anomaly:

As a registered user of Papa John’s pizza
When I try to check out as an anonymous user
Then I will be forced to login to my account

I have picked on Papa John’s here but we see these trade-offs all over the place. In this case we are stopping a transaction - which is not in Papa John’s or the customers interest. They do not seem in line with our statement about the customer being our number one priority.

Make no mistake, this was a choice. It takes more work to do this than to allow the transaction as an anonymous user. We don’t know why but we can assume that someone benefits from this decision – marketing or data science, would be good guesses.

So maybe it’s our view of who a customer is that is incorrect? Eric Ries uses this definition for a customer:

Any person who you hope will find enough value in your product or service to make some kind of investment in it, or partnership with you.

We are used to thinking of the paying customer as our primary focus but customers take all shapes and forms. They are often internal to our organisations.

In a world with multiple types of customers, we often impact one to benefit another. These are often hard choices.

So maybe we need to tweak our original statement:

Our customers are our number 1 priority*

*Some customers are more important than others

So if marketing teams are customers, what about development teams? Are they customers too? They are clearly invested in what we do.

When a development team wants to do something, they are usually asked about the ‘value’ of it. The problem being for most development teams that most of the things they want are only measurable in retrospect, so the value is difficult to measure or prove.

This statement from a developer, makes a lot of sense to me:

What about developers doing a good job, knowing we built the right thing in the right way and being trusted to do so. Why isn’t that valuable?

Very few of our business decisions are based on cold hard data. If you spend time with some data scientists, who ONLY use data to make decisions based on specific tests you realise that most of the decisions we make are not based on fact.

We don’t gather data either because it will take too long or we simply don’t know how.

Again, maybe our view of value is incorrect here. Maybe it’s even the wrong word. How about another tweak:

Our customers experiences are our number 1 priority*

*Some experiences are more important than others

Instead of talking about value, what happened if we only talked about the experience we want to create for our customers?

Our developers experience of building and supporting our product can been see alongside our customers experience of using it and our marketing persons experience of working with the data gathered from our customers actions.

The problem we encounter straight away is how to we talk about an experience? What is the language we use?

This is where using comic strips come in handy, which was inspired by the work Carol Grey did with Social Stories and Comic Strip Conversations. They were created to solve a completely different problem, but they work here too. If you want to find out more, google is your friend.

We use a comic strip to describe the dialog between 2 people, one of whom has used your product. This is told using only 4 cells – I usually ask people to imagine they are walking past these 2 people and overhear the conversation, which they then condense and re-tell.

The constraint of having only 4 cells means you must focus on the key things that make your customers experience enjoyable. What would we like people to be talking about if we built this? What would turn them into advocates, using NPR speak?

So, using my Pizza Problem, let’s look at what I would have liked my experience to be:

What did you get from this short dialog?

What experience were we trying to create for our customer?

What problems are we trying to solve?

The strange thing is that using dialog to talk about our experiences with products or features turns out to be a lot shorter than trying to describe it. This is powerful and you can use it to find assumptions, observations and features inferred in the conversation:

Observations are things we can see or have evidence of
Assumptions are thing we think are happening or will happen once we have built our product
Features are the things we need to build to bring about the experience we describing

For example, in cell 4 there are several statements we pulled out from the dialog:

People know their account details (Assumption)
People who have an account are regular users (Assumption)
Anyone can checkout anonymously (Feature)

Sadly, the feature that would have saved the day was not built in this instance. We could have probably validated the 2 assumptions using metrics:

How often do people reset their password?
What is the relationship between the time between logins and resetting a password?
Are logged in users more likely to order more frequently?

Maybe all this was done and the number of people this would affect was smaller than the benefit given to the other customer by forcing a login if you have an account.

Yes, you could say that these are all ‘value’ statements but focussing on the experience stops us from ‘bundling’ more in. When this happens, it becomes difficult to separate the things that directly create the experience – this complicates delivery since we cannot reduce scope and ultimately delays our customer experience.

Exploring experiences can be done before we build anything, allowing us to examine the intended experiences and look at what creates them. We can validate any assumptions we have or articulate them as risks because we simply don’t know. It also highlights the features that we should build to improve our customers experiences with our products.

For or With?

2018-06-05T03:27:00.002-07:00

When you meet someone new, how do you do it?

The timeless classic seems to be: "Hi! I'm Bob, I work for Widgets Incorporated"

Maybe this is split into a 2 sentences but the word 'for' feels... wrong.

The word 'for' re-enforces a sense of hierarchy, that you are controlled by someone, that you are a servant.

Next time, try replacing 'for' with the word 'with'.

For me this is feels more aligned. More like the choice it really is.

The important features of a great team

2018-02-23T08:11:00.001-08:00

There is a game we play at home that I would like to share.

The rules are simple:

Given you are alone in a dark room or corridor
When you hear someone else approaching
Then you have try jump out at them
And scare the c**p out of them

There is some skill to this game. Once you have played it a few times everyone knows what is going to happen. In anticipation, everyone goes very silent in order to detect where the other one is. Inevitably, people stop breathing but start laughing - first one who does has lost.

None of the kids play this game. This is something myself and Mrs A do, which is most unbecoming of some 40 year olds.

It is something that is uniquely ours. Something that does not really make sense in another context. It is special to us but probably completely dumb to others. It was not planned but was spontaneous and if it was copied would not be the same.

But this is where the good stuff is.

Teams also have these special bits too. They come from working closely with each other and letting your guard down enough to reveal our human selves.

This does not happen immediately. I often does not happen if there conditions are not right, if there is not enough freedom to express who we are and explore our relationships with one another.

Often unprofessional, usually silly and totally unique to each team, these are the special features that make teams great both to work in and with. Love them or loose them.

All worship Board God

2018-02-22T05:51:00.000-08:00

The use of boards by teams is nothing new, every team I work with has some way of visualising their work. Many teams seem to stall at changing the board, leaving ownership to some individual (maybe the ScrumMaster or the most vocal member of the group).

This is a shame. Since the board mirrors the teams process, which is owned by the team.

I was in a situation where the board was being dictated by a single person and the team looked too scared to change it. People would compain about the board by not try to do anything about it.

In a moment of frustration, I thought "Fine, you fix it".

Enter the 'Board God'.

If anyone ventures a strong opinion on the board you can appoint them as 'Board God' for a week.

The Board God can do anything to the board they like and the team have to follow their direction for that week. At the end of the week, the team decides what they will keep and what they will reject. Stripped of his or her powers the Board God must accept their decision.

If I hear someone grumbling about something on the board, I usually appoint them 'Board God' to see how they will solve the problem they are grumbling about. Eventually, people will start to ask if they can be 'Board God' to address a specific issue that they can see.

This can trigger a spate of change, where different 'Board God's' mess with each others changes. This is a positive thing since people are getting involved with the board and ultimately the process itself.

Teams that have learned to embrace changing the board often evolve their process outside of the retrospective, shortening feedback to days or even hours.

When used in conjunction with scoring stand-ups, a team can inspect and adapt quickly. I have seen stand ups of 20+ people go from train wreck to useful in under a week using peer feedback. A score of 3 or under means you have to share what was wrong for you and the team agree corrective actions for the next day there and then.

'Board Gods' provide a solution to a problem that is then inspected by the team. The process adapts to the use the good bits and things that do not work are discarded in a safe to fail way. One team I worked with even versioned their board to help them understand when a lasting change was implemented.

This idea started as a punishment but has turned out to be a useful tool to remind teams who owns the process and encourage them to get involved in shaping it.

"But they won't listen to me!!!"

2018-01-10T01:46:00.003-08:00

On entering the house last Friday I was hijacked by my daughter. What happened next I was not expecting but it was an interesting experience for both of us.

She explained that she has been asked by the teachers to be the manager of a cafe to raise money for charity. She has a small team and they need to organise the event and make sure everything runs smoothly. She is 10 so the rest of this makes sense :)

So my daughter comes up with a plan, tells the team what they will do and.... well, you can imagine what happens next. One of them ends up storming off to the bathroom, 2 of them rip up the plan and come up with their own one and the rest slope off to do something else. I think we've all been here, right?

OK a double serving of coaching coming right up.... let's establish the goal.

"I want them to do what I tell them to"

Wow. OK. Healthly dose of reality required. So sweetheart, how do you feel when you are told what to do? She ponders for a bit and comes back with something else.

"I want to do something that will help us bond so we can work together"

OK, nice. Still not sure this is the goal but we are thinking differently. So, if I could wave a magic wand and fix this for you what would it look like? How would people behave?

"People would listen to me and we would come up with a plan that we would all agree on"

Damn it! So close. Oh well. I know her plan is confetti but it sounds like there is 'a' plan - what is wrong with the plan the others came up with? What won't work about it?

* rant * rant * rant *

Synopsis: takes too long to serve people and everyone needs to queue which they won't do

So it takes too long to serve each person. What kind of too long to wait is too long?

"It will take 5 minutes to serve each person"

Wow. That is very exact. How do you know it will take 5 minutes?

"That's how long it will take"

Could we test this? If I asked you to sit still and tell me when 5 minutes has passed, how close do you think you would be? For the record, my daughter has never sat in the same place for 5 minutes. Ever. So I feel this is pretty good bet.

So we test our assumption - I set a timer and she sits on a chair. After about 2 minutes I notice that she seems to be counting under her breath so I start saying random numbers since I figure she is counting so she knows how long is passed. I seem to have underestimated the sneakyness (but am secretly impressed).

After about 3 minutes I ask her how long has passed and she says about 3 minutes (!) but acknowledges that it is a really long time so I deem the experiment a partial success and we move on.

How long do you really think it will take to serve each customer? What could do to find out? The shrugs are less than encouraging so I ask what she would like from MY cafe....

We act out serving a drink and a cake in the kitchen and both agree it probably wont take very long at all to serve people. We talk a little about assumptions and how we can usually test them rather than accept them as truth which mostly gets ignored.

So what's wrong with letting the others go through their plan? Could you act it out like we just did? Would that be better than trying to come up with a plan that you all had to follow? After all if something didn't quite work you could always change what you are doing.... it's also a lot more fun.

"Yeah, that might work. I still want to do something that will help us bond"

OK. I'm tired. We go through "String of Pearls" and she assumes the roles of all members of her team. Again secretly impressed she can remember each persons role and moves into each of their imaginary positions as she says them.

Since everyone can say what ever they want, how come we end up with a story?

"We listen to each other and know it all needs to join up to make sense in the end"

Wise words indeed.

So the next day, what happens? My daughter goes and finds the teacher who organises the McMillan tea morning and asks her to help her team. Just like what Mrs A said before I got home last Friday.

I think I will leave this to Mrs A in the future, we all know she's always right :)

Can you really manage people?

2017-11-10T01:06:00.005-08:00

My wife says I get hung up on words a little too much, which is probably true. She often tells me I am reading too much into the word itself and forgetting what it really means.

Of all the words I hear every day, 'management' is high up on my list of words I don't like. This is speaking as a line 'manager', with line 'management' qualifications who 'manages' stuff as well as people.

Here's how I found a happy place for my 'management' responsibilities.

I like to swap things around. So here's a simple test - has anyone,ever come up to you and said "Manage me"? How about "Please manage me?"

No? Doesn't that seem a little weird. If it was something that people wanted or needed don't you think they would ask for it?

Whilst the settings on my computer might need management I think that people do not.

How about the following:

* Help me
* Teach me
* Guide me
* Coach me
* Listen to me

My wife would argue that the word 'management' really symbolises these things, the word itself is not important. And she is probably right (as always).

Do yo' Dojo?

2017-10-25T06:59:00.002-07:00

One of the major bits of my personal development has been through coaching dojo's, which were first run by Helen Meek from RippleRock.

Taken from martial arts a dojo is a place for practice. How we use them is not much different - it is where we practice coaching.

Just like a real dojo a coaching dojo is a special place and it needs to be cared for. In a coaching dojo:

* We create a safe space - nothing is judged, nothing is shared with others
* We are all learning and mistakes are inevitable
* We turn up on time!

The setup works best with one host and 3 participants, 2 is OK as well. 1 hour sessions work well, you can expect to be pretty tired at the end of one!

We often focus a session on a particular coaching method. Starting with GROW feels right and is a simple method for people to understand and use for the first time. We usually include an intro for first timers to help them understand what coaching is and is not - discussing the difference between coaching, teaching and mentoring often helps people understand.

Through multiple sessions, once people have enough practice in one method you can then introduce more: SARA, OSCAR, CIGAR, 5 Whys etc.

We ask people to come with a problem. Ideally this will be current and real, something you need help with. Alternatively, you can go back to a situation you have already been through and maybe had some sort of resolution to. The key thing is that it is real for you. You can role play but it is just not the same, you are welcome to have your own opinion.

In a timebox of your choosing (7 - 10 mins) you have a coaching session. Someone volunteers to be the coachee (the one with the problem) and someone to be the coach. Everyone else is an observer, writing notes is a great idea allowing you to play back your observations in sequence. It is important to feedback both good AND bad since both perspectives are required. Suggestions are always welcome.

You allow the coach to complete their session and then the host gathers feedback. We ask the coachee for their perspective as well as the coach and the observers, including the hosts. It is somewhere in these perspectives that you learn what works and where you can improve.

Swap the roles round and repeat as many times as you can in your session.

In running these sessions, we have found there is no one type of person who benefits - everyone who has attended these sessions has found them useful irrespective of role. There is a lot that can be said about people taking the time to learn how to listen and ask 'powerful' questions....

For me personally, I have a tendency to solutionise. This led to me asking closed questions very frequently which is not helpful for the coachee. I was also pretty terrible as listening, often steering a conversation to where I wanted it to go rather than where the coachee needed it to go. Had I done this with a 'real' person I fear I would have done more harm than good.

True Story: In an effort to show me how many closed questions I was asking, Helen once simply responded 'no' to each one. It was brutal. Having said 'no' for most of the session, it was pretty obvious what I needed to improve. It was only through coaching sessions did this happen even though I had read several books and been to several meetups about coaching.