AGILE IN ACTION

Distributing teams is a silly thing to do

noreply@blogger.com (Simon Baker) — Sat, 19 Jul 2008 13:31:16 -0500

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

noreply@blogger.com (Simon Baker) — Sun, 13 Jul 2008 16:55:47 -0500

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

noreply@blogger.com (Simon Baker) — Tue, 03 Jun 2008 16:30:33 -0500

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

A taste of TDD

noreply@blogger.com (Simon Baker) — Sun, 01 Jun 2008 08:09:14 -0500

Via InfoQ.

Here's a nice TDD taster from Steve Freeman.

Tags: tdd, test-driven development, steve freeman

More than practices are required to be agile

noreply@blogger.com (Simon Baker) — Wed, 28 May 2008 05:05:54 -0500

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

noreply@blogger.com (Simon Baker) — Mon, 19 May 2008 17:06:15 -0500

planningboard-iterationplan-smudged
Originally uploaded by sjb140470

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.

Simplified Planning Board
Originally uploaded by sjb140470

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

noreply@blogger.com (Simon Baker) — Mon, 19 May 2008 17:06:36 -0500

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.

Clumping definition
Originally uploaded by sjb140470

Clumping
Originally uploaded by sjb140470

Clumping close-up
Originally uploaded by sjb140470

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

noreply@blogger.com (Simon Baker) — Tue, 13 May 2008 15:31:07 -0500

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

noreply@blogger.com (Simon Baker) — Sun, 11 May 2008 11:25:21 -0500

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

noreply@blogger.com (Simon Baker) — Sun, 04 May 2008 14:51:33 -0500

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

The difference between blame and accountability

noreply@blogger.com (Simon Baker) — Thu, 01 May 2008 17:51:09 -0500

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

People do pair-programming

noreply@blogger.com (Simon Baker) — Mon, 19 May 2008 17:07:11 -0500

On the whole our team is pretty good at pair-programming. Our promiscuity [doc] is ramping up nicely and we're now using the concept of rolling story ownership. It works like this: At the daily stand-up, when a new story is brought into play, someone will volunteer to own it. Another person will volunteer to pair on that card. They'll work on the story until the next pair-swap at which point the owner moves off the story passing ownership to his partner and a new volunteer steps in to pair. The same thing happens at the next swap and so on. Ownership of the card passes to the partner and a new person comes in to pair. The person owning the story when it's done is responsible for demonstrating the story at the showcase. At the end of the day I guess it's just collective code ownership or perhaps more aptly collective story ownership. I really like it because it gets more people involved in delivering the story and, because of the frequent pair-swaps and shifting ownership, it gets people communicating. And that creates a buzz. That said, the pairing sessions themselves can still suffer from some of the common ailments, for example:

Keyboard hogging
Drivers over-doing the running commentary
One-way conversations
Procrastination through too much discussion
Copilots disengaging
Copilots playing on their handheld device
Copilots not thinking at a system-level thinking
Holding one another accountable for smelly code
People not remaining aware of other person's skills and level of experience

Our retrospective today asked the question: What makes an effective pair-programming session? The goal of the retrospective was to raise awareness of the people-aspects of pairing - growing a relationship, building rapport, being conscious of the other person's needs, effective communication, etc. The team split into 3 groups of 4 people and they went away to brainstorm and create posters. After 30 minutes we reconvened and each group presented their poster and took questions from the rest of the team. The exercise worked reasonably well as all the teams identified and explored, to varying degrees, the need to build a relationship and maintain effective communication.

Here's some of the posters:

effective-pairing-4
Originally uploaded by sjb140470

effective-pairing-3
Originally uploaded by sjb140470

effective-pairing-1
Originally uploaded by sjb140470

effective-pairing-2
Originally uploaded by sjb140470

I wanted to emphasise the need for effective communication because, as a team, we're highly collaborative and extremely conversation-driven, so I spent 10 minutes talking about it. Everyone knows that communication happens in many ways - language, gestures, pictures, code, etc - yet people often don't recognise that everyone wants to get along and do their best. When people sometimes respond to something you've said in an unexpected way - maybe they're argumentative or obstinate, or perhaps they look confused - there are usually good reasons. Responding in kind is not the way to go. That's just going to make the conversation spiral negatively. Consider how the other person might have interpreted what you said. Find out what possible reasons might exist for their reaction.

A conversation is simply an exchange of information but they can be hard work. It's important to alternate between informing and listening. If you're saying something, don't assume your message is received. Ask for acknowledgement. Ask the other person to play it back to you. When speaking, delivery is everything. Is your delivery causing people to not listen? Saying it louder probably won't work. Try saying it differently. If you're listening to someone, don't just hear them, actually listen. Maintain eye contact, visibly show interest and focus on what they're saying. Verify your understanding by playing it back to them, in your own words.

People label people. These labels essentially stereotype people and encapsulate how you expect them to behave. Labels are a handy means of characterizing a person but they can create negative perception. "What I don't hear, I make up, and I hold you responsible for it." It's difficult but you need to at least be conscious of the labels you use.

Communication needs to be congruent. Balance your own needs, desires and goals against those of others, taking into account the context or environment in which you're interacting. Every person is different. Every pairing session is different. You have to invest in growing a pairing relationship over time with every person in the team.

The action we took out of the retrospective was to give and get feedback within pairs after each pairing session using a 10-minute reflection on the interaction. Here's how it works:

At the end of each pairing session the pair rip an index card in half and each person writes his name at the top of the half-card. The pair discusses the session and each person makes notes on their half-card about what worked well for them, what didn't, and where the interaction can be improved. They do not critique one another. When complete, they exchange the half-cards providing each person with a reference to the pairing session from the other person's perspective. When the pair comes together again they combine their card-halves and work together to improve their relationship and interaction. At the end of each pairing session, the pair writes new card-halves to drive continuous improvement.

We'll run with this for a while and see what happens.

Tags: pair-programming, promiscuous pairing, communication, retrospective, collective code ownership, collective story ownership

Where's the money?

noreply@blogger.com (Simon Baker) — Wed, 23 Apr 2008 14:34:22 -0500

There's a company that makes shirts for men and women using one cloth-cutting machine and one sewing machine. The manufacturing sequence is the same. A single women's shirt is cut in 2 minutes, sewn in 15 minutes, requires fabric costing £45 and sells for £105. A single men's shirt is cut in 10 minutes, sewn in 10 minutes, requires fabric costing £50 and sells for £100. The market's weekly demand is 120 women's shirts and 120 men's shirts.

	Women's	Men's
Weekly demand	120	120
Price	105	100
Raw material cost	45	50
Cutting time	2	10
Sewing time	15	10
Total process time	17	20

Each machine has an operating capacity of 2400 minutes per week and the company's weekly operating expenses are £10,500.

Machine	Minutes necessary for women's shirt	Minutes necessary for men's shirt	Total minutes necessary	Necessary minutes / available minutes
Cutting	240	1200	1440	60%
Sewing	1800	1200	3000	125%

Clearly, there is not enough capacity at the sewing machine to satisfy the market demand for both types of shirt. The company does (maybe) the obvious thing and focuses on the most profitable product. It satisfies all the demand for the most profitable type of shirt first and then uses the remaining time at the sewing machine to make the other type of shirt. The women's shirt is more profitable. It sells for more, fabric costs are less and it is quicker to make. The company can make 120 women's shirts using 1800 minutes at the sewing machine. The remaining 600 minutes at the sewing machine allows us to make 60 men's shirts.

Revenue from women's shirts (£105 x 120)	£12,600
Revenue from men's shirts (£100 x 60)	£600
Total revenue	£18,600
Raw material cost for women's shirts (£45 x 120)	£5,400
Raw material cost for men's shirts (£50 x 60)	£3,000
Total raw material cost	£8,400
Gross margin	£10,200
Operating expense	-£10,500
Net profit	-£300

By focusing on the most profitable shirt the company ends up making a £300 net loss every week.

Say the company did something else. Let's say it decides to make 120 men's shirts and use the remaining time at the sewing machine to make women's shirts. 120 men's shirts use 1200 minutes at the sewing machine. The remaining 1200 minutes at the sewing machine allows us to make 80 women's shirts.

Revenue from men's shirts (£100 x 120)	£12,000
Revenue from women's shirts (£105 x 80)	£8,400
Total revenue	£20,400
Raw material cost for men's shirts (£50 x 120)	£6,000
Raw material cost for women's shirts (£45 x 80)	£3,600
Total raw material cost	£9,600
Gross margin	£10,800
Operating expense	-£10,500
Net profit	£300

By increasing the production of the least profitable product while decreasing the production of the most profitable product the company ends up making a £300 net profit every week. Conventional cost accounting wants to minimise the cost of making a product based on the assumption that the lower the cost of a product, the greater the company's profit. One element in the cost of making a product is the time the product uses company resources. Therefore one way to reduce the cost is to reduce the time at a machine.

For a £100 investment we can reduce the cutting time of a men's shirt from 10 to 8 minutes. That's a 10% reduction in the total process time for a men's shirt, down 2 minutes from 20 to 18 minutes. This is a good investment from a cost accounting perspective. Trouble is it won't increase the overall net profit. The company will still have the same bottleneck on the sewing machine so it can't produce any more shirts than it could originally. The weekly net loss is worse, -£302 (net loss plus -£2 which is approximately the investment of £100 spread over 52 weeks).

For a £1000 investment the company can decrease the sewing time of a women's shirt by 1 minute and increase its cutting time by 3 minutes. This increases the total process time for a women's shirt by 2 minutes. Cost accounting would probably reject this because it increases the product cost. However, by reducing the sewing time required by women's shirts the company has effectively created more capacity at the sewing machine, which allows it to make more women's shirts and satisfy more of the market's demand.

Revenue from men's shirts (£100 x 120)	£12,000
Revenue from women's shirts (£105 x 85)	£8,925
Total revenue	£20,925
Raw material cost for men's shirts (£50 x 120)	£6,000
Raw material cost for women's shirts (£45 x 85)	£3,825
Total raw material cost	£9,825
Gross margin	£11,100
Operating expense	-£10,500
Investment	-£20
Net profit	£580

By increasing the process time of a product, and therefore increasing its cost, the weekly profit has almost doubled.

A company's capacity to produce and sell product is a system or chain of interdependent activities. Trying to maximise profits by cutting costs and investment will eventually damage a company's capacity to make sales. The goal of every company is to make money, not to save costs. Capacity should be protected. A company should do everything possible to uncover excess capacity (by eliminating waste and re-evaluating how things are working) and find new ways to use its existing system and the costs built into it to generate more profit without significantly increasing investment. Then it should look to reduce investment (because that increases Return On Investment) but only by producing less inventory, i.e. product that has not been sold. Cutting costs is the easy option - it should be the last option a company considers.

Tags: value, throughput accounting

Challenges for the Product Stream concept

noreply@blogger.com (Simon Baker) — Sun, 13 Apr 2008 16:29:53 -0500

The Product Stream concept is a simple one. A product stream contains a self-organising team and a Product Owner, yet it engages with the Business more deeply than just having business representation in the Product Owner. Engagement is the wrong word, I suppose, because it's more than that. Software development is absorbed back into the Business. It's no longer just aligned, it's integrated; it's part of the Business.

Product streams may be simple, but already we know it's challenging to establish them within large or enterprise organisations because we're doing it now. It's definitely not impossible though because, from the very start, we've been seeing real successes. But inevitably there's always resistance to change. So far we're seeing more from the IT part of the organisation than from the business part.

The Business has stepped up. The business people within each product stream are doing everything required of them, and more, to collaborate constructively and responsibly and keep up with a weekly delivery cycle. At the end of one of the earlier showcases, our Product Sponsor asked: "Am I doing this right? Is there anything more I should be doing as sponsor?" We're seeing collective ownership of product as business skills are mixing with technical skills to deliver value to the customers.

Generally speaking with respect to IT, the challenges for the Product Stream concept are largely based on IT's fixation on reducing perceived inefficiencies. With the business parts of companies being more vocal about the failings of their IT departments, IT is trying harder to provide better services. The problem is, in a world focused on cost, IT is often concerned more with efficiency than effectiveness. And efficiency without effectiveness just means a poor service will be delivered more quickly. Spot the vicious circle. IT has developed a predilection to centralise things that are common in order to achieve organisational scalability and software re-use, and to reduce expenditure. These are understandable goals but there are consequences if they are pursued without regard for effectiveness. Excessive centralisation has led to over-organisation and fragmentation, and the introduction of unnecessary dependencies, artificial barriers and waste (pdf), all of which hinder product delivery.

Ideally a product stream would be made up entirely of generalising specialists - people who are jacks-of-all-trades and masters of some - and would therefore contain all the skills it needed all of the time. However, there just might be some rare skill that is needed once in a blue moon, which cannot be found in a generalising specialist. In this case the product stream would have to look externally for a specialist in that field and hire him, on an on-demand basis, for the short period required. On the other hand a generalising specialist with that rare skill might be found, but if he's the only one and there are many product streams requiring that skill, what do you do? In both circumstances, it can make sense to centralise the skill, in which case the product stream has a responsibility to learn from the specialist to reduce the dependency. Ultimately, the product stream should rely on the specialist for advice rather than action.

Re-using software is another sensible goal. A product stream can make its software re-usable so that other product streams can use it. But beware. Re-usability doesn't come for free. It requires additional effort that might otherwise be spent delivering product and it creates dependencies between product streams, which may slow things down. IT often moves what it considers to be core software into centralised teams, but this strategy often leads to a focus on infrastructure software rather than product. There's an inherent danger that effort will shift from delivering product to customers - something the Business definitely cares about, to delivering generalised, re-usable software within IT - something the Business doesn't typically care about. The potential long-term impact of re-usability should be assessed beforehand because its affects can end up costing much more. What might be gained by developing once can often be lost, many times over, in the dependencies created. For example, if different product streams using some infrastructure software require changes to suit their specific needs the team owning the infrastructure software can quickly become a bottleneck. And a central bottleneck will slow down the delivery of all dependent products. The Business isn't going to be happy when that situation arises. Infrastructure software isn't all it's cracked up to be so consider re-use on an investment basis rather than a means to reduce costs.

It's preferable to make software available to others as open-source. By that I mean other product streams can take the source code and effectively own their own version of it. They are free to integrate it however they choose, deploy it to their environments, and control the hosting of it to serve their product. If they want to modify the source code they can; they can even submit improvements back to the product stream owning the original source code. The open-source model creates a loose dependency and provides product streams with continued autonomy while allowing them to benefit from the work of others.

Service-oriented dependencies should be avoided wherever possible. This is where a product stream makes functionality available to others via a published API or some client-side code that must be integrated. This is a tightly coupled dependency because the product streams using the service are entirely dependent on the service provider for the functionality. The service provider probably keeps the source code private (or doesn't allow anyone outside the product stream to maintain another version), and hosts and controls the service. If a product stream requires a change to the service or bugs to be fixed it must ask the service provider to make the changes. If the service fails, the product streams rely on the service provider to take corrective action. Consequently, product streams using the service lose some of their autonomy and to a degree, control of their own product.

Tags: product stream, value stream, product sponsor, product owner, lean

Product streams: Skills-based and product-oriented businesses

noreply@blogger.com (Simon Baker) — Mon, 19 May 2008 17:07:28 -0500

There's lots of talk about aligning Information Technology with the Business. Apparently, it's the number one goal for CIOs. Information Technology is a big field so I'm going to focus on software product development.

It's not enough for software product development to just be aligned with the business; it needs to be part of the business. At one of our clients, and with executive support, we have introduced the concept of product streams by implanting self-organising technical teams into existing business units, where each unit is focused on a product. Essentially, a product stream is a small business with dedicated delivery capability. Its purpose is to make money by selling its product and it contains everything it needs to conduct business. It has a simple structure: Product Sponsor, Product Owner, customers or users (if they are internal to the business) and a technical team. Everyone in a product stream is full-time and only those people with skin in the game are included. Stakeholders are restricted to those people who have a real vested interest in the product. The technical team contains all the skills it requires to perform every duty relating to the product, taking it from concept to production and then operating and supporting it. Decision-making, both business and technical, happens within the product stream.

Product Streams
Originally uploaded by sjb140470

In many respects, a product stream demonstrates the behaviours of a startup (but with discipline):

Focus is on product, not process.
There is a sense of urgency; people are united around single goal - get product to market quickly to start making money.
Everyone is working in the same room, to a shared vision with a charter against which success can be measured.
Everyone works together, collaborating intensely and communicating honestly - the driving force behind getting stuff done is just a conversation.
Cashflow is key. People are conscious of the finite money available so everyone thinks in terms of value and cost.
People make the right information visible and keep it up-to-date so that informed decisions can be made on where to invest money so that the development effort concentrates on delivering the highest value first.

A product stream encapsulates the value stream for a product and provides the conditions for flow and an environment where waste is first eliminated and then prevented. The people in a product stream are responsible for removing anything from their process that does not add value for their customers. They limit the work in process to their capacity, they work with a cadence, and they eliminate unevenness in the delivery schedule. All this enables them to deliver value to the customers frequently, at a constant and predictable rate.

The product stream is proving to be a more effective organizational unit for developing and delivering product than traditional role-based projects.

When project teams are formed people are seconded to the project by their silos or resource pools to perform a particular role. However, they remain affiliated to their silo and loyal to the people in it. Some people only work on a project part-time, they multi-task across projects. A project has a shorter lifespan than the product it is meant to deliver. The business people cram every requirement they can think of into the scope because they know that if they have any new, significant ideas after the project has ended they won't have any developers available. When the project does finally end, responsibility for the product is handed over to a support team via some documentation and perhaps some training. The support people have had very little involvement in the project, perhaps none. Any product expertise dissipates as people in the project team return to their silos to be reallocated. All this doesn't exactly create a culture that is conducive to building a lasting sense of ownership of and commitment to the product. Consequently, people are often not held accountable. They feel they're on top of their part of the project and they don't care about the other parts. "There's a hole in your side of the boat", as they say.

A product stream, unlike a project, is persistent and is available for as long as the product remains in service. People are dedicated full-time and therefore develop a sense of belonging and demonstrate a greater pride in their work. They care as much about the product as the business people do. They are loyal to the product and the people in the product stream and they hold one another accountable. The composition of a product stream may vary over time to best suit the needs of the product but, to some level, it retains all the skills and expertise it learned as the product evolved. The people who built it are the people who support and operate it (and there's no better incentive to deliver quality than if you have to take the call at some crazy hour on the weekend to fix a problem). Their expertise is totally engrained. When someone has a new idea and it's deemed valuable, the product stream is available to deliver it to the customers without delay or impediment.

A product stream continues to deliver a flow of valuable features to the customers who use the product for as long as they choose to use the product.

In the next couple of posts, I'll talk about the challenges the concept of a product stream faces in an enterprise organisation and how a portfolio of product streams can be managed as part of a business strategy.

Tags: product stream, value stream, product sponsor, product owner, lean

Create business value by focusing on end-users

noreply@blogger.com (Simon Baker) — Sat, 19 Apr 2008 14:50:27 -0500

Business value. What's valuable to a business?

At the end of the day, the goal of every company is to make money. So, ultimately, a business values things that make it money. We should always do our utmost to deliver value to our business by giving it the things that will help it make money from its customers. But focusing directly on business value is not good idea. Making money is most definitely the goal but focus must be on the source of revenue - the customers or end-users. If a business focuses on the money it eventually does wrong by its customers and they go away and it makes less money.

Imagine a business that makes reasonable money from adverts displayed in a heading or sidebar on its Web site. As user numbers increase, the business sees the potential to make more money from advertising and increases the amount of advertising space on its pages. It also introduces pop-up adverts, all without considering the effect on the users' experience. It turns out that customers don't like the more intrusive advertising. It gets between them and the reason they visit the site so they gradually stop visiting. The business is left with plenty of adverts but fewer customers to click on them.

Pursuit of revenue to the detriment of customers is a pretty good way to not make money.

Drucker said every company should ask itself 3 questions:

Who are our customers?
What are their needs?
What do they consider value?

To make money a business needs to focus on its customers' perception of value. Give customers what they want and they'll be happy to give you their business. Continue to give them what they want and they'll come back, time and again, creating opportunities to make further money. To deliver value to customers with high-quality, reliable solutions and to move forward with customers to satisfy their evolving needs, a business needs to understand the customers' world, what the customers are trying to accomplish and, beyond that, imagine where the customers are going.

Tags: value, customer, end-user

Kent Beck on being agile

noreply@blogger.com (Simon Baker) — Mon, 24 Mar 2008 14:29:26 -0500

What does it mean to be agile?

My definition is that you accept input from reality and you respond to it. - Kent Beck

In this interview (available on InfoQ) about his new book on Implementation Patterns, Kent Beck also talks about problems that occur when trying to be agile. I've transcribed of some of the questions and his answers.

XP is a rather practice oriented methodology. Can you describe the relationship between implementation patterns and XP and how they work together?

[Beck] The easy part of XP is practice related but there are three legs on the stool - practices, values and principles - and I think the people who are successful applying XP are paying attention to all three. This gets back to some of my disenchantment with the direction of agile development in general. People are now asking the question: "How am I going to do agile development?" Agile development isn't a thing you do. It's an attitude. It's a set of personal values about responding to the real world, being open to the information that's there, and being willing to do something about it. That's agility. Yes, there are a lot of practices that come out of that but to me that's where it starts - it's this attitude. If somebody understood a bunch of practices and tried to do them, you could do agile development without being agile and that's a disaster because your acting out of harmony with what you really believe.

So in most situations when people learn agile, they just learn how to do it, but they don't really change their belief system?

[Beck] I think that's the easy way to teach agile development but I don't think it's actually easy at all. I think it's very hard to pretend that all you have to do is learn TDD, learn Continuous Integration, learn to use JUnit and learn to answer the three questions at the Daily Stand-up and then you're agile, because its not connected to reality. It's easy in the sense that you don't have to think very hard to come up with a set of Powerpoint slides that let you explain agile development that way. But I think it's very hard to deliver that with a straight face because, pretty soon, you're getting a lot of feedback that it doesn't work that way. I think that all three legs of the stool have to be there or it falls over. I think that you do need to understand how to program well in order to program well. It matters whether you technically do a good job or not but that's not enough. I think you also have to understand and hold the value system that's consistent with agility - communication, simplicity, feedback, courage and respect - the one from XP. I think that value system is very much in harmony with being agile. And then to have a set of principles so that when none of the practices really fit, you quickly backup and say, "Hmm. None of the practices fit but in principle the XP way to solve this problem would be blah, so lets go do that". Once you have all three legs of the stool then you have a chance to really be agile.

Tags: agile, extreme programming, values, principles, practices

Time to abandon what has failed

noreply@blogger.com (Simon Baker) — Mon, 25 Feb 2008 09:51:02 -0600

More and more software will be behind schedule, over budget, underpowered, and of poor quality - and there's nothing we can do about it.
- Bruce Webster, Byte Magazine 1996

What's surprising - astonishing, in fact - is that many software engineers believe that software quality is not improving. If anything, they say, it's getting worse. It's as if the cars Detroit produced in 2002 were less reliable than those built in 1992.
- MIT Enterprise Technology Review, June 17 2002

The mass production paradigm has failed the software industry. The improvements to cost-effectiveness and the reduction in inefficiencies by focusing on methodologies, processes and tools have not materialised.

The characteristics of mass production include repeatability, large infrastructure, organisational gigantism, efficiency, and techno-centrism. Repeatability relies on the interchangeability of parts, including workers. Division of labour fragmented worker occupations into specialised jobs so that a worker could be replaced with a new worker of the same description, in theory, preventing production from slowing down. A large infrastructure with more capacity grows from the pursuit of economies of scale and allows the amortisation of production costs across production volume to provide greater return on capital investments. But a large infrastructure requires a large organization to operate it and this costs more. The best way to reclaim these costs is to keep people continually busy and, in software development, the best way to keep them busy is to have them multi-tasking across lots of projects. Efficiency means keeping the infrastructure operating constantly under full load with the machinery and workers perpetually busy. But the focus on efficiency means there is little tolerance for stopping to correct systemic problems that permit or cause defects. The obsession with efficiency leads to centralisation and departmentalization based on roles and a dependence on after-the-fact detection, remediation and acceptance. It pays lip-service to improving quality and reducing defects. The cost of rework and the loss of flexibility in being able to respond to customers and the marketplace is significant. In their quest to maximize efficiency, organisations adopt more infrastructure and tools but it's really using technology for technology's sake. The software industry likes to look to bigger, faster, more complicated tools as way to meet schedules.

If a little medicine doesn't make the patient better, keep increasing the dosage until it does. The strategies of mass production, which aim to contain chaos through task and worker specialisation, process standardisation, hierarchical structure, and command-and-control management simply don't work. But old habits die hard.

Tags: mass production, efficiency, centralisation

Inconspicuous leadership

noreply@blogger.com (Simon Baker) — Sat, 23 Feb 2008 15:25:54 -0600

A leader is most effective when people barely know he exists.
When his work is done and his aim fulfilled, they will say: 'We did it ourselves.'
- Lao Tzu

Tags: leadership

Collaborate more to achieve hustle

noreply@blogger.com (Simon Baker) — Wed, 20 Feb 2008 12:21:13 -0600

Our team has been together now for about 15 weeks and things are going well. We've got a sustainable pace that's delivering value every week, our Product Owner and Product Sponsor are both happy, and everyone is having fun. So what's bugging me?

Well, it's 2 things. First, I've been sensing that there is additional capacity in the team that we haven't been able to tap into. And second, we've not been able to sustain our hustle for anything longer than a few days, perhaps a week. Reassuringly, over the last few iterations, the team has become aware of our inability to sustain hustle and in the last retrospective the team described its overall performance as pedestrian. That's a harsh word to describe an experienced agile team but its use demonstrates that the team isn't satisfied with its current pace and supports the idea that there is more to be had.

Can we tap into the additional capacity I think is there by sustaining hustle? I think so and I believe the key is more intensive collaboration because it creates a buzz. We've already seen improved collaboration by slicing stories more. This has created more frequent opportunities to obtain feedback from testers, the Product Owner, and the customer. It generates more conversations. We've also got our new bullpen layout removing the physical obstacles presented by pods of desks. This has given us the space to huddle and have timeouts, it allows people to move freely throughout the team area with chairs whizzing across the floor, and it facilitates conversation and osmotic communication. But I feel the big win will come if we pair more promiscuously. In his paper on promiscuous pairing, Arlo Belshee reported:

Promiscuity, it turns out, is a good way to spread a lot of information through a group quickly. Rapid partner swapping ensures that a good idea, once envisioned, is soon practiced by every pair. Replacing individual accountability with team accountability empowers each person to do those tasks at which he excels - and allow someone else to take over for his weaknesses.

Each of our practices provided the team with more flexibility and better communications. More creative ideas were formed, and each idea was automatically disseminated to the entire team by the end of the day. Each person was expected to continuously learn what was happening and contribute in a very short amount of time. Working on this team often felt like drinking from a fire hose, but it was empowering.

The data shows that we were more productive the more promiscuous we were - as long as we remained with each partner long enough to exchange knowledge. What they don't show is that we also had a lot more fun. It took the team a little time to adjust to the more rapid pace, but working with that team was a career high point for every person involved.

I know promiscuous pairing will generate a buzz, I've experienced it with a previous team. But it will also consume energy. Ron Jeffries wondered whether hustle was sustainable citing success and rest as the key regenerators of the energy required for hustle. I believe we can sustain hustle if we continue our strategy for energized working, and we're already achieving success every week by delivering what the Product Owner prioritises. But, because we have 3 more weeks before we go live, visibility of success is restricted to the showcases and a demonstration environment (which is treated like a production environment). Somehow this diminishes the feeling of success (especially when you achieve it week in, week out). When we're live we'll be able to deploy to production every week and users will see a flow of new functionality. That's real success and that ought to help us sustain hustle too.

Tags: hustle, collaboration, energized work, pair-programming

From humble beginnings

noreply@blogger.com (Simon Baker) — Mon, 19 May 2008 17:09:39 -0500

From humble beginnings:	Default workspace in office Originally uploaded by sjb140470
Springs a decent bullpen:	Pairing in the new bullpen Originally uploaded by sjb140470 Planning boards in the bullpen Originally uploaded by sjb140470

It's only taken 4 months! It's been an excruciatingly painful process and having to deal with furniture police and a jobsworth here and there has required persistence and the patience of a saint.

But look at all that space in the middle for people to huddle and have conversations. It was worth the fight and worth the wait.

Tags: bullpen, planning board

What's The Prime Directive really about?

noreply@blogger.com (Simon Baker) — Tue, 19 Feb 2008 08:01:03 -0600

An interesting conversation surfaced on InfoQ that questioned the Retrospective Prime Directive. I've paraphrased a lot of it here.

The Prime Directive says:

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

But we've all thought it - what about those people who aren't doing their best, who aren't pulling their weight, those people who are, from your perspective, being deliberately obstructive? Such people do exist although many would argue, that in their own way, they are trying to do their best. It's important that we recognise that our observations are subjective and are influenced by our prejudices.

The retrospective is about the collective retelling of a story for the purpose of learning and it's difficult to learn when people are blaming each other. It's much easier to influence someone or learn from them if you haven't written them off. The retrospective is not the place to conduct performance reviews on individuals. Keep that for one-to-ones. The Prime Directive asks us to suspend all of our suspicions and judgments about others for the short time that we are in the retrospective allowing our brains to focus elsewhere so that the team might just learn something.

Tags: retrospective, prime directive

Playing with stuff

noreply@blogger.com (Simon Baker) — Wed, 30 Jan 2008 16:28:34 -0600

This blog's been quiet for a while. Sorry 'bout that. Coming soon I'll be posting about a couple of things we've been experimenting with. First, for the last 8 weeks we've been using Jeff Patton's techniques for using goals and user stories in the product backlog to express activities, tasks the user performs and tools the user needs to perform the tasks. Second, we're 'playing' with Critical Chain estimation, specifically the use of a Project Buffer or in our case an Iteration Buffer, to remove padding from our estimates to see if we are able to deliver more and get a boost into sustainable hyperproductivity. Kevin Rutherford experienced some success with this when he tried it. Last, and if I can convince Gus, we'll post about our use of Grails.

Tags: user stories, critical chain, grails