I've been fortunate enough to be invited to Kaizenconf, some kind of Alt.Net spin off with a focus on continuous improvement. Participants to the conference are asked on the web site to reflect on the following questions:
-How do we recognize new improvements?
-What improvements in the past led us to where we are now?
-How do we decide which improvements to make?
-What values drive our decisions for improvement?
-What improvements can we be making right now?
-What obstructions impede improvement?
-What improvements are on the horizon?
-How can we adapt easier to the changes that improvements bring?
-What are the practices and processes that enable improvement?
"Improvement" is in every question. Improve, improve, improve and more importantly, improve! But a harder concept is hidden behind those: how do you measure improvement in order to adapt and figure out that what you are doing is right or wrong?
How do we impove? We figure out how to measure our successes, then find ways to improve on those measurements on each and every project.
In my case, as an IT developer in a manufacturing plant, I could measure success by how well one of my applications is receive by my "customers" in other departements. Is it easy to use? How was the learning curve? How fast did they start depending on it? Does it mesh well with other applications in the enterprise? How much effort did I need to put on maintenance? What about late bugs? And the list goes on and on...
In the end, I need to figure out what will minimize efforts while maximizing speed, easy of use and whatever else makes a great software application. I call improvement whatever lowers my efforts and makes all the rest better.
I'll have to answer all those questions as honestly as I can before I head out to the conference. If I can't, I'll at least know what to look for once I'm there.
0 comments:
Post a Comment