Lots of hubbub this week about how OpenAI created the “Sky” voice that somehow sounded just like Scarlett Johansson, despite her clearly-expressed NO when her consent was sought. (Good for her for fighting back!! Here’s the source NPR link for anyone wanting additional information about the incident.)

Unauthorized voice cloning appears to be how OpenAI did it. (See this article from April 29, 2024 for details on voice cloning with AI, and how it’s both easy and unethical to do without authorization.)

NCAA athletes already have the rights to their NIL (name, image, and likeness). Musicians in Tennessee now do too, thanks to the ELVIS act. Time for the rest of us to have the same rights enshrined in US law. Maybe this misuse of Scarlett’s voice by OpenAI will be the one-step-too-far incident that creates enough blowback to finally drive through a national-level ELVIS act equivalent.

What do you think?

Leave a comment

Here’s what a few others on Substack are saying about the unauthorized cloning of Scarlett Johansson’s voice for OpenAI’s Sky, even though #ScarlettSaidNo:

- “The OpenAI board was right”

- “OpenAI Stole Scarlett Johansson’s Voice for GPT-4o”

- “Still a ridiculous mis-step”

BigTech and AI

OpenAI Stole Scarlett Johansson's Voice for GPT-4o

Hello Everyone, This is an Op-Ed about OpenAI, the state of the internet and technological loneliness. The lengths Generative AI startups are going to is not a healthy sign for the future of the internet. Scarlett Johansson says that OpenAI asked her to be the voice behind ChatGPT — but that when she declined, the company went ahead and created a voice …

Read more

2 years ago · 11 likes · Michael Spencer

For reference, our April 29 article on voice cloning with generative AI:

6 P's in AI Pods (on Substack)

AI Ventriloquism: Send in the clones

While doing my diligence on the broad landscape of genAI-based tools for our Part 3 article, I came across a whole bunch of irresponsible voice cloning tools. Here’s a summary of what I found, with recommendations for ethical ways to meet voice cloning needs…

Read more

2 years ago · 1 like · 2 comments · Karen Smiley

Subscribe now

“Don’t look at the tree”: How a disc golf lesson helped me become more agile in work and life

Many years ago, my now-late husband Dan was patiently teaching me his beloved sport of disc golf. We were playing on a nice wooded course. Tree shade is a great benefit for staying cool in the NC summer heat! The downside, though, is having trees between the tees and the baskets.

And my disc throws kept hitting trees. Completing my first hole took a LONG time. For me as a new learner, this was frustrating. And hitting trees over and over was not great for the old-but-still-good discs he'd given me to play with (probably not great for the trees, either). 😕 

On noticing this, Dan quickly coached me with 5 words of wise advice: Don’t look at the tree.

His explanation was simple: If you look AT the tree, and your aim is decent, you WILL hit the tree!

The solution? Pick a focal point on one side of the tree, focus on it, and then throw. 

Picking something other than a tree to look at in a wooded area was harder than it may sound. But Dan was right. I still hit some more trees during that round (my newbie aim was inconsistent), but far fewer per hole. My scores got better, the holes went faster, I didn’t ding up my discs so much from tree collisions, and we had a lot more fun 😊

This lesson has helped me beyond disc golf, in work and in everyday life. We all want to “be agile” - and true agile values finishing fast, working at a sustainable pace, and having fun! It’s so easy to over-focus on the very obstacles we want to avoid, though. So we don’t see clearly where we DO want to go, our aim is off, and our drives run right into the dreaded obstacles! Which leaves us frustrated, slowed down, causing damage, coping with now-dinged tools, and not having much fun. 

Learning to recognize the trees in our way is good. I find that I enjoy work and life more by also learning how to look away and around the trees when shooting my shots 😊

Share

Today we stopped in at the Raleigh Home Show for a few hours. The first person who greeted us just inside the building handed us each a ticket and told us to go over to the bank of waiting tablets to register to win a $250 gift card.

The first 3 questions were simple enough - name, phone number, email address. OK, maybe; I have throwaway info I can use. The next page asked further questions that seemed to be completely unnecessary for administratively awarding a gift card: gender, age range, marital status, family income level, etc.

Suspicious now, I played along with random responses on more pages of nosy questions to get to the end page. On the last page with the AGREE button, I clicked through to read the T&Cs.

Guess what? By clicking AGREE, one would be consenting to letting them use all of this personal information as they like AND, if selected to 'win' the gift card, consenting to travel at one's own expense to somewhere (in tiny print, there was a list of places which didn't seem to be in the Raleigh area) and have to sit through a 90-120 minute timeshare presentation in order to receive the $250 gift card.

How many people, I wonder, had clicked AGREE at this show without reading these T&Cs? We clicked DISAGREE and got out. I've seen better rewards at walk-in timeshare tour offers.

After finding the box office and buying our tickets (a very reasonable $10 per person), we entered at the admission gate, and were greeted by another person who handed each of us a different award ticket. He indicated that we should stop at a new set of kiosks inside the show, at the bottom of the escalator, to register to win a 'free' $15,000 remodel.

Care to take a guess about how much personal information was requested to enter this second drawing? Yup, same things, and even more. As a test, one of us clicked on 'married' and was prompted with a new dialog asking for spouse's name. Nope, sorry. And the requested household income brackets were even more specific and higher-ranging. We worked our way to the end of the questions on one of the kiosks, and got to a URL for the giveaway. Mobile browser in hand, I pulled up the rules.

Although the kiosk had not allowed proceeding in the giveaway signup without choosing an income range, the giveaway rules page claimed that income information was not necessary to enter. A tiny link at top for the privacy policy for "*** Marketing Services" (I refuse to give them free publicity by naming them or linking to their site) pointed to a PDF link on a site for the same timeshare promotion company. And the privacy policy URL was a dead link! A search on their site did pull up a privacy policy, but it explicitly stated that "THIS PRIVACY POLICY DOES NOT GOVERN PRIVACY PRACTICES ASSOCIATED WITH OFFLINE ACTIVITIES." - so, not relevant to their giveaway at the show? (FWIW, the policy says that they DO sell and share nonpublic personal information to third parties.)

Finally, the giveaway page indicates it sponsors a single $15,000 prize for the entire sweepstakes signup period of Jan. 1-Dec. 10, 2019. There is no mention of how many events will be eligible for this one prize, but logically, it would be many events like the home show, and thousands of people, making the odds of winning quite small.

Interestingly, the sweepstakes web page says anyone can enter manually by sending a postcard with full name, home address, email address and phone number. No marital status, no income range, no gender, etc. required. So why do they ask for it at the kiosks? The obvious answer is on the page: they will make money from using attendees' data for "promoting various products and services".

Bottom line? Beware of 'free' giveaways that ask for more personal information than needed to administer the giveaway, and aren't up-front about who is sponsoring them. If you're going to the Raleigh Home Show tomorrow, or a similar event later this year, consider skipping the kiosks if your personal data is worth more to you than a minuscule chance at winning a $15,000 home remodel or, worse yet, a $250 gift card that you need to travel at your own expense and endure a 2-hour timeshare tour to collect.

This post was first published on the agile Teams WordPress blog on February 17, 2019. As of July 12, 2024, all agile Teams content has moved here to Agile Analytics and Beyond. Minor edits have been made to support audio voiceover for the podcast.

• Search - Installed DuckDuckGo Plus in Firefox

• Email - Got a free personal Zoho mail account

DuckDuckGo promises no ads and no tracking.

Zoho mail promises no email scanning, and says they are Safe Harbour compliant.

So far, so good with both. I only ran into one quirk getting Zoho IMAP configured on my phone (need to use syntax server:port). Liking DDG so much already that I got their iPhone search app, and am just loving the speed and relevance of the search results.

I'll post an update after a few weeks to months of runtime with them. For now, I expect to sleep better tonight!

Read more

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.)

This post was first published on the agile Teams WordPress blog on June 2, 2011. As of July 12, 2024, all agile Teams content has moved here to Agile Analytics and Beyond. Minor edits have been made to support audio voiceover for the podcast.

I don't watch much TV, but one forensics show I've occasionally caught and enjoyed is the American TV series "Bones". An old episode from the start of season 2 recently caught my attention for its clues on good software management. (This is an occupational hazard for me, but a fun one: I find myself seeing software development parallels, paradigms, and patterns in all kinds of non-software related contexts!)

"Bones" Brennan is the lead forensic anthropologist (see the list of characters for more details on her and the others). A recurring theme of the series is that while Brennan is technically brilliant, her social/people skills are notoriously weak. In this particular episode from the start of season 2, pathologist Cam Saroyan joins the Jeffersonian as the new head of Brennan's forensics department. At the start of the episode, Bones seems annoyed that the director hired Saroyan instead of promoting her to that management position.

Three elements of this show stood out to me for their relevance to common challenges in managing software teams.

1. Reasons for changing jobs: FBI Special Agent Booth, Brennan's partner, and Saroyan are chatting. It's obvious they knew each other well previously, before she became the boss. He asks her why she took the coroner position. She tells him about some of the working conditions at her old job in New York, e.g. having to perform autopsies in windowless basements on "leaky tables with no drainage", and she compares its so-so reputation to the high esteem of this place (the 'Jeffersonian' in Washington, DC). Then she mentions that dark, horrible, messy autopsy room again. Booth nods in understanding. (No, money never comes up.)

2. Reasons for (not) winning promotions: Brennan is inquiring with a few of her trusted team members about why she didn't get that promotion. She's especially offended that the big boss who hired Saroyan made his decision and brought Saroyan in while Brennan was out on vacation, then took a vacation of his own "so he didn't have to face her". At first her best friend, Montenegro, doesn't want to hurt Brennan's feelings, but then she gently tells her that yes, her weakness in people skills was probably a factor in why she was passed over. In a different conversation, Booth reassures Brennan that "there must have been a reason" Saroyan was chosen over her, and she agrees to his request that she reserve judgment.

3. Reasons teams do and don't support their leaders: After a few initial difficult encounters with Brennan and her technical team, Saroyan asks Booth in private why Brennan doesn't seem to like her. Booth tells her that Brennan is a bit hurt at not getting the promotion, but mostly, she's viewing Saroyan like an insufficiently-studied corpse and won't decide about Saroyan until she has sufficient evidence! She nods, asks what Brennan is looking for, and Booth gives her one key pointer: "take care of her people" (i.e., supporting the people on Brennan's investigative team, instead of micro-managing their work as she did in one of the initial encounters).

This episode features a high-ranking political official with a strong interest in the very newsworthy case. When the official criticizes one of Montenegro's investigative tactics during a meeting, Saroyan strongly defends her. Montenegro thanks her afterward, and Saroyan acknowledges her thanks, but says with a smile that she wouldn't have supported her if she hadn't been right.

The episode involves further political posturing in which the official publicly attacks the team and their investigative findings. Near the end of the episode, Saroyan tactfully but firmly vindicates and defends Brennan and her team to the official. She further puts the official on notice that if there's ever an issue in future with Brennan or any of Saroyan's other people, it must be brought to her privately first. Watching how deftly Saroyan is handling the official in this meeting, Brennan whispers to Booth, "I'm starting to see why she got the job."

How many times have you seen these five circumstances from that Bones episode in a software development situation?

1. Organizations that expect their staff to deliver high quality results (and be happy) with low quality tools, equipment, and work environment;

2. Managers who lack the personal courage to have open and honest conversations with their developers, architects, and technical leads about how well their career aspirations align with their aptitudes and skills;

3. Technical superstars who resent being passed over for management positions, or are moved into management positions and then don't perform well because they lack the required soft skills;

4. Peers who are reluctant to give tactful but honest, useful feedback to their colleagues;

5. Managers who don't have the political courage to stand up for their people to higher-ups, or to insist that their concerns on the team's performance be raised and addressed privately and professionally.

Over the last 30 years, I've seen all of these in various software organizations. Haven't you?

If you're a software manager, consider these five DO's and DON'Ts as 'thoughts for the day':

• DON'T: Is your organization (like Saroyan's ex-employer) expecting your development and test staff to cope with 'leaky' tools and equipment, while happily delivering outstanding software products? (and are its leaders surprised when people leave for better environments?)

• DO: Have you guided your staff to realistic expectations regarding their promotion potential, whether on the 'management track' or 'technical track', and mentored them on what they need to improve to meet their career goals? (something Brennan's big boss failed to do)?

• DO: Are you cultivating a trusting environment in which your team builds good working relationships, feels comfortable having these kinds of conversations, and shares honest feedback with each other? (despite her notorious lack of empathy, in this interpersonal aspect Brennan clearly is succeeding as team lead; many software managers don't)

• DON'T: Have you hired or promoted technical people for managerial roles based on their technical skills, without paying attention to whether they have or are developing (under your mentorship) the interpersonal skills they will need to succeed? (by hiring Saroyan, Brennan's big boss did get this right; many software managers don't)

• DO: And finally, what are you doing to develop Saroyan's courage to inquire, to listen, to support, and to tactfully but firmly 'speak truth to power' and to your people? (most people won't reserve judgment as long as Bones did, or wait for you to trust them before they decide not to trust you; it's important to try to get this right quickly with a new team)

I'd love to hear what you think. (And if you're a science geek too, you might want to check out "Bones" - based on the episodes I've seen, it's a well-written series with genuine and interesting characters.)

Are YOU doing interesting work with requirements for such syst…

Read more

Read more

This post was first published on the agile Teams WordPress blog on Sept. 11, 2010. As of July 12, 2024, all agile Teams content has moved here to Agile Analytics and Beyond. Minor edits have been made to support audio voiceover for the podcast.

How to lose a customer in 5 easy steps, motivated by a customer dis-service experience I had today with a company I pay lots of money every month for tech-related services:

<rant>

1. Make a website with big promotional ads for cool, fast new services - where clicking the links will just take people in circles and never actually get them to a page with enough detail to decide they might want those services, OR a page where they can order. (This works especially well when it's vaporware, or is at best only actually available in a few small locations in the entire country.)

2. Hide the customer service phone number on a page that ISN'T linked to most of the pages a customer might typically browse. Then list a bunch of specific, different-looking numbers that actually all route to the same stupid voice system. That way when they can't reach you on one number, they'll foolishly spend more time and get more frustrated by trying to dial more of the other numbers.

3. Don't publish your actual customer service hours anywhere online. Make those people guess at your work hours AND time zone.

4. Offer live customer service chat, but design it so it only works in one browser. Don't publish the actual chat hours anywhere. And don't bother making chat available during hours when the phone line is closed.

5. Bury a link to an 'email us' page where it's hard to find. Then make the customer manually re-enter every significant detail of their account (ID, first and last name, service address, account passcode) as mandatory fields before they can submit their email. And limit that text box to 500 characters; that way people can't actually give you enough detail to be able to expect you to solve their problem without playing phone- and email- tag for a week or two, after you've taken 'up to two business days' to respond at all.

Oh, and be sure you do all of these things even for real, current, paying customers who are already logged in.

That should do the trick. As soon as they find your competitor's customer service phone number online, you're history.

</rant>

This post was first published on the agile Teams WordPress blog on August 10, 2010. As of July 12, 2024, all agile Teams content has moved here to Agile Analytics and Beyond. Minor edits have been made to support audio voiceover for the podcast.

Today some colleagues were talking about a recent meeting they had with CxO-level executives of this very large company. One part of this meeting involved a several-hour discussion on one specific, relatively small topic (an outlay of less than $20K). They noted that at the very high nominal salary level of the participants, if the per-hour values of the execs' time were considered, the meeting discussion quickly 'cost' the company WAY more than the outlay being discussed.

I have seen this at so many companies: they know, to the penny, the 'time value of money', but disregard the 'money value of time'. For instance, they:

1. "Reduce expenses" by instituting administrative policies and review procedures that drain their people's productivity in 'death by a thousand cuts'. (For instance, by putting knowledge workers in noisy, unsupportive, cubicle work environments to save office space costs)

2. Use broad, time-consuming meetings to communicate and manage, instead of investing the effort to convey and handle essentials in a more focused, efficient way.

3. Cut lower-salaried administrative support or buy cheaper, harder-to-use tools, then tell their highly-paid, scarce-skilled staff to handle those things for themselves in their spare time. (One company even dismissed the janitorial staff and told employees to take care of their own office trash and cleaning.)

These companies often say publicly that people are their biggest asset, but privately cause accelerated devaluation of those assets by draining their people's morale and productivity, and accelerating attrition.

Of course, expenses and budgets can creep, and reviews can be useful or even essential to survival. But if their balance sheets and ROI calculations included the true monetary value of their people and their time, many sub-optimal 'cost-saving' proposals would never get off the ground.

In reflecting on this tonight, I realized that the only organizations -- entire companies or intra-preneurial islands -- where I haven't seen this happen (much) are the ones that are succeeding financially even through difficult times. (Admittedly, I don't personally have experience observing a statistically representative sample of businesses, so I'm not trying to assert any universal truisms; just noticing a possible pattern among those I have observed.)

Have you see this too, or do  you know of counter-examples?

Which do you think is the chicken, and which is the egg - considering the money value of people's time, or being financially successful as a business?

Leave a comment

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.

I'd looked forward to this COOL event since I first heard about it from game co-creator Rod Nord, and it didn't disappoint. Getting to play the game with keynote speakers Jim Highsmith (his talk this morning on agility and architecture was excellent!) and Linda Rising (I'm looking forward to her talk tomorrow and her tutorial on Friday), and Marco of SEI, was great fun. The Hard Choices game is a useful metaphor for getting people to think and talk about software development strategies and tradeoff decisions, and I'm looking forward to trying it out 'back home' shortly.

You can check out the game at http://www.sei.cmu.edu/architecture/tools/hardchoices/!

SATURN is coming!

In May I'll be co-presenting a half-day tutorial at SATURN 2010 on "Efficient Software Technology Evaluations Leveraging ADD" with a colleague. We'd love to have you join our tutorial (T2), so if you haven't yet registered, please consider signing up! Or even if you've already registered, you can still add our tutorial at the early bird rate (deadline is Friday).

Either way, if you're going to SATURN too, drop me a note here - or send me a tweet and I'll add you to my SATURN list on twitter. We look forward to meeting you in Minneapolis in May!

2024-07-16: Presentations from SATURN 2010 have moved. The page does not include tutorials. If you’re interested in the materials, let me know.

Leave a comment

Getting a problem well-solved is critically dependent on defining it well. But as I read the position papers, I noticed that many identified part of the "software problem" and then immediately described how their own preferred approach already solves it. To me that was a "bad smell" and seemed like "putting the cart before the horse".

To date, I think one essential piece of a clear problem definition for SEMAT has been lacking. To extend the cart and horse analogy a bit (hopefully not to the breaking point):

• A cart needs one or more horses, certainly. A cart without passengers can certainly go fast if many strong horses can be harnessed together - but then no one but the driver (and the horses) will care where it ends up. 

• A cart with horses but without the right driver still isn't likely to get the passengers of the cart where they need to go.

• And without talking to the passengers, how can any driver know where they need to go?

So even if SEMAT succeeds in building a theoretical harness or methodological framework that gets all of the horses pulling together - a significant challenge in itself - if the practitioners of software industry aren't on board and giving direct guidance to the driver, it won't get the people who matter to their brave new world of better software.

My overall impression of SEMAT is of many strong people (or horses) trying to nudge the cart from behind or pull independently on the reins from the front, steering the cart in the direction and at the speed each believes it needs to go. In such a scenario, going around in circles or tipping the cart seems likely.

So I ask: Who are the passengers, and who will drive? Exactly whose problem are the SEMAT participants trying to solve, and what aspects do those people care about most towards solving it?  i.e.

• Who are SEMAT's customers? 

• Which customers matter most? Not all stakeholders are equally important; they must be prioritized, and the SEMAT participants must collectively agree on the priorities. 

• What do those customers need? The stakeholders of SEMAT, especially the highest-priority customers, must be actively engaged and involved in defining the problem and prioritizing the needs SEMAT tries to solve.

I see two possible customer groups which SEMAT should consider:

1) the world (literally) of industrial software practitioners

2) the even bigger world of people who buy and use software-based products (the actual end customers of group #1)

One might argue that Group #1, the industrial software practitioners, are responsible for knowing what their Group #2 end customers want and need, and for meeting those needs, to stay in business; that it's impractical to include a representative sample of Group #2; or that we all use software products in our lives and therefore any of us can 'represent' Group #2. I don't totally buy that argument, but I could live with it if SEMAT decided that their customer base was Group #1 and not #2. So let's call Group #1 the passengers in the cart.

What I would definitely be unwilling to accept would be if the illustrious participants in SEMAT decide they are, themselves, adequate proxies for today's software practitioners ("we know what they need, we don't need to talk to or involve them"). Such an approach would risk falling prey to one of the most common failings of the software projects they aim to improve: assuming they know what their customers/markets need, and developing or selling a perfectly good solution to the wrong problem.

Even industrial software engineering researchers like me are just proxies for the practitioners in our company; we are not them. Even those of us who have been 'them' in the past - which I think applies to many of the SEMAT participants as well as myself - are not 'them' today, and we should not assume that 'they' still have the same problems and priorities we knew and lived. 

My impression that this is what was happening, perhaps unintentionally, has underpinned my hesitancy in 'signing on' to SEMAT. Someone who truly hears and represents what Group #1 needs today must DRIVE the cart to where the group needs to go. 

Why does this matter?

I believe SEMAT will fizzle and fail if it is not focused strongly on what the software industry (most important customer/stakeholder class) needs - and 'software industry' cannot be represented adequately by consultants, methodologists, academics, or tool-makers. It should mean primarily the people who design, write, test, and manage software products and services that our lives depend on.

Reaching intellectual harmony among the SEMAT signatories is a stretch goal, but possible. Yet even the achievement of a  new unified theory will deliver no lasting practical value if it is not widely adopted and does not make software product deliveries better in  practice. The adoption topic - the difference between theory and practice, and the technology transfer gap between academia and industry, i.e. convincing the passengers to get on board - I will save for another day.

In conclusion, I was glad to see that during the Zurich workshop, the discussion turned towards trying to agree on the problem they were trying to solve (what IS software engineering?) and that a 6th track of work on defining requirements for SEMAT has been started. However, the focus of that 6th track should not be just on figuring out what software engineering is - it should be on figuring out who the passengers (Group #1 practitioners) are, eliciting where they need to go, and deciding who will drive the cart and who will tell the driver where to go. (For now let's ignore that it may also involve deciding that more than one cart, team, route, and destination are needed.) If the cart isn't going where Group #1 needs to go, why should they get on board? And if they aren't on board, the cart trip doesn't really matter - the software products used by everyone in Group #2 will not get any better.

My respectful challenge to the SEMAT participants: rather than hoping to win a battle for the driver's seat, are you willing to go out to talk to your potential passengers in Group #1, or be one of many strong horses of many colors pulling the cart to where the passengers (and driver, on their behalf) need to go?

A PDF of the updated slides I delivered can be downloaded from the agileteams.com website publications area. Comments are welcome, here or on the agileteams blog or Twitter!

This post was first published on the agile Teams WordPress blog on March 21, 2010. As of July 12, 2024, all agile Teams content has moved here to Agile Analytics and Beyond. Minor edits have been made to support audio voiceover for the podcast.

Today's journey to Savannah for SEPG 2010 was rainy, but otherwise pleasant and uneventful. Things got a bit confused, though, on arrival at the hotel.

After circling the block twice, I couldn't identify where to park for check-in, and no open public parking was available on the street. I saw two people standing around at an opening on the side of the block, and drove up to ask them if they knew. They turned out to be the parking valets (the only hotel parking option, but with no signs) and that WAS the place to go for check-in parking.

So I pulled my car to the side, got out to check in (which went smoothly), and came back to my car. The valet asked me, “are you staying?” I said yes (and began to wonder how often people pulled in there and then decided not to stay). He then handed me a claim check stub and walked back to his station.

I hadn't yet finished unloading my luggage onto a cart when a different valet walked up and asked me if I had a claim check, to which I said yes; and asked if the key was in the car. I said no, and handed it to him.

Then I asked him, how will you know that this key and car go with this claim check? He looked at me in puzzlement and said, well, because you just gave it to me. I said no, how will you keep track of it, how will you know that this is MY car? And he just didn't seem to understand - shook his head as if I was an idiot for asking.

After a few more minutes, I finished unloading my car, then turned to talk to the valet again. But before I said anything further, I could almost see the light bulb go off above his head. He said "wait a minute" and went back to the valet station. He came back with a rearview mirror hang tag that matched up to my claim check, and put it inside my car.

Only then did I feel confident that I'd actually get my car back from them when the time came.

On the surface, this little incident has nothing to do with software. But it has a lot to do with processes, customer service, and managing data.

Their claim check tag system for valet parking data management is simple and low-tech. When well executed, it should be highly effective (and in the spirit of doing the simplest thing that could possibly work). However, two problems happened here:

(1) it wasn't well executed, when the first valet dropped the tagging job mid-stream, and

(2) the second valet dropped the ball in two ways:

• by assuming that my having a claim check in hand meant that the tagging process was completed properly, and

• by treating his customer like an idiot for asking what was actually a reasonable and important question about their process and how it was being executed for my car.

After all, the purpose of the system and how well they use it is to support them in serving my needs as a customer. Those needs include not just parking my vehicle safely, but reassuring me that it's being well managed, and that they are keeping good track of which one is mine.

This post was first published on the agile Teams WordPress blog on March 11, 2010. As of July 12, 2024 all agile Teams content has moved here to Agile Analytics and Beyond. Minor edits have been made to support audio voiceover for the podcast.

The other day I heard a story on the radio about the US initiative for controlling health care costs. Someone had studied various health conditions and tried to measure which ones, if controlled, would reduce our country's total health care costs.

The radio report said that controlling obesity would reduce the total costs, but getting more people to quit smoking would actually increase total costs. Instead of people dying young from heart disease or lung cancer, they would live so much longer that total costs of care over their now-longer lifetimes would rise instead of falling. So, the reporter implied, we shouldn't encourage people to quit smoking; just let them die young.

Wow. Even if the reporter was being sarcastic (if so, I missed that tone), what a thing to say.

I'm not exactly a fan of smoking, but as someone who has lost beloved family members too young to both heart disease and lung cancer,  this was offensive. What, we should as a nation tackle the challenge of obesity, but it's OK to let people die young from lung cancer and other smoking-affected diseases because it'll be CHEAPER?!

Wasn't that pretty much the plot of the dystopian novel Logan's Run which I read in high school? Logan's world has too-scarce resources, so they just don't let anyone get old and expensive to take care of. Everyone gets 21 good years (30 years in the movie) and that's it. Lastday.

(I did some homework and it turns out that - as is usual with medical studies and stories - the data is mixed on whether health care costs more for people who quit than for people who continue to smoke.)

On reflection, I realized that Logan's Run (a book I hadn't thought about for years) is actually a great illustration of the problem of 'measurement dysfunction' in software development. You get what you measure. If all you measure and care about is absolute total health care costs, then Logan's Run-type solutions really are optimal, right? But the clear problem with that set of measurements is that they don't consider the value of human life, of wisdom, of parents and grandparents and elders, of having more good productive years of life and love instead of fewer.

If all you measure is total software development costs, then by all means, have the work done by whoever is cheapest. If all you care about is schedule, then go ahead and push that product out the door on time with a ton of latent (or known) defects. You will get what you measure.

You will also likely 'get' some things you don't measure and probably don't really want, like rising technical debt and customer support/maintenance costs. Like a cancer, they will gradually kill your product, metastasize throughout your organization, and cause great pain for you and your people. Your product and company will live an inexpensive (at least until the end) - but short - life in your virtual Logan's World.

As for me, I'd rather keep looking for Sanctuary, working towards a more sustainable world, and trying to find ways to help diagnose and cure lung cancer.

This post was first published on the agile Teams WordPress blog on February 27, 2010. As of July 12, 2024, all agile Teams content has moved here to Agile Analytics and Beyond. Minor edits have been made to enhance accessibility and to credit the photos.

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 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."

(Event photos, including one with Dr. Brooks, are now included at the end of the post.)

My opening comments focused on the 21st century reality that almost all teams face the communication risks which are associated with globally distributed software development (GSD), even if no offshoring is involved: from distance, time zones, culture, and language barriers. Contrary to the myth of the solo programmer hacking out code in his/her cave, up to 70% of a developer's work can involve communications with other people. So being able to collaborate well under GSD-like circumstances matters in practice. Yet this is seldom recognized or addressed.

I did a quick 'show of hands' exercise with the audience to identify anyone who did NOT work with people who are from a different culture, have a different native language or educational background, sit more than 30 meters away, travel, telecommute, or work from home. The result? Only two people, one of them currently between jobs, didn't work under these team conditions.

Bob Galen identified some key patterns and anti-patterns he's noticed over the years:

• Good patterns include collaboration, professionalism (including TDD, or test-driven development, and BDD, behavior-driven development); being 'language agnostic'; recognizing that "it depends"; allowing for variable scope and trusting the customer; and simplicity (using the Pareto or 80/20 rule).

• Anti-patterns include poor listeners; non-continuous learners; laziness; and allowing oneself to be a victim of business pressures.

Bob commented further that he often sees so much emphasis on estimation that people "miss the actuals".  He also observed that "planning is both everything and nothing": plans are useful as roadmaps and adaptive models, not as constraints.

My own experience in preparing for this panel session was a clear example of the principle that planning is invaluable even though plans 'seldom survive first contact'. I had prepared some slides in advance for my POV presentation. At the panel, none of us showed or used slides; we all talked extemporaneously based on reference sheets of notes. However, the time I spent preparing my plans (slides with notes pages) wasn't wasted. Doing so really helped me to clarify in my own mind what I thought were the most important points I wanted to make. Plus, a printout of my slides served as my 'talking point' notes, as well as on-hand paper for taking these notes on what everyone else said and what questions were asked by the audience. A PDF handout of the slides I 'used' will be available for download from the Agile Teams publications page.

Andy Hunt focused on what it means to be agile, suggested that an actual definition of agile was needed, offered one: "Agile development uses feedback to make constant adjustments in a highly collaborative environment." Then he queried, "When would you not want to do this?" He identified having an accessible, co-located customer as the biggest success factor, and commented that Scrum stand-ups are useful because they "help the team get out of their own way".

On the technical side, Andy cited a mantra inspired by Dijkstra's 1972 Turing lecture "The Humble Programmer": Always remind yourself "I am an idiot", and get another pair of eyes to look at your idiotic code, because you really do not know for sure what it will do. Andy also observed that you could replace S/360 with the name of a modern computing system in Brooks' classic book "The Mythical Man-Month", and find it still holds up today.

Favorite practices the panelists agreed on: version control, unit testing, and automation. (Andy characterized these as "hygiene, like brushing your teeth".)

Audience and moderator questions touched on the topics of:

• Eliciting and considering non-functional, or performance, requirements. This is big on my lessons-learned list, based on my experience in software requirements and architecture. Customers often do not think to even mention these needs, but they are critical to delivering a product that people actually buy and use. Requirements in general are not mushrooms waiting to be gathered, they are more like truffles that an industrious pig must locate and dig up! Andy suggested that developers should learn interviewing techniques from journalists.

• Whether reuse can ever work. None of the panelists has really seen it work in practice outside of a group, which I view as a matter of trust.

• How to keep team members happy and reduce attrition. Money is important, but not all-important; good relationships with managers and a sense of teamness with peers matter a great deal. Best way to find out what kind of recognition or reward matters to them? My answer: Ask them.

• Whether demonstrating working software at the end of an iteration really works well. Panelists' answers: yes - it's great for building trust with your customers; just find a way to do it, even if what you did during the sprint was more along the lines of infrastructure or 'plumbing' (Bob's term) than executable code.

We all agreed on the importance of having good people, although we didn't completely agree on the criticality of having the most-skilled top 1% of people in order to be successful. Most companies will need to find a way to be successful with the people who fall in the middle of the bell curve, not just those few who are on the high end of the long tail.

Some key points we agreed on:

• The phrase"agility vs. discipline" is misleading because being agile requires significant discipline, and being more agile requires more discipline.

• Management and leadership are distinct (my view: good managers lead people and manage projects).

• Over the next 10, 20, or 50 years, the world of software will keep changing at a lightning pace; being willing to keep learning is essential.

What a great way to kick off the local Computer Society chapter's 2010 year! Kudos to leader John Baker for organizing and moderating some enjoyable discussions! (See John's blog post and tweet, and Andy's tweet, about meeting Dr. Brooks).  I'm looking forward to the next chapter meeting! (See the LinkedIn group for more details.)

Event Photos

• March 22-25, 2010: Software Engineering Process Group (SEPG) North America 2010 Conference, “Applying Requirements Metrics To Guide Project Management And Assess Process Improvements”, Karen Smiley, Qingfeng He, Prateeti Mohapatra.

• May 17-21, 2010: SEI Architecture Technology User Network (SATURN) 2010 Conference, “Efficient Software Technology Evaluations Leveraging ADD” (half-day tutorial), Karen Smiley and Elizabeth Kielczewski.