We’ve all had the experience of thinking about all the things we need to get done, spinning through them in our heads, wondering how we’ll get them done and making headway on none.
We’ve also all had the experience of making to-do lists and cranking through the items one by one, satisfyingly checking them off the list as we complete them. When we get in a flow, we move quickly and fluidly from one item to the next, and feel sooo productive, with so much progress to show. The second scenario is a lot better. When in doubt, do something.
The second scenario was better because we prioritized what we were going to do, based on urgency, easiness, bigness, you name it. Point is we prioritized and then started to make immediate tangible progress. You can’t do everything at the same time, so you have to choose what to do first, what to do second, etc. If you don’t make those choices, you don’t get things done. This is true of everything we do, including developing software. The way to be truly productive is to have a clear priority order of what you need to get done, tackle the first project, deliver it, tackle the next, deliver it, and so on. This is the heart of Lean: limit the work in progress to match the actual capacity of the team (or factory), and deliver small batches completely to the customer before moving on to the next. Not only does breaking things down into small batches (that are delivered completely) measurably improve productivity, but it feels good too.
In addition to prioritizing the projects we need to deliver, we need to prioritize the goals we are working towards with the project. In project management, there is a concept called the Iron Triangle that states that you can choose to fix any two of the three corners of the triangle and the third must be allowed to flex, capturing the uncertainty of the project. Some people say the three sides of the triangle are Resources (people working on the project), Scope (set of features to be delivered), and Schedule (time to deliver), taking Quality as a fixed. Others say they are Quality, Scope, and Schedule, taking Resources as fixed. I think this discord shows that it should actually be an Iron Rectangle, with Resources, Quality, Scope, and Schedule as the 4 corners.
Whether triangle or rectangle, I believe that we should take resources as fixed, for a couple reasons. The Mythical Man Month showed us that there is an optimal resource set for each project. Too many resources actually slows a project down. Too few also slows it down and will violate the Lean principle of limiting work in progress because the extra resources will start on another project and we’ll have two projects that are half-baked, instead of one that is awesome.
The other reason I want to treat resources as fixed is that the concept is complex, resources themselves having several dimensions: team size, skills mix, talent/experience level, team dynamics, co-location, etc. I firmly believe that every project should be optimally resourced with a 'dream team' of the right size skills mix, experience, etc, to match the needs of the project. Having a sub-optimal team size will not only affect Schedule, but will also affect Quality, as teams that are too small tend to cut corners, and teams that are too large tend to introduce fragilizing complexity. Of course resources will not be literally completely fixed as we may discover in the course of a project an unanticipated skill and need to add that to the mix, for example.
So, given fixed resources, we have Quality, Schedule, and Scope as the corners of our triangle, and we have to choose which ones to put most emphasis on, and which to let flex. My view on this is that the ranking should be:
1. Quality — Quality is job one, and without it, nothing else matters. Quality needs to be well defined for each project so that the team can treat it as a binary: they hit the bar or they didn’t.
2. Schedule — Schedule comes next, because we should be delivering small completed batches all the way to customers as frequently as we can. If we let schedule slip, we risk a project that never gets out the door and ultimately fails. Schedule slipping makes a project vulnerable to scope creep, and we get a vicious cycle of non-delivery and frustration.
3. Scope — Scope is the one we should let flex. If we can’t hit our quality or our schedule with the
scope we have, then best to hold some features back, deliver what we have -- excellently -- and
then get the extra features in the next cycle/sprint.
Leave a Reply.
Philip Brittan is the General Partner of Crazy Peak LLC
Copyright (c) 2016 Crazy Peak LLC