When we looked at potential areas of improvement for our R&D (research and development) teams to tackle in 2021, project planning and commitments were high on the list. Our previous planning processes were quite decentralized and lacked definition. Too loosey goosey in some ways. Disproportionate to the scale and complexity Canvas had reached. We had people working hard and building cool things, but we needed to get more predictable. So we decided to tidy things up a bit.
We can’t talk about quarterly planning without establishing some context for how software projects are planned. There’s a truth about estimating large software projects that I think is lost on most people except when they’re asking why something is delayed: It’s really hard to give precisely accurate estimates and virtually all software companies struggle with it truly stink at it. There are good and interesting reasons for that, but suffice it to say that the larger the project and the longer the timeline, the higher the stakes and the worse the estimations get. Waterfall development attempts to get around this by perfectly defining projects up front, but it turns out that perfect definition is a mirage in complex software development, which is why basically all software companies use some more agile methodology—with more or less success.
Okay, so why do you care? You care because we make roadmaps based on what teams say they can accomplish, and then we share those roadmaps, and then you make plans based on them. The shift that we’ve made for now is to publicly drop the illusion of specificity in long-range planning. Instead of “your estimates put us at a May release,” we’ve shifted toward “your estimates put us at a Q2 release.” That wiggle room comes with the expectation internally that we’re correct in those estimations at least 90 percent of the time across R&D.
To accomplish this plan, roughly halfway through each quarter, we start the process of R&D teams committing to deliverables for the following quarter. That means designs and requirements are final enough for some chunk of work that a team can commit to releasing it by the end of the following quarter while taking into account things like peak period fires, release freezes, vacation time, misadventures with dragons, and the long ride from code commit through beta and release notes to production.
On my team, that process usually looks something like this:
This is an illustration of my engineers and me looking over a design at what we want to do, and very quickly creating tasks and estimates for our upcoming project to incorporate Pace Plans in Canvas. The number 13 here basically means "not sure...it's hard...we'll want to break this down more," the number 3 here basically means "we know what we need to do and it's not that complex or time consuming." We add up those estimates, apply a multiplier, and then sanity check it with the team to figure out if people feel comfortable committing, and then we do it!
There are a couple of efforts happening simultaneously that help us feel more comfortable with this quarterly approach to planning and communicating.
First, we’re standardizing our release definitions and practices to reduce unwelcome surprises that result from the work we do. This theme includes stuff like not locking on changes during peak period (fall start in the Northern Hemisphere), defining expectations around feature previews in active development, and gathering feedback from admins about how they learn about changes to Canvas. (These topics all deserve separate blog posts.)
Second, because you still want to understand what’s coming in the future, we’ll be leaning much more heavily on feature user groups than we have before. These provide you with the opportunity to play with stuff in active development, and they provide us with the opportunity to get feedback and engage directly with the community.
In the end, we want your experience of Canvas releases to be more controlled and streamlined through:
- Release notes (most immediate concern, most read, least surprising)
- Community roadmap (less immediate concern, most on the radar)
- User groups (least immediate concern, most exploratory)
If you find this interesting, stay tuned for more updates soon about how we plan and release stuff!
The content in this blog is over six months old, and the comments are closed. For the most recent product updates and discussions, you're encouraged to explore newer posts from Instructure's Product Managers.