Simplicity in Agility

Agile project management often means keeping the team small. Larger team compositions will require larger numbers of managers, which creates greater opportunities for communication errors.

The same can be said when looking at the game a team is creating. Start with one, open level. Create the most basic of gameplay, and take the time to make that one feature as fun as possible. That should be the goal, for each sprint. Once each level is completed, use future sprints to integrate these levels together. But the gameplay, and excitement of each level, should be the starting point. Adding too much to early sprints will set the project up for failure.

Realizing changes later in the project can cause a bottleneck of problems. One minor change, in a section of code, might require a series of changes in other areas, in order to stabilize the game.

When considering the team comps, consider "pairs" for each task. The reason this works well, is the two mindsets focused on one task. When the pair of team members can work in sync, they test each other's strengths and weaknesses, and compliment them. One can work on a particular part, while the other tests their work, to find bugs, and vise versa. This only works, however, if the two people are working in sync. Adding more people can cause communication concerns, as described earlier. Putting two people that don't work well, together, can cause unwarranted problems, and lead to bottlenecks in production.

When looking at who to pair, always consider keeping the alpha workers together. Veteran employees work at an extremely fast rate, and while it seems like a good idea, for them to train new employees, they will ultimately be slowed down, and lose productivity. Median employees, that aren't impacted as much by untrained members, are the best solution to train and build the new employees, while not losing much productivity.