Spotify Engineering Culture: Scaled Agile

This excellent video was posted on an Agile blog that I follow: Crisp’s Blog.

(I apologize for the lengthy break in posting content. Turns out, having a child changes your life immensely. Imagine THAT.)


Development and Testing in Agile Shouldn’t Start the Butter Battle

I have heard the word “silo” used to describe the cultures on each side of the invisible wall that sometimes exists between our development and our testing teams here at work—even after we’ve implemented Agile at our company five years ago. You would think by now, we would have learned that can’t exist in a successful Agile environment, but there are still individuals, on both sides of the wall, that continue to enforce the separation.

I wish they would stop it.

It reminds me of Dr. Seuss’s The Butter Battle Book, where you have two hostile cultures, living on the opposite sides of a wall, separated by their bread-and-butter differences. Their hostilities very nearly result in mutual destruction.

As a Scrum Master, I dread the start of a project when I’m waiting for the software tester to be assigned because I don’t want it to be one of those “Silo-ers” or “Butter Side Up” citizens. Because my boss is the supervisor of the software developers that will be on my team, I can use him to push back on any “Silo-ers” or “Butter Side Down” citizens coming from the development side of the wall and force them to STOP IT.

But my influence on the software tester is limited.

One of the approaches I have taken for breaking down their invisible wall is to ENFORCE team testing.

Here’s how it goes.

  1. Tell Them. I inform the team that we are going to be doing team testing and the software tester will lead this. They seem surprised.
  2. Explain Testing’s Role. I remind the team that testing is not a SEPARATE activity removed from the rest of software development. From experience, the developers all agree on this as they are constantly testing their own code through numerous methods. But sometimes, the software tester is surprised with this mentality.
  3. Plan Testing Time. Set it up as a time box and put it on team members’ calendars. If you have access to a computer lab where you can all work in the same room, do that. Unfortunately, at my company, our software testers don’t sit with the rest of our agile team. We schedule virtual meetings instead where everyone’s at their own computer with their headsets on and we connect through Microsoft Communicator.
  4. Write a Testing Plan. Ideally, this would be completed by the software tester, but in some cases, I find that they are still pushing back because they are intense “Silo-ers” so I may take this piece on. I ALWAYS communicate everything I’m doing about this with the software tester and do my best to let them know that they are really the one driving this. This is where they need to lead the team because they’re the EXPERT. It’s always good to play up somebody’s ego, right?
  5. Execute. Give the team the plan and have them go at it during their scheduled testing time. I’ve always made myself a member of the team as well with assignments in the plan. This helps me to understand the software better and brings the team together as well.
  6. Document. Document EVERY part of what each individual does for the testing plan. This will require each team member to be as exact and detailed as they can, but you know the software tester wants every little piece they can get. If you’re going to do it, do it right.
  7. Give the Results to the Software Tester. At this point, I step back and let them do with the results as they please, but usually, they start to realize, “hey this works!” And, the entire team OFTEN tells them they now have more respect for what they do as a software tester and how detailed they need to be in their tasks.

You are part of our TEAM and your piece is just as important to the team as the development is when it comes to actually getting stories to DONE.

What do you think? Is that an appropriate job for the scrum master to do? Does it work?

Too Many Chickens at the Stand Up

An important part of Agile projects are the daily stand up meetings or daily scrum where the team gets together to report three simple things: what they did yesterday, what they’re doing today and any impediments in their way. For my current project, only the team attends our daily meetings. They are my pigs—the committed team members. But for another Scrum Master here at work, he has a lot of chickens coming to his daily meetings. These chickens are interested people—only involved but not committed.

And by Scrum rules, only the pigs should be speaking at the daily scrum. The chickens are supposed to keep their yappers shut and simply listen.

The other team finds, though, that they can’t keep the chickens quiet. Two thumbs down to those chickens.

How would you handle these unruly fowl?

A discussion over on the Scrum Development group website had some interesting insight into this dilemma. For one team, they stated that they have 5-6 members and 4-5 managers attend their daily meetings, which makes the team uncomfortable and concerned.

Bring on the diplomatic skills of the Scrum Master!

Have you dealt with this situation? How have you handled it and what works best?

Looking Good: Agile Project Dashboard

I overuse and therefore abuse a phrase with my Agile team: “look good.”

It’s all about looking good.

What are you doing today to look good?

Does the team look good?

Does our project look good to management?

And so on.

Scrum certainly has the goal to deliver value to stakeholders and make customers happy. I think teams often focus on getting out frequent releases in order to do this. But aren’t there more ways than just delivering software to do this? What about continually delivering value to your stakeholders while the team is gearing up for the next release? Do people outside of your team have clear visibility on your team progress and project status? Or is only your Product Owner checking your burndown chart?

Maybe they’re not even checking, but that’s a different blog topic.

Shortly after I finished my certified scrum master class, I met with a couple of project management experts to work on putting together a tool to deliver value to stakeholders and make customers happy throughout the project. I also happen to be related to these experts: my dad, Clark and my brother, Mick.

Our goal: a one-page project status for agile projects.

Would that be useful for your organization?

I see a ton of value in having a great report to show several important metrics about your project: project progress schedule, delivered business value, product release burn-up chart, risks, the release plan, and the overall project status.

We spent an entire day hashing out the design, utilizing giant post-it notes on the walls of the office:

Spending a day determining what needs to be included in an agile project dashboard.

In the end, we feel confident in our Agile One Page Project Manager, simply using Excel to create the report. What do you think?

Mick and Clark are coming out with a book, The New One-Page Project Manager, that will describe the step-by-step process of creating the report and the purpose of each piece. Would a tool like this be useful for your Agile projects?