More than practices are required to be agile
Over on
InfoQ, Amr Elssamadisy says
successful agile teams are predominantly characterized by their culture and not their practices.
Agreed. Team culture grows out of the values people share, their behaviour and the chemistry their personalities create and the fun they have when they work together, the friendships they form and their combined sense of belonging. Sadly, a team's culture is often limited by the culture of the wider organisation. But, it's not enough to just have a great culture. Without disciplined application of practices a team is likely to deliver poorer quality.
Agile teams that just do the practices are mechanical and the rote application of practices is not being agile; you might call it 'doing Agile', maybe. Whatever. It misses
the point and the full potential of a team will never be realised. Practices are tools and they are more effective in the hands of a
craftsman. A craftsman is a master of his tools. His mastery is borne out of his personal discipline when using the tools, his awareness of context, the factors in play and what's going on around him, and his thought processes. Without personal discipline, awareness and the inculcation of values and principles, it is easy for people to regress to bad habits.
Tags:
culture,
practices,
craftsmanship,
values,
principles
Links to this post
We changed the layout of our planning boards
The photo on the right shows how our planning board used to look a while back. There were 6 columns from left to right: Not Started, In Dev, UI Preview, QA Review, Customer Preview and Done. Each column essentially represented an opportunity to get feedback, e.g. from a graphic designer, a tester or the Customer. A
story slice was expected to take a trip across the board from In Dev to Customer Preview and back and the story card earned an appropriately coloured dot for each column visited. There's duplication. The column a card is in and its last dot represent the same thing. Although all the dots together show the history of a story card. People also seemed to have trouble putting the cards back in the right place, even though their
avatars are actually placeholders. Anyway, we decided to refactor the board.
Before I describe the new board format here's a bit of background. We use
1-week iterations. We do iteration planning every
Wednesday, we estimate the stories in
ideal pair days and we go to production at the end of every iteration. We also do slightly higher-level planning that looks out over the next 4 weeks and we use t-shirt sizing to estimate these stories. Together, these give us some goals to shoot for over a relatively short timeframe that is bigger than a single iteration, setting a direction if you like, and a nice small, coherent and prioritised
backlog from which to pull stories.
Looking at the new board format in the photo on the left, you can see we've renamed the 6 columns. From the left, the first 4 columns read 4, 3, 2 and Not Started. The Not Started column contains the stories not yet started in the current iteration. Columns 2, 3, and 4 correspond to the weeks or iterations ahead and contain those stories that we think would be roughly the iteration content based on the t-shirt sizes. To the right of the Not Started column is In Process and on the far right is Done. We've retained the dots so now, when a card is started it gets a red dot and is placed In Process. When a story slice goes to the
testers the card gets a blue dot and remains In Process. The same is true for Customer Preview but the dot is orange. When the story is done, the card gets a green dot and is placed in the Done column.
The dots are opportunities to obtain feedback. (A red dot for In Dev represents the feedback that occurs during
pair-proramming.) The testers hold the blue dots and the Customer holds the orange and green dots. There's no pass or fail. The dots are simply given for the feedback generated. When the developers working on a story want particular feedback they have to go and have a conversation with the appropriate person and do a little demonstration to obtain the dot. For example, if a slice goes to the testers, the developers have a conversation with them, perform a demonstration and leave the card so they may conduct exploratory testing. In the meantime the developers are free to seek a pair swap and contribute to other stories already in play. When satisfied with the slice the testers give the card a blue dot and return it to the developers, providing feedback in another conversation. Something similar happens when the developers want to get feedback from the Customer. They'll have a conversation, walk the customer through the functionality delivered and get an orange dot. When shooting for Done, it's up to the Customer to accept the story and give the card a green dot. There is a prerequisite - the story must have gone through the testers one last time so that the whole story gets a preceding blue dot. This ensures the testers always play with the story in its final state and approve its candidacy for Done.
Tags:
agile,
planning board
Links to this post
The Clumping Phenomenon
In one our of
retrospectives a wee while ago we identified the phenomenon of clumping. Clumping, as it has been colloquially termed, is the crowding effect that occurs when too many
pairs cram into one section of the
bullpen.
Now, our bullpen has ample space to distribute pairs so they can work comfortably, yet we often experience clumping. To try remedy the effect, in the
daily stand-up and at pair-swaps throughout the day we ask people to be aware of clumping and attempt to distribute themselves utilizing the whole bullpen area. This works well if the code is mobile. By that I mean that working story
slices are checked-in at pair-swaps, so that the code for a
user story can continue to be worked on at any workstation in the bullpen and not be anchored at a particular workstation. That's not as easy as it might sound.
Tags:
clumping,
pair-programming,
bullpenLinks to this post
Collaborating with our Customer
We are creating a family of portals and a publishing system to manage their content. We have two sets of users. There are end users - the people in the public who read the content of these portals, and there are editors - employees in the organization (and its partners) who publish content to the portals. The Editorial Director is our Product Sponsor and the Senior Editor is our
Onsite Customer. We're part of a
product stream so we're colocated with the editors, our Customer and our Product Sponsor. Consequently collaboration is predominantly conversational, by that I mean it's relaxed and happening all the time. We also have some set pieces that occur throughout the iteration, which also help us collaborate with our Customer, the editorial team and the Product Sponsor.
Our Customer and the editors have day jobs and every now and again they're not available for a conversation. We have to respect their
flow time. This doesn't happen that often because we have a great sense of team across the product stream and everyone knows we're in this together. Nevertheless, if we can't get feedback when we ideally want it, we can always rely on the
Clinic Time at the start of each day. This is a 15-minute time slot at 9:30am, immediately before the
daily stand-up, where everyone in the product stream is available. It provides the team with a sure opportunity to seek out the feedback they need and there's an open invitation to the Customer and editors to drop into the
bullpen and get previews of where things are at in the iteration, share ideas and get feedback, and raise any issues.
To help us understand the editors' jobs and how they work individually and together we
shadow them twice a week. For an hour at pre-arranged times, a pair of developers and testers sit with the editors observing them doing their jobs and asking questions. This reveals many important things about their workflows, their behaviour and how they use the publishing system, which are a great help when we're designing how functionality will work.
Our
iterations start on Wednesdays and on Wednesday afternoons our testers hold a
Playshop for the editors where they get to play with the functionality
showcased by the team the day before. We only do this while we're building that first release of product. Once the first release is live we deploy to the production environment at the end of every iteration. What we're working towards is more
user-centred design within iterations but that's another post.
Tags:
collaboration,
conversation,
clinic time,
shadowing,
playshop
Links to this post
Velocity, capacity and productivity
A team's velocity is the sum of the estimates of the user stories that were
done during the iteration.
Some people use velocity as a measure of productivity. Productivity is the rate of production measured in terms of the rate of output per unit of input, but I like to think of velocity as the capacity of the team because it represents the maximum number of story estimation units a team can take on in a planning game based on
yesterday's weather. I prefer to measure productivity in terms of the goal and getting stories done is not the goal, generating revenue is. Getting stories done is the means to achieve the goal.
Productivity could be something like the business value delivered per iteration per unit of story estimation, but business value is typically subjective and therefore not easily quantifiable. Productivity is perhaps better represented by the revenue generated per iteration per unit of story estimation, e.g. £10,000 per ideal pair day. A complementary measure of productivity uses pure monetary terms and is the ratio of the revenue generated to the cost of delivering the functionality responsible for generating that revenue, e.g. £10,000 / £5000 = 2.
A
product stream should work to maximize return on investment and the team should challenge itself to increase its velocity. Pressuring people to work harder, work longer hours, and take on an increased workload is not the way to increase velocity. It's the way to start a
death march. Causing people to sacrifice their work-life balance is detrimental to the health of the people and the product because tired people drop quality and create more defects. People should be allowed to practice
energized work where they work only for those hours where they are genuinely productive and maintain high quality. And a team must be given the space and the time to find the velocity at which it can work and deliver at a
sustainable pace.
The way to reveal extra capacity and increase velocity is to relentlessly remove obstacles, eliminate waste and improve continuously. Help the team focus on the product, on quality, and to deliver only the functionality that adds value to the product and generates revenue. Keep the process simple and intuitive so that people don't have to stop and think what the next step is. And protect peoples'
flow-time by preventing interruptions. Help the team avoid creating inventory, i.e. functionality that is complete but cannot generate revenue because it is not deployed to the production environment. Quickly remove obstacles that are identified in the
daily stand-ups and minimize dependencies so the tream doesn't have to rely on others to get stuff done. This also cuts down on the time spent waiting around and chasing down and the effort required to hand stuff over.
Tags:
velocity,
capacity,
productivity,
user story,
done
Links to this post
Testers in our agile team
In our team, developers create the vast majority of the automated tests, whether they are acceptance tests, integration tests, or unit tests. They do this because they are
story test-driven. They develop stories from the
outside in, starting with the user interface and are guided by the acceptance criteria. The developers profile their code and create automated performance and load tests as they go because code has to be production-ready at the end of every
1-week iteration. Testers in our team do exploratory testing and they're free to pair-up with anyone, another tester or more likely a developer, to create any automated tests they feel are missing. The testers, however, add value to the team that goes way beyond testing. Working closely with the Product Owner they facilitate connection and collaboration with the customer, helping the team to empathise with users, understand their needs and appreciate value from their perspective. Working with the facilitator they help the team develop a conscience that is focused on the delivery of value and quality, while their continuous interactions within the team keep collaboration high.
In the pre-planning game with the
Product Owner, Customer and a few developers, the testers help grease the wheels for the coming iteration's planning game by teasing out, through conversation, preliminary details about the candidate stories to get them to about the right size. Details are noted in pencil on the reverse side of the story cards. The planning game is similar to the pre-planning game except the whole team is present. Typically, the Customer is absent because the conversations can get technical in order to estimate the stories but the Customer can be there if they want. Again, the testers help tease out story details and capture these as acceptance criteria, in pencil, on the reverse of the story cards. The team works together to identify the right acceptance criteria for each story. The planning game is about doing just enough planning to reach consensus on estimates and commit to a delivery goal. Everyone understands that, as collaboration occurs and the story is developed, it may be necessary to add, remove or modify acceptance criteria.
When stories are started in an iteration, developers build them out in
vertical slices that satisfy specific acceptance criteria. When a slice is ready, the developers have a conversation with the testers, demonstrate its functionality and walk through the automated acceptance tests. When the testers are happy they're left to run their automated build, which deploys the latest code to their environment. Here they'll conduct their exploratory testing. Exploratory testing functionality as it emerges, slice by slice, helps avoid a tail-end testing crunch in the iteration or, worse, trailer-hitching testing in a separate iteration. Developers might also ask the Product Owner and Customer to preview a slice to get more feedback. When this happens, the testers act as chaperones to keep abreast of emerging details and are part of any decisions made relating to the story.
Testers starve without slices so they pull slices from developers on a regular basis to maintain a flow of stories that ultimately make it to done in time for the
showcase.
Defects are rework and an expensive form of waste. When a defect is found in a story and the story is still being developed, the defect is a stop-the-line event. The testers interrupt the developers working on the story and ask them to fix the defect in the next slice. This conversation usually includes the testers showing how to reproduce the defect. If the story is no longer being developed - maybe the defect was discovered after a story was completed - the testers write the defect on a pink card, which is then placed at the top of the
board, so it will be the next card to be started.
Testers on our agile team have found their working day to be very different. They're using the same testing skills and they're finding new skills as they collaborate more within the iteration.
Tags:
testing,
agile,
collaboration
Links to this post
The difference between blame and accountability
I talked about communication when
people do pair-programming. For a while now, there's been some trepidation in the team when holding people accountable. People seem to have difficulty knowing how to hold someone else accountable. It's a communication problem. People are so worried about being seen to blame someone for something that they'd rather avoid the conversation completely. The problem with this approach is that the things that shouldn't be happening keep happening because the people doing them don't know they shouldn't be doing them.
Deal with the root cause. Have a conversation and hold the person accountable.
To me, the difference between blame and accountability is language and delivery. Here's a couple of examples:
"That code you wrote to do thingamyjig is rubbish. It's causing all sorts of problems."
Here you're assigning blame, which can be exaggerated with intonation and gesture.
"You know that code you wrote to do thingamyjig?
I think there might be a better way to do it. Can we sit down and try refactoring it?
I'd like to show you what I'm thinking and get your feedback on it."
Here, on the other hand, you've approached the person, offered to help improve the code and created a learning opportunity for him (and probably for you too) that will help address the root cause and prevent it from happening in the future.
Tags:
communication,
accountability,
blame
Links to this post
