Deep Agile Panel Questions – Documentation

This is the third in my Deep Agile Embedded Panel Questions series. The question is:

We had a team doing agile. To them that included not doing any documentation. We need documentation once we go into maintenance. Is doing documentation allowed in Agile?

The short answer is yes. Agile does allow documentation. Do you think agile is a totalitarian dictator? 🙂
Continue reading

Deep Agile Panel Questions – Change

Prior to the Deep Agile conference, I received a number of questions about getting people to change, to try new things. Change is hard. People need to be motivated to change. “If it ain’t broke, don’t fix it” they say. But there is always some things that are broken.

First there needs to be awareness/acceptance that there are problems to solve. Do a retrospective of the last release. Find the problems that people are passionate about. Try not have blame session. Build a logic chain from the problem to some solution you think will help. Get people to sign up to try the new approach for a month or two, not the rest of their lives. Iterations give a great opportunity for this kind of experimentation.

You have to try things, rather than just talk about them. I am not sure where this quote is from, but it is profound:

“It’s easier to act your way into thinking differently than to think your way into acting differently”

Read on for some specific questions, and my answers.
Continue reading

Deep Agile Embedded Panel Questions – Hardware

Last weekend was the Deep Agile Embedded Conference that I participated in. In this article I’ll answer some of the panel questions related to concurrent hardware development. There seems to be a theme here, because the hardware is involved, an embedded development team really can’t be agile. That’s not my point of view, or my experience. I am not a hardware engineer, but I have worked near them. Let’s see some of the questions and answers.
Continue reading

Don’t Let Embedded Tool Chain Slow You Down.

During my TDD session at the Embedded Systems Conference yesterday, I did a demo. Before the demo, I make the case for TDD as a way to prevent bugs (see Physics of TDD). For the live demo I usually code on my mac and run the tests there as well. The question always comes up: “You are running tests on your PC, can you run them on the target?” or maybe “Sure you can TDD on a PC, but what about the real hardware?”
Continue reading

Deep Agile Embedded Brain Storm

Let’s say you were an embedded systems developer, and you were planning on attending a conference like the Deep Agile Embedded.

What questions would you hope you could get answers for at the conference?

What if you already knew it all but were sending your boss, co-worker, or CEO who needed to learn more, what would you want them to hear about?

Would you want to do some hands on Test Driven Development?

Here are some of the questions we have so far:
Continue reading

Planning Poker Party (The Companion Games)

High-Low Story Showdown, Deal and Slide, Developer Guts, and Customer Guts

It’s sprint zero and you have a stack of stories needing a first estimate? You need an initial release plan. What should you do? It’s kind of hard to start on day one with Planning Poker. There is a missing baseline to estimate against.
Continue reading

Crashing Your Way to Great Legacy C Tests

Adding tests to legacy C or C++ code can be a challenge. Code not designed to be tested won’t naturally be testable. Dependencies will be unmanaged and invisible. Getting that first test written will hurt, a lot. Don’t despair! The first test is the hardest, but subsequent tests are much easier.

Knowing what to do and what to expect, when you start adding tests to your legacy code, can ease the journey. This article will give you an idea of what to expect when getting that first bit of C or C++ into the test harness.
Continue reading

Agile 2008 – Wisdom of Crowds Keynote and Planning Poker

At Agile 2008 James Surowiecki, the author of Wisdom of Crowds, gave the opening keynote address. If you have an opportunity to hear him speak, take it. He did a great job. No power point slides with a compelling style and message. Continue reading