Posts

Improve the efficiency of your software development team with the RICE framework. Learn more at the upcoming APIStrat conference in Portland, Oregon.

The Developer Experience team at SendGrid is a small, but mighty force of two. We attempt to tackle every problem that we can get our hands on. This often means that some items get left behind.  At the outset, we surveyed everything that was going on in our open source libraries and we quickly realized that we needed to find a way to prioritize what we were going to work on. Luckily, our team lives, organizationally, on the Product Management team, and we had just received a gentle nudge and training on the RICE prioritization framework.

On our company blog, I wrote an article about how employing this framework, using a spreadsheet, helped us double our velocity as a team within the first sprint. Our development velocity doubled because the most impactful things for the time spent are not always the biggest things, but the biggest things tend to attract the most attention due to their size.

What is RICE?

RICE as an acronym stands for Reach x Impact x Confidence, all divided by Effort. This calculation allows you to get a score that weighs the following. Some of the definitions we use are a slight departure from Intercom’s original version, but this has been very effective for us!

The calculation:

Reach * Impact * Confidence

————————————–

               Effort

This gives us a score for every item in our list. Then, we sort our list in descending order by score. We realized, once we had a sorted list, that we accidentally made a Kanban backlog. We worked from the top of the list, keeping work in progress (WIP) to as much of a minimum as possible. WIP can be tough with open source, because we often have 20-30 issues waiting for a community member response. These items sit at the top of our backlog, and we look into them at the start of every day in the hope that we can clear them out of our WIP category.

Lessons Learned

Reach – The number of customers this will affect

One thing we learned about using RICE is making sure that we use consistent numbers for each of the variables in the calculation. It was very tempting for us, an email company, to use the “number of emails” sent as the Reach parameter. This worked until we started trying to evaluate tasks that didn’t have anything to do with our v3/mail/send endpoint. We eventually settled on number of customers using this library for this purpose”, calculating API user count and mail user count for the Reach.

Impact – A measure of the effect completing this project will have

It is easy to assume that every single item is a high or massive priority. It looks nice, gives you an ego boost, and totally messes up everything in your ranking system. Be honest with yourself about what is on your list. If things don’t really seem to be in the right place in your list (more on this below) then look at impact, because it’s probably artificially high, especially in context of the items around it in the list.

Confidence – How confident are we that we can sit down and complete this task today

We use a text-based selection from the list: None, Minimal, Low, Medium, High, and “with my eyes closed”.  These each translate into specific numbers for the calculation.

Effort – The number of story points will this take to complete

We use story points because this approach allows us to figure out the calendar length of a task rather than the aggregate of specific amounts of time spent on the task. To be more specific, this is the difference between “It’s going to take 3 hours” and “It will only take 3 hours of work, but it won’t be finished until Friday.” This is an easy trap to fall into, because new projects are exciting and we want to jump in and knock them out. That doesn’t mean that we can actually get a project that “will only take a couple days” done within the same month we started it. Life happens, your velocity calculation accounts for that — especially if you use an average over the last year (get out yer agile pitchforks!).

Letting the backlog win

We have learned the hard way with projects we really want to work on right now, that they are not always the right project at the moment. It is important to have confidence in the calculation and take the assumption that it is correct. That is, until you are looking at the list and realize that “Hey, item 15 really should be item 5. What’s going on here?” Look at your list in context of the other items, does the order feel correct? If not, why not?

We ended up using RICE as the baseline calculation for everything we do, but it is not the end-all. We added in calculation modifiers for company priority, due dates, and status — because something the executives have on the company roadmap, that has to be done in Q3, should be worked on right away. And, because we are using Kanban, the status of an item is important. Once you start something, it should stay at the top of the list until it is done, or you decide it is no longer necessary to complete it. Getting WIP completed, rather than backed up, is a good way to see the impact of your work and get a sense of accomplishment for yourself and your development team.

Matt Bernier is the Developer Experience Product Manager at SendGrid, where he spends most of his time digging into customer feedback in order to provide a World Class Experience for Developers with SendGrid.

Learn more in Matt Bernier’s talk — How We Doubled the Velocity of Our Developer Experience Team — at the APIStrat conference coming up Oct. 31 to Nov. 2 in Portland, Oregon.

 

Concepts such as decentralizing strategy, delegating direction, and fierce transparency in communication are part of the backbone of successful open source projects. In my presentation at Open Source Summit EU in Prague, I will explore how these concepts are not only applicable to volunteer-run organizations but can also help growing corporations avoid some of the coordination overhead that often comes with growing teams and organizations.

We’ll look at some of the key aspects of how project members collaborate at The Apache Software Foundation (ASF). After that, we’ll take a closer look at German FinTech company Europace AG, which decided to move toward self-organization two years ago. We’ll highlight parallels between Europace AG’s organizing approaches and those of open source projects.

Let’s start with some of the core values of ASF projects.

Community over Code

One main principle is the concept of “community over code” — which means that without a diverse and healthy team of contributors to a project, there is no project. It puts the team front and center, as highlighted in the Apache project maturity model.

Meritocracy

Another core value to Apache projects is meritocracy — essentially meaning that there is no governance by fiat. There is no way to simply buy influence into projects — you have to invest time to gain influence. This directly translates to frequently given advice for how to get started with any given project: Focus on the things you are using yourself and fix what bothers you most essentially following a scratch your own itch kind of model. There is one level of indirection here: Committers and contributors can be paid either by their employers or as part of a consulting gig to increase their motivation to work on the topics that you are interested in.

Project independence

Be aware though that there is a strong principle of people participating as individuals on projects. That level of independence means that within an Apache project, there is no way to assign tasks to project members. Apache projects by design have a very flat organization with barely any hierarchy: Titles like Project Management Committee Chair (PMC Chair) are famous for coming with additional responsibility but no entitlement to task assignment. That means projects need a process for aligning people with potentially very diverse interests and itches to scratch. A key ingredient to coming up with workable decisions is making project goals and needs public and transparent — both in terms of asking for help and in showing appreciation and rewarding contributions that help the project. Another one can be found in an approach to integrating differing opinions and arguments in a “Yes, and” instead of a “Yes, but” fashion. This plays together very closely with the next concept.

Full transparency in open source projects

“What didn’t happen on the mailing list, didn’t happen” is one of the mantras for those involved with Apache projects. A high level of transparency is what makes Apache projects so easy to participate in across boundaries — whether they are geographic, corporate, or other. At Apache, mailing lists are treated as the point of reference for any decisions made. Thus, there is full transparency into the historic record of all open source projects.

Of course, with that entirely open and transparent model comes responsibility: A lot of decisions can be taken in the open. People tend to show better behavior when under public scrutiny. However, discussions involving interpersonal issues are best kept out of public sight. This is particularly important in a digital age where deleting statements made online and mirrored worldwide is pretty much impossible.

Project autonomy

Technologically, Apache projects are very diverse. However, when unified under one organization with a common focus on community, meritocracy, and communication patterns, there is a lot of freedom and decentralized decision making.

One important piece in growing the ASF as a whole was giving autonomy to each project. Still there are a couple topics that each project has to deal with: It’s great having one central entity answering questions on, for example. trademarks, licensing, or software patents. However, these entities controlling each of the 300 or so top level open source projects won’t scale. Instead, Foundation-level services serve as guidelines for Apache open source projects to manage their own activities in these areas. As a result, each project is supposed to have some people knowledgeable in those topics.

Open source patterns in the enterprise

In the past decade, people in the open source space have successfully brought several of these concepts to their respective employers — either in the form of open development, inner source, or open organizations. Meanwhile, ideas of transforming traditional hierarchical organizations into self-organized, open organizations found their way into concepts like sociocracy and holacracy.

Europace AG decided to move toward self-organization roughly two years ago. Looking at what was established during these two years, we see quite a few similarities to how nonprofits such as the Apache Software Foundation and The Linux Foundation work with open source projects:

Decentralization and autonomy

Europace AG is a tech company experienced with XP and Scrum, and in 2015, they began a journey toward self-organization, looking into holacracy and sociocracy frameworks. Organizationally, there are roughly 200 people split into four fairly autonomous technical units, each one of which is responsible for one business product of the company. Units are autonomous in how they self-organize: Some chose fairly standard Scrum-based software development in iterations and standard rituals. Others went for sociocratic or holacratic models. By organizing in circles, employees are given more influence over how decisions are made that affect their daily work. Backing for this level of autonomy can be found in the company’s own principles, where self-organization and decentralization are outlined as one of the four important values and are actively supported by the board.

This is not unlike Apache, where open source projects operate independently and autonomously in how they develop their software and self-organize (that is, provided they make sure that project governance remains independent of one single player, security issues are being dealt with, and legalities like licensing, patent issues, and trademarks are taken care of).

Transparent decision making

Everyone working for and with Europace AG is located in one timezone, and Europace AG itself has only one site. Nonetheless, there are good reasons to look at how decisions are made in distributed open source projects: Establishing a remote friendly communication model can help support employees with family, and deal with long commute distances. Apart from these obvious benefits, there are a few effects that aren’t quite obvious:

While an asynchronous communication model won’t lead to decisions happening faster, it can help with reducing the amount of interruptions caused by face-to-face meetings: By sharing a proposal before the actual meeting happens and providing a means to exchange ideas around that proposal can help with understanding people’s opinions, issues and suggestions with respect to the proposal. It can help with making that understanding transparent to everyone interested in the topic up front. Combined with a “Yes, and” philosophy, this can help form consent in the team quickly.

Organizational Groups

Splitting roughly 200 employees into just four units creates groups that are bigger than typical “2 pizza sized teams” often deemed ideal for software development teams. As a result, each unit had to figure out how to create sub-groups that can work well as teams.

A common approach was to create cross-functional feature teams, comprising both software developers and people familiar with financial domain (and people with backgrounds in data analytics, UX, etc. as needed). Those are called feature teams in anticipation of the fact that they aren’t necessarily particularly stable: Each week, there is a check point people can use to decide to change feature teams depending on where they are needed most. Decisions related to governance as well as product strategic aspects are delegated to the team itself. As a result, team members need a good understanding of the current product direction in terms of features and usage.

For tasks and topics that tend to fall under the general topic of “organizational operations” or “decision making with dependencies,” people organize themselves in circles, which are essentially groups of people interested in participating in making a decision related to a specific topic. Despite a lot of communication still happening face to face, some circles also set up a Slack channel that is open for all to join and participate. This level of transparency is crucial in elevating trust people have in those decisions.

Each of these circles can come with dedicated roles: Secretary being the one taking over meeting minute creation, a Lead Link making sure that “things will actually get done” and communicated to the people needing the respective information. While people can volunteer for these roles, at the end of the day these roles get filled through nomination by the team. This is not unlike Apache projects where new committers, PMC members, and even Foundation members are elected after nomination. On one hand, this kind of model shows a certain amount of appreciation for the work these people are doing. On the other, it helps with promoting people into these roles who according to their own self-assessment might not have confidence to take on the role.

Put the human first 

Much like Apache puts community development front and center with its open source projects, Europace AG puts team collaboration into a central position. This means that each employee is responsible for raising issues with team climate, and they are supported by a team of professional coaches, moderators, and mediators with a deep understanding of human communication.

Conclusion

When moving toward self-organization, corporations can learn a lot from how open source projects organize themselves. Europace AG is on the journey toward moving more power away from traditional formal structures, making it available for the people in purpose-driven, circle-based organization. It will be interesting to watch how Open Source project management, governance, and communication patterns can be applied within corporate contexts.

Isabel Drost-Fromm is Open Source Strategist at Europace AG Germany. She is a member of the Apache Software Foundation, co-founder of Apache Mahout and has mentored several incubating projects. Isabel is interested in all things FOSS, search and text mining with a decent machine learning background.

At the recent Open Networking Summit, the SDN/NFV community convened in Santa Clara to share, learn, collaborate, and network about one of the most pervasive industry transformations of our time.

This year’s theme at ONS was “Harmonize, Harness, and Consume,” representing a significant turning point as network operators spanning telecommunications, cable, enterprise, cloud, and the research community renew their efforts to redefine the network architecture.

Widespread new technology adoption takes years to succeed, and requires close collaboration among those producing network technology and those consuming it. Traditionally, standards development organizations (SDOs) have played a critical role in offering a forum for discussion and debate, and well-established processes for systematically standardizing and verifying new technologies.

Introduction of largely software (vs. hardware) functionality necessitates a rethinking of the conventional technology adoption lifecycle. In a software driven world, it is infeasible to define a priori complex reference architectures and software platforms without a more iterative approach. As a result, industry has been increasingly turning to open source communities for implementation expertise and feedback.

In this new world order, closer collaboration among the SDOs, industry groups, and open source projects is needed to capitalize upon each constituent’s strengths:

  • SDOs provide operational expertise and well-defined processes for technology definition, standardization, and validation
  • Industry groups offer innovative partnerships between network operators and their vendors to establish open reference architectures that are guiding the future of the industry
  • Open source projects provide technology development expertise and infrastructure that are guided by end-user use cases, priorities, and requirements

Traditionally each of these groups operates relatively autonomously, liaising formally and informally primarily for knowledge sharing.

Moving ahead, close coordination is essential to better align individual organizations objectives, priorities, and plans. SDN/NFV are far too pervasive for any single group to own or drive. As a result, the goal is to capitalize upon the unique strengths of each to accelerate technology adoption.

It is in the spirit of such harmonization that The Linux Foundation is pleased to unveil an industry-wide call to action to achieve this goal.

As a first step, we are issuing a white paper, “Harmonizing Open Source and Standards in the Telecom World,” to outline the key concepts, and invite an unprecedented collaboration among the SDOs, open source projects, and industry groups that each play a vital role in the establishment of a sustainable ecosystem which is essential for success.

The introduction of The Linux Foundation Open Network Automation Platform (ONAP) is a tangible step in the direction of harmonization, not only merging OPEN-O and the open source ECOMP communities, but also establishing a platform that by its nature as an orchestration and automation platform, must inherently integrate with a diverse set of standards, open source projects, and reference architectures.

We invite all in the community to participate in the process, in a neutral environment, where the incentives for all are to work together vs. pursue their own paths.

Join us to usher in a new era of collaboration and convergence to reshape the future.

Download the Whitepaper