July « 2009 « Thinking for a Change

Jul

Where would you rather work?

Would you rather be a member of a Cost Centre or of a Value Stream?

Even if you don’t know exactly what each term means, where would you rather work?

Which of the two would focus most on the customer?

Which of the two would be more open to Agile, Lean or continuous improvement?

Accounting matters. Not just for the numbers, but also for the words.

When was the last time you talked to your accountant or CFO?

Jul

I’m sorry, I can’t help you because the system is down

How many times have you heard this apology? Often, the apology is “The system is down again.” In some places the system is always down around certain times and you get the same apology every day.

Why are we suprised when systems are unavailable? There will be bugs, mistakes and scheduled downtime. We should not be suprised the system is down, we should expect it.

Some time ago, an IT architect asked me during a job interview if it was possible to build reliable systems out of unreliable parts. My response:

The only way to build a reliable system is to build it out of unreliable parts (or systems)

If you want to build a reliable system, you have to be aware that all its subsystems are unreliable. This allows you to take appropriate measures, like building in redundancy.

We need a paper process

A smart manager I once worked with insisted that every business-critical automated process also required a backup “Paper Process”. The Paper Process defined how the work would be done when (not if) IT systems were down, with nothing more complicated than pen and paper (and a battery-powered calculator if really needed). When systems were unavailable everybody knew what they had to do to keep the business ticking over as if nothing happened. They also knew how to catch up when the systems were available again. In this case, it was clear who the bottlenecks were, so the other people subordinated by entering the backlog of data on paper into the system. Did I mention that this department used less automation than other similar departments, yet had a better track record of delivering on time, was more efficient and brought in more money?

Defining an alternative Paper Process was relatively easy, because we really understood the real business requirements of our customer. Since then I use this as a test of my understanding of the real requirements: could I implement the requirements with nothing more than paper and pencil? If you have real requirements (and not a solution in disguise) it’s easy to define several different implementations.

Since that project I learned more about processes. If I had to do this project again I would do it the other way round: implement the Paper Process first and ask what, if anything, we would need if the Paper Process broke down. Maybe a whiteboard is enough.

Jul

Business Value Game v2.0

Business Value Game v2.0 released

Continuous improvement, feedback and collaboration at work: the Business Value Game has been updated. Lots of people who played or organised the simulation have given us plenty of ideas for improvement. We’ve held retrospectives after each run. Laurent Morisseau has helped us to translate the game into French.

The result: Business Value Game v2.0 is now available in English and French.

What’s changed?

There are now more projects at the end of the game with new challenges
The Accountant’s job has been simplified by making the score sheet clearer
There are more opportunities for process and technical improvements
Reduced fluctuation in development team velocity as some players felt that “luck” had more effect than sound strategy
The Development Team and the Accountant now also have pictures, thanks to Janina Köppel’s South Park Studio
All playing elements have been translated into French. The session leader manual is only available in English

If you want to help translate the game into another language or if you have ideas for improvement, let us know.

What hasn’t changed?

The Business Value Game is still a fun way to start a conversation about business value, prioritisation, working with stakeholders and company values.

The Business Value Game still has a Creative Commons license and we encourage you to download it, use it and reuse it.

Next Stop, Chicago

Portia and I will present the Business Value Game at the Agile 2009 conference in Chicago.

We’ll play the game on Wednesday August 26th at 16:00. In the morning we’ll play the Bottleneck Game to experiment with Theory of Constraints, Lean, Agile and Real Options. Come and play with us!

The Business Value Game by Vera Peeters and Pascal Van Cauwenberghe is licensed under a Creative Commons Attribution-Share Alike 2.0 Belgium License.

Jul

Avoid Change

The thing I hate most about myself is that I don’t want to change

The first XP book was very important for me. It changed the way I work. It changed my life.

I still apply the practices to improve the way I work. The principles have helped me to make my work more fun, sustainable and successful. The values have helped me to do worthwhile work that delivers value.

But “Embrace Change“? I don’t like change.

How to avoid change

I avoid change on my projects by

Really understanding the needs of customers, stakeholders and users. Those needs change from time to time, but not very frequently if we really get to the core of what these people value. I get accused of doing Big Upfront Design or Analysis, even in companies seemingly doing Waterfall. Why waste so much time upfront, can’t we start building yet? Customers don’t know what they want anyway, so why try to discover what they need?
Not committing to decisions too soon, applying Real Options. If we commit later by delaying decisions to the last responsible moment and gather more information, we need to come back on fewer of our decisions. I do get called a procrastinator. Real leaders take charge, take decisions!
By not being distracted by useless technology churn. Simple, reliable and known tools and technology in our toolkit let us concentrate on adding value. I do get called a dinosaur, not up to date with the latest framework or fad du jour. Real geeks only work with the latest 0.1 version of technologies that are so complex that we can spend months unraveling their intricacies (and bugs). I need a well-padded resume with all the latest technologies to get that next job when the shit hits the fan on this job.
By making sure we consider supporting processes and users in our value analysis. All too often we focus on the shiny business value generating processes but forget that these can’t work unless people can perform the unglamorous supporting jobs that make these value streams possible. I do get called a Waterfall analyst, who wants to explore every nook and cranny of the system before we can start building. Real Agile teams deliver Business Value, cash quickly. Why waste time with non-business value-adding processes like getting the product into the hands of the user or managing the system to keep it relevant?
By making a plan (not a schedule) of the goals we want to achieve in the future so that we have a guiding vision when we travel the path. I do get called an old-school project manager who wants to control and stifle the creativity of his “resources”. You can’t be agile if you have a plan.

Projects with fewer changes are a lot easier and less stressful than those with many changes. These projects implement Heijunka. They deliver value surely and steadily. I like that.

Embrace risk reduction and new information

I welcome any change which reduces risk. We continuously identify our main risks and find ways to avoid them. For example, we discover that there’s simple alternative way of doing something. We can use that as our backup strategy if the planned way of doing the work doesn’t get ready in time. For example, we first implement a very basic implementation of a business process and iteratively refine it, so that we’ll always be ready to release by the deadline. Of course, we have to use that extra time that Real Options gives us to actively seek out information and reduce risk.

Embrace increased flow

I welcome any change which can increase flow, get us to release faster and get the cash flowing sooner. For example, we can start by statisfying a subset of stakeholders and users. We can focus on on value stream at a time. We can mercilessly pare down what is really needed to achieve goals. We can get rid of wasteful checks, approvals and delays. We increase quality to decrease changes due to rework.

Embrace value increase

I welcome a change that increases value. For example, “Exchange Requests” let the customer increase the value of our work. If the customer wants to add a feature to a release, they first have to remove an equivalent amount of work from the release. The customer will only perform the swap if the new feature has more value than the one swapped out. So, for equal (or lower) cost, we deliver a product with higher than initially expected value.

Embrace cost and investment reduction

I welcome a change that reduces cost or investment. I welcome a new, simpler way of achieving a goal. I welcome reducing scope as we discover that we can simplify business processes. I welcome a reduction in “dimension” as we discover that we can satisfy user needs (for now) with less exhaustive or refined implementations. I welcome a way to reduce the amount of work in process.

I’ll get me coat then…

Can I be Agile if I don’t Embrace Change? Can I be Agile if I value people and their interactions AND processes? Can I be Agile if I insist on customer collaboration AND a contract? Can I be Agile if I only want to respond to beneficial change AND follow a plan? Can I be Agile if working software is not the solution or only a small part of the solution? Can I have my cake AND eat it too?

Where do I go to hand in my Agile badge?

If anybody needs a Waterfall coach, let me know. I can change. I’m agile 😉

Jul

Software Development Takt

Takt time

Takt time is the rate at which customers buy a product. Takt time determines the speed at which a Lean manufacturing runs. For example, say we sell 576 units of product A. If we have a 8 hour shift, we need to make 72 units per hour, or 1.2 units per minute. We have 50 seconds per unit.

Every step in the production process must now deliver their contribution to the product in 50 seconds.

What if there’s a step that can’t deliver in 50 seconds? Then we have a bottleneck. We’ll produce and sell less than we could. We apply the 5 focusing steps to increase the bottleneck’s capacity so that they can deliver in 50 seconds or less.

What if there’s a step that can deliver in less than 50 seconds? They still deliver every 50 seconds, even if they have to slow down. If they delivered more frequently, we’d build up lots of work in process as other steps can’t use its output faster than once every 50 seconds. Or we might build unsold goods.

Slowing down? Isn’t that inefficient? Yes, but we’re not optimising the efficiency of a single step. We’re optimising the whole value stream. If a step has a lot of spare capacity, this could be used to work on another product, but only if it doesn’t endanger the delivery of the first product.

Using Visual Management, the value stream tracks actual production rate regularly. The steps won’t run perfectly as clockwork, there will always be some variation. The production rate displays allow everybody to react (speed up, slow down a bit) to keep to the takt time. The takt time works as a metronome that synchronizes musicians.

Takt time isn’t (always) the drum beat

In Theory of Constraints, the Drum-Buffer-Rope system synchronizes the speed at which each step in production runs. The “Drum Beat” is the rhythm, the steady pace at which the slowest step (the bottleneck) runs. The rest of the system works to that beat. Again, no use producing faster than the bottleneck because we’ll only create more work in process.

The two concepts are quite similar and I sometimes confuse them. There’s one clear difference:

takt time is customer-focused, outward looking
drum beat is bottleneck focused, inward looking

If the customer is the constraint, a base (if not outspoken) premise of Lean, takt time equals the drum beat and drum-buffer-rope implements customer pull.

Takt time in software development

What is the equivalent of takt time in software development? If you’re Microsoft, you know approximately how many copies of Microsoft Office are bought every day. You could run your disk duplication and packaging plant at this takt time. But that’s not what I want to talk about.

Takt time = the rate at which you release a new product (version) to users

How often do you put new, valuable features in the hands of your users? Every day? Every week? Every month? Every quarter? Every year?

The logic of slow takt times or how to kill all your Agile teams with one simple decision

Most teams I work with, including Agile teams, have long release cycles. Long by my standards. Some of this is under control of the development team, but the release cycle is often dictated by other concerns. Often, operational teams (systems engineers, DBAs, support) reduce the number of releases.

Operational teams are often stressed, in fire-fighting mode and jerked around as projects miss deadlines and make last-minute changes. To reduce the load and ease the pressure, they reduce the number of releases. Fewer releases means more complex and error-prone releases, as more features are batched up in one release. These releases require more effort and have more issues. Fixing and patching those issues requires more work. Business people, under pressure to generate more value faster push harder to get features out of the door. Corners get cut, features get released under the guise of fixes. More work. The logical reaction is to reduce the number of releases again. Which makes the problem even worse. And so on.

Reducing the number of releases, increasing the overhead of releasing is the perfect way to demoralise and ultimately kill any Agile team. Why should we define short iterations and releases, if it takes so long to get something in production? Why should we collaborate tightly with customers if the software is outdated by the time it gets into the hands of users? Why should we focus on business value if potentially valuable features gather dust in an endless release process? We might as well switch to waterfall.

It doesn’t have to be this way. The first step is to regain the trust of the operational teams: release on time, deliver great quality code, involve operational teams in planning and retrospectives, treat members of operational teams (who are often involved in many projects) as members of your team: listen to them and optimise the whole value stream.

Once we’ve established trust and created one team, we can start to talk about improving and going faster.

Thinking for a Change

Categories

Blogroll

The Importance of Accounting