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 !

Understanding project risks in a self organized team

Risks and Issues for a project is often a matter of worry for a project manager in a team. When you start asking your team to self organize themselves, one of the challenges is to get each individual team member to start thinking of risks and issues for the project/team.

One of the things which helps during the start of a release is to run through the project plan
through a small group of people in the team, to make them understand what they are signing up for. So if your team has 6 pairs of developers it will be nice to run the plan though with 2 pairs of devs, a BA and a QA, and again repeating it for the remaining set of people. It does not matter whether they are freshers or experienced people, they start thinking about what can go wrong in the project. People start asking more questions on "Why the capacity is so much ?" , and "Why are we planning for these stories in Iteration 2 instead of 1 ? ". More importantly you sign up for a release/project plan as a team and not as a project manager/tech lead.


The team also needs to keep an eye on the risks and issues that they identified and constantly seek solutions to mitigate them. There might also be new risks poppng up. What a team can do in this case is to have a mini risks and issues wall near the team area. It can be an X-Y graph of Risks posted on Likelihood v/s Impact.





Even a white board with risks being updated will do , but what matters is that it resides in the team area. A developer taking a break or a stroll around the team area should look at it and wonder "What can we do to tackle that high risk item ?"

Watching open feedback session helps people to open up

Soon after we did a feedback workshop in the team, we gave everyone options to either use a group open feedback session, a one to one session, or a written medium to gather feedback.

As anticipated, a few of the team members were skeptical about the open group feedback and opted for a one on one session. But we kept the group feedback session open to this set of people as well, so that they could witness how it works.

And quite nicely, a few of the team members who were quite skeptical at one point about being given feedback in the open, decided immediately to have an open group feedback instead of having one on ones.

That move felt that the team dynamics were indeed headed in the right direction ! :-)

Why self organized teams after all ?

I read and reread the Agile Manifesto today. Things which stood out were

"Individuals and interactions over processes and tools "

"Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."

"The best architectures, requirements, and designs emerge from self-organizing teams."

"At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."

People often forget some of these things quite easily. What people remember is "frequent delivery of software", "deliver working software" etc.. This is common among new managers trying to understand Agile , because what is popular about Agile in the market is iterative development, and rapid delivery of software. Sadly people forget that its the team which ultimately delivers the software, and for an Agile team, the things quoted above are indispensable.

Feedback Workshop

One of the important things I learnt as an apprentice from Owen Rogers was the importance of giving and receiving feedback and building a feedback culture around it in a team. Somehow in the last few years in Thoughtworks, owing to work pressures, these things have taken a backseat.So in a valiant attempt to revive these, I borrowed Owen's feedback workshop material and studied it. It clearly brought back memories of one of our "Self organized teams" we had built in the India office where exchanging feedback was natural to team members.

I work as a Project Manager for a team of around 30 people now. I waited for a day when there were hardly any meetings for the team, no IPM, no showcases and less chaos. Since it was my first workshop, I picked a group of 6 people from the team who were generally excited about trying out something off work. The group nicely included developers BAs and QAs. We sat in a circle and I gave each person a piece of paper, pencil and an eraser.

After a brief introduction where I spoke about why feedback is important and how it is different from the regular employee appraisal, I asked the audience, how many of them felt , we lacked a good feedback culture and almost everyone had there hands up. That was a lot of motivation to actually get started. We followed the Art Critic model and decided to draw "The Team" as the Art. After 5 mins, we exchanged the sheets of paper so that every member got someone else's work of art.

I asked people to think about two things they found good about the piece of work they had with them. After 2 mins, one of the members volunteered to share his feedback with the artist. I started emphasizing that it works best if one makes eye contact while giving feedback, and also addresses using first person. Using these tips multiple people tried giving their feedback to the artist. It was quite nice to hear what people had to say and actually watch what people had drawn that represented the team. (One of them had drawn a man lifting a huge basket of work and walking). I also emphasized the fact of saying thanks after one receives a positive feedback.

Then we did the same exercise for sharing feedback about things that could have been improved in the art work. I again emphasized on how well one can phrase such sensitive feedback, importance of soliciting it in first place, and the Giver's fantasy of how the giver doesn't have control over how the feedback is received, plays out. When one of the feedbacks was exchanged , I immediately saw the receiver going on their defensive and saying "Hey, I did not mean that in the drawing" or "Ya i thought of that, but did not do it because...". I took some time to speak about how its so natural for our defense mechanisms to kick in when we get some feedback about improvement on our work. I also spoke about how one can think about it as the giver's opinion and then proceed to think about why the giver has formed such an opinion and how it can be made better.

Once everyone finished their turns, I handed them a leaflet which contained the gist of what we spoke about, and also a set of questions seeking feedback about the feedback workshop. Being a PM of the team, I was also more interested in what feedback mechanism they most preferred in the team (Open , one on one in a room, impromptu as it happens. etc..).

At a personal level , I was really excited to relate to some of the things I wanted to say, with the actual feedback that someone tried to give in the group. It also felt really nice when one of the old timers, Raghu, said that.. it has been way too long since any such thing was done in TWI and he felt glad. I will wait and see when we can do a feedback session related to work itself within the team and explain how it should be separated from a salary appraisal.

The next thing probably would be more workshops, with some new ideas and feedback. I might also try the Myer-Briggs test, a few things from Fifth Discipline, and De Bono's techniques.