Agile Resource Planning: How to Start a New Project Next Monday

Problems we've had

We cannot predict the future.

This is what makes our lives exciting, but it could be also very annoying when you're forced to make a decision without sufficient information.

As an average-sized web-development agency, we strongly depend on our customers and their needs, both of which we cannot control.

How many new projects will we have next month? How many new people should we hire to work on them and what sort of experience should they have? What if we don't have new projects? What if we have the perfect project for us, but we don't have enough people to work on it? Every new sale influences our development process because each new project requires additional resources, thus generating an infinite number of questions and ad-hoc solutions.

Another problem that we struggle with is our ability to rotate people between projects painlessly and as needed (another element that is hard to predict) - including an introduction period before leaving current work and dive into a new project. In order to make this happen, we would need to free-up some resources to fill the intermediary time gap - the period between the developer's transfer of knowledge to his replacement and the moment he's fully committed and working efficiently in a new team. Where we can find these resources without causing harm to our other projects?

This leads us to the next question: if we hire a new person to work at Monterail, how do we make sure that they would feel comfortable with our work processes, guidelines and communication rules before we put them into teams? How do we make sure that we won't lose our spirit and atmosphere at some point?

With all of these questions in our heads and no answers ready, we thought:

We cannot predict the future, but we can try to be prepared for it.

Ideas we worked with

It all started from a loose, simple idea - “maybe we should have some internal group of people, working on things we never had time for and giving us the capacity to easily kick off a new project?” - that’s what we thought. It quickly became obvious that the direction was pretty good - and that’s what we started to call a buffer, or internal team. At this point we didn't realise how much effort was still in front of us to bring this draft idea to life.

As usual, there were as many ideas as participants of the discussion. Bootcamp unit, proposed by our CTO, became the strongest opponent to the initial idea - and needless to say, that was also pretty good. What he preferred was to separate newly incoming employees into an independent division and let them learn quickly with proper, strong mentoring. The last point was not covered by the initial idea and became it's strongest disadvantage.

What happened next might actually sound pretty familiar… We were scheduling one meeting after another, not being able to agree on a good, single solution, when we realized that we were just getting lost among the multiple options. In order to stop spending more and more time going around in circles, we decided to approach the problem analytically.

Again, the idea was pretty straightforward - point out the most important goals that we need to achieve and describe how each goal is fulfilled by each solution in a comparable way. Then we could score each potential plan and choose the best one - how simple it is. So we scheduled a meeting with a smaller team to make this more efficient.

We selected three ideas to compare:

• Initial Internal team solution
• Bootcamp unit
• 4-6 cycle program - repetitive training series for new employees.

We scored our ideas based on six criteria - this allowed us to easily (at least that's what we thought) type the one that fits our reality the best. We checked if a particular solution allowed us to:

• Start a new project quickly if a customer wishes so
• Ensure availability of as many seniors as possible
• Rotate someone easily to a different project (if the person asked for rotation)
• Don't force anyone to change her project (unless the person wishes so)
• Ensure proper mentoring for new employees
• Handle half-times easily

We scored them from 1 to 3, where 1 was the highest rank (first place) in a simple matrix.

Criteria	Internal team	Bootcamp unit	4-6 cycle Program
Starting a sane project next monday	1	2	3
Have a free senior available	1	3	3
Rotation - do if someone wants to	1	3	3
Rotations - not do if someone doesn't want to	3	1	2
Proper mentoring for new people	3	1	2
Handle half-times easily	1	2	3

Enthusiasts of the first, Internal team solution started rubbing their hands once we summed the results - it turned out that their preferred solution was the best ranked. But a while after that we all agreed that we didn't like the fact that it received the 3rd and lowest ranking for two very important criteria. That's when we started thinking in a bit of a different way. If we have two, comparably good ideas why not to take the best from both?

Final idea

Finally, we came up with the hybrid system, which was suppose to serve us well in the situations described in the first part of this article.

It looks pretty simple although there are some tricks in its implementation in real situations.

The first step was to create the Internal team, which included people with a set of skills usually required to start a middle-sized project as well as assign a dedicated PM to it. Apart from the usual management duties, this person was also responsible for keeping a set of skills on the Internal team sufficient enough to start an average project next Monday and request rotations if it wasn't fulfilled.

To make it possible we created an availability list with all developers on ongoing projects where the possibility of rotation wouldn't harm the project. This also became a great driver for company-wide rotations, making this process transparent and easier to implement.

What this new system inherited from the Bootcamp idea was the assumption that all new employees at Monterail should first join Internal team overseen by one of the senior developers, in order to get more familiar with our tools, guidelines and traditions. After a period spent here, they could be rotated to an existing project more smoothly. It also provides a good opportunity to get to know a new person and their strong attributes, making it easier to choose the perfect project for them.

Rotations are combined with a ghost period, the time when a fresh developer and the experienced one work together on the project in order to share knowledge about the application. This allows us to make sure everybody feels comfortable with switching their area of work.

And when the new project comes, we are always prepared for it and have the exact right team to start it without making ad-hoc rotation decisions and without influencing existing projects.

How it helps now

After multiple hours of discussing, analyzing, calculating and comparing, we managed to develop a fantastic solution for most of our former headaches. Our decision was to stick to the initial name - Internal team or iTeam as the most natural, but we also loved naming fusion results... Booternal unit was quite fancy.

Right now the team has a dedicated Project Manager, and hands full of work. They are developing applications used internally at Monterail. We use these for ordering food, buying birthday gifts for each other and planning vacations as well as evaluating our employees or writing Codetunes posts like this one! Our internal team is following Scrum with all its facilities, learning how to upgrade our processes and being a fantastic sandbox for new Project Management initiatives. A dedicated technical leader helps developers improve their skills and introduce innovative technologies.

As desired, Internal team also helps us perform rotations. No need for synchronizing changes in multiple projects with one-day precision turned rotations from nightmare into a dream. We were also able to kick-off a fresh project quickly and easily with internal team members, making our new customer even happier to work with us.

So far it's been working well in every aspect. That's why we're very enthusiastic about this idea and looking forward to further improvements. It's more than certain that the solution will be developed and changed over time once we start struggling with multiple difficulties, but that's ok. We're Agile in every aspect and ready to evolve at any time!