The hidden features of Feature teams

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.

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.

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.