Agile revisited

I am always delighted when I get responses or feedback resulting from postings here. About a month ago, I wrote about the use of Agile for embedded development, which provoked some interesting correspondence.

Neil Johnson [from XtremeEDA] commented that, because an embedded system is, by definition, a combination of hardware and software, that requires a cross-functional development team, Agile techniques can apply just as well to IC development. I was thinking about times past, when I had often been given part-working prototype hardware, where the design was in flux. This would have lent itself to being guided by Agile. Neil’s focus is more system-on-chip [SoC] design, where simulation is used extensively through the development cycle. He drew my attention to an interesting website: www.agilesoc.com

Mike Jones has extensive experience of using Agile for embedded software. He has generously allowed me to reproduce his writing here …

I’ve been doing some form of Agile for ~12 years – originally taught/mentored by Ken Schwaber one of the pioneers of the Scrum methodology. The company I worked for had the usual problem: a realization that we needed to move to new technology, but stuck in paralysis and unable to move forward. We hired Ken and his team to come in – what an enlightening moment.

I think most people misunderstand Agile. In some ways it isn’t different from the way we think and work day to day. Do you really have this weekend planned? Is it firm? Or will you change your plans if the weather isn’t compatible with the original plan?

The biggest positive to Scrum is knowing whether your project is on track or not. It allows the finding of issues up front. Also, by focusing on having a demonstrable release at the end of the sprint, it allows “outsiders” to see and understand the result of the effort – no more abstract behind the scene non-functional releases.

The hardest part is trying to figure out how to break a seemingly immutable task into parts. However the exercise is worth it. Most teams sit and wait unable to make forward movement on a task because “if just this one item was like this … we could do it, but that depends upon X which might change in the next month … which depends …” and on it goes.
I always thought that a good book title would be “Waiting for the Stars to Align: Resolving Organizational Constipation.” Here’s a video of Ken Schwaber describing Scrum to the folks at Google.

I should point out that I’m a software engineer. However in the database world we constantly think of the db as being a very difficult item to make changes to (having a billion rows making up 1 terabyte of data – takes many many hours … a task that must be completed in 1 hour). Something that I would imagine those in the HW world would think about too. It is possible – you just have to do it and make that first step.

Once started on the path it is different and seemingly slow. However it does accelerate as time goes on. There is another phenomenon that I call “the endless treadmill” – an extreme feeling of “same crap, different day”, due to what they call “hyperproductivity.” The team needs some R&R when a project is complete. We weren’t the only team to experience this effect and it is part of the Agile research.

We used Scrum successfully for many years. Then through the normal attrition those who knew and understood Scrum left and were replaced with the normal PMP certified/traditional project managers. Slowly over time we returned to Waterfall. We recently hired an Agile coach to help us renew our training and get us back on course. My warning to others is that you need to invest and be willing to change, and then reinvest to keep on course. The coach has suggested that this cannot be a top-down approach. Instead you must get people from all levels in the organization involved and allow for an almost grassroots approach. Allow for those who have to use it daily to own it.