Focus Courage Respect Commitment Openness

Scrum Values apply to all the team not just the Scrum Master or Product Owner and they are Values that can be effectively applied to Agile and traditional waterfall methods. When moving from waterfall to Agile there values are the first thing for the Scrum Master to get the agile team to buy into.

 

Focus – Team focus and Sprint goals are important responsibilities for the Scrum Master. The Scrum Master should remove impediments from the Team and protect the Scrum team members from external influence.

 

The Product Owner and Scrum Master should be responsible for ensuring a well groomed backlog which is both estimated and ordered and the team should be fully be focused on delivering the work committed to in the sprints.

 

Courage – The Team member must have the courage to speak out and ensure that their contribution is heard but with an openness other. The. Scrum Master needs to have the courage to negotiate with stakeholders and the Product Owner when it’s right to do so!

 

Whilst at the same time the Scrum team needs the courage to commit to as much work as possible within the Sprint whilst respecting the definition of done.

 

Openness – This is a core Scrum Value that makes Agile so much more effective than traditional management.

 

The Back log should be fully qualified and visible so that everyone is aware of what work is up and coming. The retrospective must be fully open with problems openly discussed

 

Commitment – The Scrum team commits to what they will complete each sprint. They also commit to how the work will be ‘done’ and to meet the Definition of Done.

 

The Team commits to doing whatever is collectively necessary in order to meet their goals.  The wider organisation also commits to support the scrum team and to respect the values of Agile.

 

Respect –This is perhaps one of the important values in Agile… And sadly one that I often observe is not followed! The Product Owner gets to dictate what work gets done and in what sequence – And it’s the responsibility of the Scrum team to respect those decisions. However The Product Owner must trust and respect the team to decide how they will accomplish this and respect the team when they push back or if they believe the Product Owner is encouraging them to overcommit. The Scrum Master should be aware that they are not management but the servant leader responsible for ensuring that the Scrum team is able to run at maximum efficiency and to coach stakeholders, Product Owner and the Scrum team on all things agile!

 

At Althris Project Management Training we have some tool and Agile games to help get the team focused on these values. For further reading I suggest you look to see what Ken Schwaber says about the Scrum Framework for software development.

Make no doubt about it the early scrum (Planning and Daily)  meetings set the tone for all the following activities of the project. With Scrum, life cycles are short and the pace hot with little time afterwards to re-jig team attitudes and behavior.  With the early meeting setting the tone for the rest of the cycles I suggest that you create an additional scrum kick-off meeting.  This can help to ensure that subsequent scrum meeting are focused on the scrum job and not the “ground rules”

This Scrum kick-off meetings gets the getting to know how it works out of the way. Subsequent team meetings will need to be rapid stand-up ‘huddles’ lasting for all of 15 minutes, you don’t want your kick-off meeting to seem too leisurely. Yet you also want to take enough time to set the scene properly for future success. The following tips may help:

  1. Remember that Scrum is also about trusting people’s ability to solve problems. The team may be the best source of answers for some questions that arise.
  2. Make sure your whole project team is there, for full input and engagement. Change the date to accommodate anyone who has a schedule conflict.
  3. Notwithstanding quick-fire project meetings in the future, allow plenty of time for the kick-off meeting.
  4. Make sure team members get to know each other. Fun exercises and games are one possibility.
  5. State or remind the team of how Scrum works and the roles of the Scrum Master and project team members.
  6. Agree on definitions (when is a deliverable truly ‘done’) and project tools (specific project management and issue tracking software, for instance).

When you get steam up on your Scrum process afterwards, remember that from time to time, it’s good to have periodic get-togethers along similar lines to the kick-off meeting. This can be an important factor in maintaining team enthusiasm, cohesion and momentum.

Inside every project manager is an ‘agilist’, trying to get out. In fact, that’s true of everyone in a project team. While the status quo and comfort zones have an undeniable attraction for our lazy streaks, we’re not made to do the same things over and over again. We may be apprehensive about change, but we also need it. The perils of endless repetition include boredom and rapidly increasing error rates. So what’s the answer?

A little root cause analysis will help here. Change is stressful when it involves the unknown. We worry about whether we’ll feel good about what comes after, compared to what we had before. When constant change is a fundamental part of an agile project approach, it can turn into a real tug of war between the urge for variety and the fear of failure or degradation of a situation. The pressures of project sponsors and end-customers for delivery of new products or services then exacerbate the problem.

But good methods for managing change and succeeding with agile methodologies can be learned. Agile project management may be characterized by fast-moving activities focused on action for rapid results. Yet it still relies on well-defined concepts and techniques to work successfully. It can be taught, internalized and then applied with confidence – and therefore without stress or worry – about the quality of the output of each agile cycle. Going agile and embracing change can then become a source of satisfaction for all concerned.

 

When interest levels of the project sponsors drop, it’s bad news for everyone. Bad for the business that has invested resources. Bad for the project manager and team who find themselves without an essential source of support. And bad for the end-user who may then get a product or service that doesn’t meet requirements or simply dosn’t get done.

Perhaps the wrong sponsor was chosen by the business and they were never interested in the first place. In any event is is critical to have and maintain project sponsor engagement, there is no formal methodology for doing so. Some project mangers are afraid to manage upward or don’t quite know how. Teamwork between the project sponsor and project manager is the way to create really effective projects.

Here’s a few suggestions

  • Common sense – Make sure you think your tactics through
  • Understand your sponsors perspective, agenda and how it does or dosn’t align with the project goals
  • Seek to understand why disengagement has set in, workload, disapproval of change, people issues
  • Communicate – as a project manager you are a senior staff member and tackling the head-on may be the way, Let the sponsor know you need the support

If you still cant get a re-engagement don’t undermine the sponsor but perhaps seek out other stakeholders that can provide the necessary support in the organisation. This can be often be done with the permission and support of the main sponsor. Particularly if the disengagement has happened as a result of workload.

If you are still stuck and the project effectiveness is being undermined you will need to go all the way to the top.

 

 

“Just say No.” How many times have we heard that advice? In some situations, it may be the best or even the only course of action. But for customers eagerly pushing for extra features or accelerated delivery schedules for a project, being that blunt could cause problems. On the other hand, appearing indecisive or setting up false hopes may not be a good idea either.

To start with, when do you need to say “No”? In project management, a “No” is often the result of the ‘Iron Triangle’ of features – schedule – resources. If your customer wants a change in one of these factors, then at least one other element must also change. If your customer can’t or won’t accept such related change, then the answer to the extra feature request can only be ‘No’.

Communicating that ‘No’ may be done best by a short, friendly reminder about the current project goals, timeline and investment. Done the right way, a ‘No’ in this case also has two advantages. It shows your customer that you’re on the ball. It also demonstrates that you’re looking out for the customer’s interests, ensuring that the project will be completed on time and on budget.

Are there exceptions? Feature requests and schedule changes might be handled as part of an agile process, with appropriate re-planning or re-prioritization between cycles. But even with agile, sometimes it just has to be ‘No’. In that case, take the opportunity to demonstrate your professionalism and any short-term disappointment is likely to be outweighed by longer term customer satisfaction.