Using Shape Up in Project Management

This last year I've been leading a software development team on a large project. As the project manager, I started to run into the classic issues, tools, questions like many people before me.

I learned about the different types of projects: waterfall (you plan every step of the project ahead of time) vs. agile (you plan the next 2-3 weeks to allow future priorities to shift).

One risk with agile is that you might never feel a sense of completion. This is especially true in the software world: the list of things that could/should be done continues to grow. Especially as you launch incremental updates which spawn new feedback and ideas.

Then there's tracking a project. In agile the two main ones are Scrum (planning meets to start/end each cycle and daily 15-minute check-ins: What did you do? What will you do? Any barriers?) and KanBan (a list of tasks in at least 3 columns: todo->doing->done).

For my project, I went towards agile. Tracking on a KanBan board, longer Scrum meetings on Monday, shorter the rest of the week. We aim for 15 minutes on the short days but often go longer as they turn into work sessions (the team is small enough it's OK).

But along the way, I ran into a couple of issues:

1. How do you focus on the current cycle, yet keep your eye on the overall project?
2. How can you set an overall goal for a completion date when only the most recent steps are planned?
3. As the team gets bigger, more tasks need to be created, tracked, talked about, etc. How do you stay sane?

I reached out to a couple of successful project managers and the answer was: it's a lot of work to do it right. Plus, I need to add some elements of the waterfall back in. I didn’t need to detail every task along the way, but I do need to make time estimates of the larger blocks of work, and put them all on a calendar to see where the timeline ends. As work gets more detailed and progress happens, adjust the timeline and/or adjust the scope of the project (depending on your constraints).

It turns out I'm not great at estimating time because every week we were pushing deadlines out another week(!) because everything was taking longer. It got to a point where I stopped referencing the calendar because it was no longer near (by months!) the original aspirational launch date. Instead, we went back to asking, "Is this a must-have? Yes? OK, let's build it, and it'll be done when it's done."

This made sense when we were building the first iteration of the product. And since we intended to charge, the quality of the product and it features were important, and our appetite for funding the project was 2-3 times the original budget (it's said: work expands to fill the time given, apparently that's also true of budgets and money).

But as we prepared to launch, the nature of the work began to change. For starters, the backend part development still had "must-haves," but the frontend was starting on some "nice-to-haves." But then those nice-to-haves starting adding tasks to the backend. Ops. I didn't do a good enough job of catching those. How do you keep a project in balance when the majority of the work is either frontend or backend? One answer is to only hire people who can handle both. Not super realistic at this point. Avoid unbalanced projects and instead, aim for ones with equal work? Maybe. Hire more of one type of developer? The answer, it seems, is a little bit of yes of each.

A book I just finished, called "Shape Up" by Ryan Singer at Basecamp helped answer a few of those questions for ongoing projects. You can read it for free online: https://basecamp.com/shapeup

For starters, spend time shaping a project: what's the problem you're solving, the solution's scope, and the general functionality. Basically, get it to the point that a designer and developer would feel comfortable getting to work. This is an area I've been lax at. I tend to be too general about the directions. Or, don't thoroughly think through what needs to happen.

They recommend 6-week cycles. So, the project I shape needs to be able to be completed in 6-weeks. If it's a larger project, I need to figure out how to break it down into smaller, shippable in 6-weeks, chunks.

At the end of the 6-weeks, either the project ships or is canceled. That's the right, the deadline is the hard stop. It means something went wrong if you can't ship yet: maybe the scope was too much, or something was harder than expected. Either way, they recommend stopping and going back to evaluate what happened. While you evaluate, the team works on something else during the next 6-week cycle. Real consequences that everyone feels.

The nice part about 6-weeks is that it's long enough to create something meaningful, but not so long you risk a lot of time if something doesn't work out. It does a better job of spacing out the bigger planning meetings and lets the team manage the smaller tasks however they like.

(BTW, their hiring principle is to hire people who are smart and get work done. That alone solves a lot of issues!)

Another mindset I like from the book was deciding when to stop. Often we compare to the ideal product that's in our heads or on our roadmap. This can be demotivating because it's unlikely the product will ever achieve the ideal at all (let alone on time and on budget). Instead, compare to the baseline. What are customers currently doing to solve the problem? Does this project/product make it easier? If so, it's a success and move on. It keeps the focus on the customer and makes it easier to stomach removing features from the scope if time gets tight.

The book is worth reading if you're managing projects. I've already started shaping/scoping projects at a better level per their recommendations. I plan to shift our team to longer project cycles, and (this will be hard, so it won't happen right away) making the deadlines, not the ideal features, the hard stopping point. It'll provide us a level of accountability we don't currently have. I do plan to continue to track things on a KanBan board and still hold Scrum meetings.

I think it'll work particularly well with a product we're selling. Since people are already buying it, we won't feel as compelled to say, "but we have to build this no matter how long it takes. Otherwise, people won't buy it."

Then all that remains is the hardest part, which all project styles recommend, and I seem completely incapable of doing: is not adding anything else to the development team’s plate during a cycle.