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.
