Agile Essentials

In our work pursuits that involve uncertainty, volatility, change, and ambiguity, we seek to align to the principles and values of the Agile Manifesto, whereby people, valuable software, collaboration, and adaptation are held as primary.

As such, our product/software development endeavors will generally follow the Scrum methodology by default, with healthy flexibility in implementation so long as the team's methods and practices align with the spirit of the manifesto.

Agility is not not an end-state but rather a habit of continuous practice development. As such teams and individuals are enouraged to seek informal agile practitioner mentorship as well as formal training/certification from organizations such as Scrum Alliance and ICAgile. In other words, to technically follow agile is straightforward. To be a high-performing team or individual is more challenging.

The Pluribus baseline expectations for agile delivery include:

  • Visualize The Work Everything the team is working on at any given time should be discoverable and viewable visually. This can be done through mechanisms such as a scrum board, wiki, and product map using tools such as JIRA or Figma.
  • Regular Prioritization Teams will regularly work with a product manager to prioritize the work based on its value proposition.
  • Results-based Targets All work items should connect to targeted and agree-upon results that generate some value. Avoid non-value added work or ophaned work items that do not connect to any specific result.
  • Center around Users and Value The consumers of the digital services we build and the value those services provide should be central to delivery. Avoid pitfalls such as using technology for technology's sake, disconnecting from end-user needs, or sacraficing value for near-term optics.
  • Commit and deliver as a team. The scope of the sprint is a team commitment and the team should ensure all non-impacted commitments are delivered at the end of a sprint. Despite individual assignments, the team owns getting it all done. There may be quarterbacking of “I’ll work on this one”, but the whole team should always swarm to unblock stories.
  • Run high-quality retrospectives Seek and gather feedback continuously and reflect at appropriate intervals to enact positive change. If you are in an environment where this process is not valued, run Pluribus-only retrospectives.
  • Use the right measures Story points and velocity measures can be helpful if used by the team to aid in planning and forecasting, but can be harmful if used as a way to externally measure delivery. Instead measire delivery against DORA metrics or product/feature valuation.
  • Give great demos. It is worth the thought, attention, and time to deliver a great feature demo. When a feature is worth your time to build, it is worth your time to convey the value of it to stakeholders. Put yourself in the customer/stakeholder shoes to show off what you’ve built in ways that will resonate with them. This is especially true for more “behind the scenes” technical features that may be less obvious to some stakeholders.
  • Lock scope in the near term (sprint) The sprint scope is a team commitment that should be locked for the duration of the sprint unless there are extenuating circumstances. If there is a high rate of churn and scope evolves quickly, shorten the sprint to a point where scope can be locked and deliverd in a reasonable time.

Visualizing and Tracking Work

As builders of digital services for government, we are professionally obligated to document, track, and log the work that we are doing. Work visualization also helps teams and stakeholders understand what is being done and what needs to be done next. New system capabilities can be represented as Feature Epics or user stories. We generally start with a very short description ("As a ... I want the ability to do ... so that I can ..."), and then build out more information including the acceptance criteria for confirming completion.

Teams use agile lifecycle management software, commonly JIRA or GitHub Issues (with visualization help from Figma) for these purposes. Any tool works that allows us to track key elements including:

  • Title
  • Size/points
  • Acceptance criteria
  • Notes/comments/discussion

Standup Meeting

Short, daily standup meetings help teams focus and adapt to impediments on a daily basis. The meeting is meant to be very short (under 15 minutes) - just enough to raise key coordination questions and important topics for additional team break-outs. It shouldn't rehash what is already on the board, and should open up opportunities for serendipity and opportunities to solve problems. If there are issues that require further discussion they can be referred to "16th minute" items, this is a nod towards the end of the standup that should end in 15 minutes. In general the business stakeholders should be invited to attend and listen in on the standup so they can work with the delivery manager or scrum master to make decisions about reprioritization and coordinating resolving blockers.

Great Retrospectives

Most agile teams have a meeting called the “retrospective”, but it is hard to do retros really well. The retro is a great pulse-check on team health because it builds on things that are not always easy to gauge, including team culture and trust levels.

Within the typical form of a retro meeting, there are a few critical differentiators between time-wasting checkbox meetings (going through the motions because the process says to) vs. high-value meetings that help teams thrive.

Pluribus Expectations of All Employees

  • Be respectful of the fellow humans on your team in the way you interact. This helps to foster the critical but fragile psychological safety within the team. That's always important, but "the vibe" is everything in the specific retro meeting context.
  • Be candid and not "pull punches" in giving honest feedback on what truly worked or didn't. Don't ignore the "elephant in the room." This can be hard or awkward for some folks, even in the most inclusive and trusting teams. If you are having trouble, enlist a teammate or manager for help on how to best raise the issue.
  • Monitor your own interactions, making sure you aren't taking up all of the airtime. If you are talking more than anyone else, take a step back or try to pull others into the discussion.
  • If you feel comfortable, call it out when you feel the environment isn't one of open, candid, respectful conversation. Also raise the flag if the discussions are becoming stale.
  • If you are interested in growing your leadership and facilitation skills, offer to facilitate some of the retro meetings. It can be fun to research different exercises or tools and try them out.

Pluribus Expectations of Leaders

  • Take ownership of fostering an inclusive, respectful environment within the team. Look for people that are not as engaged and tactfully reach out to understand why. If specific team members threaten that fragile balance, provide corrective feedback and escalate if need be. Pay attention to who is in vs. out of the conversation and steer things accordingly.
  • Ensure some items raised result in meaningful changes, even if small. The team shouldn't act on every bit of feedback raised, but they do need to see some action resulting from the retro process.
  • Monitor your own participation as a leader and weigh your words. A thought intended as a suggestion might be perceived as something difficult to challenge if coming from a leader or expert. Do share, but be careful not to force your perspective, even if unintentionally.
  • Offer up self-criticism. Point out "could be better" items that relate to your areas of improvement. This encourages others to be similarly self-aware, but also opens the field for others to feel comfortable raising improvement opportunities in leadership.
  • Shake things up when retros become stale. This can include enlisting others to help facilitate.

Resources

results matching ""

    No results matching ""