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.
Monday, 25 February 2019
Thursday, 3 January 2019
Using extremes to help teams
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!
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.
Friday, 16 November 2018
Technical Debts and Loans
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....
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.
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".
Thursday, 23 August 2018
Lessons from my favourite angle grinder
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.
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.
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 |
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.
Tuesday, 7 August 2018
Vote with your fists
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.
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.
Monday, 16 July 2018
But.... Where do I start?
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.
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.
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.
Wednesday, 27 June 2018
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?
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?
Subscribe to:
Posts (Atom)