7 Tips for Improving the Daily Scrum

January 12, 2009

Daily Scrum also known as daily standup meeting is an important element of the Scrum process. The structure of the meeting is quite rigid and fixed. Everybody has to stand up, meeting should take no longer, than 15 minutes and everybody should answer three questions: “What did you do since the last meeting?”, “What are you going to do until the next meeting?”, “What impedes you from being more productive?”. The purpose of this rigidness is for making sure that daily Scrum is to help team members synchronize between themselves, not to solve problems.

Things to watch during the daily standups are:

1. Standup means stand up, no sitting, really.
Standing up on the daily Scrum draws attention to the brevity of the meeting. The purpose of the meeting is synchronization and no lengthy problem solving. Standing helps to remember that problem solving except the smallest one has to be taken offline – nobody likes to stand for an hour while two guys are arguing about the protocol implementation details.

2. Keep it short. 15 minutes max.

Everybody can spend 15 minutes a day on synchronizing with the others. Especially if it happens to be immediately before or right after the lunch time. Spending half an hour is a very different story. In my experience most of the time the 5-6 person teams are usually done in just 7-10 minutes.

3. Stand in front of the visual progress artifact.
Ideally in front of the task board together with the product and sprint backlog. Visuality and tangibility help discussing things. If task board is used, developers often like waving hands towards the card being currently discussed or even move the cards during this meeting

4. Everybody should be present.
One of the main reasons for meeting live is to utilize as wide communication bandwidth as possible – people are known to communicate more effectively, when meeting live. If particular team member is unable to participate, another person should report on behalf of his/her. If it is impossible for some reason, catch up later.

5. No typing.
Holding a laptop and making notes is power. The one who types immediately starts looking as a manager and often subconsciously starts writing what he thinks was meant, not what team members actually said. If you need notes, take micro-notes by hand.

6. Concentrate on the second and third question, not on the first one.
What’s done is more of a context for the second and third questions. The real point is to figure out what’s blocking the efficient work and who could help it.

7. If team talks too much to ScM, let him not too look at the team.
Daily standup is for synchronizing between the team members, not between Scrum Master and the team. If team members start behaving as they are reporting to Scrum Master, he can start literally looking at another person or even walk away a little. Such small tricks are often able to confirm that daily Scrum is for the team members and not for the Scrum Master.

Daily Scrum is a powerful tool, but as any other tool it is good, when you know what it’s useful for and have some experience in using it. The above seven simple tips can be good starting points or reminders. However, every team knows best how to adjust its standups to serve them better. The important part is the goal, not the method.

Your experience
What feels important in your daily standup?

Advertisements

10 Golden Rules of Project Risk Management

October 30, 2008

The benefits of risk management in projects are huge. You can gain a lot of money if you deal with uncertain project events in a proactive manner. The result will be that you minimise the impact of project threats and seize the opportunities that occur. This allows you to deliver your project on time, on budget and with the quality results your project sponsor demands. Also your team members will be much happier if they do not enter a “fire fighting” mode needed to repair the failures that could have been prevented.

Rule 1: Make Risk Management Part of Your Project

The first rule is essential to the success of project risk management. If you don’t truly embed risk management in your project, you can not reap the full benefits of this approach. You can encounter a number of faulty approaches in companies. Some projects use no approach whatsoever to risk management. They are either ignorant, running their first project or they are somehow confident that no risks will occur in their project (which of course will happen). Some people blindly trust the project manager, especially if he (usually it is a man) looks like a battered army veteran who has been in the trenches for the last two decades. Professional companies make risk management part of their day to day operations and include it in project meetings and the training of staff.

Rule 2: Identify Risks Early in Your Project

The first step in project risk management is to identify the risks that are present in your project. This requires an open mind set that focuses on future scenarios that may occur. Two main sources exist to identify risks, people and paper. People are your team members that each bring along their personal experiences and expertise. Other people to talk to are experts outside your project that have a track record with the type of project or work you are facing. They can reveal some booby traps you will encounter or some golden opportunities that may not have crossed your mind. Interviews and team sessions (risk brainstorming) are the common methods to discover the risks people know. Paper is a different story. Projects tend to generate a significant number of (electronic) documents that contain project risks. They may not always have that name, but someone who reads carefully (between the lines) will find them. The project plan, business case and resource planning are good starters. Another categories are old project plans, your company Intranet and specialised websites.
Are you able to identify all project risks before they occur? Probably not. However if you combine a number of different identification methods, you are likely to find the large majority. If you deal with them properly, you have enough time left for the unexpected risks that take place.

Rule 3: Communicate About Risks

Failed projects show that project managers in such projects were frequently unaware of the big hammer that was about to hit them. The frightening finding was that frequently someone of the project organisation actually did see that hammer, but didn’t inform the project manager of its existence. If you don’t want this to happen in your project, you better pay attention to risk communication.
A good approach is to consistently include risk communication in the tasks you carry out. If you have a team meeting, make project risks part of the default agenda (and not the final item on the list!). This shows risks are important to the project manager and gives team members a “natural moment” to discuss them and report new ones.
Another important line of communication is that of the project manager and project sponsor or principal. Focus your communication efforts on the big risks here and make sure you don’t surprise the boss or the customer! Also take care that the sponsor makes decisions on the top risks, because usually some of them exceed the mandate of the project manager.

Rule 4: Consider Both Threats and Opportunities

Project risks have a negative connotation: they are the “bad guys” that can harm your project. However modern risk approaches also focus on positive risks, the project opportunities. These are the uncertain events that beneficial to your project and organisation. These “good guys” make your project faster, better and more profitable.
Unfortunately, lots of project teams struggle to cross the finish line, being overloaded with work that needs to be done quickly. This creates project dynamics where only negative risks matter (if the team considers any risks at all). Make sure you create some time to deal with the opportunities in your project, even if it is only half an hour. Chances are that you see a couple of opportunities with a high pay-off that don’t require a big investment in time or resources.

Rule 5: Clarify Ownership Issues

Some project managers think they are done once they have created a list with risks. However this is only a starting point. The next step is to make clear who is responsible for what risk! Someone has to feel the heat if a risk is not taken care of properly. The trick is simple: assign a risk owner for each risk that you have found. The risk owner is the person in your team that has the responsibility to optimise this risk for the project. The effects are really positive. At first people usually feel uncomfortable that they are actually responsible for certain risks, but as time passes they will act and carry out tasks to decrease threats and enhance opportunities.
Ownership also exists on another level. If a project threat occurs, someone has to pay the bill. This sounds logical, but it is an issue you have to address before a risk occurs. Especially if different business units, departments and suppliers are involved in your project, it becomes important who bears the consequences and has to empty his wallet. An important side effect of clarifying the ownership of risk effects, is that line managers start to pay attention to a project, especially when a lot of money is at stake. The ownership issue is equally important with project opportunities. Fights over (unexpected) revenues can become a long-term pastime of management.

Rule 6: Prioritise Risks

A project manager once told me “I treat all risks equally.” This makes project life really simple. However, it doesn’t deliver the best results possible. Some risks have a higher impact than others. Therefore, you better spend your time on the risks that can cause the biggest losses and gains. Check if you have any showstoppers in your project that could derail your project. If so, these are your number 1 priority. The other risks can be prioritised on gut feeling or, more objectively, on a set of criteria. The criteria most project teams use is to consider the effects of a risk and the likelihood that it will occur. Whatever prioritisation measure you use, use it consistently and focus on the big risks.

Rule 7: Analyse Risks

Understanding the nature of a risk is a precondition for a good response. Therefore take some time to have a closer look at individual risks and don’t jump to conclusions without knowing what a risk is about.
Risk analysis occurs at different levels. If you want to understand a risk at an individual level it is most fruitful to think about the effects that it has and the causes that can make it happen. Looking at the effects, you can describe what effects take place immediately after a risk occurs and what effects happen as a result of the primary effects or because time elapses. A more detailed analysis may show the order of magnitude effect in a certain effect category like costs, lead time or product quality. Another angle to look at risks, is to focus on the events that precede a risk occurrence, the risk causes. List the different causes and the circumstances that decrease or increase the likelihood.
Another level of risk analysis is investigate the entire project. Each project manager needs to answer the usual questions about the total budget needed or the date the project will finish. If you take risks into account, you can do a simulation to show your project sponsor how likely it is that you finish on a given date or within a certain time frame. A similar exercise can be done for project costs.
The informaion you gather in a risk analysis will provide valuable insights in your project and the necessary input to find effective responses to optimise the risks.

Rule 8: Plan and Implement Risk Responses

Implementing a risk response is the activity that actually adds value to your project. You prevent a threat occurring or minimise negative effects. Execution is key here. The other rules have helped you to map, prioritise and understand risks. This will help you to make a sound risk response plan that focuses on the big wins.
If you deal with threats you basically have three options, risk avoidance, risk minimisation and risk acceptance. Avoiding risks means you organise your project in such a way that you don’t encounter a risk anymore. This could mean changing supplier or adopting a different technology or, if you deal with a fatal risk, terminating a project. Spending more money on a doomed project is a bad investment.
The biggest category of responses are the ones to minimise risks. You can try to prevent a risk occurring by influencing the causes or decreasing the negative effects that could result. If you have carried out rule 7 properly (risk analysis) you will have plenty of opportunities to influence it. A final response is to accept a risk. This is a good choice if the effects on the project are minimal or the possibilities to influence it prove to be very difficult, time consuming or relatively expensive. Just make sure that it is a conscious choice to accept a certain risk.
Responses for risk opportunities are the reverse of the ones for threats. They will focus on seeking risks, maximising them or ignoring them (if opportunities prove to be too small).

Rule 9: Register Project Risk

This rule is about bookkeeping (however don’t stop reading). Maintaining a risk log enables you to view progress and make sure that you won’t forget a risk or two. It is also a perfect communication tool that informs your team members and stakeholders what is going on (rule 3).
A good risk log contains risks descriptions, clarifies ownership issues (rule 5) and enables you to carry our some basic analyses with regard to causes and effects (rule 7). Most project managers aren’t really fond of administrative tasks, but doing your bookkeeping with regards to risks pays off, especially if the number of risks is large. Some project managers don’t want to record risks, because they feel this makes it easier to blame them in case things go wrong. However the reverse is true. If you record project risks and the effective responses you have implemented, you create a track record that no one can deny. Even if a risk happens that derails the project. Doing projects is taking risks.

Rule 10: Track Risks and Associated Tasks

The risk register you have created as a result of rule 9, will help you to track risks and their associated tasks. Tracking tasks is a day-to-day job for each project manager. Integrating risk tasks into that daily routine is the easiest solution. Risk tasks may be carried out to identify or analyse risks or to generate, select and implement responses.
Tracking risks differs from tracking tasks. It focuses on the current situation of risks. Which risks are more likely to happen? Has the relative importance of risks changed? Answering this questions will help to pay attention to the risks that matter most for your project value.
The 10 golden risk rules above give you guidelines on how to implement risk management successfully in your project. However, keep in mind that you can always improve. Therefore rule number 11 would be to use the Japanese Kaizen approach: measure the effects of your risk management efforts and continuously implement improvements to make it even better.

Success with your project!

Source: http://www.4pm.pl


Top 10 Clues That You Are Management Material

October 27, 2008
  • 10. You like not doing anything
  • 9. You have no trouble telling others what to do
  • 8. Work fascinates you – you can sit and watch it for hours
  • 7. You like ‘sweating the small stuff’
  • 6. You have always been something of a loner
  • 5. You don’t think ‘plan’ is a four-letter word
  • 4. Your favorite cocktail is milk of magnesia
  • 3. On Halloween you dress up as Alex P. Keating
  • 2. Your favorite horror writer is Tom Peters

And the number one clue you are management material –

  • You enjoy having people despise you just for doing your job.

Source: http://management.about.com


21 Precious Tips for Project Managers

October 22, 2008

Browsing the web I’ve found these amazing tips that in most of cases we all know but we never practice or remember them.

Right after I post it, I’m going to print it out and put in front of me in my desk to look at them every single day. Really worth a read.

  1. Fix the problem, not the blame. It is far more productive, and less expensive, to figure out what to do to fix a problem that has come up than it is to waste time trying to decide who’s fault it was.
  2. Tell people what you want, not how to do it. You will find people more responsive and less defensive if you can give them guidance not instructions. You will also see more initiative, more innovation, and more of an ownership attitude from them develop over time.
  3. Manage the function, not the paperwork. Remember that your job is to manage a specific function within the company, whatever that may be. There is a lot of paperwork that goes with the job, but don’t let that distract you from your real responsibility.
  4. Don’t DO Anything. Your job as a manager is to “plan, organize, control and direct.” Don’t let yourself waste valuable time by falling back on what you did before you became a manager. We know you enjoy it and you are good at it. That’s why you were promoted. Now you need to concentrate your efforts on managing, not on “doing”.
  5. You never have to make up for a good start. If a project or a job gets off to a bad start it can be difficult to catch up. Do your planning up front so you get a good start and you won’t regret it.
  6. Get out of your office. Management By Walking Around (MBWA) does work. You make yourself more approachable. You get information first-hand. You find out what’s really happening.
  7. Lead by example. If you ask your employees to work overtime, be there too. Just because company policy allows it, don’t fly first-class if your associates are in coach on the same plane. Be a leader – it’s tougher than being a manager, but it’s worth it.
  8. Delegate the easy stuff. The things you do well are the things to delegate. Hold on to those that are challenging and difficult. That is how you will grow.
  9. Don’t get caught up in ‘looking good’. “Work happily together. Don’t try to act big. Don’t try to get into the good graces of important people, but enjoy the company of ordinary folks. And don’t think you know it all. Never pay back evil for evil. Do things in such a way that everyone can see you are honest clear through.”
  10. ‘Quality’ is just conformance to requirements. You get the behavior you critique for, so set your standards and then require conformance to them. Quality will come from that effort, not from slogans, posters, or even threats.
  11. Learn from the mistakes of others. You can’t live long enough to make them all yourself.
  12. Set S.M.A.R.T. Goals. Goals you set for yourself, or others, should be Specific, Measurable, Achieveable, Realistic, and Time-based.
  13. Set an example. “One of the most significant parts of a manger’s job is for them to become a positive role model that can pull a team together and deliver the level of service expected from their customers.”
  14. Know Your GPM. In engineering, gpm is gallons per minute, a design criterion. In Management GPM is an acronym for Goals, Plans, and Metrics. To achieve your goals, you must first determine what your Goals are. Then you have to develop a Plan that gets you to your goal. Finally you need Metrics (measurements) to know if you are moving toward your goal according to your plan.
  15. Train Your Supervisors. The key to your business success is the productivity of your employees. The key to employee productivity is their perception of their immediate supervisor. Invest in training your supervisors and managers. It will pay off.
  16. You Can’t Listen With Your Mouth Open. Your associates, your employees, your suppliers, your customers all have something of value in what they have to say. Listen to the people around you. You will never learn what it is if you drown them out by talking all the time. Remember, the only thing that can come out of your mouth is something you already know. Shut up and learn.
  17. Practice what you preach. To lead, you have to lead by example. Don’t expect your people to work unpaid overtime if you leave early every day. Don’t book youself into a four star hotel on business trips and expect your employees to stay in the motel off the freeway.
  18. Leaders create change. If you lead, you will cause changes. Be prepared for them and their impact on people within, and outside, your group. If you are not making changes, you are not leading.
  19. Don’t Limit Yourself. The difference between leaders and managers is that leaders do not set limits on themselves. There are enough people trying to limit what you can do. Don’t be one of them.
  20. Anyone can steer the ship in calm waters. What will set you apart in your career is how you perform during the tough times. Don’t become complacent and relax just because things are going well. Plan ahead for the downturn.
  21. You have to make a difference. The group you manage has to be more effective, more productive with you there than they would be if you were not. If they are as productive without you, there is no business sense in keeping you on the payroll.

Source: http://management.about.com/cs/generalmanagement/a/mgt_tips03.htm


Scope – The fourth element (and most important) to manage

October 22, 2008

A successful Project Manager must simultaneously manage the four basic elements of a project: resources, time, money, and most importantly, scope. All these elements are interrelated. Each must be managed effectively. All must be managed together if the project, and the project manager, is to be a success.

  • Resources
    People, equipment, material
  • Time
    Task durations, dependencies, critical path
  • Money
    Costs, contingencies, profit
  • Scope
    Project size, goals, requirements

Most literature on project management speaks of the need to manage and balance three elements: people, time, and money. However, the fourth element is the most important and it is the first and last task for a successful project manager. First and foremost you have to manage the project scope.

The project scope is the definition of what the project is supposed to accomplish and the budget (of time and money) that has been created to achieve these objectives. It is absolutely imperative that any change to the scope of the project have a matching change in budget, either time or resources. If the project scope is to build a building to house three widgets with a budget of $100,000 the project manager is expected to do that. However, if the scope is changed to a building for four widgets, the project manager must obtain an appropriate change in budgeted resources. If the budget is not adjusted, the smart project manager will avoid the change in scope.

Usually, scope changes occur in the form of “scope creep”. Scope creep is the piling up of small changes that by themselves are manageable, but in agregate are significant. For example, the project callls for a building to be 80,000 square feet in size. The client wants to add a ten foot long, 4 foot wide awning over one bay door. That’s a pretty minor change. Later the client wants to extend the awing 8 feet to cover the adjacent bay. Another minor change. Then it’s a change to block the upwind side to the covered area to keep out the wind. Later, it’s a request to block the other end to make the addition more symetrical. Eventually, the client asks for a ceiling under the awning, lights in the ceiling, electrical outlets, a water faucet for the workers, some sound-proofing, and a security camera. By now, the minor change has become a major addition. Make sure any requested change, no matter how small, is accompanied by approval for a change in budget or schedule or both.

You can not effectively manage the resources, time and money in a project unless you actively manage the project scope.

When you have the project scope clearly identified and associated to the timeline and budget, you can begin to manage the project resources. These include the people, equipment, and material needed to complete the project.

Source: http://management.about.com/cs/projectmanagement/a/PM101c.htm


I’m Google I can read Flash

October 22, 2008

In a recent announcement, Google and Adobe have teamed up to develop a new algorithm for the spider bots to index text content in Flash file.

It also extracts URLs and understand simple JavaScript like SWFObject. This was not a partnership for the gain of Google, but also for Adobe. With this new research, Adobe has founded formats in which Flash sites will be created, constructed and designed to therefore be optimised on the Google.

However people have been questioning as to how much does the Googlebot actual index? Will it take all part of the text content? Will it rank flash files (if multiple were found on a page).

Beussery.com has been doing some extensive research which can be found here http://www.beussery.com/blog/index.php/2008/10/google-flash-seo/

If you can read that code lingo and various scenarios then knock yourself out. I just read the first paragraph to get an idea, and avoided collapsing on my keyboard.

Source: http://www.vickylalwani.com/2008/10/16/i-am-google-i-can-read-flash/


The Top 10 Tips for Project Quality Assurance (Project QA)

October 20, 2008

1 Document Your Policies
You should ensure that you document policies for your project – remember that it can be difficult to implement quality if there isn’t a shared understanding across your project of what you are seeking to achieve. For example, see the QA Focus policies on Web standards and link checking.

2 Ensure Your Technical Infrastructure Is Capable Of Implementing Your Policies
You should ensure that your technical infrastucture which is capable of implementing your policies. For example, if you wish to make use of XHTML on your Web site you are unlikely to be able to achieve this if you are using Microsoft Word as your authoring tool.

3 Ensure That You Have The Resources Necessary To Implement Your Policies
You should ensure that you have the resources needed to implement your policies. This can include technical expertise, investment in software and hardware, investment in training and staff development, etc.

4 Implement Systematic Checking Procedures To Ensure Your Policies Are Being Implemented
Without systematic checking procedures there is a danger that your policies are not implemented in practice. For example, see the QA Focus checking procedures for Web standards and link checking.

5 Keep Audit Trails
Provide audit trails to record results of checking procedures. This can help spot trends which may indicate procedural failures (for example, a sudden growth in the numbers of non-compliant HTML resources may be due to deployment of a new authoring tool or inadequate training for new members of the project team).

6 Learn From Others
Rather than seeking to develop quality assurance policies and procedures from scratch you should seek to learn from others. You may find that the QA Focus case studies provide useful advice which you can learn from.

7 Share Your Experiences
If you are in the position of having deployed effective quality assurance procedures it can be helpful for the wider community if you share your approaches. For example, consider writing a QA Focus case study.

8 Seek ‘Fitness For Purpose’ – Not Perfection
You should seek to implement ‘fitness for purpose’ which is based on the levels of funding available and the expertise and resources you have available. Note that perfection is not necessarily a useful goal to aim for – indeed, there is a danger that ‘seeking the best may drive out the good’.

9 Remember That QA Is For You To Implement
Although the QA Focus Web site provides a wide range of resources which can help you to ensure that your project deliverables are interoperable and widely accessible you should remember that you will need to implement quality assurance within your project.

10 Seek To Deploy QA Procedures More Extensively
Rather than seeking to implement quality assurance across your project, it can be beneficial if quality assurance is implemented at a higher level, such as within you department or organisation. If you have an interest in more widespread deployment of quality assurance, you should read about the ISO 9000 QA standards.