Stream or Team?

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

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?

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

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!

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

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

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?

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.