Courtney Johnston

We’re very pleased to announce that Boost New Media has been named as one of only 48 companies who are now WorldBlu certified as a democratic workplace.

“People want freedom rather than fear in the workplace,” comments WorldBlu Founder and CEO, Traci Fenton. “WorldBlu-certified organizations model how democracy in the workplace unleashes human potential and builds highly successful organizations that change the world for the better.”

We became eligible for a spot on the WorldBlu List of Most Democratic Workplaces™ when every employee completed a WorldBlu assessment evaluating our company’s practice against the WorldBlu 10 Principles of Organizational Democracy™.

Nathan Donaldson, our Managing Director and founding owner is a big believer in the principles of a democratic workplace. Nathan believes that the more employees are asked to input on the strategic direction of the company the more engaged they become. As a result Boost has happier employees which in turn has resulted in a low staff turnover rate.

Some of the steps we’ve taken to become a democratic workplace:

• Yearly strategic planning meetings
• Quarterly planning retrospectives
• An ideas and questions board
• Boost strategy scrum
• Group interviews of prospective employees

Once a year we devote half a day to strategic planning. The entire company sits in a meeting room and workshop ideas for goals for the coming year. Everyone contributes and we all get to vote on the ideas we’d most like to commit to. We then decide who should drive the tasks associated with each goal and when they should be done by. We all agree on our shared goals as a company.

To ensure we’re on track with our goals and to capture any concerns we hold a planning retrospective quarterly. This allows us to track progress and address any concerns arising.

Our ideas and questions board is located in our kitchen, giving everyone easy access and opportunity to make suggestions about any aspects of the company. The current categories are tools, processes and goals. We’re encouraged to contribute any ideas we might have for improvements or changes by post it note.

Although not everyone is involved in the day to day tasks associated with Boost’s strategic direction, we do run this work by scrum. This means that all tasks are displayed on a scrum board so that everyone can see the status of tasks (not started, in progress and completed). Essentially all strategic work is transparently displayed to anyone who is interested. We find that the underlying principles of Agile work well with the aspiration to be a democratic company.

Our hiring process is another area where employees are invited to get involved. The candidate is initially interviewed by the Managing Director and the General Manager and if they feel they would like the candidate to progress further the team are asked to come to a meeting room and meet the candidate. We’re all encouraged to ask the candidate questions and then once the interview is over we’re asked for our thoughts on the candidate.  This means that every new employee is someone the whole team have met and agreed will be a good fit for our company.

We’re delighted to be recognized by WorldBlu as New Zealand’s first certified democratic workplace. We’ve found that using democratic principles results in happier and more productive employees who feel more engaged and motivated.

Related Posts:

• No Related Posts

Introducing Scrum to an organisation is notoriously difficult but also fabulously rewarding. Making the shift from traditional project manager to Scrum Master can also be very challenging.

Australian Scrum trainer and coach Kane Mar will be at here at Boost running a Certified Scrum Master course on 29-30 March. On Thursday the 29th he’s giving a free 20 minute talk sharing his war stories and recommendations about his experience of moving from traditional project management to Scrum. We’re opening our doors to people interested in project management and Agile practices to join us for Kane’s talk. To sweeten the deal we’ll be putting on drinks and nibbles for everyone who wants to stay on for a more informal chat after the presentation.

We’ve stoked to have Kane over to run this Certified Scrum Master course at Boost again, following a very successful course late last year. Kane is a full-time Scrum trainer and Scrum coach and has been writing about Agile software development since 2005, you can read more on his website. We have a small number of places remaining on the course, if you’d like to find out more about securing a spot, give us a call on 04 939 0062 or email us on info@boost.co.nz.

Kane Mar: From traditional project manager to Scrum Manager

When:  6pm, Thursday 29 March 2012

Cost: Free!

Where: Boost New Media, Level 8, 75 Ghuznee Street, Wellington

Please RSVP by emailing info@boost.co.nz

Related Posts:

• No Related Posts

Yesterday I posted on two themes I found emerging at Webstock this year: working with design/ers and crafting experiences. Today I’m turning to finding your joy, strategic creativity and One Big Idea ….

Living a good life

There was a definite sense of reassessment at this year’s Webstock.  As Jeff Atwood wrote in a recent blog post, announcing he was stepping away from Stack Exchange, start-up life is hard on families. Walter Isaacson’s biography of Steve Jobs is causing reflection in a generation of people who have been pouring their guts into these ventures for the past decade.

Atwood was cited by Matt Haughey in his talk Lessons from a 40 Year Old. “Success at the cost of being away from your family is not success”, Haughey said, arguing that that world is full of ideas that could be executed in 20-30 hours a week, rather than while living off pizza and Coke and getting 2 hours sleep a night huddled under your desk.

The only thing I wrote in my notebook during this talk was THE SLOW STARTUP MOVEMENT. The shared notes for the session record the examples of long-term successful, self-funded companies, the go-to example being Marco Arment’s Instapaper (and see Arment’s response to Atwood’s announcement).

Amy Hoy also renewed up the Webstock tradition of talking inspiration, not technology. In a talk titled Change the Game, she urged us to ignore the invisible rules and the false dichotomies and to find our happiness instead: a true return to the militant strain of joyousness Webstock so often fosters. (And as a sidenote, try watching Matt Haughey’s talk once it’s online then following up with a dose of Hoy’s Fuck Glory – Start-Ups are One Long Con.)

Strategic creativity

Two of my favourite talks this year were by people who have a superpower I utterly envy: drawing. I was fascinated by how illustrator, letterer and designer Jessica Hische and designer, developer and cartoonist Matthew Inman have developed their careers.

Hische noted at the start of her talk that illustration and design are very different industries, and that she feels illustration has better deadlines, better customers and a better understanding between client and illustrator. She also noted that having an artist rep makes getting work and negotiating with clients easier, and that when you’re an illustrator, people assume you’ll be doing freelancing on the side, and are perhaps less demanding as a result.

While being endlessly amusing, Hische also had some strong messages about the intent and benefits of side projects (her own reputation having been significantly enhanced by the well-known Daily Drop Cap project). She noted that she often hears people say that they only get work they don’t want to do, and sees this as a reflection that their portfolio doesn’t reflect the kind of work they do want to do. She started Daily Drop Cap for similar reasons:

• It was set up when she went freelance, to garner attention.
• It was an opportunity (or demand) to be creative every day.
• It’s resulted in an “insane lookbook” for clients, who can survey 300+ examples of her work and use them to identify what feel they want.
• She became known as ‘the drop cap girl’ – which has been no bad thing.
• It’s a side project that’s project her similar paid work (because people always want more of what you’ve done before).

Hische also coined one of the most tweeted sentiments of the conference, talking about the short shelf-life of ideas:

The shared notes for Matthew Inman (of The Oatmeal fame) are some of the shortest for the whole conference, probably because people were too busy laughing to type. But as with Hische, I was impressed by how Inman has strategically moved away from client work that bored or frustrated him, and made his creativity work for him.

I was struck by how closely Inman watches the stats on his site, and rearranges content or creates new pieces to capitalise on this. I also thought about how ephemeral political satire is (most political cartoons have only days or weeks of relevance) but how a guide to correctly using the  word ‘literally‘ will be relevant over and over again. And his short rules are gold:

• Write about the things you hate
• Write about the things you love
• Be inspired by facts you learn
• Don’t throw your face up on everything
• Be a good follow
• Don’t ask for likes – make things that are likable
• Keep it short
• Don’t spend too much time on it
• Don’t have your friends look at it.

One Big Idea

Okay – it’s not such a big idea. But: the beauty of Webstock is that it makes you want to keep exploring.

I would love each presentation to end with a slide with three books or articles that the speaker recommends, in the spirit of ‘If you liked this talk, you might also like …’. Or perhaps a Webstock Reading List on the Webstock website (a little like the Kiwi Foo reading list).

Webstock is mind candy (with a side-helping of eye candy) and this, combined with the videos of the talks, would make for year-round inspiration.

Related Posts:

• Webstock 2012: design and craft
• New look for the Poet Laureate on National Poetry Day
• Winning websites
• Magic and delight

My single favourite quote of Webstock 2012 came courtesy of Scott Hanselman:

So many people who had great blogs now have mediocre tweets.

Given the immense volume of tweets and the beauty of shared notetaking, I now try to stay offline as much as possible at Webstock, so I can focus on the speaker and my pencilled notes. But over the last few days I’ve tried to boil down some of the themes I heard emerging to share here, in two posts. Today: design and craft. Tomorrow: find your happy place, strategic creativity, and One Big Idea.

Working with design/ers

One of the greatest revelations to me since coming to work at Boost has been working with designers. As someone who works primarily through words, I don’t think I’ll ever get sick of watching designers do their thing.

It’s also been humbling to find out how accidentally moronic I sometimes was as a client. Here’s a reenactment of a series of comments I once gave to a poor designer:

I really like what you’ve done – but could we maybe see it in blue instead of brown?

Oh, okay. Hmmmm. How about green?

Oh. Sure. Right. Look, I’m really sorry to keep doing this – but perhaps we could see it in pink?

It’s still not quite right – could you show me the brown version again?

Hey – the brown version’s great! Let’s go with that.

Yeah. I was that person. Now, of course, I realise that (a) designers will always be better at design than I am and (b) almost every variation of colour, placement and size has already been trialled before the best version is shown to the client – and if it wasn’t trialled, it’s probably because it was a bad idea.

So I was delighted by all the speakers who touched on how we can work better with design and the good folks who craft it.

Adam Lisagor hit so many buttons for me on this topic. Here are some of the things I scribbled down (more here in the shared notes):

• ‘Thank you for knowing what you wanted’ – the compliment for a dream client.
• There’s a difference between opinions (just saying stuff because you’ve been invited to a meeting and hey – you get to share your opinion!) and people who are identify problems and want to find answers.
• If you’re the spokesperson for a committee, speak with one voice: either distill the many voices to one piece of feedback, or at least take the names out.
• As a designer, you have been chosen for your demonstrated taste. Sometimes, your client is paying you to correct them.
• The phrase ‘treat me nicely, with trust and respect’ works for both sides.

Michael B Johnson from Pixar also had some doozies. Here he is on Giving Good Note (aka feedback):

• Point out the problem
• Offer a solution (to show you’ve thought this problem through) (not because you expect this solution to be used)
• Give this at the time when it can still be used.

Johnson also invoked the rule of ‘Yes, And’ rather than ‘No, but’, and noted that great teams have great morale, which is needed in the face of constant criticism. I love that at Pixar, criticism takes the form of ‘plussing’ – it’s part of the company’s culture, and it’s essential to the way they create things.

Finally, Jared Spool made a million interesting points, outlining five different breeds of design (Unintentional design, Self design, Genius design, Activity focused design, Experience focused design). The points that really stood out to me came out towards the end:

• Every style has a purpose
• Great designers know which style they’re using
• Great designers use the same style throughout a project
• Great teams ensure everyone uses the same style (and everyone understands that they’re doing this)
• The more advanced the style, the more expensive this will be
• The more advanced the style, the better the design.

Crafting experiences

Webstock 2012 opened with a clarion call for making experiences from returning speaker Kathy Sierra. She gave the idea of “building engagement with users through social media” a robust bollocking, arguing that no matter how awesome your brand or product is, it’s the awesomeness your users feel about themselves that counts. I was interested in her ideas about aligning business goals with user goals, but found myself wanting more actual examples of where she sees this awesomeness happening.

I wasn’t in content strategist Erin Kissane’s presentation, but it sounds like adopting an attitude of craftsmanship (and allowing time for it) were big themes of her presentation. It seems Erin was asking how to bring the values of craft (mastery, human scale, excellence, satisfaction) to large scale system. I’m looking forward to watching her talk when it’s up on the Webstock site.

One of my favourite ever Webstock talks was Cal Henderson at Webstock 2008. I’ve always enjoyed the presenters who take you on a deep dive into the work they’ve  done, while teaching you more general lessons along the way. This spot for me was filled this year by responsive design guru Ethan Marcotte, talking about the Boston Globe redesign (if you’re too impatient for the video to go up, check out his blog post on this).

Ethan ran us through the opportunities and challenges of reshaping the bulging content of a newspaper into the slim lines of various desktop and mobile devices, and the ways that designers and developers might be able to change their usual working patterns to meet these (it sounded a lot like what I see in our teams that are using Scrum).

Craft took centre stage in Jennifer Brook’s presentation about publishing and the iPad, where I was more captivated of her stories of teaching herself to bind her own books than I was by her story of working on the New York Times iPad app. I’ve squirreled away her recommendation of Designing Calm Technology for later reading.

Tomorrow

Those were my first two themes. Tomorrow I’ll cover off finding your happy place, strategic creativity and One Big Idea.

Related Posts:

• Webstock 2012: happy places, strategic creativity, and One Big Idea
• Data data everywhere: Pew Internet on social networking sites and A List Apart on the web design industry
• Writing for the Web – same as it ever was?
• 7 steps to launching with great web content

Behavior Driven Development has become a key tool in our toolkit as developers strive to become leaner and more agile. Here at Boost we have been using Cucumber with Ruby on Rails to integrate Behavior Driven Development into our everyday software engineering practices.

At Boost we’ve been using Test Driven Development (TDD) for some time now.  Test driven development is a process whereby the developer writes an automated test prior to the beginning of coding of a new function or improvement to an existing function – the test fails at the outset as no code has been written.  The developer then develops the code to pass the test, as well as refactoring the code to an accepted standard.

We’re also using Behavior Driven Development (often referred to as BDD).  Behavior Driven Development extends Test driven development by writing text cases in a way anyone can understand. Behavior Driven Development fits in well with Scrum in that the Behavior Driven Development tests can be written by the product owner.  A product owner writes acceptance criteria for a user story within a sprint, but by asking the product owner to contribute to Behavior Driven Development testing by writing feature descriptions we are fostering collaboration rather than merely co-operation.  The product owner is able to take fuller responsibility for a successful outcome.

Over the last year we’ve been using a tool that combines both Test Driven Development and Behavior Driven Development.  Cucumber is a tool that enables the product owner and developer to work together to produce features. Here’s how it works:

1.  The product owner writes a plain text description of a task and how it should work using a particular syntax (Gherkin) and providing scenario examples.  Here’s an example of a feature description written for our Intuition HQ site:

Feature: Sign up to a plan
Sign up should be quick and friendly.

Scenario: Successful sign up
Users should see a confirmation when their payment details have been accepted.

Given I have chosen to sign up
When I sign up with valid details
Then I should receive a confirmation page

Scenario: Invalid card number entered
Where an incorrect card number is entered

Given I have chosen to sign up
But I enter an invalid payment card number
Then I should be told that the card number is invalid
And the form should be redisplayed offering me the opportunity to re enter my card number

2.  The developer writes corresponding step definitions.  The step definitions should include the phrases used within the feature description.  The step definitions are tests written in code that Cucumber then runs against the site. The first time the tests are run they will fail as no code has been written.

3.  The developer writes code for the new functionality described in the  feature description and re runs the tests.  Cucumber highlights success within the feature description in green, pending in yellow and failure in red as shown in the image below:

5.  The developer amends the code and reruns the tests and so on until Cucumber shows the entire feature in green indicating that the tests have been successful.

The advantage of working with Cucumber is that both Behavior Driven Development, (in the form of the feature descriptions and scenarios) and test-driven development, (in the form of step definitions), are used to verify the success of development.

I spoke to one of our developers about his experience of using Behavior Driven Development and his response was that one of the most important advantages of using Behavior Driven Development is that it allows the product owner to write acceptance criteria in the form of features. The developer can then work towards developing step definitions to test the features the product owner has defined. The step definitions correlate with the acceptance criteria/features with the intention of leaving no discrepancies between what the product owner wants from their product and what the programmer develops.

Behavior Driven Development is proving to be a valuable tool in helping us to eliminate the gap between developer and client understanding of requirements therefore producing successful and useful features.

Related Posts:

• No Related Posts

In a recent post I discussed the question “Are user stories the same as use cases?”. This is a question that frequently arises in our Writing Great Agile User Stories workshop, and it’s often asked by business analysts. I’ve also been in Agile/Scrum training courses with BAs, who at a certain point in the day start worrying about where the BA role fits in a Scrum project.

The quick answer is: there is no Business Analyst role in Scrum – just like there isn’t a DBA role or a SysAdmin role or a designer role. You’re either the Scrum Master, the Product Owner, or part of the Scrum Team. There also isn’t a space carved out for a person to be responsible for requirements gathering and reporting.

The longer answer is that there’s still a lot of work in a Scrum project for a good BA to do. As Roman Pichler puts it:

what’s left to do for business analysts in Scrum? I have seen business analysts working as team members as well as taking on the product owner role successfully. In both cases, though, the individuals experienced a change in their daily work. Business analysts working as a team member often support their peers in product backlog grooming activities. As the business analysis activities are now carried out collaboratively, the business analysts often have time to take on other responsibilities, for instance, working with the testers or the technical writer. As a business analyst working on the team, you should hence expect to pick up new skills, broaden your expertise, and be open to work in new areas.

One small case-study

I recently worked on a short (6-sprint) Scrum project that had a nearly full-time BA allocated as a resource to the team. (Don’t you love that kind of phrasing? “allocated as a resource”. Savour it.)

We were creating a mobile interface for a cut-down set of the functionality available through our client’s current website. Our team was made up of a mix of our client’s staff and Boost staff: a Product Owner, the BA, two developers and a tester from our client; a Scrum Master, designer and me doing the wireframes from Boost.

Here’s what our BA did:

Working with the product owner

• Research for writing user stories (usually by confirming how the current system works, and where there was and wasn’t flexibility to make changes)
• Meeting with other parts of the business to explain what we were doing and what we needed, and to find out what they were doing and how that might affect what we were making.

Working with the team

• Ferreting out system documentation
• Getting screenshots of the system that I (working outside their network) couldn’t access, and reviewing wireframes with me
• Helping write and QA’ing test cases
• Getting wording signed off by other parts of the business (always harder than you think it’s going to be)
• Getting approval from other parts of the business for use of a third-party plug-in.

Our BA attended all the planning meetings, retrospectives and stand-ups. Her work was managed just like the rest of the team’s: written as tasks and posted on the Scrum board. What she didn’t do was write requirements or use cases, or reports. There was huge value in having her on the team: she was our go-to person for all the tucked-away documentation and hard-to-find system descriptions.

Further reading

A four-part article based on a roundtable discussion amongst a group of Agile experts (including Alistair Cockburn, Roman Pichler and Ken Schwaber) on business analysis and Agile

• Part 1
• Part 2
• Part 3
• Part 4

Colart Miles has begun a promised series on the Clarus blog

• Part 1: Are business analysts the stem cells of Scrum?

Related Posts:

• Use cases vs user stories in Agile development
• Tina Fey’s Four Rules of Improv, as applied to Scrum
• Jean Tabaka on the Golden Circle of Agile & StackExchange for project management
• Agile experiments: creating user stories with story mapping and ‘buy a feature’ prioritisation
• User stories in action – the Agile development process

TL;DR – User stories aren’t use cases. By themselves, user stories don’t provide the details the team needs to do their work. The Scrum process enables this detail to emerge organically, (largely) removing the need to write use cases.

Are user stories the same as use cases?

When running our Writing Great Agile User Stories workshop, I’m frequently asked “So – are user stories the same as use cases?”. Often it’s a business analyst who asks the question; they’re accustomed to working with use cases, and are wondering where use cases fit in a Scrum project, and if they’re replaced by a user story.

Looking around the web, there’s consensus that use cases and user stories are not interchangeable:

• Alistair Cockburn: A user story is to a use case as a gazelle is to a gazebo
• ExtremeProgramming.org: User stories serve the same purpose as use cases but are not the same.
• Mike Cohn: User stories aren’t use cases

My standard answer is that user stories are centred on the result and the benefit of the thing you’re describing, whereas use cases are more granular, and describe how your system will act. And then I say “Just bear me – it will all be clear in soon”. But I thought it was time to dig further down into this.

Use cases and user stories

Let’s start with some definitions.

A user story is a short description of something that your customer will do when they come to your website or use your application/software,  focused on the value or result they get from doing this thing. They are written from the point of view of a person using your website or application, and written in the language that your customers would use. A user story is usually written using the format canonised by Mike Cohn: As an [actor] I want [action] so that [achievement]. So, for example: As a Flickr member, I want to set different privacy levels on my photos, so I can control who sees which of my photos.

A use case is a description of a set of interactions between a system and and one or more actors (where ‘actor’ can be people, or other systems: for example, both online shoppers and PayPal can be actors). They are usually created as documents, and generally include this kind of information:

• Use case title
• Rationale/description/goal
• Actor/user
• Preconditions (the things that must have already happened in the system)
• Standard path or Main success scenario (what will usually happen, described as a series of steps)
• Alternate paths or Extensions(variations on the above/edge cases)
• Post conditions (what the system will have done by the end of the steps).

At first blush, use cases look like a much better way of writing requirements than user stories. How will a team be able to implement something as wafty as As an [actor] I want [action] so that [achievement]. So, for example: As a Flickr member, I want to set different privacy levels on my photos, so I can control who sees which of my photos without some rigorous use cases to detail the requirements for the system? And that’s usually the point when someone in the workshop asks that question.

Writing use cases to flesh out user stories in Agile projects is certainly not unheard of (see here, and here). But it becomes clear as we move through the workshop that user stories are just the start of a process of understanding what the team is making that, by the end of its course, covers off everything a use case would have told you, but in an organic manner.

Acceptance criteria

User stories aren’t just single sentence affairs. The product owner also writes acceptance criteria, which define the boundaries of a user story, and are used to confirm when a story is completed and working as intended. For example, if this is your user story: As a conference attendee, I want to be able to register online, so I can register quickly and cut down on paperwork, the acceptance criteria could include:

1. A user cannot submit a form without completing all the mandatory fields
2. Information from the form is stored in the registrations database
3. Protection against spam is working
4. Payment can be made via credit card
5. An acknowledgment email is sent to the user after submitting the form.

Writing the acceptance criteria is the first step of fleshing out the details of your user story

Sprint planning meetings

In the sprint planning meeting, the product owner presents the user stories from the top of their product backlog (ie. their highest priority features) and the team commits to the stories they will complete in the sprint.

As the product owner presents the stories, the team will ask questions to further clarify the user story and the acceptance criteria. Assumptions will quickly be confirmed or corrected, and any ambiguity about the requirements starts to disappear.

This assumption and ambiguity erasure continues as the team estimates the stories (if five people on the team rates a story as a 2, and one person rates it as a 5, there’s probably some questions that need answering). And it’s repeated again as the team writes the individual tasks for each story.

Standups

We’ve been fortunate in our Scrum projects, in that our product owners generally commit to attend the team stand-up. This is another chance for the team to ask questions, and also to make the product owner aware of restrictions, issues and opportunities are appearing as the story progresses.

Wireframing

I do the wireframing for some of our projects, and usually I start by talking to the product owner about the story, and sometimes making some paper or whiteboard sketches. I turn these into wireframes and then there’s normally a couple of quick iterations with the product owner as we ask each other questions, get feedback from other people, and hopefully squeeze in some user testing.

More recently, I’ve started reviewing the draft wireframes with the designers and developers working on the story. This helps flag up any questions they have, or restrictions I might not have been aware of. After the wireframes are approved by the product owner, I’ll brief the designers and developers again if needed.

Design and development

Although most of the details have been thrashed out during the wireframing more can crop up at this stage, and there are often more questions for the product owner about exactly how they want the backend of the system to behave. Pair programming is useful here, because two sets of eyes on a piece of functionality mean yet more questions and clarifications.

No user story is submitted for acceptance by the product owner until the acceptance criteria are satisfied and the definition of done is met.

Overall

This might sound like a lengthy process. In reality, it’s just what a Scrum team does all day. Rather than one person labouring over the use cases, the team works together to surface and satisfy all the requirements. The product owner can refine the original acceptance criteria in response to new information throughout a user story’s progress.

And finally, in conclusion

There are exceptions, of course – and there are times when the upfront research needed for use cases is important (I’ve got a blog post brewing on this). But my advice would be: don’t start writing use cases until your team specifically asks for them. And if your team does ask for them, spend some time in a retrospective digging into what they’re not getting from your current processes (for example – are the acceptance criteria unclear; is the product owner  unavailable; are you working with shitty documentation for another system). Then decide as a team how to fix the root problem.

Further reading

Advantages of user stories for requirements – Mike Cohn

Requirements 101: User stories vs use cases – Andrew Stellman

Related Posts:

• Agile experiments: creating user stories with story mapping and ‘buy a feature’ prioritisation
• User stories in action – the Agile development process
• Business Analysts and Scrum projects: A short case study
• Tina Fey’s Four Rules of Improv, as applied to Scrum
• Scrum in 10 Minutes

Driving home for Christmas, I listened to the audiobook version of Tina Fey’s Bossypants.* Listening to her read the chapter Rules of Improvisation That Will Change Your Life and Reduce Belly Fat, it struck me that the four rules of improv that she describes translate well to the spirit of Scrum projects.

1. The first rule of improvisation is AGREE. Always agree and SAY YES.

This rule for me is about openness and the willingness to engage with new ideas and new practices. As Fey explains it:

When you’re improvising, this means you are required to agree with whatever your partner has created. So if we’re improvising and I say, “Freeze, I have a gun,” and you say, “That’s not a gun. It’s your finger. You’re pointing your finger at me,” our improvised scene has ground to a halt.

The blue screen of death moment is any meeting is when you hear someone say ‘We can’t do that’, or ‘We tried that before and it didn’t work’ or ‘The IT team won’t let us do that’. That moment sucks away at your enthusiasm for the project and if it happens enough, drains your will to work.

A recent Scrum project I worked on had a brand new team working to create a prototype for a mobile app in six two-week sprints. At the beginning of the project, the team’s most common reaction to the Product Owner’s stories was ‘We can’t do that, because…’. This resistance was a real downer for the Product Owner. By the last sprint, the team was saying ‘We can do that by ….’,  explaining what the potential issues were, and suggesting how to overcome them. The Product Owner told me this was one of the most satisfying aspects of the whole project for them.

2. The second rule of improvisation is not only to say yes, but YES, AND.

If your reply to “Freeze, I have a gun” is “Yes, you have a gun”, that doesn’t do much to advance the scene. YES, AND for Fey means not being afraid to contribute – in fact, seeing contributing as your responsibility.

When I heard this, I thought about things from the Scrum Master’s point of view. At the start of a project, when you’re the Scrum Master, you sometimes find yourself trying to coax quieter team members into joining discussions. You don’t want to have to do this for much more than a sprint or two. A team that needs the Scrum Master to help them talk about stories or solutions isn’t self-organising. The Scrum Master can however help create an environment where no-one feels afraid to contribute, and coach people to see contribution as part of their role on the team.

3. The next rule is MAKE STATEMENTS.

Fey writes:

This is a positive way of saying “Don’t ask questions all the time.” If we’re in a scene and I say, “Who are you? Where are we? What are we doing here? What’s in that box?” I’m putting pressure on you to come up with all the answers.

In other words: Whatever the problem, be part of the solution. Don’t just sit around raising questions and pointing out obstacles. We’ve all worked with that person. That person is a drag.

I took two things out of this. One was that MAKE STATEMENTS would be a handy poster to put up next to a Scrum board if your team has a tendency to turn a 15 minute stand-up into a 45 minute philosophical discussion.

The other thing was a reminder of how much I love the way Scrum lowers the threat level of decisions. When you’re responsible for a project, making decisions can be scary. Signing off the final design in a waterfall project, for example, means acknowledging that any changes you want to make further down the line will almost certainly be difficult and expensive. If making decisions is stressful, one natural reaction is to delay or obfuscate. However, when you’re a Product Owner on a Scrum project, you’re making decisions all the time. You get used to making the best decision for the moment, and understanding that if you need something to change in the future, you’ll just write another story. This lowers the threat level of decisions considerably, and helps your team a lot: making decisions is a lot like making statements.

4. THERE ARE NO MISTAKES, only opportunities.

If I start a scene as what I think is very clearly a cop riding a bicycle, but you think I am a hamster in a hamster wheel, guess what? Now I’m a hamster in a hamster wheel. I’m not going to stop everything to explain that it was really supposed to be a bike.

The lesson here for Fey is that some of the world’s greatest discoveries have been happy accidents (think Viagra). There’s a useful lesson here about being open to suggestions and discussions, rather than clinging to your original set of assumption and opinions. This is why user stories are written in terms of what and why, rather than how.

In conclusion

Firstly, Bossypants is a great read (or, if you like audio books, a great listen).

Secondly. Improv is the act of working together to build something new from a bunch of quickly generated ideas, pruning off things that don’t work and building on the things that do along the way. The more an improv team works together, the more they trust each other, and the better they know each others’ strengths and how to use them. A lot like Scrum projects, over all.

*I was recounting this to a friend over the weekend, who flummoxed me by asking who Tina Fey is. So just in case – ladies and gentlemen, Tina Fey.

Related Posts:

• Business Analysts and Scrum projects: A short case study
• Use cases vs user stories in Agile development
• Jean Tabaka on the Golden Circle of Agile & StackExchange for project management
• Agile experiments: creating user stories with story mapping and ‘buy a feature’ prioritisation
• User stories in action – the Agile development process

I recently joined Boost after spending over a decade in the UK.  Having worked within a traditional project management process over the last 5 years, I was very keen to learn about the benefits of Agile project management, specifically the benefits of Scrum and the comparison with my previous experience of web development projects.

What I found after a week of observation was that unlike my previous experience of web development projects, an ‘us and them’ (supplier v client) situation causing conflict and resentment is less likely to arise under Scrum.  This is due to the scrum itself -  both supplier and client are team members with clearly defined roles and responsibilities.

I was asked to observe a number of Scrum meetings in my first week; a stand-up, story sizing meeting and a retrospective.

The stand up 

The stand up occurs daily and is a chance for the team to confirm what they are working on and to communicate progress from the previous day. I was immediately struck by the fact that each team member contributed to the stand up in the same way – developers are not asked what they are working on, they tell the team what they are working on and have the opportunity to identify any blockers to their progress.  Although brief and straightforward this meeting immediately appears to be beneficial for a number of reasons.

• the entire team knows exactly where in the sprint each person is
• issues or blockers are raised early
• progress is seen as it happens, stories are closed out each day throughout the sprint

Story sizing

Story sizing consists of all team members sitting around a table with a hand of sizing cards (numbered 1, 2, 3, 5, 8).  A member of the team reads out a story, team members are then asked to ‘play’ a sizing card.  The card indicates a measurement of effort that is not classified in time but by a proportional comparison.  For example if the first story is sized as a 3 (or medium) then a story that is larger and will consist of more tasks may be sized as a 5 or 8.  If a team member’s sizing differs dramatically from other team members the team member will then explain why they consider the story to be larger or smaller and after a discussion a consensus is reached.  Sizing of stories informs the decision as to how many stories will be undertaken during the upcoming sprint.

The advantage of the entire team sitting down to size work as opposed to a more traditional method of having the developer who will undertake the work provide a time estimate is that each and every team member has a chance to input to the sizing of the story therefore the team takes responsibility for the timing of the story, as opposed to an individual.  It is a transparent process that ensures the commitment of all team members to the delivery of each story.

The retrospective    

The retrospective is a feedback meeting in which each team member is asked to focus on particular aspects of the previous sprint and to record both positive and negative feedback on these.  The aims of a retrospective are for the team to communicate, review and improve on previous sprints.  Retrospectives may be run in any number of ways in order to get the best out of the team.

During my observation of a retrospective I was immediately struck by the difference between this meeting and that of a traditional lessons learned meeting (held at the end of a traditionally managed project).  The retrospective encouraged all team members to communicate openly.  Contributions from team members are presented as statements, and are constructive rather than obstructive or defensive.  The advantage of holding retrospectives regularly (at the end of each sprint) is that points are raised early and the project goes into a cycle of continuous improvement – as opposed to a traditional lessons learned meeting where any constructive conclusions are beneficial only to the next project the team works on.

My conclusions from my first week of observing Scrum in practice are very positive;

• Developers are encouraged to fully participate in all meetings demonstrating work completed and inputting to decision points as required.  As a direct result of their commitment to the project developers take a great degree of responsibility for project outcomes, they are very obviously accountable for tasks, while also having the benefit of the entire team’s support.  All too often in non scrum projects the developer is asked to take responsibility for tasks in isolation and are therefore reluctant to commit to timescales and successful outcomes.

• Clients are fully immersed and committed to the process and as such are very much a part of the team.  Unlike projects I have worked on previously  there is less expectation that the supplier will drive the project in isolation, instead the client is fully involved in all aspects of the project and always aware of exactly what work is taking place and when it will be delivered.

• Processes are consistently reviewed for effectiveness and all team members input to the review process.  There are opportunities for both positive and constructive feedback and actions are undertaken as a result.  In comparison with the traditional ‘lessons learned’ aspect of a project this seems far more beneficial in terms of continuous improvement rather than undertaking process improvement at project conclusion.

• Project tasks are broken down into explicit finite tasks and the acceptance criteria are clearly defined and agreed at the outset rather than development task estimates taking place at the outset of a project in isolation from other team members.

My overall impression in this early stage of exposure to Agile project management and Scrum is that Scrum builds a happier, closer team and minimises risk by ensuring frequent and open communication between all team members.

Related Posts:

• No Related Posts

I’ve been coaching members of the Boost team in Agile off and on over the last few years, and by and large it has been useful and well received. But attending The Coaching Stance class run by the Agile Coaching Institute last week has really opened my eyes and made me reconsider what coaching means in the Agile context.

My own personal experience of coaching is firmly grounded in the sports world. The coach evaluates an area of performance, makes a teaching point or two, sets up a drill, evaluates whether the drill is correcting the weakness or fault, and then sets homework for the coming week.

So when I am with my golf coach it usually goes something like this:

• I hit a few balls, some (not many) land on the fairway
• Coach is videoing my swing
• We review the swing together, and coach identifies an area for us to work on for that session
• We do a drill or two, and see if that is impacting on my swing
• I hit more balls then go home.

This is fairly typical and extremely useful. My golf has gone from “baboon attacks ball with stick” to “chimp attacks ball with more expensive stick” in only a year and 5 trips to the pro shop!

My approach to Agile coaching had, in many ways, mirrored this. I would talk with my client, identify an opportunity for improvement, and suggest something for them to try. Rinse and repeat. This has been effective on many occasions, but I’ve always wondered how I could do better.

The Agile Coaching Institute promotes co-active coaching, and this is what we were exposed to in our two day class. The class focussed on coaching, with the understanding that participants already had a deep understanding of Agile/Lean practices.

The class was the most effective training I have ever had. After two days I’d coached and been coached by over a dozen different people, and had moved my  practice to a whole new level. I am excited by the possibilities it opens for myself, the Boost team and our clients. I’m not waiting until I get back to Wellington to put the training into practice:  I’ve already been doing some coaching with the team back at work over the phone.

While it’s not easy or fair to try to distill the whole course into a paragraph or two, I’d like to reflect on the changes I’m already seeing in my practice. The biggest change is that I’m seeing coaching in a new light. I’m not there to problem-solve: my coaching client is whole, resourceful and creative, not someone who needs to be ‘fixed’ or ‘improved’. Instead, my role is to support the person I’m coaching to find their own solutions. This takes the pressure off me. I don’t need to know all the answers or figure out how to fix things: I can relax, and focus on what I’m hearing.

Cynthia, Lyssa and Michael provided a safe, supportive and honest space for us to learn and challenged us in many different ways. I was suprised by how quickly the class bonded. The coaching was at times intense ,and often suprisingly carthartic.

Thanks to everyone on the course. With so many talented Agile coaches,  I know the Agile world is in good hands.

Related Posts:

• No Related Posts

As an intern here at Boost I have had the privilege of working with a group of experienced and friendly developers. I have been here two weeks now and already feel settled in completely. One of the great things about working for Boost is that everybody is very approachable when you need to ask for help or when you need things to be elaborated. This has made the transition from university to industry easier than I initially expected.

Here at Boost we use the Agile software development methodology known as Scrum. So every day I have a stand up meeting with my scrum master (Jacob Creech) and product owner (Nathan Donaldson) where I go over what I have done, what I will be working on today, and discuss problems that I need to get out of my way. So far at Boost I have been working on bug fixes for our online usability testing tool IntuitionHQ, which is built in Ruby on Rails. Working in this way has helped me get my head around the large code base that I will gradually move towards developing features for.

Using Scrum means that I’m working in ‘sprints’, or two-week long development periods. Each bug in IntuitionHQ is written up as a user story. At the start of my first sprint I took part in a sprint planning meeting which included sizing the stories (assigning them points between 1 and 8 to indicate their complexity/the effort required to fix them) and then breaking the stories down into tasks. I had to indicate how many of the stories I could commit to in the two-week sprint, and how confident I was that I could complete them in that time frame.

As an intern I was not really sure how much I could complete, being new to Rails and working in the industry in general. But one of the cool things about Scrum is that at the end of each sprint you have a sprint retrospective. This is a chance to talk about how the sprint went, and what can be done to improve things. If I don’t complete all my stories in the first sprint, the next sprint will be adapted to deal with this, and so on and so forth. So in the case that I didn’t complete all my stories it will be known for the next sprint to take on less stories in relation to their size. Overall, this is about figuring out your ‘velocity’ – how many story points you can get done in a sprint.

For my first sprint I initially committed to seven stories. I ended up completing the stories early and brought in two more stories from the backlog. One of the fun things I have found about fixing bugs is it really stimulates the mind’s problem solving abilities. I developed most of my problem solving abilities while doing my Software Engineering degree at Victoria University. Although university is a great learning environment I have found that learning in a working environment has more merits. This is because you are working with a group of people towards a common goal so they are more likely to help you out and I find that social learning is the best way to learn. This differs from university as everybody in your papers are competing to get higher grades than you so they generally don’t feed you all the facts.

One of the cool things about coming out of university into a working environment is that once you get home from work it’s your time, not stressing-about-assignments time. I believe that the less stress you have weighing on your mind the more productive you can be. Not being stressed out has helped me to be more productive working here at Boost and has got me highly motivated and keen for my next sprint. To sum up my experiences so far I would say that working here has been awesome!

Related Posts:

• Free Friday Agile workshops at Boost
• Agile experiments: creating user stories with story mapping and ‘buy a feature’ prioritisation
• User stories and stakeholders – bringing people on board with Agile
• Pair programming: When and why
• Jean Tabaka on the Golden Circle of Agile & StackExchange for project management

Here at Boost we’ve been pair programming for a while, and seeing benefits in the form of cohesion and knowledge sharing, as well as the quality of code we produce when working in pairs. As part of the adoption of this practice I set out to research how pair programming has been working for other teams and how it can be used to improve the team dynamics.

For those that are new to the concept of pair programming: at its core, it’s when two developers sit in front of the same computer and develop code together.  One programmer acts as a driver and the other as the navigator. The driver controls the keyboard and mouse and is concerned with the concrete tasks of coding, while the navigator reviews the code and thinks about bigger picture issues.

It’s not for every team

As Obie Fernandez explains in his article “10 reasons pair programming is not for the masses”, in order for pairing to work the team has to consist of developers who are committed to their work, and who are sociable and able to interact with other team members. Otherwise problems will quickly arise when you are working in such close proximity with other team members.

Why it’s great

Few or no bugs: The first thing you will notice when pair programming is how few bugs are left in code produced by the pair. Pair programming is like a constant code review process, which is why typos or small details that a single programmer normally wouldn’t notice gets spotted almost instantly by the navigator, eliminating hours of debugging later on.

Code quality: The general quality of the code is also greatly increased. This is because while the driver is implementing the logic, the navigator is free both to spot errors and to think about the big picture and how it relates to the rest of the code.

Programmer productivity: When working alone it is very easy to get distracted by email, twitter, Facebook, and all the things going on within the office. When working in pairs, if you were to do any of those things it would waste the other person’s time, so pair programming is a constant reminder to focus on the work.

Knowledge transfer: In an environment where developers work alone, it can be hard to share knowledge because there often isn’t a time or place to do it. Pair programming involves constant discussion and flow of ideas on how to resolve a problem, and normally a pair can come up with many different solutions to a single problem. It’s also great in situations where you want to introduce a new team member, to get them up to speed very quickly with the development practices, coding style, git workflow and other practices the developers might use.

How to do it

When: Although some of the development companies promoting pair programming suggest using it 100% of the time, in my own experience the intense focus and concentration that happens with pair programming can be draining over a full day. I suggest you pick the tasks that will benefit from having a pair work on them, rather than applying pair programming to every task.

Workstation setup: We have been using just one display, keyboard and mouse with great success but I would definitely like to experiment with two keyboards and see how the interaction between developers works out.

Rotating pairs: One important aspect is to let developers constantly change pairs, on a daily or weekly basis. This has several benefits: it helps develop a bond between the team members; the team as a whole takes ownership of the code instead of individuals; and knowledge sharing is increased by working with developers with different levels of experience and backgrounds.

Resources

• Obie Fernandez – 10 Reasons Pair Programming Is Not For the Masses
• WikiHow – How to Pair Program
• Computer.org – How Pair Programming  Really Work
• Ian Burgess – Pair Programming- Software Development Learning Steps

Related Posts:

• My First Sprint (with Scrum)
• Free Friday Agile workshops at Boost
• Agile experiments: creating user stories with story mapping and ‘buy a feature’ prioritisation
• 10 Great Scrum and Agile Practitioners on Twitter
• User stories and stakeholders – bringing people on board with Agile

Here at Boost we’ve been reviewing the updated Scrum Guide by Jeff Sutherland and Ken Schwaber, released in July (you can download the guide at Scrum.org)

Rather than covering techniques (like release planning, burndowns and sprint tasks) the guide focuses on what makes Scrum Scrum: the roles, events and artifacts, and the set of rules that bind these together.

In an introduction to the changes from the 2010 Scrum Guide, Schwaber and Sutherland compare the Scrum Guide to guides for games: rules (pass go, collect $200) are different from strategy (get to three houses as quickly as possible, because this is when the rent bumps up dramatically). They write:

The Scrum Guide is the definitive rule book of Scrum and the documentation of Scrum itself. The Scrum Guide and the rules of chess offer simply the rules on how the pieces move, how turns are taken, what is a win, and so on.

Strategies for playing Scrum or chess vary widely and are explained in many books, articles, and blog posts on the respective subjects. For those of us working on a revision to the Scrum Guide, this meant that all tips, optional practices, and techniques should be removed from this document. This was done along with refining some language to correct some long-standing misunderstandings about Scrum.

Given the Introduction to Scrum workshops we’re running at the moment, we were keen to look at the Guide in terms of how it can help us teach people about Scrum. Here are some of the passages that really grabbed us:

The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.

We often explain that a key part of the Scrum Master’s role is to clear impediments that are stopping the team from working as well as they could. Here, we like the notion that the Scrum Master isn’t just clearing blocks, they’re teaching people to proactively stop the blocks from happening.

… each event in Scrum is an opportunity to inspect and adapt something. These events are specifically designed to enable critical transparency and inspection. Failure to include any of these events results in reduced transparency and is a lost opportunity to inspect and adapt.

We’re frequently asked whether all the events in Scrum (stand-ups, planning meetings, task estimation, demonstrations, retrospectives) are really necessary. We usually say that of course you should use the structure and methods that suit you best – but that if you’re not following the Scrum events, you’re not using Scrum.

We also try to explain how you can go through the motions of Scrum events without getting the benefits. Thinking of every event as an opportunity to inspect and adapt, and to create transparency, reminds you of why these events are held and the spirit in which people need to participate.

A Product Backlog is never complete. The earliest development of it only lays out the initially known and best-understood requirements. The Product Backlog evolves as the product and the environment in which it will be used evolves. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful. As long as a product exists, a Product Backlog also exists.

The Scrum Guide’s section on the product backlog  really emphasises that the product backlog isn’t there just to get you to an initial release – it is a long term commitment. In fact, the Guide states that the product backlog will become ‘larger and more exhaustive’ after launch. Interestingly, the Guide also dwells on the role of team members in contributing to product backlog grooming, not just the product owner and stakeholders/subject experts.

Overall, the 2011 Scrum Guide is concise (a slim 16 pages), focused and a useful resource for newbies and experienced Scrum practitioners alike. Enjoy!

More reviews of the differences between the 2011 Scrum Guide and earlier versions:

• Blog post by Charles Bradley
• Review on the Derailleur Consulting blog

Related Posts:

• Agile experiments: creating user stories with story mapping and ‘buy a feature’ prioritisation
• Use cases vs user stories in Agile development
• Improving user stories with a Definition of Ready
• Scrum in 10 Minutes
• User stories in action – the Agile development process

In Scrum, the definition of done tells us when a feature is completed to a releasable standard. It sits above the individual acceptance criteria for each user story. For example, here’s the definition of done for development stories from one of our projects:

• committed to source code repository
• passes appropriate tests for story (including cross-browser testing)
• tests written and run on integration server
• accepted by product owner on UAT (unless story asks otherwise)
• documented (well-commented)
• cross- browser testing of interface elements
• readme updated if applicable
• change log updated

Adding the definition of ready to the definition of done

Recently, we’ve been looking at the definition of ready – the criteria a user story has to reach before it can be handed over to the team. You can think of the definition of ready and the definition of done as two key points in the sprint cycle – one defines when a story is ready to go in, and the other defines when a story is ready to come out.

Jeff Sutherland and Carsten Ruseng Jakobsen have described a definition of ready as a simple concept that depends on discipline and creates stability in a sprint. It’s designed to stop time being wasted when it’s discovered that user stories are missing important pieces of information that means they can’t be started or completed.

A definition of ready gives the team confidence that every story they bring into a sprint is completely ready for them to get started on. In this way, as Sutherland and Jakobsen observe, a definition of ready can improve the flow and stability in a sprint.

A sample definition of ready

Here’s a definition of ready we’ve  developed for one of our projects:

1. The business value is clearly articulated (in the format of ‘As a type of user I want some goal so that some reason‘)
2. The story follows the INVEST model
3. The story has a 2 – 3 word short summary
4. The story is small enough to fit in one sprint
5. The story has clear and concise acceptance criteria which describe all of the features of the story. Details are captured as a narrative texts that describe an interaction of the user and the system, focusing on the value a user gains from the system.
6. Once the acceptance criteria have been met the story is complete
7. No external dependencies block the story being completed
8. Story identifies external expertise and provides contact details.

Many of the points (for example, 2,4 and 5) reinforce the usual expectations of a good user story. Some are designed to trouble-shoot in advance: for example, 7 and 8 are there to help the team work as efficiently as possible, by ensuring they’re not being held up by business processes outside of the team, and have ready access to any expert help they need. And some are small tweaks that add efficiency in the longer term – for example, point 3 ensures we have a short headings for the user stories that make them easy to scan in Pivotal Tracker.

In conclusion

Of course, having a definition of ready doesn’t mean there won’t be occasions during sprint planning meetings when gaps are found in the preparation or understanding of a user story. It also doesn’t mean the team no longer has to talk the stories through with the product owner during these meetings, and throughout the sprint. But it does mean you’re creating the best possible conditions for optimal productivity in the sprint.

More reading:

• Going from Good to Great with Scrum presentation by Jeff Sutherland and Carsten Ruseng Jakobsen
• Definition of ready by Ken Power
• The definition of ready by Roman Pichler

Related Posts:

• Agile experiments: creating user stories with story mapping and ‘buy a feature’ prioritisation
• Business Analysts and Scrum projects: A short case study
• Use cases vs user stories in Agile development
• Tina Fey’s Four Rules of Improv, as applied to Scrum
• The 2011 Scrum Guide – a quick review