This was my first attempt at a usable scrum board. There are some flaws, like the blank story card in the Product Backlog?! (only noticed this now, no idea how that got there, will have to find out) and the fact that there’s a story that has no tasks assigned to it yet is not in the DONE area. I think it worked pretty effectively, especially the use of colored post-it’s to represent different “types” of tasks (tests, bugs, impediments etc.). I say this because I was able to pull in random people (business) and ask them if they understand what is going on here, and, with some basic explanation of the process, they understood perfectly. For me a true test of an “information radiator” is if a stranger can look at it and, given the basics, understands it reasonable well.
Some things that I’d like to add include the teams definition of “DONE” and perhaps the three questions to encourage people to focus on the purpose of the daily scrums.
Thoughts or ideas on improvement (or something I’m missing)?
The bottom left stack of post-its are what we classified as “production issues” directly affecting business, which the team chose to tackle as they came in. The result was that it clearly shows we have a problem with existing systems (the sheer number of critical “issues” the team had to deal with).
The new year will bring a plethora of change in my life, a new company, new goals, new challenges, new ideas. I must admit I’m eagerly looking forward to this much like a new astronaut looks forward to his first space flight, nervous excitement I guess would summarize it.
Along with this I’m also a little sad about leaving my current employer. I’ve been instrumental in growing Scrum to where it is at the moment and I have to say that, although there is still alot of room for improvement, it’s just reaching a point of “proving itself” and getting it’s feet, and now I’m leaving. Lets hope the passion I tried to push it with rubbed off and that it will continue to improve on itself and a new champion will step up to fill the gap. The team(s) I worked with have reached a point now where they are reasonably self organized, so there will be no problem there. I think the possible impediments to continued growth of Scrum will be:
- The lack of a strong ScrumMaster/Coach to protect the team(s) and nurture the process.
- Inteference from management due to “command and control” culture.
- Breakup of the existing team(s). Although this may prove useful because they may end up “infusing” the other team members.
- The warping of the process in order to hide problems.
I’ll have to come around here in a few months to see how things are running…
As I delve deeper and deeper into “Scrum” and read more and more blogs / papers on the subject I keep fixating on the same question… “What does it mean to be a ‘ScrumMaster’?”. Yes, I know there are the standard “definitions” of it but I think it’s more than that. Personally I equate it to a journey, a kind of never-ending journey of improvement, both to self and to everyone you touch. I do not think it is a methodology, I do not believe it is even a process, I simply believe it is a set of guidelines that set you on the path to greater understanding and improvement.
My own personal journey has been interesting, and I’m sure will be for a long time to come. I started off thinking Scrum was “the silver bullet” that will solve all problems, but the more I read and the more I try to apply it the more I realize it is not a solution, it is merely a way to find a solution, and that almost every day the more I practice it and the more I experience it the more I realize that it’s core purpose is actually to expose places of improvement!
Along these lines I believe that the job of a “ScrumMaster” is to improve the world around you to a point where you become obsolete, so, the act of becoming a “Master” of “Scrum” is the act of mastering the art of exposing areas of improvement and acting on these immediately and to the best of your ability, and then taking the results of this and feeding it back into this continuous loop of inspect and improve.
Following this I think (some of) the greatest strengths of a “ScrumMaster” are:
- To truly observe and listen, without interfering.
- To act without hesitation, but with a certainty based on knowledge backed by experience.
I welcome any thoughts on this, am I wrong? Am I at close?
“Affinity Estimating is a technique many teams use to quickly and easily estimate (in Story Points) a large number of user stories. This is a great technique if you’re just starting a project and have a backlog that hasn’t been estimated yet.”
I remember this topic came up during the ScrumMaster course and I found it quite interesting, I’ve finally found an article related to it on Kane Mar’s blog, have a look at the entry here. I’ve yet to try it but will when I have a project with a huge amount of stories, it sounds like it can work quite well.
Impediment: That which impedes or hinders progress, motion, activity, or effect.
I’ve been thinking about the negative context “impediments” are sometimes set in, I don’t think impediments are negative at all, in fact quite the opposite, they are the pointers that lead you on the path of improvement, but it all depends on how you approach it I suppose. I think the important thing to remember is that there is a distinct difference between removing the SYMPTOM of the impediment versus removing the ROOT CAUSE. Yes, both will have the effect of enabling the team to continue, but fixing the ROOT CAUSE will lead to a permanent improvement potentially across the organization, you may even end up removing OTHER teams impediments!
A good example of this is something I myself had to deal with. Our team(s) rely heavily on a web service supplied by another part of the organization. Occasionally this web service supplier will do routine maintenance and bring down the service without informing anyone, bring development to a grinding halt. Our current way of removing this “impediment” is to contact them and request they restart it as soon as possible (fixing the SYMPTOM). A better solution would possibly be to set up a meeting with them and discuss how they can involve us in their maintenance planning, or at least inform us up front of scheduled maintenance, allowing us to plan ahead for these down times (aimed more at the ROOT CAUSE).
As much as I know (or think I know) about Scrum I still find it difficult some times to communicate to non-agile (waterfall) people that are resistant to change and passionate about their point of view. An interesting article I found clarifies this a bit for me, specifically how to communicate with project managers. The essence of it is to communicate to them in their own language, in terms they understand and can relate to. The article can be found here:
How to Talk to Project Managers
I thought today on the importance of certain words in an organization, like when people say “We’re DONE” what do they mean? When they say “This project was a SUCCESS”, what exactly do they mean by “success”? These are important “words” or phrases that any company must define clearly for it to run effectively.
Along these lines I found two nice podcasts on hanselminutes.com, one entitled Lean Software Development with Tom and Mary Poppendieck which has a good approach to defining success; and then What is Done? – A Conversation with Scrum Co-Creator Ken Schwaber which talks about what it is to be done. Both of these are well worth the listen.
Epiphany: a sudden, intuitive perception of or insight into the reality or essential meaning of something, usually initiated by some simple, homely, or commonplace occurrence or experience.
I’ve always struggled with accepting the concept of estimating using story points and NOT effort hours. I could never get my mind around the concept and yes, I’ve read a lot about how estimating with hours is bad (people pad, management argues that real time <> estimated time, team members feel pressured etc etc…), and I believe this, however I did not understand how bad it was until today.
During our estimation (still doing hours effort estimation) we were trying to define the tasks necessary for a story to be completed, however the story had a “task A” that would lead to several “task B’s” that were known, however no-one could (and neither should they be expected to) estimate the hours effort on the “task B’s” simply because the input from “task A” was critical to the timing! Now you’re stuck with tasks that are KNOWN, but cannot be TIMED. And then the light went on and I realized why estimation with time was so bad…You may KNOW everything you need to do (the complexity), however you may not necessarily know how LONG everything will take (the effort), in other words, you know COMPLEXITY but you cannot measure the EFFORT. It now makes sense…
A new sprint has started, with a better duration (30 days, as recommended) and with proper resource allocation. We did Sprint Planning I today and the team has committed (on their own) to a Sprint Backlog that they feel they can accomplish. Had good Product Owner involvement again which seemed to help alot. Sprint Planning II went quite well as well and lasted about 2 hours, the team has laid out the tasks they must perform and are now ready to proceed with the sprint. All in all I think today was a success, the team feels so too, they appear a lot happier anyway.
Some interesting things I noticed today:
- As much as you read how good empowering people is, it’s a totally different experience to see it in action. The general morale of people seems to be up and everyone appears a whole lot more relaxed and open, communicating freely with one another.
- The previous scrum, during sprint planning 1, I made the mistake of being the person that physically moved stories from the product backlog to the sprint backlog (based on team commitment). It’s amazing how much different the attitude of the team was when I said that one of them had to move it, suddenly people seemed to take the commitment far more seriously. Funny how a small thing like that can have such a massive result. I think I now understand why the TEAM must update the board and no-one else.
- Our Product Owner tried to introduce a story into the top of the Product Backlog that there was no detail for, saying that the detail would only be available 3 days before the END of the sprint, before I could step in to say that this was bad, and should probably be moved to a follow up sprint, the team members themselves raised the objection! This was pretty amazing for me to see the team defending themselves as a team, if it were 2 months earlier people would have just sat there quietly and accepted their fate.
After completing the first sprint since the training I feel I need to have sort of retrospective for myself on how I handled it.
What I did well
Always difficult to toot your own horn, but here goes:
- I believe I explained the process reasonably well to anyone that asked.
- The (improvised) Scrum Board I created was pretty good and effective I think, I’ll post a picture for comment, I specifically asked total strangers to come in and ask them if, by glancing at the board, they got a decent idea of what was happening, most people answered “Yes”, some people didn’t care, and others asked me to stop harassing them… go figure 😉
- I evangelized Scrum so well that I’ve had a few requests from people to meet one on one with them and explain in detail what it’s about.
- I protected the team well, they were relaxed throughout the sprint and were, for the most part, uninterrupted (managers sneak in when you’re not around, note to self: investigate Tesla Coil option…)
- I assisted the Product Owner effectively in generating a prioritized Product Backlog.
Where I can improve
Ok, here goes with the places to improve (that I can think of)
- I interfered too much, often guiding the thoughts of the team. This one was difficult to avoid because of my (prior) senior technical role, and I don’t think it had a bad impact, although it did not give the team the opportunity to become a fully autonomous unit.
- I ended up prompting people during the daily scrums, not good, the team needs to run these.
- I updated the Scrum Board and managed the burn-down chart, again, not good, I believe the team must run this.
- I allowed the daily scrums to degenerate into a problem solving session.
- I did not manage the time-boxing of meetings well.
- People missed meetings, or were late, without any form of “reprimand”. Not sure how to fix this though?
- Did not hold a review at the end of the sprint, bad! Must have this in future, perhaps pre-schedule the meetings at the beginning of the sprint.
- The retrospective needs improvement, again I prompted alot of the talking, perhaps the team wasn’t comfortable with opening up?
- I need to understand the finer details of Scrum better, especially around estimation.
- The team did not define DONE, I should have encouraged this.
- I allowed the sprint backlog to be changed during the sprint! Very bad.
- I did not include all the necessary people into the “team”. Important people were excluded initially (like testers) without realizing it. This contributed to the sprint “failing”(coming in 2 days late, features could not be removed) due to test tasks not being included initially.