Rethinking Agile 2/3: Smarter Delivery, Better Behaviors, and Real Results
Delivery is the only real reason agile teams have been created. It’s about achieving measurable outcomes and predictable results while keeping the focus on doing the right thing (and not just doing things efficiently, potentially the wrong one).
If you haven’t seen the first post from the series, I encourage you to read it first. If the context is missing, some of the things I will describe here might sound “out of the blue.”
Exploratory work and the time invested before shipping new shiny things
All teams require some exploratory work, whether before or during a project. Estimating and planning the known work is not hard. The challenge comes from the unknown and surprises we stumble upon in the process, which is the primary cause of every project’s unexpected obstacles and delays. Thinking and tinkering before committing is a good way to explore our options and remove ambiguity.
Before starting the project
Before the project starts, I always want a team (engineering, product, and design) to sit together and discuss the work that needs to be delivered, ensuring everybody is responsible for their part.
- Product — says what they want to achieve and how “done” looks. They also answer “why” we have to do it.
- Design — says how it will look and how to make it user-friendly. It often includes UX research, too.
- Engineering — decides how it will be all implemented, considering the product’s shelf-life, importance and complexity (and more) and future impact.
- The team agrees on what will be built and how we will measure the success. What needs to be delivered, what options were considered and scrapped, and 80% of what they believe are “unknowns” have been identified and assigned to exploratory work — spikes.
Spikes
These are essential tasks whose sole purpose is to answer questions nobody can answer (yet). They involve a better understanding of user behaviours, data challenges, digging into legacy systems, finding new creative solutions for technical problems, or figuring out whether something should be built or bought.
If you give a team infinite time to solve a problem, it will take them infinite time to solve it.
These spikes are time-limited, and I prefer a day or two to avoid dragging them for too long. I also like to focus them on answering one question at a time, which will inform the project requirements and potentially lead to more spike work. We are looking for suggestions on how to move forward and what else is missing. As part of this exploration, we are removing ambiguity from our projects for everyone.
That often leads to a short write-up. I strongly recommend focusing on “this is how we will do it” and quickly reviewing what options were considered, dismissed, and for what reason. The rejected paths help us understand the thinking process and the different routes we could take. It is especially crucial when a spike is focused on choosing a 3rd party tool to solve the problem as usually there are so many options, and we need to be able to compare them as this is likely a long-term commitment for the company. This approach builds a process for transparency, trust, and learning.
As a tech leader, I want to see the results and the path that leads to a particular decision, especially when it’s creating a long-term impact. When I see the proposed solution and a few options considered but dropped, it gives me amazing insight into how it was handled. It shows that somebody did a much more serious job than just coming up with an idea and presenting it. I’m also learning in the process and can challenge the outcomes on a different basis.
Pre-planning sessions
Often, teams work on a project while another thing in the pipeline is being prepared. It’s important to have pre-planning sessions for these projects, which allow the team to build understanding and set the right direction. Teams also work much more efficiently when they understand what is coming in the future.
Well-organised tech teams know when they will be working in the future and are not kept in the dark from planning to planning. That’s a topic for another product-focused article, but this is the most crucial part on future visibility
1 month ahead — with 95% confidence
2 months ahead — with 80% confidence
3 months ahead — with 60% confidence
4–6 months ahead — just informative
These pre-planning sessions, sometimes called refinement sessions, should be created only when needed. Regular meetings like that take too much time from the team and quickly become irrelevant and off-topic. They usually lack focus in the long run and bring no real benefit.
What is worth remembering is that only relevant people should be involved. Having the whole team creates noise, wastes time and allows people to pretend they care when they don’t. A rule of thumb for me is to have the lead engineer be the first point of contact for new stuff, and this person can provide high-level input and guestimates and then delegate as necessary (doesn’t mean the lead has to be always involved in everything either). And that’s when pre-planning sessions also require the magic thing rarely anybody provides — an agenda!
If you feel you don’t bring value to a meeting or a meeting has no value for you, you probably shouldn’t attend
Do guestimates for work that will hit the team, and whilst story points focus on 1-day granularity, guestimates shouldn’t be more detailed than 1 week. With longer timelines, the ambiguity grows, so following Fibonacci makes sense.
Week, 2 weeks, 3 weeks, just over a month, 2 months, over 3 months, half a year)… ish.
The delivery process, standups and stuff.
I set basic rules and allow each team to adjust within reason, assuming they take responsibility if or when they get it wrong. The approach is not rigid, and different teams and projects require different attitudes and execution.
Starting from one-week development cycles, which allow for less noise and quick response to changes, blocks (tickets) of work per design should fit into the weekly cycles and shorter planning sessions.
Monday morning planning session to determine what the team will do in the next 5 days. Which tickets they will pick up, blockers to resolve, and review what happened last week. That might also include any planning for new code releases and challenges that come with it. Such planning ideally would not go longer than an hour, although my experience usually tells me it will be 30–45 minutes max.
Monday planning happens instead of a standup.
Communicate results (plans) on public channels so people who are not involved (leadership, other teams, product owners, etc, and people who are interested but don’t attend) can see what is happening. It’s all about proactive transparency that helps to create trust.
Don’t assume that’s overcommunication and nobody cares. I love to see teams sharing stuff like that, as it gives the assurance and vibe of “they’ve got it.” This is especially important when most work is done online, not in the office.
Standups every day, 9 AM ideally, so when the day starts, they do not create distractions (I always found 11 AM standup a shitty idea). 15 minutes max! Every person gives an update to everybody (not only the team lead). There are no 1–1 conversations about issues and trying to resolve them in the meeting. Follow the circle, update each other, and if you have a particular problem to fix, leave it for the end and ask only relevant people to stay (the rest of the team should disconnect; don’t let them hang around).
Make sure everybody is treated equally, especially in the hybrid working setup. The most common complaint about meetings is that people feel left out because they join them online, nobody cares about them, and they have no voice.
People like (although “like” is probably such a bad word for it) to stay in meetings because they feel guilty if they don’t (it’s a matter of looking interested and fake caring). Do you know what breaks a lousy cycle? A team lead who stops 1–1 chat and says, “You guys sort it out at the end”, and when you are finishing standup, the lead leaves the meeting because the conversation is not relevant to him, and he will be updated about the outcomes when it is necessary.
The most important part of the process is letting the team adjust it to their needs. There are plenty of reasons why one-week cycles don’t work well. Some teams might be spread across different time zones, and standups will just have to happen later. There is no one-fit-all approach, but having a healthy, agile-focused default is a good start.
I’m against bringing on-board people like delivery managers or scrum masters into product delivery teams. These roles probably make sense only when such a team is 10+ people, but having such a big team doesn’t make sense.
Points, estimates, etc.
I wrote about this extensively in my other article. I will save myself some time and not do it again here. You can read more here…
Retros & feedback
Part of a good development process is reviewing what happened in the past. Retros are one way to collect feedback, create actions, improve, and move forward. I strongly recommend doing it once every 1.5 months. Sometimes, it might be more often, but I found little value in doing it after every dev cycle, whether weekly or biweekly.
Imagine having at least 2 hours of planning, daily standups, two refinement sessions and probably 2-hour retro, all within two weeks. That’s how you drive the team to the ground by meetings. I’ve been there, saw that, and hated it :)
A good team constantly feeds back issues and solutions, so hopefully, there are healthy conversations about challenges that make retros lighter. Waiting often dilutes the importance and urgency, so facing challenges and fixing problematic things as we face them usually brings the best results, although we need to be careful not to take away our focus from what has been agreed to deliver.
User tools for retro boards online can be very helpful, especially when a whole team is not in the office. I like using post-it notes and a board when everybody is in the same room. For online meetings, you can use something like www.teamretro.com and let the team raise all the issues, including product, UI, etc. Talk about the most voted issues, and don’t feel obligated to get into stuff nobody voted for; it’s likely only noise.
Make sure actions from Retros are written down, turned into tickets, and assigned to a particular person who will be responsible for resolving them. If you think the ticket is not needed or maybe you won’t assign it now to anybody, it likely means it is all BS, and you should skip it.
Agile boards and stuff
Whatever tool you will use, people will complain about it! So use the one that is simple, and does most of the things you need. Tweak the process to fit into the tool, rather than have a unique and complex process and match the tool. It’s possible with Jira, which is highly customisable, but I saw it being overengineered and became useless, which is one of the challenges in attempting to simplify the agile process to deliver faster. Heavily modifier software automatically implies to all other teams that they have to work in a similar way, which is against the team’s flexibility principles.
The tools
I strongly favour using something that delivers documents, the typical intranet, integrates with external tools like GitHub and provides “good enough” boards and roadmap planning. I tried ClickUp, Jira with Confluence and a few other things I don’t even remember, but in the end, I settled down on Notion as a tool of choice for such things. Boards are customisable and not too complex; I can easily connect all team’s boards with projects and give product owners visibility on particular projects across multiple teams down to single tickets and statuses, calculate effort planned and spent and even do automation directly with GitHub for PRs and other activities. Is it perfect ?— absolutely not, but it’s good enough.
Board per team
Keep one board per team. Please don’t attempt to have multiple boards in one team; it’s a nightmare, and everything they do should be in one place. Engineers have a problem updating their tickets on time in one place, not to mention a few!
Columns
Having the default starting point for preferred columns for team boards is helpful, but the team should ultimately be able to define and tweak them as needed (which rarely happens anyway).
Transparency
Ideally, each team should be able to see the future — have access to the roadmap and see what they are working on and what is planned next for them. I mentioned earlier about seeing 1–6 months ahead with some confidence. Writing about the roadmap and product strategy is not a topic so that I will skip the details.
Orphant tickets
All tickets must be assigned to some top-level workstream so the product team can track all work across potentially multiple teams, measure impact and track progress as necessary, on their own terms. Since some random tickets don’t fit the project delivery category, we always had a few workstreams like “Client Maintenance”. This way, we assign these orphans-type tasks and measure how much time is invested in the typical project maintenance. Just don’t go too crazy with these generic categories. You probably went too far if you had one for each project. Once the project has been delivered, it becomes part of an app or platform, and that’s how you should approach the segmentation of ongoing maintenance workstreams, not to overdo it.
For example, in my last company, we had four of them — Client, Phorge, Dev Platform, and Carbon — and these were the names we used as they applied to particular applications.
Decluttering
The team is responsible for decluttering the boards as soon as things have been completed. We don’t want hundreds of tickets in the “archived” column since they are already 100% completed and delivered and don’t belong here anymore. We always had a Product Archive board where everything was moved after a project was fully completed. In the same way, we have a Product Preparation board where we create and keep tickets for all projects that haven’t been started (it doesn’t often happen as the majority of tickets are created by the team when they are starting the work).
Where does that lead us to…
While I’m sure you still haven’t gotten all the answers you might be looking for, I hope you understand how flexibility, simple processes, and trust connect to create effective, genuinely agile delivery teams. Since there are so many topics to cover, I kept it light and focused on the most important elements I consider helpful. We can go deep on each topic, but the technicalities behind them really heavily depend on each team, company, and culture.
Part 3 is coming up soon…
