Blog

Agile With Non-Software Teams

It is quite interesting to note how little most software developers know about hardware development. Many of us take it for granted that hardware development cannot match the pace of software. While this might be true for the case of the best software teams, able to update a software system every few minutes using continuous integration, for the common pace of biweekly software delivery this is nothing more than a false assumption.

On
26 January 2012
In
Scrumtisch Berlin, Agile with a Purpose
Tags
agile, hardware

    At today’s ScrumTisch, the first chosen topic by the crowd was how to do Agile with non-software teams. We started the discussion with a short list of questions:

    • What to show at the end of the timebox?
    • How to set the length of the timebox?

    Interestingly, these questions, although raised by the audience, apparently were not hot enough to actually get discussed... (the topic Agile Beyond Software is much broader than this post, I’m just covering what was discussed tonight—a touch on the surface...)

    Hardware

    It turned out, that the person suggesting the topic actually had a challenge integrating hardware and software teams... Which then lead to a heated discussion about how quickly hardware can be developed, manufactured, and integrated with a new version of the software—which, in the case of these Scrum teams, happens to be potentially shippable every two weeks.

    As in many similar discussions I have observed in recent years, it is quite interesting to note how little most software developers know about hardware development. Many of us take it for granted that hardware development cannot match the pace of software. While this might be true for the case of the best software teams, able to update a software system every few minutes using continuous integration, for the common pace of biweekly software delivery this is nothing more than a false assumption. My colleague Ralf Kruse suggested to compare this with software teams new to agile development, who also tend to be sceptical about the possibility to ship working software every two weeks. With software systems, we now have quite a large number of examples which are publicly available on the web that show this is actually possible, even for large-scale enterprise systems.

    Examples of hardware development integrating new versions every two weeks might be harder to find, yet they are available if look for them. WIKISPEED is a fine example of a 100 miles per gallon car developed using Scrum, iterating the entire car every seven days.

    We know many more examples from our personal work experience, like ECUs for cars, satellite communication and other complex systems including hardware using a frequent integration pace.

    Challenge Your Assumptions

    How does that work? Or, to get at the underlying assumptions, why do we think this is difficult? In my experience, it usually burns down to organisational issues: contracts with hardware suppliers who “can’t” deliver more often than every 2 months, hardware departments who need “for ever” to develop a new prototype... This is the status quo for most organisations. But does it need to be that way? Toyota has proven in the automotive industry how long-term partnerships with trusted parties avoid long contract negotiations for every single piece you need. Instead, the partnership enables a learning environment for both sides to challenge the status quo and find new ways that might work better. This might even be easier inside an organisation where the parties involved actually would not need a contract at all to work together...

    We need to challenge our assumptions and identify our real options. How can we prove we are moving in the right direction at the pace that our competitive situation demands today if we don’t challenge the organisational dysfunctions that we developed in another century? Agile has a purpose. We need to make this world a better place, so we should stop increasing busyness in business, and start thinking about Betterness instead. 

     

    Discussion No comments yet. Be first to comment!

    No comments yet.

    (required)

    (required)


    (required)


    (required)
    Refresh captcha

     

    Latest entries

    Notes from the Scrumtisch Berlin - July 14, 2014

    Pictures of the question flipboards that were discussed during the Berlin Scrumtisch (Scrum User Group) on ...

    0 Comments

    Agile2014 session on Smart Scaling: Finding the right approach for Enterprise Agile

    Richard Dolman and Steve Spearman will discuss finding the right scaling approach for Enterprise Agile at ...

    0 Comments

    What makes a good ScrumMaster?

    agile42 European coaches discuss what makes a good ScrumMaster in their first collective video

    0 Comments

    Webinar recording: Measuring the Success of Your Agile Transformation

    Complete recording of AgileLIVE webinar on using metrics to measure the success of your Agile transformation, ...

    0 Comments

    The Lens at Agile2014 Orlando: engineering powerful insights and profound conversations

    At Agile2014 in Orlando Martin Kearns and Daryl Chan talking on engineering powerful insights and profound ...

    0 Comments