In my last post, I wrote about why we decided to scale agile, the framework we have chosen and how we chose a small area of the business to test our ideas on.
In this post I will summarise the first two week sprint using LeSS (Large Scale Scrum). The overall summary is that after a bit of a cautious start we found our feet and can see the potential benefits of LeSS – but it is still too early to tell.
Kick off workshop
We had a full day workshop with all the development teams who were part of the new product group. This was important for the team’s common knowledge i.e. the teams knew what LeSS was about and they also knew that everyone else in the team knew it.
Structure and process
First we described the structure and process of LeSS. This was an introduction to the “rules”, concepts, processes and approach. They key point was that teams are self-managing and have autonomy to reach the outcomes that are set with the product owner.
Types of debt and perfection vision
We discussed the types of debt and how we would address each one:
- Technical debt – we need to constantly refactor within each sprint
- Motivational debt – work at a sustainable pace
- Organisation capability debt – use of hiring, training and multi-skill to ensure the right skills
We also discussed that the perfection vision was to have a potentially shippable product increment that could go live that has no debt.
Capabilities and forming new teams
In small groups we listed the capabilities needed in each team e.g. front end dev, design, UX etc. Collectively we then compiled a complete list based on everyone’s views.
The important distinction in LeSS is that each person on the team is a team member who has one or many capabilities. There is no concept of single specialist job titles.
Next came the the interesting step, we asked everyone to self-organise into development teams. This took about 15 minutes and we then tested the teams to see if they all had the required capabilities. Based on this feedback the teams decided to switch around a couple of times in order to get more evenly balanced.
Finally we validated the newly formed teams by reading out some real user stories from an old backlog to check if they could complete the work. Once this was complete then the teams went away to decide on team names.
Sprint 0
After the kick off workshop we had not set the expectations with the teams that we would spend two days in sprint o getting ready. We should have explained this in more detail and set clearer expectations – as a results people were disappointed that they could not get straight back to work.
Backlog refinement
There was a lot of work to get the backlog in shape, refining and prioritising work items. This involved most of the team and we used the existing backlogs as the starting point.
The teams found this process frustrating as they had not all been involved in backlog refinement before and we had not set the expectation that they were all required to contribute.
Changing structure
During this time the new teams also started getting used to the new LeSS structure and concepts. There were a lot of questions as people got used to the idea – but the general consensus was that it was not too different to one team scrum. An interesting side effect of changing the structure of the teams was that by association the culture of the teams also changed.
Team agreements and artefacts
The teams then started developing their team spaces and artefacts, setting up agreements around meeting timings, working patterns and how they would run their daily planning etc. The teams also collectively came to an agreement on the definition of ready and definition of done.
Changing daily stand-up to daily planning
This change was to move the focus from what each team member individually had done to a focus on throughput of activities. It changed the dynamic to prioritising throughput over busyness. The daily planning was now not about individual pieces of work for individual people – it was what the team needed to do to progress tickets.
The lessons learned from sprint 0 was that we had too refining the backlog took too long so we should have done more backlog refinement before starting the experiment. We should have also have set clearer expectations for the team so they understood what their involvement was.
New sprint cadence
LeSS brought a slightly different cadence of meetings and ceremonies. We decided to keep to two week sprints starting on a Wednesday and ending on a Tuesday as all the stakeholders were used to this schedule and already had many of the meetings in their diaries.
In LeSS all the development teams in the product group have aligned sprint cadence:
Sprint planning 1 (SP1)
When: On day 1 of sprint
Attended by:Product owner, all development teams, agile coaches, business stakeholders
In this meeting the product owner outlines the highest priority items from the backlog to the teams and the teams then decide which items they are each going to work on. These items should not be new to the teams as they have been previously reviewed and discussed at product backlog reviews. I will go into much more detail about this in my next post.
Sprint planning 2 (SP2)
When: On day 1 of sprint – directly after SP1
Attended by: Development teams
SP2 is similar to one-team Scrum where the team team creates their plan for getting the items to ‘done.’ The team’s individual backlog from the previous sprint is erased and the new work items they have taken are put into a new sprint backlog.
Product backlog refinement (PBRs)
When: Twice weekly on Friday and Tuesday
Attended by: Product owner, all development teams, agile coaches, business SMEs
This is a forum for items further down the backlog to be discussed, clarified and shaped so that they could be ready in the future to be taken into a sprint. It is essential that business SMEs attend this forum to provide context for the work items.
Daily planning
When: Daily
Attended by: Development team and agile coach
This was not a new meeting in the team – however we did align the planning across the teams in the product group so they were at similar times. We slightly staggered daily planning in case some people needed to attend both team meetings e.g. agile coach.
Communities of practice (CoP)
When: Weekly on Thursday
Attended by: Domain experts and anyone from the product group who is interested
We decided to start with a CoP for architecture (LeSS mandates this) and UX/ user research. These groups are open forums for anyone who is interested in the subject not just for people who are experts. The CoP is lead by an elected expert for a short period of time and it is up to the group how this session is run. I attended the architecture CoP purely because I have an interest and I found it to be fascinating and educational. In the session we discussed and critiqued the architectural design for disaggregating one of the legacy systems and all of the challenges that this might entail.
Sprint review
When: On last day of sprint
Attended by: Product owner, all development teams, agile coaches, business stakeholders
This meeting is for all the teams and stakeholders to inspect and adapt the product. The completed items from the sprint are demoed and any ideas, changes and direction are discussed.
Team retrospective
When: On last day of sprint – after product review
Attended by: Development team and agile coach
An opportunity for the individual teams to inspect and adapt the process. This is the same as one team scrum.
Overall we learned that we should have done more preparation for some of the ceremonies. Especially sprint review and sprint planning 1.
Support and guidance
We found that even after just one sprint using the LeSS framework we were already getting comfortable with the process and cadence. Obviously the first time we had sprint planning or product reviews there was obviously a learning curve. There is lots of room for improvement but overall it was not as much of a change as we had expected.
Therefore we found that support from LeSS experts were needed most around ceremonies and the day to day running was much easier.
Agreeing common language
We quickly found that we needed to have a common language with the teams. This is what we decided on:
- Development teams (feature team) – single team of between 5-8 people
- Product group – all the development teams working on single backlog
- Agile coach to the product group – coaching the team, product owner and stakeholders
- Product backlog – prioritised single list of all work
- Sprint backlog – used only for one sprint
Re-thinking team roles and capabilities
One of the big shifts that we had to make was that each team is made up of between 5-8 team members. Each team member has a set of capabilities and not a job title. This is a subtle but important difference – individuals are not longer their job title e.g. a developer, they are a person with a set of skills e.g. back-end development and front-end development. The role over time is for people to multi skill to increase their repertoire of capabilities – in order to cope with spikes in demand for a particular skill and reduce bottlenecks. We quickly realised that there needed to be some slack in the workload to accommodate this which we plan to address in sprint 2.
We also identified the need for agile coaches in the product group. We chose two existing delivery managers and started helping them move more towards agile coaching practices. We identified that the agile coaches should have the following qualities; comfortable with conflict (candour), good behaviour observation skills and nudge questioning. The agile coaches are not there to manage or run the teams – they are there to facilitate the continuous improvement of the product group so they can deliver value to the users.
Sprint 1 – product retrospective
This is the product owner’s meeting but the team decided how they wanted the meeting to flow and how they would demo their work. We invited all the various stakeholders but explained that different parts of the meeting would be relevant to different stakeholder so they were welcome to drop in for the bits they were interested in and then leave.
The each team demoed their work to stakeholders in turn. This radical transparency sparked some debate as to whether we had worked on the most valuable backlog items. This was great feedback and the product owner took that feedback on board.
The product retrospective was a little chaotic and we learned that we need to do more prep and planning before the meeting and understand the outcomes for the review.
Experiments for the next sprint
For a first sprint with LeSS the teams did an incredible job but we have constant aspirations to get better and improve. Therefore we are going to run a few experiments in the next sprint:
1. Capturing emergency work
One of the key points from the individual team retrospectives was about how to highlight surface bugs or changes that need to be addressed mid-sprint. Therefore we are going to have a separate area of the backlog which is a holding area to place new items that then can be addressed and triaged as part of the next product backlog review.
2. Prioritising physical boards over Trello
This creates a transparent way of working and acts as a focal point for daily planning. It is also a good way to visibly show flow through the system. We want to get back to basics and simplicity. Some issues with a physical board is that team members that work remotely find it harder to contribute to the board and there are issues about showing acceptance criteria clearly.
3. Using estimated effort over timesheets
Product teams are often required to fill in time sheets in order to track the time spent on various products so the costs can be assigned and accounted for. If you enforce hour-by-hour tracking of time it slows down development and causes endless interruptions. Therefore companies ask teams to fill timesheets out at the end of the week – with little chance of recording this correctly. However this practice is accepted because we have a precise recording – regardless that it is completely wrong. Therefore we are going to use assertion that “estimated effort” is highly correlated with actual work time, our experiment will be to use estimation on work items as the basis for recorded time. Over time we will drive toward high correlation between estimation points and actual time.
On a personal note I was delighted with how the teams approached this change with energy and curiosity. Of course there are elements we want to improve and areas that caused initial frustration – but overall we took most of it in our stride and continued delivering value to users.
This post is part of a multi post series: