Agile

ScrumWorks works

I have been playing around with ScrumWorks™ Basic Edition which is a free project management tool for Scrum and other agile methods.

ScrumWorks™ Basic features are:

  • Product backlog and release management
  • Categorization of backlog items using themes
  • Sprint task tracking for teams
  • Reports
  • Impediment tracking
  • User and team manager
  • Excel import/export
  • Web Services API
  • Automated and manual database backups

It was easy to install. Just download the file, unzip it and run the installer. Online help is good and it is pretty easy to understand if you know the basic terminology of Scrum.

More information and downloads can be found on the Danube Technolgies website.

The Second Sprint

Our second sprint started this week with a sprint planning meeting. We are suffering a bit from lack of involvement from the PO, but apart from that the feeling is that this planning meeting went smoother than the first. The team is getting more familiar with Scrum.

We even introduced story cards to facilitate the process. These were nice to have, but not as appreciated by the team as I had thought they would be. We will have to have a look at what information to present on these cards to make them the tool they are supposed to be…

After all, the nice thing with an agile approach is the flexibility so everything does not have to be perfect the first time 🙂

Retrospective

We had a retrospective after the first sprint yesterday.
The team was satisfied with the flexibility Scrum gives them. They really enjoyed the freedom with responsibility way of thinking. Rather than sit and wait for decisions to be made, they were able to make them themselves and proceed with their work.

As for areas of improvement, we identified that we have to focus more on the test part in the next sprint. We also had some minor problems with test data during the demo, so this has to be prepared more carefully. To address these issues, we have included fields for “How to Test” and “How to Demo” on our story cards. In that way we will be reminded to think of this every time we look at the cards…

The First Sprint

We are in the middle of the first sprint in my project since Scrum was introduced as development method. This is my first experience acting as ScrumMaster and I will try to share some of my thoughts as we go.

Just as everybody else that are using Scrum, we are using a slightly modified version. But that is, as I see it, one of the great advantages of agile methods.
Main differences from mainstream Scrum are:
– Sprint length is set to three week iterations rather than 30 days
– “Done” is defined as ready for system test rather than production ready
– Sprint planning was done over a couple of days rather than in a one day sprint meeting. The actual sprint planning meeting was kept short (1 hour)

Apart from this, we are doing it mostly by the book.

Doctor Scrum

In this article (swedish), you can read about how they want to introduce Scrum-thinking in a hospital in Lund. By using experiences from Toyota’s “Lean Production”, they think they can do work that today takes over a month in only three hours! This is cool!

Decision Making

Rather than waiting for somebody important decision maker to make the perfect decision, the people actually working with the problem must be given the responsibility to make snap decisions. Most of the time good enough is far better than nothing anyway…

Remember: It is always easier to ask for forgiveness than ask for permission!

Peer Embarrassment

By introducing CruiseControl or other continuous integration tools, you also have the opportunity to introduce the concept of “peer embarrassment”. When someone delivers their code, the continuous integration tool kicks in to do the compilation, code analysis, run unit tests etc. and finally the build results are mailed to all the developers.

In case of a build failure it will be clear to everyone who broke the compilation, tests, violated coding standards or whatever went wrong. This is embarrassing for the developer and he/she will probably try to avoid this the next time…

Be aware, though, that there is more than one way of avoiding mistakes. One way is to do the things right, for example by ensuring that all tests are running with green bar before making a code delivery. Another way is to cover you ass by neglecting to write tests or, even worse, removing failing tests before delivering…

Fear

The assumption that a heavier methodology with closer tracking and more artifacts are “safer” for a project than a lighter methodology wit fewer artifacts has developed over the years. This heavier-is-safer assumption is often caused by the fear project managers experience when they get to far away from the code. Since they no longer can determine the state of the project with their own eyes, they tend to introduce more reports, decision points, coordination, meetings etc…..as opposed to trusting people…
Alistair Cockburn discusses some constraints in methodologies that add more burden than safety in his book “Agile Software Development”. This book is good reading!

Why is pair-programming dangerous?

Have you ever experienced that a project manager comes running asking “What is wrong?” when you are sitting there peacefully pair-programming?
Whenever one or more people are discussing something, maybe even (God forbid) using a whiteboard, managers tend to think that there are som serious threats to their precious project.

People working together should be seen as a good thing!! Two people working together on a task means four eyes and two brains rather than two eyes and one brain. To avoid unnecessary noise on your project, some efforts must be done to convince project management of this. Otherwise you might find yourself in a situation where problems are being created out of nothing. Project managers love problems. I guess it gives them an excuse to why their projects fail…

I tip of advice I got when I recently attended the Øredev conference was that rather than calling it pair-programming, you should call it “Continuous Peer Reviews” when selling the idea to the management… 🙂
Comments(0)