Distributing teams is a silly thing to do
I'm happy to see that more people are
uncompromising and are speaking out against doing the silly things that people justify with "that's reality". We create reality and we can therefore change it. Where there's a will there's a way.
Tobias Mayer
says:
"Distributed teams are not teams; they are at best a collection of people who communicate regularly. But communication is not collaboration. A distributed team cannot create the kind of energy that comes from human eye contact, from shared spontaneous laughter, from physical touch. True collaboration requires all five senses. Distributed teams require managers, and thus can never be truly self-organizing. Time differences and delayed response times inevitably slow down conversation, hold up decisions and ultimately cripple agility."
Distributed teams can never be that agile so stop pretending they can. Find ways to colocate. It's not impossible.
Tags:
compromised agility,
colocation
Inconspicuous authority
I talk a lot about facilitating self-organising teams. For a Scrum Master, a little more than facilitation skills and authority for the process is needed to ensure people interact with professionalism and demonstrate the right behaviours - respect, humility, empathy - at all times.
In most organizations, a Scrum Master is actually a manager and, sometimes, a Scrum Master has to step in when people 'misbehave', but the objective is really to help a team manage itself. The challenge for a Scrum Master is to develop a demeanor that hints at authority just enough to keep people true while giving them freedom. The question is how does someone develop such a demeanor?
I think what you say and how you say it plays a part. As does what you do and how you do it. But 'you' are the core. By that I mean you act by your values and are guided by your principles. And what drives you as a person determines the style in which you conduct yourself. This is what people see.
Tags:
scrum master,
facilitator,
authority
A recent visit
Our friend
Steve Freeman brought
David Anderson along to see us at a client a few weeks ago. It was great to have the likes of Steve and David come see what we're getting up to, listen to some of the ideas we're pursuing and give us some feedback. David has said some
very kind words about his visit on his blog.
We're a few weeks away from introducing the financial instrumentation we've been developing based on
throughput accounting but we've been using it in one
product stream and the results have been good. "Follow the money" is the mantra. I'll blog more about this when the fun starts but, sooner rather than later, I hope to share some of the theory with you and go through an example as well as divulge a bit more about the Product Hub. In the meantime, I will say the strategy for the hub is to grow a win-win relationship between The Business and Tech. The idea is to convert Tech into a profit centre from a cost code and enable it to help The Business generate more revenue by creating product streams that deliver when The Business needs it. In return The Business rewards more work to Tech rather than outsource or offshore it.
Tags:
product hub,
product stream,
throughput accounting
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
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
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,
bullpen
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
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
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
