Low Budget Scrum Implementation / roll out
I recently worked with a group that wanted to roll out the Scrum framework in their development environment. As there were limited funds for training I put together a training slide deck that was mainly comprised of my May posts from this blog. I organized and put these posts into PowerPoint and presented to the team to be Scrumified.

Next steps were to organize the Team and do a slow roll per the management of this team. As this was not the usual Scrum implementation I decided to boil down the perfect Scrum Framework into their basic pieces as a starting point for the slow roll out. Below is what I came up with including pieces I like to support a successful Scrum roll out;

Scrum SharePoint Portal:

Whenever rolling out Scrum in a new office or with a new team I always work to ensure that all data relating to the teams new framework and processes are easy to find and public. The executive staff enjoys this visibility which always helps at budget time J

Scrum toolset:

This is one of those items that is always driven by the available budget. I have helped Scrum Masters create backlogs, metrics including the burndown in Excel to a very large worldwide implementation covering international and offshore teams in Microsoft’s TFS. Luckily this implementation used Jira and their Agile tool GreenHopper.

Create/Scrub the Backlog:

The list of requirements should be scrubbed and ideally put into user stories as quickly as possible. Remember, you want the user stories to be in bite size pieces that the team wants to sign up for. It is rare that a backlog is perfect when starting out, but as the framework and processes are solidified the goal is to always improve the backlog and to ensure it is in priority order.

Sprint Cadence:

The management of this team wanted 2 week sprints so I started them out with the below schedule;

·         Day 1

o   Sprint Planning 1 where the team works with the PO (Product Owner) to choose and sometime estimate what they will be doing in this sprint.

o   Sprint Planning 2 is the second meetings of the day were the team without the PO takes the chosen stories and breaks them down into the tasks needed to get them done.

·         Day 2

o   Team starts sprinting and this is where I start the 10 day countdown.

o   This is also the day that I put in the Agile tool being used to ensure the metrics / burndown chart are drawn correctly. If you start before all the Tasks are created the burndown can look real odd.

·         Day 6

o   I encourage the team to get with the PO mid sprint to scrub / estimate the backlog to ensure it is always in a good state which helps to ensure the Sprint Planning 1 meeting goes quickly.

·         Day 11-12

o   I have day 11-12 as some teams/management like to see the sprint review at the end of day 10 and some like the demo on the morning after the 10^th day.

o   A sprint retrospective should happen quickly after sprint end while it is still fresh in the teams mind.

·         Day 12-13

o   I have implemented Scrum where the team had a day between the last Sprint review and the next Sprint Planning Meeting 1, but I have also had where the team/management decided to have the Sprint Planning Meeting 1 right after the Last Sprint Review Meeting. Time and experience will help you to know how to best handle when to start the next Sprint cadence with your team. 

Sprint meetings Schedule (Early):

Below are the meetings that I always recommend to start with when rolling out Scrum. I ensure to schedule these meeting out at least one sprint ahead to lock in this time to ensure the execs have a space on their calendar to attend reviews and most importantly to ensure there is a meeting room available.

·         Planning Meeting 1: team chooses the user stories they commit to in their Sprint iteration with the PO

o   Duration: start with 2 hours

·         Planning Meeting 2: team use this meeting to break the user stories down into tasks without the PO

o   Duration: start with 2 hours

·         Daily Standup: If you have a meeting on their calendar it helps the team remember to get to the meeting on time J

o   Duration: 15 minutes

§  Best to have at the same time and same place every day

·         Mid Sprint Backlog Review Meeting: I like to have a meeting in the middle of the sprint for the team and PO to scrub/estimate the backlog.

o   Duration: start with 1-2 hours

·         Review Meeting: Scheduled at sprint end for the team to show off what they have accomplished and to ensure the PO agrees that the work is done

o   Duration: 2 hours

·         Retrospective Meeting: This is where the team can gives their feedback on how the sprint went.

o   Duration: 30 minutes

After getting past the initial resistance to change the team quickly realized that Scrum was for them. Their existing processes only needed minor massaging to match what is expected in the Scrum framework that I implemented for them. The team is now on their 2^nd sprint and we have been working through the usual items that can hinder a kickoff, below are a few;

·         The backlog was not in a form that could be easily consumed in a sprint

·         Many Stories were very large and we had to go through these and break them down into bite sized pieces. The team balked at some of these because they were concerned about getting the work done in the chosen sprint cadence.

o   Historically this has always been the hardest for the team to get. I will be covering how I help the teams through this in later posts.

·         In our first Retrospective the team let it be known that they wanted more time to create tasks for their stories that they agreed upon in their sprint planning 1 meeting.

I will continue my consulting with this team to help them improve their processes and I will share these here with you.