Recently read an interesting article, here is the extract:
One of the most frequent complaints I hear from managers is that their direct reports are failing to deliver on expectations. They feel at a loss about why this is happening and what they can do about it. They are likely to eventually come to the conclusion that the person is either lazy, lacks commitment or just isn't up to the job.
On closer inspection though, there are many reasons that lead to this underperformance.
Here are four of them.
They don't know what to do - Especially in these days of rapid change and everyone running to keep still it's easy to overlook the basics and to jump to conclusions that we have spelt out our expectations really clearly when we may not have done so. Think about someone you manage whose performance is not living up to your expectations. How confident are you that you have articulated really clearly and specifically what you want them to do? Rather than using vague catch all terms like, "present professionally in meetings" or "write up a comprehensive report" etc. you will need to spell out exactly what that looks like so that they can replicate it.
They think they are already doing it - In the absence of effective and timely feedback, people either decide they are doing fine or that you don't care about what they are doing.
Consider if you have really taken the
opportunity to give specific behavioural feedback about what they are doing that works and what they are doing or not doing that doesn't work. A simple model to use is Action Impact Desire. What action you saw, what the impact was on you, on others, or on the project and what you Desire for the future. This can be used for motivational feedback when they have done something well that you want them to repeat and developmental feedback when you want them to do something differently.
They don't understand why they have to do it
- Someone once said to me that CEO should stand for Chief Explaining Officer. Right from the top, down through the business, leaders at all levels need to paint the big picture and help people see how what they are doing contributes to that big picture. You have probably heard the story about one brick layer saying he is building a wall, while the next brick layer proudly said he was building a cathedral. How are you helping your people see how what they do, contributes to cross functional performance and ultimately to the performance of the business.
They think they could do it differently /
better- On a similar vein, maybe they aren't doing what you want because it doesn't make sense to them. That could be because they don't have the bigger picture or it could be that it really doesn't make sense. They are closer to the front line than you and the chances are they will have ideas about how things could be speeded up, made more efficient, more user or customer friendly etc. Make sure you don't overlook their expertise. Create the forum and the climate that encourages ideas and debate.
Just because you are listening doesn't mean you have to implement all their suggestions but it does help you keep your finger on the pulse, eases the burden on you to always know best and develops and values your staff.
I don't believe people come to work to
deliberately do a poor job. They may have different drivers and motivators from you but your role as manager is to bring out the best in those you manage. So, next time you are feeling frustrated that one of your people isn't delivering on your expectations, ask yourself what could be getting in the way and how you might be contributing to the issue.
Total Pageviews
Tuesday, 13 December 2011
Friday, 18 November 2011
Reducing organisation costs - what would you do if it was your money?
In current economy, managing costs is absolutely crucial in any organisation. Many of us are having to change our spending habits at home, and in work we’re also having to focus hard on cost control. This comes at a time when the wider business needs our support to help deliver what our customers want at a cheaper price.
In most of the organisations, we spend half our life either in meetings or preparing for meetings (what a waste of time?!? Lol ). Therefore I thought why don’t I change the format of meetings and reduce the cost and save some time (and be productive ;) . There are few simple measures any organisation can implement and achieve huge cost savings:
· Avoid overnight stays. No overnight stays, hotel accommodation or rail or air travel should be booked for the same day and meetings should be arranged for the later part of the day so that attendees can arrive comfortably.
· Events. Large scale events and conferences should be subject to rigorous cost control. Encourage employees to use company’s internal facilities where they can. In addition, attendance at external conferences and external training should be approved in advance by senior managers providing a full justification.
· Making the most of teleconference facilities. If you’re not in the same building, try to use teleconferencing facilities instead of face-to-face meetings. Conference calls have many advantages – they reduce our fuel costs and environmental impact; avoid the costs incurred with non-productive travelling time; and support our employees well being.
· Use Smart board or project: We all print documents for meeting attendees and it get thrown away immediately after the meeting. Instead use Smart board or projector and avoid printing presentations. Advantage – reducing printing and paper costs and environmental impact (10 points for being green and saving trees!).
Few other simple tricks:
· Recruitment. Recruit people from within the company or encourage employees to recommend their friends and relative. ‘Recommend a Friend’ reward should encouraged to reduce hefty fees of recruitment agencies.
· Personal equipment. Any unused personal equipment (for example blackberry’s, mobiles or laptops), should be recycled for new starters/replacements wherever possible.
We all need to work together as a team to ensure that we get the maximum value for our money. Tell us what you would do if this was your own cash? We’re interested in finding out how you think we can become even more efficient.
Thanks for everything that you’ll do to help and make sure you keep the ideas coming.
Regards
Krish
Friday, 4 November 2011
Estimating story from trenches
To me, Complexity, Effort and Time are three key things we need to consider. You look at the complexity of a story to derive the effort required to estimate the time it will take you to finish the story.
To use an analogy of carrying a log of wood from point A to point B:
COMPLEXITY: “How BIG and HEAVY is the Log of wood?”
EFFORT: “How much horsepower is required to pull this log?” This is where Story point comes in (IMO).
TIME: Say it takes 2 Horsepower, “how quickly can 6 horses move the log from A to B?” And this, we all know is velocity which can only be derived after a few Sprints.
Complexity cannot be seen in isolation and effort cannot be measured without knowing the complexity.
To use an analogy of carrying a log of wood from point A to point B:
COMPLEXITY: “How BIG and HEAVY is the Log of wood?”
EFFORT: “How much horsepower is required to pull this log?” This is where Story point comes in (IMO).
TIME: Say it takes 2 Horsepower, “how quickly can 6 horses move the log from A to B?” And this, we all know is velocity which can only be derived after a few Sprints.
Complexity cannot be seen in isolation and effort cannot be measured without knowing the complexity.
Saturday, 29 October 2011
Friday, 6 May 2011
Thursday, 5 May 2011
Is there a point in story point estimation? How do we estimate accurately?
This is a relative size of the story compared to other story estimated by the same team – it has nothing to do with who is implementing it and how long it's going to take. Story points are relative estimate, so that you know that 5 point story will take approx. 5 times longer than 1 point story.
Benefits are
- Team’s velocity can be measured
- Allows team to plan future sprint without over/under committing and forecasting total number of sprints. As a result no unrealistic expectations are placed on the team
- Helps team to focus on completing dev and testing in the same sprint
- Helps teams reach a sustainable pace and due to this the business starts to believe in the team
Hours (or ideal hours) are more about time estimation. It can lead to several problems:
- Your "hours" are not the same as mine. It can be harder to make team estimate during release planning.
- It’s easier to make relative estimates and then calculate team velocity in points.
- Stories are usually decomposed to tasks for the sprint. These tasks can be implemented by different people. So total effort is not simply calculated as sum of task estimates.
Usually it's recommended to make story estimation in points for release backlogs and in hours for sprint backlog.
1. Story points are a pure measure of size and complexity
2. Story points are relative (say, with respect to the simplest story) and so have a much longer shelf-life
3. Story points are usually independent of who gives the estimate (as in, an experienced developer and an apprentice can usually agree on something like complexity fairly quickly)
4. Story points avoid the need for discussions like “what are *ideal* hours, really?” or “My ideal hours are different from your ideal hours, stupid.” These add no value.
5. Story points don’t influence behaviour (e.g. Parkinson’s Law)
6. Story points are easier to work with – especially when product owners start to wonder why “3 ideal days take a week…”
7. Story points are more fun – especially when they’re in units like gummy-bears, polar bears, or other endangered species.
Have fun
Benefits are
- Team’s velocity can be measured
- Allows team to plan future sprint without over/under committing and forecasting total number of sprints. As a result no unrealistic expectations are placed on the team
- Helps team to focus on completing dev and testing in the same sprint
- Helps teams reach a sustainable pace and due to this the business starts to believe in the team
Hours (or ideal hours) are more about time estimation. It can lead to several problems:
- Your "hours" are not the same as mine. It can be harder to make team estimate during release planning.
- It’s easier to make relative estimates and then calculate team velocity in points.
- Stories are usually decomposed to tasks for the sprint. These tasks can be implemented by different people. So total effort is not simply calculated as sum of task estimates.
Usually it's recommended to make story estimation in points for release backlogs and in hours for sprint backlog.
1. Story points are a pure measure of size and complexity
2. Story points are relative (say, with respect to the simplest story) and so have a much longer shelf-life
3. Story points are usually independent of who gives the estimate (as in, an experienced developer and an apprentice can usually agree on something like complexity fairly quickly)
4. Story points avoid the need for discussions like “what are *ideal* hours, really?” or “My ideal hours are different from your ideal hours, stupid.” These add no value.
5. Story points don’t influence behaviour (e.g. Parkinson’s Law)
6. Story points are easier to work with – especially when product owners start to wonder why “3 ideal days take a week…”
7. Story points are more fun – especially when they’re in units like gummy-bears, polar bears, or other endangered species.
Have fun
Subscribe to:
Posts (Atom)