Steve Neiderhauser

Distributed Scrum Primer

Pete Deemer created the Distributed Scrum Primer, the primer shows distributed teams how to practice Scrum.

One key is communication. And with disturbed teams poor communication places a larger tax on the software project. Why? Because if you spend more time trying to transmit an idea, you spend less time creating working software.

Pete describes a richness scale. The higher a communication method is on the scale, the greater the communication value.

 

 

 

Who else wants to grow like Spotify

Ade Shokoya shares his insights about Spotify and how the company uses Agile development to grow its markets like wild fire.

Of course they create minimal products and release them early to benefit from customer insights. In the Spotify document Alistair Cockburn says, "Nice - I've been looking for someone to implement this matrix format since 1992 so it is really welcome to see."

Just as it's easier for start up companies to take advantage of the cloud's elasticity, it also easier for start ups to embrace the notion of teams and realize one of the key advantages of Scrum — Self-organizing teams.

While a Fortune 500 company hits roadblocks because senior managers want to hold on to their corner office, hold on to their team, hold on to their design, hold on to their customers.

In Agile, there's no place for holdfasts.

Self Organizing Teams

Ruben Ortega summarizes research that explores the benefits of self organizing teams.

Self organizing teams perform a balancing act along three different beams. For example, teams must balance between freedom and responsibility.

Scrum of Scrums

I oversee seven Scrum teams and help coordinate work through a meeting called "Scrum of Scrums." One person from each team attends the Scrum of Scrums and answers questions similar to the daily stand up.

Mike Cohn describes the four questions in this article.

Successful People Ask These Three Questions

Forbes runs this article revealing three simple questions you can ask yourself to increase odds of success.

Let's look at the first question. You can read about the other two.

When designing your way out of a problem, this is the first question you should ask yourself. "What's the outcome I want?"

Asking this question shifts your mind from limiting thoughts to thoughts of creating the solution. It also takes advantage of your mind's goal-oriented machinery. What you focus on expands.

Managing Tasks vs Managing Teams

If you have a team that's underperforming should you start managing their tasks and monitoring their hours.  This approach may seem to help in the short run, although in the long run the team will grow weary and stop showing up for the tasks at hand.

What approach should you use to create a high-performing team?  Manage the team by managing the values they work by.  In Agile development, there's two sets of values.

The Agile Manifesto and the Declaration of Interdependence.  

Let's consider one value from the Declaration — "We boost performance through group accountability for results and shared responsibility for team effectiveness."

So if a team is living by the above value they are holding each other accountable for their performance as a team, including quality and velocity.  Now that's a crazy-productive way to manage teams. 

One Benefit of Story Points

On Scrum projects I've had people come up to me and say, "I have no idea what's happening on a project unless I can see hours."  My response to that is you can't tell how the team is performing with hours.  Is the team more productive when they work 60 hours a week?  30 hours a week?

Story points (relative estimate of effort) show you the improvement of the team… Story points show the velocity and how much a team completed in a sprint.

Here's a story point chart of a team I coached. By using Scrum and Extreme Programming, the team increased its velocity by 391%.

 

Successful Habits of Writers

The skills needed to write software and novels are similar in many ways. Lately I've seen software developers quoting "The Elements of Style" as a guide for creating software.

"Vigorous writing is concise. A sentence should contain no unnecessary words…"

At a software conference, I heard one developer ask for guidance.  "How do you complete software on time? I work 12 hours a day... I answer email. I read blogs. I update my Facebook status."

As laughter filled the room, the speaker, David Heinemeier Hansson, playfully said, "You may want to turn email off."  He went on to explain how he created Ruby on Rails while attending school… He worked on Rails for only a couple hours a day.  A couple of highly focused hours.

Author Jessica Brody provides three tips to help you write. I like her ticking time bomb tip.  She had an old laptop that had only three hours of battery life. Jessica would start to write and when the battery stopped so did her writing.  A clever way to train her mind to be productive.

Swiss Army Knife

An analysis of IT jobs shows that companies are less willing to pay a premium for specialists.  Companies are searching for people who have business skills, multiple talents... a balanced professional who can make projects happen.

To quote David Foote, "They're looking for walking Swiss Army Knives."

The emergance of Agile as a development approach may have something to do with this shift in thinking.  Agile teams are composed of people with cross-functional skills, allowing the team to deliver working software every two weeks.

Are User Stories like Movies

Several months ago I heard an Agile consultant lecture that User Stories are like the stories we see in movies because there's three parts to a user story — Beginning, middle, end.

That's like saying a Rueben sandwich tastes great because it has three parts.  The first bite, the last bite, and all the bites in the middle.  In fact, story expert James Bonnet writes about the limits of the three act structure.

Here's two ways User Stories are like stories.

• They both revolve around problems. The problem in a movie has to be big enough to capture our attention.
• A good movie invokes surprise, delight,curiosity. The screenwriter avoids spelling out every detail, making us active participants in the movie.  User Stories are like that too.

Product Owners should write User Stories in a way that elicits a conversation with developers.  No need to describe every detail of a requirement.  The conversation assures developers actively participate in the design.

So the conversation concept produces some of the same benefits that screenwriters create by using implied dialogue techniques.