Archive for the ‘agile’ Category

3 INCOSE takeaways on requirements

Friday, July 1st, 2011

Last week’s INCOSE International Symposium was refreshing. The sessions and events offered great opportunities to network with other industry professionals interested in systems and not just software, and I joined some useful tutorials in systems engineering. I’m still distilling my thoughts on “systems engineering vs. software engineering”, and will post later on that topic.

Participating on the “Is Requirements Engineering Really Necessary?panel with Brian Berenbach, Mark Sampson, and James Hulgan was great fun. We don’t have the official session survey ratings yet, but we drew an audience of several hundred who never ran out of questions for us. My top 3 takeaways from our discussions are:

  1. Emphasize activities, not titles. The more stakeholders and team members who understand and can use Requirements Engineering methods effectively, the more the system and business will benefit. RE advocates have to remember, though, that most systems engineers aren’t, and don’t want to become, “requirements engineers” or even “requirements analysts”. They are committed “control systems engineers”, “electronics engineers”, “software system engineers”, or “power systems engineers” who are passionate about their own domains of expertise. To be most useful, training in requirements elicitation and analysis should be aligned to their domain worlds, instead of expecting systems engineers to align with the world of RE.
  2. System requirements need systems thinking, too. How formally requirements are managed should depend on the risks and consequences – not all requirements are “created equal”. Likewise, how requirements are documented should depend on who they are being documented for – the audience who needs to understand and use them. With today’s increasingly complicated systems and escalating time-to-market pressures, the same old mountain-of-text-documents approaches don’t scale; we need to adapt, and start ‘system-engineering’ how we handle our requirements to fit the needs of the business and the system.
  3. No silver RE bullets. Requirements engineering isn’t a panacea that can solve any and all problems in a system. Requirements aren’t mushrooms to be “gathered” for analysis. They’re more like truffles that need to be carefully searched-for and unearthed. RE techniques can help you find the truffles and ensure that key needs aren’t overlooked. And RE can help you analyze and manage needs to ensure that requirements are well-defined, prioritized, verifiable, and necessary. RE can’t guarantee that you’ll never miss a requirement, include extraneous features, or misinterpret an important aspect. Using a mixture of senior and junior staff can help: experienced people are guided by the pain that came from overlooking key requirements or quality attributes in the past, and junior people can help the team avoid “expertosis”, by questioning assumptions and asking “why?”.

(My “point of view” slide can be downloaded from the Agile Teams website, as well as my 1-page position statement.)

back to the future

Sunday, February 27th, 2011

Over the past few months, my work scope has grown to encompass a new area: data mining and advanced analytics. As part of my newest project, I’ve been enjoying the opportunity to do some classical and new-fangled data analysis, and some real coding. I’ve written – and tested, and refactored – about 1000 lines of C# code in the last few weeks. That’s nowhere near the amount I used to produce early in my career, but you know what? It’s still fun. ūüôā Anyway, I thought I’d share 3 key observations that have begun to jell as a result of my new work.

  1. What’s changed the most are the development tools. Compared to the simple text editors I started with, modern IDEs offer way more built-in guidance and ‘accelerators’ (although they do sometimes get in the way). And I’m learning to leverage the vast amount of online help and forums available nowadays. Learning to navigate the complexities of newer IDEs and debuggers, and become hyper-efficient in using them, will still take a little time, I’m sure.
  2. Oddly, the languages themselves haven’t changed all that much. I began with assembler and FORTRAN and quickly moved into RatFor, a C-like Rational FORTRAN preprocessor. I also did some work in Pascal and Ada, and lots of batch scripting, before moving to C and C++, then into Java. Picking up C# over the last few weeks has been straightforward.
  3. My background in both agile methods and more formal approaches to architecture and requirements is clearly influencing how I do my work now. Thinking about what might be ‘the simplest thing that will possibly work’ and how to test steers my ‘XP For One’ task planning. I mull up front whether I need to design for performance to handle the huge datasets I’m working with now, and plan spikes to help me test early. For this project, throughput on my laptop is more than adequate so far: my programs runs through 4 years’ worth of data in just a few minutes. Robustness and error detection in how I clean and process my data are critical, though.

Bottom line: it’s gratifying to know that after so many years focusing more on management and process, I do still have the design, programming, and math skills to tackle and solve technical problems hands-on. It’s still cool to wake up in the morning with a piece of a solution to a coding challenge I fell asleep thinking about, or to find my mind puzzling out an answer while I’m in the shower. And I like that this experience is building my mental framework for my future technical leadership, whether in management or coaching or research, to truly understand what product development teams using these latest tools are coping with. It’s all good!

on coaching agile teams

Wednesday, August 18th, 2010

Today’s webinar on “Confessions and Coaching for Leading Agile Teams”, hosted by PMI Agile, was well-attended (at least 324 people) and insightful. Here’s a brief summary of Lyssa Adkins‘ key points.

[The webinar was marred only by a few technical problems: un-muted children of an attendee in the background, and some key slides that showed blank in the Acrobat Connect Pro session. The noise impediment was quickly ‘bulldozed’ away by competent moderators, and the slides will be posted afterwards in addition to the webinar recording to help compensate for the second issue.]

The ‘confessions’ part of the webinar consisted of announcing the winners of the contest. Update: The videos are available online via the PMI Agile wiki page for Confessions of an Agile Project Manager videos.

The bulk of the webinar was Lyssa, talking about her lessons learned in coaching agile teams as a ‘recovering command-and-control-aholic’. I won’t go into details here, since the entire webinar should be available online within 24 hrs. In brief she covered 8 ‘radical thoughts’, followed by some further confessions and thoughts on how to improve effectiveness as an agile coach:

  1. Be detached from outcomes
  2. Take it to the team
  3. Be a mirror
  4. Master your face (be sure it shows you believe in the team)
  5. Let there be silence (learn to “get comfortable with uncomfortable silence”)
  6. Model being outrageous (to help team members “see brick walls'”)
  7. Let the team fail (at small things, all the time – they’ll get stronger)
  8. Be their biggest fan (on how they’re growing as a team and as individuals)¬†

The second half of Lyssa’s talk focused on becoming a better coach by improving both your agile mentoring skills and your professional coaching skills. She compared being an agile coach to being a river raft guide: the trip down the river is different every time, but experience helps greatlywith knowing where to rest, how to help the team navigate around hazards, and how to get people back into the raft and moving downstream again after a spill.

Her closing point: Agile coaching is “40% doing, 60% being” – it’s important to be what you want your teams to do, to walk the talk of commitment, simplicity, etc. Journaling and finding a ‘reflective surface’ can help.

In short, good stuff. I’ll definitely be downloading the slides and getting the webinar recording. I’ve already signed up for her free weekly coaching inspiration emails, and her book’s now moved higher up in my wish list.

culture and process

Tuesday, July 20th, 2010

Today I found this thought-provoking blog post by Jeff Patton of Agile Product Design: “Agile development is more culture than process: Why thinking of agile as culture and not just process explains resistance and difficulty in teaching and learning the approach“. To me it makes sense; it fits with the “values, principles, practices” framework we’ve used for:

  • thinking about and comparing software development methodologies (e.g. TSP and agile), in theory
  • examining the impact of culture and value mismatches when tailoring development methods with an organization, in practice

I don’t think the applicability of the insight is limited to agile, though. Rather, I think it’s true that adopting any significant software development process change (like piloting TSP, or changing how the organization handles sustaining engineering) affects, and is affected by, culture and values. (Of course, I happen to believe that TSP is pretty compatible with agile values.)

What do you think? When you have learned (or taught) agile, did you learn/teach culture, process, both?

If you have introduced agile into a team or organization, did you observe cultural mismatches which impacted acceptance of the process transition?


Saturday, May 22nd, 2010

A very full week at SATURN 2010 is now over. I’ll be summarizing the sessions I attended on our WordPress blog shortly, but in brief: it was an excellent conference offering great networking opportunities and bringing much-needed attention to effectively combining architecture with agility.

Our AHEAD tutorial on Tuesday morning was well-received, and several enjoyable, thought-provoking discussions with participants ensued later in the conference week. Following Linda Rising‘s good keynote advice on using the Just Say Thanks pattern, I’d like to publicly thank Aldo for co-presenting it with me, and express my deep appreciation to Elizabeth for her extensive preparation work and thoughtful support as we developed the tutorial together.

adventures at SEPG 2010

Wednesday, March 24th, 2010

I’m at SEPG North America in Savannah this week, and at the halfway point it’s already exceeded what I expected when I tweeted via LinkedIn that I was “ready for #SEPGNA, and looking forward to [re]connecting with interesting people there.” Here are some links you can use to see what’s going on:

Blog posts by some of the interesting people I’ve met up with here:

It’s already been a great week for reconnecting – with Beth Layman (, more than a few TSP colleagues from SEI and other companies, and someone I enjoyed working with (but last saw/spoke with) 15 years ago in another state.

I’ve been taking a few pictures and some softcopy notes, which I’ll upload later; I’ll be updating this entry with additional names and links during the rest of the week, and I’ll summarize my key takeaways and recurring themes when it’s over.¬† Enjoy – comments and questions welcome!

Practical Software Development

Sunday, February 28th, 2010

I had a great time participating in the “Practical Software Development” discussion at the Eastern NC IEEE Computer Society chapter meeting on Feb. 16 with Bob Galen and Andy Hunt. Since I was one of the panelists, my notes are somewhat incomplete, but I’ve summarized some of the key questions from the audience and moderator John Baker, as well as the panelists’ opening¬† point-of-view statements.

An unexpected highlight of the evening was our discovery that Dr. Frederick P. Brooks (yes, THAT Dr. Brooks, of Mythical Man-Month fame!) had honored us by joining the audience. His comment to me afterward on why he came: “You always need to keep learning.”

(Added Feb. 28: event photos, including one with Dr. Brooks, are now included at the end of the post.)


IEEE news – Feb. 2010

Friday, February 5th, 2010

Feb. 16 IEEE Computer Society meeting, Eastern North Carolina Section: I’ve been invited to participate on a panel on “Practical Software Development” with two local luminaries: Andy Hunt (/\ndy) and Robert Galen.

People who RSVP can suggest specific questions they’d like us to tackle, and moderator John Baker promises to bring some additional ‘clever questions’ on balancing agility and discipline. If you’re in the Raleigh area, do plan to come by at 6pm for pizza and the lively discussions that are sure to ensue! IEEE Members and guests are welcome.

Where: Engineering Building I Room 1005 Centennial Campus NCSU

RSVP to John Baker at jbaker (at) to confirm your attendance and suggest questions for the panel.

trying Toobla

Saturday, December 12th, 2009

Recently I heard about Toobla and thought I’d give it a whirl. So far our new Agile Teams toobla library has only a few simple folders: one for agile, one for GSD (global software development) to organize our blogs, links, etc. Toobla CEO @blinkdaddy kindly sent me a suggestion to check out @bblanquera‘s very nice agile library in Toobla. I can definitely see Toobla’s value as a personal organizer (see their ’12 uses’ blog post for ideas), and I’ve now added Ben as a ‘friend’ on Toobla.

But how can I find agile libraries in Toobla by other cool people like Ben? I don’t see a search function on the site from my Toobla home page, and so far I am coming up empty with conventional web searches (try ‘toobla agile’ in your favorite engine – mine finds references to a few agile-inclined Toobla developers, Ben’s library, and mine). I am glad that they are adding support for more types of widgets (eg WordPress), and perhaps search goes a bit outside their core value proposition for visual aggregation and organization; nonetheless, at this point I’d have to say it’s my biggest wish.

RE09 keynote on agile and requirements

Wednesday, September 2nd, 2009

Dave West gave the opening keynote speech today at RE09, titled “Delivering Business Value with Agile Approaches to Requirements”. The keynote description had definitely caught my attention, and I confirmed in a quick chat right before his talk that Dave was fresh from the Agile 2009 conference (he was sporting his Agile Alliance/Rally logo’d lanyard).

I took extensive notes on my laptop, but wasn’t able to ‘live blog’ – we’ve got free wireless, thanks to the conference organizers, but power connections are scarce. My battery’s not as good as it once was, and having the wireless on during the day today would have killed it. So I apologize for the delay in getting this post online, but hope you find it worth the wait!

In a nutshell, Dave delivered – he was entertaining and provided some hot-off-the-press stats on agile adoption. The only ‘promised’ topic which I didn’t feel was well addressed was how ‘formality and discipline play just as important role with Agile methods as with traditional approaches’, and it was a bit under the bar re ‘provide concrete recommendations on organizations can resolve the conflict and build a better requirements discipline’.¬† Everything else he covered was up to, or exceeded, my expectations. There were also some thoughtful questions from the RE09 audience in the limited time for Q&A.

Below are my detailed notes. Be advised that most of the percentages cited below are either subject to transcription errors, or were my approximations from reading column heights on a chart. Also, the bulleting is still a little rough/confusing, and I know I’ve used some personal abbreviations in here – with your permission and understanding, I’ll clean those up later.