Scott Turnquest

 

Ever since the Mingle team started working on its new cloud offering we made a conscious effort to improve our ability to continuously deliver valuable features and enhancements to our production environment. I expected that frequent deployments, tons of automation and lots of learning about Amazon’s AWS would come with the territory - and it did. What I didn’t expect was that I’d end up asking and answering so many questions dealing with when feature X or bug fix Y would be ready for testing and when it would be ready to be promoted to production.

Thumbnail: 

read more

The Scrum Team plans their work in the Sprint Planning meeting and that planned scope (Product Backlog Items) is meant to be respected… it is a commitment by the team.  In exchange for that commitment, the rest of the organization commits to leaving the team alone to focus on its work.  Focus and commitment are both important values of Scrum.  Any interruption to any individual Team Member except the ScrumMaster and Product Owner is considered a cause for relieving the Team of its commitment.  This rule of Scrum is designed to put pressure on the organization to leave the team to focus on the most valuable work.  If the organization allows interruptions to the team’s work during the Sprint, then the team will not meet its commitments and this will diminish trust between the team and its stakeholders.  That lack of trust will lead to onerous control mechanisms that reduce the team’s ability to self-organize which, in turn, will prevent the team from becoming a high-performance team.

In the software industry until the 1980's, programs were developed on a procedural model. This led to extremely complex, unmaintainable solutions. A change to one part of the program usually required changes throughout the program.

This 'tight-coupling' is still pervasive in automotive designs. A change to the suspension requires a change to the chassis, which requires a change to something else, with eventually impacts the designing of the entire car.

Today software developers use "information hiding" and object-oriented design patterns to create loosely coupled, highly modular solutions. So you can change for instance the login process without having to modify other parts of your system.

At the X-Prize competition, many of the competitors dropped out. Why? As it became clear that there would be many entrants, the organizers planned to hold a race on city streets to determine the overall winner. This was changed to a coast-to-coast rally, and finally they settled on a race over a very demanding, closed course racetrack. Each acceptance scenario posted very different demands on the suspension. These changes posed huge challenges for teams that could not embrace change rapidly.

The WIKISPEED car is designed as 8 modules, with simple interfaces between the modules. Due to its modular architecture, WIKISPEED was able to switch suspension systems with a minimum of fuss. WIKISPEED has also discovered it can apply related patterns, like inheritance and code reuse, to its advantage.

Embracing change is a core agile value. The ability to adapt rapidly meant WIKISPEED did better in the X-Prize competition than the nearly 100 entrants who dropped out without producing a car.

How do achieve an object-oriented, modular architecture? The next two principles will help you:

• Test-Driven Development (Red, Green, Refactor)
• Contract-First Design

In the past year (gulp :-) I realize I’ve posted some writing of interest to regular readers of this site.

The ScrumAlliance has started publishing the Agile Atlas – our definition of Scrum. Those who keep score yes this definition agrees with the current Scrum Guide. As part of that it has also started publishing GASPs – Generally Accepted Scrum Practices. I teamed up with Charles Bradley to write User Stories.

ScrumMaster Tales: The Daily Stand-up – another story of John and his team this team as they struggle to make their standup effective.

Promoting Agile in Waterfall Culture: This will probably be the earliest story of John and his team. John’s VP Shawna is under a lot of pressure to deliver. John mentions Scrum and she tells him: “how Scrum is perfect for cowboys and undisciplined teams but it doesn’t work in the real world.” Learn how John recovers.

Used with care, software development estimates can help you manage project risks. They let you peer into the future, though only as well as your current understanding allows. Estimating based on what you know is easy. Estimating based on what you know you don’t know is possible. Allowing for what you don’t know you don’t know is prudent.

Managing risk is a dynamic process. I’ve seen people document a risk in a “Risk Register” document and promptly ignore it. That’s not management. Instead, consider different ways a risk might be reduced in likelihood or consequence. When time or cost is of the essence, think about how you’ll determine what you can afford, and when you need to take a second-choice approach.

I once worked on a project where we had to remove the requirement to log in for viewing certain documents, such as a Form 10K. The system had been built with the assumption that the user would always be logged in, though they could create a login that would give them immediate access to such open documents. A change in SEC ruling meant that the organization would be liable for expensive daily fines if new behavior was not deployed by December 31.

The existing code checked the access rights in numerous places. In some places, a user would be permitted or denied access to the document. In other places, a user might or might not be able to see the existence of a document when they did not have access to the document itself. Access right might be granted on an individual basis, a company basis, or a group basis. There were similar, though slightly more complicated, business rules governing the access required for the documents, themselves.

There were at least two possible approaches. We could patch the logic of each of those places. Or we could refactor to remove the duplication and implement the logic in one area. The latter approach was clearly superior for the long term, but was also more work, touching more code. It was only considered feasible if it could meet the short term deadline. Missing the SEC deadline was not considered a successful outcome.

Estimates predicted the refactoring could be done in time, by a small margin. Work started, in an order that touched one area of functionality at a time. If the estimates proved optimistic, there would still be time to switch approaches as long as we’d left the other areas of functionality untouched and working. The first couple of areas, of course, took longer than later ones. They required the initial implementation of functionality that would be extended and shared by the other areas. By the time these were completed, the safety margin had shrunk. Should we proceed with the refactoring?

Since the these two areas were completed and working, the time needed to patch all of the duplicate logic was now reduced; there were two fewer places to patch. I considered that enough leeway to support continuing with the refactoring. The project manager was nervous. The estimates of the remaining areas looked optimistic to her, given the time the first two had taken. As it turned out, the remaining estimates were a bit pessimistic, and the safety margin started to grow again with each area that was refactored to the new approach. The reduced time to implement and test each remaining area allowed the deadline to be met, and a few customer annoyances to be fixed, as well.

This story has a happy ending, but it’s instructive to look at places where things might have turned out differently. The initial estimates might have shown that there was insufficient time for the refactoring, or that patching the code had little margin for safety, itself. Either of these might have lead to choosing what was considered the simpler, safer approach, patching the code.

This team was not experienced at refactoring legacy code, and might have had difficulty either estimating or performing the refactoring without me. This team would have likely estimated the refactoring very pessimistically, but I’ve seen other teams who were overly optimistic about their ability to refactor an existing code base. Either way, the confidence that the project manager placed in the estimates would likely have been lower. I think she would not have agreed to the refactoring without my confidence, and the ability to double-check the progress along the way.

I was not new to this code. I had been working with it for a few months, and had already made some progress in finding seams to isolate sections for testability. I had put characterization tests around those sections that were substantially unchanged. These tests had proven pretty good at alerting me when I stumbled across a new assumption in the code about which I was ignorant. This knowledge, and the fact that I was finding the code more flexible for new requirements, gave me confidence that I could successfully refactor within the time constraint. Without knowledge of the code base and some past experience developing in it, my estimates would have had a wider margin of error.

The first couple areas had taken longer than I expected. I ran into a few of those unknown assumptions in the code. Had they taken longer than they did, we would have likely switched gears to patching the code. In spite of these estimates having been a bit optimistic, I still felt confident in the remaining estimates. There might still be a few special cases in the access logic, but I now had a module with good test coverage, and had solved an infrastructure problem with testing the database access. If subsequent implementation had not supported my confidence, we still would have switched gears at that point.

When estimates are used for managing risk, they can’t be performed one time and then forgotten. The confidence place in them needs to be examined for flaws in the assumptions. They need to be tested by comparison with actuals. When actuals and estimates disagree, believe the actuals. Consider what that may mean for other estimates. Do they need to be adjusted based on new knowledge or adjusted assumptions?

Estimates are never guarantees. They are, however, a useful tool for achieving the best future we can while minimizing the downside of risk.

Ladies, Please forgive me. I have to make an obvious point with some guys. And you know how guys can be. Sometimes you have to make it really obvious to them.

***

We need to know the BVPs (business value points) and the SPs (Story points) of each story, so that we can do CBA (cost-benefits analysis).  And choose the right story to do next.

Why?

Now I explain the picture.

Many guys who are into cars would prefer a free Maserati.  Truly nice sports car. See the picture.  Wow!  Is that a car or what?  Especially if it is ‘free’. (It also helps that I like really smart brown-haired girls and the color blue, but we won’t go there.  The things I have to suffer through to make a point!)

But it is shocking how many guys will choose a 2 year old used Lexus, if they have to pay for it (the car).  Why?  Just on initial cost, a Maserati costs about $300,000.  I think a 2 year old Lexus is close to $25,000.  Big difference in cost.

And the customers and business managers are the same way with the features in the new product.  If they can see no difference in the cost, of course they want the Maserati feature. But as soon as they can do CBA, even roughly, they start to say….”umm, I think I can live with the used Lexus” feature.

CBA is also a way to convince them to do the right thing. Release earlier. And then the Team looks like a bunch of heros. Rather than suffering a Death March. (I am surprised that that picture could make regular guys turn into heros.  But I think it could be true.)

 

Paul Ellarby

Do less to go faster. In this slideshare we list 10 pointers to help you speed up your agile adoption across your enterprise.

Thumbnail: 

read more

Joseph had been a contract programmer working in web development for several years. The cycle of intense work followed by beach time had left him with little in assets beside the condominium he shared with his wife and daughter, Jane and Wanda. Then he got involved in an agile project. It looked like his involvement would be long-term. He was involved in iteration after iteration. With multiple releases planned, it seemed like it might last a long time. No one knew how long since they had finally convinced their users that the developer’s job was to product quality software, not estimates.

Joseph’s father had taught him that having assets that produced a positive cash flow was the key to wealth in America. He now had enough money for a down payment on another condominium. It needed some work, but Joseph was sure that his high school buddy Clyde could get it ready to rent. Clyde could not tell him how much it would cost or how long it would take, but Joseph knew he could trust Clyde. Besides, producing a quality apartment was much more important than coming up with a plan. Two weeks later, Clyde asked Joseph for $5,000. It was just for the kitchen renovations, including some new appliances. It was more that Joseph had anticipated. He asked around, and people assured him that this was not unreasonable. Joseph has set aside some money for a surprise vacation to Disney World. Fortunately, Joseph and Jane had not told their Wanda about the trip. They decided to postpone it.

Work continued on the apartment. Jane took Wanda to her pediatrician, Helen, for a routine visit. While there, Helen told Jane about her divorce and need for an apartment close to her practice. Jane told her about the condominium. Joseph and Jane showed Helen the apartment which was still under construction. Helen loved the kitchen. She asked when the apartment would be ready and how much the rent would be. Joseph promised to get back to her. Helen would be a dream tenant! They had known her for years and she as a successful doctor.

Joseph explained the situation to Clyde. Clyde reiterated that he did quality work, not estimates. Joseph did not know what to say to Helen. He could not tell here when she could have the apartment. He did not know how much rent would be necessary to cover the mortgage, the renovation expenditures he already made, as well as the expenditures he would still have to make. By the end of the week, Helen called and said that she had taken another apartment. Joseph would have to advertise for another tenant and do the background checks on anyone who applied.

Two weeks later, Joseph got his mortgage bill from the bank. He did not have money to pay it, but he could use the home equity line they had established on their own condominium. Jane would not be happy. He had promised that this would not happen. What was worse, was that he did not know how many more times he might have to go back to this same well. His grab for the American dream was turning into a nightmare.

Joseph gave the situation quite a bit of thought. He came up with three alternatives:

1. He would tell Clyde that doing quality work was not the whole job. Clyde would have to provide a project plan that dovetailed with a financial plan that Joseph could live with. Otherwise, he would hire a contractor that would do this to finish the job.
2. He world hire an expert to look at the existing situation and estimate the time and money required to make the apartment ready to be rented. That expert could also set the rental amount.
3. Joseph would estimate the time and money himself. He did not know which end of a hammer to grab, but he had talked to people and read about the kitchen renovation when he was wondering whether the $5,000 was fair. He could do this for the rest of the job.

What should Joseph do? What should we be doing regarding the estimating of agile projects?

Leaders should stop wastingso much time on meetings. First, the meetings for planning how the team will work. Soon after, the meeting for following up on the previous meetings. Then, the combination of people and meetings just explodes. These innumerous s meetings are the biggest waste for leaders.
Instead, a leader should spend time on the ground with the team. Try to understand and improve processes and how people collaborate. Thus avoidingthe distant management purely based on meetings.
Make the work and the workflow visible. This is a crucial activity for a leader. Say no to the meeting invites. Instead, spend your time working with the team members. Look for ways to make the process (and the team work) more visible. Make information more transparent. Encouragedirect communication. These allows for greater collaboration.
Ask why! Seek to understand what is happening on each workflow step; ask why. Then ask again. Help the team members better understand their work and the reasons behind it. This, plus the visibility will enable them to understand each other, therefore better collaborating towards the common goal.
Time is limited. And you can have a great impact on your team’s work. Say no to ineffective meetings. Instead, spend your time on the ground working with the team.

My previous post showed a working prototype for what I’m now calling SlideChop (huge thanks to Eric Anderson for the name!) Since then, I’ve upgraded things a bit and now have a much more stable, much easier to use version. It no longer requires a NodeJS server, and now works on Mac, Linux and Windows. 

Teensy 3.0

The secret is in the use of a Teensy 3.0 for the controller. This little device is an Arduino compatible micro controller that has a few very specific advantages: it can emulate a mouse, keyboard, joystick or any other native serial communications device, through the hardware itself! All I had to do was write a little bit of C code to handle the click of the physical button, and then call the Mouse.click() method from the Teensy API. Teensy handles the rest for me.

Here are a few images of the Teensy in the hardware setup for the SlideChop:

 

If you want to build a hardware device that acts as a human input device, you really need to look at getting a Teensy. I highly recommend them. Do note that you’ll need to be comfortable with soldering if you want to use one, though. They don’t come with any header pins attached to them. Be sure to buy pins if you don’t have any on hand (and why don’t you? you always need header pins on hand.)

TeensyDuino

Once you have the hardware, you’ll want to write software for it. The easiest way to do this is to use the TeensyDuino plugin for the Arduino IDE. There are command line and other tools available for Teensy, but I prefer the TeensyDuino at this point. It’s easy and it works well. It’s also familiar since I’ve been working with Arduino.

Once you have it installed, you’ll get some extra menu items in the Arduino IDE. Select the “Teensy 3.0″ from the Board type menu, and then select “Keyboard / Mouse / Joystick” from the “USB Type” menu.

 

 

 

 

 

Now the Teensy will emulate a Keyboard / Mouse / Joystick, and you can use the appropriate API for that. There’s no need to include any specific header files or libraries, either. If you have selected the right USB type, then the API is made available without doing anything else.

SlideChop Code

The code for this is available from this repository. It’s fairly simple, but I’m terrible at C code and even worse with run loops. So there are a few bugs in here… most notably is when you hold down the button for a “right click”, it sometimes does a left click as well as a right click. I have no idea why… someone else with better C / run loop skillz can probably school me in this pretty quickly, though.

The Teensy has a built in LED and I’m taking advantage of that. When you plug the SlideChop in to your computer, I blink the LED twice. This tells you that the SlideChop is ready to roll. When you slap the button down, I blink the light. And when you hold the button down for more than a second, I tell the SlideChop to do a right-click and turn the light on for you. This extra little bit of LED goodness is there just to tell you that the code is working. 

Misc Other Stuff

The veggie chopper itself is the cheapest one I could find at my local grocery store. I tore the metal blade out of it and then mounted a standard momentary pushbutton on to the platform that sits between the veggie holder and the blade itself. I used a small perf-board and some female headers to create a slot that the Teensy can mount in to. The button also connects to the board the same way, and I used a 10K resistor to create a pull-down resistor setup for the button. The button is mounted to the plastic platform with silicon and soldered to some wires that create the needed 5v power, ground and signal. These wires are soldered to some male header pins that plug in to the female headers on the board.

The veggie compartment has a hole drilled through it with a rubber grommet silicon’d in place to keep it there. I run the USB cable through this and connect the Teensy to my USB port on my laptop. The Teensy is immediately recognized as a generic human input device. It takes about 10 seconds for a new laptop to configure the driver for this, the first time you plug it in. Then you’re good to go! Start slapping that button to use it as a standard mouse click. Hold the button down for a second and it will right click, too.

The Demo Video

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

In my post on ditching two-phase commits, I introduced the problem of trying to listen and talk at the same time. Essentially, people typically do two-phased commits in messaging systems because they want to deal with messages “exactly once”. But this sort of coordination is hard, and if we want to achieve higher performance/throughput, we need to take a different approach. Luckily, people much smarter than me have already identified ways of dealing with (un)reliable messaging.

Instead of having “exactly once” messaging, a more relaxed and scalable approach would be to do “at least once” messaging. Instead of locking resources everywhere, we can assume that messages will arrive at least once (and maybe twice, three times etc.) Now we have the burden on the client side – how should we deal with these duplicates?

Option 1: Every message is idempotent

Idempotency is by far the easiest way to deal with duplicate messages. There are a couple of different approaches we can take in this option, dealing with them on the client side.

The first way is conditional on our message. If there is a natural idempotency to the outcome of our message, then we really don’t need to do anything special. If our message is to affect state, and doing the same thing twice achieves the same result, then no need to do any sort of special checking:

public void TurnOn()
{
  On = true;
}

If your recipient can process the message multiple times and have the same result every time, we can just rely on that. For objects that represent state machines, or operations that alter state without side effects, this can work quite nicely for us. But what about something that isn’t naturally idempotent?

public void CreditAccount(int amount)
{
  Balance += amount;
}

If I ask to credit this account $1000, and I receive this message twice, my resulting balance is now $2000 higher! Not exactly what I want. A simple approach here would be to attach some sort of correlation identifier to my request (i.e., your checks have a check number):

public void CreditAccount(int amount, string transactionNumber)
{
  if (Transactions.Any(t => t == transactionNumber))
    return;
  
  Balance += amount;
  Transactions.Add(transactionNumber);
}

Now I keep track of the transfer requests, and only process ones that I see are new. This is similar to receiving payment in the form of a check, that might have been both mailed and faxed. The check can only get cashed once, so I just keep track of what checks I’ve cashed on my side to determine if this check is “new” or not.

If I don’t have natural idempotency nor do you have a correlation identifier that you can rely on, you might have to invent one. One approach could be to hash the message coming in and store those (sort of like Git commit hashes). In the transfer case, we might include something like a timestamp to correlate.

If we can’t implement idempotency at the entity level, then our entity can only handle at-most-once messages. When our entities can only handle at-most-once, then something else needs to handle detecting duplicates and tossing out any detected extras.

Option 2: Messages are de-duplicated

If we can’t (or won’t) rely our entities to enforce idempotency, but our messaging infrastructure still allows at-least-once messages, then we’ll need to have someone liaison between the receiving and delivery of messages:

When a message is received, it’s checked against a message store. If the message already appears in our message store, then we can safely discard it. Only when we’ve confirmed that it’s new do we forward the message on to our consumer.

Storing all these messages since the beginning of time can be burdensome, both for general storage and for checking. We might have a garbage collection process that removes messages from our store past a certain expiration, assuming that we never receive duplicates after a certain amount of time. This lets our message store not get unreasonably large.

Another option is to handle de-duplication on the sender side. If the producer sends the message twice because of failures, we might introduce a slight delay in sending messages along the wire:

Instead of sending messages immediately to their destination, we could set them aside in a buffer and delay their actual deliver. If we receive the same message twice in quick succession (for any definition of “quick”), we can prevent duplicates from getting sent in the first place. In this case, we assume that sending to our buffer is highly successful, but sometimes we send the message twice. We tune the buffering period (maybe 10 seconds, maybe an hour) based on our SLAs and so on.

This does introduce delays in getting messages to their intended recipient, so it would take some profiling to see what our buffer times should be. It turns out that this is what Azure provides out of the box.

We might provide a mixture of these two, buffering messages for non-idempotent, non-undoable operations like sending emails, but provide idempotency for the rest.

Of the two approaches, idempotency is the approach that provides the greatest long-term value, as a lot of other problems tend to go away once our system exhibits idempotency. In the messiness of the real world, most of the time us as humans pick the idempotency approach, simply because it’s the least expensive approach with regards to our transport mechanism. If we remove burdens of transactions and such from our transports to our application layer, our transport can be as speedy as possible.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

The Daily Scrum meeting is a critical method for creating transparency between Team Members.  Every day, each Team Member in turn answers the three questions of the Daily Scrum: what tasks have I completed, what tasks will I complete before the next Daily Scrum, and what obstacles do I have to doing my work?  These questions are designed to ensure that all team members know what everyone else is doing regardless of if one or another team member thinks something is “important” to know.  This transparency gives the team a regular rhythm of “Inspect and Adapt”.  Since the Daily Scrum is meant to be short, any discussion of the work should be held until after the Daily Scrum is complete.  To be clear: the Daily Scrum is not meant to be a problem solving meeting and treating it so can lead to people failing to be as transparent as needed (or to breaking the timebox for the Daily Scrum which leads to other problems).

Podcasts are a passion of mine. I love to listen to them, and I love to create them. But, not unlike writing, what I love even more is thinking about creating podcasts. I’m a natural born procrastinator, but I’m recovering. That is why I’ve volunteered to reboot the Xebia Podcast by Serge Beaumont and Robert van Loghem.

The Xebia KnowledgeCast will be a bi-weekly podcast about software architecture, software development, lean/agile, continuous delivery, and big data. Also, we’ll have some fun with stickies!

In this first episode, Guido Schoonheim explains why he has high hopes for the Xebia KnowledgeCast Reboot, before sending me off in search of content.

Then, Jacqueline Evers shares her views on work-life balance. For some reason, a lot of lean/agile coaches seem to suffer from a lack of it. Why is that? And what can you do about it?

Third up is our first regular section in the Xebia KnowledgeCast: Fun With Stickies by Serge Beaumont. In this episode, Serge talks about the ISAS acronym he uses when coaching lean/agile teams. The acronym stands for Identity, Stability, Autonomy, and Scientific.

Then, DevOps guru Mark van Holsteijn explains the gist of his session on On Demand Infrastructures For Continuous Delivery. According to Mark, we need those infrastructures for something like DevOps to really succeed.

Finally, Olav Maassen shares some information about his new book “Commitment,” a graphic novel about Real Options he wrote with Chris Matts and Chris Geary.

The feed is currently being vetted by Apple. Within a few days you’ll probably be able to find the XKC in iTunes and other podcast directories. Can’t wait? Get the feed now!

Your feedback is appreciated. Please leave your comments in the shownotes. Better yet, use the FiRe field recording app from Audiofile Engineering to send in a voicemessage as an aiff, wav, or flac file so we can put you ON the show!

The jingles used in the Xebia KnowledgeCast are made by audionautix.com.

All interviews are recorded in double mono with a Marantz Pro PMD661 recorder using an AKG D230 dynamic mic or a Rode NTG2 condenser mic on a boompole resulting in a 96.0 kHz, 24-bit wav file. The fun with stickies section is recorded using the FiRe field recording app from Audiofile Engineering and transferred through SoundCloud.

Post production is done on a Macbook Pro using LogicPro with a light voice over filter resulting in a 44.1 kHz, 16-bit mp3 file.

I am pleased to announce that starting in June, all my Scrum trainings in Zurich will be held in a more spacious, easier to get to location. More space, better air, easy access to parking and public transportation. Just 10 minutes from the main train station!

The new address is:

• Training Room "Zurich West"
• Hardturmstrasse 181
• 8005 Zurich
• Tram: Zurich, Fischerweg (9 minutes from Sihlquai/HB!)

You can find more information about the Training Room "Zurich West" here. I look forward to meeting my first participants in the Intense CSM Course June 24 & 25! (And if you know someone who wants a Scrum course, please point them to my registration page!)

What happens if an engineer comes up with a way to build a safer car door? Can that new door be deployed right away? No. A stamping machine and a custom made die produce that door. Together they cost over 10 million US dollars and they must first be amortized before the new door can be economically produced. Given the high costs, it can take 10 years or more before that better door can enter production. You can see the impact of the need to amortize huge investments in the slow, incremental changes in automobiles from year to year, even from decade to decade!

WIKISPEED can change their design every seven days. They employ tools like value stream mapping not merely to reduce the variance of products produced or to optimize the flow through the production line, but first and foremost to reduce the cost of change. It does not cost them more to use a new design than to use an existing design. So if they have a safer way to build the door today, they start using it next week.

Welcoming and responding to change represent core Agile values and principles (see the Agile Manifesto and the Principles behind the Agile Manifesto). So by adopting this principle, you take a huge step towards becoming an Agile organization.

Tomorrow: Object-Oriented, Modular Architecture

The 10 Principles of Extreme Manufacturing

In 2008, Joe Justice responded to a challenge from the X-Prize competition to create a road-legal 100mpg automobile. Despite having little time, hardly any budget, competition from over 100 well-funded competitors from companies and universities around the world, and changing requirements from the awards committee, his company's WIKISPEED entry placed 10th in the Mainstream class. Joe not only created a great car, he also developed an Agile approach to creating physical products.

As a software developer, Joe was an "Agile native." He had only worked with methods like Scrum and Extreme Programming, so his engineering practices drew heavily on his software experience. Today, WIKISPEED is selling prototypes, and the WIKISPEED approach to manufacturing is turning heads worldwide at companies like Boeing and John Deere. "Our technology is more sophisticated than yours, but your culture is light-years ahead of ours!"

Joe calls his approach "Extreme Manufacturing." XM emphasizes the ability to create products quickly and integrate changes rapidly into existing products. XM is collection of principles and patterns to help you create and adapt products quickly.

I had the honor of co-teaching a CSM + Extreme Manufacturing course with Joe last week, and with his encouragement, this series of articles seeks to refine, document and publish those principles:

1. Optimize for change
2. Object-Oriented, Modular Architecture
3. Test Driven Development (Red, Green, Refactor)
4. Contract-First Design
5. Iterate the Design
6. Hardware Design Patterns
7. Continuous Integration Development
8. Continuous Deployment Development
9. Scaling Patterns
10. Partner Patterns

These principles and patterns do not represent the final wisdom on Agile manufacturing, but rather a work-in-progress, on the discovery of better ways to manufacture things.

I plan to publish an article on each of the 10 Principles of Extreme Manufacturing, every day for the next two weeks.

Let start: XM Principle 1: Optimize for change

Viele Unternehmen, gerade auch High Performance Unternehmen, sind heute vernetzt strukturiert. Sie  haben schlankere Hierarchien und arbeiten verstärkt mit unterschiedlichen Formen der Projekt- und Teamarbeit. Die Hierarchien gewinnen eine neue und andersartige, oft geringere Bedeutung. Die klassische Führung mit ihrer starken Betonung des heldenhaften Einzelkämpfers an der Spitze mit seiner  “Alle mir nach”-Attitüde hat sich abgenutzt und ist auch als Modell wenig sinnvoll für selbstorganisierte Teams. Oft wird dieser Widerspruch thematisiert im Sinne von “Wir da unten sollen als Team zusammenarbeiten, aber die da oben sind lauter Einzelkämpfer” (und oft in deutlich wahrnehmbarer Konkurrenz zu einander). Gerade für die Führung agiler Unternehmen (aber nicht nur für diese) ist die Installation von Führungsteams eine effektive Alternative. Führungsteams sind kollektive Steuerungs- und Entscheidungsfunktionen in Unternehmen. Sie verteilen Macht, Kompetenz und Verantwortung auf mehrere Schultern. Trotzdem wird dem Führungsteam im Management aus einer tradierten Vorstellung von Führung heraus immer noch mit einer gewissen Skepsis begegnet und/oder man belässt es bei schnell durchschaubaren Lippenbekenntnissen. Dabei bietet diese Führungskonstellation durchaus höchst überlegenswerte Möglichkeiten.

Führungsteams können

• wie andere Teams auch den Synergieeffekt von kooperativer Teamarbeit nutzen.
• das Risiko von Entscheidungen minimieren.
• die Reduzierung von Komplexität besser steuern.
• ein höheres Maß an Kreativität und Innovationskraft generieren
• entwickelte Strategien und Maßnahmen wirkungsvoller umsetzen.
• eine breitere Akzeptanz vom Führungsentscheidungen nach unten bewirken.
• mehr und schnelleren Konsens bei Veränderungen erreichen.
• ein höheres Maß an Vertrauen bei den Mitarbeitern aufbauen.
• nach außen, z.B. an Schnittstellen, mehr Durchschlagskraft entwickeln.

Führungsteams bewegen sich in der Regel weit mehr als Mitarbeiterteams in einem Spannungsfeld zwischen Individualität und Kooperation, zwischen persönlicher und geteilter Verantwortung. Daraus ergeben sich Problemfelder, die es zu beachten gilt:

• Grundsätzlich das Beibehalten/Zurückfallen in gewohnte Muster als Einzelkämpfer
• Dominanzverhalten einzelner trotz guten Willens
• Individuelles Beharren auf der eigenen Meinung, bis hin zu narzisstischen Phänomenen
• Mangelnde Unterordnung unter gemeinsame Entscheidungen und Commitments
• Konflikte aus dem Widerspruch zwischen dem eigenen Verantwortungsbereich und dem Ganzen
• Zu wenig Zeit bzw. Aufmerksamkeit für die Selbstorganisation als Führungsteam
• Zu viel taktisches Verhalten, z. B. zu schnelle Commitments aus taktischen Erwägungen
• Schmoren im eigenen Saft, zu wenig Feedback von außen
  • Flucht nach außen einzelner Teammitglieder, bis hin zu Illoyalität

Grundsätzlich gilt, dass Teams, welcher Art auch immer, nicht per se bessere Leistungen bringen als einzelne Spezialisten. Vielmehr braucht Teamarbeit spezifische Bedingungen, um den allseits gewünschten Synergieeffekt im Sinne von Effektivität und Effizienz leisten zu können:

• Zeit zur Einübung teamorientierter Einstellungen und Verhaltensweisen. z.B. Zeit und Willen für Teambuilding und Teamentwicklungsprozesse
• Bewussten Konsens und ausgeprägten Teamspirit – “wir sind ein Team”
• Klare Rollen und Zuordnung von Verantwortlichkeiten
• Eindeutig akzeptierte interne Führung sei sie disziplinarisch oder lateral
• Konsensfindung bei Entscheidungen, Disziplin im Umgang  mit Vereinbarungen
• Bereitschaft zu Konflikten und die Fähigkeit, sie gemeinsam zu lösen
• Akzeptanz von Heterogenität und Unterschiedlichkeit und den Willen, gerade dies gezielt im Sinne von Synergie zu nutzen
• Effektive Meetingstrukturen, Meetingkultur und Zeitmanagement
• Hohes Maß an interner Transparenz und dialogischer Kommunikation
• Immer wieder Feedback von innen und von außen, von oben und unten (Retrospektiven)
• Informelle Beziehungspflege durch Maßnahmen außerhalb des reinen Arbeitskontexts

Führungsteams sind zweifellos  eine wirkungsvolle, aktuelle Alternative zu klassischen Formen der Führung für Unternehmen. Aus meiner Erfahrung als Moderator und Entwickler diverser Führungsteams konnte ich erkennen, dass dort, wo Führungsteams optimal kooperieren und ihre Führungsaufgabe gemeinsam bewältigen, auch die gemeinsame Erfolgswahrnehmung hoch ist. Vor allem aber ist persönliche Zufriedenheit, Gelassenheit und Motivation bei den Führungskräften in der Regel ausgeprägter vorhanden und wahrnehmbar. Auch die Rückmeldungen von kollektiv geführten Mitarbeitern deuten auf eine verbesserte sachliche Arbeitssituation und ein angenehmeres Miteinander hin, diese positive Wirkung nach unten ist sehr hoch einzuschätzen.

In der Regel geht die Initiative zukünftig als Führungsteam zu agieren von der ranghöchsten Position im System aus. Hier kann man CEO, CTO, Bereichs- und Abteilungsleitern nur genug Mut wünschen, sich darauf einzulassen, ein Führungsteam zu kreieren. In einem gut gestalteten Teamentwicklungsprozess kann in den meisten Fällen dann auch die evtl. noch vorhandene Skepsis des einen oder anderen Führungsteammitgliedes gezielt bearbeitet und abgebaut werden.

Related posts:

1. Führung in Scrum | der Manager | Teil 1
2. Führung in Scrum | Manager | Teil 4
3. Führung und Teams | Die deutsche Nationalmannschaft | Euro 2008

I love the attitude behind this letter to the editor from The Times earlier this week:

Sir, Ben Macintyre says that attempts prior to 1953 were "each a chapter in the long and glorious narrative of heroic British failure". This is unfair. Previous attempts brought new knowledge of routes, clothing, equipment and mountain leadership. This knowledge was bought at a cost of lives. It all increased by increments until brought together 60 years ago. The summit area was and still is known as the death zone.

I. H. Cairns,Perth

I've been spending a lot of time recently working with our UX guys. I've enjoyed it and I've come to appreciate the work they do. I have a reasonable idea of the techniques they use but have a natural flair for their kind of work.

However ... I think I've found an analogy which helps me understand why EXPERIENCE is sometimes so important.

The analogy came to me last week when it was (atypically) sunny during lunch time and I decided to go for a walk around Stockbridge, which is about 5 minutes from my office in Edinburgh. When I got there I bought a delicious Parma ham, pesto and goats cheese roll from Peters Yard bakery then crossed the road to find a place to eat it. I considered walking up one cobble-stoned street, which was familiar for some reason, but then decided not to. I wasn't sure why, at first, but then I remembered that was the street I went to to have my vasectomy.

Yikes.

Here's the experience bit: NEVER PUT A VASECTOMY CLINIC ON A COBBLE-STONED STREET.

The drive there is okay; the drive home is not.

 

Continuing with the 100 Things You Must Know to Be Effective In Software Development This blog is also in preparation for a webinar I am doing this Wednesday called: How to Start an Agile Implementation. I wrote a blog about a year ago called Why Scrum Works and How This Tells Us When It Won’t it was a follow up to a blog now more than 6 years old Challenging why (not if) Scrum works. I have...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]