The journey
I work in a software organisation that uses Scrum to lead our development teams. Outside the development team, the business unit is structured in functional silos e.g. marketing, design etc. With the success, we had with using Scrum we believed by adopting Agile principles in other areas of the business we could change the way we work for the better.
At the time of writing this post, I have been running an Agile squad for a few months, and these are some of the learnings I have had.
The most important things I learnt
If I were asked what are the top two most important things I have learnt, they would be:
- The team – Focus on building a team so they can work in harmony
- Test, measure & adapt – don’t assume it will be successful. Find a quick and easy to test your ideas.
The other important thing I learnt the mission of the squad has should be:
- Easy to understand
- Easy to measure
- Something possible but impossible to complete
The principles we started with
- Change takes time so start small
- The squad members have responsibilities outside the squad, so do not overburden the team
- Being a member of the squad is entirely voluntary so build an amazing team to attract and retain members
Where we started
To build the squad, we needed people to cover every major business function (UX, user research, design, development and marketing) and some particular requirements for our business model. This way the team could act independently and deliver.
We also had soft skills that we felt were essential for the team (happy to learn through iteration, able to accept change and able to work effectively in a team).
It was important to get the business leader’s buy-in as members of the squad would come from their team. Once we knew what we wanted, we spoke to the team leaders and explained what we were looking for. They then spoke to their teams looking trying to match the experience of their teams, the availability of individual members and their desire to work in an Agile squad.
The interviewing process
Once we had a list of possible candidates it was time to speak to them. It was important to understand:
- What are their expectations?
- What skills do they bring to the team?
- Are they a good match for the team e.g. do they welcome change, can they work under an Agile framework and are they interested in the projects we will work on?
- How much time can they devote to the project?
What I learnt from this experience:
- Being excited does not necessarily translate to commitment to the squad. Some of the more reserved people have a deep passion for their work.
- Agile is buzz word so it is important to clarify what it is meant by it
- Clarify the level of participation they are comfortable with. Do they want to lead? Are they are interested in trying things outside their core skill set? Do they have any major upcoming projects coming up?
Kick-off meeting
Once we have the team it is important to have a kick-off meeting. The objective was twofold:
- Let everyone get to know each other
- Outline how the squad will work
What our kick-off meeting contained:
- Objectives – Explain the mission of the squad and how it plays into the vision of the business.
- Some sort of icebreaker activity – to create a space where people can open up
- Metrics – how will we measure success and failure
- Failing fast – ideas of MVPs
- First steps – what are the first round of projects we will work on
What I learnt from the experience
- Build trust first
- Outlining initial projects helped the team adjust to working in a squad
- There are many smart people in the room, listen attentively
Having squad meetings
What I learnt from having squad meetings:
- Regular squad meetups are instrumental in improving communication and collaboration
- Ask for feedback
- Not everyone will participate in a meeting. They may prefer to share, comment or feedback after the meeting.
- Having meetings optional except the kick-off meeting respects the squad member’s time. If certain members of the squad need to attend a meeting, then it needs to be explained why we would like them to attend.
- Publish meeting notes after the meetings to act as a reminder of the outcome of the meeting and for those who did not attend.
Sharing is power – communication and virtual whiteboards
People learn differently, they understand things differently, some are auditory, some are visual, and some are tactile learners. By sharing information openly, we achieved:
- Sharing early and often helps save time in the long run.
- If it is documented, it is easy to reference in the future. Especially when onboarding new members.
- Sharing information creates a culture for others to share as well.
- Helps remove follow-the-leader mindset and puts a value on the contributions of all members of the squad
The ego and the need to be right
Moving from a top-down approach where the highest paid opinion counts more moving to an Agile framework can be a jarring experience. The leader becomes a servant leader rather than the centre of the team. A meeting or a project can easily be derailed when a difference of opinion arises. And the only way to resolve this is through discussion and testing.
The take-home message from this experience it can be a very humbling experience. Success in Agile is about swallowing your pride and accepting that evidence/testing is more important than your opinion.
A shared brief
In a business where teams are organised by function, it is typical for the business owner to produce a brief for a project. This brief will then be used by other teams to deliver on that project. In the Agile squad model, the cross-functional team meet to discuss so everyone can voice their concerns or how to optimise before it goes into production.
What I learnt from this experience
- Encourage critiquing of ideas as everyone has a perspective
- Meetings can easily get sidetracked. It is important to manage the discussion to be on point.
- Use virtual whiteboards to brainstorm and track conclusions
- Some team members will need to be encouraged to speak
- Ask the question how do we test?
- End the meeting with action items
- Produce a summary write-up after the meeting and share it with the team
Prioritisation and Impact
One of the first exercises we ran was to rank a list of projects by impact and ease of implementation. For impact, we look at estimating revenue generated and ease of implementation we used t-shirt size to measure the level of complexity. These were then sorted by now, next and future which gave us the pipeline.
What I learnt from this exercise:
- Estimating revenue is difficult, but expert help was a lifesaver
- Using t-shirt sizes simplified the comparison between projects
- Using now, next and future not only gave us a pipeline of activities but helped unify the team under a roadmap
First project – the first win
I believe it is important to take baby steps as the team comes together. Our first project was simple to implement and likely to be successful. This gave us an early win and time to come together as a team.
MVP (minimum viable product)
An MVP is a concept from Lean Start-up. A proof of concept is built and tested with the results of the test determining what action the squad takes.
What I learnt from this experience
- MVPs do save time and effort in the long run but in the short run, they can add more work for the squad.
- A successful MVP is not a complete product. There is usually duct tape holding it together.
Running a retrospective
The developers run a retrospective at the end of every two-week Sprint. In our Agile squad, we don’t have Sprints, but we still use retrospectives. The purpose of the retrospective is to take stock of what has been achieved, the good, and the bad. This gives us the ability to improve.
Everyone answers three questions
- What should we continue to do?
- What should we start doing?
- What should we stop doing?
Once everyone has spoken, we then get a vote on the top 3 areas of improvement.
What we learnt from this experience
- Look for themes in the feedback
- The value of the retrospective is to act
- Post retrospective report back on improvements made
Dealing with priorities and overload
As the squad member had other priorities and other projects it is easy to pile on the work without understanding the impact it has. In my experience, it is better to set a target deadline that is an unrealistic fanciful deadline that looks great on a Gantt chart. More importantly, regular check-ins can help to maintain, build or slow down the momentum.
If a key person cannot deliver:
- Do they need help to prioritise?
- Can we assign the work to someone else?
- Should we focus the team on the next top priorities while we wait for them to become available?
Definition of done
To end I wanted to mention the importance of the definition of done. In Scrum, the definition of done is an artefact. The Scrum guide states:
The Definition of Done creates transparency by providing everyone with a shared understanding of what work was completed as part of the Increment. If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.
In our squad, as we come from different specialties what we see as done can be very different from each other. This is something we are working on.
Images taken from Pixabay
