Author Archive: Peter Green

Scrum: the Model-T of Agile?

Posted on November 27, 2012 by Peter Green | Comments (2)

Several years ago during a break in a scrum training class, a student approached me and asked “what do you think will come after scrum?”. At the time, I had no answer for this question. The several teams that I had worked with that had used scrum had gotten so much benefit from it, and the rest of the organization needed scrum so badly (in my opinion), that I couldn’t imagine the need for anything different for product development.

Our organization, its environment, and my understanding of scrum have all evolved quite a bit since that day. If asked the same question now, I would have several possible ideas to discuss, depending on the team and the situation. Scrum would probably be the starting point for all of those conversations, but in many cases it would be augmented by something else, or a modified version of scrum, or some other agile approach like Kanban might be the right answer. There are still many parts of our organization that will benefit from adopting scrum, and teams that have been using it for years have all evolved their own implementation of scrum that suits them well. I don’t see scrum going away in organization any time soon. But if it did not evolve it would seem a failure to me.

Scrum was invented in the early 90s. We’re approaching its 20 year anniversary. In software terms, that is ancient. That it has survived and in many ways thrives is a testament to its broad applicability.  Most successful scrum adopters will augment the framework with other technical and business practices like XP, Innovation Games, and Lean Startup. Particularly with teams that are taking a Lean Startup approach, I’m beginning to see the need for the way we understand the Product Owner role to evolve. I’m not sure how that evolution will happen, but I wouldn’t be surprised if on such teams, the PO role gets absorbed into the cross-functional team, doing both the idea validation with customers as well as development of the software that results from those discussions. I wouldn’t be surprised to see Product Backlog Items sorted into categories like “working software”, “idea validation”, and “technical validation”, rather than having a single Definition of Done for all product backlog items. While this could be a slippery slope for an org that is not agile in its culture, experienced agile teams can gain significant advantages from such an approach since the learning we need most doesn’t always require us to build working software to get an answer (check out the link to Lean Startup above for more on this idea).

With these thoughts in mind, I started wondering: “Is scrum too much of a sacred cow to evolve?” I’m not sure the answer to that question, but while thinking about it, the idea came to me that Scrum is not a sacred cow as much as  it is the Model-T of agile.

Ford didn’t invent the automobile, that honor goes to Nicolas-Joseph Cugnot, Gottlieb Daimler, Carl Benz, or Wilhelm Maybach, depending on the book you’re reading. What Ford did was figure out a way to mass produce the automobile and sell it to the public at an affordable price such that it became an integral part of the lives of nearly everyone on the planet today.

 

 

Similarly, Jeff Sutherland and Ken Schwaber didn’t invent agile. The ideas of agile go back to at least the 1950s and probably before that, and are part of a family of new approaches to doing business that also includes movements like Lean, Theory of Constraints, and Six Sigma in manufacturing, Leadership Agility and Radical Management in management theory, and Lean Startup and Innovation Games for learning about customer needs. What Jeff and Ken did was figure out a way to mass produce Agile and sell it to the software industry in a way that has put agile on the map all the way up the C level of nearly every organization where software is important. Gartner famously predicted that by this 2012, 80% of software development will be done with an agile approach. The focusing of agile principles into a broadly applicable framework like scrum was a major innovation, just as the development of the Model-T assembly line was a major innovation in manufacturing.

The Ford assembly line was the exact innovation needed in its day. It persisted as the primary innovation in the auto industry until the 1970s when companies like Toyota evolved a newer approach that was more fit to customer’s evolving needs and provided higher quality products. It took decades for Ford to adopt similar approaches to catch up to Toyota. The question for me is this: at 20 years old, will Scrum see the need to evolve, and if so, how?

Talk to your customers

Posted on November 13, 2012 by Peter Green | Comments (3)

I have heard something multiple times this week, something that has me a bit concerned. The gist of the sentiment is something like this: “Oh, we discourage the developers from talking to customers; we don’t want them to be distracted from their work or to build a bunch of stuff that’s not in the plan”.

If you are working in an agile environment, this sentiment is outdated and harmful. We want developers to understand the customers and have empathy for them, and there is no substitute for direct interaction for building that understanding.Let me start by discussing the agile mindset regarding developer-customer interaction, then address the concerns expressed in the statement.

Cross Functional Teams

Agile, and specifically scrum, relies heavily on the idea that cross functional teams build better stuff. While product managers, sales people, and similar roles have responsibility for understanding the customer problem space and communicating it to developers, and agile teams typically have a Product Owner for a similar purpose, agile teams see that expertise as a part of their team, not a separate group. The most effective development teams try to learn as much about the customer problem space as possible. They make multiple small decisions every day about how to solve customer problems. Requiring all knowledge about those problems to be siloed in one person or group, and separating that group from the team creates an unnecessary bottleneck to the system. Once developers understand the Why of what they are developing, they become much more engaged, championing solutions that they think will best help their users.

Empathy

Great products emerge from experimenting in the overlap between the customer problem space and the technical possibility space. Developers know the second space well, but can only know the first space through experience either as an actual customer or through talking to customers. In my experience, great products are rarely built without the developers having a good idea of how their customers think, and more importantly, empathy for their problems. Chip and Dan Heath give a great example of this in their book Switch. They describe a Microsoft team full of brilliant developers. They were certain they were writing brilliant software, but when the usability group tested it with users, six out of 10 customers couldn’t figure out how to use the new features. When they told the programmers, their response was, “Where did you find six dumb people?” To increase empathy, Microsoft brought the programmers into a usability-testing lab and put them behind a two-way mirror. When the programmers watched a real customer struggle with the software they designed, the programmers immediately started thinking about ways of changing it. They were developing empathy for the users, and instead of contempt for their ineptitude, they developed an intrinsic desire to improve the software to better meet the needs of the customers.

But what about those concerns?

“…we don’t want them to be distracted from their work…”

In his book Radical Management, Steve Denning describes a shift in the way that we describe the high level goals of everyone at a company. He proposes that the primary goal of every employee is to “Delight Customers”, and that companies should set measurable goals for the company, executives, and employees related to this purpose. In this light, the idea that a developer’s work can be summarized as “writing code” feels almost insulting. Great software teams tend to spend the vast majority of their time figuring out what problems their users are facing, potential solutions to those problems, and the best technical approach to solving those problems. A small percentage of their time is spent actually typing code. In this environment, “their work” is not just writing code, but delighting customers.

“…we don’t want them to build a bunch of stuff that’s not in the plan…”

This one’s pretty easy to address in an agile environment. One of the simple rules of scrum is this: “if it’s not in the product backlog, we don’t work on it”. This provides transparency to the system.

Another potential concern:

“…developers will promise customers stuff that we can’t deliver…”

Sales people have been doing this for decades, so this isn’t much different <grin>. At least if developers promise something, they get to experience a direct consequence of their action, so the behavior is likely to improve.

So get out of the building, talk to customers, find out what’s driving them crazy. Scrum says that developers should spend 10% of their time on forward looking backlog refinement. What if they spent an additional 10% of their time talking to customers? Would we have a higher chance of delighting customers? It’s an interesting hypothesis. Anyone care to test it?

Premiere Pro Agile Adoption Experience Report from Agile 2012

Posted on August 17, 2012 by Peter Green | Comments (1)

Hi all,

I had the opportunity to present an experience report about the Adobe Premiere Pro team’s adoption of scrum at the Agile 2012 conference today. I’ve uploaded the 10 page paper here, as well as the slides from the presentation. If you have any questions or comments, add them below and I’ll be happy to share more!

Agile 2012 day 1: Leadership Agility

Posted on August 14, 2012 by Peter Green | Comments (2)

This week I am attending the 2012 Agile conference. Below is a quick recap of some highlights for me today:

  • In the morning, I started out attending a session but found it to be, shall we say, “uninspiring”, for me. Using the Law of Two Feet, I took off after about 15 minutes. The other sessions I had marked as interesting were full, so I wandered the halls.
  • Wandering the halls is awesome. I ran into LOTS of friends and met some new ones. Instead of sitting impatiently in the originally planned session, I ended up in great, engaging hallway conversations:
    • Listening to Mary Poppendieck describe how software developers and hospitals have, generally, eerily similar bottlenecks (deployment for software, discharge for hospitals)
    • Getting picture taken with Luke Hohmann, excited about the release of Scrum Knowsy (sorry, too lazy to look up the character for “registered”). (BTW Luke, I’m still waiting for the cardboard version of Knowsy to be released. I’m all over it when it is!)
    • Catching up on our plans to put together a Lean class for agile practitioners with Robin Dymond and Bas Vodde
    • Seeing my friend Roger Brown who is organizing this year’s Coach’s Clinic, seeing if I could help coach anyone dropping by
  • In the afternoon, I attended the session that immediately made the whole trip worth it: Bill Joiner and Michael Hamman presented on Leadership Agility. My summary follows the break.
  • Caught up with Lyssa Adkins, author of the fantastic book Coaching Agile Teams and Michael Spayd – my personal coach.
  • Had a great dinner with some of our fantastic Adobe agile coaches & gurus: Eric Rapin, Barb Spencer, and Duane O’Brien.

Continue reading…

What got you here won’t get you there

Posted on July 23, 2012 by Peter Green | Comments (0)

The famous quote that is the title of this post typically refers to how an individual’s approach needs to change as they move into management and then executive leadership. I like to think of it in a broader context. In a business where the environment is constantly changing, the approaches that were successful in the past are often less effective in the new, evolving work. Unfortunately, just like newly minted managers trying to succeed by doing everyone’s work for them, or new execs struggling to get out of tactics and into strategy, we often find it difficult to break our habits, especially when those habits have yielded success in the old context.

The same applies to teams attempting to break old habits. When teams try to adopt a new approach, like agile, or a framework, like scrum or Kanban, they often find themselves falling back into old habits shortly after the afterglow of training wears off.

Scrum defines a role to counteract this problem, that of the scrum master. In scrum, the scrum master helps the team be aware of situations where they are falling into old habits. They help the team recognize the possible consequences of that habit, and help them figure out new habits that will get them where they need to be.

Breaking old habits is really simple: Be aware of the habit, recognize a new possibility, then practice! Just like scrum, that simple approach is really difficult to do well. Having a defined role to help the team continually update their habits to more effectively address the current situation is extremely helpful. When we are choosing who should act as a scrum master, we should therefore keep in mind that this role is all about change management.

Scrum masters, how are you helping your team recognize that “what got them here won’t get them there”? What new habits are you helping them form?

Does every item in the product backlog require a User Story?

Posted on June 20, 2012 by Peter Green | Comments (2)

At a recent workshop on agile requirements, I was surprised by the number of attendees who had been told that EVERYTHING in their product backlog had to be written in the form of a user story, and specifically in the format described in Mike Cohn’s great book User Stories Applied for Agile Software Development: As a <type of user>, I want <some feature>, so that <some goal>.

Now, I’m a huge proponent of writing user stories. So-called “Requirements” are the hardest part of software, and a user story, when done right, is a great way to make requirements a little bit better. Like many tools, they are most useful when used as intended, namely a quick way to describe a requirement with a bit of context, so that the team knows who to talk to for more details and what problem the feature is trying to solve. They are not the only tool we can use to make our requirements a little better, we have other things like Acceptance Criteria (actually an important part of a user story, the “confirmation” of the three Cs: Card, Conversation, and Confirmation). We have Story Maps, Use Cases, User Persona, and a host of other great tools to use. User Stories are probably the easiest to understand and teach, and maybe for that reason, they are the most common agile requirements tool. I love to use them, as well as the other tools.

But I am also lazy. I abhor anything that smells faintly of “busy work”. Writing a user story for every item in a product backlog smells pretty strongly of policy over pragmatism, or to put it another way, Processes and Tools over Individuals and Interactions. So jump the break and let’s look at when to use the User Story hammer and when to leave it in the toolbelt.

Continue reading…

Measuring the success of an agile adoption

Posted on June 8, 2012 by Peter Green | Comments (0)

Over the past several years scrum has grown to become the most commonly used product development method at Adobe Systems. Large desktop software products like Premiere Pro and After Effects, Platform tools like Adobe AIR, and Software as a Service products like Acrobat Connect and Omniture SiteCatalyst are using scrum to become more effective at delivering the right solutions to customers with higher quality. In 2011, I presented a paper at the HICSS conference that describes some of the things Adobe teams try to measure when they move to scrum. Details after the break… Continue reading…

The benefits of the Daily Scrum part 1: Building Trust

Posted on June 4, 2012 by Peter Green | Comments (5)

The daily scrum is one of the most recognized parts of the scrum framework. Even for non-scrum teams, it is a simple practice that can bring a lot of benefit to a project.

There are lots of great things that an effective, quick daily scrum does for teams and individuals. Some of these are obvious, like:

  • Keeping the team in sync on how things are going
  • Providing an opportunity for small course corrections within the sprint

Some of the benefits are less obvious, but are every but as valuable:

  • Building trust between team members
  • Encouraging personal planning

I’ll cover the building trust portion after the break, and other benefits in coming posts.

Continue reading…

The Heart, Mind, and Tactics of Agile

Posted on May 11, 2012 by Peter Green | Comments (2)

At the Scrum Gathering in Atlanta this week, my friend Petri Heiramo (@pheiramo) and I were discussing the different agile frameworks, how they were similar and how they were different, and which parts of those frameworks were most important to success. The conversation included lots of sketches on napkins, revisions, and iterations. Eventually we worked out together what we think is a pretty good way of thinking about what Agile is, how the different agile frameworks are similar, how they are different, and how to decide which parts to try in which situations. This blog post clarifies my thoughts based on those notes. We’ll look at Agile in three ways, what we call the Heart of Agile, the Mind of Agile, and the Tactics of Agile.

Continue reading…

Time, Priorities, and Innovation

Posted on May 4, 2012 by Peter Green | Comments (0)

Does your team constantly feel under the gun to deliver more stuff faster? Are you often told that “these features HAVE to be in by the deadline” (or it will trigger the apocalypse, I presume). Oh, and by the way, please be innovative, right away. Let’s take a look at some of the core agile principles, and see how, when applied correctly, they can help companies create a culture of innovation.

I was recently reading this article from the Wall Street Journal. One of the paragraphs says:

“Instead of saying “I don’t have time” try saying “it’s not a priority,” and see how that feels. Often, that’s a perfectly adequate explanation. I have time to iron my sheets, I just don’t want to. But other things are harder. Try it: “I’m not going to edit your résumé, sweetie, because it’s not a priority.” “I don’t go to the doctor because my health is not a priority.” If these phrases don’t sit well, that’s the point. Changing our language reminds us that time is a choice. If we don’t like how we’re spending an hour, we can choose differently.”

This got me thinking about how this applies to our work lives equally as much as it does to our personal lives.

Time in Agile
According to the Principles of the Agile Manifesto, “Agile processes promote sustainable development. The sponsors, developers, and users to maintain a constant pace indefinitely”. This means that once teams figure out what “sustainable pace” means for them, the amount of time we have to work is roughly fixed, with occasional exceptions for urgent & critical business needs.

One opportunity to get more effective time is to examine how often team members are asked to multi-task or context switch. We know that multi-tasking can have as much as a 40% penalty on how productive we are. One of the purposes for the rule about not adding new stuff to the current sprint is to provide the team a chance to focus on the work without distractions. Many teams are also implementing the Kanban principle of limiting Work In Progress (WIP) during the sprint to help cut down on this problem.

Priorities in Agile
Taking the recommendation from the article, we may want to practice changing our language from “We don’t have enough time for that”, to “that’s not a priority for us”. How we communicate that to stakeholders asking us to do their thing may require a little finesse, or we may simply refer to our “Priority Information Radiator” aka the prioritized product backlog, showing the priority of the request, and explain the timing of delivery of their item in terms of our average sustained pace (velocity). There can be some benefit to good politics here, trying to keep the stakeholders happy without setting unrealistic expectations, but having a logical plan behind your prioritization allows you to explain WHY things are in the order that they are. A stakeholder will always want their thing first, but being able to clearly explain the reasons for the priorities as they exist can at least provide context of why they may have to wait. In addition, Luke Hohmann recommends that every release (or every quarter for rapid-release teams), product owners prioritize such that every key stakeholder gets at least one thing. This seems wise to me.

Innovation in Agile
I also hear from teams that they are concerned that Agile might stifle their creativity or innovation. In Tom DeMarco’s great little book Slack, he describes an all-too-common anti-pattern of trying to do more stuff, faster, more efficiently all the time, and how eliminating all slack in an organization leads to an organization that cannot change. If you are seeking to “fully load” all of your employees, first of all, as soon as conditions change they are now overloaded (see above on limiting WIP), and second of all, there is no slack time, no down time to dream up great new ideas, to reinvent processes, to experiment:

“…in the superaccelerated corporation, change of direction is almost impossible. The very improvements that the Hurry Up organization has made to go faster and cheaper have undermined its capacity to make any other kind of change. An organization that can accelerate but not change direction is like a car that can speed up but not steer. In the short run, it makes lots of progress in whatever direction it happened to be going. In the long run, it’s just another road wreck.”

Teresa Amabile writes of this challenge in her article “Creativity Under the Gun“:

If you’re like most managers, you have almost certainly worked with people who swear that they do their most creative work under tight deadlines. You may use pressure as a management technique, believing that it will spur people on to great leaps of insight. You may even manage yourself this way. If so, are you right? Based on our research, the short answer is “no.” When creativity is under the gun, it usually ends up getting killed. Although time pressure may drive people to work more and get more done, and may even make them feel more creative, it actually causes them, in general, to think less creatively.

One of the simple Scrum rules is that the scrum team owns the speed of development, and works on items from the product backlog in priority order at a sustainable pace. If a team decided it wanted to make innovation a priority, and Adobe’s leadership is asking us to do this more explicitly than at any time in my 10 years at the company, I can think of at least three approaches within an agile framework to help this succeed.

  1. Build in slack – the development team owns the speed of development. What if a self-organizing team decided to take a page from 3M and gold,  and pull in sufficient work to still allow them to take 15 or 20% of their time to work on things that they were passionate about? This would need to be agreed to ahead of time with the team and product owner to feel comfortable to me, I don’t think teams should do this in a sneaky way.
  2. A product owner could insert a product backlog item, time boxed, to “work on something you’ve always wanted to” in each sprint. This is similar to suggestion one but makes it more transparent that we value this enough to put it in the backlog.
  3. A team could decide to give a certain amount of time back to the team – there are several ways to do this. The After Effects team does “JDI days” between some sprints, where the team can work on whatever they want whit whomever they want for a day, they just need to demo it at the end of the day. Atlassian (makers of Confluence Wiki, Jira, etc.) do a similar thing company-wide once a quarter. Mike Cohn was telling me about a team that has taken the 20% time approach to their sprints, where every fifth sprint, the team are the product owners and can work on whatever they want- they just have to follow the normal quality guidelines.

All of these approaches would fit nicely within a scrum/agile context. You may read this and say “well, my (Product Owner/Manager/Leadership) would never go for that – we need to get all of these features in by the deadline”, you may be working an environment similar to that described by DeMarco – a Hurry Up organization. Since this may be at odds with most company’s (including Adobe’s) stated philosophy of Innovation first, it may be appropriate to raise this concern with said Product Owner/Manager/Leadership.