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…