Avoid Surprises at Sprint Planning, create a Definition of Ready?

There has been a lot of talk over the years about having a definition of “Done” or “being Done”, but I think it is just important to have a definition of Ready.

Have you ever been in Sprint Planning and been surprised to find out the requirements aren’t clear or the team has no idea how to implement it?

The original Scrum writings stated that Sprint Planning should be done in two parts:

1. Review the scope and understand the stories
2. Task the stories

More and more, I see teams conduct part 1 earlier, during the previous Sprint in backlog grooming sessions. The goal is to work ahead just enough to limit the number of surprises during Sprint Planning and consequently, the Sprint. To know what is just good enough, you should define your Definition of Ready. i.e. What does it mean for your team to be ready to start a Story in a Sprint?

I recommend teams spend up to 10% of their time preparing for future Sprints. This may involve activities such as the following:

• Reviewing Epic or MMF (Minimally Marketable Feature) stories and breaking them down into Sprint Sized Incremental Stories
• Having conversations with the Product Owner (PO), Stakeholders and/or customers to understand their needs and working with the PO to document the Acceptance Criteria 
• Discussing new stories and providing a rough sizing estimate so they can be prioritized
• Thinking about what will be needed to implement the story: New HW or SW? New Knowledge? New Architecture? Paying off accumulated Technical Debt?
• Working on just enough design to keep things flowing. It is common for UX Designers to work about a half a Sprint ahead of the rest of the team.

So if your Sprints have a lot of surprises, you might consider working with your team to form a Definition of Ready and allocating time to work a little bit ahead. Your Sprints should flow like a track relay where the next runner is already running as the other one starts. Don’t start your Sprint’s flat footed.

For further information, see our Evolution of a User Story post to learn more about how to get your stories ready.

Austin DevOps Events Summary - Culture is Important

Last week some of our team attended several DevOps related events here in Austin. We had a great time learning and interacting with other technologists attending both  PuppetCamp Austin and DevOps Days Austin.

This edition of the annual DevOps Days event in Austin (which also takes place in other cities each year) was declared the biggest. There were great discussions, Ignite talks, and Open Space sessions as well. And while there is always much conversation around technology, there was a noticeable focus on culture.

Many of the talks on both days had a strong cultural component. On the second day, the organizers even mentioned feedback from some attendees to move past the culture stuff and on to tech talks. But it was obvious from the sessions that a large number of people felt the cultural conversation was important. Those of you in the Agile community who haven’t looked closely at DevOps will recognized these are similar conversations to those occurring about Agile in general.

Some notable takeaways:

• Patrick Debois on The future of DevOps - slides/video
• DevOps State of the Union by John Willis
• John Heintz tweeted that DevOps is 90% attitude (culture, meme) and 10% technology
• Pete Cheslock had a talk on DevOps in Your Job Title Is Doing You Harm
• Jeff Hackert had a talk on Exploiting Conway’s Law for Underpants and Profit
• Gene Kim, one of the co-authors of The Phoenix Project, spoke on How Do We Better Sell DevOps
• Speaking of The Phoenix Project, it was referenced in many talks and obviously making an impact with many. It is a novel about DevOps and Business and highly recommended.
• Sharing a Culture of Automation - Instant Infrastrucutre in Developing Nations by Chris McClimans

There were too many great talks to highlight them all here. You can see all the recorded talks on Vimeo. You should also look back through tweets to see what people were saying during the conference.

If you haven’t attended one of these events, you should definitely try to attend at least one they put on each year.

Announcing: Behavior-Driven Development with Cucumber Workshop June 4 & 5

Our goal is to change the way you think about building software. 

Behavior-Driven Development (BDD) employs the approach of specification by example. Instead of talking in abstract terms about what the system will do, the team collaborates to create specific examples that specify what the system should do from the user's perspective. These executable specifications function as acceptance criteria for the user stories the team is developing. The team specifies as concretely as possible what the specification is, and then the developers code enough of the system to make the test pass to satisfy the acceptance criteria for that specification.

Cucumber is such an amazing BDD tool because it’s so good at mapping stories and acceptance criteria to automated functional tests. Product Owners and BA's write acceptance criteria in business language. Developers and testers unobtrusively automate tests for them.

Taught by expert instructor Paul Rayner, coauthor of the upcoming Addison Wesley book, BDD with Cucumber, this 2-day hands-on workshop is designed to get you productive with doing BDD with Cucumber in the shortest time possible.

Class Schedule:

Day 1: Introduction to BDD

• Introduction to agile background and process
• Feedback loops: vicious & virtuous
• Building quality in
• Understanding the place of BDD - the agile testing matrix
• Outside-in testing
• Why test automation?
• Build the right product using specification by example
• Creating a ubiquitous language
• Writing scenarios with Cucumber

Day 2: Creating Value using Cucumber

• Using Cucumber for using specification by example to test web applications
• Best practices for Cucumber test scenarios
• Dealing with scenario data
• Adopting BDD with Cucumber - emphasize learning and focus on value

Who Should Attend:

All delivery team members:

• Testers and QA staff
• Developers (Ruby, Java and .NET)
• Project managers
• Product owners (Business Analysts, domain/subject-matter experts)
• Software architects

Requirements:

Attendees should bring a laptop for the class coding exercises. A pre-configured virtual machine image will be provided for class coding exercises.

Registration

Notes from Data Day Texas 2013

I didn't really know what to expect being that Data Day Texas 2013 was my first Big Data conference. While it is a young conference and some might say that what we call "Big Data" also young, there were a lot of interesting and enthusiastic people talking about a field that is rapidly changing and maturing. The opening talk (slides) was by Paco Nathan (Evil Mad Scientist at Concurrent Inc.). Some random points:

• There are 3 kinds of data, Human/Tabular data, Human/Nontabular data, and Machine Generated data
• 80/20 rule for big data says that 80% of the costs of processing data are tied to preparing the data.
• Big Data is moving from more obvious fields into areas such as agriculture, heavy industry, and energy.

The second talk I attended was by Dr. Matthias Broecheler, the lead developer of the distributed graph database Titan. I am a complete beginner when it comes to graph databases, but they seem to make a lot of sense for certain types of data. More random notes:

• There are three classes of graph DBs: In-Memory, Distributed, and Batch Oriented
• TinkerPop is an open-source set of frameworks and tools for working with graph DBs.
• The Gremlin DSL is a way to query a graph DB. It reminds me of XPath queries, but applied to a DB.

Other random notes I made during the day:

• Cascading, Cascalog, and Scaling are three (Libraries? Frameworks?) that make it easier to  express and implement algorithms that can run across Hadoop clusters.
• Cascalog offers 10:1 reduction of code compared to SQL
• Interestingly, Cascalog offers a way to do "TDD for Big Data" by allowing the user to setup assertions (as regex's) on inbound and outbound flows, and then make the assertions pass as the code is written.

Because this field is in a very dynamic phase, it seems like a new Big Data tool or framework or database is introduced everyday. The need for better ways to process and analyze large amounts of data is also increasing. The challenge will be to apply Big Data tools to Big Data problems in an incremental and "Big Agile" way.

Is Hadoop the right solution?

I noticed some interesting announcements recently concerning the open-source Apache project Hadoop. Firstly, in the last week, both Intel and EMC have announced their own Hadoop distributions (link). It seems that the big iron hardware vendors are finally coming around to seeing Hadoop as the standard for big data processing. It makes sense for these vendors to optimize and integrate Hadoop into their platforms, but in reading these articles, I have to wonder if these vendors are focused too much on Hadoop as the single solution for all large scale data processing needs.

I stumbled across an article some time ago by Mike Miller at Cloudant that made the case that Hadoop's days are numbered. Mike makes the point that while Google MapReduce and it's open-source cousin Hadoop were great innovations when first introduced, even Google has moved on to other technologies that have fewer limitations and are better performing. I have personally struggled with determining the best approach to handling streaming data sets in Hadoop. In fact, it seems that something like Storm might have been more appropriate.

Part of the job of a good software architect is knowing what tools to recommend to the team that are available and best fit the job. This means that you need to know about a range of tools with different strengths and weaknesses. So, the next time someone mentions Hadoop as the solution for a large-scale processing need, take a step back and make sure the problem maps well to Hadoop. If there are ad-hoc analytics, dynamic data sets, or other features that Hadoop has trouble supporting, look for other alternative that might perform much better.

Podcast Recommendation: The Ruby Rogues

WAIT! Stop Right There!!! I know some of you saw Ruby in the title and are about to move on, but I encourage you to read on. This could be beneficial to you even if you don’t know or don’t care about the Ruby programming languge.

Podcast Description

For those of you who listen to podcasts while driving, mowing the lawn, running, cleaning the garage, or lounging at home, here is a recommendation of something I like and listen to. Like many, there aren’t always enough hours in the day to keep up with various topics and I like to listen to podcasts when I can to keep up.

Our reading audience are technology folks, usually involved with delivering software using an Agile or Lean approach. This podcast recommendation isn’t explicitly Agile or Lean focused, but those elements can be found here in there along with healthy doses of pragmatism. While there is a focus on a specific language I have found a wealth of good knowledge and discussion often applicable to general software practitioners of any technology set.

Agile Velocity has a lot of experience working with Ruby on many projects over the years, which led me to the Ruby Rogues Podcast. This is a group of Ruby practitioners who lead a weekly panel discussion of Ruby and Software Development topics with frequent guests from the community. Many of the regular hosts are well known in the Ruby community and are also authors and conference speakers. Each episodes also ends with fun technology (and sometimes non-technology) picks by the panelists.

This is an easy recommendation for anyone who works with (or is considering) Ruby. But there are many episodes that focus highly on general software issues around development, delivery, agile, technical practices, craftsmanship, etc.

Recommended Episodes

Here are some episodes that general agile software practicioners may find interesting:

• Rescue Projects: A discussion of projects that have become problems and how to approach them, including dealing with legacy code and designs
• Book Club: Practical Object-Oriented Design in Ruby: A discussion with the author about learning and applying good Object-Oriented Design. This is timely because many people in the Ruby community came to programming with little formal OO training.
• Learning From the Past: A discussion about standing on the shoulders of others and how to learn and improve our skills by looking at past experiences (ours and of others)
• Complexity (with Glenn Vanderburg): An examination of what complexity is, it’s effects, and how to deal with it
• Service Oriented Design: A look at applying Service-Oriented design
• Book Club: Growing Object Oriented Software Guided by Tests: A discussion with the authors about testing, design, object-oriented principles, and software architecture. This is one of the best books on the subject of TDD.
• Functional vs. Object-Oriented Programming (with Michael Feathers): With the recent resurgence of interest in old and new functional languages there are many people trying to compare these paradigms and evaluate when/if to use them.
• SOLID (with Jim Weirich): Using SOLID principles of Object-Oriented design
• Domain Driven Design: Like it says, a discussion of Domain Driven Design, technical practices, design patterns, ubiquitous language, etc.
• Agile Communication (with Angela Harms): A discussion of Communication techniques and awareness for Agile teams
• Estimation: A discussion estimation, tracking/managing projects and measuring speed
• Software Craftsmanship (with Noel Rappin): The panel dicusses the concept/manifesto of Software Craftsmanship, apprenticeship, Code Retreats, etc.

It was difficult for me to pick just this list because there are so many more great episodes. While this is probably nothing new to people in the Ruby community, I hope I have pointed the rest of you to one of the best software development related podcasts around that most software practicioners can benefit from.

ALPN Houston Presentation

It was an honor to have a chance to speak at the Agile Leadership Network Houston Chapter tonight. Here are the slides from our presentation.