Monday, December 7, 2015

Big Picture Retrospectives

Taking improvements beyond the team

Sprint retrospectives are an amazing tool for teams. They foster a culture of continuous improvement and hold the team accountable for making improvements. However, when you look at Scrum beyond a single team, the power of sprint retrospectives becomes diluted. Often there are areas that the team would like to see improved that are beyond its control.

Every few sprints, we run a retrospective that encourages the team to look outside of itself for improvements. We then capture those improvements into an organizational improvement backlog that is reviewed and prioritized by our Project Management Office team and executive management. We review that backlog with all the teams regularly.

Here is the format that we use for our Big Picture retrospectives:

Step 1: Set the scope. Ask your team to imagine the best organization for a team member.

Step 2: Generate ideas. Use your favorite retrospective game to gather ideas for improvement at the organization level. My favorites to use: Mad, Sad, Glad; 4Ls; and Sailboat.

Step 3: Determine the organizational level. Create areas on your workspace for each level of your organization. We use team, division, and organization, but every organization is unique, so choose the spheres of influence that work best for your organization.

Have the team organize each issue into the area that they believe owns it.

Step 4: Create or update the improvement backlog. After you have discussed and organized all the issues, you are ready to add those issues to your organizational improvement backlog. Just like with product features, it is not enough to just add the items to the backlog. To help the improvement backlog's product owner prioritize the backlog, it is important for the team to give a business value to each item.

Step 5: Sprint to improve. Gather together your improvement team and start pulling items from your backlog!

Step 6: Review your progress. When your improvement team's sprint is done, review your progress with all the teams.

Step 7: Retrospect your improvement team's process. Even your improvement team can continuously improve its process for making improvements.

When your whole team is committed to continuous improvement, the results are amazing. By using the same tools we use to create software to improve our process, we can create a culture of agility and continuous improvement.

- See more at:

Monday, October 12, 2015

Agile Open Nor Cal 2015

I spent the last 2 days at an amazing open space event, Agile Open Northern California. The theme was Growing Up Agile and I was lucky enough to not only participate in some great sessions I also had the opportunity to have great conversations in the halls and at lunch tables.

The 2 sessions that created the most hmmm and ah-ha moments for me were Dev-Ops hosted by Gail Ferreira and Modern Agile hosted by Joshua Kerievsky.
One of the best ways to understand the conference is through the amazing art notes created by one of the participants. (Who I would love to credit here so if you know who made the amazing "art notes" please let me know in a comment)

Wednesday, October 7, 2015

Breaking Down the Agile Manifesto

The first step in developing an Agile culture

Today Agile frameworks are being implemented by a wide variety of organizations. They often begin applying frameworks such as Scrum without fully integrating the principles behind the Agile Manifesto into their culture. Without a culture that embraces Agile, the application of any framework will not reach its full potential. The first step in building an Agile culture is understanding the Agile Manifesto. It reads:

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Since its development in 2001, thousands of software professionals have signed the Manifesto and hundreds of books have been written about it. The manifesto has fundamentally changed the way many teams write software. That's a lot, for 68 words written by 17 software professionals over two days at a ski resort.

To build a culture around the Manifesto, we must first explore the meaning behind those 68 words. So let's follow Lewis Carroll's advice and "Begin at the beginning, and go on till you come to the end: then stop."


Good Agile software is not a solo endeavor. It requires close collaboration at every level, from development teams to project teams to organizations to the Agile community as a whole. We are in this together and rely on each other to be successful.
are uncovering

There is no one-size-fits-all solution to developing software. No one has all the answers; in fact, many answers are yet to be discovered. Striving to find those answers is an important part of the journey. Explore, try new things, keep what works, and eliminate what doesn't.

better ways of developing software

We should not be bound by perfect but always strive for better. Inspect and adapt, look for small improvements, and make them quickly. Perfect is the enemy of good.

by doing it

Build software. The best way to find out if something will work is to try it. Failure is always an option. Better software techniques come from experience. You never know if it will work until you try it.

and helping others do it.

Share your knowledge, let others learn from your mistakes and successes. Team up with others so you can learn from them. Mentor others and grow the knowledge of your team and your community.

Through this work we have come to value:

The values of the Manifesto come from hard-won experience building software. They were not developed in an ivory tower; they grew out of the trenches of technology.

Individuals and interactions over processes and tools

Bob Martin described Agile as "a set of values based on trust and respect for each other and promoting organizational models based on people, collaboration, and building the types of organizational communities in which we would want to work." The main focus of any Agile team should be on the people working together to build the software, and ensuring healthy, productive interactions between those people. Every process or tool that you choose to use should support and enable those interactions between the people working together to develop software. If a tool or process is getting in the way of those interactions, serious consideration should go into why the team is using it and whether there is a better alternative.

Working software over comprehensive documentation

The main goal of a software team is to create software for people to actually use. The goal is not to produce a 200-page spec document that will not be maintained. Document what needs to be documented but strive to make sure that you identify what is important. Document only the important items, because the more documentation you create, the less it is read, and it is too easy to lose the important stuff in a sea of minutia.

Customer collaboration over contract negotiation

Bring your stakeholders into the team engage them. Be flexible. Concentrate on creating collaborative relationships that result in high-quality, usable software that meets the customer's needs. Maintain a structure that protects your resources, but not at the expense of your relationships. Don't sweat the small stuff, and avoid falling into the trap of finger pointing.

Responding to change over following a plan

Agile thrives in situations where there are a number of unknowns or quickly changing requirements. Do not avoid change -- embrace it. Expect change and look at it as an opportunity to create something better than you had planned.

That is, while there is value in the items on the right, we value the items on the left more.

Don't toss out all of the tools of traditional project management and development if they work for your team. However, don't let the tools get in the way of building strong relationships with your customers, or the ultimate goal of your project

Originally published at :

Getting Buy In

One of the most difficult parts of implementing scrum is getting buy in from all the necessary groups. In every organization the path is different, and the obstacles are unique. However, the first steps are the same in almost every organization.

1. Know your Audience
A. Tailor your message to their needs, and concerns

2. Explain your situation
A. Your current process/ methodology
B. Any issues, problems, or inefficiencies

3. Explain the benefits of Scrum
A. Link to your current situation

4. Explain Scrum

5. Be upfront about the challenges of Scrum
A. Make sure to address company specific, cultural and infrastructure challenges


Moving to Scrum: Making the Case to Management, Doug Tillman,, 2007

Explaining Scrum to Your Management Team, Pete Deemer and Gabrielle Benefield,, 2008

Scrum Master : Ken Schwaber’s Top Tips, Ken Schwaber,, 2005

What is SCRUM?, Marc Clifton and J. Dunlap, , 2003

Redistributable Intro to Scrum, Mike Cohn, , 2008

Unit testing, , 2008

How to Track Testing

One of the hot topics lately is how do you account for QA within the framework of Scrum. In my experience we have tried 2 methods the "task" method and the "state" method. Since every team is different I think it is worth mentioning both.

The first is the state method which borrows slightly from Kanban. In the simplest terms you add a column to your SCRUM board to represent the "IN TEST" state. Once the developer is done with a task it moves from the "IN PROGRESS" state into the "IN TEST" state. Once the task has passed all of the needed tests it moves to the "COMPLETE" state.

Next is the task method which falls into your traditional SCRUM. All of the QA tasks (Write test cases, build automated tests, test, etc.) are added to the task list and they flow through the standard SCRUM board states.

I have had the most luck with the "task" method because it allows you to see the various QA tasks with as much clarity as the programming tasks. This also alerts you to any bottle necks that could pop up.