content top

eXtreme Manufacturing

eXtreme Manufacturing

The term eXtreme Manufacturing (XM) was coined by Team WIKISPEED, a non-profit car manufacturer, to describe how it manufactures automobiles combining the Scrum framework, Object-Oriented architecture and eXtreme Programming (XP). Blending these three practices, WIKISPEED invented a new manufacturing process that can shorten time-to-market, reduce labor costs and spur innovation.

eXtreme Manufacturing borrows the basic Agile principles from Scrum. First and foremost, it leverages small, cross-functional Teams, which have a Product Owner and Scrum Master. XM is structured around Sprints to help develop functionality in vertical slices that build overtime. Like Scrum, XM makes development transparent through tools like a Scrum board and a product backlog. It also borrows the concept of tracking process improvements by using Velocity. And, most importantly, it relies on the Lean concept of continuous improvement by employing Sprint Retrospectives and the Happiness Metric. Scrum provides the basic structure for XM.

In this hour long online course, Scrum inventor Jeff Sutherland and WikiSpeed founder Joe Justice discuss eXtreme Manufacturing and how you can implement test-driven hardware development using the Scrum framework. 

 Scrum Inc.’s online courses are eligible for Scrum Alliance SEUs and PMI PDUs. See FAQ for details.

Download Extreme Manufacturing Slides

eXtreme Programming (XP) 

Scrum has adopted many best practices from XP and so does XM. Writing Product Backlog Items in User Story form helps develop products from an end-user perspective. This is particularly useful because XM designs and builds product on a per/contract basis. This helps create more customer-centric products so building a product based on the perspective of the person who will be using the product increases value.

XM also borrows pairing from XP: two people work together on every job. This allows a small team to swarm on a particular task, while cross-training employees and building quality control into the manufacturing process. Pairing also reduces dependency on different skill sets.

XM uses Test Driven Development, or TDD, to dramatically speed up time-to-market and lower development costs. Team WIKISPEED for example used real-time crash test data to build a computer program that simulates an actual crash test. They were able to save millions of dollars in crash tests by simulating them each Sprint. After a number of Sprints accumulating data, WIKISPEED pays for another physical test. The new information is then used to up-date the computer simulation. This lowers material costs since WIKISPEED doesn’t have to destroy a car each time they want to test it and it reduces production costs because crash tests are expensive.

Object Oriented Architecture

Modularity allows for innovative design while building on iterative development. For example, Team WIKISPEED uses modularity for all its components. That allows the team to re-design the suspension system, speedometer or car body at any point and not have to tweak the chassis or dashboard to make the improved components fit. Modularity prevents engineering challenges from rippling through the entire design process. It also allows the team to swarm on the most important improvement without affecting the rest of the car.

Contract First Design: As manufacturing matures, more and more customers are insisting on custom designs. XM embraces customization before the manufacturing process even starts. For example, WIKISPEED takes only custom orders of its commuter cars and is able to easily meet each customer’s need because of the car’s modularity.

XM leverages Design Patterns in two ways: 1) by re-using mature designs with a proven track record and 2) by reducing complexity. Basically, XM doesn’t try to reinvent the wheel. The idea is to take advantage of established technology and techniques to reduce costs of designing specialty parts.

WIKISPEED has incorporated design patterns in a number of ways but there are two clear examples: modularity and inheritance. Modularity we mentioned above. By keeping the same interfaces between all the modules, the team can increase or reduce complexity in any given module without affecting another.

Inheritance is the idea of benefiting from established techniques and technology. WIKISPEED, in its quest to achieve 100mpg didn’t invent a new highbred engine; they used a very established, efficient engine (40mpg) and then reduced weight and aerodynamic drag to cut fuel consumption in half (80mpg.) Just by using less weight, a sleeker design and piggybacking on an established engine they achieved 80% of their goal. To get the remaining 20% they re-tooled some of the engine’s software to get the car to pulse-and-glide. Pulse-and-glide is a hyper-efficient driving technique that increases fuel efficiency. WIKISPEED just automated what is essentially a manual process. No fancy new engine, just good old fashion engineering.

Patterns: 

Happiness Metric

 

Scrumming the Scrum

 

The Scrum Pattern Language of Programing : The PLoP movement codifies well know Agile practices that have been successfully implemented many times.

Scrum Inc. offers XM Build Parties for corporations and events. Participants build a car from the ground up in 60-minute Sprints. Guided by professional coaches, it’s an inspirational experience that leaves participants confident about conquering their work using Scrum. Because attendees apply the Scrum framework and eXteme Manufacturing to solve complex problems, build parties are a terrific way to win buy-in about agile practices.


Sign up for a Prime Membership to get access to all online courses.

Back to All Topics


Read More

The Scrum Team

The Scrum Team

The Scrum Team is made up of the people who actually work on Product Backlog Items during a Sprint. In a software context, this group is most often called the Development Team. In other contexts, the simple term Team is often used. The Scrum Master and the Product Owner, while part of the overall Scrum Team, may or may not be members of the Team working on PBIs. There is no Project Manager or Team Lead in Scrum. Everyone is simply an equal member of the Team.

 

In the original Harvard Business Review paper that inspired the creation of Scrum, “The New New Product Development Game,” Professors Hirotaka Takeuchi and Ikujiro Nonaka observed great teams were:

1. Transcendent: They have a sense of purpose beyond the ordinary. This self-realized goal allows them to move beyond the ordinary into the extraordinary. In a very real way the very decision to not be average, but to be great, changes the way they view themselves and what they’re capable of.

2. Autonomous: The teams are self-organizing and self-managing, they have the power to make their own decisions about how they do their jobs, and are empowered to make those decisions stick.

3. Cross-Functional: The teams have all the skills needed to complete the project. Planning, design, production, sales, distribution. And those skills feed and reinforce each other. As one team member that designed a revolutionary new camera for Canon described it: “When all the team members are located in one large room, someone’s information becomes yours, without even trying. You then start thinking in terms of what’s best or second best for the group at large and not only where you stand.”

People sometimes struggle with the idea of transcendence. Transcendence is the spirit of the team. The first Scrum team watched a video at the beginning of each Daily Meeting of New Zealand’s All Blacks rugby team. The energy from that team is palpable. They are united in purpose. The first Scrum team wanted to capture that spirit: the determination to crush any impediment; the spirit to celebrate every success; the goal of victory. That is team transcendence, whether on a sports team or delivering great products or services.

In the early 1990s Jim Coplien was invited to assess a project at the Borland Software Corporation. They were making a new spreadsheet program called Quattro Pro for Windows. The software had more than one million lines of code, took thirty-one months, and a team of eight people. That means each team member produced one thousand lines of code every week. That’s more code in less time than any team on record. (See Coplien’s paper in the Papers and Patterns tab.)

To figure out why the Borland team was so fast, Coplien mapped all the communication flows within the team—who was talking to whom, where information was flowing, and where it was not. This type of mapping is a classic tool that can be used to spot bottlenecks or information hoarders. The greater the communication saturation—the more everyone knows everything—the faster the team. Basically, the metric spun off by this type of analysis measures how well everyone knows what they need to know to get their work done. The Borland team still has the highest rating ever: 90 percent. Most companies hover around 20 percent.

What cripples communication saturation is specialization—the number of roles and titles in a group. If people have a specific title, they tend to do only tasks that match for that title. And to protect the power of that role, they tend to hold on to specialized knowledge. That is why Scrum only has three roles: a person is either a member of the Team, the Scrum Master, or the Product Owner. This can be difficult for traditional organizations, but it is critical to get the kind of productivity increases that Scrum can deliver.

Just as the number of roles impacts performance, the sheer number of people on a Team also has a dramatic effect. The Team dynamic only works well in small teams. The classic formulation is seven people, plus or minus two, though the fastest teams usually hover around five. What’s fascinating is that the data shows that if there are more than nine people on a team Velocity actually slows down. Surprisingly, more resources actually make Teams slower.

In software development there’s a term called Brooks’ Law. Fred Brooks first coined it in his seminal 1975 book The Mythical Man-Month. Put simply, Brooks’ Law states “adding manpower to a late software project makes it later.” This has been borne out in study after study. Lawrence Putnam, a legendary figure in software development, made it his life’s work to study how long things take to make and why. His work kept showing that projects with twenty or more people on them used more effort than those with five or fewer. Not just a little bit, but a lot. A large team would take about five times the number of hours that a small team would. He saw this again and again, and in the mid-1990s he decided to do a broad-based study to determine what the right team size is. So he looked at 491 medium-size projects at hundreds of different companies. These were all projects that required new products or features to be created, not a repurposing of old versions. He divided the projects by team size and noticed something right away. Once the teams grew larger than eight, they took dramatically longer to get things done. Groups made up of three to seven people required about 25 percent of the effort of groups of nine to twenty to get the same amount of work done. This result recurred over hundreds and hundreds of projects. That large teams accomplish less than small teams do seems to be an ironclad rule of human nature. (See Slides tab.)

Too often there are tasks that only one person on the Team can do. This is common among beginning Scrum Teams. It needs to be addressed as quickly as possible. The reason is that if only one person can do the work, and that person is unavailable, the whole team grinds to a halt. People get sick, people change jobs; you can’t afford to have your organization held hostage by one skill set.

Good Scrum teams make sure that at least two people, and ideally more, can do any one job. The teams that solve this problem tend to increase their Velocity. The reason is that collective knowledge, not individual skill, is what improves team speed. Individuals can falter, yet if the rest of the team can carry on, their productivity doesn’t suffer.

Perhaps the best way to make sure your team isn’t limited is through pairing and cross-training. If there is only one person that can do a task, make sure the next time that task comes up they pair with someone while doing it so that person can learn. Encourage all of your people to cross-train in various skill sets, not only will you reap the benefits, but they will be more engaged and excited as they learn new skills.

Papers:

Borland Paper on Teams 

Patterns:

Autonomous Team

 

Stable Team

 

The Scrum Pattern Language of Programing: The PLoP movement codifies well know Agile practices that have been successfully implemented many times.
 
 

Next Suggested Topic: Scrum Master    

Back to the Framework 


Read More

Scrum Master

Scrum Master

The Scrum Master is tasked with making Scrum work. They work intimately with the Team, sometimes as a member. Their primary task is to remove Impediments and guide the team in Scrum practices. The Scrum Master does whatever it takes to help the team succeed.

Scrum Masters are servant-leaders not managers. They play the pivotal role of making sure Scrum is practiced well. The Scrum Master is accountable for the Velocity and the Continuous Improvement of the Team.

The Scrum Master accelerates the Team’s Velocity by:

  • Removing impediments
  • Surfacing and implementing process improvements
  • Ensuring theTeam understands and adheres to best Scrum practices
  • Facilitating the Scrum ceremonies
  • Coaching the Team to self-organize and self-manage
  • Making sure the Team is cross-functional
  • Keeping the Team focused on a transcendent goal
  • Assisting the Product Owner to refine a ready backlog
  • Representing the Team to the rest of the organization
  • Protecting the Team from interruptions
  • Keeping Team morale high

Persistence

Persistent people achieve success by continuing forward even when things are difficult.

Drive

Driven people are self-motivated and push themselves hard to achieve what they want.

Service

People with a strong sense of service are constantly looking for ways to serve and help.

Listener

Good Listeners are able to listen intently to what people say and help people feel heard.

Catalyst

Catalysts motivate and inspire others to make things happen.

Enabler

Enablers create the conditions for people to grow and develop for themselves.  Courageous people don’t let their fears dictate their actions.

Patterns: 

Scrum Master  

The Scrum Pattern Language of Programming codifies well known Agile practices that have been successfully implemented many times.

Next Suggested Topic: Product Owner

Back to the Framework | All Topics


Read More

Backlog Item (PBI)

Backlog Item (PBI)

Product Backlog Items (PBIs) are the elements that make up the Product Backlog. They can range from specifications and requirements, to use cases, epics, User Stories, or even bugs and chores. Each PBI must have these qualities:

  • Description: What the goal of the PBI is.
  • Value: he Business Value of the PBI as determined by the Product Owner.
  • Estimate: the Team needs to estimate the relative effort it will take to move the PBI to Done.
  • Order: The Product Owner needs to prioritize PBIs by their relative value.

Together these qualities make up the Definition of Ready. Having a ready Backlog can double a Team’s Velocity. Ideally, PBIs reflect the needs of customers or stakeholders. A common way to incorporate the end users’ needs is to write the PBI in the form of a User Story.

Back to the Framework 


Read More
content top