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 three most important things I have learnt, they would be:  

  • The team – a vital component of success is in harmony amongst the team members
  • Test, measure & adapt – Find a quick and easy to test your ideas. It is better to be wrong and learn something. Then to be right, but not know why. Businesses scale when they know why.
  • Focus on an objective that is possible to achieve but impossible to master 100%

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. Build something amazing so people want to join

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 was not dependent on another’s team’s schedule and could deliver rapidly.  

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 essential 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 trying to match the experience of their teams, the availability of individual members and their desire to work in an Agile squad to meet our requirements.  

The interviewing process 

Once we had a list of possible candidates it was time to speak to them. For us 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?
    • Do they welcome change?
    • Are they happy to work inside an Agile framework?
    • 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 individual have a deep passion for their work. 
  • Agile is a buzzword so it is important to clarify what they understand Agile is?
  • 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? Or are they prefer to work inside their comfort zone? 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 were twofold: 

  • Let everyone get to know each other 
  • Outline how the squad will work  

What our kick-off meeting looked like: 

  • Objectives – Explain the mission of the squad and how it plays into the vision of the business. 
  • An icebreaker activity – to create a space where people can open up  
  • Metrics – how will we measure success and failure 
  • Failing fast – ideas of MVP
  • 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 regular squad meetings 

As a squad we organised regular meetings so members of the team could come together to discuss

  • What are they working on?
  • Any potential roadblocks?
  • Refining what is next

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. Some may prefer to share, comment or give feedback after the meeting.
  • Have 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 they should 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 to understand what was discussed. 

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 

Transitioning from a top-down approach where the highest-paid opinion counts more and to an equal playing ground 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, so it needs to be resolved before moving forward with logic and evidence and not because I am paid more than you.   

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 and experience.  

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 becomes the source of truth and will be used by other teams to deliver on that project. In the Agile squad model, the cross-functional team meet to discuss a brief, this gives everyone the option to voice their opinion on the brief before it is finalised.  

What I learnt from this experience 

  • Encourage critiquing of ideas as everyone has a perspective
  • Meetings can easily get sidetracked. It is important to ensure the discussion is 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 and forecasting to estimate revenue.  The ideas were then sorted into now, next and future, this gave us our pipeline.  

What I learnt from this exercise: 

  • Estimating revenue is difficult, but expert help is 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 to unify the team under a roadmap 

First project – the first win 

I believe it is important to take baby steps as the team is coming 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. The results determine what action the squad can take. 

What I learnt from this experience 

  • MVPs do save time and effort in the long run but in the short run, they can create more work for the squad. 
  • A successful MVP is not a complete product. There is usually duct tape holding it together. 

Running a retrospective 

Our developers run a retrospective at the end of every two-week Sprint. In our squad, we did not 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. Thus giving 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 
  • Within a week after the retrospective report back on improvements implemented

Dealing with priorities and overload 

As the squad member had other priorities it is easy to pile on the work without understanding the impact it has on the individual team members. In my experience, it is better to set a target that is based upon the ability to deliver then an unrealistic fanciful deadline on when you think it should be done by. 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. We had to work to build a shared understanding of done. As an example when something is done, it can still go through additional rounds of iterations.

Images taken from Pixabay and Unsplash

Photo by on Unsplash

Photo by Matt Benson on Unsplash

Photo by Mark König on Unsplash


Write A Comment