PROJECT HEALTH CHECK
  • Home
  • Services
  • Templates
  • Articles
  • About

Scrum Meetings: 7 Steps To Get Them Right

16/10/2017

0 Comments

 
Agile is a methodology which is getting more and more traction in the IT industry, to the point where the word is agile is thrown around out of context and with incorrect capitalisation. There are many variants, but a feature now common to many is the idea of a daily Scrum meeting to manage the work. In our experience, how this meeting is planned and executed will set the tone for the entire project, and how effectively they embrace the true Agile approach. Will it be truely Agile, or just "Agile", or even Watergile?

We've seen it done well, but also sometimes sickeningly badly - and made our own errors along the way. Here are our top tips for effective Scrum meetings:

  1. Scheduling: The Scrum should be at a set time every day without fail, early enough in the morning to set the tone for the day but late enough to ensure everyone is consistently in the office in time! I suggest around 9:30 - 10:00 is ideal.
  2. Timings: I suggest the Scrum should be 15 minutes in duration maximum top, short and sharp - any longer and you are just waffling. It should start on time precisely - be obtuse if needed to ensure this happens. If you're missing people, or they are having a chat then just start without them or over them - it might cause some angst for the first couple of meetings but team members will soon get the message. One problem is that many team members have poor time keeping - in fact it is our personal bugbear. Invite someone for a meeting at 09:30, and rather than be there ready, they will nonchalantly meander around to the meeting at 09:33 without a care in the world. To combat this we suggest that the meeting invite in calendars is scheduled for  a twenty minute period such as 09:30 - 09:50, but the meeting starts at earnest at 09:35 sharp. Use the first 5 minutes as buffer and for the obligatory morning salutations. Get a high quality visible wall clock, set it right and make sure everyone knows that is the master time clock - then there are no excuses! 
  3. Sprint Burndown: The Sprint Burndown is essentially your status report on the Sprint, it tells you as Project Manager as well as senior managers who take an interest, how the Spring is progressing. Have the Sprint Burndown on a screen for all to see when they assemble during the buffer time; this will help foster the mindset that it is a team effort and the entire team is responsible for that progress. 
  4. Stand Up: I'll be honest and say we didn't when I used to attend scrums, but I regret it. We always sat down and got nice and comfortable - then the meeting dragged on for half an hour. By physically standing up, it encourages brevity from participants.
  5. Agenda - Each scrum team member provides an update on 3 things during the Scrum: what they did yesterday, what they will be doing today, what is blocking their progress. As PM you should be particularly interested to the blockers, catch the team members off-line after the Scrum to see if you can help remove those obstacles.
  6. No Discussions - The team updates shouldn't morph into a discussions, if someone responds to someone or asks a question then the Scrum Master should start a visible egg timer in front of everyone with a 30 second time limit. As soon as that limit is reached you move on to the next update; discussions should take place immediately after the Scrum between the interested parties only, to stop wasting other people's time.
  7. No External Input - Only the project team can contribute, that is those completing Story Points and contributing towards Spring Velocity. As PM this may mean that you don't contribute and are not allowed to talk! It depends how you translate the traditional PM role into Agile - in our experience the Scrum Master was typically more of a technical lead role, but PMs sometimes are Scrum Masters and we have done it before. But definitely no senior managers or external stakeholder interrogating the team or asking questions - shut them up and kick them out! If that means you as PM needs to take heat to protect the team: so be it.

Do you disagree with any of these, or would you suggest any others? Let us know your thoughts in the comments below!

Stay Healthy! - Project Health Check projecthealthcheck.org
0 Comments



Leave a Reply.

    Mission:

    To understand why do Projects Fail and what we need to do differently to stop it happening again.

    RSS Feed

    Project Management Update
    Performance Measurement 2002 Planning Defining Process More >>

    Archives

    March 2018
    February 2018
    December 2017
    November 2017
    October 2017
    September 2017
    August 2017
    July 2017

    Categories

    All
    Agile
    Assumption Management
    Book Reviews
    Cancelling Projects
    Cost Management
    Dependency Management
    Governance
    Issue Management
    Knowledge Transfer
    Lean Six Sigma
    Lessons Learned
    Metrics
    PRINCE2
    Process Improvement
    Process Management
    Project Closedown
    Project Health
    Project Planning
    Risk Management
    Status Reporting

    Tweets by Proj_Health
Powered by Create your own unique website with customizable templates.
Photos used under Creative Commons from Feans, Dipartimento Protezione Civile, IN 30 MINUTES Guides
  • Home
  • Services
  • Templates
  • Articles
  • About