12 min read
Will It Make The Boat Go Faster?: an Agile journey
Craig Rogers on Sep 29, 2020 3:21:00 PM
Ben: “Will it make the boat faster? Then do it!” p.295, Will It Make The Boat Go Faster?
We interviewed engineers and managers at Eagle Eye to gather tips on becoming a faster Scrum team - here are the top 7!
1. Have a designated expert for technical decisions
No matter how experienced your team is, there will be rare occasions when they have to seek some external guidance, particularly when breaking new ground. In these cases it’s easy to get bogged-down seeking a wide consensus, or debating small details.
We know that having a single source of truth on requirements and priority, the Product Owner, can bring clarity, consistency, and speed to product decisions. In the same way, a designated technical expert can bring these qualities to technical decisions. So, well in advance of actually facing these decisions, establish a relevant expert to make the final call on them. Designate your expert in the way that makes the most sense, perhaps that’s per epic, team, component, or technology.
For decisions which are consistently a stumbling block, such as naming new microservices, create RFCs (Request for Comments) to set standard approaches which are accepted across all teams.
This is not: An excuse to remove key decision-making from teams; it’s a way to keep them fast when they would like support.
Note that if your teams are consulting on decisions frequently, that’s a red flag 1.
2. Invite key players to refinement
At Eagle Eye, there are too many client setups and integrations with our product for the Product Owners to understand the detailed ins and outs of every ticket. It’s sometimes easy for Product Owners to become a go-between in these cases, having to postpone discussions while they consult with people more familiar with the client context.
The Scrum Guide makes clear that the whole team can help refine Product Backlog items, even though the Product Owner is solely accountable at the end of the day. So, it’s not an act of anti-Scrum to invite key players to your refinements to provide immediate answers on client-specific contexts, helping your team to:
-
Double check that their high-level approach is appropriate
-
Ask questions about any client integrations or knock-on effects of the work
-
Understand the more complex, uncertain, or risky elements of the potential solution - improving their estimation and informing their approach to completing the work
This is not:
-
A move to weaken the Product Owner in their role - they should still have the final say over the requirements of the work
-
An excuse for weak Product Ownership - they should understand how the product is used as much as they can
3. Fulfil the original client request first
Often, your work on a product feature will have its roots in a specific client request. If you’re not aware of the request, your team could misspend a few sprints prioritising a different subset of the feature, which isn’t actually valuable to the client.
Make sure the original request isn’t lost in the process of forming a wider product vision for the feature, so that you can deliver value quickly to the client that asked for it.
This is not: A deviation from the product vision as set out by the Product Owner. It’s a tactical focus on the areas where the client-specific and broader product requirements overlap.
4. Only perfect each component once you get the key data flowing
When using an Agile framework such as Scrum, it’s easy to forget the lower-level benefits of an Agile mindset, and fall into the habit of fully completing work in one component (e.g. adding lots of new fields in a UI) before starting work in another component (e.g. completing business logic in a microservice).
Remember that being empirical (validating your ideas through doing / showing) isn’t just for Sprint Reviews. By building your solution in small slices, you can give nasty surprises fewer places to hide. In the example above, you could initially agree on the payload/data structure of only a few fields sent from the UI to the microservice. This would allow you to quickly mock the incoming/outgoing data in each component, and work on a minimal implementation of the feature in both components at the same time. Once you’re done, you’ll know for sure if the data structure is appropriate, and whether the data flows without issue. This approach will validate your assumptions before you perfect the work and move on to the next small increment of fields 2.
At Eagle Eye, this has been used in our ‘hackathons’ - where a team works very collaboratively to get the key data flowing first, and only then perfect each component with validation etc.
This is not: An excuse for a lack of validation or other essential checks by the end of sprint.
5. Use similar feature implementations as a basis for your own
We spend lots of time solving unfamiliar and complex problems under pressure, and it’s tempting to dive into coding as soon as possible. However, this can sometimes overwhelm us with low-level detail and send us down rabbit holes which slow down delivery.
Make time to pause and think at a high-level before jumping into the detail. Have a look at the area of the product you’re working in, and ask your team if any similar functionality has been delivered before. Occasionally you’ll find something which you can use as a guide for your own solution, speeding up your delivery, and giving you brownie points for consistency. On other occasions, you’ll find examples of what not to do, but of course this can be even more helpful.
This is not: An excuse to copy and paste code without considering whether it is appropriate for the current solution, or whether you are adding to your technical debt.
6. Ask and offer help early
There’s a dichotomy in working as a team, which is that we’re responsible for our own part of the commitment, but also for the whole team’s commitment. Knowing when to ask and offer help is the key to this dichotomy. Here are some tips.
On asking for help:
-
Always try to fix the problem yourself before asking for help. This will help catch simple oversights, and will show initiative to the teammates you ask for support
-
Use stand-up to raise that you are struggling. Even if you aren’t stuck before the stand-up itself, it’s a great place to give people warning that you’ll need their help later in the day, and it will put your issue on the radar of the Product Owner and Scrum Master
-
Ask your team as soon as you find yourself spending significant time on a problem - it could cost them 20 minutes but save you 2 hours. To help with this, consider setting an alarm as soon as you hit a problem, and ask for help when it goes off
-
Become increasingly loud if you aren’t getting the support you need, and make sure your Scrum Master is aware. If you’re too polite, the whole team’s output will be affected so they shouldn’t mind the interruption
-
‘Pull the parachute’ if you’re still stuck after an extended period of time. Hold your hands up and pass your task to someone else, or pair up with them. Your team will respect you more for having the courage and honesty to do this than for trying to save your ego
On offering help:
-
Never offer to help with a task that you’re unequipped to help with. If someone is just looking for a listening ear and a new perspective, then you may be able to provide that without experience in the particular domain. However, if they want more technical support, make your lack of experience in the area clear to them, and recommend the best person to ask next
-
At stand-up listen closely for subtle signs that your teammates are struggling. Perhaps their ticket hasn’t moved in a couple of days, perhaps they keep mentioning new ‘surprises’ in the code, or perhaps they just sound concerned
-
Try and encourage everyone on your team to offer help when they can. If it’s always the same person, they’ll be sacrificing their own ability to complete work
This is not: An excuse to disturb your colleagues without trying to fix your problem first. Give it your best shot and tell them what you’ve tried so far when asking for help.
7. Discuss your approach to tests as a team
Your team will ideally have a good understanding of their Definition of Done - the things that need to be complete for a story to be called 'done'. This will cover the categories of tests and reviews which need to be performed, but will not specify exactly which tests should be written for each story. This can lead to under-writing or over-writing of tests, creating a less stable product or slowing down delivery.
Discuss the tests you plan on writing as a team to identify those which will protect the business from impactful failures. Also consider the cost of automating the test relative to a manual check. If a rare use-case would cause a low-impact problem, but an automated test would be high-effort to produce, then a manual test is the way to go.
This is not: An excuse to expose the product to unacceptable risk by sacrificing essential tests.
Thanks
A huge thanks to everyone at Eagle Eye for providing invaluable interviews and feedback in the formation of this article.
1 The response from leaders here depends on the root cause.
If the team lack the experience/knowledge to make these decisions:
-
Set aside time to up-skill them
-
Change the type of work they do
-
Add new team members to bridge the gap in experience or skill
If they’re capable of making these decisions, but are being too cautious:
-
Clarify and encourage them to make certain categories of decision without asking for input
2 This is a lower-level extension of ‘walking skeletons' (coined by Alistair Cockburn), and 'tracer bullets’ (described in The Pragmatic Programmer by Andrew Hunt, David Thomas)
5 min read
The Importance of Securing your Network (Honeypot Analysis)
Chris Feasey on Nov 27, 2020 8:58:00 AM
The internet, as we all know, never sleeps, never takes any time off, and is active at all times of the day.
10 min read
What makes a good code review?
Craig Sefton on Nov 5, 2019 2:50:00 PM
Start With The Right Attitude Code reviews are a collaboration between two or more people. It's not an opportunity for you to show how superior you...