It seems proper that my first post on this blog should be something about how I learned of agile development principles and methods. Sort-of a history of my “enlightenment,” if you will. It just so happens that another local ScrumMaster, Chris Young (@tombombadil), recently asked me about my involvement with Scrum and agile. The following is based on my email response to him.
In the spring of 2007 I came across a video of Ken Schwaber explaining Scrum to a Google audience. I was fascinated. I then embarked on a personal education journey of Scrum and agile, learning what I could from online sources and then going after books. At the same time I started evangelizing the ideas at my employment, bending the ear of key engineers and the CTO during lunches, in discussions and finally in presentations that I called for about once a month. I did not use the words “Scrum” or “agile” for the first few months, but by the time I successfully scheduled a lunch visit to our office by Derek Neighbors (@dneighbors) in November 2007, all the top technical management was involved in the discussions.
Finally at the end of May, 2008, our Senior Program Manager came out of a meeting announcing that we were going to be agile and he, myself and the software group manager were going to be trained. I attended my ScrumMaster Certification Workshop with Micheal Vizdos (@mvizdos) in July, 2008. Shortly thereafter we declared one engineering team as “doing Scrum.” A great victory!
But not really.
Just as agile principles declare that a team must do, inspect and adapt, so too with an organization. It is not reasonable to expect a company, a department, a team or even an individual to change to agile as quickly as we want. The victory above was the “official” beginning of our journey to agile. As self-declared “chief evangelist” of change toward agile practices, I continue to have some successes, much disappointment and high hopes.
Part of the difficulty implementing Scrum where I am currently employed is the nature of what we do. There are mountains of literature on using Scrum and agile practices on a purely software product. Not so much on a software and hardware product. There are certain aspects of hardware design, like PCB manufacturing lead times and other physical things that make agility harder. The physical things are actually not that hard to overcome but the hardware and embedded engineers are people that lean on physical things, have years of experience doing things waterfall and with vendor schedules in their face. If they don’t want to see the benefits of agile, it’s hard to change!
In my view, the beauty and power of Scrum is it’s simplicity balanced by how hard it is to do. The formula to becoming an accomplished musician is simple: practice. But practicing 8-12 hours a day for years is hard so most don’t do it! Scrum and agile are like that: They are easy to understand, hard to practice. It’s hard because the team and organization fail faster, operate in transparency and have to deal with people issues instead of technology. But that’s where all the power is and that’s why it works!
I continue to learn, read, inspect and adapt my behavior. I sometimes see where I need to improve. I sometimes don’t see. But I keep talking and learning, training and teaching. There is power in these words that can produce great things and great engineers.
I really believe that.
No comments yet.