Pen & paper Scrum – 10 days edition
True to the spirit of continuous improvement I just created new printout templates for a Sprint Backlog and a Sprint Burndown Chart for ten-day sprints with pen & paper Scrum.
Hope you find them as useful as I do.
If you're irritated about what pen & paper Scrum is refer to the original article.
Scrum with pen & paper
A friend of mine recently asked me if I'd know any good freeware tools for use with Scrum. Well, I told him, I don't have any first hand experience with freeware Scrum tools but there certainly are a few.
However in the case that you're just starting with Scrum I would argue that you might be better off without tools. All tools force you into some kind of process that works for somebody else, but might not be optimal for you.
So instead of jumping to a fancy tool that comes with all the bells and whistles instantly, I'd recommend starting as low-tech as possible, learn the basics and discover your individual needs. After that you are enabled to get the Scrum tool that does exactly what you need it to do.
How do you start low-tech? Use pen and paper.
Ken Schwaber’s “Confusion about Scrum”
On December 31st 2009 Ken Schwaber posted his article "Confusion about Scrum" in the Yahoo ScrumDevelopment Newsgroup.
He states that
There are now two definitions of Scrum. One is maintained and sustained by Jeff Sutherland and myself at www.scrum.org. Another is an old copy that is posted at www.scrumalliance.org, by the ScrumAlliance.
His article continues mentioning what sounds like the start of a copyright dispute over the Chinese version of the Scrum Guide (English version) which in its original form is written and maintained by Ken Schwaber and Jeff Sutherland. Apparently now the ScrumAlliance claims ownership to the Chinese translation of the Scrum Guide (again the English version). As Ken points out
Any of you familiar with copyright law know that a derivative of the original is still owned by the original copyright holder.
Ken Schwaber recommends
that you refer to the Scrum Guide created and sustained by
the authors of Scrum, Jeff and myself.
This is serious news.
Attempting Scrum in a SDLC environment, pt. 2
In the first part of this article series, I covered the aspects of the real life office environment. This included the lack of physical space for pinboards etc. Go check it out.
In this second part I will focus more on the virtual environment, the tools typically used by a company following the traditional waterfall approach / SDLC and how you might still be able to use these tools for Scrum.
Bug tracking system
Let me start with the bug tracking system. Most likely your organization will have one of those. Typically issues can be categorized, prioritized and assigned to a person as well as tagged or grouped into releases. To make this tool work for you in a more agile way you could create a couple of additional categories and put everything (!) into that system: Don't put only issues into it. Also add things like feature requests, enhancements, documentation, testing and refactoring tasks. I'm sure you can come up with more with a bit of thinking. Just be careful not to make this more complicated than required... 
Well, that looks pretty much like a product backlog to me. You can do a printout of the overview and pin that to the board for better clarity. Stick it to the window with Scotch Tape if you don't have a pin board. In any case you should make this virtual backlog physical, otherwise the transparency will suffer. Only with a physical product backlog the team will have a clear idea about the big picture.
The overhead to maintain that printout would be minimal. You effectively avoid having two independent lists (in my experience always a recipe for disaster) and your not-so-agile management will probably be pleasantly surprised by the transparency you introduce.
Scrum and fixed price contracts
I'd like to draw your attention to a discussion that was in the Scrum Development group on Yahoo titled Scrum and fixed price contracts.
Go and read the thread for quite a few interesting points. In a nutshell though, the question was how Scrum can help in fixed price contracts. I think that's an interesting question since at first sight a fixed price environment - and hence a fixed time environment - is contradictory to the agility that Scrum offers in terms of rescheduling tasks that have not begun yet, replacing items with others etc.
The consensus in the Yahoo group seems to be that fixed price contracts generally are a bad idea, will fail and that Scrum will not help you with that other than in damage control.
Well, in part I agree to that. Fixed price environments are tricky. Maybe they come into place because the client does not trust the agency, maybe it is a new relationship. Maybe they come to be because the sales staff of the agency gives the wrong impression in the first talks and no one dares to tell the inconvenient truth to the client after that, before the contract is written.
Maybe it is just how it always has been and we've all grown used to the process and the suffering involved?
I agree that some clients are politically important, door openers, key players. Whatever you call them, you will want a contract with them. Not for the sake of that contract but because of the things you believe you can get after that first contract runs well. And yes, in that situation it might not be very important to make profit on the initial contract.
But let's muse a bit on that thought. What good is a disappointed door opener client?
Attempting Scrum in a SDLC environment, pt. 1
I was brainstorming a little about doing Scrum in a company and office environment that isn't tuned to Scrum and would like to share those thoughts. Let me know what you think in the comments!
The good thing about the standard Indian IT office is that it is built from cubicles. That way people can quickly shift from one cubicle to the other to form a team that sits next to each other.
The bad thing about the standard Indian IT office is that it is built from cubicles.
There simply is no space for big white boards or task boards to tack all the user stories on.
But no one prevents you to use pen and paper. If your software design doesn't fit on an A-4 paper it might be too complex to begin with or more detailed than required. Tasks are not bigger than a few days of work, right?
It may not be feasible to put all user stories on a task board, but every developer sure can put his tasks on a wall of his cubicle. Our new office luckily has a small section of each cubicle wall converted into a mini white board. Cool stuff for rough sketches also but frankly speaking I wouldn't count on the sketch being there the next morning after the cleaning staff went through (knock on wood though, so far it worked).
Conference rooms - that mystical land where the white boards are - are rare and frequently occupied, so spontaneous meetings in there are somewhat impractical. However, with the office shift I secured myself and the teams two windows. Who says we can't draw sketches on the window? Word of advice though: Verify that your white board markers are removable on glass first! Any corner usually hidden behind blinds should do. Oh and those sketches will definitely not survive the cleaning staff. Make sure one of you has a decent camera on his phone .
The burndown chart in my case is easily printable on A-4 paper so it will literally fit anywhere. Starting from tomorrow it will be tacked right next to the window in question.
Welcome!
Hey! Welcome to my blog.
I'm a software architect and developer, detail driven and opinionated, playful and curious.
Constantly learning, I strive not to do what others do but what I think is right.
This blog is about my experiences in information technology and the management aspects related to that.
My thought cloud
Popular Posts
- HOWTO: Continuous Integration for PHP, pt. 2 - 652 views
- HOWTO: Continuous Integration for PHP, pt. 3 - 531 views
- HOWTO: Continuous integration for PHP, pt. 4 - 461 views
- Scrum with pen & paper - 459 views
- HOWTO: Continuous Integration for PHP, pt. 1 - 434 views
Events Calendar
- Events are coming soon, stay tuned!
Recent posts
- Successful offshoring part 4: Independence
- Pen & paper Scrum – 10 days edition
- Successful offshoring part 3: Preparation
- Successful offshoring part 2: The coordinator
- Successful offshoring part 1: Time management
- ownCloud – centralize your data and keep control
- Tools for a mobile office
- Thoughts on HipHop for PHP
- Scrum with pen & paper
- The CAPTCHA arms race
Browse by topic
- Agile (15)
- Commerce (1)
- Events (3)
- General (9)
- Management (11)
- PHP (3)
- Social Web (2)
- Test Automation (5)
Other places to find me
Blogroll
Recent Comments
- Interessante Links im Netz 9 | DaRaFF's Blog on HOWTO: Continuous Integration for PHP, pt. 1
- Tweets that mention Successful offshoring part 3: Preparation | Dominique Stender -- Topsy.com on Successful offshoring part 3: Preparation
- What To Do When You Become The Boss: How new managers become successful managers | G2Roms.com on Successful offshoring part 4: Independence
- Tweets that mention Pen & paper Scrum – 10 days edition | Dominique Stender -- Topsy.com on Pen & paper Scrum – 10 days edition
- Tweets that mention HOWTO: Continuous integration for PHP, pt. 4 | Dominique Stender -- Topsy.com on HOWTO: Continuous integration for PHP, pt. 4