No Scrum Master? Is it still Scrum?


What happens when the team gets all the training about Scrum, begins to kickoff the process but they don’t have a Scrum Master?

There are arguments (some legitimate and some not) to justify why Scrum will work without a Scrum Master. First, let me say that a Scrum Master is a role not a title so there really shouldn’t be any restrictions on who can fulfill the role.  Second, someone should take on the role and really dedicate time and energy to give the team the support they deserve. Check out Mike Cohn’s blog about Rotating the Scrum Master Role.

SAM_2306So what work does a Scrum Master do that now needs to be covered by someone else or the team as needed?  There have been a number of response to this question all over the internet and books so you’ve all probably heard that standard answers of remove impediments, champion the process, shields the team from outside interferences, etc. but I’d like to take it a step forward or maybe sideways.

Scrum Masters are champions for the team, their decisions, their delivery and even their failures. They are constantly looking at how the team operates from both an internal and external lens; one that the team members are very rarely able to use because they are in the thick of things and may not have the objective eye.  When a Scrum Master is able to identify things that are impeding the team and help them discover it rather than point a finger, jump up and down and demand they fix it, a bond is developed between the team members that gives them the confidence and trust that someone is looking out for them and is there to help them achieve their next level of expertise.

Eventually, a Scrum Master should find that the team needs their guidance less and less over time.  There are a few exceptions to that.  Teams that are dispersed  teams that gain new team members, teams that experience growth and then split (scaling scrum) will need more time and attention from their Scrum Master during these times.  They may have been experts at their process and become self managing but anytime the dynamic changes, there will be more to talk about, more to decide on and generally shakes the team for a time.

Another thing to note is that Scrum Masters are not Project Managers or even Tech Managers in their primary role.  There is a tendency to do this and it’s a dangerous thing because it can taint decisions and imply a level of power and control that should be absent from a Scrum Master.  Members of a scrum team should continue to rely on their managers and peers to improve their level of skill and professional growth whereas a Scrum Master may notice and relay recommendations about team members to their manager as a way of keeping the health of the team and growth of the team moving in a positive direction.

Hope this helps some of you!

Coach in Manager’s clothing…errrr what???


It is not a new question to ask who should be the Scrum Master when you’re starting a new team or beginning to use Scrum in your existing team. There are so many different opinions and advice on this that when I reached out to my fellow agilists, I got a lot of different answers. My friend and agile coaching mentor, Eric Willeke, sent me a link to Ester Derby’s blog post that speaks about the qualities, the warnings and her experience with different choices in choosing the right Scrum Master.

Switching to Kanban – Wise or Worthless?


Reposting an article from a fellow agile blogger
http://fragile.org.uk/2010/01/the-switch-to-kanban/

Timeboxing the Sprint Review, Retro and Planning in a Single Day


Prep work for the Project Manager, Scrum Master or the like:

  1. Break the meeting scheduled in calendarto explicitly time box the Sprint close from the Retro (maybe two separate meetings in calendar)
  2. Have a set agenda posted along with detailed descriptions as noted below (Customize as you like as a team) for the Sprint Close out and Retro sessions as a reminder of the flow of the meeting.  Posters or even a wiki page with the info is good.
  3. Move any retrospective item that you accomplished in the last sprint from the improvements/retro poster to a “completed improvements” poster so you can reference things you did and agreed to do over time.

Sample agendas for the last day of the sprint:

  • Team Prep Night before Sprint Close out
    • Remind the team to close out any task(s) that they completed in advance so that all you have to do during the Review meeting is do the QUICK CLOSE on any stories with zero remaining hours at the story level. This will set status to Done and zero out the remaining hours of the task in one click
    • Confirm any unfinished tasks/tests that are not done, update the remaining hours, make the task estimate the same number as the new remaining hours number (this helps with capacity planning for the next sprint)
  • 930-10am Sprint Review and Close out
    • Confirm which story and defect is complete (QUICK CLOSE the story)
    • SPLIT any partially completed story to move the unfinished tasks/tests to the next sprint and then
    • CLOSE SPRINT
    • After everything is done (sprint closed and new sprint activated), this is when you can move into the RETRO section to talk through why the team is completing more or less story points each sprint.  If an idea comes up during this discussion, this is a perfect time to slide into the Retro portion of the day
  • 10am-11am Sprint Retrospective
    • Review the VELOCITY TREND report on the  Sprint Planning/Sprint Scheduling section and discuss what the team is doing that is causing the trending to be what it is. Are there some improvements they could be making to improve it? Are there some things that the team is doing that is making a positive difference to the trending?
    • Look at the Retro poster (or wiki) to see what improvements the team has talked about in the past. Are there new ideas to add? Has the team completed some of the items already? CELEBRATE them!
    • Vote on which item(s) the team would like to tackle in the next sprint. Maybe there is more than one that can be accomplished?
    • Add a story card to your sprint backlog for each item the team agrees they want to add and assign the owner(s) that will be responsible for doing the work it will take to make the improvement and/or providing updates on it throughout the sprint as requested.

11-Noon Product Owner/Scrum Master Prep Session

    • Add new stories to the sprint backlog that should be considered in sprint planning
    • Remove stories that should be moved out of the sprint
    • Review any blocks, issues or impediments to resolve them or pull stories out of the sprint if they are not resolved yet
    • Prioritize the sprint backlog (will review again with team at the sprint planning session)
    • If time permits, plan out the stories a few sprints ahead as a “request” to the delivery team and to assist with forecasting/scheduling
•    1-4:30pm Sprint Planning (entire team include Product Owner)
  • 1-1:45pm – Story walk through and Estimation
    • Product Owner walks team through the stories they would like to consider for the sprint, should include the story description, user acceptance criteria and stop to add more detail or to explain any new stories that need additional information so that the team will be able to size/estimate the story
    • Team members “sign up” for stories they would like to work on (add themselves to the OWNER field on each story)
    • Team sizes each story after all have been reviewed based on relative sizing technique (“smaller than this, bigger than that”)
  • 1:45p-3:45pm – Story Detailed Planning
    • This time is informal and time to self-organize!
    • People tend to group together as needed by story to detailed out the tasks that each person will be doing on each story, entering the tasks/tests as they discuss and then estimating the hours for their work
    • Each team member should look at the Sprint Planning/Member Planning page to see who is over allocated based on their assigned work against their offered capacity.  Talk to other team members to help them out by discussing how to spread the work more evenly across the team.
  • 3:45p-4:30p – Sprint Plan Commitment and Kickoff
    • Review the Sprint Planning/Member Planning to ensure no one is over allocated
    • Review the total story points planned for the sprint – Is it higher than the trending velocity? It’s ok to go a little higher if work was partially finished in the last few sprints but the completed story points were low because of splitting.  Just remember to keep your new sprint somewhere between what you did and what you planned last time so you have a better chance of doing it!
    • Do a fist of five vote on the final sprint plan and you are ready to kick off the sprint!

If Scrum isn’t working could we try Kanban?


If your team is currently struggling in their Scrum practice, you may be ready to give up or try something else.  Kanban is becoming quite popular and I’m recently a Kanban convert so I can understand the allure especially having seen it work so fantastically for teams.  However, as a coach, it’s my responsibility to find out the root cause of the team’s problems with Scrum first.  Sometimes it’s a simple change that can get them back on track and well worth the cost savings of another training expense.Here are some questions to ask when scrum “isn’t working”:

  • Are the timeboxes too short? or too long?
  • Is the backlog volatile? (many priority changes during a sprint or changes in stories planned)
  • Are there impediments consistently through every sprint that delay the work of the team that are either not resolved or outside the team’s control?
  • Is team size larger than 9 people?
  • Is planning and forecasting of work being done and communicating?
  • How are the team’s stakeholders reacting to the scrum practices?
  • Is management supportive of the scrum team and their practice?

There aren’t right or wrong answers to the questions above, but they do give a good picture of where the pain points are with the team and their stakeholders so that you can take the next step which is to begin trying new techniques or refreshing old ones to get the team back on track.

So when do I recommend Kanban for a team?  It depends. Don’t you love that answer?!  It happens to be very true regardless of how flippant it may sound.  These are the cases where I’ve seen Kanban “fit” better for a few teams I’ve coached.

  1. Team A had been practicing scrum for years and very poorly.  They had varied sprint lenghts, team members that would be borrowed by another team for an entire sprint, non-existent Product Owner and never did estimation or forecasting for future sprints.  There was such a bad taste in everyone’s mouth for scrum that we decided it would be best to just try something new with less prescription and more adaptivity and a newfound energy to make it work with a strong agile coach.
  2. Team B had never done anything but Waterfall or organized chaos (which they self-admittedly claimed).  They were an operations team that had several stakeholders across the company so their manager was essentially operating as a pseudo-Product Owner/Intake manager.  Kanban was chosen since the work they received was a steady flow of changes deployed as soon as they were completed.  Kanban works really well for maintenance and operations project teams since the work is relatively the same size each time they receive a new request, sometimes small and mostly steady for those teams.
  3. Team C had been practicing scrum for over a year and they consistently met only 50-65% of their sprint commitments.  After repeatedly trying to get the team to accept less into their sprint plan (4 week sprints), reduce their sprint length to 2 weeks and getting their team members cross trained, I decided to show them how to implement Kanban flow and WIP Limits into their sprints; the ScrumBan approach.  We created more “states” on their sprint board from “Not Started, In Progress, Done” to “Ready Queue, Dev In progress, Dev Done, Test In Progress, Test Done, Demo and Done”.  Then we updated the WIP limit for each state. These two small changes would allow them to see how long it took for work to progress through each stage, limited how much they could do and also raised awareness across the team where work was not moving.

Some important things to remember with Kanban is to be diligent about keeping the ready queue current and populated for the team so they can keep moving through the backlog, and honoring the WIP limits and adjusting them as needed when you first start out so you can find that sweet spot.  Equally important is metrics.  Too many teams forget about this or use it just as a status report but don’t take the time or know how to really analyze the metrics so they can explain the cycle time for outliers, make improvements or adjustments on the WIP to smooth out the flow and reduce the bottlenecks and watch the CFD (Cumulative Flow Diagram) to see trends so they can highlight success areas and recreate those situations to have more in the future.

Scrum Tuning – Google Experience


Scrum in Under 10 Minutes – HD


I’ve used this to share with new students and it’s been the best, quickiest and most simple way to explain what Scrum is…

Kanban as an alternative to Scrum


Here’s a list of sites that are good resources for Kanban instruction and introductories:

Scrum 1:2:2 (Month One:Week Two:Day Two)


This is my second day of the second week of my first month at my new job.  The differences between me and the other Scrum Master are really style at this point so it doesn’t make sense for me to sit in on all of their meetings anymore.  I’ve been focusing on the Business and the process they go through today to get work done.  Boy, it’s a mess!  There are, by title alone, about 3 Project Managers for just about every area of the business and they don’t seem to talk to each other much.  The PM at the outer most realm of the actual delivery team doesn’t really know when or who works on their request and they appear to communicate solely via email with questions like “What’s the status of x?” and “Is anyone working on Y?”  The most important thing for our teams right now is to find out WHO is doing WHAT and WHEN are they going to be done.  There is work being done already but it’s unclear who has been assigned or what their schedules are.
Using my connections through LinkedIn, I was able to find out more than the Product Owner candidates resumes told me.  Our interviews for the new Product Owner are coming along but they won’t start by the time we kick off our first sprint.  In the meantime, I’ve created a draft backlog with Business Owners, Resource names, Roles and requested launch dates so we can begin collecting every project known to the team.  We’ll need to discuss what work must continue, what work should be transitioned.  As busy as it seems and chaotic as it is, this is when I get excited because bringing clarity to chaos is my specialty.  Bring it on! My goal of getting the Scrum Teams trained and in their first Sprint Planning session by the 18th of August is too aggressive considering we don’t have a clean backlog and we are still missing the Product Owner and a Dev Engineer.  I met with the team today to formally introduce myself as their Scrum Master and to share everything I know about our teams, our workload and began our first exercise of team building by voting on simple things as a team. I made sure to include everyone when asking for their input on the team make up (even the one UI guy that had to call into the meeting), and made a point to use words that were team friendly – the “we”, “our”, “us” and “this team” so that everyone begins to hear and feel how being part of a Scrum team will be. We agreed on staggering the sprint start and end dates from the other two team in case we ever need to be at their sprint planning sessions for cross-team impacting stories.  We agreed that our team’s core working hours will be between 10:30am and 3pm to accommodate everyone’s individual schedules.  Two other decisions that will be decided during our Scrum training in two weeks are the team name, the sprint length and the inclusion or exclusion of the User Experience designers as part of the team.  Our resource plan looked like this for our initial discussion:

  • 1 Scrum Master
  • 1 Product Owner
  • 2 Dev (Sys Eng)
  • 2 UI Designer
  • 2 QA Tester
  • 1 CMS Eng
  • 1 DBA
  • UX (Need to confirm if this role will be in the team or not)

We have enough people to start with two teams but we’re thinking of starting out as one team, focus the first few sprints on Knowledge Transfer between team mates in the same role and then split out to two teams once we can function as two independent fully functional teams.  The team seems to be open to that so we may end up there by the end of our next team meeting.
One of our partner teams is not sold on Scrum so he’s asking many of the standard questions about how Scrum works with UX, what are the processes and procedures for how team members work together and where are the data flow diagrams and detailed documentation which is usually not dictated but rather organically grown as the team or teams mature.  This is an area where I need a successful Scrum engineer to share their successes and failures with different Scrum team make ups.  I want to know what they started with and what they ended up with and what scenarios they went through to get to success. Anyone know someone who’s done it? I’m reaching out to some of my Scrum forum groups to see who I can connect with.
Here are some links I found searching the web:

 

Scrum 1:1:3 (Month One:Week One:Day Three)


Long day yesterday so I’m late with my blog so I’m catching up while I ride the train to our other office.  I observed Sprint Planning for each of the first two teams.  This is their fourth sprint so they are working quite well together.  There is open dialogue about stories and their purpose, detailed tasking of the work to complete each story and consensus about how detailed they should be on day one of the sprint.  Occasionally, the conversation would dive a little deep into solving but their Scrum Master was able to redirect them as needed.  Many of the team members are fairly new to the company and new to Scrum so the relationships and communication styles are still in their infancy.  Even still, they have a very respectful and open tone across the team.  That also describes my relationship with their Scrum Master.  We’re spending a few hours a day sharing insights on the team’s maturity as well as his own delivery style to uncover any opportunities for improvement.  It will be a welcome exchange once my team begins and he observes my style firsthand.

%d bloggers like this: