|
|
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 😉
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.
You’re not done when you have a Definition of Done
Agile coaches and trainers will tell you you need a “Definition of Done“. Everybody needs to understand and agree what it takes to put a User Story in the “Done” column on the team’s board. Does “Done” mean “released to production and used by the end user”? Or does it mean “ready to handed over to another team, who’ll do acceptance testing”? Agile pundits will vigourously debate what Done should mean, but there is no one definitive answer. Each team has to agree on their own definition. My only advice would be to define Done as far as possible in the value stream where you still have control or influence.
(Re)Defining Done has a large impact
In one team, developers called their stories Done when they were given to the integration test team. Unfortunately, most stories didn’t stay Done for long, as the testers invariably found many issues. Most of the time, the “Done” story didn’t even start up in the test environment. To which the developers invariably replied: “But it works on my machine!” 🙂
After making a Team Quality Manifesto, the development team decided to update their definition of Done with “It’s only done when another developer has tested the code on their machine”. In the retrospective of that release the testers remarked that quality had increased enormously: it had become really hard for them to find any bugs.
Changing that Definition of Done had a small, but important psychological effect: the developers didn’t mind that testers, who worked on another floor, in another team, couldn’t get their stories to install or run correctly. Testers are paid to find bugs, aren’t they? However, the developers did mind that their peers found issues in their code. It was just too embarassing, so they made sure that their stories were Really Done.
The Definition of Done is useful. But it’s not enough.
User Story State Transitions
As we work on our User Stories, they go from one column to the next on the board. Each move is a state transition. Each transition has a set of guard conditions that must be satisfied to make the transition.
Shouldn’t we define the other transitions? Would that be helpful?
The definition of everything
I’ve seen teams struggle with “immature stories”: a set of stories is chosen for the iteration or release. The team starts to work on them, but many of them quickly end up in the “Blocked” box, to the frustration of everyone involved. If this happens more often, the team can see if there are common causes for these blockages. Was it because we used a new, unknown or immature technology? Was it because another project, on which we depended, was late? Was our external partner not ready? Were the agreements not clear? Were the people we depended on not available as agreed?
Often, these causes can be grouped in a few clusters and we can quickly determine for each project which of these clusters could endanger that project. For example we can say: for integration projects, the definition of “Ready to be included in Iteration Planning” includes that “a test integration server is available and has been confirmed to work.”
A column on the board is a promise for a conversation
“Oh no, are we going back to phase transitions now? I thought we were doing Agile, not Waterfall!”
Try this at home: ask your team “What are the criteria to move into this column?” Are the criteria clear? Maybe we should clarify them. Do team members disagree in which of two columns we should put a story? Maybe the extra column doesn’t add any value and we can eliminate it. Are there stories that we don’t know where to put? Maybe we should add a new column. Each column, each transition must bring value. What extra information do we have if we move the card from column X to Y? Who uses that information? Which action will you take based on that information. What information do we get from being able to see at a glance how many (or which) cards are in a certain column? For example, if the “Ready for iteration planning” column is empty, we might not have enough stories to fill the next iteration. Shouldn’t someone start to work on that asap?
Start the conversation in your team. You might uncover some issues, simplify your process and make essential information visible.
XP Days Benelux 2009
 The next XP Days Benelux will take place on 23 and 24 November, in Mechelen, Belgium. As usual, this is a great opportunity for everybody’s who’s interested in Agile methods to share information and learn from each other.
Submit a proposal
Presenting a session is a great way to learn. Why don’t you submit a session proposal for XP Days Benelux?
- Do you work in interesting circumstances? If not, what are you doing there?
- Did you learn some new useful tool, technology or method? If not, you should definitely come to XP Days!
- Did you experience some failures? If not, are you taking enough risks? Are you still learning?
- Did you work together with some new and interesting people? If not, you should definitely come to XP Days because that’s filled with interesting people.
Even if you’ve never created and presented a session before, submit a proposal for XP Days. We practice the agile values, so there’s plenty of collaboration, communication and feedback to help you refine your session. It just requires a bit of courage. Or you could ask for a session on a certain subject. That might give someone the idea to create a session for you.
What are you waiting for?
I just submitted a proposal about solving conflicts without compromise together with Jef Cumps.
Did I mention that up to two presenters per session get a free pass to both days of the conference?
See you at the conference!
Operational Excellence AND Customer Intimacy, but not at once
In the previous blog entry, we saw how one company resolved the conflict between operational excellence and customer intimacy. They found a way to have both. But we didn’t implement both at the same time.
We first went for Operational Excellence. First we standardised, made things reliable, made work repeatable, not only in production but also in IT. The existing product definitions were inconsistent and complex. This made our code complex because we had to treat every product as a special case. Over a period of about one year all the product definitions and the code were refactored to new standardised forms. All of this happened while the system was in production and new features were released every two months. We got very good at refactoring and migrating without disrupting because we did it so often, in small steps.
A similar ‘refactoring’ happened on the production floor. Product line by product line was tackled: work cells clearly labeled, clear flow lines from input to output established, work in process limited… When I first went to see the production floor I nearly got lost between the piles of work in process and it was hard to see what was going on. After the changes, the area looked a lot more spacious and it was clear at a glance what was going on.
Once we had the production and development system under control, we started to think about customisation and getting more intimate with our customers.
Effectiveness AND Alignment, but not at once
This reminded of Alan Kelly’s blog entry about the “Alignment Trap“. In summary: we want our IT organisations to be effective (do things right) and aligned with business objectives (do the right things). Unfortunately, most organisations do neither.
If we want an organisation that does the right things and does them right, what strategy should we follow? Based on a study, Alan conjectures that it’s best to focus on effectiveness first, alignment second. First learn to do things right, then do the right things.
Managed and Agile, but not at once
I encounter a similar situation in many coaching and consulting engagements. Organisations want IT teams that are reliable, predictable and can be trusted to deliver as promised. And they also want them to be agile, deliver faster and respond to change. Lean and Agile can get you there.
What’s the first step? Usually, we need to bring things under control, clear away the clutter, reduce chaos, limit task switching, limit work in process and make things visible. This often involves “anti-agile” or “anti-lean” measures such as batching support, analysis and design work to avoid task switching and installing strict change management and issue prioritising to keep focus. I always get lots of complaints and get accused of “not being agile” from people who are used to the chaos and suddenly find that the team no longer asks “How High?” when they yell “JUMP!” Those who stop jumping find that they get a lot more done and that the results are better. They are less stressed.
Once we have the process under control, we can start improving the flow.We know how to do things, we can start to go a bit faster, in smaller steps; we can disrupt the stability to improve a bit. And then we find a new stability and so on.
Heijunka
Heijunka is one of the often forgotten Toyota Way principles. It means “levelling the load”, working at a steady, regular, sustained and sustainable pace. It means planning the work so that there’s a good balance between flow and the load on people and machines.
Large companies who impose just-in-time deliveries to their suppliers without levelling their orders abuse their suppliers. Teams who randomly request clarifications for stories burn out their Product Owner. Teams who push out releases faster than their customers and users can accept them throw away value.
Heijunka means making and keeping work humane.
Which small step can you take to make your work more humane?
|
