How we kept the project management to a minimum.

Scrum or Kanban? Trello, Redmine, Google Docs? A detailed plan or some shots in the dark?

Right after the idea of pooling was born and moulded into a brief concept I was confronted with the question of how the time for planning etc. could be reduced to an absolute minimum. And how could we estimate the efforts while doing so.

We did research, and pretty much all the details on the job.

This gave us the benefit of being able to start right away after our boss gave us the “go” and not wasting any time with the “ifs” and “buts“ and reaching actionable results incredibly fast.

We took care of the details when they mattered. Which means when we wanted to built them.

A crude roadmap was our beginning.

We set up a simple Excel as our production plan. It had a x- and y-axis. The y-axis listed all features we were planning to built, separated into the different parts of the product like API etc. The x-axis showed the order in which we were planning to implement them so we could see the correlation between them.

Our goal wasn’t to estimate any due-dates with this. This wouldn’t have made sense anyway because we have other project obligations besides pooling.io at ion2s.

No our goal was simply to keep track of the progress and see if any changes in our plan could backfire or stop the progress. But there was another benefit. Due to the roadmap we were able to roughly estimate the time needed to realize the project.

We did that as a Google Spreadsheet by the way.

The advantage was crystal clear. Everybody could work on it, we could work asynchronously as well as synchronously and leave comments for others.

Plannings in Trello

After we had the allowance for the project plan we started to plan the details. Each week.

Only for that week. That’s it. Not more.

We only took the parts of the plan that would fit into the week of our development-team and discussed further details for the first time then. Whether to use this or that UI-Pattern for this certain feature.

Before that we also decided what tool to use for our plannings. We picked trello because we wanted to have a simple tool that is not overpowered, free and nice to use.

We used pivotal tracker before, which I personally like. But we wanted to try something different this time and see how far we could come without paying.In pivotal you hit a paywall pretty fast.

We use redmine in our company as well. But I see it as a ticketing-system and not really a tool for planning. Also we didn’t want to spend time on any customization-efforts. And without that it is a pain in the ass if you are going to work collaboratively. Besides not being the fastest and easiest tool out there.

Scrum + Kanban = Scrumban

As mentioned before we chose trello and sprints. But we neither chose scrum or kanban.

I would rather say that we combined the two and ended up with scumban. Here is a short break down of how we did it.

  • Sprints went on for a week max. If the team needed more time they got more time. (I think every scrum-evangelic would shoot me for that)
  • No plannings: the team did all that stuff themselves. They prepared their own trello-cards for every sprint and followed along the project plan.
  • A review-re-planning-retro-meeting. We did all that in ONE meeting. (Now I am certain scrummers would shoot me) that almost never took longer than an hour. They showed me the results and after that we shortly discussed what we were building in the next sprint.
  • I decided when we would present our work to our CEO.

Long story short. We saved A LOT of time. The team was really happy because they could work autonomously and weren’t micro-managed.

And if something needed talk…

We still faced phases in our project that forced us to hit the breaks here and there.

One time we had to make some changes to our initial concept the other day we added something to our plan or we had a new idea that got us excited. Sometimes we did that stuff in a real meeting and other times we just had a brief talk while making coffee. But we had the time to do so thanks to our really lean approach.

Conclusion

The described approach is the perfect fit for us. We still identify things that we can shorten here and there and that is fine too. But we have to admit that we are basically our own client currently and have no other stakeholders to deal with than ourselves. Sometimes we weren’t as fast as planned due to client work that we still had to manage besides our own endeavours.

If I were about to manage a product design team for a client we would spend some more time on estimating the overall efforts of course to get a more precise outlook and to identify possible roadblocks or white spots within. But honestly I would still try to keep all that pretty marginal as well to keep things agile. I am aware that our approach might be not ideal for client-work at all but if we will develop another product for ourselves I’d probably handle that matter with a similar approach.

Thank you for reading this and if you have any thoughts on that topic feel free to leave a comment.

Show your support

Clapping shows how much you appreciated Arne Cornelius’s story.