Setbacks

What do you have to anticipate when you have a large number of new members on your team? This doesn't necessarily mean that the new member are really "new". They might have worked for an extended period (several months) on a different project or product.

One likely consequence is that people may no longer be as familiar with how your team works. Or in the case that they are in your team for the first time, they don't know at all how your team works.

At the beginning of this month quite a few new people joined my team for the next release cycle. They are all good engineers, keen to deliver good quality. Yet, this week it happened that although the continuous build was broken, a few more commits of the code base were made.

This was definitely not their fault, and it also was resolved very quickly. The team leads chose a good way by simply talking to the people and explaining to them why it is important to stop committing more change sets if the build is broken. Apparently some of them came from a background where this was not as much encouraged as it is in my team.

In my view there are more than one lesson to learn from this:

• If there are new people - either from other teams or new hires - you have to expect setbacks, even if you conduct a proper induction to the new team members.
• By working in a co-located team, and by using pair programming as a default, such setbacks do not go unnoticed for very long.
• If you have helped your team to become self-organized, you don't need to step in. The team will take care of such issues themselves. They will find good approaches to resolve such issue immediately.

So, don't be afraid of such setbacks. It pays off to have the courage - one of the agile values - to delegate decisions to the team. They become much more self-sufficient, and setbacks are handled much faster and without your intervention.

I think my team did a great job here. Although they were not "hoping" that something like this would happen, they behaved exactly as expected. They simply helped the new team members to learn and that way to become even better team members.

A Nice Story On Estimates

The stereotypical conversation between a manager and a software engineer in a more traditional company goes as follows:

Manager: "I have this piece of work. How long does it take you to complete this?"

Engineer: "It'll take me about 2 months."

Manager: "That's great but let's push the envelope. I think you can do it in 1.5 months."

This is overruling the estimates, and in my experience a big no-no. It is ok and depending on circumstances even helpful to ask guiding questions. E.g. you might want to ask: "What if we implemented this using [xyz] ?" or "Did you consider [abc]?"

Guiding questions help avoiding over-engineering or misunderstandings in the first place.

Today I experienced a different dialog. The manager in the following scene was me:

Manager: "I have this piece of work. How long do you think will it take to complete this?"

Engineer: "It will take about 2 months."

Manager: "Ok, so to be on the safe side, should we say it takes 3 months?"

Engineer: "It will take about 2 months."

And then he went deep into the details to explain to me what tasks would be required for the job.

Bottom line: I observed something extremely positive here. The engineer insisted on his estimate, and I think he was right. He was the person closest to the problem and with the best expertise to make the call. How could I dare to question this if I didn't have better arguments?

Ben, who was the engineer in this particular case, showed me that the above rule also works the other way round. Don't just change the estimates if your best engineers give you an estimate. And this applies for both, decreasing and increasing the estimates. Thank you, Ben! I shouldn't have questioned your judgement in the first place.

Impact and Mitigation of Staff Turnover

In my last post I explored the reasons for staff turnover. Reasons can be monetary (e.g. salary) and non-monetary. In all cases the departure of a team member has consequences, some of which may become visible months later.

Example. For one release cycle a project team signed up for a backlog of 70 stories. Two weeks into the release cycle (12 weeks in total) the team got together and identified a few stories that were too large to fit into one iteration (1 week). As a consequence the backlog grew to 80 stories. The team asked the customer to re-prioritize the stories to identify the low priority stories that would have to be moved to a future release. Not surprisingly, the customer wasn't happy about this as it was perceived as "falling behind schedule". On closer investigation it turned out that the initial backlog contained stories that were too big for acceptance. These stories should have been split or re-scoped before the release cycle started. The person who would have spotted this had left the company just a few months ago. Other team members weren't sufficiently aware of the impact large stories could have. The team learned their lesson and it is unlikely that the same mistake will be repeated.

The important lesson to be learned is: The consequences of the departure of a staff member become apparent only as time passes, and sometimes this can be much, much later.

How could the mistake from the example be avoided? I think that it is important to re-emphasize the rules of the game as often as possible. You might sound like a "broken record". But consider the consequences if you don't repeat "the tune"...

The example also demonstrates that when a team member leaves, some knowledge and skills disappear as well. What are the options to mitigate the impact?

Agile methodologies provide quite a few techniques and tools that you can use. In particular all techniques and tools that foster communication, collaborations, and learning are suited to reduce or mitigate the impact to a large degree.

Release planning involving a good cross cut of different roles - developers, testers, customers, performance experts, technical writers, etc. - ensures that all relevant aspects are considered. Techniques like Agile Auction (aka Planning Poker (TM)) help to detect uncertainties or the need for further discussions.

Frequent reviews help to identify over- or under-engineering. Do you really need all these bells and whistles? Are the features implemented in a really compelling way?

Techniques and tools like Pair Programming, wikis and Show-and-Tells help fostering knowledge transfer and the acquisition of skills.

Keep it simple and try tons of different tools and techniques. Don't give up just because one tool or technique didn't work. If it didn't work, try something else. Learn from your observations. And always challenge your team for instance by asking questions like:

• Given this unsatisfying result can you think of a way how we can prevent a similar situation in the future?
• Given the suggested approach, can we think of an even better way of doing this?

Experiment and try new approaches. Doing that you'll have mitigate a large proportion of the possible impact of turnover.

Reasons for Staff Turnover

People are joining your team. People are moving on. Both can be good or bad. In all cases staff turnover has an impact on your team and also an impact on the relations to other teams, including customers and other stakeholders.

People leave for different reasons. In some cases it might actually be the best option for both the person and the team, if the person is leaving. Sometimes people simply prefer a different working style that is not compatible with that of the team.

A few years ago I had a team member who preferred to work alone and who preferred to work on very complex items. He saw these tasks as unique opportunities and challenges. He was an excellent engineer. The solutions worked and when you took a closer look they turned out to be excellent solulutions. Almost beautiful. However, the person was very introverted and he wasn't able to fully leverage his potential to the rest of the team. In addition the code he created despite being excellent from an engineering perspective as too complicated for the average engineer. The solution was complex, elegant, and still hard to understand as some of the concepts were too abstract for some people. In the end he decided to move on to a different company. It turned out a good development. He was better off because he moved into an environment more suitable for his working style, and the team was better off because the proliferation of the highly abstract code was avoided.

And even more years ago, I had a team member who wasn't able to adopt a new programming paradigm. It was when we introduced object-oriented programming. That was in the early 90s. The engineer tried for many months to come up to speed. Finally he and his manager had to realize that he wouldn't be able to make the required mindshift. We then decided to try finding a different role. Fortunately we found a solution that was beneficial for both the team and the engineer. Instead of simply developing software, he took on a role that contained elements from marketing and presales support. We preserved his experience for the company and at the same time opened up a development path for the struggling engineer.

Fortunately when people leave most of them leave for good reasons. For instance people may choose to move to a different country. Here in New Zealand it is part of the life style to go on an overseas experience (OE). Over several years I saw people leaving for Europe, US, Canada, Singapur, Australia.

Another reason to leave might be that people would like to pursuit a career that is not available within the current company. Sure, you probably would keep people within the company but sometimes it is simply not possible.

Compensation might be a reason as well. My personal preference would be that people don't leave just because of the compensation package. And similarly I don't want people stay just because of the compensation package. I guess I am trying to say that you should be very careful with the compensation package. You don't want just the geniuses (see example above) but on the other hand you don't want to pay just bananas and peanuts either (otherwise you shouldn't be surprise if you are surrounded by monkeys). Compensation is a hygiene factor. You have to have an eye on it.

In my next post I'll explore a little more on the impacts of staff turnover and how to mitigate them using agile principles and techniques. I wish you a Happy and successful New Year!