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.

Are you a noise cancelling Project Manager of your team ?

I have heard a lot of people saying a good PM is one who cancels out most of the noise around , so that the team can work smoothly. Like a PM should not only give visibility into the iteration/release on an ongoing basis to the customer, but also take care of ensuring that the work queue is maintained such that there is a smooth stream of work for the release timeline.

In a way he/she is like a noise cancellation headphone, which a developer wears, to concentrate on the code he wants to write, and not worry about anything else. A team should just worry about the stories they have to deliver and the value they wish to provide to their customer and nothing else.

In my view, this is the very first task a new PM should learn to do. The next big task is to actually fix the noise so that the team doesnt need a PM all the time to cut out that noise.

To draw an analogy, if a programmer has to repeat a set of tasks again and again, he will automate that in a shell script. Similarly if a PM finds himself repeatedly doing the same thing, he needs to figure out a process which ensures this happens automatically. An example would be, instead of a PM asking devs every now and then "What is the status of the story?" , create more ownership about that story with the BAs. Let the BA who wrote that story worry about how its being developed and make them collaborate more with developers. The BAs should be eager to see their story being developed by the developers, and that will make sure devs collaborate and show progress to BAs everyday. And the BAs know the story is on track

This not only builds ownership and pride within the team, amongst people who are actually delivering value, but also removed the need for a PM to do a mundane follow up job. If a PM does not think along these lines, it is very hard for that team to be self organized.

Dont work long hours, its neither good for you or the team

Sadly enough, this simple issue of ensuring no one work long hours (>10 - 12) a day, in a team seldom sinks in. When a team is behind schedule, the first thing a novice manager pushes for, is for his team to put in long hours of work. In a developer centric organization, if a manager does this even once, he is immediately in the bad books of people around him. Such a manager is never spared !

However, in the same developer centric organization, some developers may take it upon themselves to finish a certain piece of work, even if no manager asked them to do so. Now this, is considered cool. While I understand that when you are programming a solution to the problem, you really don't want to give up in the middle , just because it is 7pm, sometimes developers slog for the heck of it.

In fact if you are on an XP project, it is better for you to not work long hours. For instance if you ended up working 12 hours everyday in an iteration and you ended up delivering 10 points in that iteration, when a manager looks at yesterdays weather, he will end up planning around 10-12 points of work in the next iteration as well. If this happens consistently, your manager will forget that it was just an exception in an iteration that you slogged for over 12 hours, and it will soon become a norm. A novice or a less people oriented manager will be easily prone to committing this mistake. The next time if you are on a vacation for an iteration, it is up to the remaining people in the team to achieve the same result which you did, which implicitly means they working 12 hrs or more.

While your team (and mostly your managers) will look good in front of your stakeholders, to have finished a lot of work consistently in an iteration, you as a developer will be suffering from a burnout. And you will know quite well that the next time you are not around, your team will suffer, since others in the team might not be ready for the 12 hour marathon.

What I am talking about here is how to achieve sustainable pace in the team. Not only does it give predictability for people to plan their iterations better, but it also keeps the team going for months together without a burn out.

If you are a Developer or a Manager, please do not abuse yourself or the team by slogging out all night for days together !