Author: Rick Tonoli

Tools…

Ok, first of all I’m a strong advocate of NOT using tools and applications to run Scrum, and that Scrum is about people, communication, visibility and transparency and that the best way to achieve this is to scream it out to the world on a nice white board, after all, you should have nothing to hide.

A colleague of mine, however, raised the idea of having a set of tools or “things” specific for a ScrumMaster to use? Along the lines loading something like a PDA with a sort of ScrumMaster Toolbox that he could carry around (like your traditional Project Manager’s with their clipboards 😉 ) that would aid and facilitate him in doing a better job? Then I got to thinking what this “toolbox” would include, I guess something along the lines of:

  • Contact details and roles of all the people involved in the project (PO, Team, Management, Users, BA’s, Pizza Delivery etc), essentially everyone that can prove useful in aiding the team in completing the sprint successfully.
  • A way to manage and record progress on current impediments.
  • A kind of stopwatch / countdown tool to manage the time-boxing, preloaded with the predefined times for different meetings.
  • A few core documents defining Scrum, or core principles, a sort of “suggested reading” list. An example here would be the Agile Manifesto.
  • A place to easily jot down notes during meetings.
  • Perhaps a list of “games” that can be played to aid in understanding the benefit of Scrum?
  • A list of personal and blackmail information on various team members to use against them to force them to…. oh wait a minute, that would be old style management 😉

Not sure if any of this would be useful but I think it might, and I could always improve on the tool set as I go along, perhaps I’ll give it a try and see how useful it proves to be…

Done?

This is always a highly contentious and relative subject, what does a team mean when it’s DONE? This sort of popped into my head a while ago when I was contemplating how a person would go about making sure a team is actually performing as best they could, without interfering. My question was this, because Scrum is essentially a management process (and yes I know, its not only a process but also a “way of life” and a “mind shift”), and not an engineering process, a “green” team may not realize that a solid engineering process was missing from their way of working? Would it be your responsibility to point this out and prevent future technical debt building up, or should you leave it to the team to inevitably “fail” and attempt to fix the problem then?

Based on the input I had to this question I believe that part of the ScrumMasters role of ensuring process was being adhered to was to make sure the team had a well defined definition of “DONE”, and not only that they adhered to it but that they attempted to improve on it during retrospectives. “DONE” then becomes the instrument by which the team improves HOW they do things and can include good engineering practices like continuous integration, unit testing and essentially anything the team believes will improve the quality of their shippable product.

Along these lines I found a great article on the Scrum Alliance website by Mitch Lacey titled “How Do We Know When We Are Done“, which includes an exercise a team can go through to help them define their “DONE” list. I haven’t tried this yet, so I cannot speak from experience, but in principal it sounds good and I’m hoping to try it at the next available opportunity.

Retrospective

Ran the first retrospective today, the team seemed a bit apprehensive but eventually started talking, but only after alot of coaxing, which for me bordered on interfering again, but what else could be done? I explained the point behind a retrospective, to see what we did well, and where we could improve; I tried to set a relaxed mood but I don’t think it worked too well, people were very quiet for the most part. I still struggle with this part, how to get people to open up and talk about things. Eventually though we did hammer out some potential improvement areas and put those up on our impediments list for me to deals with. I guess there was some value gained from it, although I’m wondering how the team will fair once I’ve left…

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.