Partial Retrospection

I firmly believe that in order for a team to succeed they should be committing themselves, and take accountability. I saw teams succeed when they do, and saw teams fail when they don't.

So in the upcoming changes we're making, we want the team to be part of it. Thursday, we did a partial retrospection, to test the water. Why partial? Well, it's full when you take at what's good and what can be improved, and decide on ways to take the next time. We just did the first part, get people's reaction and readiness for changes.

This team suffered from turnover this year, and it showed, as new people talked about having no on-boarding plan. This is in part, because we are doing real-time hiring, with no ongoing recruitment plan. Has been like that since I got here 10 years ago. New people come in when needed, or in a worse case, later after their needed, and there's no succession planning. Related to that, people talked about having no back up, in terms of team members having the same knowledge. This stems from the team structure (and yes I claim responsibility here).

The other major thing that came up is the one we're going to attack first. This is the parallel development inn teams, for a while, without integration and making this work, before moving forward. This has implication in so many levels:

• Requirements close late, so developers and testers work partially on their related tasks, lengthening the tasks and splitting them
  
• developers and testers do not work on features at the same time, making long cycles of find-fix-verify.
• because the releases are big, and mostly late, there's a big pressure period toward the end, which is followed by big relaxation period after release, and so on. There is no sense of sustainability.

Like I said, the 1st thing we're going to do is time box. Focus the team within the period, and hold them accountable to their plan. We will work on things we know now, rather than plan for things that might be later. And hopefully see after a stumbling period success.

People seem ready for changes. I'm not sure what measure of commitment they will show, based on past experience. We'll see.

Ayende on Broken Windows

Ayende gives an example of how to set the bar high. The broken windows theory talks about what happens when you let your guard down.

In software this means that if you start setting the bar low, for example allowing more bugs, or stop refactoring for a while (because now is not the right to focus on this) , you actually make it easier for these things to happen more.

IO can say this is a mentality, that I've seen and experienced both on a personal level, managerial and team level. On the personal level, I gave in to pressure to complete tasks, by saying: it's done. Although it was not done-done.

As a manager, I allowed team members to continue working the same, although it was obviously not effective. But we had a project to deliver. And if it is coming from a manager, it's no surprise the team accepts this as guidelines for work: the release date is more important than any other metric (like quality).

We're all guilty of this at some point of time. And kudos to Ayende for sticking to his values. It is my punishment today to try to educate people in the same position I was, thinking the same way I did, to do the opposite...

The Secret Sauce of Success

What makes a project succeed? Well, the list is long, so I won't even try. I have seen failures and successes decided on team work.

Why would a person contribute to the team success, or not? Apart from the "survivalist" who cares about his job, there are others that excel or remain average. Those who excel are the ones who care about the project and their team members. Manager Tools' Mark Horstman's rule #1: It's all about people (the rest are here).

If we rule out the survivalists, we're talking about people who are not in danger. Even if they are not motivated, they can still move forward, slowly. But we don’t want that. We want real success.

So if the layoff whip is not used, then what? Unless they are sociopaths, they do care about their teammates. And this is where peer pressure comes in. If they feel they are letting the team down, they will pull through.

So the 64K dollar question is how to get people to commit, or care? Make them take ownership on what they do, and be responsible, not only to the organization, but also their peers.

Two of the things we're introducing are the iteration planning session and a demo. The planning session is when the team commits their actions for the iterations (not just for the boss, also for the team). A demo is where the team presents working features (including a whole ceremony). A part of showing successes, this proof of commitment they made in the beginning of iteration, not helps them take pride in their success, but increases the peer pressure for team success.

Apparently, We're Already Doing Agile!

Not really, but there are improvements. One of the PMs has scheduled builds every Thursday. The team is working cohesively to meet these deadlines and share the responsibilities. Status is communicated every two days, and solutions to problems are found.

It takes a lot of re-planning, as things change from week to week. Features are dropped from the next build and moved to the next. The test team expects features in the next build, but if it doesn’t go in, the test plan changes.

Not easy - but it's working, as the release date approaches.

I want to meet with the team, and do a retrospection, and get a sense of what's working and what can be improved.

Winds of Change

We're going agile! Note that it's not with a capital A. And when we do it is with small steps. However, I think it is a step in the right direction.

How did this miracle happen? I can take some of the credit, but it's mostly letting people absorb the theory until it looks real. It also helps that when there's no single source. I could shout from morning till noon, and not get attention, but when someone else outside the organization says so, it helps. Plus, he can show successes, while I can cite theories.

It's not going to be a revolution. The PM although being more open then before, is still skeptic. Also, it's expected that some of the team will resist changes. But it's more challenging this way.

The first step would be to take apart the current plan, and tear it to small iterations. This means taking long implementation features and separating them into workflows that fit into the iterations. This requires some planning up front. The size of the iterations will probably be 2 weeks.

More things that go into the plan: a buffer of support and analysis of current issues. The way the project is running today, we can't just say to emails from our customers "we'll discuss this in the next iteration".

Still, the PM role here is to set the ground rules and stick to them. For instance, today if one of the developers says one day before the iteration: "I still have 3 more days to complete this" here's what happens: the build will probably be delayed. In the meantime, the rest of the developers are rushing forward, since they are not waiting for that developer, as they have more things to do.

Instead, the default would be that the team will propose a solution, to meet the deadline. If not the feature is dropped from this build, but the time-box must be respected.

This is going to be interesting.