Tag: team

Next Sprint…

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.

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…

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…

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.

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…