Scrum

Product discovery, Scrum

On Discovery Of Product Discovery

By 3 Comments

What A Difference A Year Can Make!

About this time each year, I don my scrum master cap and visit the University of Sussex to deliver a lecture to under graduates and MSc students on Scrum. And each year I find myself having to modify my lecture to take into account the ever-changing state of the framework and the experiences I’ve picked up during my agile travels.

calendar-660670_1920
Some lecturers might find this constant evolution a pain in the ass (after all, rewriting a lecture isn’t exactly fun), but I think it’s testament to how awesome practices like Scrum are.

What A Difference Three Months Can Make!

Earlier this year I quit my relatively secure scrum master job in Brighton to go freelance. It was a daunting move with, typical of so many big decisions, the procrastination being more painful than the execution. I walked into a scrum coaching role expecting to use my well-practiced skills on a new scrum team. You know the stuff: mess with the rituals, add some vigour where it’s needed, help the team find their happy place. All great stuff and indeed the bread and butter of scrum mastery (yes, I know there’s way more to it than that, but I need to keep this post relatively short and most of you know this stuff already, right?).

If you spend too much time thinking about a thing, you’ll never get it done. – Bruce Lee

The team’s product owner is a really bright star, eager to take the product to another dimension. I recall having a chat with him over coffee about roadmaps. We were talking about Roman Pichler, goals, MVPs and all that well-documented awesomeness and I dropped into the conversation that I particularly loved Jeff Patton’s work on User Story Mapping and Gojko Adzic’s Impact Mapping techniques. I’d been aching to use these techniques more and now I had an opportunity to introduce them to a team that hadn’t dipped their collective toe into such waters. I eventually ran a User Story Mapping workshop with the product team. I ran five Impact Mapping sessions with “the business”. Both techniques were received positively.
But I found myself questioning the validity of it being me doing this work. “Is this a normal scrum master duty?” I asked myself. “Am I abandoning my teachings?” I postulated as I rubbed my stubbly chin.

Intellectual growth should commence at birth and cease only at death. – Albert Einstein

Discovering

640px-cuneus_discovering_the_leyden_jar

Fast forward to today. I’m now no longer my client’s scrum master. Instead, I’m their newly appointed product coach, helping the product management team adopt discovery and delivery techniques, otherwise known as dual-tracking. The work I’m doing now is upstream of the typical Scrum team. We’re focussed on creating experiments, challenging assumptions, hypothesis testing, rapid learning, and user development. Of course, all of these artifacts and rituals can be considered to be under the general agile and Lean umbrella, therefore my experience as a scrum master is still relevant and applicable. But am I a traditional scrum master? I don’t think I am any more. My eyes have been opened to the value of product discovery, and I’m hooked.
I wonder how many of you reading this have found yourselves on a similar path. Please share your experiences in your comments.

Agile, retrospectives, Scrum

On Being Mad, And Glad, And Sad

By No Comments
On Being Mad, And Glad, And Sad

And no, I’m not incredibly confused nor clinically insane (although others may have a different opinion).

Reveal: I love retrospectives

In my early days of Scrum Mastering, I typically stuck to the same retrospective exercise because it felt safe. But there’s only so many times that you can do “The Speedboat” before it becomes stale or irrelevant (by the way, The Speedboat exercise is great for looking back on an iteration; the team I worked for would regularly change the speedboat for other vessels: X-Wing fighters, submarines, tall ships, radar-invisible stealth cruisers..)

retro1

Fig 1. A Speedboat With MC Hammer Obstacle

Over time, I learned that not only were there different retrospective techniques tuned for certain project scenarios, but also for the different stages of the retrospective (checking in, setting the scene, gathering data etc).

Buy “Agile Retrospectives – Making Good Teams Great” by Esther Derby and Diana Larsen. It’s the retrospective bible, in my humble opinion.

So after messing about with The Speedboat for a few sprints, I switched to Starfish then to Team Thermometer and even Pictionary (one of the funnest). If you want to read up on them and others then buy, “Agile Retrospectives – Making Good Teams Great” by Esther Derby and Diana Larsen. It’s the retrospective bible, in my humble opinion. However, one retrospective technique stands out for me as being truly engaging: Mad, Sad, Glad.

Welcome to Madsadgladland!

On the beaches of Madgladsadland, inhabitants rub shoulders rather than converse across a table. They move around each other in a dance of cooperation rather than let their humble servant-leader direct their choreography. They invoke human-evolved pattern recognition rather than have those patterns pointed out to them. In short, they Own.

Sadly, in our office at least, there are no beaches and there is no dancing. But Mad, Sad, Glad is retrospective technique that encourages lots of cooperation. I’ll explain.

The suburbs of Madville, Sad Town and Glad Central

Find a big whiteboard and write the headings “Mad,” “Sad” and, “Glad.”

Ask the team to write down things that really stuck in their throat (for Mad), things that they wish didn’t keep happening and need fixing (for Sad) and things that they really get a kick out of (Glad). You can use your own definitions for the headings. It helps to have different coloured stickies for each of the categories.

Ask the team to place the stickies under their respective headings.

Rest.

Next ask the group if they can spot anything about what’s been put on the board. Ask them what it felt like to write what they each wrote. Ask them if anything surprised them. There are other Powerful Questions you can ask, and you’ll find them in the literature.

Before I continue, it’s at this point that I’m reminded of how much of an impact this technique had on me. Until I’d run this exercise, many of my retrospectives involved putting stickies on a board, but then the team would sit down, relax, and let the facilitator drive. On the first time I ran Mad, Sad, Glad my heart fluttered with pride and a big grin appeared on my stubbled face as I witnessed normally static team members move and interact and debate!

So, next you ask the whole team to get up out of their comfy seats, walk over to the sticky-infested board and work together to identify patterns in what has been written. This is regardless of where each sticky was originally placed; the colour coding maintains whether it was a Mad, Sad or Glad. If your experience is anything like mine, you’ll witness people collaborating (“what about putting this one with this one”), you’ll see them negotiate (“I’m not sure this Jenkins one should go with code quality; shall we create a new category for it?”) and you’ll see them query (“what does this one refer to, Jon? Why did you feel that way when Jane was super happy with the same issue?”)

Some groupings may have Glad stickies and Mad stickies in them; if this is the case, enquiry why. This can reveal misunderstandings and tensions.

In short, you’ll get the level of collaboration you wish they maintained during their normal working day. But let’s not be too hard on our teams; collaborating in a retrospective is as good a place to do it as any.

teamsize

Fig 2. A Grouping Of Stickies About Team Size

During this physical interplay between team members, you should notice some healthy chat happening. If you see that one or two team members are the ones doing the organising of the groupings, politely ask that they step aside to let others review what they’ve grouped, or to add some new groups. Remember, in a retrospective, we’re all equivalent despite not being equal. When they think they’re done, I ask them to look over the groupings one more time and then label them with an appropriate heading.

In my opinion, if the technique ended there (and I guess it can, if you wish) then it would be a success, solely judged on the increased cooperation between team members. However, the next natural step is to allow team members to vote for action on the groups they’ve created. (Some groupings may have Glad stickies and Mad stickies in them; if this is the case, enquiry why. This can reveal misunderstandings and tensions.)

From this point onwards, it’s upto you how you deal with voting. In the team I serve, we try to commit to no more than two actions for improvement in the upcoming iteration. If there are others that also seem important, I’ll note them and ask the team in the next retrospective if they want to deal with them.

Just do it

My recommendation is to try Mad, Sad, Glad in your next retrospective. Its simple title belittles its awesome impact. And as with all retrospectives, don’t forget to check-in, set the scene and evaluate the meeting.

Agile, Planning, Scrum

On My Phobia Of Sprint Planning

By No Comments

Yes. You heard it here first. Sprint Planning sessions fill me with fear.

Like most Scrum Masters, I’ve attended many Sprint Planning sessions – for many different projects, for many different teams. The ones in which there’s a distinct client (rather than for a product owned by the business) strike a particularly strong sense of foreboding into my soul. What if I don’t understand the requirements? What if the client gives me a hard time and I have to think on my feet? What if I can’t contain the developers’ enthusiasm to underestimate everything to keep the client happy? What if I can’t contain the developers’ enthusiasm to wildly overestimate in order to protect themselves? What if I go over time and we’re not finished? What if, what if, what if???

And then I take a deep breath, turn the door handle and step, once more, unto the breach..

The fear

Of course, if all Sprint Planning sessions turned out to be as bad as I feared, then I would have quit Scrum Mastery a while ago. Maybe I would’ve taken up something like shark painting or oil rig wrestling.

The first mistake I make is to be fearful for myself. Two things then come to mind, and provide immediate comfort:

  1. if I’m scared, how do I think the team must feel?
  2. it’s a team effort and the developers know more than I do; draw upon them for support and give them yours

By now, my heart rate has dropped a little. Then more lifelines get thrown down to me by my reasoning:

  1. being brave is about being honest. The outcomes are better following an honest appraisal of a problem than from following one given under duress
  2. the last iteration is behind us, we’re closer to the finish, and there are new discoveries ahead. Rejoice!

Facing it

As with checking in during retrospectives, I combat my fears by trying to be the first person to speak when the meeting kicks off. I state the intended outcomes of the session, the duration and all that administrative stuff, and I make it clear that the meeting is about discovering work and focusing on creative ways of addressing the Product Owner’s goals. By making this first stab, I’m quickly able to bury my nerves and get on with it.

kid2

Image courtesy of Frederick Homes for Sale, Flickr (CC)

But some Sprint Planning meets can be…. difficult. So what happens when my nightmares start to come true?

I’ve been on the brink of an argument with a client during one memorable session. But rather than let emotions get involved, I reminded myself that lives were not at stake here; just assumptions – some valid, some not. I assured the client that I was only labouring a point because I felt I had evidence to back up my claims (about estimation, now you ask) but that we, as a Scrum team, were there to not only validate his assumptions, but to challenge them and present hopefully better alternatives. After all, we’re paid to think, not just do.

Keeping your head and your cool is key.

Sometimes the problems are closer to home. Like the time the team I was serving never finished any stories, and each planning session was a repeat of the previous; always choosing the same not-yet-Done stories. In those cases, your skills as a Scrum Master are tested quite hard. You have to come up with a way of breaking the deadlock, lifting spirits and ensuring all parties, stakeholders and Product Owner included, know the facts, no matter how painful they are to admit. You need to extract valid points of learning from failures such as these. And, of course, you need to establish a way of not going down that alley again in the future.

So, with all this going on, it’s no wonder I get a little shaky! But, that all said and done, a little adrenalin can certainly add gusto to your mastery.

Agile, Planning, Scrum

On My Love-Hate Relationship With Tools

By 2 Comments

I don’t hide the fact that, given the choice, I’d rather have my feet swapped out for frying pans, than have to use Agile “management” tools. I make it clear to the teams I serve that nothing really beats what we’re finely tuned to be good at: face to face encounters. I keep away from software tools when it comes to working within the Scrum framework.

This resentment began, I think, when I was introduced to Jira. (My recall is foggy because my brain has put a lot of effort into erasing that moment.)

I was in the throes of becoming a Scrum Master, and was feeling particularly excited about the prospect of using big whiteboards and PostIt notes and marker pens and magnets. In fact, I may already have started using them. I’m not sure.The company I was employed by was rolling out Jira as a means of not only tracking defects but, God forbid, sprints.

No matter how hard I tried, at least one team refused to move to a physical board. It was a team of three, and they sat next to each other no more than 1m apart. Yet they insisted on using Jira to keep themselves updated. And just half a metre from them was a shiny new whiteboard on wheels, ready to be drafted into action at the drop of a hat. I’ve no doubt they probably used Google Talk to chat to each other too.

“Individuals and interactions over processes and tools.”

Tool usage in itself may not be a problem, but the tools themselves restrict us. For example, in the same company, the Product Owner wanted to see how the team was doing with her stories. For the aforementioned renegades, we had to arrange a Jira login ID (but we’d run out of users so had to boot someone off to make room for her) and then train her in how to use the tool. I’m not convinced we’d bought into Scrum’s “information radiator” ethics. Information coolers, more like.

But the issues aren’t just around visibility. I’ve used other Scrum tools that absolutely insist upon the users entering estimates against stories. But if you’re working with a team that has moved beyond estimation, the tool becomes unusable. The workaround? Type in any number against the estimate. This is fine for the developers, but I had one case where the stakeholders also had access to the same software and they raised concerns about the velocity of the team. The software told them that the team was going to be late on delivery based on the numbers they’d punched in. I’ll repeat that. The software told them. Not the team. Not the Scrum Master. But some software.

kid

Physical boards give you the freedom to modify your way of working without waiting for a change request to go through to a team of open source developers spread across the globe. For example, I’ve recently been using Taiga. It’s a great looking bit of software and really easy to use. But hold on, what happens when you want to close a sprint? Well, normally, you’d make a note of the stories that didn’t reach Done, maybe note also the ratio of stories Done vs not Done, and close the sprint. But Taiga operates on the policy that a sprint closes when all the stories are Done. Until then, the sprint can’t be closed. OK, so I’d love my teams to get all their stories to Done. But in reality, this doesn’t always happen In fact, Scrum works on priorities, so sometimes you half expect the stories near the bottom of the sprint to not get finished. C’est la vie. Taiga, instead, operates on the fallacy that teams will get all their stories to Done. Always. The solution? At the end of the sprint, you have to move all off the not-Done stories out of the sprint and back into the backlog. The sprint then closes. Oh, but now the tool will tell you that you completed 100% of your stories in that sprint, which was zero. Gah!

Necessity

Recently, I’ve found myself acting as Scrum Master for a team that’s located about 200 miles from me. I’m using agile management tools. It makes me feel a little dirty, but the team is getting some use from them. We were using Taiga (see above) with some manual note taking thrown in to cater for its restrictions. I can live with that for a while. But what about retrospectives? This is an area that I really enjoying indulging in. But that’s when I’m in the same room as the team, reading emotions, watching body language and, in many cases, veering wildly off course to cater for something crazy that pops up during the exercise. With a team that’s 200 miles away, I had to revert to tool usage again. I scoured the web for a cloud-based retrospective tool. I found some. I tried one for two retrospectives. It worked. But boy, by the end of each retrospective I was exhausted! Why? Because I had imagine the feeling of the remote room; I had to work hard to listen over VoIP to gauge the sentiment of the team. It was very very hard work. The tool allowed us to type things within certain columns (like Mad, Sad, Glad) but what was missing was that human touch. The unsaid.

I don’t blame the tool for this; it was making a good job of a less than desirable situation. But boy would I have preferred to be there, in the thick of it.

So, I’m no tool playa. I’m a hata. Word.

Agile, Scrum

Keeping It In The Retrospective

By No Comments
Keeping It In The Retrospective

“What happens in Vegas, stays in Vegas” so the saying goes.

Retrospectives are a well-known, but not necessarily well understood or well executed ritual from the Scrum framework. In fact, retrospectives have been around in one form or another long before Scrum became mainstream.

This is what the Scrum Guide says about retrospectives:

“The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.”

Over time the retrospective ritual has grown to encompass not just the previous sprint’s activities, but the well-being of the team. Esther Derby, co-author of Agile Retrospectives – Making Good Teams Great, says:

“..retrospectives focus not only on the development process, but on the team and team issues. And team issues are as challenging as technical issues—if not more so.”

At Bright Interactive we have several teams of different sizes and with different purposes and goals. For each of them, we have regular retrospectives. If they are facilitated well, and certain constraints are put in place, they turn into valuable gatherings where real change can happen.

Retrospectives deserve and have many books written about them, so I’m not going to delve into the subject any further, but there is one thing I want to share with you: transparency.

Open

Much is made of being transparent within agile practices. In Scrum, for example, the Scrum Board is an information radiator, allowing everyone and their dog to see the progress made by a development team; the Definition of Done is supposed to be a publicly-visible contract, open to scrutiny; and likewise, the retrospective is a time in which all team members have an opportunity to talk openly (bound by the team’s Working Agreement). However, recently at Bright Interactive we’ve been trying something different with our retrospectives: secrecy.

Retrospective

OK, so “secrecy” is a bit strong here. Up until recently all of our retrospectives have been published internally for the whole company to read. This in itself is not a bad thing, as openness and honesty are good things for teams to practice. But we tried an experiment with one of our teams: we said that everything said in a retrospective would stay in the retrospective. Once a retro’ exercise had finished (for example, variations on Speedboat, Starfish, Mad Sad Glad and the like) and an action or two had been agreed upon – this is important – the board would be wiped clean and all stickies consigned to the bin. We did this with agreement from the team first, naturally.

As soon as we tried this, the team was more open and explicit (in a good way) about a lot of the things they wrote up on their stickies. At first we were concerned about the items that gone thrown away, but once they had been discussed and an action settled upon (which we do for every retrospective) this didn’t seem to irk the team. Normally, many of the trashed items related to specific events from the previous week, and those items which transcended several weeks or iterations would come up again in subsequent retrospectives anyway.

That said, this is an experiment. If the team decides that documenting retrospectives bring more pros than cons, then we’ll resort to that. In the meantime, we’ll keep it in the retrospective.

Scrum

90 Minutes of Nerves

By No Comments

If you’ve been hiding under a very large rock for these past few years, then you wouldn’t have heard of the #noestimates ‘movement’. However, everyone else that works in the field of agile development has probably heard of it, or even tried to embrace some of its ideas.

I’ve been keeping an eye on this oft-misunderstood hashtag through Twitter and the numerous blogs that have sprung up since the tag become popular. One such author that I’ve been digging quite a lot is Vasco Duarte.
Vasco wrote a book on the subject (currently in beta) and kindly made it available to anyone who was willing to give it a read and provide him with feedback. I was one of those people.

It was quite a read. In fact, it cemented the idea of #noestimates in my mind, making me more determined to try it out wherever possible (which, when you work in a development agency with external clients, is no simple task). However, “it” is quite hard to define. No estimates isn’t actually about absolutely NO estimation; it’s about acknowledging that estimates aren’t really worth the effort that many teams put into them. Anyway, that’s for another post. I mention Vasco because he also put out a call to all scrum masters, asking for volunteers to be interviewed by him for his new podcast series, “The Scrum Master Toolbox.”

I put my name forward and a few weeks later, there I was on one end of a Skype conversation with the man himself. I’m actually quite nervous when speaking into a microphone (and also, like many others, I detest the sound of my own voice), but Vasco put me at ease and soon we were just talking like buddies in a bar talking about, err, Scrum.
He fired some tricky questions my way, but I think I was able to field most of them. We spoke about failure, measuring success, interviewing, bad moments, good moments and a whole lot more.

I’ll post a link to the podcast when it’s published. In the meantime, enjoy the ‘casts that are up there on the site.

The Scrum Boy

Scrum Master Toolbox Podcast

Vasco Duarte’s blog

#noestimates on Twitter

Scrum

Buses

By No Comments

You’re waiting for a bus. You’ve waited ages. Then four come along.

Well, sometimes it feels this way when being a Scrum Master at a company whose income relies on multiple clients requesting projects of all shapes and sizes.

I have one project which is ongoing with rarely a break between 10 day sprints. The team pretty much looks after itself, and our busiest times together are Tuesdays when we have both a sprint planning session and a retrospective for the previous sprint. Tuesdays are busy, but the rest of the time, I can almost take a backseat.

I had a project which lasted just two sprints. It finished very recently, but the client is making noises about buying a third sprint.

Then there was yesterday. It was Tuesday. I had a backlog refinement session, two sprint planning sessions, a retrospective and a project management knowledge share meet. Bang. I had about 30 minutes to myself throughout the entire day. But this kind of busy is a good kind. Despite the day being consumed by meetings, each one of them was highly productive and, dare I say, fairly exhilarating! See, we’ve got a team of developers that are really starting to get what it means to work in an agile way. Sure, there are holes that still need filling with knowledge and experience, but generally, we’re all on the same page, so to speak.

Yesterday also saw the kick off to a brand new project. There’s only three of us on it, but we were all up for doing it right. We’ve drafted a great, concise Definition of Done (I always consider DoDs as draft – always up for review) and stuck it up in the office; we agreed to use as much test automation as possible, so we set about getting a Jenkins CI server up and running, along with a SonarQube instance to keep track of our coverage metrics; we nailed the acceptance criteria for all stories before choosing which would go into sprint 1; we agreed to use a physical Scrum Board (I like whiteboards – but other teams have plumped for Scrumwise); we created faintly amusing personas for our user stories (helps us picture real people using our product) and the Product Owner has even secured the time of two external clients to act as stakeholders for us.

Even though I got home desperate for a rest and a fat glass of wine, I was still buzzing from the enthusiasm of the people I work with.

I think back to my Scrum Master training, and how I said to myself, “This is the job I want.” And now here I am, realising that thought and looking forward to growing my skills, and the skills of the teams I serve.

Awesome.

Scrum

Softly, softly

By 1 Comment
Softly, softly

I won’t deny it; I used to be a fairly aggressive chap at work. Not in a physical sense; nor in an abusive sense. Rather, I would call it like it I saw it, even if that meant I’d trigger an argument or fight. I’d send my opinions into battle and keep reinforcing them until the war was won.

In a way, it was satisfying. In others, it was horrible. It wasn’t really in my nature, but at work I wore a different persona (I think we all do), and it wasn’t a great one. I wasn’t a horrible person. But my patience wasn’t great.

Yuk.

It took a job-change to make me realise that I needed to change path. I needed to practice the art of saying nothing. I needed to listen. I needed to let people fail rather than try to teach them, to press them, to succeed.

I think I’m getting there. And I think I know why. In my old job I was both a “senior” developer and a Scrum Master. So I was trying both to force home technical solutions and be open to all. I now know that wearing these two hats is no easy task.

I’m now 100% Scrum Mastering. And it makes such a difference. It’s taught me to accept that the developers I serve are the experts in their field, and that I need to let them make the decisions, good or bad, right or wrong. At most, I guide; normally using stories from my own experiences. I question, but I don’t demand answers. I educate but I try to keep it to lessons about Scrum and practising agility.

I’m happy with this state of affairs. I’m happy with myself.

angry-face-clip-art-black-and-white-printable-coloring-book-smiley-face-clip-art-vector-clip-art-online-royalty-free-happy-face-coloring-pages