TDD in embedded C/C++ too expensive? Think again PDF Print E-mail
Written by Ed Willis   
Saturday, 29 October 2011 18:12

Embedded development in the wireless domainLike many developers, I’ve spent more time wishing I’d done Test-Driven Development (TDD) than I’ve spent actually doing it. The mistake I’ve made is that when put under excess schedule pressure, I make quality implicitly negotiable by allowing the scarcity of time to drive out all the work I wanted to do to ensure a quality product. I suspect I’m not alone in that. With studies like these indicating TDD’s 15-35% additional cost over traditional development, it would seem unsurprising to see teams abandoning it when the going gets tough. That my work is in embedded systems in C/C++ gives us additional excuses to avoid embarking on a TDD path. There’s extra effort required to set up and maintain the unit test builds, concerns about testing on target versus off, among at least a few other concerns that make TDD a little harder to say ”yes” to. So lots of reasons not to do TDD but still that desire to do it. I recently had an experience with TDD in an embedded systems context that really turned all of these assumptions on their head and forced me to rethink how I approach TDD in this space.


Last Updated on Saturday, 31 March 2012 18:12
Raising the Waters PDF Print E-mail
Written by Ed Willis   
Tuesday, 02 August 2011 18:41

Defects or features?Imagine a product team of seven people. They work together to develop new releases of their product while simultaneously supporting the released versions in the field. Year after year, they get solidly positive feedback on the quick turn-around they provide on customer-reported issues. Historically the team released new product versions about once a year but in the months following their adoption of Scrum they improved their productivity while increasing the pace of their releases to around one per quarter. A significant problem the team has encountered along the way is meeting Sprint commitments in an environment where the amount of support work needed for customers is tricky for them to forecast. Sound familiar? There’s got to be a very large number of us in this position or something close to it. This post is about how this common situation can be hard to manage in Scrum because of the difficulty accounting for support demand in Sprint planning and how an unusual application of the analogy of the lake and the rocks analogy from Lean can help.

Last Updated on Wednesday, 04 April 2012 15:29
PDF Print E-mail
Written by Ed Willis   
Saturday, 09 October 2010 09:41

Just published this on Mike Cohn's new site, Scrumpedia.  Here's an excerpt to get you started:

This article is about developing requirements. I’ve used a number of different techniques and have come to appreciate their varying characteristics and how they can be used to advantage for different project needs.

The Illuminati Approach

Likely the most common method for developing requirements I’ve seen is what I’d call the “Illuminati” approach. In an Illuminati approach, a small cadre of senior people writes a requirements document and sends it off to the rest of the team. This can be fast and effective, providing all those senior people are actually able to speak to the complete scope of the project and find the time to do so. In practice though, my experience has been that this approach is neither particularly effective nor fast - partly because neither of those provisos tends to pan out. Beyond that, because so few people have been involved in the requirements development process, the eventual review and acceptance of the requirements will take quite a while. Similarly, this approach does a pretty poor job of informing everyone who needs to understand the requirements because most of them will only get the document - they won’t have the deep understanding of those who actually participated in developing the requirements development.

At this stage in my career, I’d be hard-pressed to use this approach.

You can read the rest of the article on the Scrumpedia site itself,

Last Updated on Saturday, 09 October 2010 09:48
Certified Scrum Coaching Application - Ed Willis PDF Print E-mail
Written by Ed Willis   
Sunday, 19 September 2010 13:32

Below is most of my successful Certified Scrum Coach application - I've removed the employer-specific references and the testimonials from former customers (I haven't obtained their approval to publish them this way).  I'm posting this to the site so you can get a glimpse into the process of attaining this certification.

Certified Scrum Coach (CSC) Application

This application is intended for individuals who are applying for the Scrum Alliance Certified Scrum Coach certification credential. The completed application should represent your Scrum coaching experience, skills and competencies. The information you provide should be quite thorough and therefore, it may take you several hours to complete it. Give yourself plenty of time and review the entire application before entering your responses.

Last Updated on Wednesday, 13 October 2010 18:41
In Defense of the Half-Assed, part 2 PDF Print E-mail
Written by Ed Willis   
Saturday, 11 September 2010 00:22

The second in the ScrumBut series, posted over on the Rally Agile Blog.  Here's an excerpt:

Scrum Sticker ShockIn the first part of this two-part series, I talked about deploying Scrum to parts of the larger organization without starting in development (“Can you deploy Scrum to a test team?”).  This article looks at another kind of “ScrumBut” – the most commonly meant kind:  deploying only parts of Scrum to an organization.

Is it half-assed to skip practices in adopting Scrum in your organization?

Lots of sources appear to say that it is.

Ken Schwaber gives a short presentation on ScrumBut in this video (you may have to click the “Download Optimized” button to play this).  I’d paraphrase his position as saying that the Scrum practices fit together to create more value than they do individually. So if we punt on one or more of them, he sees potential value being left on the table, and potential organizational weaknesses becoming more entrenched.  He sees Scrum as best adopted as a whole without deviation.  Consider this excerpt from his book “The Enterprise and Scrum,” about the medium-term issues in Scrum adoption:

“… many people in your enterprise are probably advising you to change Scrum because it needs some tweaking to be compatible with your enterprise.  My advice is this: Don’t Do It.”

Later in the same book, he suggests developing an organizational audit function to independently assess the degree of success in adopting Scrum:

“… the ScrumMaster and the team often get so embroiled in their work that they lose perspective on themselves.  For this purpose, having an audit capability is useful.  Someone who knows Scrum and is from outside the team needs to have a way to measure how well the team is using Scrum.”

That can be viewed as an organizational-wide commitment to avoiding ScrumBut.

This article from Mitch Lacey, “Practicing ScrumBut: Ensuring Project Failure,” captures a workshop delivered at SQE Agile Development Practices 2009.  I think the title here says it all in terms of the expected value of ScrumBut.

This article from Michele Slinger covers a particular pattern of ScrumBut that’s near and dear to my heart, failing to meet sprint commitments.   The thing I liked most in this article was the notion of “we suck less” Scrum adoptions.  Michele is encouraging us to strive for more than “we suck less” – in large measure, saying to at least aim to suck less.

You can read the entirety of the article on the Rally Agile Blog.

Last Updated on Monday, 13 September 2010 04:31

Page 3 of 5