Meet the Authors:

Vivian Rashotte is a digital marketer at Three Point Turn. She's a writer and a visual artist who's interested in digital strategy, brand management and creating compelling web content.

Trishan Gunness is lead developer at Three Point Turn. He shares insight on enterprise development, system design and development culture. He lives in Oakville, Ontario.

Nafeu Nasir has a versatile set of skills in graphic design and software development. He's currently pursuing a degree in Computer Science at the University of Toronto.

Anderson Hung recently graduated with a degree in mental health studies. He's a web development intern who's lending a hand with marketing projects at Three Point Turn.

How Cardboard Boxes Became Our Project Management Template

Posted on: October 23rd, 2014 by


 

software change requests version control

Well, virtual cardboard. Is that a thing yet? Digital paper is, so cardboard is probably just around the corner. Here’s what you might be interested to know: we save days of development time using a system we call Feature Stacks. It’s a project management tool that started with a handful of post-it notes and cardboard boxes, saving us hours of unnecessary rework and transition time.

The developing dilemma

Your company is creating a website. You’ve outsourced development to build it. It’s almost perfect, but for these teensy little changes. Why is your development partner pushing back?

The honest reality

Change requests can really delay a project. As an application development shop, our mobile developers really feel the sting of that last-minute amendment to the nav bar, or the reorganization of a few header titles. The breakdown comes when a client, you, pushes for those changes in the immediate future. It means revisiting existing code and making changes to elements that may not be in a condition to accept changes yet. A subtle change to your requirements could be a critical alteration to stable, functional code. That’s a pretty disruptive problem. Just a few of the issues with modifying a codebase could be:

  • There’s a hierarchy to code. Dependencies can result in changes throughout the project that were not intended. Suddenly a small change becomes a big problem.
  • Compiling code—sort of like baking a cake—is pretty permanent. Making changes to the recipe would mean un-baking that cake, and could end up looking like this.
  • The practice (or art?) of refactoring code is a smart way to boost performance in software. It clones duplicate sections of code to be reused elsewhere in the application, and it’s super difficult to reverse.
  • Software programs, websites, apps—basically anything coded—must be tested. Testing is a significant undertaking. Guess what developers need to do if changes are made to a project that’s already been tested? Yeah. (And to answer your next question, yes, probably the whole thing.)
  • Developers use frameworks. I always use the analogy of painting versus creating a collage: programming is rarely like painting, where a dev writes out code line by line, stroke by stroke. Instead, devs will use frameworks which act like pre-built sections of code that interact with each other, like gluing magazine cutouts onto an art project. Some change requests can reside outside of the abilities of those frameworks, and altering those could mean ripping off a section of magazine from your collage and starting the whole mess over again. Sticky.

Change requests are not a symptom of poor project management

No, no. I would never suggest that you refrain from making changes to a project. You can’t plan for mid-project genius, and we here at 3PT think we’re onto something: the disruption from change requests isn’t the content of the change, it’s the timing. Watch how a simple collaboration between client and developer can drastically solve many project delays, or prevent them outright. It’s either this; or learning to program, yourself.

Feature Stacks – How it works

Our project management team at Three Point Turn has battled this dilemma for years, and we may have cracked it this year with this system we use called Feature Stacks. A little demo run by our very hip PM (the same one who solved our email problem) showed us the value of bundling change requests into logical deliverables. She took a client’s long list of changes and wrote each one onto a sticky note. Then, she threw a pile of cardboard boxes onto our meeting room table. It looked like moving day.

L2_Custom-Software_new

She asked our developers to sort the sticky notes—change requests—into similar groups. Some were simple copy changes. Some were larger database alterations. A few were pretty large in scope and could seriously de-rail our delivery schedule. We ended up with three nearly-empty boxes, one full-ish box and two overflowing boxes. Yikes. “Now,” she said, “which boxes will threaten our go-live day?” Everybody pointed at the two overflowing boxes. “Right,” she continued, “so let’s complete to the other changes first. That means this box,” picking up the first overflowing box, “is our next release. Version 1.1 due in two weeks.” She squeaked ‘V1.1‘ in sharpie marker onto the side of the box. She picked up the other overflowing box, “and this will be afterwards, Version 1.2, due next month.” She wrote ‘V1.2‘ onto the second box. “Okay,” she said, “let’s get to work on what we can finish by go-live day.”

This means a significant shift in delivery. Our client is expecting changes to be resolved in the order they were requested, but that’s very different from needing those changes in the order they were requested. Remember how I said timing was the crucial fix to this problem? So we called the client. We introduced the idea of tackling these changes in a different order, a logical order. We explained that two of the groups of change requests were threatening launch day, and our PM suggested that these changes be external to this project delivery. They were kept out of scope, but not forgotten. They were scoped into a new project peripheral to the immediate one. It’s a simple version control scheme. Now here’s my favourite part, next.

The benefits of Feature Stacks are mutual

There are some pretty staggering implications for the project. This resulted in a number of benefits for the client:

  • The original project was delivered on time. Change requests are external to the original project requirements, so instead of threatening the entire project’s due date, those extra changes became bundled into their own V1.1 project, with a new due date.
  • Feature Stacks welcome change requests, instead of making developer teams run for the hills. Scope creep doesn’t scare us anymore. Go ahead, make my day.
  • There will be significant cost savings. Regardless of your cost model, fixed cost or time and materials billing, you can expect to reduce the work requirement by grouping changes into smarter deliveries.
  • Count on greater visibility over milestones. Your developer is going to need to run these new deliverables past you for sign-off. If it’s a whole new version we’re talking about, even more so.

Similar benefits aid the development team:

  • There’s a commitment to scope. No project will ever run away again; it simply becomes a multi-version project.
  • Change request tasks can be assigned properly to devs. No more scrambling for resources and switch-tasking. Monday through Friday, every task is organized and tracked.
  • Logical tasks are tackled together. All changes are completed in the same environment. Making the same kind of changes in series is so much more effective than alternating between different environments. (I have Grant, one of our developers, nodding vigorously as he reads this over my shoulder.)
  • Changes planned properly become traceable. This is a crucial step in managing testing and support for a digital product.

 

Feature Stacks at a glance:

  • Changes are bundled based on their environment and workload, not the order received, which saves time thanks to logical grouping. Developers tackle each bundle like a new deliverable.
  • Significant changes merit their own version. A PM assigns delivery dates for the new version and shares this with the client.
  • Project due dates remain unchanged for the original set of requirements. Projects can roll-out as expected.
  • Client takes development partner out for pizza with the budget they saved using Feature Stacks.

I hope this explanation helps with your next digital project. We’re all about client-vendor harmony here at Three Point Turn, so if we can help your teams implement the stacks system at your shop, give us a call or email Chris.

 

Rhys Mohun is a digital marketer at Three Point Turn. He shares insight about small business growth, marketing technology and development culture. He lives in Toronto, Canada.


Tags: , , , ,

Leave a Reply