Month: November 2008

Are you really Agile?

I found this interesting article by James Shore:The Decline and Fall of Agile which essentially talks along the subject of people claiming to be “agile” but are not really and having this potentially destroying the true “agile” drive. People should be careful that they don’t just grab at buzzwords and ideas without realizing what they’re getting in to, especially with Scrum:

“But because Scrum works in short cycles and doesn’t include any engineering practices, it’s very easy for teams using Scrum to throw out design. Up-front design doesn’t work when you’re using short cycles, and Scrum doesn’t provide a replacement. Without continuous, incremental design, Scrum teams quickly dig themselves a gigantic hole of technical debt”

Read the full article, it was an eye-opener for me, and be careful, Scrum alone does NOT make you fully agile, it’s only a small step towards agility.

Silos

Someone told me something interesting the other day…”Silo’s destroy Scrum”, which I found interesting but never fully understood the impact until today. We’re approaching the end of our sprint and only one of the stories has been completed, a severe bottleneck was building up with the test work and when the team approached the “tester” within the team that was assigned to us with the offer to have them help out with testing, they were told that only she is allowed to “sign off” testing. I explained that this would cause the sprint to fail because there’s no way she could sign everything off in the remaining time but they were not interested, I guess they’re more interested in sticking to their silo’s than the project succeeding. There’s not much more I can do about this other than to point out that the sprint will fail and just let them fail…

Too involved….

Without realizing it I’ve become too involved in the team, almost interfering in the Daily Scrums I suppose. It’s difficult coming from a technical background not to want to interject and comment on what people are saying. How do you approach the scenario where you have information that may be of value to the team but you do not want to dictate to the team what to do? Right now I take the route of subtle suggestions, trying my utmost not to dictate, but inevitably I’m seen as a more senior person with experience so people will tend to go with what I say, and is this not pretty much the same as dictating? But then, in the end, its about delivery, and if you can assist the team to delivery quality shippable products (without too much interference), is this necessarily bad? Or should you let the team “fail” and learn from that?

ScrumMaster and Parenting

Today I sat watching my daughter sleeping and thought about just how similar the role of ScrumMaster is to that of (what I consider proper) parenting, more so from a father’s point of view. A team is like a child, you don’t interfere with their exploration and understanding of the project but rather give guidance, protecting them from the impediments that may come up, letting them grow and achieve all that they are capable of, essentially arming them with the information and skills and trusting that they can and will make the right decisions.

Now how about the role of the traditional waterfall based Project Manager? I equate that to a typical “bad” parent, interfering in the teams exploration and growing up, trying to micro-manage and force people to do without thinking if they really WANT to do it, not trusting in capabilities but trusting only in ones ability to force the team to comply to what you believe is the right way of doing things, forcing them into a mold and ruining any chance of greatness

An interesting analogy I guess…

Scrum in a Nutshell

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…

Change…

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.

Everything still good…

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 (Self Organizing) Team

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:

  • Micro management and interference from management.
  • Priorities changing.
  • Outside interference from other projects.
  • Production issues.

I’ll need to deal with these as they come up. I may not make any friends, but I will make this sprint succeed…

First Sprint Planning…

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?