People do pair-programming

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:






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

Posted by Simon Baker @ permalink

Links to this post 

2 Comments

Where's the money?

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

Posted by Simon Baker @ permalink

Links to this post 

1 Comments

Challenges for the Product Stream concept

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

Posted by Simon Baker @ permalink

Links to this post 

5 Comments

Product streams: Skills-based and product-oriented businesses

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

Posted by Simon Baker @ permalink

Links to this post 

0 Comments

Create business value by focusing on end-users

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

Posted by Simon Baker @ permalink

Links to this post 

0 Comments