Monthly Archives: February 2013
As organizations adopt agile practices, there are several key skills that differentiate high-performing teams from mediocre teams:
1) Working in short timeboxes
For a team that is accustomed to delivering working code every six or eight months, two or four week long iterations can be unfathomable. But doing this is essential to the success of the project in order to get the benefits of continuous code integration into a testing environment and frequent user feedback. The sprint’s timebox forces the business stakeholders to constantly question the scope of each feature at a micro level and decide when to carve out functionality.
2) Splitting work into small pieces
The most common excuse for teams wanting to plan sprints using large user stories is that it is “more efficient” to do all of the coding work together and test it at the very end or in the next sprint. This perceived efficiency is self-deception. Successful agile teams know that they must put working code in front of their users early and often. Remember the old saying that “users often don’t know their requirements until the software fails to meet them?”
3) Communication and transparency
Old-school silos between IT, Product/Marketing, and business operations groups are an agile anti-pattern. Political games, finger pointing, and one-upmanship are a huge waste of an organization’s resources and energy. A grown-up culture of transparency allows all of these players to collaborate and solve difficult challenges. For the Scrum Master, this means posting project information in high-traffic areas of the office. More importantly, it means being open with stakeholders about the challenges that the team or project is encountering. Team members can feel secure speaking freely about impediments and project risks in a public forum without fear of reprisal. The essential skill here is knowing how to voice issues in a way that does not sugar-coat them but does set the stage for a constructive discussion.
4) Swarming, collaboration, team first
“Your side of the boat might be leaking but my side is fine” attitude just doesn’t cut it anymore. Lone gunmen need not apply. The most effective agile team members will gladly work outside of their skill sets and comfort zones if it helps the team succeed. Agile developers welcome and seek opportunities to discuss functionality with end users to understand their goals and needs. They leverage techniques such as User Acceptance Test Cases to capture and understand detailed requirements.
5) Focus and finish mindset
This is another one of those things that is counter-intuitive at first for people new to agile. Coders are used to getting all the coding tasks done so that they can get all of the stuff to the testers. Understanding that high work in process = low throughput is key. Developers working in lockstep with testers results in higher throughput, even if that means that the developers have to swarm on non-development tasks every now and then.
6) Scope negotiation
Scope negotiation means being relentless both when talking about items in the current sprint or when doing release planning. Sometimes it takes two, three, or four conversations about an item to admit that it is not really needed.
7) Talking about requirements at the right level of detail at the right point in time
Skilled agilists recognize that the conversation that happens in a user story writing workshop is at a much higher level than the conversation about a story right before that story is pulled into a sprint. They also shun detailed requirements until the sprint starts, knowing that a large collection of detailed requirements is inventory that is subject to decay.
8) Automated testing
Refactoring is a fact of life as requirements are progressively elaborated. Effective implementation of test-driven development and automated testing blunts the effort for regression testing as the application evolves.
A mature agile team intuitively knows what a story point means in terms of the relative size of a user story compared to other stories that it has sized in the past, but how does a new team that perhaps even has people who are new to agile get started with story points? As I mentioned in another blog post, Ideal Days is a story point estimation scale that blends size with effort and degrades the backlog sizing process into a drawn-out time estimation exercise. Given that a points scale like the Fibonacci sequence that relates more to size/complexity is preferred, how does a team get started when it does not have a baseline story against which to do relative sizing?
A few things should be in place to set the stage for establishing a baseline story:
- Definition of Done. This should include quality assurance and user testing.
- Sprint length. Should be no longer than two weeks.
- Understanding by the team that high throughput is achieved via low work in process, i.e. having a small number of user stories in flight (being worked on and not at ‘done’) in a sprint.
Once there is a set of stories in the backlog that are small enough to pull into a sprint, the next step is to discuss and assign story points. In asking the team to assign story points for the first time, I usually tell them something like this:
Team, we know that in order to meet our sprint goals we need to get the first story in this sprint coded, unit tested, and into QA by the second or third day of the sprint. Let’s call that a three point story.
With that in mind, the team sizes the first few stories. Some might argue that we are just using Ideal Days. We are not, because executing and supporting the QA and user testing efforts are not included in the goal of getting the story to QA by the second or third day of the sprint. The other reason we are not using Ideal Days is because we only use this method for sizing the first couple of stories in the backlog. After that, all estimations are done relative to those first couple of stories that were sized, by asking whether or not a story feels bigger or smaller than those stories.
- Establish the Defintion of Done, sprint length, and concept of high throughput via low work in process before sizing stories.
- Size stories with the goal of getting the first story into QA within the first few days of the sprint.