Search This Blog

11 June 2017

LAST Conference 2017, Melbourne

LAST conference is in it's sixth year this year.

LAST is a cross functional conference, that has roots in the lean and agile movements.

Cross functional?
This conference  is a platform for a variety of people to meet together and share. It's so much better than a bunch of software devs, Product managers or testers circle jerking themselves.

Roots in Agile and Lean?
The truth is that these days we steal the Agile and Lean  labels and co-opt them for our own agenda; which is "The Learning Organisation."

Goddamit, I should be better than this at four martinis. (But maybe my source remains opaque ans special.)

So, go sign up and buy a ticket.

Seriously, you'll thank me later. It is really a globally unique experience. And it's fucking amazing.

What? You want your annual training budget to be expended on, what? The mediocre crap fest that a google search pays off? 

(Amusingly my personal search on that topic yields not one reputable result I would recommend let alone pay for. Maybe your google profile is more optimised for good results than me.  I hope it works out for you.)

No seriously, people, get to LAST. Then think seriously about your training and development budget after your eyes are opened to the real potential before you.

1 May 2017

Writing Better User Stories

The patterns of a product owner writing user stories for software development teams is an opportunity to be improved upon.

On Tuesdays at 11am, Mark walks over to the round table near the window. The team see he is ready and wrap up the tasks they are on. Justin heads over to the kitchen and grabs a fresh water. Jerome grabs the two index cards that are still in play from the whiteboard and brings them over to the table as well. Zoltan grabs some sharpies and a stack of post-it notes and walks over with David. They sit around the table.

I walk across and ask if I can sit in and observe the meeting.

Mark plays down six index cards onto the table like a blackjack dealer. Unlike blackjack the cards are all face up with Mark’s almost legible scrawl on them.

Mark picks one of the index cards up and starts reading it to the team. There is a back and forth across the table about why this user story, how does it help the customer, and how it might be implemented. After about 6-7 minutes a consensus is reached and Zoltan grabs the card, flips it over and writes a few acceptance criteria on the back, reading them aloud to the team as he writes. The other software developers on the team chip in with minor adjustments to the phrasing.

By the end of the session, all six cards have been accepted into the sprint and each of Mark’s index cards have also been marked up with the handwriting of the team members on the back.

The guys started to shift, getting ready to get up and head back to their desks to get a little more work done before heading out together for some Korean Fried Chicken (and beer.)

“Hey, before you go, can I ask a couple of questions?”

Everyone settles back into their seats and look at me expectantly.

“It’s interesting to me that each of you on this team have written on the cards. You all took turns to write up the acceptance criteria. Why is that?”

“Well,” says Justin, “If I write the card, then I know what I mean. If someone else writes the card, I have to struggle to remember the details of this conversation and probably have to repeat most of it in three or four days’ time.”

“It’s just easier this way” says Jerome.

“Cool. When did you start doing this?”

“I can’t remember. It just started one day. It didn’t come out of a retro or anything, but we did used to talk about how often we would repeat the user story discussion over a week or fortnight,” said Jerome.

***
There are fundamental reasons why this practice of shared story writing is better than having a product owner or business analyst be the one to exclusively write the user story cards.
Think about your own experience listening to others.

Your attention wanes in and out. You remember parts but not the whole of conversations. And the things that stand out in your memory the most aren’t necessarily the most important things.

However, when you take notes things change. For a start you need to make choices about what to write down. This makes you think about the content in more than one way – you are listening to it, engaging with the idea behind it, thinking about which points you want to focus on in your notes and also choose the words you use to represent the idea. Finally, your body also has to contribute to the note taking. Your hand moves a pen across some paper. Your eyes then read it to confirm what you have written is correct, and then you process the idea again.

All of this is going on almost simultaneously.

As you can see your brain is working much more when taking notes than just listening. This means that the memory around your idea is being imprinted much more firmly in your head than if you had just been listening, or even if you have been engaged in a discussion. You are creating multiple connections in your memory to the idea through these interactions and transaction.

Note taking is a powerful tool when trying to understand and later recall an idea.

(A side note; the act of physically writing appears to be a more powerful tool for understanding and remembering than typing. Even holding an index card improves understanding more than reading a screen because of the same multi-sensory processing going on.)

***
“Nice. Let me ask you another question,” I said. It was almost time to wrap up. The fried chicken was calling. “If this is a good practice, what would make it better?”

The team looked across to Mark, the product owner. A pause. Everyone thought for a moment. One of the guys was chewing his inner cheek as he thought. Zol twirled a pen around his finger. Then David, the team’s designer spoke up. 

“We shouldn’t let Mark touch the cards at all.”

Mark was confronted by this idea.

“I don’t feel comfortable with turning up without cards to talk to.”

“That’s okay. You bring your cards, but we will rewrite our own.”

***
There is another opportunity in writing cards rather than receiving them. Can you guess what it is?

Imagine this scenario;
We sit at the table described above. I’m the product owner and I hand you a card with my user story on it. I tell you what the customer goal is, their motivations, the constraints and related rules around the user story. You listen attentively. It seems kind of obvious. You ask one or two questions about what I explain.
At the end of this discussion, because I am diligent I ask you; “Do you understand what needs to be done?”
You give a short nod affirming you understanding and head off to do the work.

That sounds straightforward and simple, right?

Now imagine this scenario.
Same job, but this time I hand you a pen and paper and you write the notes. I still tell you the same things but this time you are actively asking questions and drilling into what I am saying because you are writing notes down. You choose the description. You use your own mental models to frame the written description. And at the end you say what you understand the job to be, by reading out what’s on the card.

Which of these two scenarios is going to better equip you to go away and do the work?

***
Mark and the team tried the experiment and it was useful for a while. Over time they vacillated between Mark writing cards and the team writing the cards. They are a tight knit group and these days anyone writes whatever needs writing regardless of role.

There was one last effect I saw as they played this out, and it isn’t specific to the technique. It’s more about the people; By putting the card writing in the hands of the delivery team it put responsibility into their hands to pointedly and specifically ask “What’s in this for the customer.” Over and over again they guys asked that question.  They were always very customer centric, but they were no longer being told. They were actively asking. That helped the knowledge acquisition and it helped memory and focus. It also helped with prioritization and managing scope better.

***
It’s funny. People like to find patterns and follow them. Inherent in high performing teams is the need to go farther and do better. The job isn’t done when you have your requirements on a pin-board and can ship features fortnightly. You don’t follow a manual.

The fundamental thing about this agile movement is learning through doing. You inspect and adapt. You ship and get feedback. You collaborate, deliver, reflect, and improve. You explore and learn. And that means experimenting and researching.

The scientific theory behind these ideas idea is pretty well established, although there is debate about how to make the most impact for memory. And it’s intuitively true to most people when you describe the ask over tell mode of communicating. Most people just get it. Still, people don’t change their habits without expending their limited energy.

To help you shift I want to ease you in with a low-cost experiment.

Share this post with your team mates and talk about it together.  Propose that you all run the new card dynamic as an experiment in your next sprint. If your Product Owner is currently writing ALL the cards, maybe take the first step of just taking over acceptance criteria. But why stop there. It’s an experiment. You could just take over the whole card writing thing and give it a shot.

Then, at the end of each week, maybe for two sprints, talk about whether the new card dynamic has paid off in any ways.

***

Here are some links to more on this topic in case you want to go deeper.


Some details of this anecdote have been simplified to make the point, but this is a real case study with a real team.

As always I love to hear feedback if you try any of my ideas out. Comment below, tell me direct etc.

Thanks for reading.

 

30 March 2017

Meetup notes: An introduction to Scrum

Last night I ran a meetup introducing people to Scrum. Lectures are boring so I made it a game. At a rooftop bar.

Meetups in bars are best. Lucky it wasn't raining.

Agenda on the night

Tools I provided;
  • A printed copy of the Scrum Guide for each table.
  • A copy of my run sheet for the night
  • The picture from Wikipedia of Scrum
I organised people into teams of 3-4. People made this teams of 3-6. People were drifing in for up to an hour from the start time and we joining teams in progress.

The agenda on the night was as follows

1. Form teams, introduce yourselves to each other. Small teams work best. Take a photo of your team and publish it on the meetup site.

2. Focus you conversation tonight by coming up with specific questions your team wants answered.  You must write them down. Post a pic of your questions to celebrate the completion of this milestone.

3. Now, as a team, with the help of the scrum guide, the internet and the people in the teams around you, go answer your questions. When you are done, take a picture of  your answers/and your team celebrating success.

Why this format?

Learning works best when you pull (not push) information. Generating questions and hunting down answers mean the knowledge gained will be more personal, be better retained and be more useful.

Agile teams work best with clear goals and small teams. You practiced working this way.

Ideally you have all the skills you need on your team, but usually you don't. The activity provided this very problem and now you have experience solving it.

Meetups are about fostering a community of people who share with each other. Far better than having an expert stand out front while everyone sits quietly and listens.

It was fun.

What I observed

Most people didn't open the Scrum guide unless prompted. Even though a printed copy was on each table. This reinforces my views on oral traditions being the only ones that matter.

The activity surprised me by being a study on scaling work across multiple teams. Good will and respect for other people's time are all you need to scale. Anyone tells you anything else is selling something.

While most people professed to be absolute novices at the end of the night everyone pretty much said they had their questions answered and their goals for the night satisfied. I think I helped out with two answers and pointing two teams at the Scrum Guide.

So I think it was a successful meetup.