Scrumming Man

I’ve been lucky enough to have work in a few organisations where Scrum has been implemented from scratch so feel I’ve got a good idea of what it takes to implement Scrum in such organisations. Below are a few tips that I’ve found helpful….

Continue reading

I previously blogged about my upcoming Product Owner course which I completed last week. The course was run by Agil8 and David Hicks in Central London. Having already used Agil8 for my Scrum Master certification I was familiar with David and his approach to training.

I’ve never performed the role of a Product Owner but with the relationship between Product Owner and Scrum Master being so vital I felt the course would be beneficial to gain a further grasp of the PO role. There was quite a lot of overlap between the CSM and CSPO course content so whilst a fair chunk of the course material wasn’t new to me, it’s always nice to re-affirm what you are doing and why you are doing it that way.

Continue reading

Recently the team I am the Scrum Master of has started using an electronic tool for tracking stories, tasks and sprints. Whilst I do not object to using such tools for Scrum I feel a common misconception is that these tools are required for Scrum to be successful. My personal preference is to run a manual Scrum board located very close (if not in) the area the team operates. I find this works best and keeps the process low ceremony and acts as very valuable information radiator for the team, stakeholders and anyone within the organisation. The temptation with just an electronic board is to leave it all in the tool which means if you do not have the URL of the tool you have no idea of progress of the current sprint or what is in the backlog.

I also find tools to some degree contradict part of the agile manifesto

Individuals and interactions over processes and tools

Tools can be valuable but are they essential?

JIRA

I’ve used JIRA in previous teams and have found it to be one of the better tools I have used. It is a very mature product from Atlassian which means it has a very strong base. The JIRA Agile plugin (or Greenhopper as it was previously known) is a must. This plugin allows electronic versions of the backlog and scrum boards (it also supports Kanban) with a drag and drop interface for ease of use.

To be fair to JIRA and other tools they do provide some positives

1. For distributed teams or distributed members of a team it can be very difficult for them to see the physical board so an electronic tool can be useful here
2. Tools such as JIRA Agile allow story artefacts such as designs, documentation, wire-frames to be attached in one central location rather than emails or print outs.
3. Most tools auto-generate the sprint reports such burndown charts, velocity reports etc

All in all I think a tool can help a Scrum team but I always manually replicate anything in the tool to a physical board. It’s more work for a Scrum Master but I class the board as an integral part of the process for which the Scrum Master is responsible for.

The Product Owner I am working with at Monarch has recently tidied up the backlog board and made it nice and easy to understand.

Here is a picture:

The layout is nice and simple and becomes a very valuable and important information radiator for the team. It also advocates the Scrum principle of “transparency”. Anyone can see where an item of work on the backlog is and its current status (on hold, requires estimation, not ready for dev and ready for dev).

Pleased to say I am attending the Certified Scrum Product Owner (CSPO) course next week. I did my Scrum Master certification around 18 months ago via Agil8  and will be doing the CSPO with them too. I was very impressed with Agil8 and David Hicks course content on the CSM as they provided a good level of theory as well as practical exercises and experience from David and his 20 years working in software teams and using Agile methodologies.

Continue reading

Scrum is not a new concept in software development but I find that a lot of people think they are practicing Scrum when they really aren’t. Near enough every job ad asks for “Agile methodologies or Scrum experience” but from my experience of interviewing and attending interviews very few people are doing Scrum as it was defined.

What is Scrum

In order to “do” Scrum you have to know what it is. The following summary is taken from the Scrum Alliance website (http://www.scrumalliance.org/why-scrum) which i think sums up Scrum pretty well:

• A product owner creates a prioritized wish list called a product backlog.
• During sprint planning, the team pulls a small chunk from the top of that wish list, a sprint backlog, and decides how to implement those pieces.
• The team has a certain amount of time — a sprint (usually two to four weeks) — to complete its work, but it meets each day to assess its progress (daily Scrum).
• Along the way, the ScrumMaster keeps the team focused on its goal.
• At the end of the sprint, the work should be potentially shippable: ready to hand to a customer, put on a store shelf, or show to a stakeholder.
• The sprint ends with a sprint review and retrospective.
• As the next sprint begins, the team chooses another chunk of the product backlog and begins working again.

Continue reading