Friday, 19 September 2014

Scrum – Don’t implement it without being trained in it

Imagine you are just about to start on a very important project – big budget, all eyes on the team, the kind of project you dreamed of. The whole team is all geared up and ready to get on with the work. When on the first day of the project, the project manager walks in with a lot of enthusiasm and says – ‘Guys, I just read this article about this really cool methodology called Scrum. Everyone has these daily standup meetings every day, decide what they will be working on, do it, and then meet again the following day. I think we should give it a shot.’
It just got better, didn’t it? A big project and a cool new methodology! Not quite, as is often revealed on so many projects. Admittedly, the dialogue of the project manager was simplified, but essentially, this is how a great methodology is set up for failure. Cut to a week later:
Team member 1: ‘Why do we need to stand around? There are chairs around. We can just sit, right?’
Project manager: ‘That is what the methodology says.”
TM 1: ‘But why?’
Project manager: ‘Something to do about if people stand, meetings are shorter’
TM2: ‘But our meetings typically last for an hour or so and it is so tiring.’
Project manager: ‘We have to discuss so many issues. Obviously it will take time. If it is such a big deal, then you can sit.’
Thus begins a slow, but steady twisting of the tenets of Scrum and the team embarks on a slippery slope. As the team now begins to sit during ‘Daily Stand Ups’, the meetings increase in length from 1 hour to 1.5 hours, and sometimes stretching to 2 hours. With less time available for actual work, tensions increase. Team members start questioning the need to meet on a daily basis when on earlier projects they met once a week and things were more or less fine. Then from ‘Daily Stand Ups’, the format changes to ‘Alternate Day Sit Downs’. This affects coordination and as the gap increases between meetings, the meetings start taking a bit longer, or issues increase.
Slowly, other changes start taking place – the whiteboard where tasks were updated in the first week stop being used by team members. Instead, they revert to sending email updates. The project manager, not realizing the critical importance of each of these tenets of Scrum, not trained in Scrum methods and never having practiced Scrum, also starts questioning himself and accepts these changes. He keeps a track of ‘To be done, In Process and Completed’, but only at his desk. Other team members start to become more confused.
Now as the team had dedicated itself to Scrum in the beginning, switching to alternate traditional project management methods in the middle of the project leads to an even bigger mess. End result – a poorly managed project which started off with good intentions of using Scrum as a methodology, but failed because of lack of understanding of Scrum.
Scrum is a simple methodology but needs training in Scrum and guidance for first time users. Without it, critical elements end up getting twisted and the project heads towards failure.
Moral of the story – Scrum training is not optional. If you want to get the best out of it, get expert help in the beginning and only after thorough training, should you use it at work.

 To know more click on: http://www.scrumstudy.com/blog/

Thursday, 4 September 2014

Justifying an Investment, When and How?

For a piece of work to be initiated and continued with, it is imperative for the people involved to
justify the investment made by the sponsors in their work, be it an activity, a business operation, a
project, a programme, or even a portfolio. This is so because without a valid business justification
the sponsors may not initiate the work or continue with it. So, the team involved or the people

making the investment have to carry out an analysis of business justification.
Business justification demonstrates the reasons for undertaking a project. It answers the question
“Why is this project needed?” Business justification drives all decision making related to a project.
So, it is important to assess the viability and achievability of a project not only before committing to
significant expenditures or investment at initial stages of the project but also to verify the business
justification for continuance throughout the project’s lifecycle. A project should be terminated if it
is found to be unviable; the decision should be escalated to the relevant stakeholders and to senior
management. The business justification for a project must be assessed at the beginning of the
project, at pre-defined intervals throughout the project, and at any time when major issues or risks
that threaten the project viability arise.
Now that we understand what business justification is and also agree that an investment needs
to be justified for a piece of work to begin and continue, let’s discuss the factors that need to be
considered when justifying an investment. There are numerous factors a Product Owner must
consider to determine the business justification for a project. Some of the most important factors
are reasons for the project, business needs, project benefits, opportunity cost, major risks, project
timescales, and project costs.
Business justification is first assessed prior to a project being initiated and is continuously
verified throughout the project lifecycle. The following steps capture how business justification is
determined and assessed in a Scrum project:
• Assess and Present a Business Case
Business justification for a project is typically analyzed and confirmed by the Product Owner. It is
documented and presented in the form of a project Business Case prior to project initiation. Once
documented, the Product Owner should create a Project Vision Statement and obtain approval for it
from the key decision-makers in the organization. Generally, this consists of executives and/or some
form of a project or program management board.
• Continuous Value Justification
Once the decision makers approve the Project Vision Statement, it is baselined and forms the
business justification. The business justification is validated throughout project execution typically
at predefined intervals or milestones, such as during portfolio, program, and prioritized product
backlog review meetings and when major issues and risks that threaten project viability are
identified. Throughout the project, the Product Owner should keep the business justification in
the Project Vision Statement updated with relevant project information to enable the key decision
makers to continue making informed decisions.
• Confirm Benefits Realization
The Product Owner confirms the achievement of organizational benefits throughout the project, as

well as upon completion of the User Stories in the Prioritized Product Backlog.
to know more visit-http://www.scrumstudy.com/blog/justifying-an-investment-when-and-how/