Agile teams and processes, ingredients for success

By

Image Learn how to change direction quickly!

As an engineer my focus for most of my career has been building scalable, performant, well architectured and secure software. While those are definitely required ingredients for your product to succeed I’ve started being more and more aware those are just part of the whole recipe.

Eighteen months ago I became fascinated by lean product development and Design thinking so I decided to get out of my comfort zone and start a new career as a Product Lead. I started that journey working on a project for a global company. The product today has a tremendous impact on its users and it’s one of the main enablers of our client business strategy. The development has recently paused and I’ve found myself reflecting on the journey and what made it successful. While many different factors contributed to the success of the product I’d like to share with you my experience with processes and team dynamics.

Before we get to the nitty gritty it’s important to note that Potato is a product development agency and we work with brands and businesses across the world, from startups to big corporations. We don’t generally own the products we develop and it’s therefore a priority for us to collaborate with our clients to find the right approach and processes to succeed together.

Since processes, expectations and governance can vary from company to company this can sometimes be something of a challenge. Fortunately, at Potato, we like a challenge.

In this article I’ll look both at how we changed the relationship and approach with our client and how we’ve reshaped our processes and ways of working to equip the team for success in any environment.

Reshaping agency/client relationship

When I joined the project our client was expecting a pretty rigid waterfall approach. They felt they could just hand over a product specification and expect the team to deliver it. Collaboration between the team, stakeholders and product owner was expected to be minimal.

While we knew from the beginning this wasn’t an ideal set up, we were aware we couldn’t turn processes around from day one.

We had to prove our approach would work better and allow us to deliver faster and higher quality results for our client.

I won’t lie, the beginning of the project was messy and, as we were expecting, the big gap separating the development team and product owner proved to seriously impact the progress straight away. It was hard to align on goals and purpose, client and agency struggled to understand the direction the product had to take and that was preventing us from moving fast and building the right solutions. At the same time, the client was having difficulty creating focus around the right problems to solve, many voices from different departments involved in the development were being lost and it was hard for the product owner to understand how the different pieces of the puzzle would fit together.

This gave us the opportunity to suggest different methodologies and prove how effective we could be working as an agile team, where the product owner and development team join forces to innovate and deliver together.

We started using Scrum and leveraged sprint planning sessions with the client to define actionable goals to create focus around the problems the product had to solve. We also began collaborating with the product owner and senior stakeholders to identify how the product could deliver against business goals and user needs/problems to create an effective product roadmap. This really helped the team to keep the right focus, understand the challenges ahead and finally be able to effectively build the right product.

We started working as one team, there was no separation between client and agency and that proved to be powerful. It was now clear we were all pushing in the same direction and everyone was exposed to the right context. The team had visibility on the strategic goals and product outcomes while the product owner could keep a closer eye on progress and understand the impact of his choices. The team could design and build features understanding what outcomes were required from them and the product owner could trust the team to take those decisions.

The impact of these changes was great but I wouldn't be fully honest with you saying it was an easy and sharp transition. Finding the right way to work with our client and improving team processes and approach took time and effort. But I can say today it was a really rewarding experience that was worth every minute. The quality and speed of work dramatically improved as did the team health and client satisfaction.

Find the process that works for your team

Image Never be afraid to experiment. Embrace change.

The first lesson we had to learn in this journey is that there’s no one solution to fit them all. I learned that first hand, when I started reshaping the processes. We’ve worked with the agile coach in our team to define the perfect process, to have well-defined roles and responsibilities, to have our ceremonies be consistent and effective, to have our Gitlab board structured in the best way possible.

I was expecting everything to be perfect from day one, but that’s just not the reality, it really isn’t. Every product, every team and every organisation is different and there’s no perfect way to run your project. The key is to work with your team to find the ideal approach, the one that works for you.

That’s what enabled us to improve and become more effective and organised through time while always being conscious that perfection is not to be reached. Rather strived for and the key being continuously adapting to change.

But how do you do that? I can tell you what worked for us and hope it’s a good source of inspiration.

Don’t strive for something perfect from day one, be experimental, try, learn, iterate and adapt your processes to your needs. Doing a retrospective every sprint is a good way to do that: learn from your mistakes, take what worked well and iterate.

Make sure your team understands the process and is involved in shaping it. The words Agile and Scrum are widely misunderstood and/or misused across the industry. On top of that differences in Scrum approaches and process are intrinsic in its nature. That’s why it’s crucial everyone understands the concepts, owns the processes and believes in them. It wasn’t the case for us and that caused some issues at the beginning of the project.

On top of that, at Potato we work in cross functional and autonomous teams and, while that’s key to delivering good digital products, it also introduces a few challenges.

The team needs to work as a cohesive unit while, at the same time, different members need to apply different lenses to the product. As a Product Lead you likely want to focus on the long term strategic view of the product, think about the big themes and their impact on users and business. As a Product Designer you need a good setup to run Product Discovery, run User and Stakeholder Interviews, carry on discovery work and effectively organise product insights. As a UI designer and Engineer you need a good framework and processes to effectively collaborate on User Stories. This applies to all different roles of your multi-functional team.

That’s why it’s fundamental everyone is actively involved in defining processes and shaping the framework and methodologies to run itself.

Empower your team

If your engineers are just writing code and your designers creating UI components you’re leveraging 25% of the capabilities of your team.

When it comes to defining and designing solutions, it’s still pretty common practice to have product managers or even senior stakeholders and executives decide what features go into the roadmap and how they are scoped out. The team's only focus is to implement what is funnelled down.

While changing such a structural behavior is incredibly hard, we did work closely with our client to break some of those patterns and prove the benefits of having an empowered team.

While it's the product manager’s (and management) responsibility to provide the product vision, lead the long term strategy, create focus and refine the value proposition, it’s the team responsibility to solve those big challenges. They own the actual expertise, they understand the technical constraints and they better understand the users.

Be reassured that this way your team will thrive: they’ll be more inspired and driven, they will understand if/when some trade offs are required (instead of being frustrated by another “silly” request from management).

Having your engineers, designers, uxers really understand the product and the problems it is trying to solve has been one of the most important means to success.

What is the importance of a steering meeting and why do you need one?

By

Image In my experience of leading agency delivery teams, I have regularly been invited into meetings to meet senior client stakeholders as a one-off, or intro, but noticed this engagement is rarely followed up with a more regular meeting. These people are often the most important decision makers in the project, and only get to understand second hand information or review deliverables at the end, when it’s too late to provide further input without impacting budgets.

As part of a professional services software delivery and product build agency, client engagement and satisfaction is at the forefront of what we do to retain clients, grow market reputation and build trust.

Our delivery teams are focused on delivering the best possible value and outcomes to clients as efficiently as possible and our Agile centric approach focuses around cross discipline, self organised teams that can make this happen.

Our discovery processes allow us to meet and interview key members from the client team, understand their needs and expectations, and identify who our main point of contact and interaction will be and how best to work with them.

But in doing this, how often do the teams get to engage with the senior stakeholders client side post discovery? Is the Product / Project sponsor’s voice regularly heard within the team, or do we just focus on what is shared from our key stakeholder (usually the Product Owner)?

To improve our commitment to client and teams, we recommend a steering committee.

What is a steering committee?

The Steering Committee will provide oversight of progress, support and where needed, guidance. It’s an opportunity to share thoughts, plans and upcoming risks at a senior level, without impacting the core focus or delivery of the project.

Members of the committee from our side don’t usually work on the project themselves, although there may be some representation (Delivery Lead / Product Lead / Tech Lead). Think of it as an over-arching retrospective, looking at how things have worked well, or where we could look to adjust to make improvements.

The main goal is to ensure the satisfaction of the end user, and outcomes of the delivery (and project) are a success and all parties remain informed.

Who should join a steering meeting?

Depending on the size of the project and client, and the team our side, the steering committee team will also vary. Examples of those involved include:

Image

*These roles will vary based on size of the agency, size of the account, and the nature of the work being delivered

Cadence, agenda and outcomes

The regularity of a steering meeting depends on several things which I will expand on below

  • Need
  • Size of engagement
  • Number of stakeholders

We find that when an engagement spreads over several months, the use of a steering committee as an oversight and escalation point is useful to ensure there’s alignment on both sides higher up from the delivery team itself.

The agenda generally revolves around 4 key areas:

  • Finances and budgets
  • Progress and performance
  • Risks and issues
  • Longer term plan

These agenda points or guides relate specifically to the people involved from both sides of the project, for example, if there are no representatives for strategy and longer term roadmap in the meeting (see the section on Who should join a steering meeting) then there's no point in going into vast depths about this agenda point. Just a high level overview could be enough to provide clarity and inform all parties of the position and status.

It’s important to note that the meeting is not a place to solve problems but more a discussion forum to outline progress, highlight issues and take away actions. The ongoing cadence can be used to follow up on the actions taken and offer solutions or adjustments.

A great example of this was demonstrated when we onboarded a new client from another digital agency. As part of the onboarding process we recommended regular (monthly) steering meetings. The client was initially surprised, “why do we need those, we didn’t used to have them?” But after the third meeting, the feedback was glowing - “These meetings are really helpful, it’s exactly what was missing in our previous engagement”. We helped the senior stakeholders to understand what was going on, so that they had time to think about and shape things on their side before the next meeting, without being overly involved in the day to day. The final result was a much more engaged client, a more transparent working throughout the team, and team that scaled up to meet a growing business demand much quicker than expected.

How will the Steering Meeting help?

By regularly engaging with senior members of the steering committee, early warnings, possible risks, and adjusted solutions can be discussed openly ahead of them actually appearing.

Budget discussions can be held outside of the delivery team, removing distraction from the day-to-day.

Escalations can be kept to a minimum, regular touchpoint rather than ad-hoc and unplanned. And progress updates and forecast can be shared directly with members of the client team without expectation that the message is passed on.

A steering meeting should bring closer client relationships and offer new, more insightful approaches to collaborative working.