News, tips and cool ways to make the web realtime

At Pusher we’ve discovered that Scrum can be a useful tool for organising non-engineering teams – but not all of it. Here’s how we did it, what we found out and what you can gain from our experiences.

The Growth team comprises mainly of the non-technical functions of the company (marketing, agency support, etc) and it wanted to use the framework as a way of more effectively communicating and collaborating on ongoing projects.

Daily Stand-ups

An early win was establishing daily stand-ups. For the first few attempts we found that it was getting shuffled/missed as people came in late/were away/etc, so we quickly agreed to set a time and stick to it, with a rule that it starts on time no matter who’s there.

At our first retrospective we found that that the set time wasn’t working for everyone, as holding it in the middle of the day was proving too disruptive, so we agreed to move it to 10:30. One of the great things about Scrum is that you can try something differently for one iteration, and, if it doesn’t work, you’ve only lost two weeks.

Another variation is that we often use the instant messenger HipChat for our stand-ups, to include those who occasionally work from home. Although this goes against the concept of this meeting a bit, we find it works because it allows us to continue having daily real-time meetings, while including the maximum number of people.

Retrospectives

Another thing that has worked well for the team is the sprint retrospective. We use a fairly simple format of identifying five key questions to base our discussion around, which are:

What went well?

What could we improve?

What didn’t go well?

What did we enjoy?

What did we learn?

We stick these on a whiteboard and, underneath each one, everyone adds their responses on sticky notes. Once everyone’s done this, we get people to add their ‘+1s’ to any comments they particularly agree with, and discuss these highest-rated comments first.

Making this session an integral part of our iterations has meant we can adapt and change things early on. It’s also allowed us to have open and honest discussions about things that are causing us stress, invaluable at this stage in the process.

User Stories Schmuser Stories

One of the biggest headaches has been trying to define epics and user stories in a way that works for us as a team. A lot of stuff that’s written about this focuses on technical product development, not surprising since it originated in the extreme programming (XP) movement. A quick win was to change the names into something more meaningful – ‘epics’ became ‘projects’ and ‘user stories’ became ‘tasks’.

We tried the ‘as a… I want… so that…’ format, but it didn’t really catch on. We found instead that just writing a short description of the task (e.g. ‘add search function to support documents’) was adequate for our needs.

Sprint Planning Gone Wrong

This is the area where we’ve most felt like we’re trying to fit a square peg into a round hole. In traditional Scrum teams you have a number of cross-functional individuals working towards one product. The Product Owner prioritises the backlog and the team then selects which items it is going to work on for the sprint.

The idea is that, during the sprint, anyone can take any item from the backlog to help achieve the sprint goal (normally some kind of viable working product ready for release).

There are some areas of collaboration in our team, but generally we have individual areas of responsibility working on different projects. Our first attempt at collating and prioritising the entire backlog went disastrously wrong, as we all had our own individual priorities and projects we wanted to focus on and no clear sense of a shared goal.

As a result, we overcommitted on the following sprint, and selected items that generally the team felt were important, but that no one wanted to take on.

Sprint Planning Done Right

After a frank discussion at the retrospective, we discovered that what the team found useful was the communication aspects of sprint planning (being aware of and influencing what other people were planning to work on) but not the collaborative aspect (feeling that everyone had to work together in a way that felt false).

We’ve revised our planning sessions so that each member of the team brings their own items to the meeting (in effect we are all our own Product Owners), which they then present to the group along with their reasons for choosing them. The rest of the team then has the opportunity to ask questions and/or challenge this decision, if they wish.

It may be a move away from one of the original precepts of Scrum as a vessel for ensuring regular delivery of completed work, but making this change has removed an area of stress and enabled us to continue to feel good about using the framework.

Scrumish Scrumban

Going forward, it may make sense for us to move towards a Kanban-type model. Identifying work in progress limits may be a challenge, but an ongoing workflow will be better for the types of projects the team manages. We intend to try out some different methods and techniques over the coming months.

One thing that’s become apparent is that the Scrum process allows for constant review and change – as the Agile Manifesto says, “individuals and interactions over processes and tools” and “responding to change over following a plan”. These are relevant whether you’re a software or non-software team.

Whatever we do, it’s likely to be a combination of methods – we’ve taken the best bits of Scrum and chucked the rest away, to build a process that works for us.

Our department (QA) team is too small for scrum to be necessary, but we have an office scrum every morning across all departments, and it’s very helpful for us. I also sit in on Support’s weekly issue reviews, as they provide me some visibility into what sorts of problems our customers face in deployed environments.

Frances Bonnington

Thanks Sam – I love the idea of an office-wide Scrum standup, it’s something I’d like to introduce here at Pusher too. Just having that short conversation about what people are working on is great for improving communication and visibility.

Olivia Jennifer

Scrum
is the most commonly used agile process for projects specifically more
prominent for software development. As a product development framework scrum is
applicable for any type of projects. Whether it is minimal project requirements
at the start of the project or complex requirement which keeps changing
throughout the life of the project or even aggressive timelines to build the
product with the least time to market strategy, scrum is very effective.

http://payments.expertrooters.com Francesca

Excellent pieces. Keep posting such kind of information on your page.
Im really impressed by your site.
Hey there, You’ve performed an excellent job. I’ll certainly
digg it and in my view recommend to my friends. I’m sure they will be benefited ffrom this website.

http://hire.benchmarkcleaning.com/ Claudio

It’s truly a nice and useful piece of info. I’m happy that you simply
shared thiis helpful information with us. Please keep us informed like this.

Thank you for sharing.

http://test.com equally insanity

Quality content is the important to invite the users to
go to see the web page, that’s what this web site is providing.

http://apuestasdeportivasenlinea.tumblr.com Lourdes

What’s up to all, because I am actually eager of reading this web site’s post to be upddated
daily. It contains pleasant information.

http://privado.ocho.com Cecil

Thanks for some othr informative blog. The place else may I am getting that kind of info
written in such ann idral method? I have a project thbat I am just now running on, and
I have been at the look out for such information.

http://api.wpsocialexplosion.com/outlets/diigo/rss/3.atom Websites

Its like you read my mind! You seem to know so much about this, like you wrote the book in it
or something. I think that you can do with a few pics to drive the message home a bit, but instead of that,
this is excellent blog. An excellent read. I’ll certainly
be back.