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.

Hardware and software engineers traditionally spend most of their time segregated. How do do we show them the value of designing together on the same agile team?

This is a real problem. We need to get engineers out of their cubes and working together. Make working together easy by investing in a decent team space. Have team meetings there. Paper the walls with the product/project information. Get some pairing stations in place and some target hardware. Create an opportunity for collaboration. Forcing people to work together won’t work. Build it and maybe they will come. There are probably people that already value working together that will use the space right away,

Also engage the team in identifying the problems they face. Once a team reflects on this, it is likely that some problems identified can be improved through more collaboration. Such as scrambling late in the project to integrate, or specific misunderstandings in the interfaces between hardware and software. Leaders can challenge people to integrate earlier because we can’t afford to wait to integrate at the end.

Tips for applying TDD and Agile to embedded development, particularly in a community that is not convinced of the benefits or willing to invest the effort required. How can an agile engineer work within a non-agile team?

Whatever the problems at your organization are, uncover those in a non-threatening way, in a effort not to fix blame, but to improve. Use project retrospective techniques. See how some of the agile solutions fit the problems people care about. Make a market for change. Foster a learning and experimenting culture.

For example: Can people agree that debugging is taking too much effort, that schedules are unpredictable, that requirements are not well understood… How long is the bug list? How fast is it growing? Do we want to try to fix that? Maybe TDD is part of the answer.

Will automated tests help find bugs sooner. Maybe we can avoid bugging the code with TDD, cutting out the need to debug it. Would shorter planning cycles be more successful and provide early warning of potential troubles.

An engineer states “I already know how to do my job. I don’t need training.” How can this attitude be overcome?

I guess things must be pretty good. Developers deliver faster than the customer wants. There are no bugs in the system. No one ever makes a mistake, resulting a new bug. Code is delivered on time, no one every has an integration problem, and they work 10am to 4pm, raking in the bonuses.

“Anyone who stops learning is old, whether at twenty or eighty. Anyone who keeps learning stays young” — Henry Ford

How old are these guys? I think it takes a person of relatively few years to think they know everything.

It’s harder to change people behavior than to implement a technical solution that [they think] won’t work anyway. How do we help engineers and management to choose the harder path?

Challenge the status quo. If everything was fine, there would be no reason to change. Is everything fine?

“Insanity: doing the same thing over and over again and expecting different results.” — Albert Einstein

Use a logic chain to tie a solution to an important problem. Then get people to try it. With iterations you can try things. Give it the good old college try. Don’t fight it for two months. If its not helping we can try something else then. The only option is not taking action to improve. Remember…

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