Stories often start out too big. Big stories are a challenge, and it is not always obvious how to deal with them. Its important that stories be small enough to estimate, to fit easily into an iteration and to have a decent definition of done. This article explores why some stories don’t fit this mold and what you can do about it.
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.
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.
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:
The Microsoft Zune 30G had a well known crash to bring in the new year. Here is the snippet of code that is the alleged culprit, from one of MS’s suppliers (Freescale).
Coupling and cohesion have been discussed for a long time as the right criteria for judging a design. But there seemed to be no objective way to determine if code exhibited those qualities. Could TDD lead to higher cohesion and loose coupling?
I’ve been talking Agile at the Embedded Systems Conference. Last week was my 7th year of participation. A few common questions usually come up. I’ll paraphrase the questions and answers.
I keep hearing that you can’t write unit tests for device drivers. I don’t believe that’s true. To disprove this claim, I thought I would find a device driver and write some unit tests for it. This blog posting shows what device driver unit tests look line.