Customer Interviews

In preparing for the next release as well as defining a "bigger picture", our Product Owner has been conducting extensive customer interviews.  This has involved traveling to their sites as well as phone interviews.  As I sat in on these calls, for the first time, I was able to get a better perspective on customers pain-points, desires, rational for certain functionality as well as what's good about our existing software.  (Which is nice to hear because when developing software, you tend to always be in firefighter mode and become thick-skinned to all the problems with our software.)

During the calls I worked on my mind-mapping skills and mind-mapped the interviews. I started to notice that there were some consistent themes forming among the customers.  My wheels began to spin as to potential epics we can start with for our release planning, (which by the way, is coming up fast and furiously).  

When doing customer interviews it's important to have questions prepared in advance so you can have a consistent framework to follow as well as an easy way to compare answers.  Keep the questions fairly open ended to allow them to elaborate as needed.  It's important to remember the goal of each question as often times the interviewee will digress and it's all-too-easy to digress down that black hole with them.  If they are having a difficult time with answering, then provide examples of what you are looking for.   Often times, this will trigger some ideas.   Just be careful to not put words into their mouth.  Remember the interview is about them and their needs, not about us.   

Another point to mention is that often times, what they are initially asking for, isn't really what they want.  Or they tend to tell you how they want to do something in the exisiting software.  When this occurs, it's good to rephrase the question to ask, "What is it that you want to accomplish?".  They are typically telling you how to do something, rather then what they want to do.  Remember, it is our job, as a team, to figure out the "how", it is the customers job to provide the team with the "what". 

The customers were all very willing.  Every one of them expressed appreciation and gratitude . They said that they felt valued that we took the time to solicit their input.  This was extremely encouraging for me as we now have the seeds planted for communication between us and them. The door is open to continue the dialog and involve them more during the development of our next release.  After all, isn't that what scrum and agile are about?  Pull in that customer as a part of our iterations.  

Approaching the finish line of a release

We are winding down with a release and I am already thinking about the next one.  What can be done better the next time around?  Well, for one thing, having a release backlog before the release.  I'm happy to say that there is more talk about users and framing our next release from the user's perspective.  I'm hoping that starting from the top we can generate some good epics and then break them down into well-written user stories.  I'm also going to be gathering requirements from end-users which will be great.

What I've been working on with our PO is defining some epics.  He has been speaking with all customers to feel them out on what they are asking for, framing them in themes and going to bring them back for some fine tuning.  I am eager and hopeful that this will develop into some constructive release planning work sessions.  I will post about them as they evolve.  

It's important to remember and remind myself as well as the POs and leads that it is the customer that we need to satisfy.  So all pre-conceived ideas must be checked at the door.  Meaning, if scrum teams need to be re-arranged to best facilitate the next release, then this is what must happen.  So it's important to not think about writing stories to make sure that the existing scrum teams all have something to do.   This will guide a direction pre-maturely.  First come up with the stories, then decide how the teams will come together to implement.  (At least that's what I'm thinking right now).

Anyway, take away for my first release with these teams so far has been to stick with the basics.  (In the ways of scrum) stories, sprints and communication.  Next is being more comfortable with estimating, thinking about acceptance tests and pushing back on over-committing.

I will post on these topics as I tackle them in this next release.

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.

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.

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 was..how 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.

I should have thought of this sooner

While attending the Emerging Technology for the Enterprise conference yesterday, I was talking with a former co-worker of my woes at my current position as a scrum master.  I've been feeling nothing but frustrations and fighting an uphill battle for the past few months since I've been hired at a company as a project manager to implement scrum to a company that was no using any formal methodology.  He suggested rather than feel frustrated or defeated, think of it as an opportunity to learn and grow.  And, he suggested, you should blog about it too.  Blog?! I thought...hmmm...wow..what a great idea! To go public and publish what I've been trying and learning; this would help me two-fold.  First it would allow me to journal my trials and errors, frustrations, success etc.  Second, in addition to helping me, I hope that I can help others that may be in the same situation that  I am in.

Anyway, just wanted to get this started.  Background info on myself and where I am now on the next few posts.  But for now...must think about dinner.