HL Arledge

15 Scrum facts that can make or break your team

If you follow Scrum, it can work miracles in your organization, but I've explained many times before that it is far from being a silver bullet. Without making the effort to built and maintain a solid team, Scrum is completely useless.

Scrum is a tool. 

Use it properly, and it will accomplish what is was designed to accomplish.

Abuse it, and you will fail.

To confirm that this is not news to anyone, I offer Scrum Founder Ken Schwaber's text on the subject:

Scrum is Hard and Disruptive!

1. Scrum is a framework for iterative, incremental development using cross-functional, self-managing teams. It is built on industry best practices, lean thinking, and empirical process control.

2. Scrum is optimized for high yield product management and product development. Scrum is particularly appropriate for high risk, complex, large projects and can be used when other parts of the endeavor are hardware or even waterfall development.

3. If waterfall suits current needs, continue using it.

4. An enterprise can use Scrum as a tool to become the best product development and management organization in its market. Scrum will highlight every deficiency and impediment that the enterprise has so the enterprise can fix them and change into such an organization.

A doctor's call on finding new blood for your healthy team

When your organization moves from a command and control environment to a network of self-managed teams, productivity will increase dramatically—as can turnover.

"There’s good fit – like a glove – or there’s bad fit – like socks on a rooster. In terms of an organization, fit has more to do with adapting to, and embracing an organization’s culture."

In a post regarding hiring for a medical team, Dr.Carol Westfal not only defines the problem, but the solution.

"Different personalities can help you define the cultural orientation of your organization. Becoming aware of the importance and value your organization places on these characteristics will help your interview team identify and define its own culture and make it easier to discover the candidate’s relative fit."

Here are some traits Carol says defines an organization’s culture:

Use the Cone of Silence: It's the Law

This morning, I was abiding by California Law, driving with my cell phone in "speaker" mode.

Not only is this experience like using Get Smart's Cone of Silence, but the whole thing is completely unfair.

It's unfair to me, and it's unfair to the underwater person I am attempting to have a conversation with.

This awkward situation has us screaming at each other. Not only is this unfair, but it is also very rude.

I stopped at one light to find a rather obese guy with two egg McBurritos in one hand and scalding hot coffee in the other—but no worries: he had both elbows on the steering wheel.

At the next light, I found myself beside an attractive blond—attractive, because she had her whole beauty shop in her car. She was applying so much makeup as the light turned that I could have sworn she had three arms.

Where's the law against applying mascara and stuffing your face while driving? Is there some survey that proves these folks cause less accidents than those with cell phones to their ears, or is that a law, only because some bored California lawmaker had nothing important to talk about?

Almost to the office, I hit one of those uncomfortable lights. The ones where you are forced to sit in front of a cop. You know you're not guilty of anything, but you're nervous anyway. You start thinking of "what-ifs".

What if I weaved, and he thinks I'm drinking? What if my break light went out overnight? What if that parking ticket in New Mexico last summer finally caught up with me?

What if the cop is bored and looking for something to do? What if he is having a bad day and is looking for someone to take it out on?

In the end, I was able to breath a sigh of relief.

The officer had no time for me.

He was busy with his cell phone in his ear!

Scrum Teams: weighing Individual Performance Appraisals

According to a recent Wall Street Journal headline...

“Teams have become commonplace in U.S. Companies.”

Of course, that is common knowledge to readers of this blog.

It is also descriptive of a problem that I am trying to solve this week.

As I've noted before, most performance appraisal techniques are formulated with individuals in mind—they measure and rate the performance of the individual employee. Therefore, with the number of teams increasing in the organizations, it becomes difficult to measure and appraise the performance of the team.

The problem is in defining how to separate the performance of the team from the performance of the employees.

One solution being adopted by many companies involves measuring both individual and team performance. Sometimes, team based objectives are also included in the individual performance plans.

From a software development perspective, I am pondering how this can be applied to a Scrum team.

I would love to hear any ideas you may have.

Only 12% of all software companies leverage Scrum

You might recall my complaints regarding Axosoft OnTime's advertised support for Scrum and its short-comings.

This week, Axosoft conducted a survey and determined that I was right.

"...Scrum is one of the top methodologies getting adopted by teams. At Axosoft, we’ve been very intrigued with Scrum and the philosophy behind it. Scrum is very much inline with our own development philosophy, and we hope to improve OnTime even more so it addresses the needs of Scrum teams even better in the future."

They also discovered that most software companies are not using Scrum.

Now, you understand why Decade Software is surpassing our competition like never before.

Hiding unjustified stress from your team

Someone said to me today...

"You hide stress really well."

I thought of all of the people in my life that would disagree with that statement, and then, I realized that I do act differently at the office.

Don't misunderstand me. I do try to be vulnerable and honest with my team at all times, but I also strive to guard them from the sky-is-falling types. If my team knows I am concerned, they may lose confidence in our work or in the company as a whole.

For this reason, I try to expose my stress only when I am 100% certain there is a real problem.

Steve Jobs once said...

"Remembering that you are going to die is a sure fire way to remind yourself that you have nothing to lose."

I prefer that my teams think this way.

Don't ignore the risks, but don't run away from them either.

If a team has a leader that is constantly in panic mode, no risks will be taken, no one will focus on mitigating risks, and innovation will die.

How's that for a doom a gloom viewpoint?

What do you mean 'no commitment'?

When I read Ken H. Judy's post title—Stop calling it an estimate. Stop pretending it’s a commitment.—I launched Windows Live Writer ready to attack.

Reading on, I realized it was one of those tongue-in-cheek titles that trick us into reading blog posts.

Ken says...

"Setting an achievable target and owning that decision, communicating the rationale for your decision and having that rationale inform your priorities earns trust and rallies a team to deliver.

Don’t set arbitrary targets. Don’t burden yourself with unnecessary risk, demotivate your developers and thoughtlessly constrain the value built into your software.

Do set meaningful targets. Take calculated risks, manage costs, partner with your developers and know what and when you need to deliver to your customers.

It’s not an estimate. The developer cannot assume your risk.

It’s not a commitment. You’ve got to earn that."

Now, maybe you still see Ken's last statement above as controversial? If so, you have much to learn about truth, trust, and transparency.

Of course, no one in the Scrum trenches would disagree, but on the road to the statement above, Ken has much to say about estimating in general—an area that always prompts a debate or two and is well worth a read.

Grizzlies lost last night, but our team won!

Last night, Decade Software teams from all departments gathered their families and made another trek to Chukchansi Park for an all-you-can-eat BBQ outing.

The Fresno Grizzlies lost to the Portland Beavers, 4-2, but the July temperatures were lower than expected, allowing a good time to be had by all.

I wanted to thank Kevin for funding the event and to thank all who attended for coming out and supporting the DSC team.

Thanks! It was a blast.

How not to hire a developer

This is from a job posting I found on the net...

"Knowledge of agile development methodologies (e.g. SCRUM, RUP).
A BS/MS degree in Computer Science or related technical field is required...One of our guiding principles is no meetings across the team one day a week—great for heads down work and potentially where you do your best work."

This is a place I would never work.

Let's look at the problems individually...

"Knowledge of agile development methodologies (e.g. SCRUM, RUP)."

Any shop that thinks that Scrum is an acronym and that this project management tact somehow equates to the Rationale Unified Process development methodology has no idea how to succeed.

"A BS/MS degree in Computer Science is required."

This requirement has always been one of my favorites, and my perspective on the issue is likely to offend many among you.

Public appearance this week, call the assassin

An invitation for you...

Central Valley Software Partnership

presents

A two-meeting showcase of innovation
in Fresno's software development industry

Participating companies include

July 10

• Argos Software
• Decade Software
• Decipher
• WatchDoit
• Yosemite Technologies

August 14

• Famous Software
• Galaxy IT
• SJV Technology Group
• Company TBD
• Company TBD

Who Can Attend:

Anyone with an interest in the growth and well being of Fresno, California's software development industry.