Why Doesn’t SOC Agile Mention Retrospectives?

When you read the following you might believe that we’re “anti-Scrum.” We’re not! We’re huge fans of Scrum. That being said, we acknowledge that Scrum isn’t for everyone.

So far we’ve heard quite a bit of feedback regarding SOC Agile. This feedback has been on Twitter, Facebook, Google+, LinkedIn and private email. Here are a few samples that were publicly shared:

So while we’re pleased that people are happy and that we’ve accomplished our goal of reflecting what the real world does, some concerns were expressed. Many concerns boiled down to “you’ve left out feature X!” That’s often true. We purposefully didn’t include:

  • tracking velocity
  • burndown charts
  • sprints
  • retrospectives
  • backlog refinement meetings
  • calculating product backlog item effort
  • pair programming
  • refactoring days
  • planning meetings
  • backlog board

… or any of a number of activities that, while worthwhile individually, risk obscuring the forest for the trees. It’s worth keeping in mind the first important point of the Agile Manifesto:

Individuals and interactions over processes and tools

SOC Agile is all about returning Agile to a “lean” environment. It’s perfectly OK to extend SOC to include those processes that you find actually help you, but SOC Agile doesn’t presume to know you or your needs.

Products Over Process

You might recall this graphic we posted:

workflow

Obscuring the forest with trees.

Click on that graphic and read every item in the workflow. Ask yourself, from a management perspective, “what benefits does that item provide?”

Now that you’ve done that, keep in mind that in companies who use interesting workflows, developers often ignore the workflow and still get work done. What is interesting is that management can generally justify every single step in that workflow. It can be an uphill battle to convince a company that layering on process can hurt productivity even though there’s a well-known trade-off in adding process: when spending time following process is risking becoming as time-consuming as spending time developing products, it’s time to assess the risk/reward ratio involved in layering on additional processes. This is not an easy trade-off to assess and a “one size fits all” methodology doesn’t work (to be fair, every agile methodology suggests customizing it, but as soon as you do someone invariably claims that “it’s not agile”).

So why didn’t you include retrospectives?

For those unfamiliar with Agile development, the retrospective is basically a meeting where teams discuss:

  • What works
  • What doesn’t
  • What should change

Retrospectives are a very valuable way of continually re-examining what you are doing and making it work better. However, the lack of a retrospective in SOC was the biggest complaint. While we addressed this briefly in the “Extending SOC” section, we deliberately kept the post brief.

Retrospectives were skipped for the simple reason that we’ve encountered many successful teams that skip them. Of course, there are also successful teams that include them. SOC doesn’t presume to dictate this choice. We agree that retrospectives are a valuable tool that can help your team improve, but we hold that there are two main reasons for adding process to SOC:

  1. When productivity suffers
  2. When morale suffers

If you have a highly productive, high morale team, how is adding layers of additional process going to help? Do not force process on teams that do not need or want it.

When retrospectives become a chore, they can become burdensome and people start coming up with creative strategies to keep them interesting. When they arise naturally out of a desire to fix something, they become useful. Just as Agile often favors an evolutionary design process in software, SOC favors an evolutionary design process for teams. We may update SOC in the future to include an optional retrospective, but done when the team feels it’s needed, not on a regular, mandatory basis.

If you want to include retrospectives, do so! But keep the following points in mind. The meeting should be time-boxed and held in a pleasant environment, maybe even off-site. These should focus on creating actionable tasks that the developers feel will help improve productivity or morale. These tasks should be added to the backlog, when feasible, or used to adjust SOC, as needed. If you create Priority Tasks (as defined in SOC), try to keep a retrospective task as a Priority to ensure that action is actually taken. One of the biggest complaints about retrospectives is that they become a gripe session and nothing gets done.

But you need a Scrum Master!

In a Scrum environment, the Scrum Master:

1. Helps the team agree on what can be done in a sprint.
2. Helps the team reach consensus during stand ups.
3. Helps the team follow Scrum rules.
4. Removes blocks to productivity.
5. Protects the team from outsiders.

Unsurprisingly, many of the Scrum Master roles assume that you’re using Scrum. There were suggestions that without a Scrum Master, the team could be distracted by outside influences or, in the memorable words of one commenter:

A team without a good Scrum master is a team that is handicapped, it may have to struggle for its existence.

We feel comfortable in saying that many teams without Scrum Masters would be surprised to learn that they are handicapped and possibly struggling for existence. When your three developers in the five-person startup find themselves hacking away like mad to reach a beta and the next round of funding, it’s not a given that adding a Scrum Master is going to help.

In many ways, a Scrum Master is there to facilitate Scrum, but since SOC is not Scrum and is much lighter-weight, the need for a Scrum Master is mitigated. A Scrum Master is not a team lead, but the Team Lead in SOC assumes some of these roles, including keeping members focused.

In Scrum, teams are said to be “self-organizing” and a Team Lead is said to suggest a “command-and-control” process style. In SOC, a Team Lead does have final say, but they are to follow a supporting role as much as possible instead of a directing role. However, at the end of the day, sometimes someone has to cut the Gordian Knot of team disagreement and the Team Lead bears this responsibility. We strongly reject command-and-control as the sole mover in Agile, but we don’t reject that sometimes someone has to make tough decisions when others can’t. We also don’t believe that “self-organizing teams” necessarily mean that no one assumes responsibility.

But how to you keep developers focused?

Another excellent concern expressed is that developers might continually choose poor tasks and get stuff done while the project drifts aimlessly. We addressed that, but it’s clear we should have highlighted this better and we updated the SOC description to make this more clear.

There are two tactics in SOC to prevent “team drift.”

First, in the daily Summary, the PO says “where we’ve been, where we’re going” and also brings up interesting things that developers may need to be aware of. The “where we’ve been, where we’re going” part of the Summary is the tool that developers use to understand what tasks they should prioritize.

Further, it’s mentioned that the Team Lead and PO are responsible for assisting developers in choosing appropriate tasks when they’re doing a poor job of doing so. This is part of the “continuous improvement” that we strive for in Agile. Give the developers the responsibility to get things done, but have an appropriate mechanism when they don’t.

Stand Ups: In Person or Email?

A couple of commenters suggested that stand ups are a waste of time and daily status updates can be conducted via email.

This was an interesting objection to SOC. Unlike most others responding, these individuals were trying to make SOC even more Lean than it already is! We would suggest that if email works for you, so be it. We’re not claiming that every team should function identically. However, we refer you an article by Alistair Cockburn, Characterizing people as non-linear, first-order components in software development.

So did you read that? No? Well, the title may have put you off, but it’s firmly tongue-in-cheek. It’s a hilarious and brilliant. Section 2 refers to several different methodologies used to help teams deliver software better and each description ends with:

  • Problem 1. The people on the projects were not interested in learning our system.
  • Problem 2. They were successfully able to ignore us, and were still delivering software, anyway.

However, that’s merely an amusing digression away from the “email versus face-to-face” discussion. Stands ups can work over conference calls, but they’re less effective. If you have a remote team, a video Skype call can be almost as effective as a face-to-face. In fact, in Cockburn’s research, he lists the following in descending order of communication effectiveness.

Effectiveness Method
Best Face-to-face
Phone
Email
Videotape
Audiotape
Worst Paper

Email, in the above, winds up being better than video, audio, or paper only because someone can reply to your email and expect to get an answer. It works if there is interactivity. Otherwise, it’s no better than paper and, in our experience, it’s often worse because many people dash off emails very quickly with little thought to coherence or proofreading. At least something committed to paper has more thought put to it.

In the case of a stand up, you often want someone to say “wait a minute, why did you do that?” A quick question like that and a brief response can easily avoid much confusion and tremendously help improve communication. Email is often not read or the recipient thinks “I’ll respond to that later,” but doesn’t. It’s simply not as effective for a stand up, though with temporally diverse teams, sometimes it has value.

However, we need to stress again that if you find email works better for you, great. Not everyone works the same way.

PHBs?

At this point we want to address a comment that was made once about the workflow in the graphic above. Your author (Curtis Poe), was presenting a talk entitled Agile Companies Go POP and afterwards someone commented to him that the person who created that workflow must have been a real Pointy-Haired Boss (PHB).

In this case, we’ll call that boss “Bob.” Bob was married, had two children he was devoted to, had lived in multiple countries and spoke several languages. He also had an interesting talent. At meetings, when a manager asks “can’t you just do X?”, developers often groan because now they need to explain to the clueless manager that no, we can’t backup the local server farm to a remote data center over Wifi (true story). In the case of Bob, when he asked “can’t you just do X?”, developers also often groaned, but that’s because they probably missed something. Bob was sharp, technically savvy and knew all of the projects very well. When he asked a question, you had better have done your homework or risk looking like a fool in the meeting.

So while he may have defended that 20-step workflow, it’s not because he was a PHB. He simply had a different, non-agile, approach to working. Various people in that company told me that he was exactly what they needed compared to their prior Cowboy coding style and that he brought much needed discipline to their processes. While it’s easy to dismiss someone who does something differently from the way we do, it’s always worth remembering that there’s always a backstory and the situation is never as simple as it seems.

Summary

The people who primarily objected to SOC were heavily invested in Scrum, some of them selling Scrum-related services (note: that’s not saying that having a stake in the answer means that their objections were necessarily wrong). They felt that SOC was too lightweight and didn’t provide enough structure. Those who liked SOC generally felt that it represented the “real world” and often reflected what their companies are currently doing.

We continue to maintain that Scrum is great and being Agile is almost mandatory in many of today’s companies to help them keep up with our fast-paced world (it’s no coincidence that Agile was blossoming just after the dot-com bubble burst). However, some people in the Agile world seem to have lost the plot: they’re defending processes and tools over people and interactions. Some people are calling Agile “snake oil” in part as a backlash against (in our opinion) misunderstandings about Agile.

SOC is about making Agile “lean” again.

This entry was posted in General. Bookmark the permalink.

3 Responses to Why Doesn’t SOC Agile Mention Retrospectives?

  1. David Lowe says:

    One small thought: a good ScrumMaster (or agile coach) has the skill of drawing out improvements and challenging stale practices/the status quo, etc, rather than just being about planning sprints and removing impediments.

    • David, that’s an important point, but can’t that be pushed into a decent retrospective for a self-organizing team? I think it can, and should. That being said, I strongly recommend that everyone generate their own SOC and if they feel a central person is a good fit for this role, let the experiment begin!

      • David Lowe says:

        In theory, everyone on the team can be perfect at everything. However, in reality, each of us has skills that others don’t … so having someone who specialises in change/improvements often has benefits.

        However, I concede that a team ‘could’ get the same effect without such a person.

        It’s probably also worth noting that sometimes a team HAS a person who is focusing on improvements, but that person has little positive effect (or, sometimes, a negative effect) — a good team without a ScrumMaster/coach is better than a good team with a bad ScrumMaster/coach.

Comments are closed.