"once you stop learning you start dying"
Agile stuff, the stuff I like
I found a nice, concise, description of SCRUM here:
Scrum – a knol by Dan R Greening
I found particularly interesting the first comment made that clarified my questions regarding the fundamental difference of the feature/story point estimation vs the task/hours estimation techniques. It appears that the reason is pretty much around the comfort of the team and their willingness to participate effectively in the estimation process. I strongly suggest reading it…
As predicted an item was removed from the sprint backlog and then added a day later. I guess this is a symptom of bad planning and lack of vision by the Product Owner(s)? Or the fact that they don’t communicate between themselves? I’ve tried to explain to the BA (whose acting as a voice for this “Product Owner Committee”) that it’s important that we get one message from them, and that they are reasonably sure of what they want, or is it? Not sure because is change not what this whole thing is about? Anyway, the team took it in stride and we sat down to rethink the sprint, they all agreed that it was still do-able (they’re becoming good at self organizing I have to admit) and we re-introduced the work. Additional work was added to the Sprint Backlog which I don’t believe is a good idea but was unavoidable, a requirement that was omitted for this sprint. The only condition I set on this was that the team as a whole accept it and believe it is do-able, if not it does not go in. It’s not the easiest job being a ScrumMaster I must admit, but I think I’m making some headway, and even though things aren’t working strictly “by the book”, they seem to be working nevertheless.
Created the burndown chart today and the scrum wall using spare flipchart paper stuck up on a wall after looking at some ideas on http://www.mountaingoatsoftware.com. Everything seems to be running semi smoothly so far, had to fight off some managers wanting to inject work. Also read some interesting stuff on prioritization from a blog post on Scrum 4 You which essentially revolves around a process using relative weight to predict priority.
The sprint planning sessions are taking long but this is because these concepts are new to the team. They need to be taught that they are the owners of their own destiny and as a team they, and only they, must move forward in this. The current way of working is way different, generally involving one or more managers dictating what needs to be done and being micro-managed until it’s done. I can see how this demoralizes people (myself included), afterall, doesn’t this send out a clear message that people don’t trust you to do something? And if someone doesn’t trust you how can you feel any pride or joy in what you do? I like the opening statement from “Agile Software Development using Scrum” saying “work can and should be an ennobling experience” , this is so true but people forget this… I think SCRUM is a way of bringing this back, a sort of “re-ennobling” process.
Anyway, I was pleased to see the team engaging (for the most part, I’m not expecting miracles yet) each other about the backlog, I do find though that I need to continually poke them to get them to start up, but they seem to be getting the idea that it’s all in their hands. I do need to be careful not to interfere too much though. The team has now managed to break down the user stories into reasonably well defined tasks that they need to perform to achieve success in this sprint, tomorrow the first scrum will happen and the team will commence with their work.
I did notice a interesting thing though, we had several questions and ideas we wanted to try during the sprint (one of the stories is overly complex but cannot be decomposed) and after the meeting the team seemed to spontaneously “self organize” in such a way that people who were best suited to do this “investigation” in various parts of the system automatically started doing it, this without prompting or “managing” them in the correct direction, all this before the sprint actually started! I found that pretty amazing…Let’s see what tomorrow brings.
As a side note, I’ve thought about the potential impediments to the upcoming sprint:
I’ll need to deal with these as they come up. I may not make any friends, but I will make this sprint succeed…
Today was interesting… we did our first sprint planning meeting with a team of 5 people. After I’d sat with the designated Product Owner (a BA with a passion for the project) and created what I think is a sufficient product backlog, I explained the concepts of Scrum to the team (especially around estimation and effort) as I was taught and we actually managed to determine our first sprint backlog. I did have one question regarding the burndown chart though, and having researched it in “Agile Software Development with Scum” and I realized what I was taught is different (in implementation) to what they say in the book. Boris estimates using what I think are “weightings” for tasks (relative to one another), the book demonstrates the use of “hours” to measure effort, although the “hours” are not commitments but only estimations made “as a team”. This seems a little more logical to me as well. I’ll take it to the team and see what they think, afterall, in the end its only important that you have a decent burndown chart with decent tracking isn’t it?
One of the key success factors of Scrum is a prioritized product backlog. Somehow I thought this might be easy, boy was I wrong. I’m trying to figure out why it is that I cannot get a single prioritized list of work out of business and I came up with these observations:
The first day back at work after the course was surprisingly interesting. Several people were extremely curious about the CSM course (this is good) and wanted to know more. I ended up explaining what we were doing wrong (to the best of my knowledge) and what I believed (or was told to believe?) was the best way to do it (for now I’ll follow the principle of doing it by the book first, I think it’s the best approach especially from a junior in the field). I was surprised at the level of interest from people, this will help in the change we need to make in the place. I ran it through my manager and as predicted he was eager for my “proposal”, which I will now start working on. I think I’m going to take for following approach:
The Certified ScrumMaster course in itself was extremely interesting and I’d recommend it to anyone who can get to it. It was also extremely difficult to find in South Africa but I finally stumbled on a course given by Boris Gloger (hosted by Peter Hundermark) and managed to get into it. If you’re thinking of going Scrum, or any agile approach for that matter, this is a definite must have on your list, not so much for the “certification”, but for the sheer volume of knowledge you’ll take away from it. Be prepared to be overwhelmed, but in a nice way…
… ok now what? I guess that’s the biggest question I went away with from the CSM course I completed today. The course itself was extremely interesting and I think it served two purposes, the one was to reinforce my existing knowledge and the second to correct it, the latter being more prevelant. It was refreshing to discover that what I thought was being done incorrectly at my company was, in fact, being done incorrectly.
The course was also an eye-opener and sort of a wake up call. I have always liked the agile approach but have always been a fence sitter when it comes to implementation, trying a bit here, trying a bit there, never fully committing. I think what this course has given me is not a piece of paper to say I’m now somehow “qualified” to be a Scrum Master, but rather a direction, a sort of impetus to do something constructive with the knowledge I’ve gathered.
What am I going to do with it? I’m not sure, but I have a plan. I’m currently employed by a company that is attempting Scrum. I say attempting because I now know how horribly they’re failing. Yes, projects appear to be working and coming in with reasonable success, but not without monumentus effort at varing stages through the sprint(s). I think I’m now capable enough to fix this and that is my plan. I will draw up a draft proposal documenting what I believe to be the points in our process that need to be corrected. I’ll then present it to the IT manager and see what happens. Being a strong proponent of Scrum and the agile approach I’m hoping he likes it. From there, well, let’s learn to walk before we run…