AGILE IN ACTION

Collaborating with our Customer

2008-05-13T11:01:00.016+01:00

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

2008-05-11T14:04:00.016+01:00

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

2008-05-04T18:20:00.017+01:00

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

2008-05-01T00:18:00.006+01:00

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

2008-04-30T22:38:00.046+01:00

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?

2008-04-19T17:29:00.077+01:00

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

2008-04-13T21:08:00.011+01:00

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

2008-04-06T00:13:00.031+01:00

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

2008-04-05T17:39:00.016+01:00

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

2008-03-24T17:31:00.012Z

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

2008-02-23T21:43:00.018Z

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

2008-02-23T21:20:00.003Z

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

2008-02-20T18:31:00.007Z

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

2008-02-20T10:19:00.035Z

From humble beginnings:	Default workspace in office Originally uploaded by sjb140470
Springs a decent bullpen:	Pairing in the new bullpen Originally uploaded by sjb140470 Huddles 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?

2008-02-19T11:13:00.015Z

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

2008-01-30T21:56:00.000Z

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

Tips for Analysts fulfilling the role of Product Owner

2008-01-10T22:07:00.000Z

If you're an Analyst and you're fulfilling the role of Product Owner on an agile team, focus on:

'The What' - what does the business need.
'The Why' - why is it valuable to the business and how much value does it have.
'The When' - prioritise it by the value to the business.

Leave 'The How' to the team.

Tags: product owner, business analyst

Acting 'as if' is self-fulfilling

2008-01-06T21:23:00.000Z

New year is the time for setting resolutions for oneself. One of the principles of Appreciative Inquiry is that of Enactment - positive change comes about as images and visions of a more desired future are enacted in the present.

Mahatma Gandhi said: Be the change you want to see. Enact the changes you seek. Fulfill your resolutions, be what you want to be by living your dreams today.

Tags: appreciative inquiry

Common

2008-01-04T21:24:00.000Z

Voltaire said: Common sense is not so common.

Sometimes, in IT today, it appears that common sense is masked by common practice, making it seem counter-intuitive.

Tags: common sense

Entropy always wins

2007-12-20T23:42:00.000Z

Your world is changing faster than you'll ever be able to keep up with, and you can view that fact from 2 different perspectives:

I believe I can control my world, and through an aggressive campaign of task management, personal goals, and can do attitude, I will succeed in doing the impossible. Go me!

I know there is no controlling the world, but I will fluidly surf the entropy by constantly changing myself.

Surfing entropy takes confidence; this is a personal confidence you earn by constantly adapting yourself to the impossible.

Follow me and let's figure it out together

2007-12-16T17:22:00.000Z

Via InfoQ.

Mary Poppendieck talks about the role of leadership in software development at Agile2007. Here's the handout to accompany the video.

What I found particularly interesting was the history lesson:

1900s: Frederick Winslow Taylor and his Scientific Management and his contemporary Charles R Allen with his on-the-job training.
1940s: Training Within Industry.
1980s: W Edwards Deming and his System of Profound Knowledge.
1980s - Present day: Toyota Production System.

Here's a quote Mary used that I like:

We get brilliant results from average people managing brilliant processes. Our competitors get average results from brilliant people working around broken processes.
- Fujio Cho, Chairman of Toyota Motor Corporation

Tags: lean, leadership

Building trust

2007-12-16T12:23:00.000Z

A bit of trust goes a long way.

(Via Pascal Van Cauwenberghe) David Anderson gives us a few tips on building trust:

Trust begets trust
Be humble and respect the other
Vulnerability disarms
Apologise for poor results; take responsibility, even if you weren't involved in the delivery of the poor results; promise better; deliver
Keep delivering, regularly, predictably
Deliver daily on your personal commitments; deliver daily or weekly on team commitments
Demonstrate competence; rehearse and practice for perfect delivery
Be transparent
Encourage learning from failure
Get rid of command and control
Build up a reputation
Define clear values and principles; let them guide decision making

Tags: trust

Who'd believe it?

2007-12-15T22:05:00.000Z

We're 9 weeks into our project. 1 week in and we had built the rudiments of a working portal. When we were 2 weeks in we asked our Product Sponsor if we could put an early version of the portal (and the Publisher system we're building to go with it) live before Christmas. If I'm honest I'm not sure he believed we could do it but he liked the idea and gave us the go ahead. We've been building out the functionality iteratively every week since then.

On Thursday evening we put an early version of the portal live and we celebrated with pizza. During the day there was lots of fun and frolics. Judging by some of the looks we were getting, I don't think people in the company had seen people in the process of going live be so relaxed, let alone have fun.

Now it's done, the Product Sponsor is excited and can't decide whether to publicise the portal. A nice dilemma to have.

First test deployment to production
Originally uploaded by sjb140470

Ding! Ding! Ding! Come and get it
Originally uploaded by sjb140470

Retrospective using Appreciative Inquiry

2007-12-15T18:26:00.000Z

The iteration after looping the loop has been the best yet. Everyone enjoyed it immensely. The team were buzzing and the Product Owner, Product Sponsor and Customer were ecstatic. I really wanted to tap into the positivity and leverage the energy to consolidate our gains in teamwork so I decided to facilitate an appreciative retrospective.

I introduced the retrospective by stating the following affirmative goal:

During this retrospective, we'll find ways to amplify our strengths in process and teamwork.

Here's the agenda:

1. Prime Directive

2. Check-in (5 min)

To get each person talking, ask every person to check-in by showing their appreciation for someone else on the team. They should say something like:

I would like to thank so and so for doing x.

3. Brainstorming (5 min)

Gather data by asking the team to brainstorm enjoyable events, team strengths, and successes. Have them write each one on a colour-coded post-it note.

4. Futurespective brainstorming (10 min)

To begin generating insights ask the team the following question:

Imagine we could time travel to the end of the next iteration/release. When we arrive there and converse with our future selves, we hear that it was the most productive, most satisfying effort we've ever worked on. What do you see and hear in that future time?

Have them write on a different colour post-it notes.

5. Affinity mapping (15 min)

Ask the team to group related post-it notes and assign each group a name.

6. Dot voting (5 min)

Tell the team to examine the groups again and to think about the things they identified in the future, and then ask:

Building on our successes to date and given our team strengths what do we really want to sustain?

When they've taken a minute to think ask them to dot-vote to identify what (group) they want to sustain going forward.

7. Identify the take-away actions (20 min)

Now the team needs to decide what to do. Ask the question:

What actions should we take to amplify our strengths in process and teamwork that will help us build towards the successes we have foreseen?

Facilitate a discussion to identify one or two actions, note them on index cards and take them into the next iteration's planning game.

Appreciative Inquiry - Functional Team Output
Originally uploaded by sjb140470

The format above worked well. It generated the following actions to carry forward:

Strive for slices
Ask for help and offer help to others
Pair promiscuously

There was lots fun and smiling faces, it relaxed everyone and put them in a positive frame of mind, which helped the planning game (that follows our retrospective) go more smoothly.

Tags: retrospective, appreciative inquiry

Looping the loop

2007-12-15T17:30:00.002Z

We entered the loop at speed.
We went up, over and down and came out the other side faster
and stronger for the shared experience.

All teams have blips. Gus and I had sensed growing frustration in our team over the last few iterations - sniping, bickering, moaning, negative comments. Morale was starting to be affected. We opted to hold off for a couple of iterations and tried to coax out the root causes indirectly through the retrospectives, hoping that the team would become more aware and take remedial action. In the end, when the team norms were breaking down and a lack of respect started to emerge, we quickly decided to tackle the problem head-on. We canceled the next retrospective and informed the team that instead we'd be holding one-to-one sessions. (This upset the team further because they love their weekly retrospective but we held firm.)

The one-to-ones proved very effective and were just what the doctor ordered for the team members and for us. We realised that actually things weren't really as bad as they appeared. The general frustrations were around learning a new technology (Grails), people perceiving others to be not as committed, people cutting corners and not being held accountable, ambiguous information sharing and story myopia leading to a lack of teamwork, especially around preventing slop. Chatting about it all reminded people of their responsibilities to the team and helped people generate some great yet simple ideas for making things better and getting the team back of track.

Connected learning from retrospectives
Originally uploaded by sjb140470

The one-to-ones cleared the air and we've made some small changes that have completely transformed the team. The small changes so far include:

A more conscious effort to vertically slice stories to create opportunities for collaboration with (and obtain feedback) from QA, the graphics designer and the Product Owner). The rule of thumb is at least one slice a day. People are taking a little time now to think how they will build the story out using slices before jumping in.

In the daily stand-up when story owners talk about their card, they now mention their pairing partner and speak only in terms of the acceptance tests:
"So far x out of y acceptance tests have been satisfied. Yesterday, so and so and I completed acceptance tests a and b. Today, I will pair with someone to complete acceptance tests d, e and f"
Again, in the daily stand-up story owners request any specific expertise they might require during the day and when they think they will need it. At the end of the stand-up when we form pairs, the team organizes itself so that the right skills can get to the coalface on each card.

Pairing is more promiscuous. The Grails expertise and styling (CSS) expertise are now being transferred more effectively spreading the knowledge and building skills redundancy into the team.

These are simple changes we've made many times before with other teams. Sometimes blips happen because we take our eye off the team.

With respect and trust restored, the team norms have returned. There's a stronger sense of team. Everyone is asking for help and offering help. Collaboration has gone through the roof. The net results: The team is happy, healthy and hustling, and the velocity has doubled.

Tags: team, daily stand-up, retrospective, one-to-one, vertical slice, pair-programming