At Agile2011 Kevlin Henney provactively suggested that we don’t learn from mistakes (see: Why we don’t learn from our mistakes, The Optimism Bias), suggesting that we learn more from our successes. This seems to against the core agile principle that we learn from our mistakes (i.e. my motto “Fail Fast” etc). It also seemed to contradict the message in Linda Rising’s keynote that followed Kevlin. This makes me very happy to have seen a pair of articles in the past few days that bridge the gap: How Your Brain Reacts to Mistakes Depends On Your Mindset (a short summary from Science Daily) and Why Do Some People Learn Faster? (a longer item from Jonah Lehrer that ties several ideas together). The upshot both Kevlin and Linda were right. We do learn from our mistakes but not everyone has the mindset to do it.

Read More…

When we left John and the team they were just getting the shipping features ready and were waiting to go live with the site. This turns out to be a blessing and a curse. Its a blessing because the business is making money, a curse because with it come support issues.

John spends some of his time and energy just watching the team and their flow everyday. In the first two sprints after the release the team struggles and fails to meet its planning commitments. At first he’s ok and just says its the inevitable post release hiccups (I don’t agree with John on this one, its not inevitable I think it was a first warning sign – ed), but when its clear that its continuing into the 3rd sprint he starts to get worried. John notices that team members are being interrupted often several times a day. Most of the interruptions are support issues.

Read More…

Caveat – given the way I’m writing this series occasionally things will happen out of order, i.e. I will be reminded of points I wish I had made earlier.

John, Sue and the rest of the team have started another sprint this time they committed to fewer stories and part way through the sprint are well on the way to getting stories completed. This time they committed to 8 stories with sizes ranging from 2 – 8 points. Every couple of days they get a story accepted. Things are going awesomely well.

Story

• As a Canadian book buyer I want to Amazon to ship my book to Canada so I can get my book home – Story Points: 8
• As a Canadian book buyer I want to Amazon to calculate the import duty on my books – Story Points: 3
• As a Canadian book buyer living in Ontario I want Amazon to calculate the local sales tax (HST) – Story Points: 2
• …

Read More…

Last time we met John (ScrumMaster) and the team, they had just discovered that their backlog had many large stories and no-estimates. The team delayed the start of their first sprint, did some Product Backlog Grooming. When we meet them again their first sprint in is in progress.

Story

Coming out of the planning meeting the team committed to five stories totalling 42 Story Points. Their overall Sprint Goal get the customer’s book home:

• As a book buyer I want to add my book to my shopping cart so that I can purchase it – Story Points: 13
• As a book buyer I want to tell Amazon where I want my book shipped to so I can get it – Story Points: 8
• As a book buyer I want to see the price for my books with shipping and tax so I can see whether I’m ok with the price – Story Points: 3
• As a book buyer I want to choose my payment type (MasterCard, Visa, Amex or Paypal) so that I can pay for my book(s) – Story Points: 3
• As a book buyer I want to pay for my book(s) so I can get it home – Story Points: 13
• As a book buyer I want a confirmation message so I can see that the purchase was successful – Story Points: 2

Read More…

You’ve just finished your Scrum Master training and to start exploring some issues we didn’t have time to cover? I spent the afternoon putting together a list of 29 books that I think you will find interesting. As part of the process I decided to experiment with doing the list as a mind map.

Let me know if this was helpful or if there was a key book I missed. In addition give some ideas of how you might have presented this.

New to Agile Coaching? Trying to get your head wrapped around how to help people without any official authority? Have a tough coaching problem you’re not sure how to handle? Not a coach – but you need some Agile Advice – come ask a question.

We may not be able to solve all your problems but we can help start down the right path. Come to Agile 2011 Coaches Corner (located in the Open Jam). Unlike the Canadian hockey version it won’t be loud brash former coaches telling it like it is, it will be a clinic where you can catch sometime with an experienced coach.

Read More…

I’ve been struck how little is written about being a great Scrum Master. There is heaps written about Scaling Agile and a lot of great Technical books, but very little on playing individual roles well. The ScrumMaster Tales are intend to fill this gap.

Cast of Characters

ScrumMaster John – he’s been in the software industry for over 10 yrs. He’s been a developer and sometime development manager. Recently he’s been “promoted” to ScrumMaster and was sent on Certified Scrum Master Training but has no practical Scrum experience.

Product Owner Sue – she’s also new to Agile. Unfortunately she hasn’t had training yet, although she has read a few books. She’s open minded, but a little confused about what needs to be done. Sue has 15 yrs experience doing Product management.

The Application – I tend to use Amazon in many of my examples because most people know it well. Cast your mind back to 1995 when Amazon was first launched. Our team is building the original Amazon.

I will introduce other characters as the tales evolve, onto out first story. Read More…

I’ve heard several references recently to the Scrum Canon. I went searching and I’ve not been able to find it. Is it one Ken (et al.) three books? Ken and Jeff’s most recent Scrum Guide? Does it include the ideas that Mike documented in Agile Planning and Estimation? … Is what the majority of CST’s are teaching at this moment in time? In end I don’t think there is a Canon and its absence doesn’t matter. We can all agree on the basics: three roles (PO, Scrum Master and Team Member), Four meetings (Planning, Daily Standup, Demo, Retrospective) and three artefacts (Product Backlog, Sprint Backlog, Burndown Chart).  Beyond that is the art of what makes a team truly successful Scrum Practice (in no particular order):

• User Stories
• Planning Poker
• Release Planning
• Engineering Practices
• Cross Training
• ….even approaches to Scaling

I teach about all of these in my CSM courses, but none of these is core to Scrum. None is required. Why not? Scrum is incomplete it gives you enough information to get started and says you should improve from there. Its not a straight jacket and it welcomes other ideas/practices. I get concerned when people seek a complete methodology as they discourage diversity, outside thought and even thinking for yourself. So practice Scrum but don’t assume it or any other toolbox has all the answers. Sample from the buffet.

This quick links is a bit of a potpourri:

Building an Agile Environment – Rachel Davies describes her experiences helping people to model work environments, using craft materials, playmobil characters etc. This helps surface the annoyances, impediments, attractors. Sounds like a great workshop. Next time you ask me if proposed work area is Agile I will try this.

But We Need a Database … Don’t We? – Ron Jeffries tackles one way to design a database in a test driven fashion, without actually having the database. Remember its not the only way its another tool.

Pair Design: Better together; the practice of successful creative collaboration – Stefan Klocek describes Cooper design’s approach to pairing in design. Some valuable ideas even for pure coders.

Estimation Non-Functional Requirements – Mike Cohn offers another approach for estimating the costs/tax of non-functional requirements.

Improving Names in Code – JB has a cute drawing to help us see how to evolve better names in code.

12 Tips to be a better coach – Martin Proulx gives us some things to remember when acting as a coach. My favourites:

• Inner Silence – “To be truly effective at listening to what others are saying … it is critical to block the voice inside your head”
• Keep silent: “After asking a question, never speak first.”

Code Cleaning: A Refactoring Example In 50 Easy Steps – Wouter Lagerweij provides a step by step example of a refactoring he did.  He’s since re-examined using tests to drive the refactoring: Code Cleaning: How tests drive code improvements (part 1).

In From Months to Minutes (1hr presentation on InfoQ) – Dan North examines what can be done with Agile if your turn the dials to 12 (its better than 11 :-). Its a very interesting and provocative take on where you can take Agile. My only concern is that some will listen to this presentation and start throwing away practices because Dan didn’t need them anymore. Remember context is important, Dan’s approach may not work for you.

For sometime I’ve been publishing Agile Quick Links. Links to articles that Agile folk will be interested in. Now I’m starting NeuroAgile Quick Links, these will references to articles or summaries of papers that I think are of interest to members of the Agile community.

The Conversation is Over. Long Live the Conversation – reacting to an article about the use of twitter like tools in high school, David Rock examines the affects our interactions through facebook, twitter etc. are reducing our empathy and damaging the art of conversation. David talks about the silence in cubicle mazes as people ignore each other and fail to collaborate. Talk your teammates don’t IM or Skype them, real collaboration happens through face-to-face conversation and not over a computer

When We’re Cowed by the Crowd and The Web and the Wisdom of Crowds – we’re all familiar with the Wisdom of Crowds (James Surowiecki) and the idea how a diverse group of people can make some very accurate estimates/guess. In these articles, Jonah Lehrer describes:

The scientists then gave their subjects access to the guesses of the other members of the group. As a result, they were able to adjust their subsequent estimates based on the feedback of the crowd. The results were depressing. All of a sudden, the range of guesses dramatically narrowed; people were mindlessly imitating each other. Instead of cancelling out their errors, they ended up magnifying their biases, which is why each round led to worse guesses. Although these subjects were far more confident that they were right—it’s reassuring to know what other people think—this confidence was misplaced.

I wonder what affect this has in planning poker where we get more information than just the raw numbers, also the ideas behind the numbers. Read More…