top of page

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.

6 views0 comments

Recent Posts

See All

Thinking back, on the time I have spent studying production and documentation, the things that really stand out, to me, is the level of documentation that most teams require. It surprised me that most

One of the biggest parts of keeping logs and documentation, in any project, is to see where you need to make changes. This week, we looked into the documentation of multiple teams, and provided feedba

Today we are pitching a scrum method, that is quite unique. Please watch the video below, and provide feedback in the comments section.

bottom of page