Focus on Goals, not Best Practices (Part 1)

Focus on Goals

Focus on Goals

Mark Kilby and Jeffry Hesse

As we discussed in Part 1 of our engineering tour webinar, we have several teams following the Scrum framework, but not all in the same way.  As a framework, Scrum does not give you all the details.  It lets you work out what’s best for you.  Instead, the “rules” of Scrum are more akin to goals you want to achieve for your process.

What goals do we have at Sonatype?

  • Frequently refine future work so that we have it well defined, prioritized and ready to go
  • Work as a team throughout the Sprint
  • Talk daily if not more often about what we are doing to meet Sprint goals
  • Demonstrate shippable product slices to gain feedback from stakeholders

That’s basically it. You will likely notice that our goals align with the Agile Principles quite well, but that wasn’t by design. We chose to use Agile methods and Scrum because they fit well with what we valued. We also chose our own process goals because it allows us to use Scrum as a framework, and not as a recipe. We take a look at Scrum, Kanban, etc.. and we pick the parts that work the best for our culture, and we play with them.

The Playbooks

How we get to the goal depends on our team and the “plays” they want to execute. The Nexus Team for instance does Backlog Refinement in a different manner than the CLM teams. This flexibility in getting to the goal allows us to create different playbooks for these “slightly” abstract concepts that exist in Scrum. Over time, our playbook becomes a team best practice, but only for as long as the team decides it is. If the playbook stops meeting the process goal, we take a step back and see what we can do to adjust.

So “best practices” really are unicorns.  We don’t believe we can have one practice that will work well for everybody.  What works best for one team may not work well for another.   Also, what worked well in the past, may not work well now based on changes in the work or the team.  We’ll run through a couple of quick examples..

Why Backlog Refinement?

Backlog Refinement is a practice that we’ve used to meet our process goal of “Refine future work so that we have it well defined, prioritized and ready to go”. It’s not the only one though. We also do a separate meeting with The Nexus and CLM Teams called Bug Triage. How do these meet our goal?

Backlog Refinement for the Nexus Team helps meet our process goal because it allows us as a team to get together and discuss future work. We take stories that have very little detail and together we add Acceptance Criteria, Mocks, Screenshots, and Technical Direction. When we are done with doing this, we know that the story contains enough information to enable us to start working on it. We also know that it contains enough information such that most anyone on the team can work on it. This helps enable our next process goal to work as a team during the Sprint.

For CLM, the Product Owner (PO) prepares a first draft of the stories with acceptance criteria.  As a former senior developer on the team, he has an understanding of translating very loosely defined requests into stories that the team can more easily discuss.  For more complicated stories, our PO will have our UX designers provide some wireframes.  Then in backlog refinement, the teams may revise the acceptance criteria through conversations with the product owner as well as add notes on technical direction.  We use our sizing via planning poker to guide the conversations and when edits are needed to clarify the requirements.

The Bug Triage

Another meeting we do by the name of Bug Triage is a bit more specialized but just as important to us. We get reports of bugs from our Open Source users and so we set up a special meeting to just look at those, and ensure that we as a team knew about issues that were coming in from Support and those OSS users. This helps to make sure that we aren’t just focusing on future “feature” work, but also the work that is important to maintain the Nexus Product ecosystem. Since we do these meetings as an entire team, it also helps enable the goal of working together during the Sprint.

With CLM, the team has chosen to just have three developers participate in the CLM bug triage on a rotating schedule.  We can do this for a few reasons.  First, we only have the commercial product (no OSS) and that makes for a smaller user base.  Second, as our developers tend to move through broad areas of the code base, they are able to address a broad range.  So with three developers, we can usually assess and size any bugs that come in from Support.  Also, in this same meeting, the developers will identify any technical debt that the team as a whole might need to address in an upcoming sprint.  This then gets put on the backlog for the team to pull in when sprint commitments are near completion.

How do we work together?

Being our teams are quite different in how they are constructed, there are a number of ways by which each team approaches working together.

Remote pair programming

An experiment we tried on The Nexus Team was to get two developers together to pair program remotely. There were many reasons for us to try this, but the biggest one was that we want to work together as a team! Although we are remote from each other, we still want to learn from others, and we still want to create awesome software together. Remote pair programming is not the only thing we do though.

Peer review

We have a pretty thorough peer review process, where the team takes a look at the work others have done like in this example of Maven Hosted Repositories in Nexus 3. You can see a lot of conversation happening! This is something both teams do, and do often!  Also, in another blog post by Jamie Whitehouse, we describe in detail how both CLM and Nexus uses Github as part of our peer review process.

It’s actually amazing to watch the conversations unfold in Github, sometimes the more difficult one discussed further in email and then decisions captured in Github and Jira.  This mechanism of capturing the conversations electronically allow for a breadcrumb trail to be left for any team member to follow if they are picking up the code or if they are onboarding as a new member of the team.

Helping teams reach the goal

In this blog post, we discussed a number of ways teams reach their process goals to deliver value for our customers.  Next time, we’ll talk more about some of the daily communications and how the teams get feedback on the features they deliver every sprint.


The following two tabs change content below.

Mark Kilby

Agile software project mentor helping organizations achieve profound productivity, increased quality, and intense customer loyalty to rapidly adapt and thrive in today's marketplace. Interests include organizational change breakthrough methods, collaboration techniques and technologies for distributed and co-located teams as well as automation of software construction to allow developers to focus on craftsmanship and quality.

Related posts