(Technical) Ways of Working
Some less talked about practices for smoother project delivery.
“We have the requirements and a beginning point in the backlog. So, let’s start Sprint 0 to build the project skeleton.”
Sound familiar?
This may seem like a good place to begin; however, many other significant considerations for engineering teams need to be established from the outset to ensure successful product delivery. You’ve undoubtedly heard of effective Ways of Working (WoW) in Agile, among other commonly used practices. Let’s explore a few less talked about (Technical) Ways of Working that are also vital for success.
Why is this approach important?
I term these Ways of Working as technical to raise awareness that most of these mutual agreements might be best driven by engineering teams themselves rather than relying on a designated delivery lead or project manager.
Inconsistencies in WoW related to tools or unaligned decisions within an engineering team can hinder the smooth delivery of projects, resulting in lengthy discussions and unnecessary context switching for the team. We even have physics to prove this for us!
Momentum = Velocity x Mass
Michelle Labrosse, a prominent figure in the world of project management, describes project tasks as gaining mass and efficient collaboration as gaining velocity from a project management perspective. It follows that if there are numerous roadblocks and inefficiencies in WoW within software development, then momentum will decrease.
In this blog post, I will share a few situations I’ve faced in my career that helped me use these less talked about (technical) WoW alongside the more traditional agile approaches to setting up project teams for success. Each situation begins with a quote from someone I worked with at that time.
Effective Technical Ways of Working
Situation # 1: A Product Owner (PO) told one of my teammates, “You’re seeking an extension on the project, but there’s nothing more in the backlog for your role.”
The PO knew the functional requirements and architectural details very well, so he collaborated with the scrum team to create user stories. However, other work related to the supporting frameworks and environments wasn’t entirely visible to him to create all the stories.
The strategy for all the supporting frameworks (like automation, environments, etc.) was well communicated and agreed upon by the team, but a lack of visibility into several technical stories in the backlog gave a false perception that the project was nearing completion. The PO assumed that the backlog included all remaining work. Meanwhile the SMEs didn’t find the capacity to create tickets for the remaining technical stories.
Technical WoW: A mutual understanding of who will write the technical stories and how they do it will reduce ambiguity and make the backlog reflect the actual remaining work. All known technical stories should be in the backlog to present a current and actionable state.
One useful approach is for SMEs to imagine the framework as a product on its own. This way, creating a prioritized backlog of technical stories for the framework with the team and the Product Owner would achieve a vision of what is critical to complete, when, and who will complete it.
Another significant benefit of visibility into any remaining technical stories is to prepare other roles whose input will be needed to achieve an outcome in a framework. One classic example is automation frameworks that run on fitting environments and pipelines during different stages of the software development lifecycle. This kind of work may involve multiple roles to collaborate, and visibility is essential.
Situation # 2: A PO told an engineer at my former workplace, “I can’t release the app with this major bug.” The engineer replied, “Well, I created a ticket for this issue in the backlog five weeks ago. Didn’t you see it?”
At a previous workplace, mid-way through the last sprint before a major release, one of my teammates raised a question in a standup meeting.
“Before launch, are we going to fix the bug where the video disappears in some situations?”
Everyone was confused and unaware of any such issue. It was an extremely critical one given that the product relied on extremely high-quality video that was precise to a matter of milliseconds.
The PO asked, “Which missing video issue? Is there a ticket in the backlog for this?”
There was a ticket in the backlog, but it was created at an odd hour of the day when nobody else knew about it. The owner also forgot to raise it with the team.
We often see a lack of ownership in communicating issues within a team. Engineers may feel they have done their part of the job by logging the issue. That is like a needle lost in a backlog haystack unless it’s communicated and discussed with the team.
Technical WoW: Create enough visibility between engineers into defects and tech debt in the project. Get alignment on the mode of communication to promptly discuss these issues. Screen sharing sessions to dig deeper into any problems together, or having a quick huddle to talk through the impact of any tech debt saves time and supports the goal of fast feedback between teams. Other times, if working with cross-border teams, let automation handle the comms. Many automation tools exist that can be set to trigger alerts in communication platforms for important information.
Situation # 3: An engineer I worked with once told a Tech Lead, “On my past project, the data engineer did that work. I assumed that you would do it in this project.”
A week before a milestone delivery and user acceptance testing, the Tech Lead at an emerging startup I worked at shared, “We don’t have the front end working yet because the data model changes are not completed.” The Data Engineer replied, “I wasn’t aware I needed to take care of this. It’s definitely something that software engineers can do as well.”
Technical WoW: In project-based work, where team members often change, it’s crucial to establish clear lines of ownership. While cross-functional roles in agile may often blur lines of responsibilities, it remains essential to ensure that team members understand each other’s roles and areas of impact to prevent work from falling through the cracks.
Quality is another area that benefits from an initial discussion about what type of testing and automation will be done by each role to build quality into each story. Assumptions, especially those made from past experiences, can lead to rework and wasted effort.
Situation # 4: An engineer I knew nervously told their team, “I used the wrong branch for the rollback release!”
While working at a digital media house, I witnessed a “sky is falling” production issue that needed a hotfix of a rollback. Since the branching strategy was not clearly understood by everyone on the team, the absence of a key member created confusion. Not to mention avoidable chaos and loss of time. This chaos impacted how the hotfix was managed, “I take complete responsibility for this mistake. I’ve merged ongoing sprint work to the rollback branch!” Using the wrong branch added a severe risk of unnecessary movement of a large amount of code between branches and potentially negatively impacting user experience.
Technical WoW: New teams or projects often overlook the need to establish a mutual understanding of the chosen branching strategy and different branching scenarios that may need timely attention in the face of critical issues. This can lead to confusion and mistakes.
It’s vital to establish common ground early on and ensure that everyone on the team clearly understands the branching strategy, release strategy, rollback strategy, and other key processes. Visual diagrams such as the one below can be particularly helpful.
To reduce the stress associated with these nail-biting situations, create a structured runbook or document detailed steps that clarify both the release and, if applicable, rollback procedures. By following a methodical structure that has already been analyzed and implemented, teams can move forward confidently, knowing they have a plan to address any issues that may arise.
To spark a few more ideas around how your teams can align on your technical WoW, here are a few essential actions to consider:
- Rip off the band-aid and delete older irrelevant tickets in the backlog: There’s no use maintaining work/defects that are two years old and nobody is likely to work on. Rip the band-aid off and only keep value-driven work in the backlog.
- Align access levels and roles earlier: At times, product user permissions and roles may be designed later in the product lifecycle. Earlier decisions within the team will reduce any risk of access loopholes being left in the product.
In a nutshell, spice up your team dynamics with a sprinkle of mutual alignment, a dash of cross-functional awareness, and a generous serving of collaboration. It’s the secret sauce to not just meeting, but flawlessly rocking those project goals.
I’d love to know if you have any suggestions for technical WoW that have accelerated your project delivery process. 🚀
