Over a million developers have joined DZone.

The “To Do Less” List

DZone's Guide to

The “To Do Less” List

· Agile Zone
Free Resource

Learn more about how DevOps teams must adopt a more agile development process, working in parallel instead of waiting on other teams to finish their components or for resources to become available, brought to you in partnership with CA Technologies.

“Everyone tries to do too much: solve too many problems, build products with too many features. We say ‘no’ to almost everything. If you include every decent idea that comes along, you’ll just wind up with a half-assed version of your product. What you want to do is build half a product that kicks ass.” Quote from the founders of 37signals (in Taylor, W. C. Practically Radical: Not-so-Crazy Ways to Transform Your Company, Shake up Your Industry, and Challenge Yourself, 2011).

“Doing less” is a deceptive term, one that gets you thinking. While you might be put off by the phrase because the mantra in most companies is to accomplish more, doing less actually means delivering more value, more throughput, more ROI, more creativity, and being more focused.

What the quote above from 37 signals’ founders says in effect is “think more, do less.” It’s easy to think about what to put into a product, we often get suggestions from a wide variety of sources—engineers, customers, managers, executives, the janitor, and other teams. Product backlogs can grow exponentially. It’s easier to say “yes” to various stakeholders than to say “no.” One of the consistent problems with engineering organizations is too much work-in-process (WIP). Projects are undertaken because the prioritization scheme breaks down (if there is one). It’s easier to tell the VP of manufacturing that “we’re working on your project,” than “we can start on your project in 2 months when we have adequate capacity.” So projects stack up in WIP and throughput drops, sometimes drastically, because of thrashing and multi-tasking.

Each of us have a handy “To Do List”, maybe what we need is a “To Do Less List.” There would of course be some process around these lists. For example, one rule might be that for every entry on the To Do List we have to make one on the To Do Less List. A product manager might create a backlog of features to do, and another backlog of features not to do. Having an explicit list of not to do features sends a message to everyone that this list is important. Deciding not to implement a feature isn’t enough—they have a tendency to creep back on the active pile.

Similarly, you might keep a list of all the meetings you decided not to attend (this one isn’t as difficult). As you start keeping meetings to attend and meetings not to attend lists, you begin to think about and refine the criteria for each. Actually, you will begin developing these criteria for each of your dueling lists.

You could even think about celebrating your “Not Done” lists at retrospectives. Here are all the features we did; here are all the ones we didn’t do. Here are all the meetings I didn’t attend this iteration. Here are all the projects we didn’t start this month. Here are all the overhead items we pushed aside last quarter. Obviously we also celebrate what we accomplished, and that those accomplishments were sharply focused on value, on real customer solutions, and on creative ideas. By lining up both lists, we begin to see how our focus on effectiveness rather than raw productivity actually improves overall performance.

Discover the warning signs of DevOps Dysfunction and learn how to get back on the right track, brought to you in partnership with CA Technologies.


Published at DZone with permission of Jim Highsmith, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}