We’re happy to have another guest contributer to the AgileSoC blog. This one is special because it’s a case study on an exercise I’ve written about before and presented as part of my talk at Agile2011. I’ve called it The Steel Thread Challenge to reach the software crowd and Operation Basic Sanity to reach the hardware crowd. These are 2 different names for achieving on goal: finding ways to help hardware developers think in terms of early functionality and tangible milestones.

Catherine Louis, a long time agile coach and trainer, has tried the exercise on more than one occasion with SoC development teams. I’m happy to report she’s had some success with it and has agreed to take us though what she’s done (Note: I like the way she uses the term “tangible outcome”).

With that, I’ll turn it over to Catherine. Thanks again!

—

I’ve had some great success taking Neil’s Basic Sanity presentation (Agile2011, available here) as a retrospective exercise for hardware teams interested in learning about adaptive hardware development. (a.k.a “Agile”.)

If others have not tried it, it is time you give it a whirl.

Preparation:

What I do (a slight modification of the original presentation) is schedule a retrospective sending out these instructions to the team:

Be prepared to discuss a design that you have finished, make sure everyone who was involved in that project/product is available for this exercise.

You’ll need to include designers, verification engineers and modeling, board layout, thermal…maybe supply management too… as well as the system architects and managers. (This can be up to 30 people to work successfully, more than that you may need two overlapping sessions.)

Then prepare the room yourself. You need to book at least 3 hours and 15 minutes in a large conference room.  Book 4 to be safe.  If you use a cafeteria, make sure you drag whiteboards around the tables.  Bring sticky notes and again, lots of white space and markers to fill up the white space.

Step 1:

Timebox a half an hour to have everyone draw a block diagram of the design that includes the design and test environment. The blocks  should be labelled.

Step 2:

Timebox a half an hour to decide as a group one (just one) simple function which provides some tangible outcome. Give this simple function + tangible outcome a name, and title the drawing with this name.  Identify the main processing path by drawing a line through your block diagram.

Step 3:

Timebox one hour, divided in 3 parts. Remove everything you don’t need beyond the simple function that provides the tangible outcome. The goal is to find the smallest code footprint that supports this function. Warning! Before you erase everything so carefully drawn, take a picture of what you have so you can redraw it if you need to.

1. Look for entire blocks to erase if you can.
2. If there is logic that can be moved, simplified, or perhaps not needed for this function, make a list of the simplifications and then erase those blocks.
3. From the blocks that remain, list the features that aren’t necessary and could be removed. This should leave you with a list of what has been removed, what has been simplified (and how), and a diagram

Step 4:

Timebox 1 hour for a mock-planning exercise to deliver this simple function. Pretend that this isn’t a finished design. Even to the point where you write date in the past on a board from well before the project started.  Pretend we are now planning to deliver this simple function with the tangible outcome working from a clean slate.   Take 15 minutes and have everyone write on post-its answers to these questions:

In a perfect world…

1. What would you do differently from what you normally do?
2. Would the code you write be any different than usual?
3. Would the teams or the organization be the same or different?
4. Would you deliver this simple function first? How long would it take?
5. What would your schedule look like? Would you be assigned to 2 projects or more at the same time?
6. What would your documentation look like?
7. Would you have more access to a customer/team/architect than you had?
8. Would you have more access to specialists outside who could help accelerate our knowledge gain?
9. Is there a different type of planning, different from what you normally do, that you’d attempt?
10. Pretend that you’ve completed and delivered just this tangible function- would you celebrate? What might you have learned earlier (or later?)

The logistics of this exercise can run like a retrospective – on one wall you could capture “what we’d like to do more of”, and on one wall you could capture “what we want to avoid.”

You will have a list of things to change, enhancing the ability to work together

Step 5:

Finish with a retrospective, a quick 15 minutes, on the exercise itself. This will help you for when you do the next one.  Draw a sailboat and an anchor, and ask for one item that would put “wind in our sails” for doing this exercise the next time, for the next team, and ask for at least one item that slowed us down. Have folks put these on sticky notes and bring them up to the sails or anchor as appropriate.

Results:

Every team is different.  Results however have been surprising.  There is one in particular I’d like to share which I have seen several times now.  Many large projects which combine both hardware and software development, are diviid up very early on to a technology leader of the hardware development, and a technology leader of software development.  In Step 4 where we do a mock planning, this is discussed as a reason for resource contention: the software vs hardware folks are competing for the same money pot.  If you run across this in your stab at the exercise please ask for the delay this caused in the project.

What I’m looking for in this exercise is an increase in self-managed, -motivated, -disciplined teams, collaboration, an awareness that rhythm of development is something you can consider (towards delivering something tangible), business-value driven thinking, innovation (or more simply, the freedom to consider “if life could be better”, which always brings about innovative thought), and the idea that “Plans are nothing; planning is everything.”  Dwight D. Eisenhower

Good luck with this exercise and please share back your results with Neil!

—

As founder of CLL-Group, Catherine’s focus is on helping organizations transition from traditional (waterfall) project-driven governance to adopting Agile/Scrum in a Lean, continuous flow framework. Her focus is not just on the R&D development teams, rather it is on the end-to-end flow from the “idea” phase at the front-end of development, through to full support of large, multi-customer based established products involving Channel Partners, Supply Management, Operations and Offshore partners.

Catherine has over 20 years of software development experience in complex product development in large telecommunication firms. Her focus is on Agile methods, Agile R&D, and managing organizational Agile transitions: Enabling change to build speed and flexibility in business.

You may reach her here on linkedin, or on twitter @catherinelouis