Featured in
Architecture & Design

Mini-talks: The Machine Intelligence Landscape: A Venture Capital Perspective by David Beyer. The future of global, trustless transactions on the largest graph: blockchain by Olaf Carlson-Wee. Algorithms for Anti-Money Laundering by Richard Minerich.

Featured in
Process & Practices

In-App Subscriptions Made Easy

There are various types of subscriptions: recurring, non-recurring, free-trial periods, various billing cycles and any possible billing variation one can imagine. But with lack of information online, you might discover that mobile subscriptions behave differently from what you expected. This article will make your life somewhat easier when addressing an in-app subscriptions implementation.

Featured in
Operations & Infrastructure

Mini-talks: The Machine Intelligence Landscape: A Venture Capital Perspective by David Beyer. The future of global, trustless transactions on the largest graph: blockchain by Olaf Carlson-Wee. Algorithms for Anti-Money Laundering by Richard Minerich.

Featured in
Enterprise Architecture

Mini-talks: The Machine Intelligence Landscape: A Venture Capital Perspective by David Beyer. The future of global, trustless transactions on the largest graph: blockchain by Olaf Carlson-Wee. Algorithms for Anti-Money Laundering by Richard Minerich.

Retrospective of Retrospectives

Once all your teams use Agile and are implementing local improvements, what happens to the larger organization formerly called "IT" or "Systems Development"? A coach with a large Agile program shared the strategy they designed to let the larger community spot trends and benefit from all this learning. ThoughtWorks' Paulo Caroli calls it "Retrospective of Retrospectives". As always with large programs, there are tradeoffs to be considered.

Feedback is a cornerstone of Agile approaches to software development. It's the important pause teams regularly take to "inspect-and-adapt," to watch for and respond to red flags in their processes and products, and to spot opportunities that might otherwise slip by in the rush of delivery. ThoughtWorks' Paulo Caroli noticed, in his program of a dozen 15-person teams, that while improvements were being made at a team level, the overall program was losing focus on continuous improvement.

At times, the action point from one team’s retrospective was dependent on other teams. At other times, two team retrospective action points were contradictory.

Another challenge the program faced was that program level management had no window into issues and improvements. "The program manager (and other people) would like to attend each team retrospective; but it was just not possible to be at several meeting at the same time."

Similarly to how the daily scrum is extended to the Scrum of Scrums ... I came up with the idea of having a Retrospective of Retrospectives for large Agile teams. ...the RoR context is: "What can we do as one team (the whole program team) to improve the overall output for the program?"

The RoR participants include representatives of all team and of the program, including each team's manager and one other team member (this last is recommended, possibly on a rotating basis). His writeup indicates no participation by Product Management, but this may be buried in the role names used. The meeting's starting point is the top 5 items from each team's retrospective. Repetition is eliminated and the results are voted upon (presumably to determine order of discussion).

Here we run into the catch-22 of large programs: yes, it's difficult for the managers to get around to all the teams in person. So, the teams come to the managers. This many-to-many meeting then presumably becomes much larger than the Agile-recommended small group, and facilitation would need to compensate for the loss of intimacy in this meeting, in comparison to a regular retrospective.

Key benefits noted by Caroli include:

all managers and stake holders have visibility on the top items for each individual team.

all this is available in only one meeting.

common goal: all attendees are periodically talking and acting on the overall goal of the program.

everyone is heard – Any local team problem will be heard by all the teams.

This list raises the question: what happens to retrospective confidentiality, here? With this scheme, expectation setting would have to be done at the team level, knowing that it could potentially influence the dynamics of future team retrospectives. Would team members still be willing to delve into touchy topics, knowing that non-team members (without team context) would hear the results? In a high-trust, high integrity organization the benefits of this scheme might outweigh the risks.

Sort of off-topic (applying the RoR concept across a Whole Company?)...
by
Stephen Starkey

Has anyone experimented with using the Retrospective approach (and this Retrospective of Retrospectives is very relevant to what I'm talking about) in a larger context? The author talks about keeping the Tech Systems agile, but what about the rest of a company that isn't necessarily wholly technologically focused?

For example: a financial services firm (sort of like what I'm dealing with) struggles with remaining nimble in all aspects of business, some of them technological, others very much not. I've been playing with using Retrospectives to work out overall cultural issues by breaking each division into its own retrospective and then "rolling up" the results of that retrospective that are cultural in nature (as in: intra-unit concerns) into a larger retrospective to be held semi-annually or even quarterly.

The issue I'm having is in selling the idea of a Retrospective to senior management as a Good Idea (I can see parts of even the Agile Retrospectives book that work well in any arena) for overall cultural improvements. After all, any activity you can do with a bunch of programmers/analysts/etc. can probably work with lawyers, accountants, and so on, right? Well, notwithstanding strange personality quirks, power struggles, etc.

I know.. it's radical and possibly (*gasp*) democratic, but I wonder if other folks have this experience? It all assumes a fairly flat organization (which we strive for here), but I'm also considering trying to use it as a vehicle for "democratizing" the company slowly from the grass-roots.

The team retrospectives should be a safe zone to "put it all on the table" so to speak. That means that the team members' boss(es) should not be present in the retrospective. Like it or not, most people behave differently around the boss, even if the boss is awesome.

I would think that an effective way to structure the RoR, would be to shuffle all teams' retrospective feedback into one list. To preserve anonymity, the items on the list should be disassociated from team identities. Then, the RoR meeting could be held with management and perhaps representatives from each team to identify trends and plan action items.

we use on person (a scrum master on one of the teams) to facilitate all retrospectives. He then acts as the 'knowledge bridge' and should be able to see any issues across the teams and can act upon them. Effective, non-bureaucratic, less meetings. This is kind of like described by Henrik Kniberg: www.infoq.com/minibooks/scrum-xp-from-the-trenches

Re: Sort of off-topic (applying the RoR concept across a Whole Company?)...
by
Deborah Hartmann

Hi Stephen.

I have used Retrospective techniques with management. Here, I found the mix of management and other roles very useful - parties were astonished to discover the very different perceptions held by people in different roles in the organization!

In one instance in particular: top level leaders were shocked and dismayed at how their actions were (mis-?) perceived by software developers. More transparent and clear communication ensued, and doors were opened for developers to offer feedback to upper management.

Yes, retrospectives can be powerful at many levels, from personal introspection to organizational introspection. In an organization, though, be sure to set expectations: these techniques will surface things not currently talked about. Are they willing/ready to deal with these?

And, stick around to help deal with the chaos that ensues, if you can. Out of chaos can come many good things. But people may need help at first, not to fall back into CYA and defensiveness.

I share your concerns about respecting team integrity and the effect of bosses' involvement. This should be thought through carefully, realistically, in the context of the given organization's culture. Don't be optimistic here - be realistic. Retrospectives are provocative and can bring out people's reflex responses, not just their best selves.

A simple way to allay the fears of team about managers hearing "dirty laundry" is to put the control back in the hands of the team. As part of Closing the Retrospective, ask the team which bits they want communicated into the RofR (and possibly, on which ones they'd like to apply "Vegas rules"). The team member who participates in the RofR has the responsibility to disclose only what has been team-approved.

However, like Deborah, I'd counsel caution about using this approach in a fear-driven organizational culture.

Also, the RofR might be the occasion to bring in a retrospective facilitator who has broad experience managing larger groups with more perspectives. The RofR is more akin to the end of project retrospectives that look across a wider spectrum of what it takes to get the software out the door, and as such, is a more complex meeting to lead.