TrueStar Thoughts

Scrum makes sense on paper.  It seems easy.  There are few rules for Scrum.  Transparency must make it easier for everyone to know what is being done.  Right??

Scrum, like everything, takes dedicated work in order to continually improve and reap the benefits.  I think one of the biggest challenges most companies face, is how Scrum is implemented and the focus for continuous improvement in each role.

Scrum is typically implemented by a champion within the company.  Sometimes this is one or two people, usually in the development team.  There are several articles on Scrum and also many courses on Scrum Master Certification.

As I began to learn more about Scrum and eventually implementing it at a company I worked for, I knew I needed executive support.  Someone who would help to protect the framework and let us have the chance to succeed.

We both became Scrum Certified and we even had a couple of other people get certified.  The role of Scrum Master was implemented pretty well.  The roles of the Developers were implemented well.  The importance of the role of Product Owner was not fully appreciated.

The Product Owner has to be involved in the Scrum process.  While their roles are pretty well defined; prioritize the backlog and accept the stories when ‘done’.  They also have to be available throughout the sprint in order to define the acceptance criteria, and answer questions during the sprint.  This usually takes more time than people think.  How much time will depend on the projects, people, and technology.

A company I recently worked with needed the Scrum Master about 20% of the time and the Product Owner about 60% of the time.  The challenge is the Product Owner was only available for about 20%, which required the Scrum Master to increase their time to about 30%.  This increase of time was mostly solving blockers because the Product Owner was not available.  Unfortunately, the Scrum Master cannot assume the Product Owner responsibilities and even with the additional time, the success of the sprints suffered.

Is this a problem with Scrum or is this the power of Scrum giving transparency to the real problems?  In this case, a resource constraint by the Product Owner.  Scrum does not promise miracles, but it does shine the light on problem areas.  Companies need to acknowledge and address the problem areas as they are discovered.  Failure to do this will prevent the company from receiving many of the efficiencies that Scrum was implemented for in the first place.

Change is difficult and getting everyone to really buy-in to the changes needed for Scrum to work can be too difficult.

If you are struggling with implementing Scrum, make sure you have the right people doing the right roles and that everyone is empowered to do their job.  This means they have the authority, knowledge, and time.

Agile, Scrum

This quick answer to this question is it is up to the team.  When starting to use Scrum or other agile frameworks, sometimes the Scrum Master needs to explain benefits to the Scrum team and management.  My experience is when developing software, management AND the developers expect to have software available to track the backlog, sprint, and schedule.

Most Scrum Trainers recommend not using a third party solution to manage the Scrum model.  Having implemented Scrum in a traditional software company used to the waterfall method, I agree with the trainers.

It is recommended that the Product Owner use Excel to track the backlog and Scrum team can use Excel to help track the burndown in the sprint.  See the Scrum Alliance for a spreadsheet template.   The Sprint Planning and tracking can be done by using an old fashion cork board.  This may seem like you went back in time, but this process has several benefits.

• Buying software to manage the process will set an expectation to all stakeholders that the process is being managed.  Not to mention that when a company invests money in tools, they expect to see quick results.  This can really set the team up for failure before they have the chance to succeed.
• Story cards on a cork board are inexpensive and engage the team in the process.  Remember that, once committed, the team is responsible for delivering the work.  The ‘how’ is up to them and the Scrum Master is responsible to facilitate the how.  The team is responsible for getting it done.Story cards are also extremely flexible and easy to move around.
• Story cards help to create the conversations that are so important for successful sprint
• Cork boards are highly visible and help to create the transparency that is so important.
• The team can figure out the best processes for them instead of complying with their initial understanding of how the software solution wants them to do Scrum.

Challenges that I have experienced when using software

• The product owner and/or stakeholders end up putting too much detail in the product backlog.  This can cause the team to spend more time creating estimates and also have a higher expectation of the accuracy given the additional information.
• The team begins to reduce the conversations because the software can capture more detailed requirements.
• Observers can tend suggest/manage the scrum team in order to attempt for them to become more effective.  This can be the most difficult part of implementing a strong agile methodology.

Scrum and other flavors of Agile processes require a high level of trust among team members and the executive teams.  It is generally understood by Scrum ‘experts’ that it will take a team about 2 years to really figure it out.  This needs to be understood and emphasized early on.  While 2 years seems like a long time, it doesn’t mean that the team is less productive than the traditional waterfall.  It just means the team needs to make mistakes and figure out how to get better over many cycles.

Agile, Scrum