Archive for May, 2006
May 31st, 2006 by Mark Ramm
Simplicity is knowing when one more rock would be too many, and one less rock would be too few. But it’s not just knowing the right number of rocks, it’s also knowing which rocks are right, and how to arrange them.
As Brad reminds us, simplicity is not achieved merely by making something easier, or less complex.
Take away all the complexity, all the difficulty, and all of the details from anything and what you are left with is not simple: it’s just boring.
On the other hand, Simplicity embraces exactly the right details, the right difficulties, the right complexity, but because everything is tied together in the right way, you are left with a sense of clarity, and a sense that everything belongs exactly where it is. Simplicity is achieved when everything means something.
In other words, simplicity is defined by what you add — clarity, purpose, and intentionality — not by what you remove.
For those of us who write software, simplicity is not a simple thing to learn. Writing the TurboGears book and working with the amazing group of people who contribute to the project has been a learning experience for me. Everybody is focused on making the web development simpler — and it’s amazing how much experience and depth of understanding is necessary to create a simple interface. It’s easy to build an interface that solves 80% of the problem, or an interface that solves 200% of the problem, but it is hard to solve just the right problem, and to do it in a clean, clear, way.
Of course, every project has warts, and TurboGears re-uses other projects which also have warts. So there’s no way I can say that TurboGears has arrived. But the will is there, and the journey sure has been productive for me.
May 26th, 2006 by Mark Ramm
Kevin Dangoor, creator of th TurboGears framework, has just announced that his DVD is available for pre-order.
You can help accelerate the growth of TurboGears, and kickstart your own learning process by buying the DVD.
I’ve been working with Kevin on the upcoming TurboGears book for the last few months, and I really respect his insight into how to make the web development experience better. Even if you don’t use TurboGears, I think you will learn something valuable about web development, ajax, and python from this DVD.
Not only that, I think yo’ll have fun watching this DVD. Kevin’s Effective Ajax with TurboGears talk was entertaining and extremely well received at PyCon 2006, and he definitely knows how to put together a good presentation. I’ve seen snipits of what he is doing, and all I can say is — “WOW, this really takes screencasting to a new level.”
And, as if that wasn’t enough incentive, buying this DVD can help accelerate the progress of the TurboGears framework, by allowing Kevin to work full time on TurboGears development, documentation, and project management.
Not only that, but if you order now, you’ll have the opportunity to get your name or company logo in the credits. So, you can learn cool new stuff, show your support for the framework, and get some publicity of your own.
Sounds like a good deal to me!
Oh, and if you sign up for the premium version you get this cool Toolbox too, along with your logo in the credits.
May 10th, 2006 by Mark Ramm
Brad Appeltion summarizes The Theory of Constraints (ToC), Lean manufacturing, and Agile software development with three words Friction, Flow, and Feedback.
- ToC is about removing friction,
- lean is about improving flow,
- and Agile is about getting better feedback sooner.
But all of these things actually describe Lean. The briliance of the Toyota Production System is that it tells you how to removE friction through the reduction of waste (motion, long cycle times, poor quality, etc), creating a clear flow of work through your system, and reducing the time between a customer asking for something and when it is delivered. And that helps to make the Feedback loop is as short as possible.
May 5th, 2006 by Mark Ramm
I think Jared is right on target with this statement:
“I don’t grow apples. I grow apple trees.” One is a result of the other. Overly focusing on the apple can cost you the tree.” –Jared Richardson
If you throw together a team to build a product, you might get lucky and create a great product. If you are really lucky you’ll get a great team that works well together, is motivated to build amazing software, and is starting to learn and grow as a group — not just as individuals.
Unfortunately, the next step most companies take is to pull that team apart, promote some of them, and try to start all over again new products with new teams. This is a colossal waste of time and money. Great companies find ways to re-use existing teams who have already learned to work effectively as a team. I’ve found that small companies, who have no choice but to re-use the same teams over and over again, have a competitive advantage over their larger competitors who constantly reshuffle their product development teams.
If you constantly grow your capacity to build great things, your competitors will always be playing catchup. But if you slow down and focus on your current cash cow the milk will eventually dry up.
May 4th, 2006 by Mark Ramm
In my opinion, Toyota’s success does not come primarily from the details of the 17 elements of Lean Manufacturing (though they are brilliant), but from the fact that they found a specific and sustainable way to capture the creative insight and energy of every member of their workforce and channel it into striving to reach their ultimate goals — just in time production, and the total elimination of waste.
People are motivated by a vision
Toyota has a clear vision. Lots of companies have vision statements. GM and Ford have vision statements. But that’s not vision — Vision is never just words on paper.
Most “lean initiatives” fail when the ground floor implementation experts don’t share the vision. Either because management has confused the tools for the process, or because management vision is just words on paper to them. Â Â It isn’t connected to anything real, anything they care about.
Kaizan is not an event is it is a process for continuous incremental improvement. Those who think they can make their plant lean by having a couple of kaizan events are doomed to failure.
In fact, even those who see recurring kaizan events as a process of continual improvement aren’t necessarily going to be successful. Kaizan is isn’t just a process, its also a culture, a way of life, and an over arching vision of a future with less waste.
One of the characteristics of a vision is that it feels very specific and very focused. For Toyota this this is reduce the time between when a customer orders a product to when it is delivered — which turns out to be almost the same thing as saying “remove all the waste from the manufacturing process.”
Why do some Agile Software initiatives fail while others succeed?
For those of us who are trying to implement Agile Software development initiatives, the lesson to learn from all of this is pretty clear. If we are going to succeed, it will be because we get our teams to share a vision for delivering better software faster, with less waste.
If, on the other hand, we impose agile as “a bunch of new processes” on people who don’t share a vision, then when something goes wrong (and something always goes wrong) everyone will blame the process. Conversely when the team shares a vision, and are empowered to make it happen, the first person to see something a problem will just fix it and move on.