Articles You Should Read

Here are my current favorites articles, in no particular order. I've shared them all at work and now I'm sharing them with you.


The Guard: I've read this article at least nine times now. I identify most with being the Old Guard, which makes me cringe helplessly every time I read it. It is thoughtfully written and makes some excellent points about how a team starts to trust themselves. Key excerpt:

• The Old Guard: "I feel empowered to fix everything."
• The New Guard: "I don’t know how to fix anything."

Teaching Iteration: High schools around the world need to start teaching this topic now and it should be a mandatory course. The cool thing is that the core concept can be applied to just about any subject. Let the students pick the thing they have an interest in and teach them skills for "how to make it better". 

Don't Get Blocked: This may be the closest thing I have to a personal mantra. The anti-pattern is people who like putting up roadblocks. Those people should get (symbolically) run over.

Sprint Review Best Practices

The sprint review is a critical checkpoint in agile development. It is the opportunity for the stakeholder to see your solution to their problems. Their feedback during the presentation leads to future work being defined and provides a common understand of thier pain points to the development team.

From personal observation, I noticed a few things that detract from the effectiveness of a sprint review. Particularity, new team members don't know what to expect, so I think having a short set of guidelines helps set expectations.

The best case scenario is that you are sitting in the same room with your client. However, some of the points below consider the challenges of a remote team conducting a sprint reviews via telecon and screen-sharing.

Presentation

• Have a compelling narrative with demonstrable stories flowing into each other
• Use a common scenario or theme as much as possible
• Role-play as a specific stakeholder role, demonstrating new functionality within context of their daily tempo
• Use their team names, role titles and domain language to inspire confidence that you know their processes and how the implemented stories help them
• Shun words and phrases like "lorem ipsum" and "foo/bar" as they show you don't understand the problem or care enough to use stakeholder specific terms
• Focus on new functionality, unless a review of previous functionality helps understand the context
• Minimize UI components that don't contribute to demonstrating the new story
• Maximize the UI so that background elements don't detract from the story focus
• Know the audience and understand if they have previously seen the functional area you are talking about. There could be new people listening in or specially invited VIPs.
• Give reminders of what acronyms stand for before using them
• Know your project and its capabilities so that you can react to customer confusion and answer questions during the live demonstration
• Allow "space" during the presentation for feedback. Remember, a good sprint review is not a monologue, it is a conversation.

Etiquette

• The stakeholder always has precedence during conversations; don't over-talk them. Keep side conversations at a low volume so everyone can hear stakeholder feedback.
• Mute your telecon microphone if you are not actively involved in a conversation. What seems like low background noise to you can come through loud and clear over the telcon.
• Turn off cell phone ringers
• Presenter should close all applications, such as email, IM and team chat apps, that could display popup notifications during the presentation

I hope these points help you during your next sprint review.

And if you think these are all common sense, stay tuned for my next blog post!

Agile Story Done Criteria Template

As an agile development team lead, I assisted our solution owner by explaining the intent and direction of our backlog stories to the team.  Normally this happened during a weekly team "backlog grooming" session. The purpose of the session was to fully understand the story, scope out the done criteria to match a fairly solid implementation plan and to estimate a story WAG. 

I found that the extra planning and team discussion before the story was accepted at backlog selection a valuable time investment. To help focus the grooming session discussion, I created a standard template for the story Done Criteria section. The concept of the template is to encourage team participation, scope the full expectations of the story, and document important discussions and ideas that will prevent confusion during the implementing sprint.

I'll present my template below and then follow that with a more detailed explanation for each section of the done criteria.

Story Done Criteria Template:

---

User Acceptance:

1. User can save a new map scene composed of a map background layer, a lat/lon center point and a zoom level.
2. User can only delete a map scene if the user was the creator.
3. ...

Team Definition of Done (derived requirements, quality, standards):

1. Approved by UI team
2. Must create a supporting release notes task documenting manual installation steps
3. Remove unused database entries for "system.map.*" properties.
4. ...

Out-of-scope:

1. Users cannot rename map scenes. This is covered by a future backlog story.

Discussion Answers:

1. TBD

---

Template Explanation:

User Acceptance:
User-facing requirements that must be complete for the solution owner to accept the story. Typically thought of as hard requirements that would necessitate direct negotiation with the solution owner (or users) if an problem were discovered during implementation or testing.

Team Definition of Done:
Derived requirements that influence the team's implementation.  These could represent functionality that a user would notice, but that does not impact the user's intent of the story.  This category also encompasses criteria that the implementation team values for internal quality, consistency or project standards reasons. Items in the section can be contributed by anyone on the team: developers, designers or quality control, for example.

Note that these specific criteria typically represent areas of high risk and otherwise important tasks that have not yet become a normal habit of a high performing team. For example, we don't call out typical story tasks such as unit testing, peer reviews or required documentation updates.

Out-of-scope:
This important category complements the positive criteria of the story by documenting good ideas for future backlog stories. Having this section seemed to encourage team members to contribute ideas on stories while allowing a place to record the ideas without bloating the scope of the story being discussed.

The other important reason for this section is that by being explicit here, we can avoid mid-story confusion when someone asks: What is the expected functionality when the user does X? Did we forget to consider this functionality or did we talk about it and arrive at a decision that it was not covered by this story?

Discussion Answers:
This section is for use AFTER the story has been accepted by the team and is under development. If any mid-sprint issues are discovered where the expectations are not clearly covered by user criteria, the team will work out a plan with the solution owner AND record the decision here. All such answers should be recorded here as the source of the requirements. This avoids having important story criteria being discussed in email threads, or on the phone, but not transcribed here for full team visibility.

Typically, these answers will be translated into criteria for user story acceptance tests (USAT) and become part of the official application specification.

Miscellaneous Helpful Ideas:

• The criteria should use numbered bullets for quick, unambiguous verbal reference during the team grooming session.
• Out-of-Scope items should have a POC assigned so that the ideas get translated into new stories or suggested to the users during the sprint review presentation.

"There’s no success quite like failure"

From Accept Defeat: The Neuroscience of Screwing Up:

"This is why other people are so helpful: They shock us out of our cognitive box. “I saw this happen all the time,” Dunbar says. “A scientist would be trying to describe their approach, and they’d be getting a little defensive, and then they’d get this quizzical look on their face. It was like they’d finally understood what was important.”

What turned out to be so important, of course, was the unexpected result, the experimental error that felt like a failure. The answer had been there all along — it was just obscured by the imperfect theory, rendered invisible by our small-minded brain. It’s not until we talk to a colleague or translate our idea into an analogy that we glimpse the meaning in our mistake. Bob Dylan, in other words, was right: There’s no success quite like failure."

Global Collaboraton In the Second Grade

I just finished reading The World is Flat by Thomas L. Friedman. He had some good insights and specific example about how the world is increasingly connected and how it functions as a global marketplace. The most interesting take away I had was that simply providing the cabling into countries that had not been previously connected was enough of a spark to allow individuals with curiosity and an innovative spirit to engage a global community.

Those of us in the software business, take this interconnectedness for granted now. I find it fascinating, being a father of two, that my children will know no different; the world was always connected. In the span of a single generation the world got very small indeed. I have friends who grew up their entire life in single small town. Any road trip of more than 100 miles was a big deal. But my kids won't have to "go" anywhere to instantly know what is going on on the other side of the planet or to actively collaborate with people on other continents.


So with this in mind, I had an idea for an education software project. My second-grader already has computer lab class once a week where he and his classmates learn and solve problems on a standalone system. What better time to learn about teamwork, on a global scale, then now, while he is in school.

My idea is a collaborative system that lets kids work together to solve and reinforce basic school (and life) skills. As math is a universal language, it would be a good first subject.

Picture this:

• The system is browser-based and has a easy to use, friendly RIA interface.
• One student from the USA joins the "Collabmath" course; One student from India joins the same course and they are paired together to solve 5 math problems.
• Each student will have a friendly avatar with their county's flag next to it. Each student's name can be clicked on to hear it pronounced in the native language. Google maps can show each student's school marked on a world map.
• The math problem will be presented in a large left hand workspace, and a chat window could be in a right-hand pane.
• The chat window can be used by the students to provide encouragement or ask for help. The chat would be I18N capable and feature emoticons that would make the session more personable.
  

• Each student takes turns solving a problem a step at a time. When each step is complete, control transfers to the other student, and so on. So, for a simple example, if the problem is to draw an octagon, the first student will draw the first line segment, then the second student will draw a complementary line segment connected to the first. When the octagon is complete, the students will have worked together to solve the problem.
• At the conclusion of each problem, a practical real world example of the use of that problem in each culture could be presented. In my example, the students would learn that in America, the octagon is the shape of a traffic stop sign; a related symbolic example could be presented that would be relevant in the country of India.

A wide range subjects and grade levels could be taught, of course, but for starters, this could get the ball rolling. I envision my kids being excited one day, coming home from school, "Dad! Guess what? I learned division and fractions with a kid from China today! Her name was Ming Wu! It was so cool!"

I can see it. Can you?