Archive for October, 2006

A colleague of mine worked in the automotive industry. he was always full of tales about the Detroit boys and their ways. Here is one of his cautionary tale. Keep in mind that at the time, Detroit was into making “platforms” which would be used for many years to come. A typical development cycle, from specification to production, would run anywhere from 3 to 5 years.
The group responsible for the transmission controller was migrating from the venerable 68360 to the (then) new PowerPC 555 processor. The ’360 code was a mixture of Assembler and C code. This code did its job and everyone was pleased with what it was doing, but it had become your usual nightmare of patches after patches, with no owner, and the original designers long since gone on to bigger and better things. No one understood how the code worked, and the porting attempts to the PPC555 were met with mixed success. When a transmission goes from 50MPH directly to reverse, engineers tend to duck for cover…

As the immutable deadline approached, everyone was starting to panic. Their solution was clever, but oh so frightening… They created a virtual 68360 processor for the PPC555. This virtual processor understood the 68360 object code, so they could simply use the same binary code that had been used for years. With the added horsepower of the 555, the virtual 360 performed faster than the real processor.
I don’t know which scares me the most…a virtual processor running a transmission, or a transmission controller so complex that creating a virtual processor is simpler than a re-implementation?

We are doing something very interesting at work.  We make supervisory Control and Data Acquisition (SCADA) systems that measure anything from temperature & humidity to particle counts in clean rooms.   We design software for Windows and embedded processors. We also design and build hardware devices.  We typically provide a turnkey system to our clients, to meet their particular needs.

As we are a small company with limited resources, it is always a constant challenge to manage the software, hardware and ongoing customer installations projects.  What are we to do? Use agile for everything of course!

We had our first planning session last weeek.  Considering that the entire cross-functional team is new to agile, I would say it went very well.  The approach is foreign to most people in the organization, but all were excited about the project visibility and accountability the daily stand-up brings. The instant visibility the task board affords into the project status was also welcome.

The major issue I believe we will face is simply the sheer number of projects we have to manage.  We curently have over 12 projects, most of them customer focused, the rest software development.  We have decided on using scrum with a 2 week sprint.  I am certain we will make changes as we come to grip with the specifics of applying scrum to a non software development area.  I’ll post from time to time about our experience using Scrum for everything.
Exciting changes are afoot!