We interrupt your regularly scheduled programming to bring you this short email back-and-forth I had with Aart de Geus last year during SNUG (Aart is co-CEO of Synopsys for anyone not familiar with the name). It happened just after his keynote where he spoke about something he called systemic collaboration. I remember it being quite interesting and thinking that in people terms, systemic collaboration seemed synonymous with cross-functional teams, a key characteristic in agile development. I asked the question in that direction… he was kind enough to respond. I’d be interested to hear what people think. Continue reading
Leadership
Commit to becoming a Hardware Craftsperson
It’s my opinion that are are some very basic techniques that create great value, and should be re-stated and reinforced as good practices from time to time. I also contend that they are strongly related to agile methodologies that we’re promoting here at AgileSoc.
Debugging Professionals?? (A Call To Action)
Dear AgileSoC Follower,
I need your help.
I need you to join me in heading off a trend that’s progressing dangerously toward the point of no return. The collective sanity of the hardware world depends on us working together. The time to act is NOW… before it’s too late!
Survey: Project Planning in Hardware and Embedded Systems Development
If you’re currently working in hardware and/or embedded systems development, we’d appreciate your participation in the following survey:
Project Planning in Hardware And Embedded Systems Development Survey
Are people in the hardware and embedded systems communities confident that their approach to project planning gives them a reasonable chance of success? We don’t know… but we’d like to.
We want you to know, too.
The survey is designed to measure confidence in the project planning approaches we use in hardware and embedded systems development. It is two pages of multiple choice questions covering tendencies in project planning and demographics. The survey takes roughly 5 minutes to complete and data is collected anonymously. Data and analysis will be published and freely/publicly available at the conclusion of the survey. The survey is being conducted by in partnership by me, Neil Johnson, and Catherine Louis of CLL-Group, LLC.
Project Planning in Hardware And Embedded Systems Development Survey
We’d also appreciate people’s efforts in spreading the word. Please help us by posting a link to the survey or to this page on Linkedin, Facebook, Twitter, your company intranet and/or anywhere else you go to share news and information with colleagues.
Thanks very much for your participation and thanks for helping make this survey a success!
For more information, you can contact me at neil.johnson@agilesoc.com.
-neil
Work Smarter, Not Harder
You’ve been working 12 hour days for the last 4 months. You’re coming off a night of only 4 hours sleep because all you could think about was the all-hands meeting with the CEO, CFO and CTO the next morning where you’d be reminded that you’re 3 months behind schedule. Your alarm sounds. You drag yourself into work. You’re there in the meeting – just barely – leaning back half asleep. After listening for 30 minutes about how important <this release> is the company, you finally hear it…
We need to find a way to work smarter (not harder).
The ultimate bit of useless advice… work smarter, not harder – or some variation thereof.
Is Specialization Good For Hardware Development?
Last night I started reading “The Machine That Changed The World”. It’s a book from 1990 that I’ve been meaning to read for a couple years that documents the rise of lean production through the 1900’s at companies like Toyota. The second chapter called The Rise And Fall Of Mass Production foreshadows a point on specialization that is discussed in detail (I’m assuming) later in the book. I thought it was interesting enough to post here for opinions on how it may or may not apply to specialization in hardware development.
Enough Already About Collaborating With The Fab!
In the last 2+ years that I’ve dedicated to applying agile methods to hardware development, a big part of my focus has been on using agile to bring design, verification and software developers closer together. In my opinion, we have room for improvement in that area. From the beginning, I’ve seen incremental development as being the key for improvement because it pulls experts together, forcing them to continuously prioritize and exercise what they plan to deliver instead of hunkering down in their cubes and hoping things come together at the end.
But with all the effort I’ve put into this, I’m starting to wonder who else is thinking the same way. Is a lack of meaningful collaboration a problem in SoC development or am I seeing a problem that doesn’t actually exist? I’m starting to question my observations – or imagination perhaps – for a few different reasons.
The big one for me lately has been all the effort dedicated to increasing collaboration between design house, EDA and fab. Now I’m sure the value there is huge, but so much emphasis on collaboration between design house and fab, to me, insinuates that this next level of collaboration is a natural extension of what is already a highly collaborative environment within the design house. Is that true? Are cohesive, collaborative teams and shared priorities the norm in SoC development? Or, for example, are design and verification sub-teams formed and insulated from each by ambiguous product specifications and bug tracking databases as well as independent priorities, scheduling, and reporting structure?
It’s also easy to notice all the attention being paid to enabling early software development as software becomes an increasingly dominant component of an SoC. That’s certainly been propelling innovation in ESL design not to mention emulation and hardware acceleration. But in focusing on those areas, is it being suggested that pulling in software start dates is the missing link to getting successful product out the door? What about the fact that hardware and software tend to be treated as completely independent deliverables? Or that hardware and software development for the same SoC may be controlled by 2 separate groups within the same organization? Do early start dates compensate for that kind of deep rooted disconnect?
Of course it’s easy to generalize. Not all teams are in the same boat with respect to how they work together. And I’m certainly not suggesting a culture of bickering and infighting. That’s not the point of this at all because that’s something I don’t see. My points relate to the organizational and operational levels and on those levels there are characteristics that SoC teams exhibit almost universally. Splitting into independent functional sub-teams is one example (modeling/architecture, design, verification, software, implementation, validation, etc). A preference for working toward a single big-bang deliverable is another tendency. Software and hardware teams that are separated organizational is yet another. The list goes on.
The details and extent obviously vary team-by-team but I don’t think I’m making this stuff up. I reckon there are significant gains to be made through a critical look at and restructuring of SoC development teams in the name of stronger collaboration. Take the time to question the barriers you put up between design, verification, software and everyone else that contributes to delivery. Imagine how regular shared goals and an agile approach to development can help break these barriers. If you’re wondering what agile SoC development could look like, you can read an article I co-authored with Bryan Morris called Agile Transformation in IC Development to find out.
And of course…
Despite what the title says, continue to pay attention to collaboration with EDA and fab. Continue to invest in ESL and emulation as a means of expediting software development. I don’t want to downplay either of those because they deserve the attention they’re getting. Just don’t forget to mix in a little time for some other things that are just as important.
neil
Q. What are your thoughts on SoC team structure and how we develop and deliver products? Are we good the way we are or are we due for a change?
Not A Problem… The “Fluffy Stuff” Isn’t That Important Anyway
There are 17 different stages at the Agile2011 conference in Salt Lake City that cover a wide variety of topics. Though there are obviously technical stages (it is a software conference after all), what would probably look odd to hardware developers browsing the program is the number of stages dedicated to the non-technical (aka: the “fluffy stuff”).
Yes, you did read stages dedicated to the “fluffy stuff”, not just individual sessions. The 5 that stick out to me are:
- Business and Project Management
- Coaching & Mentoring
- Collaboration, Culture, & Teams
- Leadership
- Working with Customers
I know that these topics are important to agile developers so I wasn’t too surprised to see them. What did surprise me though is that not only are these topics covered at Agile2011, they’re well covered with an average of 15 sessions for each stage! Now, I’ve never been to previous Agile2xxx conferences, or any software conferences for that matter, so I know nothing of content and quality (both of which I’m assuming are decent). But by the simple fact that these sessions take up almost a 3rd of the program, the folks that put this on seem to think they’re worth the time and effort.
In another universe… could you imagine going to DVCon and seeing a track called Collaboration, Culture & Teams with 22 sessions? Would SNUG, User2User or CDNLive have a track called Coaching & Mentoring with 15 sessions. How about just 1 session? One bright light I do see is at DAC where they have a “Management Day” on June 7th. Other than that, topics stay pretty technical at all of the above. I list these conferences because they are reasonably accessible for the average joe and generally well attended. If there are other conferences I’ve missed that do fit the bill, I’d appreciate you letting me know.
I’ll venture a guess that the sessions I point out don’t get run at hardware conferences because we hardware guys don’t have much of an appetite for the “fluffy stuff”. Even though leadership is important, even though we could probably learn something by listening to how out peers work with customers, even though there are times when we need to coach and/or mentor colleagues, we probably rely more on what we’re born with and experience first hand than what we learn. Or maybe as a group we figure that technical excellence will compensate for lacking the “fluffy stuff”? Maybe we already know what we need to know! Who knows for sure.
It is hard to argue against the fact that “fluffy stuff” plays a tremendous role in hardware development. There’s no denying it. And we could likely get better… much better… though it seems we’re a little behind when it comes to realizing it!
neil
Q: Got an opinion for why the agile software crowd spends so much time on “fluffy stuff” like leadership, coaching and mentoring while we hardware folks appear indifferent? I’d like to hear what you think!