Small Countries Seem to be Aggressively Agile

Google trends has been used to map agile development interest in different countries. Jonathan Cogley started it with a search for 'How Agile is Your Country'. Dave Nicolette went on with revisited search term set, and got this google trend. By choosing the regions you find (at least I did at the time) Finland in 10th place. So it is no wonder agile conferences in Finland are packed.

Prisoners of Our Habits - Act Four

Prisoners of Our Habits. Act three. Executive manager enters.

Executive manager is reading an email from project manager
"Dear Sir, I overheard this developer, John Smith, saying
his technical solution may cause $1.00 increase
in bill-of-material."

EXEC'MNG: -"Stop the press. This John Smith starts
immediately to investigate alternative solutions,
what ever they are."

Product under development may have hundreds of relationships. Tradeoffs between these relationships are being made in hourly basis. When one of these issues gets taken away from the context, it may seem like a big deal. The big deal in fact is when a bad decision (based on bad information) like one above is made the project environment, a complex adaptive system (CAS), gets an unexpected input. What happens in CAS is totally unpredictable. Typically the system is pushed into chaos and disorder. This is why agile development blocks these inputs from the team for a certain time, and opens the window for these new inputs only frequently enough. Command and control is traditional way of managing projects. Developers have not been encouraged to self-organize traditionally.

And old habits are slow to die.

I know paradigm shift is extremely slow, and so does James Shore (see his Change Diary). I'll be on vacation for couple of weeks and after that it would be perfect time to reflect and adjust the course of this agile journey. I just hope couple of weeks is enough for the old batteries.

Prisoners of Our Habits - Act Three

Prisoners of Our Habits. Act three. A manager enters.

DEV -"We should try to learn new ways of doing thingies 
      around here. We could participate in action research
      program, you know?"

MNG -"Hmm, That sounds like a lot of money. We could buy 
      a lot of chairs in two-day course for that. Wouldn't 
      that be great?"

...

There is a huge difference between being teached and learning. To start with there is a difference of acquiring existing knowledge versus creating new knowledge. Further there is a huge gap between action learning and a static content course which may have zero contextual relation with developer's current situation. I have seen the affect of these courses, and it does not impress me. It is just like many other mental models in this industry; a pretty model without connection to reality. But hey, traditionally developers have not taken part in action learning.

And old habits are slow to die.

Prisoners of Our Habits - Act Two

Prisoners of Our Habits. Act two. Project manager enters.

PM:   -"You need to focus on project's
        paper deliverables for the next two months"

DEV1: -"Which papers you mean? For whom they are,
        and for what purpose?"

PM:   -"I do not know, but reviewers know all the
        buzzwords, so my ass needs to be covered."

DEV1: -"Eh, That does not sound so valuable and motivating?"

PM:   -"It's not supposed to be. I fill in dashboards
        which no one reads. You should have no problem
        creating papers with no value."

...

The above is not a Dilbert strip. It is status quo in many development projects. Dashboards illustrating Gannts, PERTTs etc. are what we traditionally use for project management, and paper documents are what we traditionally use for progress monitoring and project quality assurance. So what the hell is wrong with that you ask? Again, it is a nice model, I really do like it. It has only one flaw; it does not hold in reality.

Then again working prototype, incremental release plan, Sprint backlog, or burndown chart are not used traditionally.

And old habits are slow to die.

Prisoners of Our Habits - Act One

I have been describing continuous integration for an embedded firmware project targeting a low-end microcontoller. Based on discussions I see a need for pointing out something about my view;

I do not mean that you need to apply continuous integration, unit tests running on both the host and target, etc. if you are writing a 200 LOC blinking LED application for 8-pin microcontroller for fun. This is a job for Solo-Virtuoso, and methods should be alike. The project I'm talking about, while targeting the low-end microcontrollers, will develop tens of thousands of lines of C source and will eventually be compiled into ten or so configurations for mass production. The configurations have some special areas where expertise is needed, like power management and wireless RF technology. This type of project cannot fit the Solo-Virtuoso category. Instead it requires a collaborative group of people - a job for an agile team and this team should adapt these practices.

Purely based on my biased participant observation, the trend of firmware projects is towards bigger and more complex so we are going to need these practices. The problem in firmware domain is that former electrical engineers (now programmers, or even worse, managers) are not willing to see this increase in complexity, but remain prisoners of their old habits. They are still in denial. My recent experiences manifest this very thing.

Prisoners of Our Habits. Act one. Programmer enters.

A colleague following our agile journey mentioned that based on his observations of daily Scrum meetings and collaboration we continuously run into problems caused by someone changing an interface and all of a sudden none of the configurations work. His obvious solution for this was; "there is a need for up-front designed interface contracts between modules". Problem solved, eh? We do not have full set of requirements, nor the freezed hardware architecture. For me iron-bound interface contracts seem pretty far fetched objective, but then again, it's just me. Still I would be amazed (but happily so) to find this wizard pulling out a comprehensive up-front architecture for us. Oh, and preferably delivered as a PowerPoint presentation I might add. If you happen to know this guy, ask him to drop me a line. I could use a good laugh.

I see these discussions about interfaces as a solution, not the symptom. It is good to see team members having courage to change things, to refactor when opportunity arises. These conflicts usually get solved easily after the daily Scrum at latest, so to me these are just short architecture meetings. In addition there is a huge difference compared to normal high ceremony architecture meeting: decisions get made and implemented immediately and feedback is available the next day. I have witnessed this working extremely well, and fast, even with programmers with junior skill level. This is just not the way it has been done traditionally.

Old habits die slowly.

Agile Business Conference - Program Draft Available

There is a program draft available for this year's Agile Business Conference in London. I have attended this conference for two years and I can recommend it. It is organized by DSDM Consortium and the title has word 'business' in it, but the agenda is about agile in general. This years highlight for me seems to be 'Agile and Embedded Systems' (Pekka Abrahamsson) . I'm also very interested in presentation by Mike Criffiths - 'Utilising Agile Methods Alongside the PMBOK Guide'. I see very little value in this balancing, but this is something we currently often need to live with and nevertheless we should always remember and reflect where we are coming from. This helps us to understand where we would like to go next (post-agilism).

Again interesting to see keynotes from Kent Beck, Sean Hanly, David Taylor and Polyanna Pixton. I really hope I'll be able to make it! If you are planning to be there, and are interested in agile [product] development, drop me a line and we will catch up.

Objects and Firmware - Inheritance

This is the third and last post (see earlier basic encapsulation and polymorphism) about object based firmware programming. This is about single inheritance, another important object oriented principle. This is also pretty much as far as I would go with the HW currently available for our embedded projects, low-end 8-bit microcontrollers. Anything further would require even more use of pointers, including function pointers, and I'm not really that comfortable with their heavy use.



The sample code implements a simple Level object type which has only two members, level and currentState. The first one holds a threshold value, the latter indicates wether the latest sample was below the level (currentState = 0), or equal/above (currentState = 1).

Next we have used Level as a parent for another object type, LevelWithOffset. The new object has the Level type as its first member, named super. This gives us possibility to use pointers to both of the object types in similar way. LevelWithOffset object type has an additional offset member. Value of offset is added to set level. In the example code we have two objects, one simple Level and one LevelWithOffset. Constructor is called for both setting the level to 2. The LevelWithOffset object is then further adjusted by setting the offset also to 2.


The main loop calls the notify method for both objects with values from 0 to 4 and outputs the state of both objects. We can see from the test run that the other object switches the state only after the sample is increased by 2 more steps (effect of additional offset).

You can go a long way with this object stuff in C. If you are interested then check out the papers listes below and start working on your skills and creating your own opinion.



Miro Samek, Portable Inheritance and Polymorphism in C, ESP (pdf)
Ron Kreymborg, Single Inheritance Class in C, Dr. Dobbs Journal
Matthew Curreri, Object-Oriented C: Greating Foundation Classes, ESP (part2)

CruiseControl Configuration for GNU Make

I promised to share the CruiseControl config.xml file we use. Here you go, it is not much of a contribution, but I hope it helps some of you jumping into cruising mode. Our configuration file uses the Exec builder for GNU Make automated builds. Typical examples use Ant in Java environment.



For additional information:

• Martin Fowler, article on Continuous Integration
• Lasse Koskela, Driving on CruiseControl Part1 and Part2
• CruiseControl Configuration Reference

See it in action in my earlier post.

Agile Methodology is not a Religion, it's Just a Passion

I spent three days in Oulu, Finland, attending the XP2006 conference. I have attended other agile conferences, but this was the first time I attended this conference, which was the 7th in series of XP conferences. I have to say I was impressed. The conference is about practitioners to the degree that you really get to sense the belonging in a community of practice. Authors of best selling books, key note speakers, most successful agile consultants in the world, signers of the original agile manifesto, other practitioners from all around the world, all open for discussion on this shared passion, without trying to close a contract before telling more.


I saw that strong passion of doing things right as the combining force of this community.

(Some) People are passionate about religion, too. This is why I think agile thinking is sometimes compared to religion, and comparison of agile and waterfall like methods is said to be a religious war. I saw nothing like religion (at least in a bad sense) in this conference. Instead lots of presentations and hallway talks alike concentrated on balancing methods, applying best from the both worlds, taking existing organization culture into count etc. I do not see this resembling fundamentalist religion at all, do you?



I have to say that in the early days of agile movement I sensed that strong black and white positioning as well. I participated in that. This I believe was the result of so strong survival anxiety after being so fed up with the situation and just wanting to get rid of the old ways of doing stuff all at once. The brilliance of agile methods is manifested in what we are experiencing now. We use continuous retrospectives to improve the method and to adapt it to changing situation. This is possible because practitioners are passionate and enthusiast and put lot of effort into keeping the method fit and healthy.

Sean Hanly from exoftware pointed out in his key note that we must be careful not the end up in the process graveyard with the famous "failures" like RUP, CMM(I), Waterfall and numerous others... By saying this Sean meant that the interpretation of original methodology is in danger to get twisted when number of interpreters increase. When agile development is moving into mainstream we are going to see a lot more practitioners without this passion, but just making the use of a new tool.

There are photos from the conference...

Comprehensive Documentation for Riding a Bike is Difficult

Nonaka and Takeuchi (1995) defined knowledge as explicit and tacit. This view is of course shared with other researchers in organizational learning.

I posted about agile development emphasizing Enable Future Work -documents (as described by James Shore). That holds, but it still does not make creating quality documents easy.

Day after day engineers will arrive at work and launch MS Word alone because they need to document their work for future use. Unfortunately some will open the same tool for documenting what they are planning to do, but this is Get Work Done- documentation (as described by Jim Shore), and we are not talking about that now. At the exact same time same number of engineers will get a copy of such a document to start working based on it. By the lunch time most of them have realized the same old thing; "Just words, not even grasp of what I would have needed, half a day wasted, thank you very much."

I'm reading the Communities of Practice, by Etienne Wegner, for the second time. This time I understand a lot more, but of course I am still not fully getting it. However Etienne gives good example of two sides of knowledge, explicit and tacit. Mr. Wenger used skill of riding a bike as an example. Most of us master this skill, and we can explain it - even fairly well - in paper;






"Push some initial speed, start pedaling and just steer where ever you want to go. "






This is the explicit part, but there is one fundamental ingredient missing in the above document. How do you keep the balance? This is the tacit knowledge part, and it is extremely hard to put on paper. I give you few minutes to think about it...

OK, I tried it also while reading the book, and it reminded me about something we all have experienced.

Agile methods promote simple design to the degree that documentation is not necessary. In embedded world where you want to minimize the material cost you often end up in software and hardware design which are based on intuition. This tacit information is difficult to put on paper, just like the balancing bit of riding a bike. How many times you have been explaining your design to a peer until a bit of detail which has no meaning to you opens the design to your colleague? These obvious facts seldom get identified and reported in paper document created by the original designer individually. As a consequence the document has little or no value. This was manifested with our three-day faceoffs recently. This has nothing to do with agile development methods, since they promote simple design and light documentation?

Quite the contrary. Agile teams work well in preserving and sharing tacit knowledge among members. Daily meetings, retrospective and pair programming(co-design/debugging) are natural techniques for this. Additionally the team commits to deliver work (software/product) which is "done". Done means delivered with just enough and barely sufficient documentation. Agile team should have also shared commitment to deliver necessary documentation, which would enable them to create the documentation in collaborative way. This type of activity is valued in RaPiD7 (Ph.D. pdf), an agile method for creating documents developed at Nokia. Of course the best thing would be to have the "customer" of a document present during the creation work (or that the "customer" writes the document as Vasco Duarte proposes), but this customer for Enable Future Work -documentation is often not available at that point.

The next best thing might just be a collective team responsibility with other project stakeholders and to give it your best shot from multiple perspectives instead of single unmotivated view.

embUnit has some additional features

I posted about my options for proceeding with CruiseControl. A while ago I already wrote a python script which ran the unit tests, and interpreted the results into XML following the JUnit schema. This seemed to be working, but there was one major problem. embUnit output did not include any detail about successfull tests. So I started looking my options again. I took a look at CUnit. It has XML output for its own translator, but this of course does not follow JUnit schema either, so I was not getting any closer.

Then while browsing through embUnit source I made an interesting discovery. The code for embUnit library does not require standard C libraries. This I believe is the embedded part of it. In the distribution there is however additional source code for two different user interfaces; 1) text and 2) XML. These can be compiled into another library (the basic libary comes as binary with distribution), which can be used for host run unit tests. Two libraries can be tied together with nice function pointer usage, similar to what I tried to explain earlier. Everything is coming together beatifully. Example of generated XML report is below. This again does not of course follow the JUnit schema, so I will continue by modifying the CruiseControl XSL translator for it.



To be cont'd...

Celebrating the Complexity - of Life

I just finished reading Stephen Denning book 'The Springboard: How Storytelling Ignites Action in Knowledge-Era Organizations". Easy to read, entertaining material, explaining the power of light touch of storytelling having huge impact. Of course one has to admit that just by reading a book, one won't become the most successful change agent.

I liked the phrasing in the last page:

'...Living instrumentally to achieve explicit fixed objectives is less important than living moment by moment, day by day, appreciating difficulties as much as success. It is a matter of letting go of the urge to control, and the fear that goes with it - learning that the world has the capacity to organize itself, recognizing that managing includes catalyzing this capacity, as well as sparking, creating, unifying, generating emergent truths, celebrating the complexity, the fuzziness and the messiness of living, all the time relishing the sense that almost everything one thinks or knows about the world has turned out to be fake." (Denning, 2001)

I wonder if storytelling is really all it takes. We all know what storyteller Kent Beck achieved with his book.

Original '51 is going to retire

Intel will stop producing embedded processors, including 8051, in 2007. Read what Jack Ganssle wrote about it.

Reserving the Right for Technical Excellence

"...and then the administravite party decided it's time to spend a month repairing and polishing documents, as they seem to be demanded. " I had a nice discussion with two researchers a week ago who have experience in studying NPD processes, also globally. The above phrase is still common. They shared this with a weird smile on their faces. I feel panic closing.

Which documents? For whom? For what purpose? These in my opinion (Vasco Duarte seems to agree) eligible questions all remain unanswered to the date. Of course the idea behind this madness is to offer a project steering committee possibility to control the project (once a year, I'm not even going to get into this). Most of us know that - at best - this is only an illusion of control. Yet, repeatedly the rare resources of a project are streered towards creating this illusion. At the same time people on this same planet are talking about innovative knowledge creating organizations, rapid time to markets etc. Yet some New Product Development can afford spending a month putting 50% obvious facts and 50% of nonsense into form of Word document at the early stages of development?

What do they teach you in courses dealing with panic?
Right, STOP-THINK-ACT

I felt panic, I stopped and I been doing some thinking. What is wrong with this environment? What is there to do? I could apply my (and pretty much majority of developers) favorite "Yes, it is 80% done, and will be complete in - yhm- couple of weeks" -continuity of answers (of course not having a clue what the task in question is). This is not making me laugh anymore, so I propably won't.

Projects that succeed under this type of project management typically have developers which are in "Don't Ask, Don't Tell" mode. I did this for a while. I'm not amused anymore. I do not want to keep up the smoke cover-up. **I want it visible**
After all I think I really need to reserve my right for technical excellence without cover-ups. Always.

Dr. Cooper has acknowledged this and updated his Stage-Gate with seven F's and other guidelines for adapting the model to be more flexible. Phased process models, like waterfall, and early Stage-Gate, survived for 50 years. Transition is ongoing, but all too many organizations remain in denial.

Suddenly at 35 I feel pretty tired, weak and old...

The Seven Principles to Success Revealed

Dr. Robert G. Cooper, the author who introduced the Stage-Gate process model first in 1988, published a Working Paper No.23 recently. In the paper he lists seven New Product Development (NPD) principles that high productivity businesses practice. Data shows that productivity in top organizations can be five times what it is in average company.

The seven principles:

1. Customer focused
2. Front-end loading
3. Spiral development
4. A holistic approach
5. Metrics, accountability, and continuous improvement
6. Focus and effective portfolio management
7. A lean, scalable, and adaptable process

Where have I heard this before?