Category: tool
Photo (c) Janusz Gorycki
"Still working the old fashioned way with whiteboards, spreadsheets and outdated software?” – I have stumbled upon an agile consulting company's web site with this slogan on the main page the other day. Efficiency! Speed! High Tech! Aren't we all supposed to be after these? Well – not at all times. So yes – our team maintains the old fashioned habits, uses low-tech, old school corkboards, does the planning sessions playing planning poker with actual playing cards (Piatnik brand if am not mistaken). We even sometimes plot the burndown charts manually, with pen and pencil. And we do it for a reason.
Don't get me wrong – the modern, efficient tools are useful. Hell, my company is making money producing and selling them! But – they are not everything, and they are not always appropriate. Use them as a tool, not as a gospel. There are things more important for your team's and project's success than the use of fancy software.
The quality of the team and the caliber of its members is more important than the efficiency of its processes – nothing controversial about this statement really, this fact has been well documented in some pretty classic books on team management ("Good To Great” by Jim Collins comes to mind). And the old fashioned rituals are crucial in maintaining the team spirit and identity. This is because people happen to be wired in such a way that it makes them feel safe and comfortable if they can devote some time every day to repeatable old habits. And teams become better integrated if they have some common habits that they care to repeat every day – as a team. Liturgies and rituals do matter a lot – and there is no reason for these rituals to be overly efficient. That's not their purpose to be efficient.
Bookmark/Search this post with:
In my previous post, I talked about my team's experience using ScrumWorks as our Scrum backlog management for the first year or so of our project. After our vendor's license for ScrumWorks ran out, we thought we were close to the end of our project so we stopped using any tool for tracking tasks beyond our bug repository. As I'll talk about in this post, a combination of factors led us to start looking for a new backlog / taskboard tool and the one we've settled on is VersionOne. Read on for more details about why we chose VersionOne and how we plan on using it, even once we've moved on our first agile project.
First, a word about Part 8 of this series, where I outlined the things my team and I didn't like about ScrumWorks. I didn't intend that article to be a review of ScrumWorks at all but more of a look at how we used it and why we didn't like it at the time. It expanded and was seen by some as too harsh on ScrumWorks, especially since I was talking about an older version. It appears that ScrumWorks has done some good updates and fixed a lot of the issues we didn't like about it. But some of the problems are philosophical and I'll get to those in a bit. But if you're looking for a Scrum tool, make sure you do your own evaluation and don't take my word for it. Every team is different.
Also, just so there's no misunderstanding; neither I or Agilesoftwaredevelopment.com have any connection to any tool I mention here beyond using them.
Bookmark/Search this post with:
This installment of My First Agile Project is going to be a little different than the previous ones (Table of Contents for the series available at the end of the post). Today I'm going to tackle the topic of tools. During the first year or so of our project we used ScrumWorks by Danube. It was brought to us by our vendor along with the Scrum methodology. After our license ran out we didn't like ScrumWorks enough to get our own license or even go with the free version, which I'll go into more detail about below.
For our last couple of sprints, we've been making due with a whiteboard and evaluating other tools. The one I like the best and we'll probably be going with is VersionOne, which I'll be talking about in more detail next week. Honestly VersionOne makes ScrumWorks look old-fashioned and barely functional. I had a list of things I didn't like about ScrumWorks and one of the first things I noticed during my initial demo was that VersionOne didn't do any of those things, obviously a big selling point. This week's post is that list of pros and cons about ScrumWorks.
Choosing a tool can be very important in a lot of software development and choosing where to put your backlog and tasks is extra important to Scrum. Since the whiteboard/corkboard + stickies/index card approach is basically free, you want to choose a tool that gives you some extra benefit. Read on for my team's pros and cons about ScrumWorks and hopefully it'll provide some insight on this important decision.
Bookmark/Search this post with:
Excel is one of the most popular tools for managing the backlogs of the Scrum process. There is a number of templates available and here is a screencast on using one of the advanced ones. This template was created by Petri Heiramo from Digia and includes facilities for managing both product and sprint backlogs. You can download this template on the page with the collection of Scrum templates and examples.
You might also like to have a look at the video tutorials on the simple product backlog template and simple sprint backlog template.
Bookmark/Search this post with:
Full disclosure: On Agile 2008, I was asking Pyxis Technologies about the possible sponsorship of this site. It didn't proceed further but at some point I am going to get back to the topic.
Lately I discovered that since last time I paid close attention to Agile methods related tools they did improve much. On Agile 2008 I visited many if not all of the tool vendors booths and in the coming weeks we will probably publish a number of reviews. Before I left for the conference one of the AgileUkraine group members asked me to have a look at the GreenHopper software. This post is exactly a result of the quick look I was asked for. It is no in-depth review, just my impressions after the demo made on the conference and after the extensive interrogation of a Pyxis representative who demoed the tool for me.
Bookmark/Search this post with:
Let's assume you work in an agile team and follow the Scrum framework. Let's also assume that you collect and track requirements "using" user stories. Mike Cohn in his brilliant book User Stories Applied somehow discourages from putting user stories into "digital tracker". In his opinion the best place for user story (most probably yellow or green sticker) is cork- or whiteboard.
As far user stories are concerned I totally agree - but what about programming tasks, bugs and other ah-hoc "low-level" developer's communication? How can small sticker with information like this As a user I want to ... [in order to ...] help itself developers deliver the user story to the customer?
Isn't some tool help needed here?
Bookmark/Search this post with:
I'm an agile developer because I write my code incrementally i.e. only what I need today. I usually start writing the code by writing Unit Test - it really works and it really helps me understand what should be implemented and how system should behave (I will leave the subject of convincing people, who are new to unit testing, to do "write-test-first" for a separate post). OK - I usually do this but sometimes it's difficult or I'm just too impatient to see the result and start with the implementation and write unit test later. How do I know which packages/classes/methods are tested and which are "not touched" by any single unit test? How do I know that my code is really used somewhere by other parts of the developed system? This is the work for code coverage tool.
Bookmark/Search this post with:
In this 6 min-long tutorial I demonstrate how you can manage your Sprint Backlog in a very simple Excel sheet based on a
popular free template. Watch this screencast if you want to get started with Scrum.
Bookmark/Search this post with:
In this tutorial I demonstrate how you can manage your Scrum Product Backlog in a very simple Excel sheet based on a
popular free template. Watch this screencast if you want to get started with Scrum. You will see how to get started, how to detail, inject and remove requirements, how to build burndown and velocity charts.
You can download the somewhat lower quality version of the tutorial
from Google Video.
See also
Bookmark/Search this post with:
Update: Link to XLS fixed. Kudos to Jukka Laurila
Bookmark/Search this post with:
RSS feed
Subscribe on Kindle