A pattern is an old idea. A pattern is simple way to represent implicit knowledge about well-known solutions to well-known problems. Patterns were pioneered in architecture by Christopher Alexander to facilitate the understanding of good solutions to common challenges in building houses and other structures. Software developers picked up on the idea to communicate solutions to typical challenges in computer systems. WIKISPEED has identified a number of patterns to help design good hardware. For example:

1. Wrapper – Use a wrapper to adapt a third party part to your contract. If you use the supplier's interface as your contractual interface, any change in either product or supplier will probably cause you to redesign the interface, a potentially expensive undertaking.
2. Facade – Use a façade, a connector of connectors with a simple interface, whenever multiple wires (like data & power) need to go to the same place.
3. Singleton – Every component needs power, data and ground. The first thing every engineer wants to create when designing a new component is the power, data and ground bus. The singleton pattern says for each basis component, there is just one in use. So if you need a power-data-ground bus - use ours!

Sometimes the patterns have a cost. The wrapper pattern added 8 kg to the weight of a WIKISPEED car, for example by adding an extra slab of aluminum between the chassis and the suspension.

Was the design pattern worth the extra weight? Yes, because that pattern allowed Team WIKISPEED to a) reduce several hundred pounds from the weight of the car by steady optimization, and b) react easily and cheaply to the changing suspension requirements. Had they not been able to do that, they would not have been able to participate in the final selection round.

Next: Continuous Integration Development

One frequently asked question for hardware or embedded projects considering Scrum is, "How can we get stuff done every sprint? It takes longer to develop a piece of hardware than could ever fit in a two-week sprint!" Hardware development needs to take a slightly different view on iterations and iterating than software development.

When the WIKISPEED engineers were first working on the interior, they realized that the lack of an emergency brake was slowing down their progress. The brake handle sits between the seats, close to the gearshift and to the attach points for the seats and seat belts. Because no one knew what the emergency brake handle looked like, they were unwilling to commit to design decisions on these nearby components.

The solution was "version 0.01" of the emergency brake: a cardboard box that said, “the brake handle will fit in this box.” That was enough functionality that the team could move forward on nearby components, even though nobody had any illusions that this cardboard box would actually hold the car in place!

When working with hardware, you will iterate on your designs:

1. Create the test that your design should pass.
2. Create the simplest design possible that enables the test to pass.
3. Improve the design to be simpler or more elegant.
4. Repeat this process ("Iterate on the design") until improving this component is no longer the highest value work you can do.

In the case of v0.01 of the emergency brake, the acceptance test was "Can the engineers design the surrounding components with confidence?" The cardboard box satisfied this test. Other components were judged to be of higher value, so they stayed with the cardboard box until the other components were finished enough.

When developing software with Agile, each iteration should produce potentially deliverable functionality. That may not be possible when working with hardware, so you may need to iterate on a particular item many times before the design is satisfactory. In the case of the WIKISPEED X-Prize entrant, those subsequent iterations included, "An emergency brake to hold the car in place," and "An emergency brake which produces no resistance when the car is in motion."

You may also need to iterate on your acceptance tests, especially as you strive to automate them. Before WIKISPEED performed a real crash test, they had done many Finite Element simulations. These are cheap and repeatable, because all they need is computer time. Then they had a real crash test performed. That crash produced results that were different from their simulation, so they iterated. They used the real crash data to improve their simulation. Eventually their simulations became close enough to reality that they no longer needed the expensive physical tests.

Next: Hardware Design Patterns

The initial design decision of the WIKISPEED car was that it should consist of eight modules – body, chassis, motor, suspension, interior, etc. Before Team WIKISPEED even started to design individual components, they designed the interfaces between those modules.

Joe did not know what suspension would be used on his car, but he was able identify the external parameters and boundary conditions of the suspension. After researching the subject, he found that that if the suspension mounting could withstand 8 gees, it would more than meet all the necessary requirements, even for Formula One racing applications. So the team identified a suitably sized block of aluminum that could carry that load. Any suspension that could be attached to that block could be used on the WIKISPEED car without modification to the rest of the car.

So when designing a solution,

• Design the interfaces based on outside parameters, e.g. load factors, or communication and power requirements.
• Only architect the connections up front, not the individual components.
• Leave room to grow, i.e. over engineer these interfaces, because changing these fundamental contracts may be expensive.

P.S. Be sure to check out the Wrapper pattern to ensure independence between your design and the design of any component suppliers.

Next: Iterate the Design

...also known as "red, green, refactor"

Before Joe started building a car, he created a model for predicting fuel economy. He identified over 100 well known, freely available parameters, like weight, drag coefficients, engine power, tire size, etc. Based on these parameters he could predict the EPA fuel economy of the car within a few percent.

Armed with this model, he was able to calculate the characteristics the WIKISPEED entrant must have in order to achieve not only 100 miles per gallon, but also to achieve performance characteristics worthy of a high-end sports car.

Team WIKISPEED wanted to achieve five-star crashworthiness according to the specifications of the NHTSA and IIHS. These specify impacts under multiple conditions to evaluate the crashworthiness of the cars. These tests are quite expensive, US$10'000 per test, plus the costs of the vehicle itself, transport and disposal of the test vehicle and the travel costs for the people involved. How can they update their designs every week, when each change requires retesting?

Step one was to use Finite Element Analysis to simulate the crashes. When they believed their car would pass the test, they ran an actual test. Of course they did not pass the test, but that was not the purpose. They wanted real crash data so they could better model crashes in their simulations. They updated their simulations based on the actual crash data. After a few iterations, their simulations became so good, that the authorities now accept the results of their simulations in lieu of actual tests. Since they can now do (almost) fully automated tests, they can simulate crash tests every week.

When designing new components,

1. Create the test it is expected to pass. That can be very high level, like emissions tests or crash standards, or it might be more component level. If it is possible to automate the test (or create an automated proxy for the test), do so, as this reduces the cost of repeating the test after future design changes.
2. Create the simplest design possible that enables the test to pass.
3. Iterate on the design, improving it until it is more valuable to work on another portion of the product.

In software, this process is known as "Red-Green-Refactor." To implement something, first create a test, which by definition fails immediately ("goes red"). Then implement functionality to make it pass (go green). Then improve the design for better maintainability, efficiency, etc. This is called refactoring.

Next: Contract First Design

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

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

with Joe Justice &Peter Stevens Scrum beyond Software: Applying Scrum to Manufacturing and Management. Joe Justice with
WIKISPEED 100mpg Prototype Are you enjoying what Scrum Project Management is doing for your software delivery teams? How about sharing some of that success with your sales, marketing, and public relations staff, and your HR, legal, and finance teams? And your hardware development and manufacturing managers?

Learn all about how your entire company can achieve 10x typical  velocities with Peter Stevens, the pioneer of Scrum in Switzerland, and Joe Justice, the founder of Team WIKISPEED. Join us for a special event in Zurich:

May 28 and 29: Certified ScrumMaster Training for Management and Beyond

Read the detailed information (here)!
Sign up for the course (here)
And be sure to join us for a beer on Thursday to talk about WIKISPEED, Stoos and Making the whole company Agile... (find out more here)

I have long published upcoming Scrum Breakfasts either on my blog or in my newsletter. As the community gets bigger, it is hard to keep track of what is happening. So I will now publish here everything I am aware of. If it proves to be a popular feature, I will expand on it, maybe make a real calendar...

Do have an event which belongs here? Let me know by submitting your event here.


Updated on April 22, 2013

Want your event on this list? Click here.
Lean Startup
Zurich - 22.4.2013 TBD:
discuss how to Build your MVP Register
map swissICT Scrum Breakfast
Bern - 24.4.2013 Ralph Jocham:
Agile Portfolio-based Release Trains Register
map Stoos Network
Zurich - 25.4.2013 Kurt Schär:
Gegensätze als Erfolgsfaktor Register
map swissICT Scrum Breakfast
Zurich - 8.5.2013 Jiri Lundak:
Einmal agil, für immer agil? Register
map swissICT Scrum Breakfast
Basel - 15.5.2013 Rainer Hiss:
Projekt-Priorisierung auf Basis eines Kanban-orientierten Pipeline Boards Register
map swissICT Scrum Breakfast
Lucerne - 16.5.2013 Philipp Engstler:
Agil surfen - eine Organisation reitet die Welle Register
map
Want your event on this list? Click here.

My last customer event was to inaugurate my training room last October. It's time for another one!

Joe Justice will be in town this May to co-teach our CSM Course: Scrum in Management and Manufacturing (sign-up for the course here).

After the course, we will have a free public event.

Besides networking, Joe & I will talk about WIKISPEED, Stoos, applying Agile values to the rest of the organization, and the importance of beer in changing the world.

Space is limited, and we look forward to seeing you!

Here are the details:

• What: An evening with Joe and Peter on WIKISPEED, Stoos, Agile in the Organization, and Beer
• When: May 30, 2013
• Where: Training Room "zum Talgarten", Am Wasser 94, 8049 Zurich
• Doors open - 18.30
• Presentation - 19.30 or so
• Doors close - whenever 
• Admission is free but space is limited. Registration is required. If you register please come. If you can't come, please cancel. We request a donation of CHF 10.-- or more for project WIKISPEED.

Update: The event was a great success! Here is participants feedback, created by eebee:

Back in 2008, I started the Scrum Breakfast community and quickly saw that it needed a home in the Swiss IT community. In 2009, the swissICT became that home in what became known as the the Lean Agile Scrum working group. The swissICT has been a great home -- Scrum, Agile, Lean and related practices have thrived! Today, a core team of 25 people organize five monthly breakfasts throughout Switzerland and a major conference once per year! (see swissICT event program)

I am pleased to announce a cooperation between my company and the swissICT. All swissICT members qualify for a 20% discount off the early-bird price to all my Certified Scrum courses in Zürich. Just include the discount code LAS-swissICT in your registration. (jump to the Scrum course program).