Monday, April 27, 2009

defining users

With the next release closing in, and a new one to think about, I want to be better prepared with a release backlog.  Since last release focus was getting everyone familiar and up to speed with scrum, some things fell to the wayside.  Now that the teams are familiar with the general rhythm of a sprint cycle, I want to focus my efforts on having a better 6-month plan, in addition to fine-tuning some other aspects.

The book User Stories Applied by Mike Cohn has some great info on user role modeling gathering stories.  I read this a few months back but I think I need to brush up on it in order to prepare and be better organized for the next release.  I will spend some time outlining a plan for the next release and perhaps have a few sprints of better understanding our users and defining some stories around them.

Sunday, April 26, 2009

How to organize?

It's difficult trying to be up and keep people energized. Not to mention the lack of direction of future goals. I see it as a problem, but don't know how to attack this situation.

I've got most of the team into the "flow" of scrum...although I'm sensing a dullness. How do I challenge the teams in a positive and encouraging way? And how does one get a PO organized with a vision?

Maybe my problem is that I've never been exposed to upper management since working at larger companies. At smaller companies, you are exposed to all aspects of it. So when you see that the indecisiveness, it's quite unsettling. Like not having a leader of our country leading. One just assumes that there is always someone there to tuck you in at night. But when you don't have that, and you know something is just not right it's a bit unsettling. The question is, I realize it, but how do I help facilitate a change? Maybe it's like this all over the place, but just my first time seeing it.

Today I listed the problems - how to address them - and the risk if they are not addressed. I brainstormed the problems (as best as one can do alone). Perhaps I'll revisit them. The more difficult part is how to address them. How does one address them when you are alone? I need camaraderie and it's difficult to do alone.

Anyway, what's coming up is the end of one release and the beginning of another. My goal for this past release was to get the team up on scrum. Still more to do, especially in the ways of writing tests. But what I need to focus on the next go-around to get the PO(s) more organized.

Monday, April 13, 2009

Retrospective on a Retrospective

I'll have to fill in all the pieces as to what lead me to where I am right now during a later time. If I wait to do that before I can actually blog my days, I'll never get current.

So anyway, we had our 3rd retrospective last week. The first two were pretty similar in format.  Since I am running...(not really sure what my role is actually) but since I am the Scrum Shepherd, so-to-speak, I am working with 4 teams at once.  (More on my scrum team breakdown in a separate post).  That being said, I'd go nuts if I had to run 4 separate retrospectives, as well as not have enough time to get in that along with planning meetings and reviews.  So I have decided to have all teams involved in the reviews and retrospectives.  There may be a better way to do this, but this is what it is for now.  

For the retrospectives, I'm following the format from a most excellent book called "Agile Retrospectives: Making Good Teams Great" by Esther Derby.  I used this format from my previous ScrumMaster experience.  Once you get the idea behind it, you can start to modify as needed.  But for me, with the nature and dynamics of the teams, I need to follow the KISS principle as much as possible.  

I've scheduled my retrospectives to 2 hrs.  They should probably be a bit longer as we often run out of time or I am pacing the retrospective as such to stay on time, however some times the discussions get on a roll and it's easy to go long.

The first two were similar in format in that I had them brainstorm on sticky notes and then we posted them on the board and grouped (found themes).  Voted, and then discussed.  Now the tricky part, is how do we "post sticky notes" with people remote?  What we did was have them email them to our scribe and then we'd add them to the board. 

Seeing that we don't have any video conferencing available at this time, posting peoples feedback on sticky notes is useless to those remote.  So while we had me facilitating on in the room with the notes, we had a scribe posting the same responses into Freemind and with GoTo Meeting running those remote could see everything changing on the fly.  I'm sure there are better ideas to doing this, but this is what we have done so far.  Any suggestions would be greatly appreciated.

Anyway, the team seemed to like this format and I noticed that they were almost "expecting" this to be for the 3rd retrospective.  Now here is where I was torn.  Do I keep it the same with the fear of the team getting bored of this same format?  Or do I change it up a bit?  

I opted with change it up a bit and tried something a bit off the cuff and ill-prepared.  I tried to follow Mike Vizdos format from his Agile Roundtable talk at the ETE conference.  That being, have a mini-sprint during the retrospective.  The team was a bit thrown off by this and it took them a while for them to see where I was going with it.  Now to form the backlog, we had people throw out ideas.  The thing that I am quite cognizant about is that we have a couple rather out-spoken individuals in the group and they tend to smother the rest.  Even more of a problem when more than 1/2 the teams are remote.  So I do need to focus on ideas that will involve the others a bit more.  After brainstorming, we "voted" on top issues and made the first two the topic of discussion.  I think that then next problem I had do I break the team up into groups when we have people remote and people local.  I did the easiest split and took the remotes and the locals.  The teams went off and hashed out their feature and again, those that were the most outspoken dominated while others remained silent.  

When we all re-convened, we had a fairly good discussion.  However we ran out of time quickly and I had to wrap it up (keeping in mind our time box)  I felt it ended prematurely and we didn't not take away any action-items.  

Anyway, lessons learned for me,  when something works -- keep going with it, set more well-defined expectations up front, involved everyone as much as possible,  better closer so the team feels like they got something accomplished.