Browsing posts in: Agile

Fame and fortune by being slightly better

I’ve been attending our local lean coffee agile lunch (“lean lunch” sounds like something different…), and our discussion last Wednesday included something that I was meaning to write up for a couple of months, so here it is.

The setup is that we were discussion why agile adoption – XP adoption specifically – was so poor when the results were so obviously better.

This issue is the way management culture works and the way the incentives are structured. Let me posit two different groups.

The first lead – let’s call her Traditional Teri – does the existing company methodology well. Her team does code reviews, they do decent designs, they fix the right bugs first, and they take corrective action early.

The second lead – let’s call her Radical Rachael – is an agile advocate. Her team does decent agile; they do pairing, TDD where appropriate, story-based design, incremental releases, experimentation, etc.

Just to pull some numbers out of the air, Teri is about 20% better at getting software to market than her peers, and Rachael is about 100% better.

Who will be more successful at most companies?

We would all love for the answer to be “Rachael”, but the answer is, in fact, “Teri”. Almost universally. Because the cards are stacked against Racheal:

  • Rachael is doing something different and therefore risky. Just like “nobody ever got fired for buying IBM”, “nobody ever got fired for using the same slow and bug-prone development methodology”. If anything goes wrong, Rachael is at a big risk regardless of whether it is a result of her process choices or not.

  • They have different levels of peer acceptance. Teri is better than her peers, but only by a little bit and her peers can see how to get to that better level. Rachael makes her peers *look bad*. If she is doing the right thing, then they are clearly doing the wrong thing, but her peers don’t understand how to do what Rachael does nor do they want to. This is a built-in incentive for her peers to actively make Teri less successful or appear to be less successful because it makes them look better.

  • Teri is a joy for her manager Susan. Teri is never the problem team on projects, she has extra time to help out others, and Susan’s world is consistent and understandable. Rachael is a big pain for Susan, as she makes waves. Susan is forced to deal with different processes across the teams and field questions that come from outside the group as to why Rachael’s team is different. The outside discussions are very bad, as they make Susan look like Teri; now Susan has to convince *her* peers that what Rachael is doing makes sense, which isn’t good for Susan’s career. And like Rachael, Susan is running the same risks if anything goes wrong. The best thing for Susan to do is to actively hide what Rachael is doing, which means that Rachael won’t get credit for her team’s success.

  • Rachael is running a “no drama” team; because of her team’s process choices, they write very few bugs and they don’t have to work extra hours to get things done. But that looks like a team under the conventional process that is lazy and not working very hard, and since it takes a lot of effort to understand how objectively hard a team’s work is, the feeling that they aren’t working hard overshadows her team’s productivity. This is frankly a bit of a problem for Teri as well, but to a much lesser degree.

The end result is that Teri has much better career prospects at her company. It’s *easy* to make a case why Teri should get a promoted and why she would be a good choice as a second level manager, and the discussions that Susan has to have to convince others that Teri should be promoted are comfortable. And Rachael won’t get that promotion because Susan not only has a harder time making the case to Susan’s peers, it is not conducive to Susan’s career aspirations to have those process conversations.


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.