Browsing posts in: Agile

Agile Transitions Aren’t

A while back I was talking with a team about agile. Rather than give them a typical introduction, I decided to talk about techniques that differentiated more successful agile teams from less successful ones. Near the end of the talk, I got a very interesting question:

“What is the set of techniques where, if you took one away, you would no longer call it ‘agile’?”

This is a pretty good question. I thought for a little bit, and came up with the following:

  • First, the team takes an incremental approach; they make process changes in small, incremental steps
  • Second, the team is experimental; they approach process changes from a “let’s try this and see if it works for us” perspective.
  • Third, the team is a team; they have a shared set of work items that they own and work on as a group, and they drive their own process.

All of these are necessary for the team to be moving their process forward. The first two allow process to be changed in low risk and reversible way, and the third provides the group ownership that makes it possible to have discussions about process changes in the first place. We get process plasticity, and that is the key to a successful agile team – the ability to take the current process and evolve it into something better.

Fast forward a few weeks later, and I was involved in a discussion about a team that had tried Scrum but hadn’t had a lot of luck with it, and I started thinking about how agile transitions are usually done:

  • They are implemented as a big change; one week the team is doing their old process, then next they (if they are lucky) get a little training, and then they toss out pretty much all of their old process and adopt a totally different process.
  • The adoption is usually a “this is what we are doing” thing.
  • The team is rarely the instigator of the change.

That’s when I realized what had been bothering me for a while…

The agile transition is not agile.

That seems more than a little weird. We are advocating a quick incremental way of developing software, and we start by making a big change that neither management or the team really understand on the belief that, in a few months, things will shake out and the team will be in a better place. Worse, because the team is very busy trying to learn a lot of new things, it’s unlikely that they will pick up on the incremental and experimental nature of agile, so they are likely going to go from their old static methodology to a new static methodology.

This makes the “you should hire an agile coach” advice much more clear; of course you need a coach because otherwise you don’t have much chance of understanding how everything is supposed to work. Unfortunately, most teams don’t hire an agile coach, so it’s not surprising that they don’t have much success.

Is there a better way? Can a team work their way into agile through a set of small steps? Well, the answer there is obviously “Yes”, since that’s how the agile methods were originally developed.

I think we should be able to come up with a way to stage the changes so that the team can focus on the single thing they are working on rather than trying to deal with a ton of change. For example, there’s no reason that you can’t establish a good backlog process before you start doing anything else, and that would make it much easier for the agile teams when they start executing.


Embedded development, unit testing, and Port/Adapter/Simulator

I’ve been working on a project to decode pinball bus signals to figure out the current state of the lights on the machine.

Why I am doing that is still shrouded in mystery, but I’m to the point where I have the hardware ready to hook together for prototyping purposes. At this point, I would generally start writing code, but this is a bit more sophisticated than what I usually build – I have shift registers to read through serial, some decoding logic to write, and I need to detect whether a light is on, off, or flashing.

So, taking a page from my day job, I decided to write the code using TDD. One of the advantages at TDD is that it’s good at making progress if you aren’t quite sure what you need; you start building things that you need, and pretty soon you’re done.

Since I knew that I needed to be able to read serial data out of a the shift registers and convert it into bytes, I started writing a SerialToByte converter. And, I decided to write it in my fastest TDD language – C#.  My plan is to write the code – using as few non-C++ features as possible – get it all working, and then convert it to C++ code for the Arduino.

Once I had that, I decided to write the class that would talk with the 74HC595 shift register. Conceptually, the operation that I need to do is fairly simple:

  1. When new data is available (how will I know this?)
  2. Flip the shift register from parallel to serial mode (it’s just setting a pin to low).
  3. Read a bit
  4. Clock to the next bit
  5. repeat until 8 bits are read
  6. Flip the shift register back to serial mode

There is a problem, however; to talk to the shift register I need to send electrical signals to the hardware, which is something I can’t do until I’m writing code on the arduino and choosing pin assignments. Or can I?

The situation – dealing with external dependencies – is a common problem when using TDD, and there’s a great pattern to deal with it, which is described at length in my post: Port/Adapter/Simulator. Instead of building code that talks directly to the hardware, I can define an abstraction on top of the serial register. I’ll build a simulator that I can use for test purposes, and then a real version when I move the code to the arduino.

Here’s the abstraction (aka “port”):

interface IShiftRegister
{
byte GetBit();
void SetParallelMode(byte parallelMode);
void SetSerialClock(byte serialClock);
}

To test the code that uses this abstraction, I built a simulator (using TDD), along with a full set of unit tests for the simulator:

public class ShiftRegisterSimulator : IShiftRegister
{
public void SimulateParallelLoad(byte value) {}

public byte GetBit() {}
public void SetSerialClock(byte serialClock) {…}
public void SetParallelMode(byte parallelMode) {…}
}

The simulator implements the 3 methods in the port, and also one additional method to put values into the shift register. I also write a DataStrobeSimulator that lets me simulate an interrupt, and then I can write a test for the BusDataConverter class:

[Test]
public void when_strobe_with_a_medium_value__it_has_the_correct_value()
{
DataStrobeSimulator dataStrobe = new DataStrobeSimulator();
ShiftRegisterSimulator shiftRegister = new ShiftRegisterSimulator();

BusDataConverter busDataConverter =
new BusDataConverter(dataStrobe, shiftRegister);

shiftRegister.SetParallelMode(1);
shiftRegister.SimulateParallelLoad(179);
dataStrobe.SimulateStrobe();

Assert.AreEqual(179, busDataConverter.GetValue());
}

This test sets up the shift register simulator with a  value, simulates the strobe, and then verifies that the BusDataConverter correctly reads the data from the shift register.

So far, this approach has worked well; I’m confident that the code is pretty close to what I will need.