The things we weren’t told about Scrum
2010 February 22
This is a short presentation I first delivered at the MIH Tech conference in Prague last year, and then touched up in February 2010 to deliver to a local tech team that is in the process of implementing Scrum.
The main areas I cover are the challenges of innovating within the Scrum process, how to use Scrum techniques for non-Scrum teams, and the key things we’ve learned about Scrum over the last 2 years at 24.com.
Comments are welcome ; )
The things we weren't told about Scrum
View more presentations from Tim Gregory.
Related posts:
6 Responses
leave one →
Hi Tim – nice presentation, thanks for sharing (I found it through a tweet from @gvrooyen).
If I may add something, I think another reason why Scrum often has challenges, is because it has the danger of being too focused on the sprints, and not focused enough on the overall customer journey. If the focus is too much on getting the next sprint done, and prioritizing the backlog, it is easy to forget the overal product vision and end goals.
As a Product Owner / Product Manager, this is part of my job — to make sure that our sprints not only address customer and business needs effectively, but also that each sprint gets us closer to the product vision. I’ve found that customer journey research and customer lifecycle planning really helps to focus everyone on the team on those end goals.
I also sense (and maybe I misread the presentation) that the Product Owner is almost seen as an outsider — someone who needs to be convinced. I believe the Product Owner should be so embedded in the team that he/she is not seen as a roadblock, but a facilitator that helps to make sure the product you launch is going to meet user needs.
Anyway, lots more to say, and this is an interesting discussion. I am moving back to SA in March and would love to catch up — really enjoying your blog.
Rian
Hi Rian
thanks for the comments. You’re right – in some senses, the Product Owner is a bit removed from the team in our organisation.
In part this is because our PO is focussed on one area of the Publishing business, but our main Scrum team is in fact a central resource that needs to do work for other parts of the business.
The setup is not perfect, our Product Owner doesn’t really own the full backlog, and we can’t dedicate a Scrum team to each area of the business that needs tech resources.
Also, our Product Owner typically comes out of a Publishing/Content production background, and would not own the technical part of the backlog – dealing with accumulated technical debt, system upgrades, technical investigations etc.
There has never been any pushback from the Product Owner in these areas, but the PO would also never put these on the backlog without prompting, nor focus on ‘keeping the saw sharp’ and ensuring that some innovation happens.
Hi Tim,
Thanks for sharing this.
I’m curious about your slide #11 (whiteboards as info radiators).
Question:
When, during your Sprints are the team members working on mock-ups, info architecture, use-cases etc. Is it ‘right when they begin a particular story’ , or is there some sort of pre-planning that goes on at the start of a project which captures the high level structures or relationships in a web project?
In our move to Scrum, I’m finding that we’re being encouraged by our Scrum master to tackle the design / use cases just when we start that particular story. And I constantly worry that by not having some of those ideas fleshed out earlier, we’re coming up with solutions which might not mesh well with stories that have yet to be tackled, further down the product backlog.
Your Whiteboard radiator, kind of looks like a bunch of that planning up front, or maybe it’s simply a displat of what has already been accomplished.
What’s your take?
Thanks,
Dom
Hi Dom
We handle this in a couple of different ways – for some of the stories, the discussion about approach, architecture, design etc happens during the task estimation, and is fleshed out during the task breakdown.
We try to keep stories small – if we get an estimate of more than 20 points (i.e. a 40-pointer) during estimation, we usually try break it down into smaller pieces of functionality. Usually possible, but not always.
There are 2 reasons we try keep the stories small – we would rather have 2 stories on the board than 1 big one for efficiency, and also the team knows that they don’t get any of the points counted in the sprint if the story is not 100% complete. Smaller stories means it’s easier to achieve a steady throughput and velocity.
That’s the one way of doing it.
Another approach is for me to look ahead into the backlog, and if I see stories that are particularly gnarly and it’s likely that when we reach them the estimates will be difficult because the technical design or some aspect of the technology is unknown, then I’ll create a spike boxed to a specific number of points (we usually make them 5 points for what that’s worth), and the output of the story is an investigation and some documentation regarding the approach to be taken when the real story is tackled. The idea is that enough work is done to enable a clear approach and accurate estimation of a future story.
It could be argued that this is not truly agile because we’re doing work in this sprint that supports a story in a future sprint, and there may be wasted work.
But for us it makes the whole process run more smoothly.
The third way we tackle this is to simply create stories that address the architecture / design directly – along the lines of “create a technical architecture that will allow user personalisation of all our sites from mobile phones”, or “have a whiteboard session to discuss the use of cookies on phones for authentication vs. tokens on the URL”. Later stories will build on this work.
I have no idea whether this breaks the scrum rules or not, but it works for us.
The relevant bit about the whiteboards is that they are in our corridors on display for anyone who wants a realtime snapshot of what’s going on, and contain pretty much everything we are working on, including exploratory stuff, testing, deployment etc.
I’ve had business managers ask me for regular status updates, and I always simply invite them to attend standup and to scrutinise our boards whenever they would like to.
Dom, take a look at http://www.agilemodeling.com/, and keep an eye out for Scott Ambler (for instance, a great interview here. Smart guy and very pragmatic and practical. He seems to get the Scrum True Believers in a knot pretty often, but he has a lot of valuable stuff to say. Scrum is great, but it’s (intentionally) incomplete – you need to add in your development and management processes along with it.
Just taken a look at the Slide 11 you were referring to – this is actually the use of whiteboards and an agile approach in a web development team that DOESN’T use Scrum! These guys use a combination of formal project management techniques when they are on conventional projects that have a defined start and end (like the site redesign pinned on the board), and some agile techniques for their maintenance and incremental work. They don’t use Scrum and shouldn’t, but they have picked out some of the useful elements of Scrum like the daily standups, whiteboards to manage project progress, regular retrospectives etc. But they don’t have a backlog, and they have a formal project manager running the project. Slides 13 & 14 show a project team on a traditionally managed project gathering for a short daily standup around the designs for the new site. Not Scrum, but some Scrum ideas and techniques being used.