Learnings from Leading: Tweaking Your Delivery Process

This article is a reflection on some learnings while leading delivery in teams.

I have written about some takeaways from leading teams and the transition to Lead, so this is a continuation of that thread.

As part of leading, you will gain different responsibilities, one of which is the responsibility over delivery.

When I think back to my time as an IC, I had varying experiences with being responsible for delivery. With some projects I was asked to technically scope the work required and provide estimates which I felt empowering. With other projects, I felt disempowered because I was not a part of that estimation and scoping exercise. I felt like I understood why behind a project, but may not have contributed to owning how and when.

So I can empathise with developers if they feel like this and hopefully this post will provide some insights and techniques for everyone to feel empowered and understand how to meet their OKRs and delivery milestones.

What the delivery process might look like

I remember as a graduate, the software development process followed the Waterfall methodology. Teams would spend months gathering requirements and getting sign off, followed by analysis and design, then build, system testing, systems integration testing, and UAT. Then the product would be deployed in production and moved into BAU.

Waterfall Software Development Lifecycle

As I progressed in my career, Scrum and other Agile methodologies were becoming in the industry norm. And other times, there was an amalgamation of Waterfall and Agile, affectionately called WAgile.

Other methodologies also emerged, like Dual Track Agile, where discovery and learning from previous sprints would feed into upcoming sprints.

What I’ll Cover

I’m going to cover some learnings I’ve had for processes within my control, when leading scrum teams on the delivery phase.

So let’s say the process resembles the following:

A Typical Flow

1. Here the feature has been researched by a product owner/manager and requires additional validation and research from UX/Design and Tech Lead.
2. The UX Designer will validate ideas, create prototypes and test with users, before creating high fidelity designs for the team. Sometimes, testing may get missed.
3. The Tech Lead will analyse the proposed wireframes/prototype/high fidelity design and undertake some technical analysis (perhaps with another team member or on their own) to identify changes required, risks, create a technical design and identify dependencies.
4. Once Product, Design and Tech are ready, the feature corresponds to an Epic and are broken into stories and tasks for the team to start building. Rough milestones are scoped for the feature.
5. The team then start estimating a sprint’s worth of work and start building the feature.

From real experience, these were some problems that arose from this approach

• The team lose the bigger picture of the feature
• The team do not have a clear understanding of the goals and the why behind a feature.
• The dependencies of tasks were not understood well
• Work may not be scoped well
• Friction between design and developers, for example developers may feel like they are being forced to build components that are difficult to build and impact delivery timeframes
• The team were limited in growing their skills, for example not given the opportunity to stretch and undertake technical analysis
• User testing may not occur at the right time and the team may need to iterate on components they’ve already built.
• Teams did not come up with their own Objectives and Key Results to measure the success of their work.

Let’s Make Some Adjustments

Here is a version of the above process with some adjustments to alleviate the problems on alignment, engagement and ownership.

Adjustment 1: Walkthrough

At this step, the team is given a walkthrough of prototypes and/or designs, so the team are given a chance to ask questions, highlight issues and possibly continue with co-designing.

Why is this important?

• Front-loading risk — The team get a chance to highlight risks earlier
• The team get to collaborate and validate earlier with the designer/product
• Feasibility of work can be identified earlier (e.g. creation of new endpoints or components in the Design System etc)
• The team gain context into the problem space and understanding why

Adjustment 2: Backlog Grooming

Normally the Product Owner and Tech Lead will groom the backlog together so the highest priority items are ready for the next sprint.

Now this may not work for everyone, but these were some adjustments that seemed to work with a particular team:

• Optional invitation for the whole squad to attend backlog grooming. This will attract developers who are “planners” and those who want to gain context on upcoming work. They also feel empowered and a part of the process of prioritising work, having a holistic overview and identifying risks.
• Send a summary of the groomed tasks and stories ahead of sprint planning, providing enough time for the squad to digest tickets and bringing questions and comments to sprint planning.

Adjustment 3: Pre-Scoping a Feature

Together with product, identify milestones for the feature and bucket items into must-haves and nice-to-haves.

Having a rough idea on these items will drive teams to think about quality MVPs to iterate on for the feature.

Adjustment 4: Technical Kick-Off

It’s important to implement technical planning as a part of software development and this also provides developers the opportunity to grow their skills.

Good leaders will provide a space and forum, and lead their teams in developing these skills.

Some techniques on how to do this:

• Send relevant information to the squad so they have time to digest information
• Ask the team for input on — risks, blockers, dependencies and identify opportunities for spikes
• Have a technical scope/architecture meeting — developers may not like meetings, it’s important to articulate that sometimes meetings may be important to work on problems together. If the agenda is clear beforehand and information is sent to the squad ahead of time, this will drive better outcomes.
• During a technical scope/architecture meeting — lead with identifying the main milestones. Then engage with the team on identifying risks, ideas, etc on each of these milestones. Identify which items can be spikes into sprints an owners for these spikes.
• Ask questions to drive holistic thinking, such as: which users can/cannot have permission to API calls and views? Is there an impact of changing data to other parts of the platform? What are the scenarios we need to cover? What complicated setup do we need? What tasks are dependent on others? Etc

Adjustment 5: Empower Developers to Own Tickets

I tend to write detailed tickets, which can be disempowering to some developers and also doesn’t allow developers to stretch beyond the scope of a ticket.

So here were some tweaks that were made:

• Defined high level acceptance criteria in the ticket. Then noted questions that needed answering in the ticket.
• Create a story to capture user acceptance criteria and empty task tickets. This worked well actually, during sprint planning the team talked about what the task may entail, identified possible risks and impacts, and we captured these points into the ticket (i.e. we walked out of sprint planning with notes and questions in the ticket).

What was the difference?

• The team were empowered to think more holistically about a feature
• The team were empowered to own a ticket and research further if needed
• The team helped each other identify risks
• There was more engagement in sprint planning.
• Decisions and discussion points were still captured onto a ticket during sprint planning.

Adjustment 6: More spikes earlier

Spikes happen during backlog grooming or sprint planning, but wouldn’t this be great to identify before even starting a feature what spikes are needed?

For example, while building a particular feature, the team identified that a calendar was not a component in the Design System and may need some research to identify which React component to use. A spike was created with the goal of identifying which component could be used.

The approach

• A team member used a separate repository to quickly prototype a few options of the calendar, with mocked data (note: there was a previous session to define the API interface between frontend and backend)
• The separate repository allowed the developer to move quickly. They were not hindered by boilerplate from the main repository and build pipelines, which was not needed for this prototype.

The outcome

• Lighter way to test a technical implementation
• Eliminating risk upfront rather than during implementation
• The feature was delivered in 2–3 sprints! (in the past features took months)

Adjustment 7: Define Interface Contract Upfront

Defining common dependencies upfront, for instance defining the API contract actually enables the team to have

• A common understanding and technical design upfront and
• Frontend and backend developers could work in parallel once an API with stubbed responses was created.

Adjustment 8: Review Environments

During the project, we only had one testing environment (staging) and feature flags to test the work.

Around this time, we were also testing and reviewing work on Pull Requests by pulling the branch and running the branch locally. This was time consuming and cumbersome.

So some work was done to create test environments using Docker, Kubernetes and Helm in order to test work.

Outcomes

• Branches were easier to test and validate. Our product owner found these useful to test and validate rather than waiting until work was merged.
• Code reviews were used as a mechanism to review code and test each other’s work
• We had more confidence on what we were building

Adjustment 9: Regular check Ins

This was a technique I learnt from a Product Manager a few years ago, to gage how the team was doing, re-assess scope and get the team aligned as a team on their progress.

This also aids conversations with stakeholders in providing transparency on the progress of work, challenges and blockers and any adjustments to the timeframe of delivery.

This involved a whiteboard and a conversation with the team on the milestones of the feature and each item currently in progress.

I strongly believe in involving the whole squad in this discussion. The squad are working on the feature, they each play an important role, they each have insight to bring and alignment is paramount.

Below is a photo of what the outcome of the session had:

• Features with current progress in percentages
• Key dates we aimed to hit
• Iterations for the feature
• Dependencies and risks
• Communications with other departments
• Capacity impacts — when people were away

Adjustment 10: Team QA / Test Bash

This was a technique that I learnt a few years ago at another company.

The whole tech team gathered to perform exploratory testing of the feature and use the feature like real users to identify issues.

It was fairly straight forward:

• Allow for 30minutes for the team to test together
• Issues were captured in a document with screenshots, test data and comments
• Prioritise issues
• Follow up for clarifications on issues

Adjustment 11: Release Plan

Using feature flags and staging environments as well as a CI/CD pipeline meant that releasing requires flipping the flag on.

However it’s not always as simple as that. For example

• What order of remaining features need to be merged
• Do communications need to be sent to customers and internal stakeholders?
• Do we need to define dashboards and metrics to measure features?
• Do we need to define monitoring or observability metrics and alerts?
• Smoke test and sanity test production?

The technique:

• Gather the team around a whiteboard, brain dump and order the items for release.
• Assign owners to items on the plan.

Adjustment 12: Squad Coffee

This technique I learnt over 10 years ago, from another team’s development manager. I noticed that a team would go for a team coffee every fortnight and chat.

At the time I wondered why that was important and after a number of years, it clicked.

This act of getting coffee together was a chance to align with each other, raise awareness of each other’s work and foster an environment for collaboration.

I decided to do the same thing. Every fortnight, I allocated a fortnightly group catchup, for the purpose of information sharing. This worked to some degree.

Outcomes

• The team enjoyed the flow of information that I could share with them
• They liked the chance to connect in a relaxed environment
• We didn’t always have the session.

I was conscious that developers need blocks of time for deep thinking, so if the team felt like they wanted to skip a session, we wouldn’t have that week’s session.

My Learning:

This can be adjusted further, for example, scheduling coffee first thing before standup rather than sometime in the afternoon may have made this session more impactful.

What I did not talk about:

• OKRs
• Measuring Success
• Dual Track Agile

I have my own points of view and biases on the above, which I’ll save for another day. In short, I believe if teams can define their own OKRs, they will be more empowered, engaged and own the outcomes of a feature as a team.

I am also a big believer of Dual Track Agile and how this further empowers teams and teams can deliver the right solutions and learn earlier. It is a big cultural shift though, so that is a whole other topic!

Takeaways

I hope the post has provided some insight and tweaks to your current process and the parts of the process you can lead and make a difference in.