Timothy Bowler

Before starting, I would like to tell you the two reasons why I want to share this. Firstly, the many books on scrum that I have read all talk about scrum in large corporate companies where the team might work on a project at a time. As I work in a small creative digital agency where we have many projects on the go, not to mention other influencing work - how does scrum fit in with us? The second reason is how to introduce scrum into a place where the core management do not really understand the scrum process and do not wish to know.

Early last year I heard about a management process called Scrum. As we didn’t really have any management process in place for the development team, I felt it necessary that we needed something. I began reading about Scrum, and could see the benefits that scrum would bring us. Before long, I booked myself on a SCM course, which was a 6 month wait. In the mean time, I decided to implement some of the scrum practices based on my understanding at the time. The first thing I done was bought 3 sprint boards, which were placed at the end of the office where everyone can view them. The following week we started to have morning scrum meetings. This was at most the very basic attempt at scrum that we employed.

Before letting you know of the results and how we actually benefited we did initially encounter many problems:

The morning scrum meetings

Every morning, we started off the morning scrum. This consisted of all the departments, and the stake holders. The problem this presented to us is, was there a need for the designers to be present when in most cases they where not needed and therefore produced waste. A knock on effect of having the design team there also sparked conversation. The result was a morning ‘catch up’ meeting that lasted up to an hour.

Of course reviewing the situation we ended up just including a PO, the SM and the team which of course worked better for us. However, the time boxed meetings still dragged on longer than the 15minutes.

The two questions that were eventually answered later where, should the designers be part of the team? How can be keep our morning scrum meeting time boxed?

Educating the team

Getting the top management to buy in was actually quiet easy, so to was the development team. However, everyone seemed to have a slightly different interpretation of Scrum. Of course this then produced mixed results like:

- Why do we needs morning scrum meetings when we can add all the work to trac and it can be monitored?

- How come we are not including the designers when we need to create GUI’s?

- User stories, story points etc what are they and we need hours!

These questions where later addressed too, but they were all fair points.

Sprint boards and tasks

To be honest, I found getting my head around user stories very hard. To me a task is a task, but creating user stories is a fine technique. Therefore tasks were usually a little to complicated and a little ambiguous. As of the sprint boards, sometimes task notes where tampered with and instead of having the notes in the order of the backlog they were very randomly placed.

The results

After 6 months and one scrum course I am now Certified Scrum Master. The course provided me with a wealth of information on scrum, not to mention the practical element showed me how to incorporate some of the practices. As a CSM I think everyone took me a lot more seriously which paved way for me to now fine tune the process.

The first problems that I addressed were the morning meetings and other small projects. Here I laid it straight, I ask the 3 quesitons and other than a reply no one should talk as we can arrange a meeting straight afterwards. Also, this was done standing around the sprint boards. Or other office based in Poland also joined in the morning scrum meetings as they too are part of the team. This resulted in a short and effective meeting, just like the scrum process dictates. The points as to why the relevant people have a meeting afterwards was to loose all the waste of everyone having to listen to a discussion that did not really effect them.

As of the other projects, we usually have 2-3 medium projects, then several tasks from many different projects that were mainly updates, added functionality, bug fixes etc. No book actually provided me with an answer. Therefore, the only thing i could think off is create an ‘other’ project that acted like any other project. This was welcomed and have been using it since.

The result of the problems were all overcome by simply educating everyone. To be honest we have seen vast improvements in our working practise. Some of the notable ones:

- Sprints on 5-10 days. Our clients instantly took to view and playing with the prototypes than the flat visuals that they were used to seeing. To quote one of the POs (as best as I can remember)
“We went over the visuals with the client, then before leaving I showed them the prototype and they loved it. I could tell they were still on the site after I left”

- Retrospectives formed an integral of the process. Having a retrospective after release highlighted all the pitfalls and good points through the sprint. It also serves as part of the documentation for ISO 9001.

- All management could see all the work being done at a glance by looking at the sprint boards. Also, the burndown charts are updated every morning so they are also aware of anything major, although just listening to the scrum meetings highlights this.

Another mis -understanding was using scrum along with scm tool. We use trac/svn as our source code management tool. Some of the developers though that just adding everything to trac without the morning meetings could be seen as more beneficial. But I reminding everyone of the key points

- Trac encourages collaboration to a certain extent, where scrum is total colaboration

- The PO’s don’t want to login to trac to see a list of tickets.

- Trac is for source code management, not managing the whole process.

- Problems would not be highlighted etc.

After everyone bought into this, a user story was accepted by a developer or pair of developers. They wrote the tests, documented it on the trac wiki and created their own ticket. Any additional information was added to the ticket and if needed the documentation on the wiki.

I have seen first hand how the process of just a system like trac in place can in fact let a project down.

Other things that I have learned as a result of trial/error, reading and attending events like the London Scrum Users Group.

When implementing scrum or introducing a client to scrum might help if you change the terminology. As we work with a lot of non technical peopel, the word scrum can scare people. Using words like process, release, release meeting, morning meeting, tasks etc masked the fact that scrum is present. I did find this useful and was something that I picked up from several people in the London Scrum Meeting.

User stories can be difficult to write at first. But after reading two books on user stories and agile estimation, some trial and error I finally sussed them, which had the benefit of more people understanding them and work being more accurate. A link to my linkedin profile and book review follows below in the list of other resources.

To use Scrum you either use it or you don’t. Of course implementing a few features can work but not as successfuly as following the process completely. One problem I encountered was slipping out of the process. One project suffered a great deal as a result of this.

Other resources
My linked in profile and book reviews

The london Scum Users Group linked group

The london Scum Users Group Wiki

This entry was posted on Thursday, November 20th, 2008 at 2:19 pm and is filed under Project Management, Scrum. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.