One Team, but just a team

One of the agile development practices is One Team, meaning that team as a whole takes the responsibility. When agile team is formed by a bottom-up initiative, it will soon face the problems of limited sphere. Most of the problems in projects are not related to design, technology or engineering practices. These are the only ones that the team is capable to fix quickly through iterations and reflective retrospectives. After fixing its own sphere, the team hits the wall when working in the shadow of a large organization. This can be a stressfull situation as everything is starting to be crystal clear.

Afterall One Team is just a team.

Last monday at Agile Seminar Helsinki Heimo Laukkanen presented that the whole organization needs to be agile in order to fully harness the power. He talked about IT governance, but even faster you will notice need for change in leadership styles, design review practices, personnel development, project planning (not plan), marketing involvement, and a lot more. Even while the agile development only in technical level may be rewarding, seeing clearly the dysfunction of standard organizational processes (so called best practices) and structures will hammer down the gained team spirit and motivation, eventually forcing it back to old ways of working.

Changing these processes and structures in a large organization may be impossible with bottom up approach. Large organization has a whole process department to take care of the process. It would take a complete paradigm shift to access this process. What makes this hard is that this department is not rewarded based on project success or revenue, but the success of current paradigm - from the administrative perspective. Admitting that a paradigm shift is actually needed might feel like a failure of the department.

This is one of the reasons why agile interventions often fail, the rest of the organization fails to learn fast enough.

Come Again, What's the Cost and Overhead?

I've been implementing object-based stuff in C for embedded firmware with passing an index parameter to an array of structs, like I tried to explain here. Yesterday I remembered an article about pointer-less C in Embedded System Design and thought I will give it a couple minutes more. The article gives some ideas how to make pointers safer to use and talks about the cost and benefit of using pointers. I'm not saying anything about the value of article itself, but I got curious. I took our simple switch debounce filter routine which is used a lot, and which is typically the only one that actually implements multiple objects at run time. It uses the me index as parameter for two functions. I quickly modified the code so that both functions take in a pointer to a struct instead of simple unsigned char. I compiled both versions for Microchip 16F876A (8-bit uC) and got surprised. The pointer version used over 30% less code memory than the index version, reducing the ROM image from above 300 words to below 200 words. I then compiled the source files to give me the assy listing, and below are the results that I found for a simple function that just sets some members of a struct. Because of werd mechanism of indirect addressing in PIC micros, the pointer is actually passed just as a 8-bit register. Word of caution; we have experienced problems when passing pointers and enabling optimization with Hi-Tech compilar for PIC micros, that is another reason why we have avoided this.

The lesson; while I do believe in intuition for great solutions, it is worth to challenge your beliefs every once in a while.

Pointer version:

    30  0764             _Cbutton_construct
    31                   ;button_ptr.c: 27: me->debounceCounter = 0;
    32                          
    33  0764  0084       movwf fsr
    34                            
    35  0765  1383       bcf 3,7
    36  0766  0180       clrf 0
    37                   ;button_ptr.c: 28: me->level = !1;
    38                          
    39                   ; _me assigned to ?a_Cbutton_construct+0
    40  0000             _Cbutton_construct$me set 
                         ?a_Cbutton_construct+0
    41                   ;_me stored from w
    42  0767  1283       bcf status,5
    43  0768  1303       bcf status,6 ;carry unused
    44  0769  00A8       movwf (((?a_Cbutton_construct+0)))
    45  076A  0A28       incf (((?a_Cbutton_construct+0))),w
    46  076B  0084       movwf fsr
    47                            
    48  076C  1383       bcf 3,7
    49  076D  0180       clrf 0

Index version:

    30  06F6             _Cbutton_construct
    31                   ;button.C: 27: theButton[meIndex].
                         debounceCounter = 0;
    32                          
    33                   global _theButton
    34                   ; _meIndex assigned to ?a_Cbutton_construct+0
    35  0000             _Cbutton_construct$meIndex set ?a_
                         Cbutton_construct+0
    36                   ;_meIndex stored from w
    37  06F6  1283       bcf status,5
    38  06F7  1303       bcf status,6 ;carry unused
    39  06F8  00A8       movwf (((?a_Cbutton_construct+0)))
    40  06F9  0828       movf (((?a_Cbutton_construct+0))),w
    41  06FA  00F0       movwf btemp
    42  06FB  1003       bcf status,0
    43  06FC  0DF0       rlf btemp
    44  06FD  1003       bcf status,0
    45  06FE  0D70       rlf btemp,w
    46  06FF  3E20       addlw ((_theButton))
    47  0700  0084       movwf fsr
    48                            
    49  0701  1383       bcf 3,7
    50  0702  0180       clrf 0
    51                   ;button.C: 28: theButton[meIndex].level = !1;
    52                          
    53  0703  0828       movf (((?a_Cbutton_construct+0))),w
    54  0704  00F0       movwf btemp
    55  0705  1003       bcf status,0
    56  0706  0DF0       rlf btemp
    57  0707  1003       bcf status,0
    58  0708  0D70       rlf btemp,w
    59  0709  00F0       movwf btemp
    60  070A  0A70       incf btemp,w
    61  070B  3E20       addlw ((_theButton))
    62  070C  0084       movwf fsr
    63                            
    64  070D  1383       bcf 3,7
    65  070E  0180       clrf 0

Code smells - just refactor

As we identified, agile development puts more demand to top quality source code than we (firmware developers) are used to. Actually agile development only makes the bad quality visible to larger crowds. This fact fairly quickly takes us searching for new practices like refactoring. You can find about it in Refactoring site, or better yet from Martin Fowler's book.

There is a nice table by Gene Garcia available as a summary of code smells and refactorings. Take a look, this stuff applies to firmware as well.

We Can See Clearly Now

The beauty of Scrum, or agile development in general, is that it gets everything laid down in front of everyone. Everything, everyone, good and bad.





1. Developers learn to understand what 'done' really means, and how much effort it takes to get things done. It demands discipline not to have technical, or administrative in large organization, debt increase increment after increment, but actually do all-at-once, in parallel. At the same time the satisfaction and enjoyment from accomplishing meaninfull work is immediately rewarding.

2. Stakeholders outside the team start to understand the unpredictable nature of new product development, but also the true capablities of reliable development. Customers understand that they do not need to ask for everything in order to get at least some. Common understanding of business value (benefit) starts to emerge between the customer and developers. Managers and project managers see the effect of meaningless deliverables and context switching. Managers start to understand just to stay out of the way and remove obstacles.

Trust begins to take form.

Agile Seminar Helsinki, Fall 2006

Title says it all. Check it out.

Jeff Sutherland on the Roots of Scrum

A presentation about the roots of Scrum is available via infoQ. A 60-minute presentation held at JAOO conference about everything and some behind the Scrum as we know it today from Dr. Jeff Sutherland, the original creator of the framework. Without the need to travel. Great.

Bubble, Bubble...

We have had our continuous integration server running for a while. At this point we thought that some not so serious step should be taken. It was time to implement the lava lamps.

Being a firmware shop we obviously could not go the normal way with X10 publisher. We used our own shutter relay prototype to drive the two lamps. The relay module is normally driven with I2C -bus, but we simply used the data and clock signals to transfer pulses from pc's serial bus. The I2C bus is running at +3VDC level, so we needed to shift the 12v levels found on serial port to that level. Don't worry, the +3VDC level is isolated, so 'it should be fairly safe'. If you want help with similar hw setup, feel free to contact us.




All we did from that point was a couple of simple python scripts to drive a short pulse on DTR or RTS according the build result. This was easy with a little help from pySerial module. Shutter relay connected the lamps according the last detected pulse. These scripts are called via <execute>-publisher in CruiseControl's config.xml.

<onfailure>
  <execute command="python pulse_rts.py">
  </execute>
</onfailure>

<onsuccess>
  <execute command="python pulse_dtr.py">
  </execute>
</onsuccess>

Next steps:

1. Write an actual publisher for DTR/RTS signals in Java
2. Use our rf comm devices to transfer the build status
3. Hook another lamp to indicate the ongoing build process
4. Write a LonWorks publisher similar to X10

Mark Michaelis described their similar effort. They are a bit ahead of us.

Immediate Payoff

Ken Hughes shared his story about their first three months with Scrum development. Findings are all too familiar. There is also a nice example of excel sheet working as backlog.