Weekly Delivery of Firmware

Yesterday we finished a six week project developing technology platform for User Interface innovation using some practices familiar from agile methods. The project delivered two different configurations of home automation user interface device; one for wall mounting and one for remote control. Some facts:

• Vague or missing requirements
• New 8-bit microcontroller
• Lots of new sensor technology
• New embedded firmware team of 3+1, including one consultant (in house)
• Some drivers developed by outsourcing
• Final project consisted of 20KLOC of firmware C source (bad meter, but...)

Some findings after initial reflection:

• Weekly delivery (not release) of firmware is possible, at least in some cases.
• Short term goals and daily Scrum meeting effectively work as motivators, and enforce full learning and getting things done done.
• There is not small enough project to not use version control and continuous integration (we had no way to have common version control with outsourced team: large org, IT, you know the drill...)
• HW evolved from microcontroller starter kit to final electronics via several bread board mocks and one halfway PCB prototype. This causes extra assembly work when looked at the surface, but this overhead is by far overcome by enabling the concurrent engineering instead of waiting for final version.

The last point holds only if all the disciplines work as One Team.

We did not have cross-functional team as we did in earlier larger experiment. Schematics, PCB layout and mechanics were developed concurrent, but they were not part of the team - nor did they follow any of so called agile practices. Firmware planning was tried to be synchronized with deliveries from other disciplines. In several occasions these deliveries were delayed, and a common goal needed for a team to actually be a team was somewhat missing. This is where I would like to do things differently if I was to do it all over again.

Occasionally we heard sentences like "If everything goes smoothly we will be ready on Tuesday, but we will be ready at least on Thursday". At this year's Agile Business Conference in London David Taylor (The Naked Leader) said "Don't have a plan B because you will always achieve it." Just guess if the delivery was on Tuesday or Thursday - or Friday?

The whole project was started by extremely vague idea. In few hours we worked out initial backlog and a delivery (release) plan based on simple themes. From that point on plan, design and requirements emerged during the 6 weeks nicely synchronized with weekly demonstration of prototype and new planning session. This experiment supports the belief that good people can work this way, and that we truly live the era of enlightened experimentation. We believe that we could not have performed any better with thorough analysis, design, and specification phases - at least not to cover the cost of them. During the development there were several points where it was not possible to proceed as we had thought. A comprehensive plan based on these initial assumptions would have failed miserably, and the time creating them would have been wasted. In this project the whole team worked out an alternative solution, adjusted the next week's plan, and the project was fine...

I will write an experience report and hopefully make it available here.

Skunk Work Is Not A Longterm Solution

In her "The Agile/Waterfall Cooperative (pdf)" presentation Michele Sliger summaries three modes in which agile team can work in a waterfall organization; SWAT team, Skunk Work, and stealth agile. I agree that applying just some agile practices can benefit your work. This is pretty much what we are doing at the moment, but I do not see this as sufficient long term solution - if it is only in team's sphere or just above. All three forms of team work can of course be used. SWAT teams can go parallel even in more wide spread agile organization. Skunk work probably, and hopefully, always exists in large organization - it's fun. If you are working as stealth agile, and avoiding radars by not communicating to the top management, you are not going to be able to fully harness the power. You need to inform top management that you are doing things differently and communicate your need for changes. They probably will not get it, but what they do get - is success. So it is fine and in most cases necessary to fly low at first, but after certain point it is not satisfying anymore to work as a shadow system, because you know you are constrained by the legitimacy structures, and these structures are holding back you and your learning.

The rest of the presentation has also good ideas, and based on my experience these ideas hold in reality as well.

SWAT team – outside the domain of the process police, brought in on projects that are in trouble. Agility is prized in this situation. They take over however – they don’t work in a cooperative mode.

Skunk Works - “a small group of experts who drop out of the mainstream company operations in order to develop some experimental technology or new application in secrecy or at speed, unhampered by bureaucracy or the strict application of regulations.” Sanctioned and protected by management, these teams are rare. This formation however, prevents the headaches involved in org structure, project approval hoops, portfolio metrics and management, budget calls, and other bureaucratic nightmares.

Stealth Agile – As Jim Highsmith once said in response to a question about how to sell agile to upper management – don’t. “They don’t know what you’re doing anyway.” Do as much agile as you can where you can. Some benefit is better than none at all.

Link: Scrum and XP from the Trenches

No matter if you are developer, PM, or CIO and you don't know what agile/Scrum/XP is, you are thinking about applying, or you are already practicing - you should check out "Scrum and XP from the Trenches (pdf)" report from Henrik Kniberg. Henrik describes how they applied Scrum and XP practices in real life and presents the adaptation needed in this situation. Excellent Writing!

main_theOneAfterFinal.c

Today I happened to see a file name with word 'new' on it on a presenter's computer. I was slightly amused because of my history. I can still see the old version naming convention in many "shared team folders" in our server. It goes something like this:

original
new
latest
final

I have been using version control system since my first university years (some fifteen years ago) and throughout my professional life. First it was just an advanced XCOPY method putting released versions of one man projects into the system, but about three years it has been collective code ownership and at least daily update-commit (we use CVS) cycles from the beginning of development. Lately we have adapted continuous integration and automated regression (confirmation) testing as you know. Currently we are looking for ways to add some automated acceptance and system testing as well.

During the past couple of years I have had a pleasure to work with software developed outside our own company. Quality of source varies a lot of course, but it is striking that version control typically is not even mentioned. In some occasions lately the software was delivered as zip'd folder with a version number in folder name - at that point I was happily surprised by that! Embedded firmware domain - based on my biased observations - walks some 10 years behind the mainstream software industry. The wide lack of basic discipline, version control, proves the point. I'm glad that I work in a department where I can say that developers would never go back working without version control.

I found this Yahoo group message - nostalgic.

The Lenghty Debugging Phase

To give embedded firmware TDD a kick start we have had two sessions with a colleague. During these sessions we have created scripts to automate the unit test structure and build process and discussed how the make as thin wrappers for HW as possible. However we learned also other valuable lessions during these sessions. Lesson number one is the "debugging phase" being so strongly in our domain culture. We often hear a firmware developer saying, "well, it takes couple of days to implement it, but you can never tell how long the debugging is going to take". Of course debugging phase is where all the firmware heros truly shine. That's another unfortunate culture issue in firmware development.

In our first session we ran into problem of not getting one test running. Immediately we started debugging. Printf's fly in here and there (as an advanced host run I/O twist). The change to this mode was so rapid, that neither of us realized what is going on until later. After some 30 minutes(!) we recognized that we are not moving, but just desperarately experimenting with printf's, and it hit us; we have not changed our behavior as we were supposed to. We should have picked a more simple thing to implement. When we realized we can not chew what we had chosen, we should have started all over again with simpler thing.

It is our belief that by doing TDD for firmware we should get rid of, or at least dramatically reduce, the debugging phase and thus create an atmosphere of success, and improve the reliability of estimates.

This type of sessions are great tools for learning. I strongly share Michael Harmer's opinion on The Training Course Scam.

Ken Schwaber on Quality of Code

Ken's presentation "A Canary in a Coal Mine" at Agile2006 conference is available via InfoQ. Ken talks about quality and the danger of Scrum teams droping quality issues to get higher velocity and to be sure to hit the date. He calls this a re-definition of "done", or "somewhat done". We have manifested an increasing technical debt in our iterative work. So in the last project we were putting more focus to acceptance testing inside each sprint and introduced something we called "cross-testing". This means that other pair needed to test the feature implemented by other pair in order to claim feature "done". Embedded firmware systems need a lot of manual acceptance testing (at least our current practice) and it is easy to get slobby testing your own work over and over again.

Was the technical debt there because of Scrum? Well, no - it was made visible by Scrum and the team was able to decide to do something about it early enough.

----

Ken's another speech about Scrum is available at Google Video. (You will find out that Scrum works with idiots as well)

I posted about Jeff Sutherland's Scrum speech earlier. It is also available via InfoQ.

XP2007 Conference Web Page

XP2007 web page is open. The conference will be held on June 18-22.2007 in Lake Como, Italy.

In the scope of conference is:

• Embedded software (e.g., SW/HW co-design) and Agile SW development

...among of course other interesting stuff. Hopefully we see some papers in this domain as well. I attended the conference this year in Oulu, Finland, and if next year's event is anything like that - I can highly recommend attending.

NPD in General With Agile and DSDM

Iterative and incremental development ideas have been presented for general new product development (NPD) for years. I'm interested in agile methods (as in software development context) because they give a philosophy behind and lots of ideas how to actually do this. It is of course also because of extremely active and powerfull community. Ideas of using these methods and practices in NPD in general have been presented by Jim Highsmith (Agile Project Management), Preston G. Smith (Developing Products in Half the Time), and many more. Both of above mentioned can be contacted via Cutter Consortium.

Now there is something new coming up. At London Agile Business Conference 2006 few weeks back the DSDM consortium talked about the future of the DSDM framework. DSDM version 4.2 has been open for online viewing since this year. They are going to publish a new version of framework in Spring 2007. This new version is supposed to be more general and not specifically targeted to just software development. It was also presented that DSDM can be seen as a wrapper for models like Scrum and XP for use in enterprise environment. It's a bit too structured to my tasting, but very well worth to check out when available. It may also become more open.

Risky Business

It has been identified that the biggest risks in project work concern management and marketing. Yet, in most environments we only concentrate on technology risks. Agile, incremental and iterative, development is also often assumed to be risky. By changing the way of thinking about risk, people would see that iterative risk management is a proactive way to tackle all aspects of risk. A very simple way.

1. Management risks - just fund the project for the time zone you are comfortable

2. Marketing risks - use the first possible release to test the waters

3. Technology risks - use the effort early to tackle any technological uncertainties that traditionally are left lurking until the (assumed) end of the project

The status quo practice is quite different. We take huge risks by starting a megaproject, for example estimated to 5 calendar years, based on a business case. Everyone knows that business case targeted five years from now is pure speculation. In the global markets it's a very expensive speculation by the way. Based on this speculation management needs to make a decision for funding a five year project. Their natural reaction to tackle the risk is to review the project mercilessly. We can be sure that changes to project requirements, technology and scope will happen. We have this heavy review practice going on making the project move even more slowly. More time means more changes, more changes mean more reviews - are you starting to get the picture?

Most of us see this everyday. How do we try to fix it? Naturally by reviewing. Because? That's what we allways do.

Refactoring for C

SlickEdit is a commercial compiler source editor that many people speak highly about. I thought I will give it a spin and downloaded the trial version. Their web page describes "cool features", but for some reason refactoring is not listed. Anyway the product has capabilities for refactoring several languages, and few quick refactorings (based on tagging instead of parsing) even for C; extract method, rename, modify parameter list, and replace literal with constant. At least for simple code they all seem to work. SlickEdit is also available as Eclipse plugin. I only tested the own IDE version.

You can find out the reason why there are not so many refactoring tools for C from MS and doctorate thesis by Alejandro Garrido. They are available via this site.

Web Page for Embedded Unit

Embedded Unit (embUnit) is an unit test framework for embedded C systems. It now has a simple web page with manual. It is not pretty, but it is something.

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.