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.

Certified Scrum Master

I had been thinking about taking the 2-day Certified Scrum Master (CSM) training for couple of years. Last week I finally got to the course with a colleague. My concern was that since I mainly develop firmware, I would not benefit that much from the course. I could not have been more wrong. I highly recommend CSM course to anyone involved with project work. Even if you do not believe in agile development, this course can still give you pointers on where to improve your work.

We got our training from Boris Oestergard and Jens Gloger. They have been giving in-house training in finland earlier, at least at Nokia Networks, Sulake and Accenture. We had also Bas Vadde from Nokia Networks giving an interesting guest speak about scaling Scrum to larger programs of hundreds of developers.

You can see our group photo at www.scrum.dk (photos).

Just Nail That One Thing

I have become to value that the team should be imposed to only one new thing at the time. For example bringing in team room, pair development or TDD should not happen in a huge bang but a transformation time is needed. However when I had a chance to run an agile day with senior management I forgot this important lesson. I got over ambitios and tried to achieve too many things at the time.

1. I started with presentation covering agile development philosophy, results from our experiment and also the needs for more advanced future adaptation. All this in 1.5 hours with active discussion. Try to keep your presentations focused.

2. We then applied Open Space Technology and went through three sessions. This went fairly well considering we were only 6 people and all new to this way of working. Some difficulties in coming to a conclusion, but time-boxing still helped to cover the issues.

3. At the end I tried to run a 58 minute agile simulation. I combined XP Game and Scrum Simulation and run a preparation phase with vision creation, then two sprints 10min each and finaly a closure phase. This is OK and could be done again with some slight improvements, but where I made a huge mistake, was that I wanted to wrap up the results from Open Space within simulation. Time pressure from the simulation, new practices coming at fast pace, and meaningfull work at the same time. Not likely.

So my lesson; if you have some very important issue at your hand, do not try to be too clever. Just focus on nailing the one task with the highest priority/value and make sure it gets DONE (aka implemented, tested and documented). If you chose the wrong issue, well buhuu, that's tough.

On the bright side it at least wasn't anything like Dave Nicolette described happening during Jon Kern's presentation. So maybe it was ok from the learning point of view, and at least the journey still continues.

Head up. Reflect. Repeat.

We Are not Alone

This post by Simon Baker really, really, made my day. It's good to know that the situation I'm currently in is by far not unique.

Can our agility bring about a wider culture change, at least in the program office? Maybe. It depends on the willingness of people to move beyond the comfort zone provided by a command and control environment.

Next week is going to been an interesting one.

Not So Naive Change Model

Agile methodology is not visible. I do not know what my team is doing. These are complaints often heard from project manager. Ops, I of course mean persons that understand that they are project Managers. Managing is translated into command and control. When saying "not visible" they mean "I can not command", "I can not control", or "I do not understand prototypes, show me paper".

What is described above is the impact of change, and it follows the satir change model. After a smooth start of agile pilot enabling more effective team work, all new kinds of problems start to emerge. Team learns about the actual effort needed in disciplined incremental development versus hacking, but also people who have evaluated their status by how much power they have to command and control (project Managers) may fear loosing their status. All of a sudden product gets developed without screaming, hair pulling and jumping up and down like a freaked out kangaroo. There is no room for the blame game, what is going on here? What is my role in this? A paradigm shift from command and control into trusting and facilitating causes fear among this dying specie of command and control type knowledge-work managers.

One needs to be very carefull not to interpret this new state of chaos as failure in agile intervention. This is excatly what was expected, but fear is a powerfull emotion and when in panic we do irrational things. I on my part fear what happens to a project Manager who in panic starts to act even more irrationaly (compared to my understanding of rational). As we remember from the theory of complex adaptive systems this emerging behavior is of course totally unpredictable...

...fingers crossed everyone, stop-think-act, maybe she gets agile.

Taming the Big Animal - Agile Intervention in a Large Organization

I made an academic paper about our first larger scale agile experiment available. You can find it via this link (pdf), and it can be found also from the sidebar. Also see the analysis that started this experiment.

Abstract— New Product Development (NPD) today is mainly
managed with plan-driven, relay race type, processes. Today’s
dynamic markets and new technology used in NPD result in a
possibility of benefiting from more adaptive, rugby style,
methods. In the software community methods applying this
approach are commonly called agile methods. In this study I
present experiences from a bottom-up initiative to apply agile
methods for embedded system development in a large
organization using the Stage-Gate® project management
framework. The purpose of the study was to find out whether
agile methods have a chance and how much this type of
organization could benefit from agile methods. Study supported
the earlier research showing that implementing incrementally
some agile practices the project organization was able to improve
the team spirit, motivation level, and additionally to increase
productivity. The affect of agile practices to the Stage-Gate®
framework was minimal. Through wider buy-in and
commitment, the agile development increments could be
synchronized seamlessly to the Stage-Gate® milestones. However
as described earlier in literature, top-down commitment and
changes in organization culture are needed in order to succeed in
process change. The philosophy of agile development is quite
contrary to so called traditional NPD approaches. These changes
in organization culture are also needed in order to fully harness
the power of agile development.

Can RUP Be Like Switzerland?

At one point debate on agile and more waterfall like sequential process models was claimed to be like religious war. This impression might still be seen in an large organization when agile methods are piloted for the first time. What if the Rational Unified Process (RUP) is the legitimate model for software development in this organization? RUP, being (in my and some others opinion) extremely abstract framework, could easily adapt to pretty much any methodology.

I do not hold a guru status on RUP. I have read the introduction by Kruchten, browsed the net, some papers and that's about it. Yet I propose that RUP could be seen as neutral territory for getting the advocants from both camps to work on common framework in order to let all the flowers bloom.

I know that if I was running a small start-up, and obviously using agile methods full a head, I would not concern my self with RUP because it would not offer me enough. However in an large global organization some level of legitimate system and standardization can be seen necessary, and thus I do not see RUP as bad option. Especially if RUP is already in the house.

RUP has been adopted to agile methods and vice versa starting from the early days, but some major effort has been put to this just lately. Check out:

1. Agile Unified Process (AUP) by Scott Ambler
2. Eclipse Process Framework (EPF) and OpenUP by Eclipse Community

...About Team Rooms and Pairing

Mishkin Berteig pointed to this web page about setting up a team room. This page pretty much covers everything I have in mind about the subject, especially with the links it has. Pros and cons of the team room are handled. These guys also share my philosophy about forcing these things. If you should force people to do anything, team room and pairing are definately NOT among such things. I believe these issues are automatically brought in when (if) the team jells and learns to work together.

Our Version of Primetime Emmy Award

It's been awfully quiet around here. It's just because I've been lazy busy.

During the previous Sprint we experimented a practice we called Primetime. Primetime means that immediately after the daily Scrum work was continued in the team room and by pairing for couple of hours. Of course in embedded system development pairing means pair development, not just pair programming.
Yes, yes, we all know that this should be a full day practice. But ... there is lots of other emergent responsibilities, for example maintenance and things like that. At the moment Primetime is the best we can achieve in our environment.

Tom DeMarco highlights the importance of uninterrupted work in his book. The cost of reimmersion time to flow (state of mind when developer "gets her design") is extremely high, and our experiment manifested this.

In our retrospective we easily identified five observations:

1. People got enthusiast about the design when pairing, and continued way beyond the agreed Primetime
2. Two people pairing blocks other people from interrupting
3. Emails, phone calls etc. got postponed
4. Learning was accelerated because of osmotic communication, and active collaboration
5. Defects got detected as in review process, thus improving the quality

Within this experiment the team easily achieved Sprint goals, which were set based on earlier velocity. It is too early to make a conclusion, but we decided to keep this practice.

Plans, Planning and Speculation - There's Time for Everything

It has been funny to me from the very beginning that agile methods are often claimed to lack the planning activity while the opposite holds. The difference lies in the fact that planning for the unknown becomes speculation. Prolonged speculation period brings very little added value and is thus kept to minimum in agile projects until better knowledge is achieved by active learning. Simon Baker in AGILE IN ACTION reminded about the two great early agilists believing in planning instead of plans.