Industrial Agile

How To Manage Trade-Offs In Design

How To Manage Trade-Offs In Design

Budgets: It’s Not Just Money That Is Scarce

By Hubert Smits

The Hyperloop, a high-speed transportation system initially proposed by SpaceX and Tesla CEO Elon Musk, is one of the most exciting technological propositions in recent history. To accelerate its development, SpaceX announced an open competition for engineering teams to design their own Hyperloop pods to compete on a test track in 2016. Formed on social media site reddit, rLoop is the only non-student team to reach the final stage of the competition.

Recently, I had the incredible opportunity to work with these dynamic, brilliant and very dedicated volunteers.

The Challenge:

The rLoop team wondered whether all their parts would fit into the available space of the pod. For example, extra batteries would make it easier to design magnets and brakes, but they add weight and take up space. Stronger magnets produce more heat, which is difficult to get rid of in a vacuum. The challenge was how to handle the trade-offs needed in this situation.

The Solution:

My proposal was to treat the scarce resources like money: lay out a budget for the use of a resource. With 100Ah of electricity available for all the power consuming parts inside of the pod, decisions had to be made: 40Ah to levitation, 30Ah to braking, 20Ah to logic, 10Ah to spare.

Just like in your household budget, you can shift allocation. For example, less money for vacation, more for the new car. In the rLoop environment, it may be more power for levitation, less for braking. Some of those trade-offs are needed. The magnets may not be able to lift the weight of the pod, so something has to give (like you give up your vacation when the car breaks down). Others might enable more elaborate solutions. Teams can negotiate and haggle about the use of the budget. Ever done that with your family members?

The trade-offs are more complex than your household budget because different budgets influence each other. For example, the need for more power may dictate bigger batteries, which influences the weight budget. Now negotiating a power budget becomes more difficult: more teams are involved and more factors need to be taken care of.

Just like other reports in Scrum (Burn-down and Burn-up charts), the main goal of managing the budget is to give warnings when a budget is challenged. The Scrum Master can issue the warning and the team has to find a solution.

Here are some photos I took while working with the rLoop team:

This is the brake system this team developed from scratch. It is one one of the reasons they were recognized with the Innovation Award.
This tube is the model required for the SpaceX test flights. It is 25% of the real pod.
These drawings are the documentation linked to the Scrum task board.

Go Deeper

More about rLoop. rLoop is an open-source, crowdsourced, online think tank. Visit their website: www.rloop.org

Burn-down and Burn-up Charts
“The team displays, somewhere on a wall of the project room, a large graph relating the quantity of work remaining (on the vertical axis) and the time elapsed since the start of the project (on the horizontal, showing future as well as past). This constitutes an “information radiator,” provided it is updated regularly. Two variants exist, depending on whether the amount graphed is for the work remaining in the iteration (“sprint burndown”) or more commonly the entire project (“product burndown”).” — AgileAlliance.com

Teams: Cross-Functional Is Broad In An Industrial Environment

Teams: Cross-Functional Is Broad In An Industrial Environment​​

By Hubert Smits A couple of months ago I talked about Scrum4HW™ to a local user group. Lots of interest, good discussions, and several people from the industry attended. One of the people working in the manufacturing space, made an important remark when I talked about a six- to nine-year cycle to get a new car model on the road. “It isn’t the design of the car that takes six years,” he said. “We can do that in a year. But to align supply chain and manufacturing, that takes the other five years.”

Cross-Functional Team In Scrum For Hardware

“Delivery teams are cross-functional, with all of the skills as a team necessary to create a product increment.” – a quote from the Scrum Guide, This quote means that a Scrum Delivery Team not only has design engineers (for electronics and mechanics), but also people who work in the supply chain or manufacturing space. Once those skills and interests are represented during development of a new product, “Twice the Product in Half the Time™” is possible. I have two examples to share with you: The first occurred in the rLoop team developing battery packs. Inside a pack, the battery material is enclosed in a material designed to dissipate heat. The designer created a clever production process using only an electric heater and a kitchen vacuum sealer. Another volunteer produced 300 of the heat dissipation layers. Half of those were too thick, and the battery packs couldn’t hold them. A waste of time and money. Had a manufacturing expert been involved, tests would have been developed for the volunteers so this mistake wouldn’t have been made. Another client was used to spending three to four years developing new banking equipment. Hand-offs made it hard to find problems until very late in the project — problems that were often only solvable by redesigning parts of the equipment. These redesigns were the reason that these projects took so long to complete. After considering the cross-functional concept and bringing the right people into the development team, they delivered the next piece of equipment in four months! I believe that two things happen when the right people are on a team: problems are found earlier in the process, and both a problem-finder and a problem-solver are part of the same team. Finding a problem early makes it easier to solve it. In a four-year project cycle, the people working in the first year aren’t readily available to solve a problem that is found in the last year. Teams need to go for the win: there is no them-and-us because we are all here to win! When a problem is discovered by the person in charge of the supply chain, the entire team works together to fix it. Ken Schwaber stated, “Scrum is simple, not easy.” The scenario above isn’t easy — people can be spread out over the globe, and products can be large and complex. However, as Einstein said, “No problem can be solved from the same level of consciousness that created it.” Work on the challenge to create a cross-functional team in your Scrum4HW™ project, and it will pay off! If you’re looking to help your team optimize your processes, get in touch with us at Big Orange Square. We have been helping teams learn how to work at peak efficiency for years, and we can help your team, too! Go Deeper: rloop: rLoop is a non-profit, crowd-sourced online think tank, competing in the SpaceX Hyperloop competition. rLoop is comprised of over 300 members representing more than 15 countries. Rebecca Zhou is one their members and she spoke at the Scrum Alliance Scrum4HW Track in San Diego April 2017. Ken Schwaber: Ken co-developed the Scrum process with Jeff Sutherland in the early 1990s to help organizations struggling with complex development projects. One of the signatories to the Agile Manifesto in 2001, he subsequently founded the Agile Alliance and Scrum Alliance. He is the founder of Scrum.org.

Scrum Makes Sense For Startups: Part Two

Scrum Makes Sense For Startups: Part Two

In our last blog, we discussed how the Scrum framework can be helpful to startups who are looking to get the most amount of work done as quickly as possible in order to get it on the market as soon as they can. We also talked about how Scrum is an adaptable framework that can change the way you think about your final goal.

In today’s entry, we will talk about why moving towards iterative development can be so beneficial for your startup team in an age that demands speed and flexibility. If you want your team to start working more efficiently, call us at Big Orange Square. We offer public classes about Scrum and agile development as well as personalized training programs built specifically for your team. We have trained more than 15,000 people over the last 10 years and we can help you, too.

Iterative Development

Iterative development is the cyclic process of developing a prototype, testing it, and then refining the prototype after analysis. While this might not sound much different than the way that products and some software is traditionally built, it is actually a different process. While traditional development focuses on taking steps in order, iterative design instead looks at the final product as a collection of products that must each be built in order for the final product to function correctly. By accepting this model, teams don’t have to wait for other pieces to be completed in order to complete theirs. Instead, teams work in parallel to build the products that will then combine in the end for the final product that you want to take to market.

Each team works on their own product separately but they all come together frequently to share their findings and to show the others how their product will eventually fit in with the others. By repeating this process of prototyping and refining, each team is solving problems every day that might otherwise take weeks, months, or even years, to be discovered. The iterative design and development process basically creates a large number of scenarios that mirror the actual use of your product by users without having to risk the bad press that follows broken software or a product.

At Big Orange Square, our approach to teaching Scrum is tailored to both software and physical product development. Our method will help you work through the processes and make your work move more quickly by actually engaging your minds with hands-on training. We have found that tactile training yields the best results by showing teams that the prototyping process is much less scary than they think it is and that it yields faster results with better solutions.

Contact us today to find out how we can help your startup team get off on the right foot. We have years of experience helping software development teams get started with agile Scrum and we have tailored these processes to work with physical product development in a way that hasn’t been done before.

Scrum Makes Sense For Startups: Part One

Scrum Makes Sense For Startups: Part One

If you’re just getting your startup off of the ground and you’re looking for a way to maximize your results in the least amount of time, you have a lot of options. While you could go the standard route of having your entire team work on one problem until it is solved and then move on to the next one, there is a way that allows you to break a goal up into smaller pieces that can be tackled simultaneously by smaller teams.

The Scrum framework is an agile project management framework that takes all of a project’s requirements and breaks them down into pieces that can be completed by a team within a short amount of time. The benefits to using the Scrum methodology are many, and in this blog we will cover why Scrum can be a good idea for some startups, especially those startups that are trying to build physical products or create software.

If you’re looking for a way for your team to effectively learn the agile framework of Scrum, get in touch with us at Big Orange Square. We have years of experience helping teams learn the process of iterative product delivery through personalized programs built just for you and your team. Our hands-on classes are the most effective way to get ahead of your schedule while still delivering the highest quality products.

Learning The Scrum Framework

While Scrum sounds like a spectacular way to work, many people are confused about the basic steps. Part of this confusion may lie in the fact that instead of having rules that apply to every possible situation, Scrum is actually a much more malleable way of approaching your work than it is a list of hard and fast rules.

Instead of thinking about Scrum as a rule book, try thinking about it as conversations with a philosopher. While books are great (they’re fun to read and full of knowledge you might not have), they don’t answer you when you ask questions and they don’t change when the outside world changes. Thinking of the methodology as a conversation is more helpful because a conversation not only teaches you something in a way that is similar to a book, it also teaches you how to think and how to teach yourself. Because a conversation with a philosopher adapts and molds around the give and take between ideas, it is infinitely more flexible and helpful than an inert book.

One of the most important things that you will learn when you attend one of our agile Scrum classes, is that Scrum will help your business adapt to design and build challenges much more quickly than you would be able to following regular design and build procedures. By breaking the process into small pieces and tackling several of them concurrently, your team will move forward at a rate that is almost hard to believe.

In our next entry, we will continue this introductory discussion of how Scrum can work for your group. Contact Big Orange Square now to learn about how we are bringing Scrum to design and manufacturing.