Kicking off the first squad

When our squad started the engagement with our client, it was August 2016.

We had to deliver an MVP in 16 weeks. This included client interviews, story mapping with UX designs, setup of the delivery pipeline for the squad, Continuous Integration, Continuous Delivery, deployments, identifying and implementing communication channels such as Slack, with integrations into the delivery pipeline.

The first squad is always the hardest.

Overtime is required, there are many internal walls that need to be broken down, and internal business processes require adjustment for Agile delivery. Business will require quick feedback and they want to see value within the first 2 sprints… the pressure was on.

We knew this going in though. We also knew that for any squad to be successful, the market research and discovery phase in sprint zero is vitally important.

The importance of sprint 0

The discovery phase defines the MVP and the feature pipeline which sets the roadmap for the squad. What we built had to be tangible, achievable, disruptive and attractive to business.

The discovery phase (Sprint 0) sets the tone for the team and is usually the hardest to show value. Most of the work done in sprint 0 doesn’t have much of a tangible value to it, so we knew it would be important to show the experience. Make it visible.

An outcome of sprint 0 is to have the work aligned for the first 2 sprints. All the stories should be groomed, any designs should be done by the UX designer, so that the squad can kick-off the development with ease. It sets the standard for working in an Agile manner.

While the discovery phase didn’t need the full squad, we made sure we had a representative from each of the core skillsets to cover all possible bases from the get-go. These included:

• Business (the Product Owner)

• Analysts (to assist with the design, user story grooming, client interviews and environment analysis)

• UX Designer (to analyze the customer journey and experience)

• Engineers (to kick-off with the technical integrations, setting up of the CI/CD and delivery pipeline).

Getting this team structure right upfront was vitally important to the developers and the success of the product. You can even throw in a small teambuilding exercise to ensure everyone knows each other and, to build culture.

Once the discovery phase was complete, we’d defined the MVP, completed the User Story grooming, and laid out the first 2 to 3 sprints, we were ready to get the rest of the team to join in. And they hit the ground running.

Adjusting

The 2nd squad kicked off after the first 16-week phase. We used the learning from the first squad to kick-start the 2nd team and drive the delivery from the start. The walls broken down by squad 1, allowed for an easier kick-off and start for the 2nd squad.

Even after the 2nd squad had kicked off, we realized the biggest challenge would be to get the client business to adjust to an Agile methodology: to be more hands on and thoroughly invested in the processes, not just a by-stander overseeing the agile transformation. They needed to join the transformation and live and breathe agile it on a daily basis.

To help client adjust would mean a very hands-on approach from our side.

We invited the client to spend time within our dev squads, understanding why Agile was so important for building services and products in today’s market place. The hierarchy of the person is irrelevant. The important thing is for them to understand why it worked.

Once we had buy-in and understanding, we were able to grow to six squads all compiled by Agile Coaches, Product Owners, Tech Leads, Software Engineers, Analysts, Data Scientists, UX Designers, UI designers, and Testers.

The stakes?

Of course, there were risks. Any integration into legacy systems or existing applications that still run in waterfall delivery could affect the efficiency and effectiveness of the squad.

But we were prepared for this. So, our approach was to tackle these dependencies upfront.

It’s well understood that the first squad is tough. There are development and integration challenges, but also buy-in, and very often an organizational mind shift required to adopt Agile methodologies.

One solution we worked with was to have one or two software engineers from other integration teams join the squad. This helped with knowledge sharing, IP, and buy-in where integrations and changes to existing services are needed. It also removed the old approach of ‘throwing work over the fence’ and waiting for feedback! 'Throwing work over the fence’ should be long gone, and banned from any custom development. The software vendor must build the software with the client, getting continuous feedback, and living the journey together. That's why Entelect had such great success, because we formed a business partnership instead of the client/supplier relationship.

Things worth sharing

Being people-focused; setting up career paths and performance appraisals that allow the engineers to grow and have short- or long-term targets for themselves is beneficial to the entire squad. Corporate reviews are just too restrictive, each member of the team needs their own defined path for growth.

Monthly check-ins between the scrum master and each person on the squad creates regular health checks and opportunities for mentoring.

It’s also vital for squads to have the buy-in from an Executive or Director to open doors and remove any blockers that may be there. Organizational adjustment to Agile is a big deal and must be a team effort.

Give the squad the freedom to be bold, to grow, and take chances, knowing that they will be accountable for the delivery as a squad. Make sure they see and get the support from business.

The next ‘first squad’?

It’ll be tough, they always are. But we’ll use everything we’ve learnt to refine, adapt, and take our client into an exciting new space for Agile development.