Wikispeedhttp://wikispeed.org
My next car gets 100 MPG.Mon, 23 Mar 2015 18:20:33 +0000en-UShourly1http://wordpress.org/?v=4.1.1WIKISPEED Enters Local Motors ARPA-E LITECAR Challengehttp://wikispeed.org/2015/02/wikispeed-enters-local-motors-arpa-e-litecar-challenge/
http://wikispeed.org/2015/02/wikispeed-enters-local-motors-arpa-e-litecar-challenge/#commentsWed, 11 Feb 2015 20:42:57 +0000http://wikispeed.org/?p=676This challenge, with $60,000 in prize money for first place and $150,000 over all, has just been announced and closes March 5th. http://www.compositesworld.com/news/local-motors-teams-with-arpa-e-for-lightweight-future-vehicle-design This seems a natural fit for us, we have a crash-tested ultra-light weight chassis in the SGT01. Please forward this post to interested parties, and email info@WIKISPEED.com with your capacity of how many hours per week between now and March 5th you can commit to put in. From this list we will form a team. I’ll start by saying I can commit 8 hours per week to this exclusively, with up to 40 hours potentially on some weeks. I will contribute directly and serve as a Scrum Coach to the team. If you wanted direct experience pairing with me on a Scrum Team, this is an opportunity for that. Any winnings will be deposited into WIKISPEED’s Non-Profit account with the explicit purpose of purchasing turn-key engines for our customers. Significant contributors will be written up in a press release distributed to global media outlets, featured in a white paper of our findings if time allows, and invited to present on the topic during at least one of the world’s major manufacturing technology conferences. -Joe Check out our entry here: https://localmotors.com/infocc/team-wikispeed-sgt01/ Join us in making the world a better place. Let’s do AWESOME together!

]]>http://wikispeed.org/2015/02/wikispeed-enters-local-motors-arpa-e-litecar-challenge/feed/0WIKISPEED Needs You!http://wikispeed.org/2015/01/wikispeed-needs/
http://wikispeed.org/2015/01/wikispeed-needs/#commentsFri, 09 Jan 2015 01:24:35 +0000http://wikispeed.org/?p=671AWESOME UPDATE: On Sunday, February 15, we produced another running engine module! These calls for help got us the velocity to the backlog we needed to develop a solution. We have a functioning path forward and have resumed producing running engine modules, but still need your help leaning that process to accelerate it and further improve efficiency. EVEN MORE AWESOME UPDATE: February 26th video of Milo iterating the running engine module with a wire harness extension prototype. We have encountered a block in our engine module development and need your help to continue. Sadly, we’ve failed to deliver a car a running engine since car 002. Our only successful customer deliveries since have been to groups that opted not to purchase an engine module. We haven’t been able to get stable and durable running engines in any of our cars since car number 002. Car number 002 was built by an AWESOME ASE certified master mechanic with experience at Mercedes Benz and with custom fabrication. With that success, we began taking customer orders with him as foreman of our prototype assembly line. Shortly after, he left Team WIKISPEED to found his own auto-repair shop in his home town, a dream he’d had since childhood. Since then, we’ve hired Craigslist mechanics, tested 3 types of electric motor modules, partnered with an engine company, had the owner of an engine control system company spend one month dedicated to our engine module development, even had a group of 200 engineers at a missile systems company work on one car with just one engine module for 5 days straight with a craigslist mechanic at a workshop, and the best we’ve gotten is a rough idle or 30 seconds of engine response. In the meantime we’ve shown we can do almost anything with aluminum and carbon fiber, rapidly iterating suspension/interior/aeroshell/safety modules for all of our customer cars in the queue. But that isn’t enough for customer deliveries. Team WIKISPEED needs to do something radically different or 0) sink this project and kill the company. 1) Drain all remaining funds to switch to a Front engine, Front wheel drive design, and incorporate the entire drive-train un-modified from used vehicles (must be used as new FF drive trains are not sold complete and running). est $5,000 per engine module but many sprints to convert all modules to accept FF without modification to the drive train. 2) Raise funds and switch to a Chevrolet LS3 “connect and cruise” crate engine. This is the only crate engine currently on the market that is delivered with all electronics connected and a matching key. We don’t have enough money left to do this without raising funds. There is risk in that we’d have to learn how to work with the LS3. est $15,000 per engine module. 3) Raise funds and deliver each car in turn to an electric vehicle conversion shop, at a price higher than the LS3. We don’t have enough money left to do this without raising funds. Lowest risk, needs the […]

]]>http://wikispeed.org/2015/01/wikispeed-needs/feed/9Should we reset our reference stories?http://wikispeed.org/2015/01/reset-reference-stories/
http://wikispeed.org/2015/01/reset-reference-stories/#commentsSat, 03 Jan 2015 06:18:53 +0000http://wikispeed.org/?p=668Bill, an experienced and veteran Scrum Master just completing Sprint 1 with a newly launched team, emailed in to say his team got way more done in Sprint 1 then they had estimated. They pulled in half as much work again as their original Sprint 1 commitment. Congratulations! Bill asks if his team should choose larger reference stories and reset their estimates so that they can work with smaller point numbers for a while but loose comparative velocity to Sprint 1, or if they should keep their current reference stories and values. Here’s what I wrote back: >> Hi Bill! Savvy questions! To my mind, given this is a new team and one of the first in this company, I’d prioritize the decision based on morale. Which will delight the team? It’s not too much more effort for them to create new, larger, reference stories and re-set their statistics. It’s also not too much more effort for them to split 33 or so stories into these tiny buckets as they double velocity and approach 100 points per sprint under their current estimating scheme. So, my question to you as our informed observer, embedded with the team, is do you think they would be more proud of themselves to have to choose new reference stories because they crushed the first batch faster than any of them thought they could, or to get to split epics down into 33 or so stories as they approach doubling velocity because they can chew up and deliver those story sizes so quickly? Ultimately, as the team increases in speed, they’ll be pulling in huge amounts of points anyway. So this is a good problem that they’ll need to take on sooner or later. My leaning is to keeping the same point schema, and showing the acceleration trend as they continue to become more and even more awesome together! >>

]]>http://wikispeed.org/2015/01/reset-reference-stories/feed/0Top Five Scrum Metricshttp://wikispeed.org/2014/12/top-five-scrum-metrics/
http://wikispeed.org/2014/12/top-five-scrum-metrics/#commentsWed, 24 Dec 2014 05:08:39 +0000http://wikispeed.org/?p=665When coaching in a company, I always recommend each team Scrum Master track 5 metrics each sprint: 1) Team Velocity per sprint. This gives us the more important Acceleration. 2) Quality. How this is tracked varies per industry, but is often bugs found in field. 3) Time to Fix a bug: For each bug or defect, the number of hours from the time it was found until it was resolved. Bonus points for recording the root cause analysis and systematized resolution for bugs that take more than 2 hours to fix, in hardware or software. 4) Team Happiness, using the Happiness Metric. 5) Try’s. The Try’s are single process improvement the team selects each retrospective. It takes the Scrum Master about 15 minutes to record all 5 of these each sprint. Does the Scrum Master have to be the one to do it? Of course not; but if no one is doing it the Scrum master has to- they are the pointer to make sure this gets done. These metrics are IN ADDITION TO the Scrum Master’s normal responsibility to make highly visible the 3 Scrum Artifacts each sprint: The Backlog, the Sprint Backlog, and the Potentially Shippable Product Increment. And these metrics are IN ADDITION to the Scrum Master’s normal responsibility to post a big, visible Scrum Board or Kanban Board, a Burn Down chart for the sprint, and a Burn Up or Burn Down of the release plan.

]]>http://wikispeed.org/2014/12/top-five-scrum-metrics/feed/2Initial Feature Planning and Level of Finishhttp://wikispeed.org/2014/12/initial-feature-planning-level-finish/
http://wikispeed.org/2014/12/initial-feature-planning-level-finish/#commentsWed, 24 Dec 2014 04:44:31 +0000http://wikispeed.org/?p=662A question from a friend of mine in the Seattle area, working in a hardware company on one of the software teams that supports the software, wrote about story size splitting and Agile Principle number 10: >> My question is about initial feature planning and level of finish.Example: I’m making the first implementation of a wireless key fob for my car. Previously it was just a metal key. My main feature is lock and unlock doors. Does it lock/unlock only driver side door or all doors or both? Does it need to have panic mode? Trunk opening (assuming there is an electric trunk opener), etc. I think you get the idea. Where do you say, “this must be in the implementation” and where do you say, “this can wait”? I’m looking for an answer that relates back to the customer of course. I would assume in the above example that delivering less than a capability to lock/unlock driver side or all doors and a panic mode would be not enough because of public expectation? I’m wondering how to reconcile this with the principle of maximizing the amount of work not done? >> My reply: >> If the team can get a small, working, tested, elegant feature out the door each week, it’s no problem for me as a product owner to ask for just the driver’s side unlock. Then use it at the demo, then ask for the panic button. Then use both at the next demo, as it’s only been two weeks. If the team is slower, then my first priority is to give them easy wins to pump up their morale which in turn makes them more likely to increase their velocity of Done Tested Releasable features. So I’d split it even smaller than Driver’s side door unlock only: maybe a key with a compartment in the fob that can hold a battery and circuit board, but they haven’t had to develop that yet. Then the next sprint, after I’ve seen them slide in and out a plastic card to mimic a battery and circuit board, I’d say now it needs to be a circuit board in there, with a battery, and button, and a red light that blinks when you push the button. If the team is not able to get any of those Done, Tested, Releasable at sprint end, I’d split it further, ask their Scrum Master for the list of impediments from the team to getting more done with quality, and set myself to removing all the impediments in priority order. After removing the impediments, if the team still can’t get me done and tested features in a single sprint, I’d stop paying them and look for a more capable team to fund. Agile Principle Number 10, Maximizing the Amount of Work Not Done, is about cutting the 80% of the backlog that, statistically, is seldom or never used by the customer. Paper prototyping and recording what is actually used, or other usability studies, can […]

]]>http://wikispeed.org/2014/12/initial-feature-planning-level-finish/feed/0Scrum is the dominant creator of new money according to the NYSEhttp://wikispeed.org/2014/11/scrum-dominant-creator-new-money-according-nyse/
http://wikispeed.org/2014/11/scrum-dominant-creator-new-money-according-nyse/#commentsFri, 21 Nov 2014 03:16:23 +0000http://wikispeed.org/?p=652According to Forbes list of the top US IPO’s of all time (all in the last 25 years), we have a list of the top creators of new wealth on the New York Stock Exchange (NYSE). Each of these companies relies on Scrum for fast creation of new product and rapid discovery of opportunities for improvement. Some I’ve worked with. Some I’ve worked with the coaches who work there. Some of these companies even go so far as to post their number of Certified Scrum Masters and Certified Product Owners publicly on the Scrum Alliance site: Facebook: 0. (I’ve been there, it’s Scrum boards everywhere. And Twitter and Zynga, too). Visa: 74. (I’ve met with Visa’s Scrum Teams, Scrum is core to their business strategy). GM: 29. (I’ve worked with GM’s Scrum teams and their full time Scrum coaches. Amazing to see 29 certified folks publicly posted!). Kraft: 0. (I’ve worked with Scrum coaches from inside Craft. And, Nestle, too.) UPS: 5. CIT: 2. Travelers: 9. (I’ve worked with their Scrum Coaches). Hospital Corporation of America: 1. Goldman Sachs: 3. (They have a very sophisticated Scrum adoption, awesome to see 3 certified folks publicly posted!) People’s United Bank: 0. (I’ve met with Scrum team members from Peoples, good job folks!) Although Forbes has written about Scrum numerous times, I’d love to see them index top IPO’s by project management type. We still have waterfall holdovers making huge money, like the Agricultural Bank of China, but as even big government goes Scrum (thanks Washington State and Michael DeAngelo, and the teams that rescued Sentinal and Healthcare.gov!) we can suspect to see even more direct financial dominance of the companies that can iterate themselves and their services the most quickly.

]]>http://wikispeed.org/2014/11/scrum-dominant-creator-new-money-according-nyse/feed/0Technical Debt and Legacy Solutionshttp://wikispeed.org/2014/10/technical-debt-legacy-projects/
http://wikispeed.org/2014/10/technical-debt-legacy-projects/#commentsThu, 30 Oct 2014 02:14:30 +0000http://wikispeed.org/?p=636The best I’ve seen to-date on coping with spaghetti wiring harnesses or spaghetti code, or any legacy tangled up technical debt in hardware or software, is pasted below from an email exchange earlier this week. To set the stage, the working definition of Technical Debt for non-software or software I use is currently: Anything that reduces the cost to make change. This is typically poorly architected solutions, difficult to understand solutions, and brittle solutions that we put in as a quick-win or test. In order to speed back up the pace of new development (change) they need to be replaced with more durable, elegant solutions that are comfortable to build upon, easy to test or self testing, and easy to swap in and out. >> For coping with technical debt, I’ve seen teams have regular improvements without getting overwhelmed or missing the new feature dev by “refactoring in place”. I’m a big fan now. They pulled this off by making sure whatever area of the code (or in hardware or other work, that module of the solution or service) was refactored and made compliant with elegant architecture and their current definition of done. That meant as they developed new awesome, they improved the code base a section at a time. By ramping up the pace of new development they even ramped up the pace of beautifying the legacy solution. That gets my respect and applause. >>

]]>http://wikispeed.org/2014/10/technical-debt-legacy-projects/feed/0Velocityhttp://wikispeed.org/2014/10/velocity/
http://wikispeed.org/2014/10/velocity/#commentsThu, 30 Oct 2014 02:07:51 +0000http://wikispeed.org/?p=634I was recently emailed asking how a group of teams might better measure their velocity. The exchange might be interesting to more folks, and I’ve posted it here in the case that it is useful: >> Awesome to have the conversation go a bit deeper. The definition of velocity Scrum Inc uses is: the amount of work done sustainably and with quality. We always ask for 4 measures when we coach teams: Velocity, Quality (defects found in field, support calls, cyclomatic complexity, or the best the team is measuring now), value (NPV per point), and team happiness (Happiness metric). We then are brave enough to get specific about quality: The amount of work accepted by the PO as “done” during the demo that meets the current definition of done at a pace the team votes they can continue indefinately (http://www.agilemanifesto.org/principles.html principle 8). The definition of done must include tested, and we encourage the team to elaborate that with “elegant design”, “refactored in place”, test driven, automated tests, gated check-in, unit testing, integration testing, regression testing, exploratory testing, compliant with OOA (and therefor loosely coupled), etc. In this way while it should become more difficult for teams to complete a given amount of work within a sprint, we find as they evolve the habits to produce elegant and excellent solutions they actually continue to speed up. >> Measuring historic or baseline velocity, to compare previous speed with speed after a Scrum transformation: >> 1) They measured in velocity points (http://www.scruminc.com/points-vs-hours/). To measure previous velocity, they used a two methods: A) use the first 3 sprints velocity average as baseline. B) estimating the backlog of the most recent delivered project and taking the point values, then dividing by the time it actually took to ship. >>

]]>http://wikispeed.org/2014/10/velocity/feed/0Definition of Done for Hardware Projects with longer release cycleshttp://wikispeed.org/2014/10/definition-done-hardware-projects-longer-release-cycles/
http://wikispeed.org/2014/10/definition-done-hardware-projects-longer-release-cycles/#commentsWed, 15 Oct 2014 16:43:46 +0000http://wikispeed.org/?p=625I was recently emailed by a savvy Certified Scrum Trainer (CST) about the “Definition of Done for Hardware Projects with longer release cycles. e.g. Saab Fighter Jets.” Kelley Harris writes: >>I’d welcome your suggestions for adjusting the definition of done for hardware projects that have a longer release cycle. e.g. the Saab Fighter jet on a 6-month cycle. Or GE’s Jet engines on 18-month cycle, etc. I have CSM students from some HW/SW companies. e.g. Cisco hardware + firmware with 12-18 month release cycles. Lockheed Martin with space launches that only happen once, at the end of 10+ years of development. What would you tell these students when they ask, “What does it mean to be done and potentially shippable at the end of one week, when there is no hardware ready for months or years, and there really is one one big shipment?”>> And here are my current best thoughts in the response>> I’m glad you asked. Many companies just can’t even imagine, yet, a world where they can produce their physical products in short iterations. This is simply not true, as more and more companies every week are achieving it. This is such a common belief that Alex Brown and I are teaching a 45 minute online course on short cycles (<1 week) in large volume production manufacturing + their support industries: https://www.scruminc.com/scrum-courses-and-training/event-registration/?ee=82 About the definition of done, whether the release cycles are multiple times a day or every 5-7 years, I’d recommend the DOD be very similar in both cases. Companies have the best results when their iteration is releasable. To do that, the DOD includes the regulatory compliance tests, packaging, any required documentation (more often video filming now then writing), unit testing of each module with stubbed neighbor modules, integration testing across all modules, and regression testing to verify the product or service meets the company’s mission statement and not just the minimum regulatory requirement. The stubs piece of this, just like in software only teams when they were just getting started with Scrum and not able to ship their entire project in a week or less, allows the piece that is developed this sprint to be tested against the other modules in the system. A good Object Oriented Architecture is required for contemporary product or service development, and enables this TDD approach to hardware or services. >>

]]>http://wikispeed.org/2014/10/definition-done-hardware-projects-longer-release-cycles/feed/0Tooling Lead Timeshttp://wikispeed.org/2014/08/tooling-lead-times/
http://wikispeed.org/2014/08/tooling-lead-times/#commentsMon, 25 Aug 2014 21:14:38 +0000http://wikispeed.org/?p=607Brilliant email from a printing system’s engineer: >> …the question of tooling lead might be: You’re right, If it takes you x months to build a prototype with the tools you’re using, there’s no way to deliver functionality to the user and get feedback with a cycle of less than x months. On the other hand you’ve got to ask yourself if there’s not some other tool that’s much faster. Imagine that someone with another tool, say a carbon composite technique, entered the market as a competitor to you tomorrow. How much value can your competitor add by being able to deliver a new idea in a week while it takes you x months? If it takes you 18 months to deliver a prototype and in that time your competitor has generated 78 generations of product, how long will it be before his knowledge of and adaptation to the market space surpasses yours? It would take some very serious drawbacks to the faster technique to make it worth your customers while to wait for your product. Not THINKING about how to do the job with radically faster tools is a risk you can’t afford to take. Dave Behnke Sr. Software Engineer Brady Corp. >> I’d like to add on some information about ProtoMold: http://www.protolabs.com/protomold “Get 25 to 10,000+ parts in less than 15 days starting at $1,495.” I’m not sponsored by ProtoMold, but deeply impressed that they can do same week turn-around of injection molds for $200. Apparently they were founded by an exec in a printing company, fed up with waiting months before he could try a new design, and now it is a hugely successful silicon valley startup. Related, to fit molds made in house into a one week sprint: here is a quick lap around the WIKISPEED frugral composites process: https://www.youtube.com/watch?v=Vy3h5rYuUM4. This clip is from the August 2014 eXtreme Manufacturing Certified Scrum Master Class. This next link shows our composites process, hands-on, in miniature: https://www.youtube.com/watch?v=VgqgoC0Pol8 The molds are machined out of foam, exactly as this timelapse shows us: https://www.youtube.com/watch?v=rPORNz9TMdc We use a $2,700 USD CNC router, available as a kit here: https://www.buildyourcnc.com/blackfoot48v40.aspx For aluminum molds made within a week in house, Roland’s SRP machines may be a strong fit. I have not used them myself. With this $40,000 USD machine your mold shop can produce aluminum molds each week for hand-held sized devices: http://www.rolanddga.com/solutions/rapidPrototyping/pg2.asp Related, QuickParts providing molds and parts as an outsourced solution: http://quickparts.com/LowVolumePrototypes.aspx?utm_source=bing&utm_medium=cpc&utm_campaign=rapid_prototyping