I “Post Master”

Delegation, A topic which cannot be missed in any management books. The message is don’t try to do everything by yourself. By delegating to others (who is capable of doing), you can groom the person, help him to grow and one can focus on the most important tasks.
Delegation
But, what is the key here?

  • Don’t do everything by yourself… It doesn’t say don’t do anything at all
  • Delegate to a person who is capable. “Horses for courses
  • Follow up in a regular interval, check if things are going OK and whether the other person needs any help.

Check here for the 12 Rules for delegation

But People are different. They take only what is important for them. Anything and everything can be delegated to others…

I recently spoke to someone (Let us call him A) who took over an account from another manager. This account is a crucial account and there is a struggle to fill the key position for this crucial account for a very long time. There was no progress made for about 7 months till A took over and suddenly in the last 1 month, there is enough progress that has been made, which is visible.

How come someone couldn’t do anything for 7 months and there is a sudden change in the last month? You can say “Luck“… But that’s not the truth. The Previous person delegated his work to someone and probably that someone delegated it to someone else and this chain could have extended further down and no one had any accountability.

Post MasterBut, since its a crucial thing, A has personally started working on it and because of that things have started moving, and the progress is visible.

Did A do anything different in this context? No, A just did his work and nothing else…

Delegation is important. Delegate when your plate is full, or you know someone else is ready and he can do the job so that you can do something more important.

Don’t Delegate because you have a person and you don’t want do anything at all…

If you do so then you can proudly call yourself as “I am a Post Master….”

Happy Learning!!!

Image courtesy

Ambro / FreeDigitalPhotos.net
Dundee Photographics / FreeDigitalPhotos.net

Advertisements

Release Planning and Schedule Monitoring : Myth or Real

In the previous post, we looked at the issues with estimation and for sure it’s clear that there is no way one can estimate accurately.

If you want to plan and monitor a release, the first thing one should know is the pace in which his/her team is running and the second is where we stand as of now. All the management care is if you cannot complete it tomorrow, when you can complete.

Obviously, one cannot go to their senior management and say it will be done whenever it is done. I am sure, we all need our jobs :).

Monitoring

But is that an excuse for the manager’s to sit idle and do nothing saying my developers are not giving any estimates or say I have got you an extension whenever you asked for. For sure, most of the managers rely on their techies to give the real picture. But isn’t that we all have some brain and we should put our brains to some use?

In one of my previous posts i have talked about my view points on this “Are we there yet?

There are two things one as a manager can implement, which can help him make informed decisions.

CYCLE TIME

As a manager one of the tools that can come handy for monitoring is the cycle time. Cycle time is the time that takes to complete a feature/story/task from start to end. Now classify your stories/features/tasks/whatever you have, in the format of small, medium, large, and extra-large.

Cycle Time

Calculate the cycle time. What one should be more interested is on the Average. Display your average time takes to complete the Features on a White Board. Build a Trend chart on the same so that everyone knows how things have changed (whether you are spending more time or less time) over the course of the development.

What if we realize that we are taking a lot of time to complete a feature?

There are two things one can look at.

  • How much time is spent at each section (Analysis / Development / Acceptance)
  • The Lead time to move a story from one section to another

This will give you the complete insight and all possible optimizations can happen after that. This will not only expose the problem within engineering team, but also the time spent in requirements. Say for example: If you see your team members spending most of the time in Analysis, i am sure you know where to optimize.

What are the benefits of doing this?

  • As a manager, one is not only dependent on the team to get the estimates. 95% of the teams are into brown field development and this will help big time.
  • Everyone in the team knows how much time approximately it takes to get anything done (since the average time and the trend chart has been displayed). If you are the Product owner, it’s easy to plan for releases by seeing the average time taken and the trend (whether it’s taking more time or less time).  Will it still be accurate? May be or may not be. But then you have some way to predict (using the Velocity Chart, Cycle Time and Cycle Trend) rather than just shooting at the dark.
  • Oh, this works for Brown field. But ours is Green field. Sure, you cannot change the estimates given. But even in your Green field you still need to plan for releases and this will be very helpful even in that case.

What are the downsides of it?

  • Project status will be crystal clear for all the stakeholders. People can make informed decisions.

VELOCITY CHART

Check this post from Johanna on creating project dashboards to display progress

Create the Line chart with Markers in Excel sheet which displays

  • Total Number of Features to be delivered in the duration of the project in X Axis and
  • Duration of the project (Week wise or month wise) in the Y Axis

Velocity Chart

(A Velocity chart for one of the projects i managed in 2009. This Snapshot was taken sometime around 26-Jul-09)

This will help you see the Features done on a week wise or month wise and the features left on a weekly or monthly basis. If there is a new feature or a set of features added on a specific period it will also show you a spike of the remaining features and anyone with common sense can understand what is going on in the project. If you need the project to be done on time, then most likely the Features done line and Features Remaining line has to meet in the middle.

What are the benefits of doing this?

  1. First, it gives a clear status on what is going in the project, how many features done, how many left and how many are newly added etc.
  2. Second, it helps the manager in clearly showcasing the changes that happens in the project. So no need to defend saying features added or modified is troubling the guestimate. In other words it helps in CYA…
  3. Third, the manager do not have to go to a techie to ask where they stand if he/she has to give a monthly update to the stakeholders.

What are the downsides of it?

  1. Project status will be crystal clear for all the stakeholders.
  2. Manager has to work. Apart from giving GYAN to the team members saying they need to be disciplined with their code, Manager also has to be disciplined in creating, updating and maintaining this which is quite some work. Of course, one can always find an executive assistant to do this. J
  3. Manager cannot blame someone else when things go wrong.

This sounds good. But how will it help me solve my estimation problem?

One may not get rid of the issue with estimates completely. But if this data is captured organization wide and have some way to classify data, you still have some scientific way to estimate rather than guesstimate  Of course, I do understand that every project is unique and the complexity varies.

An almost immediate thing which you can expect is

  • Oh, we don’t have such tools in our organization or project.  You don’t need a tool to do all this. You can do it using Excel sheet. Immediate response would be i don’t know how to create a line chart in Excel. All you have to do is type “Line charts in Excel” in Google and click “I am feeling lucky”. Of course one needs to read it which is beyond the scope of this post 😦
  • The other thing is oh, we are not agile. For sure, you don’t need to be agile to do this. Anyways most of us who claim that we do agile do not anything about agile.

IMHO, it is all about bringing in some discipline within the environment, and with a very minimal change everyone can gain.

Happy Learning!!!!

Image courtesy

ddpavumba / FreeDigitalPhotos.net

The Estimation Myth

My discussion with Sendhil on this topic started after reading the recent blog post from Ron Jeffries on Estimation is Evil.

I had a wonderful opportunity to listen to Linda Rising (Author of the book: Fearless Change: Patterns for Introducing New Ideas) at the Agile India 2013 Conference recently on this topic Deception and Estimation – How we fool ourselves.

If you are a Manager or a developer or a Tester or Director or you do anything related to Software, listen to this talk. To me, Linda is one of the masters of storytelling. Watch this video and you will understand.

My version of the example on this: 

Count BeansHave you ever been to a local salon/barber shop on a Sunday?

In India, we don’t have the concept of taking appointments yet with local salons and the salon will be crowded with people. If you enter the shop say @ 10 AM, you will see at least 5 guys waiting and at the max the local shop will have 3 people working. Now the shop owner or the leader of this 3 will look at you and say 10 to 15 minutes sir.

You know for sure there are only 3 guys working and there are 5 people waiting to either get a haircut or shave or head massage etc… How in the world they will be able to finish the 5 + 3 in 15 minutes and attend you? If you are a logical person, who wants to leave they will still persuade you saying wait sir… it will be over very quickly and you most probably end up listening to this and spend few hours of your Sunday in his shop.

What does it communicates to us?

  • First of all we don’t have any clue on how much time it will take to complete a specific task (even with the guy who is doing the same thing his whole life) – > (Developer, tester)
  • Second, we as humans always want to communicate to the other person in the way he feels comfortable  -> (Manager)
  • Third, we as humans are always optimistic (even when we know that things cannot be achieved in a specific time) – > (Client)

Linda in her talk refers to a research where in as humans

  • If speak for ten minutes there will be 3 lies at least in that.
  • We are tuned to say and accept lies right from childhood. Example she quotes is that a Grandparent gives a gift to their grandchildren. Even though the child, doesn’t like it, as a parent one excepts their child to say “It’s a very nice gift and that’s exactly what they were looking for” 🙂

So how does it translate to our software projects?

  • If you are developing software for whatever period, there is no way you will be able to provide an accurate estimate.
  • If you are a Manager, even when you know that you will not be able to meet the commitment, you will still persuade your client saying that you will be on time.
  • If you are a Client listening to your vendor or to your own team, even when you know that it will not be done on time, you will still accept saying that it will be done on time.

In his book “The Mythical Man Month”, Frederick Brook mentions all Programmers are optimists. The underlying assumption of scheduling is that “all will go well”, i.e., that each task will take only as long as it “ought” to take. It’s a book (bible) for everyone who is into software business.

So much has been said / discussed about this topic. But even 30 years after Frederick Brook has written the first version of his book, nothing has changed. We still believe in the same model.

Young boy countingThe other side of the equation is that if I don’t know the numbers I will not know how much I need to spend and when I can go to market. How will I get bid for a RFP? How will I give a number to my CEO so that he approves the budget?

As a Manager, it is very clear that one need to still give estimates as the Top Management/Middle Management with whom you are dealing with doesn’t understand this and they need an estimate. So as a manager, one do not have an option, other than giving their gut feel numbers.

But is there anything that can be done which can help us and in turn we help the senior management and top management to make some informed decisions?

Let us see it in the next post…

Happy Learning!!!!

Image courtesy

nuchylee/ FreeDigitalPhotos.net

Arztsamui / FreeDigitalPhotos.net

People Management : Team

If you are a Manager, your success depends on your team. If you as a team play well you have better chance of succeeding.

The way a team plays as a whole determines its success. You may have the greatest bunch of individual stars in the world, but if they don’t play together, the club won’t be worth a dime. ~ Babe Ruth

Devil Says:  Don’t worry about the team. You can manage the perceptions of your Manager and your client. You always can find a reason to blame the team.

In my opinion, a Manager plays the key role in building the team, groom and makes them perform. Manager is the one who makes or breaks the team.  He/she is the one who connects the various dots and make it a complete picture.

Starts with your Hiring
Your success and the Project’s Success start with Hiring. If you as a Manager put in enough effort in hiring, you have already crossed 50% of your hurdles.

Inducting, Roles Definition and Expectations Setting
Once the person has joined, everything starts with the way a manager inducts team members in the team.  Define the Roles clearly on who will play what. Clearly specify the expectations at the very first week of a new member joining your team.

Example: A Technical Architect managing/leading a Project and the team members. If you are a manager, this is the last thing you want in your life. This clearly says you as a Manager do not have any clue of what you are doing.

It’s not only important to have the right people in your team. It’s more important to have them seated in the right seats ~ Jim Collins

Manage Emotions
Manage your team member’s emotions on a daily basis. People Management is all about managing people Emotions. You are definitely not managing a computer. Be on the floor. Manage by walking around. Get out of your cubicle or cabin and go around the floor. Get a firsthand experience on what’s going on. Make sure your team feels comfortable. When a project gets started it’s natural that people do not understand their roles, have conflicts etc. If their emotions are managed in the right way, I am sure the team will start jelling well.

Managing Projects is all about Managing Emotions ~ Doug Decarlo

Lead by example
Meet your commitments and make sure your team member’s meet their commitments on a daily basis. Meeting commitments helps building trust with each other.

Do not postpone or Cancel meetings with your team members. ~Common Sense

Set a process to address Conflicts between members
Discuss with your team and figure out how they can handle conflicts between themselves. Build a escalation model so that they can come to you only if things are not resolved within themselves.

Power of 1:1s:
Have regular 1:1’s with your team members. I am sure every company today forces you to enter 1:1 data in the system on some interval. I am not talking about that. Have 1:1’s at least once in a month. The reason why you can have only a maximum of 10 or less people reporting is to make sure that you have time to do this and not for reading news papers online.

Review your expectations and goals set, see how things are going. Give Feedback and take feedback.

Listen to get feedback
It’s not only important to listen to your team members only during meetings, but also when you walk around in the floor. Not everyone in the team will give you feedback. There will be casual comments. Take a note of the comments and review them offline. See if there is anything which is a real feedback, take them and work on it. When your team members see that you have taken their feedback and worked on it, obviously you have scored a couple of more brownie points.

High Maintenance Resources

If you have Super stars in your team, have 1:1s with them on a bi-monthly basis. Super Stars are typically High Maintenance Guys. You have a better chance of growing if you know how to manage Super Stars.

Nothing comes free in the world ~ Common Sense

Get Rid of Bad Apples
If you have a non-performing resource or a bad apple who introduces lot of negativity, have some spine and remove them. Don’t just worry only about your billability. If you are the one who is bringing in the negativity, get rid of yourself from the team.

Be a Role Model.

  • Don’t go give gyan to your team members, saying they need to work hard, get things completed on time etc. If your team members do not see you contributing to your project in a meaningful way there is no way they will listen to you.
  • If your team members are working on a weekend or late night, sit next to them and give moral support. Show that you are really interested in the outcome of the project. Don’t inside your cabin and say I am giving moral support.
  • Don’t give suggestions to your team members only when your manager is around. You may get a temporary mileage, but sure it will not last for long.
  • Make sure you give the confidence, if there is anything which goes wrong you take the complete responsibility and protect the team.

Walk the Walk. Talk the Talk

TEAM – TOGETHER EVERYONE ACHIEVES MORE

Happy Learning!!!! 

Image: FreeDigitalPhotos.net

The case for Explicit Risk Management in agile projects

Risk is a fuzzy term — it can mean different things to different people.

If you search for “Agile Risk Management” in Google, though you may get lot of links there are very few links which will be helpful for you. I am sure, if you take any of the agile projects that are being executed, you will not see anything related to risk management defined explicitly.

Why is that?
Agile was created keeping a single team in mind. Agile is focused on producing a working software every iteration by automating any repetitive tasks. This leads to frequent customer deliveries. Transparency and Visibility are the core values. Risk Management is implicit in agile teams and happens continuously (or should happen) within duration of the development. That’s why in most of the agile projects you do not get to see any form of explicit risk management.

Is this the case today? If you are from a Services company, i am sure its not the case. Even, if you are from a captive center, its not the case. We do (or say that), we practice agile in distributed environment, where multiple teams are involved. In some places there are even multiple companies involved. In a smaller environment, where there is only one team, Stakeholders are from single company and the project size is small its Okay not to have an explicit risk management. If you have a large team, a project running for more than 3 months, you will be in a much better place by doing explicit risk management.

Wait a second. Isn’t this what we did with traditional software development (waterfall). It was just a list and someone maintained it. I am a Project Manager/Development Manager who is extremely busy. What benefits will i get by doing this?

Well, in one way, its more or less the same thing. You need a list. But earlier, it was created/maintained/managed by the Project Manager. Activities happened mostly during the initial stages of the Project. It was never revisited.

In an agile environment, you revisit this, take necessary actions every iteration. This may improve your success rate.

Apart from that, today the Delivery teams might be from different companies. Though your product owner might be aware of the Risks, but your Product Owner is not the only stakeholder. As a Project Manager, its your responsibility to keep all the stakeholders up to date with the Risks, Owner of the Risk item, the plan to address, steps that been taken to address (Ignore, Accept or Mitigate). In case if your project doesn’t succeed, this may be another document which might help you CYA and CY Team’s A.

In an agile environment, Risk Management as a process – no one person owns the risk management. The whole team is responsible for risk management with a clear owner defined to address each risk item.

Okay, Sounds like a good story. If this is so important, why do we not see this happening?

Most of the Projects will have common risks. The challenge is to identify Risks which are project specific. If you know how to identify risks, i am sure we will find a way to mitigate them. Its a lot of effort and makes you thinking. Probably that’s on of the reason why you don’t see this happening.

I am planning to write couple of more posts in this. Will try to address the following as part of the next posts.

  • Risks Vs Uncertainty, Known Vs Unknown
  • Risk Management Process
  • How to Identify Risks?
  • Risk Response Planning, Tracking (Risk Burn down Chart, Risk Profile)

In the past, whenever i tried writing a series of posts, it never happened. Hope this time i will have some more energy to complete what i started in this post.

Happy Learning!!!!

Are we there yet?

Are we there?Whenever I take my son and daughter for a long drive, one question they always ask me in between is are we there yet? How much more time it will take?

If you are a business stakeholder sponsoring a project one of the questions you will ask your project or program manager is that are we there yet? When can we go live?

How many projects today we execute are in the state where you can say that it will take approximately this much more time to complete? If the question is simple and all the project/program managers know this answer then every PM should be able to answer this right. Still, why don’t we get an answer?

Let us take our travel scenario. If you are travelling from Place A to Place B, then you would know approximately the distance between these 2 places. and i am sure you will know the speed in which you are driving and how much covered in what time. When someone asks you a question, how much more time it will take you will probably be able to say, we will be there in an hour or hour and a half. This may not be accurate, but atleast you will able to reach there in that time, unless there is a traffic jam or you completely under estimated the distance to cover (which is very unlikely today with google or bing maps).

So, what are all the things that helped us in calculating the time to reach? Distance between 2 places, Average speed in which you are travelling, Distance covered, Time taken to cover the distance, Remaining Distance etc, Expected # of stops in between, Approx. time for a stop …

Definitely not rocket science. huh?

If it is possible in a travel, what is stopping us as project or program managers to do the same with our projects?

Of course, calculating the size is not easy in project management. Infact, there is no way you will be able to get the exact size. But, you can always get the size in some approximate number (Story Points, Use Case Points, Function Points, Gut Feel Number).

If you have a team which delivers, as a Project or Program Manager, one should be able to know how much they are delivering. Over a period one should be able to judge the team’s velocity (Average Speed) and the average time it takes to complete a Story/Feature.

Oh! We dont estimate, We follow Kanban. Great, you can always calculate the cycle time. Over a period, you will know the Cycle Time for different feature categories.

If you know the average velocity/cycle time (Speed), and if you know the features completed (distance covered), you will be able to say what is remaining and how much more time (approximately) you will take to complete the remaining work.

Agile methodologies were created to help the customers and provide business value. It doesnt mean that because we follow agile, we cannot or should not provide the needed information to business. Finally business needs to know where do we stand and how much more time is required to complete any work. One may not be accurate, but atleast should be able to give more or less correct information.

Prakash, you are from services business and it may happen in services business. Not in our environment. Be Honest. I have worked with different kinds of companies across the globe and i am sure we all know the reality.

It is very important to create the project management ecosystem irrespective of whether you follow traditional, iterative, agile or any kind of methodologies. If your project or program manager is not capable or interested in creating/providing the ecosystem, it is time for you to look for a new person. Dont expect the PMO to create a ecosystem for you. You cannot train people to do all these. It is like training a experienced developer how to program. If someone is interested, he would have learnt it by himself, anyways.

Check this article from Johanna Rothman’s blog Are We There Yet?: Creating Project Dashboards to Display Progress

The other argument, i generally hear from people is that this project was estimated by someone else and there is no way in the world this can be executed in that time. Sure, i understand what you are saying. Everyone is human. People make mistakes. But, as soon as a project comes to a Manager it becomes his/her responsibility. You may not be able to deliver something within the time frame what the other person has estimated. But at least you should be in a position to say how much more time it would require to deliver. Is that really that difficult?

If you are a manager and your organization is not supporting you to do all this, then it is time for you to look for a new job. It is upto you whether you want to be a Project/Program Manager or a Post Man/Cowboy.

If you are a developer, you take pride in being a good developer writing high quality code. If you are a Project/Program Manager, you take pride in being a manager doing all what is required.

Happy Learning!!!