Edward Bear Does Not Have Time to Improve.

In many companies the software assets and practices are left to rot. This indifference to fundamental quality issues is justified with phrases like "we are in a hurry", "we need to create new stuff", and other nonsense. Software is going to require maintenance and further development for its whole life. If you neglect to keep it fit it is going to haunt you back for sure. And it gets worse. If you leave your code base and practices to rot, you will eventually paralyse your whole productiveness. See Ken Schwaber explain it in this InfoQ video.

I have used the story about timber jack being so late at his logging site, that he does not have time to sharpen his saw. Some time ago I bumped into another quote that makes the same point.

“HERE is Edward Bear, coming downstairs now, bump, bump, bump, on the back of his head, behind Christopher Robin. It is, as far as he knows, the only way of coming downstairs, but sometimes he feels that there really is another way, if only he could stop bumping for a moment and think of it.”

It really gets painful sometimes.

It's less chaotic today than it was yesterday

SD Times reviews the new, 2006 Chaos Report from the Standish Group. According the article:

35 percent of software projects started in 2006 can be categorized as
successful, meaning they were completed on time, on budget and met user
requirements.

I'm not sure if 35 percent is a good number, but it surely beats 16.2 percent in the 1994 report.

It would be nice to know how the size and complexity of average software project has developed during those 12 years. Maybe that is in the report, we just have to wait a bit more (and get 500$ for the report from somewhere).

The report lists three reasons for the improvement:

• better project management,
• iterative development, and
• the emerging Web infrastructure.

I don't know if better project management in this context means agile project management. A quote “Managers have a better understanding of the dynamics of a project.” hints to that direction. Iterative development at least is something that we believe is essential for success, and it is nice to get more and more data to show that. Web infrastructure plays quite insignificant role in firmware development.

If you happen to know recent data about new product development success rate in general, or maybe even embedded software numbers, I would be most interested seeing them.

What does it mean to be agile?

OK, the ESC2007 Conference is over. Many of the classes and especially Peer Roundtable discussions at the conference, Beer Roundtable discussions at the bars after conference hours, and long flight hours with a colleague, woke several questions, among them:

-What does it mean to be agile?
-When is an organization/team considered agile?

In his review (pdf) Dr. Pekka Abrahamsson showed the software life-cycle support of different agile methods. We know that Scrum does not have any engineering practices described in detail, but focuses on project management. That's why it has been adapted also outside software development. It is simple. This is why majority of the so called agile adaptations at least say they follow Scrum. As have we; we have used it with cross-disciplined embedded system development teams to develop a complete embedded system as fast paced iterative development. I have also written in my paper how I saw reflective iterative development as a tool itself for figuring out what practices you need. This said I share Simon Baker's post

Are you missing the point?

As long as you share the underlying values of agile development, and keep the obvious practices like short iteration, demonstrable progress and retrospectives, you are going to figure out the rest of it - or die trying or at least you figure out the need for something and can start looking. If your survival anxiety in your current environment is high, but you have juniority prevailing in your team, you can still gain a lot from practicing "just" Scrum. Scrum puts the basic structure in place with its simple rules and in my experience this is an immediate relief to chaos. This does not mean that it is easy. It will make everything visible; good and bad and needs a lot of discipline and nurturing.

With this approach, you being now out of the chaos and anarchy, it is time to bring in the engineering practices. Our case has shown that they are needed. We have experienced with eXtreme Programming (XP) practices; collocated team, pair programming (development), test driven development, coding standard, metaphor, and so on. We have seen the value in them, but not been able to actually master them in firmware or embedded system development in order to put the discipline into using them. Still we feel that we gain from practicing Scrum, and agile development as learning-driven thinking. This is the very reason why we still keep learning more skills and practices.

Are we agile? I do not know.

If your environment is functioning and open minded, and you have master mind developers in your team, why not go full blown XP right away? We have manifested that those practices are of high value, but they are hard for beginners. We now have also hard evidence to support the effectiveness of these methos (see for example the AGILE-ITEA project, run by the same Dr. Pekka Abrahamsson btw). It may be that with this approach you find out that you need some project management practices from Scrum. Who knows.

I wrote in my original paper about agile firmware development that lot of the agile programming practices for firmware development need innovative thinking. I think last week at the ESC2007 I met some of the people capable doing this. In the front line James Grenning from Object Mentor and Mike Karlesky and Greg Williams from Atomic Object. They have put these engineering practices into full use (also) in low end firmware projects. They are also willing to share their knowledge by publishing their tools as open source, and having discussions about the methods. Maybe we even become clients of these guys some day... Furthermore during the classes and discussions I got the feeling that a fair amount of people are actually practicing.

We have just scratched the surface, but after last week I believe that it is time to put some serious effort into agile programming practices, and actual firmware development. After all that is where we started this journey. It just kind a slipped into system development.

Are we agile after adapting these practices? I do not know.

The Vacation is Over - Officially

It's Monday. Back at work after seven weeks of vacation. It actually feels almost as bad as it sounds. I did spend over six weeks in Thailand. Lots of sun, beer, good food, nice people, and of course technical diving. Technical diving is a nicely balancing hobby for an agile proponent, as it relies so much in up-front plan:

Plan the dive, dive the plan.

There are very few situations where this rule may be broken. It is the opposite to my beliefs in new product development. I'm a strong believer in:

Plans are useless, planning is everything.

This Friday I'm off to Embedded Systems Conference 2007. We're planning to get together with people from AgileEmbedded Yahoo group during the conference. If you you are planning to be in San Jose keep an eye for that. If you are not planning to be there, it's better get started.

ESC2007

Embedded Systems Conference 2007 in San Jose, California, is having some interesting events. James Grenning is giving several sessions and people from Atomic Object are coming to tell about their low level system agile testing methods.

The best news is that right after my vacation (still have some three to four weeks to burn) I'm going to attend the conference with a colleague. Talking about nice return to work! I'll try to have energy to write something about the conf'.

Scrum Simulation Rocks

Last week I gave an introduction to agile development and Scrum for a global project organization in Shanghai, China. After the lunch on first day it was time for 59min Scrum simulation. I have written about bad experiences when trying to achieve too much, so it was back to the basics.

There were participants from Finland, China, and Mexico. We used the product backlog for Family Cookbook. Only addition to original Scrum simulation was the use of relative complexity estimations on product backlog items. This time it worked. Estimating the tasks in numbers gave birth to discussion on whether something is simple, or not, not just dividing an item into tasks. Some items were also soon identified to be too large to fit in one 14 minutes Sprint. Team was immediately forced to seek for collaboration with Product Owner.

On retrospective the main thing experienced was the time pressure. I do not see this as a bad thing, it is just the beginning of understanding the discipline needed for time-boxed development. Time pressure will decrease when the team builds trust and improves estimating.

Everyone valued the exercise and though that it was a good lesson. I might consider adding a separate exercise for planning and estimating before the final Scrum Simulation. With this early experience I do not think that I will ever try meaningful work inside the simulation again. The difference was so clear.

TDD'ing State Machines

I'm an electrical engineer. Everything in programming seems to be very very hard for me. Last week I spent 40 hours in aeroplanes, so I had some quality reading time. I did read Agile Estimating and Planning and Test-Driven Development from cover-to-cover. I had quickly gone through them earlier, but this was enlightening experience.

First of all, I have told that we have been trying to figure out effective TDD for our FW development. To be honest, we've struggled. We wrote tests for a state machine implementation. We expected the tests to be run in certain sequence, and that the state was always left where it should be after the test. We of course ended up in lot of rework on test code when our state machine design emerged. We thought that we need to design the state machine up-front in order to be able effectively write tests for it. This did not sound like test driven development at all. This required some more thorough thinking.

So back to my flight. Kent Beck writes that coupling is bad also between tests. A test should leave the system as it was. So writing unit tests in the same sequence as you expect your state machine to work does not seem like a right thing to do. You should be able to execute individual tests and to change the order of individual tests. So instead we are starting to recognize a single state as something to test.

Ph.D. Miro Samek writes about state machines being a killer app for function pointers. He further defines a design pattern for state chart implementation. Our state chart interface has become to be something like:

construct()
dispatch(event)

construct is self explaining and dispatch dispatches new event. We have specific event tick that gives resource time to state machine every 10ms (based on our 50Hz mains). We could also implement a timeout as OS service, and not to have local counters for timed events. Anyway, if we implement each state as a function as Mr. Samek proposes, and we hold our state as a function pointer we can write

dispatch( me, event )
{
me.myState(event);
}

We get rid of cryptic switch -structures. This solution helps us to unit test each state as a function with natural feel.

I'm going to write some benchmarking code to see the actual overhead, but at the moment I like this idea.

Driving Embedded Firmware C Project on CruiseControl

I finally made it. A dedicated page for configuring CruiseControl for embedded firmware C project. It combines some of my earlier posts, but also tries to add detail. Take a look here, and tell me what is missing.

Book: The Tipping Point

I finally read The Tipping Point, by Malcolm Gladwell. The Tipping Point tells us how little things can make a huge difference whether an idea will success or not. Will it tip or not. Examples and cases presented by Mr. Gladwell range from young men's high suicide rate in Micronesia, via fashion trends, cigarettes, children's tv shows, all the way to warning mechanism in surroundings of Boston about the upcoming attack of Brittish in 1775.

Malcolm explains, in a very understandable way, the law of the few; Mavens, Connectors and Salesmen. These are the three different personalities needed for a new idea to become epidemical. He talks about social epidemics. He then further explains the concept of stickiness factor, and the power of context.

What has this to do with things we are interested in? Graig Larman calls introduction of agile development methods a paradigm shift. When you introduce an idea of this magnitude, what you are doing, is asking people to unlearn much of their current knowledge. We of course know that the old knowledge is by no means useless, we just need to update it with some new knowledge. Never the less, introduction of agile methods and lean thinking is a novel idea in most organizations. The theories and concepts presented in The Tipping Point help us to understand the process of making this change and getting it to last. I have learned a long time ago, that it is not enough that you understand, you need to get others to get it as well.

Let's see what these theories in my opinion tell about agile intervention. In many cases, especially early in the decade, agile methods were introduced to organizations by younger champion developer, usually from position of no power. They just happened to be interested in learning and continuous improvement. They read a lot, they go to conferences, and they talk to fellow craftsmen. Furthermore they like to analyse the new things, and then tell these ideas to others. They are the Mavens. If things go nicely they will meet a Connector at some point. Connector knows everyone inside the organization, and knows who to talk to in order to get the change started. After the initial start, to make the idea of agile development really tip, we need extra ordinary people called Salesmen. They are the ones that can translate the ideas and experience reports so that we can communicate with lots of different people in order to get real structural changes to happen in an organization. Agile coaches and consultants are a good bet at this if you can not find someone in your organization fast enough. On top of that agile is a nice sounding word, and it can help to increase the Stickiness Factor. The first agile pilot project should have importance and wide enough commitment, creating the right Context for the intervention to tip.

Other literature (for example Pinchot, Intrapreneuring: Why You Don't Have to Leave Corporation to Become an Entrapreneuer, 1985) documents the same kind of process. Terms used elsewhere include 'Brain workers' who have the intellectual ability to think in novel ways and are able to argue their decisions. 'Intrapreneuers' are daring in using their vision of innovation regardless of for example political resistance. 'Gate keepers' have strong contacts to the organization's environment and have communicational competencies for making initiatives 'digestible' for the organization. Further a top management mentors, godfathers, or corporate angles are terms used for expressing the need for management commitment in such a venture.

Look at the world around you. It may seem like an immovable, implacable place. It is not. With the slightest push - in just the right place - it can be tipped.

Blogger is out of beta

Blogger is out of beta and I thought I finally upgrade my template. I'm glad I did, managing the appearance of my blog is now a breeze.

I did some rework on links as well. If you are interested in agile development methods for embedded software and firmware you should join the discussion at Agile Embedded Yahoo Group. There are some brilliant people in the group, but the group could use some additional energy.

I seem to have few regular readers, so if this change messed up your reader - my sincere apologies. This was just something that needed to be done at some point.

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.