Agile Is More Than Just Concurrent Development

Considering SoC development requires several disciplines and considering our history of specializing and siloing these disciplines, it’s easy to see why people fall into the trap of equating agile development with concurrent development. But they aren’t the same.

Historically, I think hardware developers see concurrent development as providing two major advantages. First is that it seems more efficient. We have several teams producing outputs simultaneously as opposed to a pure phase-gate approach where each team is waiting on the previous to finish up. Everybody busy; that’s efficient. Second is that concurrent development expidites deployment. If 10 different teams have 1 month of work to do and they can do it concurrently, your product hits the market 1 month from now.

The idea of concurrency enabling early deployment was probably the motivation toward executable specifications, ESL models and co-development platforms. If only architects could provide the hardware and software teams with a platform and/or comprehensive model, both teams could hunker down and build their half, then come together 2 years down the road to hold hands and sing Kumbaya as their integrated product performs and deploys flawlessly.

My understanding is that the promise of technology enabled concurrency hasn’t really materialized across the industry. We’ve tried… hard… but thinking there’s some tool or technology or methodology that enables long concurrent development from siloed teams without major issues related to integration, usage model and deployment is where we’ve gone wrong. I don’t think it’s possible.

Which brings us to agile development. If you think agile is here as the next great enabler to perpetuate the idea of hardware and software being developed concurrently then plugged together at some later date, forget about it… because it isn’t.

To drive the point home that agile development and concurrent development is an apples-to-fire trucks comparison, here’s a day-in-the-life video of an agile software team that uses mob programming. With mob programming, the entire team sits around the same computer with code projected so everyone can see. There is one person writing code at a time. Others are observing, discussing, making suggestions, researching implementation and so on. Developers code in a rotation, switching every 15 minutes or so. With this agile team there is very little concurrent development (the majority of the time they maintain single piece flow which means no concurrent development).

[youtube_sc url=p_pvslS4gEI width=640 height=480]

I think we can agree that what the people in this video are doing is the opposite of concurrent development. Yet what they are doing is also very agile when measured against the values of the agile manifesto. I’ll also assume that what they’re doing is very productive considering a) Woody Zuill (aka: the “father” of mob programming) is regularly invited to conferences to speak about it; b) people from other organizations ask to sit in with the team to experience it first hand; and c) the team hasn’t been fired and replaced by people that are more efficient.

Granted, this is a pretty drastic example of an agile development team and no one example is going to prove a point. But there are other notable and highly productive teams working toward the same agile values and they’ve adopted the relevant practices and frameworks to support them (and if you’re new to agile, I can assure you that many of these practices and frameworks would seem almost as drastic as mob programming). Fair to say most of these teams are also multi-disciplinary, focusing on UI, database, web, mobile development with QA and test specialists and architects, analysts, IT and others (that I don’t know about or completely understand).

So I’ll suggest we avoid looking at agile simply as some key to enabling concurrent development of hardware and software; or concurrent development of RTL and testbench; or concurrent block level and chip level verification; or RTL and implementation; or whatever other tasks we think we can do concurrently to be faster and more efficient. We need to get past the ideas of concurrency and efficiency and move on to something more productive.

Think toward a single/steady stream of development, collaboratively releasing product one feature at a time. That’s the goal. Think about software and hardware developers starting together, sitting together, working together toward common deliveries, answering each other’s questions as they arise, exposing and resolving architectural issues as they’re discovered, fixing bugs on the spot without tracking tools (or avoiding bugs altogether) and improving UIs/APIs/implementation/product continuously. And don’t forget to do it all at a sustainable pace so people don’t burn out.

One adaptive and agile multi-disciplinary team working and delivering together… all day… everyday.

That’s agile development.


One thought on “Agile Is More Than Just Concurrent Development

  1. I think the misapplication of concurrency comes from the misconception that what works for small designs/less complexity will scale up to large designs/very complex designs. How did we scale up complexity from simple synchronous designs? We pipelined the micro-architecture by adding resources that operate concurrently. This is basically Conway’s law. But if you look at the actual designs, the thing that enables more complexity is not just throwing more transistors at it, it’s the wide/low-latency communication between inter-related units. So what practices like pair programming (and by extension, mob programming) do is they emphasize communication (and also less Facebooking during office hours). Which is part of Brooks’ law.

    And good architectures tend to use the right metrics. The project management analogy for CPUs would be, CPI and FLOPS per Watt, rather than “are all the transistors busy”. Efficient teams need to incentivize the correct behaviors by measuring “work finished”, not the easier-to-track-but-poorer-proxy “work-in-progress”. And it may seem like measuring “work finished” would be easy, but it requires clearly defining the criteria by which it is considered “finished”, which requires a lot of communication.

Leave a Reply

Your email address will not be published. Required fields are marked *