Archive for category Practices

Things I’ve Learned, the Hard Way

Don’t Procrastinate

It’s always easy to leave things for later, but the consequences are almost always bad. Usually, there is no logical reason to defer anything, starting with simple things such as paying your bills, and ending with dealing with your project’s problems. They won’t just get solved by themselves, they are only going to get worse as time passes. What is more, there are for sure some people relying on you and waiting for you to finish, in order to be able to do their job. You owe these people to get your job done as soon and as well as you can.

Respect Your People

They’ve made it to this team thanks to their qualities and strengths. They have developed into experienced professionals, or they are just taking the first steps. Anyhow, they are the ones directly helping you do your job, and respect is one of the key factors in any good relationship.

Trust Them

There are two kinds of people. The ones thinking that trust is to be earned, and the others who trust people from the beginning, only to lose it if they get let down. I personally belong to the latter, but I find worth mentioning that trusting someone doesn’t mean being naive. You still have deadlines to meet, you still have to make sure your team is producing quality work, so there is a very thin line between being trusting and being too loose.

Don’t Lose Control

There is an old saying: Trust is good, control is better. You may be shocked to find out it belongs to no other than Joseph Stalin, but I consider this only proves that even villains can be pretty wise from time to time. Even if you are lucky to have competent people in your team, you still have to find non-intrusive ways of keeping track of your schedules and commitments. Thinking about that fine line again…

Don’t Micromanage

While being confronted with stressful situations or tight commitments, you can easily turn into a control freak. You may feel the need to know every aspect, every detail, in order to be able to have everything under control. Humans however, are not that “multi-threaded”, so they need to surround themselves with trustworthy and skilled people who they can rely on, rather than trying to squeeze every bit of information into their 20%-used brain.

Listen and Make Sure They Listen to You

You want to be constantly aware of your people’s needs and problems, while making sure they know your expectations. You have every reason in the world to be attentive while in meetings with your fellow leaders and managers, but also to be able to leave relieved that they all know your team’s status or your personal points of view, when the meeting is over. Finding the right ways to communicate is therefore crucial, and yet so different from one situation to another.

Never Wait

Leaders aren’t waiting, they’re acting. Being reactive, or even worse – passive, isn’t part of a leader’s job description. A good way to tell if you are being proactive enough is to ask yourself this question: Usually, when my manager asks me something, do I know the answer on the spot, or do I have to find it out? If you are always being told what to do, you probably aren’t much of a leader after all.

Be What You Want Them to Be

Being a leader means heaving people follow you. But if they find you worthy in any way, they will also borrow from your way of being, more or less consciously. Your behavior is therefore crucially determinative for their own, so unless you don’t want to be surrounded by jerks, make sure you’re not one. Unfortunately, negative behaviors are easy to imitate, but the good news is, positive things are also quite catchy.

  • Facebook
  • Twitter
  • Google Buzz
  • MySpace
  • Yahoo Messenger
  • Google Gmail
  • Yahoo Bookmarks
  • Yahoo Buzz
  • AIM
  • AOL Mail
  • Blogger Post
  • Delicious
  • Digg
  • Google Bookmarks
  • LinkedIn
  • Orkut
  • StumbleUpon
  • Technorati Favorites
  • Windows Live Favorites
  • Share/Bookmark

Tags: , , , , , , , , ,

Burning Down the Reports

Burndown Chart

For years I have relied on different reports, pie-charts and graphs for tracking my team’s progress, as well as my own. I had filters for the tasks which were in progress, for the ones overdue, and for the ones assigned to myself. I had pie-charts rendering the bug count for each of the guys in my team, and also for each product component (architecture-wise). I used a graph that was telling me how many issues were created, in contrast to how many were resolved over a period of time.

But why…

Well, I guess we were driven to this kind of management by the way we used to work.
Our teams were built around the omniscient Team Lead figure, the one who had all the answers to any question, from anyone – “above” or “below”; the one who was reporting, and was being reported to. Each developer was focused on his or her components, not “needing” too much knowledge of others’, so the lead was playing a key role in keeping things together and working. Testing was perceived as a somewhat external job, as there was a completely separate team for that, with their own schedule, and their own way of doing things. The developers pretty much thought their job done as soon as the product of their work was delivered to the testers.
You have probably figured out by now, that the team leads had all the reasons in the world to make sure that they were aware of the detailed status, problems, and interdependencies with other teams, while still struggling to avoid doing micromanagement. Tough job.

This is exactly why we had to change something.

And we did. After countless attempts to correctly understand and adopt the Agile practices and principles, after reading many books, attending some conferences and trainings, and after having failed so many times, we have now finally come to a point where we’re doing things much different than before.

The all-knowing team leads turned into trusting scrum masters, relying on their people, who now need to work closely together to get the job done. The teams are now composed of both developers and testers, so everybody finally got on the same page. We don’t develop anything that can’t be tested right away, developers receive useful input from the testers just from the analysis and design phase, basically everyone works together from the start ’till the end. This doesn’t only happen inside a team, but to some extent, throughout the entire “big” team.

I still have my reports and pie charts, but I don’t recall when I’ve last checked any of them. Instead, we all use a continuously updated Burndown Chart. Not only it tells us how much work we have done, but most importantly, it tells how much we have left to do until we’re done. This also means that we can use it to tell whether we are able to finish everything we’ve planned, and also, what we are going to get done by the end of the sprint. Combined with the task board, containing cards for what’s to do, in progress and what is done, we’ve got all the information we need.

If anybody asks about progress, problems or status, anyone in the team can answer, because we’re all together in this. We are all estimating, planning, reestimating when needed, together, so we all know and care about what’s happening anytime.

And it’s all in one single chart.

  • Facebook
  • Twitter
  • Google Buzz
  • MySpace
  • Yahoo Messenger
  • Google Gmail
  • Yahoo Bookmarks
  • Yahoo Buzz
  • AIM
  • AOL Mail
  • Blogger Post
  • Delicious
  • Digg
  • Google Bookmarks
  • LinkedIn
  • Orkut
  • StumbleUpon
  • Technorati Favorites
  • Windows Live Favorites
  • Share/Bookmark

Tags: , , , ,