Inducting people on large Agile projects

For a small to medium size project, one really does not need a project specific induction. A developer for example, can learn most about the codebase, by pairing with developers working on different stories. A similar strategy can be adopted by BAs/QAs.

But on a large project (eg: around 20 pairs of developers working simultaneously), the scale of the problem (of inducting people) itself becomes big. The codebase is growing rapidly everyday, and so is the business functionality that the application provides. Getting people upto speed for such a project is a big challenge. Moreover, if you have people who are new to Agile, it adds yet another dimension to the whole problem.

One solution is to have a project specific induction. The model which we have seen work well is actual project simulation, rather than having days of overview sessions and brown bags.

In a project simulation model, you try to create a project like setting on a smaller scale, in order to provide a safe environment for new comers to learn and come up to speed with the project essentials.

Some key factors to keep in mind while planning this.

Group size

Try to maintain a group of 4-6 new joinees in one batch of induction. The attendees will be much more involved by simply being in a smaller group setting. Ensuring a good mix of people from various roles would be useful, however you might always not have this luxury. If you find that the latest batch of new joinees are only developers, allow for a BA and a QA to act as part time mentors for the induction.


Timeline

The time line should be at least as long as a typical iteration in the actual project. One should be able to complete a couple of small stories of the project within this time frame. A 2 week time line would be ideal.

Mentor

Choosing a good mentor is of utmost importance for an induction to succeed.

Mentor Developer - A seasoned developer, a journeyman on the project who can work with a few apprentices around him will be the ideal fit for this role. He/She needs to have a decent understanding of the codebase and also the domain of the project. This person needs to play a full time role in the induction and is constantly pairing with developers, on some of the sample stories in the project induction. He/She could also take a few classroom sessions on the project architecture, technology choices etc...

Mentor Business Analyst (BA) - A mentor BA is needed to help write narratives for sample stories which the induction team will work on. A mentor BA should also have a good understanding of the business problem that the project is trying to solve. He/She should also be pairing with any new BAs joining the team. This can be a part-time role.

Mentor Quality Analyst (QA) - A mentor QA should help in coming up with test scenarios for the sample stories which the induction team will implement. He/She should also have an understanding of test automation framework (if any in use), and help the new QAs on the induction team to write new test cases.


Sample stories

One needs to come up with a wide variety of sample stories, spanning across various areas in the project, to make the induction more interesting and a better learning experience.

Simple functional stories

Pick some user stories that are simple in terms of business value they add. The story size should be less than the average size of story in the actual project. Implementing this story should allow instant gratification for the induction team. It might be as simple as showing some information in the UI which is pulled out of a database. Try to have a set of stories in this category, which will allow people to touch different areas of the code. The stories should also add functionality across different areas in the application to make it more interesting for new BAs.

Refactoring stories

In a huge system, there is always potential for technical debt cleanup. Lining up some stories which are purely technical in nature will allow senior developers joining the team to question the code and try their hand at refactoring it, and in the process learning a lot more about the architecture.

Gold cards/stories

There will always be those interesting tasks in an application which people would have wanted to work on but never got a chance to do so because of project schedule. This is the right time to get those out.

Simulate a mini iteration

Try to put together a mini iteration plan. the length of this should be such that at least an average sample story can be completed in the time span. Prefer a shorter time line so that multiple iterations can be packed in the induction. Ask one of the mentors to double up as an Iteration Manager and run the Iteration in a similar model a real one. This would mean arranging for Iteration Planning meetings were one would estimate and task sample stories, as well as end of iteration retrospectives which will allow the team to look back and focus on learnings. Try to also use the same tools for story tracking, bug tracking etc... as the real project

The more closer this is to a real project iteration, the better are the chances for new joinees to get adjusted to the processes followed in the project.

Artifacts

Artifacts might include anything from presentations used in sessions, video recordings of domain specific sessions, or even retrospective notes from last induction. A lot of these will help future inductions happening on the project and hence must be preserved carefully, ideally in a wiki which is easily accessible and searchable, so that new joinees can find the materials easily. In a rapidly evolving project a big challenge is to keep these materials upto date. This should happen after every induction at the bare minimum.


Buddies

Ensure that new joinees have someone easily approachable in their project after they complete the induction process. Assign them a buddy who can help them learn the ropes. This will ensure the newbies never feel lost, which is mostly the case on large projects.