HL Arledge

Do you need to hire a consultant to fix your team?

In business—and in life—you get back what you put into it, but do you really need to hire expensive consultants—or pay for re-certifications—if you don't need them?

Most everything that works is documented in a book somewhere—or it can be learned from experience. Even things that are better learned in a classroom setting will not require refresher courses unless (1) processes and strategies improve, or (2) you don't practice what you've been taught.

This all crossed my mind when I was prompted by the Scrum Alliance to re-certify—just pay them another hundred bucks per certification—as a Scrum Master and as a Scrum Practitioner. The re-certification provides no new training as Scrum processes and strategies have not changed—although Ken's new book did enhance existing processes with some trial by fire examples.

I live Scrum everyday, so I have more Scrum experience than most Scrum trainers, so tell me again why I should send more money to the Scrum Alliance?

Consultants are the same. If you listen to them long enough, you'll break things and believe the consultant predicted the break—the same day you paid him to tell you how to repair it.

What's on your Task Board?

Yesterday's discussion of User Stories reminded me of a template Kane Mar had provided during my ScrumMaster Certification course. The template is designed to work on 3x5 cards and travel within the task board, as do our Project Backlog Items today.

The front of the cards say:

Story Title

As a  X  

I want Y

So that Z

Think of the story title as "what you'd call it if you were making a movie of it".

X is the person who will benefit from this story being delivered.
Y is the content of the story.
Z is the benefit the story will deliver.

This is great because it makes the business value explicit, so the programmers understand what the customer hopes to get from the story. Often the actual benefit can be delivered by a different Y, but that will discovered during planning.

The back of the cards are divided into two columns, labeled:

User...	Application...
Clicks the Skull and Crossbones.	Erases the hard-drive.

These represent the top level acceptance criteria.

When the user can do all of those things, and all the corresponding things happen, I'm done. At Decade Software today, our use cases are broken into tables that track exactly these same steps.

You can imagine some interesting patterns here. For example, if Z is just a restatement of Y, the customer typically hasn't thought through the real value of the story. Stories even vanish during planning for this reason—following statements like...

"I guess we don't actually need that feature."

or...

"I thought you said we needed that option."

...And Mr. Agile said, "Let me tell you a User Story."

Darryl Booth has recently taken on the role of Client Services Manager at Decade Software, but for the last few years he has been the guiding force behind our Design Team.

The Design Team itself has also underwent change, as many designers have grown with the company and taken their knowledge of the application into other departments.

With EnvisionConnect's foundation laid and its core functionality solidifying, the remaining designers are struggling to keep up the pace of subsequent product iterations. Does this surprise you?

We have found that the bells-and-whistles of subsequent iterations—those additional coats of paint that all good applications require—are extremely time-consuming, both for the developer and the designer.

Just as one code change can break code downstream, technical choices in first iterations can often change the course of subsequent iterations, so if you think that the designer's job gets easier in subsequent iterations, you are mistaken.

Sure, by now the remaining designers have had extensive communication with the customer, and they have meticulously documented the customers every need. However, as customers use the application provided by the initial iterations, these customers have reserved—no demanded—the right to change their minds.

There are many things that can make a designer's life miserable in preparing those subsequent iterations, but the toughest is likely the time spent on communication.

Darryl came to me yesterday saying, "I'd like to boil down the details of each use case into goal statements for each item on the product backlog. I believe it will help communication between designer and developer if both are clear on the essence of what the customer expects to be delivered, even if the details have to be changed. What do you think of this idea?"

"Sure, Darryl," I said. "I'm always open to improving our processes."

Later, I met with my teams and explained the idea.

My teams hate change, so they weren't exactly jumping up and down, but they agreed to be patient. Afterall, we still have use cases for the details. This new goal statement is just a guiding spirit when the use cases are vague in areas.

At home last night, I realized I was experiencing déjà-vu.

The statements of the day sounded suspiciously like an agile development practice that our company has never experimented with—something called User Stories.

Michele Sliger says Honesty is NOT a Scrum Value

This week, Certified Scrum Trainer Michele Sliger is in the guest seat at ImplementingScrum, where she expresses an interesting perspective on what she labels "Scrum Values".

She defines a team's Scrum Values as those things that fit into the following formula...

We believe in [value] therefore we will [do something].

Her most startling statement was that Honesty is not a Scrum Value.

Michele doesn't disagree that the infectious honesty among team members is an integral part of Scrum. However, she believes honesty is merely a byproduct of the true Scrum Values.

She sites those "true Scrum values" as:

• Commitment
• Focus
• Openness
• Respect
• Courage

Look back at her formula...

We believe in [value] therefore we will [do something].

...and consider the following statement...

We believe in respect for our teammates, therefore we will show up on time for all meetings.

This thinking is just the tip of the iceberg. Read Michele's full post.

I would love to hear your thoughts.

Where is the 'Mystery Spot' in your office?

This year marks my eighth in California, but yesterday was my first trip to one of the state's most famous attractions. As Santa Cruz resident, David Beach, explained...

"It seems, in California, you have the Golden Gate Bridge, Yosemite, Disneyland, and the Mystery Spot. It's a phenomenon on many levels. First, this thing has been open since 1939—every day. Second it is hugely popular for Japanese, German, and Indian tourists. Like crazy popular!

...You see balls roll uphill, water flows backwards, you can stand on the wall, people shorter than other people look to be the same height, and you can lean over Matrix-style without falling down."

Like any good knowledge-addict, I hit the Internet before the trip, and I knew what was really going on. William Prinzmetal, UC Berkeley's adjunct associate professor of psychology, had explained it all...

"All the visual illusions in the Mystery House derive from the fact that the house is tilted. You know the house is tilted, but you don't know how much. Everything is tilted. You can't look outside and get a horizon, so you think that what you see is right."

Prinzmetal is an expert on perception who has been to the Mystery Spot over a dozen times. Although he has studied these illusions in depth, he said his visual perceptions still are distorted every time he enters the house.

Visiting the house, I can relate.

Knowing the theories and understanding the facts, I was still fiercely debating with myself as to what I was actually seeing. That's when it occurred to me: there are Mystery Spots in everyday life—especially at the office!

Truth and Transparency comes to Politics

In 1822, James Madison—the President of the United States—described his vision of a successful government...

“A current Government, without current information, or the means of acquiring it, is but a prologue to a farce or a tragedy; or, perhaps both. Knowledge will forever govern ignorance; and a people who mean to be their own governors must arm themselves with the power which knowledge gives.”

In other words, unless everyone knows what everyone else is doing, there will be failure. Professional Office Holders will not admit mistakes for fear of persecution—and maybe prosecution, and no one can volunteer to help if they do not know where the problems lie.

Does that sound familiar?

James Madison is merely saying that the most successful government will be one governed by truth, trust, and transparency.

In my home state of Louisiana, the Republican governor is blogging about transparency in government, and even our presidential candidates are getting into the act. Barack Obama is pushing for a Google-like search of all government documents and appointment schedules!

In today's USA Today, they collected headlines from newspapers across the country proving that local governments are finally realizing how right Madison was.

Albert Wang talks about IdeaBlade

Decade Software is a Microsoft partner, as is IdeaBlade, Inc—another Decade partner of sorts. EnvisionConnect's database connectivity leverages largely technologies created by IdeaBlade.

MicrosoftStartupZone has spotlighted IdeaBlade with a "Where are they now?" article. Since IdeaBlade's future is connected with ours, I thought readers might be interested in some highlights from that article.

The article reported...

"From single-person developer shops all the way to the Fortune 500, and for 2008, [IdeaBlade] plans to enterprise-enable key technologies from Microsoft such as LINQ and Silverlight, and help .NET become the dominant platform for delivering on-demand enterprise applications."

In an interview, IdeaBlade CEO Albert Wang said that IdeaBlade has doubled or tripled revenue each year since they launched in 2001.

"This is a huge achievement for us. There are now tens of thousands of developers using our product. We have a very passionate, vibrant community of developers and consultants who really like to use our product, evangelize it, and are getting huge value out of it.”

I know we are, Albert. Thanks for being there.

Time to put an end to Sneak-factoring

If refactoring is defined as...

"...any change to a computer program's code that improves its readability or simplifies its structure without changing its results."

Then sneak-factoring is...

"...refactoring that occurs without full commitment and/or knowledge of the coding team."

If you commit to enhancing a specific section of code—perhaps adding some new feature or correcting a defect—your team should assume that some refactoring may occur.

Often when you write code, you're focused on solving a particular problem, so some coding best-practices may be far from your mind. Revisiting the code months or years later, you may find yourself stumbling—or deciphering as you read—your own code and asking yourself...

"What was I thinking?"

Everyone on the team knows this will happen. It has happened to them, so they expect routine refactoring to occur.

Depending on what code you have committed to enhancing, you may need to refactor your own code, or you may need to refactor someone else's code.

In both cases, there are times when developers are reading code that the team has not committed to change, and they will feel that inevitable, uncontrollable urge to reach out and fix something.

Don't do it!

Transparency is one of your team's keys to success. If you change code without anyone else's knowledge, you break that transparency.

In that oh-so-rare instance when your little "improvement" will break something else, no one will know where to look to correct the problem, and the time lost looking for it will cost your team time and your company money.

If you stumble upon code that could use a washing, just add it to your team's task list, and address it when the team has the time to commit to it. If this is not possible—if you cannot control the urge to refactor—at least notify the team of the changes you've made—or better, the changes you intend to make.

You and your team will be better for it.

Serenity Clock and the Lost Defects of Doom

Our Quality Assurance Engineers have been integrated into our Scrum teams now for over a year.

For the most part, this integration has improved quality by leaps and bounds, but like others learning the ways of Scrum, our QA Team admitted just this week to still harboring a few die-hard habits and fears.

In a Scrum world, a meeting of retrospective follows the end of every sprint, and in that meeting, all problems and mistakes are identified and potential avenues for improvement are explored.

Eventually, through this incremental process improvement cycle, both process and product become more refined.

The one thing you don't do is to try and solve problems before they are proven to exist. Unfortunately, this way of thinking is completely counter to the historic QA mindset.

That traditional mindset reminds me of Indiana Jones.

Indy tackles a problem head-on, expecting the worse, and improvising as he is attacked. When sent into a cave to retrieve some artifact, he knows he must explore every tunnel, even if he knows exactly which cavern holds the item. If he doesn't do this, some giant boulder or tribe of cannibals may come out of that tunnel and the movie will end early.

Our QA team—Dave Blanton and Serenity Clock—dream of similar adventures.