Recommended Agile Reading

From time to time, I will review and/or list books that I find helpful.  I don't have time to go into a full review while I'm on my lunch break, but right now I'm re-reading 
The Agile Samurai: How Agile Masters Deliver Great Software (Pragmatic Programmers), by Jonathan Rasmusson.  It's a great back-to-basics book for those of us who have been doing the agile thing for a while.  For those of us who are newer to the agile universe, it is a must have for your Agile Library.  It also has some great tips and tricks for all role types.  I highly recommend it.  You can get the Kindle Edition for less than $20 on Amazon right now.  

How to Give a GREAT Demo!

One of the major tenets of Agile is the Product Demo.  As we all know, agile encourages us to demo at the end of our sprints.  This is done for several reasons.  Not only does this keep us accountable to our customers, but it helps us to focus on forward thinking.  At many companies, it is highly likely that actual external customers will attend these demos, so it is of the utmost importance that we always put forth our very best. 

In our pursuit of excellence, here are a few things to keep in mind when prepping for a demo. I compiled this list with a few of my collegues, so I can't take all the credit.  Here goes.  

What to include in every demo deck

Frame the demo with PowerPoint and then broadcast it via a webinar.  Just about everyone has access to a phone and the internet, so use them.  You can bring in your external customers this way, while still catering to your internal customers.  That being said, always be cognizant of WHEN you have customers attending your demos.  Make sure you inform everyone just who is on the phone so that you’re on your best behavior. 

That’s great, you say.  But what should I include? 

Project Goal 

This is basically the goal of the project, our elevator pitch, our reason for being.  This needs to be repeated at every demo because our audience fluctuates. 

Customer Value

This is the reason the world needs our project.  Again, the overall customer value of the project needs to be repeated every demo.  However, sprint specific value can be spelled out in the goals we set for ourselves.  We should be able to answer questions like “What have we given to customers thus far”, “What are we delivering next”, and “What are our plans for future customer value?”  Additionally, customer value should be integral to every part of our demo.  When we show something live, we need introduce it in such a way that spells out WHY it is valuable to our internal and/or external customers.    

Sprint Goals

I think this is optional for demos that include external customers.  You don’t want to get TOO in the weeds because you want to keep your external customers engaged. 

These goals ultimately align with the overall project goal, but think of them as bite-sized pieces that we can deliver iteratively.  Sprint goals usually change every two weeks and are specific to the work to which we’ve committed.  These goals should manifest with customer value in mind.  Remember: customers are both internal and external. 

Project Status

This lets everyone attending the demo know the health of our project.  It should answer questions describing how we’re tracking to our road map deadline, how much work is left, and whether or not we are meeting our commitments.   We also need to comment on major milestones or epics: are they done, and if not, are they accounted for?  Finally, do our customers KNOW what we’re giving them?  Have we communicated TO THEM the way we’re going to change their world for the better? 

Live Demo 

Show everyone how awesome we are!  Get to it with live demos of transitions, versioning, provisioning, wireframes, slick UI, YOU NAME IT.  DO NOT merely insert slides stating what we did.  SHOW IT OFF!  If we have very little or nothing live to demo, then we need to show reports, matrices, RACIs, Visio diagrams, etc.  This is all in addition to anything live we can show.   Also, we shouldn’t demo any stories that are incomplete.  That’s just plain silliness.    

What to Expect Next

“What To Expect Next” is usually the Product Owner’s vision of things to come, tempered by the realism of the team as a whole.  While we haven’t had planning for the next sprint yet, we need to let our audience know what’s on the horizon for our project.  This gives them the opportunity to plan whether or not they need to attend or whether or not they can move forward with their own agenda (project dependencies, sales pipelines, roadmap planning, etc).   This also keeps us always looking forward.  Keep in mind that “what to expect next” can change based on feedback and market trends, and this is the very reason why we demo!  We need that feedback to make sure our customers are getting the value they’re asking for.

Things you need to do as a teammate

BE THERE

This means physically as well as mentally, even if you haven’t contributed much during the sprint.  Try to avoid being out of the office on demo days.  Being together lends credence to what we’re doing, and it also serves to bolster team morale. 

Participate

While not everyone can participate at every demo, make it a point to participate as much as possible. 

Make sure the demo is recorded

This is more for moderators/facilitators, but if you can, help remind them to push the “record” button.  Recorded demos help keep our executives and sales folks in the loop when they can’t make it to demos.  

Tips and Tricks

Announce wins

If we’ve done something great, then we need to shout it from the rooftops!  Find creative and exciting ways to weave these wins into the demo deck. 

Demo Prep

This is a dress rehearsal, so to speak.  In prep we can iron out technology wrinkles, get a feel for presentation flow, and actually calm our nerves.  I like to do demo prep an hour or so before the demo.    

If we promise something in a previous demo, we need to deliver it in a subsequent demo.  If we don’t, then we need to explain why.

This is self-explanatory.

Have fun with images! 

Image searches on Google bring up loads of crazy things.  Create interest!  Incorporate some of these into our demos!  Of course, all things should be done in moderation and good taste.  Remember: external customers can and will see these demos!

So that’s it in a nutshell.  Be prepared and have fun!  What are some ways you give great demos?  Chime in!  

User Stories: Make ‘em SMALLER, please!

User stories are the building blocks of whatever project we’re working on, are they not?  They give structure.  They give solidarity.  They stand things up.  Epics are the larger, overall stories that lay the foundation.  When building something, it is prudent to have the larger stories on the bottom and the smaller stories on the top.  I could get into the engineering aspects of building design, but I’m not smart enough to discuss such things.  I’ll stick to what I know.  Here’s what I’m getting at: make the user stories smaller than the epics.  This seems like a no-brainer, but too-big user stories are way too common.

One of the largest hurdles I face in early sprint planning sessions is user story size.  Yes, we’ve sized them previously in Release Planning, but once in a while we hit stories that are just BIG.  At first, new teams think they can tackle these monstrosities in one sprint, but then they quickly learn that just isn’t possible.  They over-commit and velocity takes a hit.  Have you been there?  I have.   

As the team grows together and matures, they realize what they can and can’t do.  They eventually get better at estimating.  In the meantime, how do we – the scrum masters – mitigate this? How do we get our teams from the Dark Side of too-big user stories to the Jedi Side of small, manageable stories? 

We guide them in breaking down these user stories into smaller stories, AND we give them the tools to do this. 

There are many resources at your fingertips.  I’ve perused these myself and have found that the INVEST model works best.  I got this from the guys over at Agile for All, but they got it from Bill Wake.  Check out his original article here.  In a nutshell, your stories should be the following:

·        Independent

o   Self-contained.  Not dependent on another user story.

·        Negotiable

o   Right up to committing to a user story in a sprint, you can rewrite it or change requirements.

·        Valuable

o   Self-explanatory.  The end-user needs to get something from it. 

·        Estimable

o   This means that “infinity” doesn’t work.  If the story is to be sized, it needs to be reasonable.

·        Small

o   You have to be able to complete it in one sprint.  This includes Dev AND QA work. 

·        Testable

o   QA folks need to know what the heck is expected as an outcome of this story.  It’s called user acceptance criteria. 

If your user stories fall short on one of these, then you need to rethink it.  Should it have more details?  Can tasks be divided out to create another user story that’s smaller?  Still stuck?  Check out Richard Lawrence’s workflow on how to split a user story.  I learned from him early in my agile career.  He knows what he’s talking about. 

Hopefully, once you’re done you can get the user stories into your sprint and be on your merry way.  Ideally, the product owner would have taken care of this breakdown and user story grooming outside sprint planning.  That’s not always the norm, and we scrum masters have to adapt!

What are some methods you incorporate into your planning to cut stories into bite-sized pieces?  Please chime in.  I’d love to learn from you!     

Welcome!

Hello and welcome to my first blog post on Scrum Bubbles!  I know there are LOADS of scrum resources out there, so thanks for stopping by.

Let me start by telling you why I decided to join the hoards of scrum blogs.  I love being a scrum master.  Pure and simple.  I love to keep teams moving forward and all the interaction that entails.  I'm hoping that my love of people will bubble into my posts and help you see how to ALWAYS look at the human element in what we do as scrum masters.

What will I share, you ask?  I'm going to share my ups and downs with you.  I'll share best practices (and not so best ones) and detail training I'm getting.  I'll look at trends in the community.  I hope we can share laughter and thoughts.  I hope to not only give you ideas but to encourage you to give your ideas as well.  I want us to share in a common pool of knowledge and help one another.  So... what do you say?  Are you in?