First of all let me tell you that your STG01 (the 100mpg car) looks great. I am tempted to buy it now, what a great model. There is so much I want to talk to you about; we’ll see how much we can fit into this one hour. You want to start with telling us about your career so far and your touch points to project management. And then tell us how you got started on the agile concept.
Agile for me was the de facto standard. When I graduated college the first job I took was with an agile software development group. I didn’t even know it was agile, it was just the way business was done there. At that time I was writing one of the first web services for .NET 1.0. Then I was poached by a consulting firm that did Microsoft enterprise software. Agile was becoming hotter and hotter, and customers were requesting agile more and more. So for several years I never worked with anything except agile software development, I didn’t know any other method!
Some of these teams were quite large, maybe more than 50 team members, and sometimes these were distributed teams working from multiple countries at once. Again I didn’t know any other method than agile software delivery – working with the principles and values of agile, lean and scrum we found ways to co-ordinate multiple teams during larger and larger project deliveries. As these deliveries grew to multiple teams, I began to interface with more teams with hand-off points and joint deliveries. They were using some other method; it turned out to be waterfall. It was so painful, so much time was caught up in change request and a lot of it came to rely on the theatrics of the project manager to convince the client that they needed a change request. And none of the teams I was on needed to do that, the client was just aware of the current state of the project and able to re priortorize. It was very much less dramatic and as a result far more efficient.
I started studying this other method, trying to figure out what it was and why it seemed so painful. And why the people on the team I was with were excited, eager, and creative. Contrastingly, the folks on these other teams were often very depressed, quite literally, and looking forward to going home. They often needed to work week nights and weekends to meet some goal that a project manager had mentioned in passing and the client had taken to be gospel. Again I was struck by this, which didn’t happen on the teams I had been working with because it was continuously iterative and work was completed in priority order. So I began studying this in earnest. And really only discovered what agile was once I learned what waterfall was. To me again agile was just the way you did work, I was lucky enough to be born right into it. I began to become very passionate about it once I saw how concrete these differences were. And the difference wasn’t that you had a high performing, creative team just magically. But there was a creative high performing team because of a specific type of project methodology and project management approach. Once I found that it was repeatable, with different teams, and there were these set of principles that could be applied again and again to avoid teams becoming so disheartened, so 9 to 5, so pathetic, so uncreative. It became something like a personal mission for me, and I become very passionate about it.
Now at WIKISPEED, again I did not know any other way to run a project. When I was on the automotive design project and then on the ultra efficient automotive challenge the only delivery method I knew was agile, lean and scrum. It came to be incredibly effective for us. It developed a very different type of car than what is on the road now. It became a very efficient car, a very quick to develop car and a very inexpensive to maintain car. Again it is not that I set out to build an agile, lean or scrum car, I set out to make an ultra efficient car with this whole team of volunteers all over the world. As the team lead who determines the project methodology, it enabled us to have this high energy high performing team, high creativity, high velocity team, and to do so much in so much less time.
You are the first person I have met, who started out with agile. I want to talk to you about WIKISPEED, but I want to ask you one more question. On the project management side if I were to ask you what your vision for what project management is, how would you respond to it?
Project management, I imagine should be exactly about delivering customer visible value as quickly and efficiently as possible. Maximizing customer deliverables for visible value. That’s important because it is not value that the customer might not notice, it is exactly what is meaningful to the customer. And so that means that the project manager would care about maximizing time spent on creative problem solving rather than on any other task that the team could be doing. They want to be minimizing paper work, minimizing process overhead; minimizing meetings, minimizing time spent doing anything except creative problem solving which creates customer visible value.
And how would they possibly do that? Wouldn’t that be nice, wouldn’t the team or the project manager be much happier and much more invigorated if they are solving problems all the time. Wouldn’t that just be Utopia? Well it turns out that agile, lean and Scrum does enable that when they are implemented properly. So Scrum mandates two meetings – there is one a day, your daily stand up and then every week or two weeks you have one other meeting. It’s a big meeting – it has your demo, it has your retrospective and your sprint planning. And nothing else. And I feel a lot of teams tend to loose some of the value of Scrum when they introduce additional meetings.
They say “well we have to for this regulatory compliance; we have to integrate with these other teams”. It turns out that there are methods within agile, lean and Scrum to accomplish this where you still don’t have to have any other meetings. That begins to get you some of the value of that creative problem solving which keeps morale high; which we care about since morale is a multiplier for velocity. This is completely how WIKISPEED was able to build the car so quickly; by keeping morale high. Agile, lean and Scrum is an organization’s toolbox to maximize customer visible value.
So I have said “here is the thing that could be great”. But it turns out that the project manager has the ability to realize this value at the project level. They determine who has to do what and when – if people need to fill out this report, if people will need to fill out this documentation, what type of code changes are required. They can wield the tools of agile, lean and Scrum to keep morale high and to minimize time spends doing anything but creative problem solving – at the project level.
You speak about creative problem solving. Are there any specific things you do to motivate you teams in order for them to do that? Or is it just by virtue of the way we set this up, less meetings, less paperwork, less process and the availability of time. Does that translate into creative problem solving?
I am glad you asked, that is off course a prerequisite. But in a software team and building cars, there is a whole lot more to it. So we make it very quick to find tools. We make it very quick to take something apart, we make it very quick to put something back together. So we do a value stream map continually of our work and our value stream to make us recognize how much of our time is value being added verses how much time is overhead. So if you were to say changing a light bulb, how much time is getting out the ladder, taking the lens off the light verses actually replacing that dark light bulb and putting on the working one? Putting the lens cover back on, putting the screw driver away, and putting the ladder away; we analyze all of that continually which, as I see it, is a project manager’s role. They can remove that waste, and that waste is not creatively solving problems.
So it’s not just less meetings, less paperwork, but in our case it is that we have a transparent bin that has screw drivers. And every screw driver is in there. There is not a screw driver anywhere else. If someone needs a screwdriver, it’s at a central location not more than twenty steps away. And it’s a clear bin so that they can see if what they need is inside before they even get there. In fact they can see what’s in there across the room and it is labeled. In software teams we would do the same thing with templates, we would do the same thing with test driven development, we would do the same thing with class naming and interface design, so people understand what goes with what.
If someone says “I’d like to make a change to this part of the code”, they don’t have to read many documents, or maybe any, to understand where that code is and what that code does. And then the automated tests for that code are easily available and apparent and the meaning of those tests is easily available and apparent. This reduces waste. The project manager also says “look, it’s important to have this minimal amount of proper process” which would be test driven development, which would be contract first development and clearly labeled interfaces. This is all true for software and that is exactly the way we build cars. So that’s applicable to authoring a book, to running an online newspaper, to a large enterprise software project, a small project or automotive manufacturing.
I was looking at your LinkedIn profile and you have helped companies set up their, agile practice so to speak. On of the challenges in introducing agile to new teams is for the team members to get this sense of ownership and to get that feeling that they are in control of the work that they do, and that they don’t really need a PM to tell them what to do when and how. Some of these team members are so entrenched in the waterfall mindset. The team seems to be dependant on the PM.
Some of this can be addressed during daily stand up meetings, if every member of the team feels responsible or accountable to someone who is present. Usually that someone is a person with hire and fire authority, but not always. When they are there, the team stand up becomes becoming a very effective, very quick meeting, and when that person is not there for that team member it can often linger, take too long or not be taken seriously. When the daily standup functions well, it very clearly puts the onus on every member of the team to clearly convey what it is they did yesterday and what it is they are doing today, so they are accountable for it. They move their backlog card across with personal pride. That seems to deputize them and empower them. Now it can only empower them if the person they feel accountable to is present during that stand up. If they are then that person becomes quite excited and with a profound sense of ownership, and that’s part of what starts to build morale, which then builds velocity- so we can do crazy stuff like build an 100mpg car in three months.
You spoke about virtual teams. Can you talk a little bit about how you have applied the agile concepts to the virtual teams? If the team is not co located, then what are the things that have worked well for you?
So first off to phrase the current state for folks coming into a virtual team, it is my understanding that a dedicated, co-located team is the fastest and has the highest morale and will solve problems most quickly. Now barring that, just in the last ten years, there are tools that enable us to reduce the overhead from having distributed teams to the point where they are almost as quick as co-located, dedicated teams. This means that if a project manager started their career 12 years ago, these are tools that they would have had to learn in the field.
After adding these collaboration tools, then we try to make these distributed teams dedicated, so they don’t have tasks coming from any other queue, so they all just have one priortorized backlog, no matter what their location, which improves velocity and improves communication, because we have single focus. So if can’t have co located teams, we would at least want to have dedicated teams.
Back on the tools side collaborative document authoring, like Google Docs, where you have multiple cursors with each person’s name for their cursor, is an enormous value. We use an open conference call bridge, like freeconferencecall.com. It’s even free for international calls. So we can have a phone bridge open with people calling in fromSouth Africa,Ireland, US andUK. That type of collaborative editing makes it almost as good as if they are all in one room.
Other tools that help are having a single backlog, where it shows who moved what task last. The best online backlog tool I have seen is scrumY. scrumY helps distributed teams from multiple locations stay on task and stay on backlog and are aware of the current state of all items. Linoit is also excellent, but requires a slightly higher level of process maturity across the teams, because there are no predefined columns or swim lanes. It’s free form sticky notes. It auto updates, so if one person moves a sticky note the other folks don’t have to refresh to see the change. It shows you who moved what last and it can have multiple boards under one account. So you can say “here is this board that is related to this particular project”. These two tools seem to work quite well, yet neither one is perfect; neither one shows you here are the last five changes made or here are all the changes made across the last week by having the notes glow or something, but they are getting there. And then neither one also ties into something like a Google account or a Microsoft Live ID, so that you have a clear understanding on mouse over of who moved what backlog item. But an online backlog tool for all folks, with an open conference all bridge and collaborative editing makes velocity almost as fast as being in one room.
Another tool we use is an email list, every time we are communicating with anyone, we reply all – the entire email list. We will have 50 to 100 emails going across a day. What that allows is for people for all over the world to be appraised of the current state of the project and what’s being talked about. Now they might not have time to read 50 or 100 emails. But they can skim the subject lines and say “oh, now I know that this part of the electrical system is being worked on. And I see that this part of the emission system is being worked on, that does not apply to me, but when I have time I will skim”. It’s the same idea of a scrum room, where you have these folks working in one room. So everyone on the room, on the periphery of their vision and hearing, is becoming continually informed about the entire scope of the project. They are having continual reinforcement on how the part of the project they are working on relates to the entire project and they are able to unblock roadblocks quickly.
We try to avoid sidebar conversations, if you imagine in a scrum room where everyone is sitting together, two people get up leave and come back five minutes later going, “Yah, I thought so” and sit down. The rest of the team says “what just happened?” It actually slows down their work and potentially folks become suspicious, no matter what was discussed, since it wasn’t shared. So we try not to have private email conversations, we try to always reply all to try and approximate being in the same scrum room.
Then when it comes to demos, we film them with a flip cam and put them on YouTube, so that way members from the team all over the world can see what the demo. All of these are based on basic tenants, one of them is trust. We have all known this for a long time, like the two people in the scrum room who get up and talk about something and come back. This breeds suspicion and decreases velocity. If you trust your team you can talk about anything in front of your team. So we assume that your team is trustworthy. We don’t block documents from anyone, when ever a document is planned to be shared with one person, we say can I share it with the team?
Questioning access restrictions is another factor to make the team feel empowered and trusted. Suddenly they realize they have access to these documents that aren’t necessarily related to them, yet they realize that they can take on those projects later. It begins to be exciting, which keeps velocity high. An expensive problem I have run into many times when I have come in to a company for consulting or coaching an existing collaborative and dedicated team; is that one of the team feels junior. They will even have names like a core team, and the “other” team. Right there the team feels subjugated and minimized. That’s an immature way to run a project and it is unfair to both teams. That’s exactly the thing that we want to remove when we are trying to drive a very high velocity project.
I have seen this feeling being more prevalent in the off shore teams, they feel like a sub team to the core team.
Absolutely, I am glad you brought that up. When we say “oh the team inNew Yorkor the team inChicago– everyone going out for drinks tonight”. Then the team in Mumbai replies to an email with “there are brownies in theNew Yorkteam scrum room?” How does that affect us? We want to have people go out for team building events, but we try to make it location independent if possible. We would say, “this time in four weeks, we are all going to meet at this place. Anyone who is in town is welcome.” Then taking pictures and sharing. It helps everyone feels like first class citizens. The project manager’s role in this dynamic, probably more than anything, is keeping the team tone proper – respectful, encouraging. It’s absolutely their job to be as inclusive as possible by their phrasing, and by the way they send their updates. Worst case scenario is “Check out the pictures of happy our last week.” And everyone else goes, “what happy hour last week?”
The project manager has a unique opportunity by crafting the communication across the teams to keep morale high, by being respectful, being trusting, being trust worthy, and being encouraging, open minded and adhering to these principles. The project manager doesn’t have to be a saint. There is simply a prescribed set of process principles, which if followed well, will make them an effective project manager – and they are called agile, lean and scrum along with XP and Kanban.
I read on your LinkedIn profile that you have skills in MS Project. Do you use Microsoft Project Server on agile projects?
MS Project Server has matured so much that it supports iterative development, and mixed methodologies pretty well. Now that said we can do almost everything we need to do just with sticky notes and a whiteboard and without project management software. And whenever we do, it ends up being leaner and we have less time spent in overhead. Where Project Server comes into its own is when we have a solution that spans agile and non-agile teams, and especially with a project that requires a certain set of project metrics aside from velocity. Now all those metrics are overhead, and Project Server makes that required overhead easier to cope with and makes a fantastic tool to integrate with other teams that use mixed methodologies.
So let’s talk about WIKISPEED and STG01. Didn’t it start out as a side hobby, what made you think of building a 100mpg commuter car?
WIKISPEED is a project some teams members do full time and most members do part time. Every team member is a volunteer. We are all volunteers and there are a 110 of us now, in eight countries, and we work on it from 2 hours a week and in some cases 60 hours a week. We are trying to build the ultimate commuter vehicle, among other problems to conquer. Our mission is “rapidly solving problems for social good”. And one of those social goods is to built ultra efficient vehicles, if those were possible, if those were safe, if those were fun to drive, wouldn’t that be better? Because we could radically reduce our personal carbon footprint and, in quantity, completely change the emissions and level of fuel consumption globally. So wouldn’t that be fantastic if those were available.
WIKISPEED produced functional prototypes, proving that yes it is possible and it wasn’t that hard to do and in fact it didn’t cost very much, in fact they are incredibly fun to drive, and they are phenomenally efficient, and there are even more benefits than that. And they are extremely safe. Now we are micro manufacturing, where we make prototypes for early adopters, people who want to iterate on the vehicle with us. The goal is attracting enough donations, to actually prototype these cars and make them available to the masses.
And then what made the idea? I am an efficiency nut, and I am an agile, lean and scrum nut. There are four things that I take for hobbies – that I take extremely passionately – one of them is cars, one of them is efficiency with agile, lean and scrum, one of them is martial arts, and the other is wilderness camping.
You put all those together and I desperately wanted to have an environment friendly, fun to drive, very safe vehicle. In 2006 I had an opportunity to try – I was on a software team writing the titling and registration system for one of the 50 states of theUS. And my part of that project, myself and a team of three other developers, was writing the rules engine that says that if someone walks into the Department of Motor Vehicles and hands them a piece of paper saying this car is legal to drive on the road, how does the department know the car really is road legal? How do they know that it is insured properly, and how do they know it meets the road safety specifications?
I had to read hundreds of pages of the code of federal regulations, chapter 49, to understand what makes a road legal car. What are the road safety legal specifications? To build those rules in code that ran on the central server and code that ran on the local machines. As a result I realized what it took to register myself as an automotive manufacturer. Now that would have taken likely millions of dollars in lawyer fees. It was my job to figure this out. And over months and months I leaned that information, so I registered my self as an automotive manufacturer.
So now we have this person who is passionate about cars, who only knows agile, lean and scrum, who is a registered automotive manufacturer, because they take their hobbies extremely seriously. So I started iterating on two very light chassis. Lightness isn’t the only part of the recipe for high efficiency cars. But it is an important part, and I was attempting to make a very safe, and a very light chassis. That was in 2006.
I 2008 the Progressive Insurance Automotive XPrize was announced. They announced a $10 million prize to see if it were even possible to make road legal cars that achieved a 100 mpg. Now there were cars that got a 100 mpg – but they were nowhere close to road legal, and they didn’t achieve a 100mpg on the EPA sitting highway driving standard. They were like bob sleds, one person got in and would lay down, and they drove about 25 miles per hour making slow left turns. That was the state of the art in 2008. In 2008 the Progressive Insurance XPrize asked if anyone can make 100mpg cars that meet road legal specifications. And if anyone can they will give their company, their team, their university $10 million. They made it a race where the fastest team to make a 100 mpg car would win the prize. Eventually they divided the prize across three classes.
I thought, “I have these very light chassis, lightness is part of the equation, how efficient would these things be?” And I wrote a piece of software that calculated the EPA city and highway fuel economy scores, the same scores that are advertised in any car that we might go out to buy today. I gave it an enormous set of parameters to figure out the fuel efficiency results. And I was able to test every car that was built in 2008 and compare the software’s results to their posted EPA results. Using that I modified the algorithm and modified the algorithm until the algorithm returned within one percent of what the EPA got. The software package helped me predict fuel economy if I gave it an enormous amount of parameters about the car. So then I was able to do regression tests; I was able to do exploratory testing to figure out what sets of parameters would achieve 100mpg in city and highway? So I got vehicle resistance weights, rolling resistance weights and break specific fuel consumptions of the engine, etc, etc, etc. This made up the band of what could achieve 100 mpg. Then I looked at those results and asked “which of these are possible?”
So I did test driven development, in fact exploratory test driven development, not because I said “let’s try test driven development”, but because that was the way I knew how to solve problems. I didn’t know another way. I had these set of parameters, looked to see what was possible, and then did contract first development. Just like the web services development I was used to. I didn’t know what type of suspension I want to use, I didn’t know what type of engine I want to use, I didn’t know what kind of front crush structure or seat belt or mounts or steering racks we want to use. But I knew that they all need to connect together somehow and I actually needed to figure out that first; that’s the interface first or contract first development.
How are they going to connect together? I first designed the interface. That’s where I had to learn a lot about material science, and I had to learn about load transmission, to say “ok between the suspension and the chassis on one corner, how much load is transferred and what type of interface will hold that load without adding much weight or complexity?” And what amount of data comes over those modules – speed sensors, air bag sensors, antilock break systems, and what will transmit that data. We ended up using network cables, and connections that look a lot like the way wheels connect to cars. We already know that with 4, 5 sometimes 8 lugs we can hold 1/4th of all the stress that is ever communicated to that car as that is what comes through the wheels on every car on the road today.
Then we had structural plates and we did finite element analysis. So we did exploratory software testing to determine what materials we need to use. We finally settled on aluminum and carbon fiber and then we built the contract.
We still didn’t have a complete car, we didn’t even have an engine, but we had a contract on how these different parts of the car connected. Then we could iterate on the modules, very much like software where we have classes and components of our code and we have our database system separate from your UI layer. We had our engine module separate from our interior module, separate from our chassis, separate from our suspension module, etc. etc. etc.
Which meant then, we can build these in parallel. We had a v1 of one system and a v10 of another system and a v27 of another system, just like you have in software.
The volunteer team happened purely by accident, I decide to blog about everything that happened. I didn’t know how I was going to compete with some of these very large companies and universities that would be entering this competition. There were 136 cars, from all over the world. They came from companies like Tesla and Tata Motors and universities like MIT and Cornell. And I was one of the tiniest teams. Just me and my garage. But I blogged about everything I was doing, what went well and what didn’t go well, my retrospectives essentially. And folks began to answer questions on the blog and then folks even began to come by the garage just to see what I was doing. I never expected what happened next; they began to stay and help. And by the time we were a finalist in the competition, we were a team of 44 volunteer team members in four countries.
It’s the regular successes in an iterative team that help keep people engaged. When we see, “In just one week or two weeks, in one SPRINT we released an entire new version!” That’s what gets customers and clients really excited. It also keeps the team really excited. Because we were changing whole sections of the car every week, it was easy for people to stay excited and to stay involved, even though they were doing this after work on nights and weekends.
What parts of agile, lead and scrum did you use during this development process for STG01? Did you have SPRINTs, Demos, daily stand ups?
During this process and still today – and WIKISPEED doesn’t just do cars by the way – we in general solve problems for social good. We have team members working on large energy storage systems for electric vehicle charging. We have team members working on bi-pedal robotics walking systems. We have team members working on remote deployments of medical systems to remote countries, we have team members who are working on vaccine deployments, for micro financing for third world countries. All these efforts use agile, lean and scrum, because we found it to be fastest way to solve problems.
So what we care about is solving problems that make the world a better place. And solving them as quickly as possible using the least amount of resources. So we use the best process we know, and currently, it is agile, lean and scrum, and extreme programming, and Kanban. We are able to make meaningful changes in the world with a few hours in a week.
Then we care about sharing how we did it, which is exactly why I am excited to speak to you, so that other people might get their work done faster and then go out and solve problems for social good. We would like to encourage them to do exactly that! We try to implement what we have done for the social good, for example making an ultra-efficient car. It is not only enough to design the car produce a prototype; we then want to make them available. We want to deliver the change end to end.
So how do we do this with agile, lead and scrum? As a distributed, volunteer team, we do weekly stand ups. A lot of team members work two hours a week. Some work 60 hours a week. So we talk every Thursday at 6:00 p.m. Pacific Time on a free international conference call. And it is exactly the standard format, what I did last week, what I think I am going to be doing next week, and any blocking issues. Demos are then written up in minutes and emailed or filmed using a flip cam and posted on YouTube.
Then in sprint planning we pull tasks from a prioritized list. The folks who know the most about each task help prioritize them. Then we have a single product owner, who is also the single vision holder; and that person changes depending upon what we are building at that time.
We have multiple projects, but we have a single backlog, that makes it easier for volunteers to pull the next task in priority order. We also use work in progress limits, only one task in flight per team member. We also do inline demos, where if the person who knows most about the task is available, we’ll have the volunteer demo that and put it on YouTube.
Like a software team we have something like version control, we have versioned modules of the car. This gives us some of the same advantages software teams gain from source control and modular projects. We iterate quickly because we have these replaceable modules. We even have some “best in the worlds”; Like the lightest chassis in the world that gets a 5 star crash rating equivalency. And when we want to try a different bumper configuration and crush structure configuration we don’t have to build new seat belts, we don’t have to build a new car, we just change the part that we want. Imagine in a software team, if you were to update the code and you had to delete the code base and you had to start over again? It would be completely impractical.
That starts to speak to the value of using agile, lean and scrum here. Cars typically take 10 to 15 years to design. The entire car is a 5 to 14 year model cycle. We built a 100mpg car prototype in 3 months.
So that’s a quick overview of how we use agile, lean and scrum in WIKISPEED. We have a product owner, we have a scrum Master, and in some cases stakeholders outside the team, we have our backlog, our demos and retrospective is done at the time of the demo.
This is so amazing, in three months, some teams don’t even end up writing a charter. Isn’t this amazing speed that you were able to achieve?
It is a rapid velocity, but it is a velocity that people on agile, lean and scrum teams are used to being a part of. When one team in an organization adopts agile, lean or scrum, typically they go through a phase of compete elation saying “We are moving so fast, compared to how we have moved before!” Infact we often see those teamshave to slow themselves down to work with the other teams they interact with. And that’s why we have SPRINTS. So we say “I will at least not give you updated product more than once a week”. This way the entire organization can handle moving so quickly. We did realize the same things during our automotive development.
I have one last question. What are your hobbies? When you are not consulting, when you are not doing WIKISPEED, what else do you like to do?
Thanks for asking. During the day I am an agile, lean and scrum software consultant and coach. And some of what I do now is called the cloud rack, its one piece infrastructure component for agile IT deployments. It’s for rapid deployment of environments, for development, staging, tests and deployment. And when I say rapid, I mean in minutes. You don’t have to fill out a request form when you have to add a new team member, or when you have to request a new environment. You actually go to a web GUI and provision a new set of environments. It’s a private and cloud appliance for agile IT.
Nights and weekends I do WIKISPEED. Thursday nights is where most of WIKISPEED happens and a little bit every morning, every evening and weekends. Every Wednesday and Saturday my wife and I do martial arts together and we have been for years and years. And I think that’s a large part of where the energy comes from. It takes a whole lot of energy to stay focused even during a day job. But when you essentially add another job to it – WIKISPEED – we want to be careful that we don’t get grouchy, that we don’t catch a cold. And martial arts absolutely help. We do Shaolin Kung Fu – martial arts with a meditative component. I just tested for 4th degree back belt this year and passed! I have been to the Shaolin temple and done a demonstration there. I spent three and a half weeks inChina visiting various marital arts training centers and sites. Many people think of that as “hard styles”, however it includes Tai Chi and lesser known “soft styles” as a completely necessary component. I have an enormous amount of fun doing that with my wife.
My wife and I also love wilderness camping, where we try not to bring a tent. We build a small, unobtrusive shelter out of leaves, and we try not to bring food. We try to gather from local plants. So essentially it is getting closer to the point where we don’t have to plan a camping trip in advance, we kind of just walk out into the woods with whatever clothes we have on and come back when we are ready to come back. We are not quite that good yet, and still bring some food, but try not to eat it. We are getting closer. With that we do animal tracking and animal observation. We learn a lot more about the world around us then we did before. For the wife and I those things together to keep a strong bond, which then enables me to spend a lot of other time – nights and weekends, when most people will be watching TV with their spouse. I replaced that with WIKISPEED and with rapidly solving problems for social good. I have a day job and then WIKISPEED and then make it sustainable for my family and my health and my energy level by doing martial arts with my wife. And then for our vacations together, we’ll go wilderness camping, which really adds quality time.
This is such an amazing story Joe and I should ask if you still accepting volunteers for WIKISPEED?
We absolutely are. We are looking for all types of volunteers with skills from project management to welding to sewing to marketing to art to phone calls and everything in between. I’ll also mention we are funded by donations through http://www.WIKISPEED.com; that’s how we finance everything we do. But even cooler than people joining the WIKISPEED or enabling us; what if folks took even two hours a week to work on something to do with social good, something radical, something large. There are a group of people in the Sub Saharan African desert that don’t have banks. So they quite literally have to keep their money on them. Or keep it in their home and hope it’s still there when they get back from working the fields. But they have cell phones with data plans. If someone was passionate about micro finance, or mobile application development, in about the time it would take them to watch all four seasons of LOST, instead they could write a V1 mobile application and transform all of those lives.
And what’s more important, being entertained for those couple of hours, or really making a difference in the world that we live in?
And Rotavirus. Rotavirus kills millions of children every year. Rotavirus has a vaccine, and it’s not expensive, but it requires refrigeration to be delivered. Where the most children die of rotavirus, there aren’t roads to access it. The vaccine is delivered by people carrying it by hand or on horseback. And it expires frequently before it reaches the people who need it the most. So if someone is a refrigeration nerd and savvy with refrigeration technology, they may be able to develop a powered chemical refrigerant they could put in something like a cardboard FedEx tube and keep the vaccine from going bad. They might save millions of kid’s lives a year. And that would be way cooler than getting caught up on LOST or 24.
If people took some of the time they spent on entertainment and spend it on radically solving problems, on social good, the world would be an amazing place. And that would be even cooler than donating to WIKISPEED or working with WIKISPEED. They are welcome to do that with us – we use agile, lean and scrum to do that and we would love the have them. We care about all those issues and we need people working on them. What WIKISPEED need is materials, machinery, and person hours. Person hours come from volunteers, and machinery comes from donations and materials come from donations.