I was gratified in a nostalgic way to read articles by my friends and former colleagues Sol Sender and Charles Chesnut, writing about the challenges of adopting agile. I was on the first scrum team (Cloud Computing) in the IBM Digital Lab Charles ran. Sol was the product owner. It was an experiment in applying agile methods to digital marketing work. Once we worked out the bugs, we scaled it to a lot of other teams. Since then, I have worked on more than a dozen agile teams, and served as product owner for several of them. Along the way, I have learned a few hacks to agile scrum that can help managers, individuals, and executives embrace agile more fully.
Before I get down to the hacks, let me preface this: I am a huge advocate for agile, especially agile scrum. Scrum helps me manage projects in a measurable, repeatable, and non-arbitrary way. It also helps me manage people by giving them a stake in choosing what needs to be done next and what “done” means. I believe in empowering team members to do what they love on the terms that they set as a team. When Charles sent out a survey of managers on their attitudes on agile scrum, I said, “Best project management system ever!”
I really do love agile, but I am not an orthodox scrum practitioner. There are certain aspects of the Agile Manifesto that have the ring of absolutism about them. Orthodox scrum practitioners claim that if you don’t follow the letter of the Manifesto, you’re setting yourself up for failure. Any deviation from the manifesto is called “scrum but(t),” a derogatory catch-all to attach blame when an agile project fails.
Sometimes scrum butt is the cause of a failure. But as often as not, the failure is in the organizational culture, which doesn’t allow orthodox scrum to thrive. If that culture is unlikely to change, it is often better to adapt scrum to the culture. That is what I advocate. For example, executives insist on reviewing branded content before it is published. That breaks orthodox scrum in a way I will show in detail below. Better to apply scrum flexibly than to have an executive pull the plug on an agile project.
Definition of done
One of the defining principles of agile is to create a usable piece of code with each story. To demonstrate that you’re done, you have to be able to show this working code doing what it was designed to do. In software development, this can be shown on a test server. Bug testing, integration, regression testing, UX testing, etc., can all be done in the following sprints.
Creative pieces aren’t done until they’re approved by executives and ready for publish. The agile hack is to chunk up the process into draft, editing, review, etc. So in those ways, creative agile work can be done in scrum. But the idea of a minimum viable product has a larger barrier of entry. It might take several sprints for a piece to be ready to go live. And you might not have much you can even demo in the feature presentations before it is ready for launch.
One of the principles of agile is “never let perfect be the enemy of done.” But, as I mentioned, a lot of creative work needs to be pixel perfect, per executive reviews. If executives are not allowed to review branded content because such reviews violate a core principle of agile, they will often abandon agile. It is better to be flexible with agile than rigidly insist on releasing stuff that’s flawed for the sake of agility.
Sizing
A key ritual of agile scrum is planning poker, in which the whole team sizes the stories in the backlog so that they can commit to a reasonable amount of work in the next sprint. The team sizes their stories by laying down cards that indicate relative sizing (typically with numbers on the Fibonacci sequence). A story is not sized until the whole team comes to consensus on it. Often this means several rounds of poker per story with discussions in between.
Software development stories are relatively easy to size. Most of the people on the team can work on any of the stories in the backlog, so they have a good sense of how to size them. But creative work is often difficult to size. For example, an agile team in charge of building a microsite will have a content strategist, a UX designer, a coder, a metrics analyst, and perhaps related roles like writers and UX testers. They all need to work together, but they typically don’t have a good idea of how to do each other’s work. So they don’t feel qualified to size it, and often just defer to the person who will do most of the work for a particular story to size it.
Scrum masters can instill discipline into a team by helping team members work together even if they don’t share the same expertise. For example, a content strategist and a UX designer can work together to design content that meets user needs better than either practitioner could have done independently. But this kind of collaboration is unfortunately rare in my experience, especially in early-stage teams. The ideal is that everyone on the team is a jack of all trades and a master of one–having “T-shaped” skills, as Sol alluded to in his piece. But learning other trades can be slow. And mastery is so hard-won, practitioners tend to resist the horizontal part of the T. This leads to sizing apathy, in which practitioners let others size stories in their respective areas of expertise.
When planning poker degrades into sizing apathy, it can lead to bad behavior. Some creatives pad their sizings to hedge against writer’s block or the equivalent. Since a team gets no points if the story is not done, team members also pad stories to make sure they are getting their points. Even though the team looks like it has high velocity based on how many story points it completes, it actually is not getting as much done as it can.
The hack for this is what we call “pull-in stories.” These are stories the team did not commit to in a sprint, but that they can work on if they have spare cycles because of dependencies. For example, a writer might need to wait for an editorial review before revising a piece. If the writer doesn’t have anything else she can help out with, she can pull in a story from the backlog and work on it until the editorial review is done. If she finishes the story in that sprint, the team gets to count the points. If she doesn’t finish it, the story is at least partly done when the team commits to it in the following sprint.
Pull-in stories encourage good behavior and team initiative. On teams I have led, encouraging pull-in stories increased our velocity by between 20 and 30 percent.
Feature presentations
One of the parts of the Agile Manifesto that doesn’t work particularly well outside of software development is the desire to document as little as possible. The team has one feature presentation each sprint, which is ideally just a lot of demos of working code and little else. This tends to maximize velocity because the developers can spend more time working on the code and less time documenting.
Also, there is a popular myth in the software UX communities that documentation is unnecessary if the product is designed properly. Anyone who’s tried to teach a newbie how to use an Apple computer–the one that is not supposed to need documentation–knows that this is not true. But the myth amplifies software developers’ disdain for documentation.
Outside of software development, executives want to see more than just demos. They want to understand the value of the work and how it relates to other work in the company, among other things. Also, executives love to see 30/60/90 plans for work to be done so they can understand when they can start getting the business benefits from the work. Because traditional feature presentations don’t meet their needs, executives often skip the presentations after the first few. The team then suffers from a lack of visibility. I’ve seen strong teams lose funding because executives didn’t see the value.
The hack to this is to actually create compelling feature presentations. They should still include demos as much as possible. But the demos should be put into context for the executive audience. This means not only saying what you did and how it works, but why it’s important and how it relates to other stories in past or future sprints. The team has to spend about a tenth of its time (one day per sprint) working on the presentation, but creative teams are actually good at doing this. And there are lots of benefits to documenting the value of your work. For example, the library of feature presentations can be used for other purposes, such as business cases and training materials.
Conclusion
Agile scrum is a great way to maximize the value of team work. But it is not a one-size-fits-all solution. You have to apply it flexibly for it to work best, especially in creative environments. Here I described three hacks that have worked for me, especially on teams that create microsites. I believe it’s in the spirit of agile, if not in the letter, to try new ways of hacking scrum, depending on the team you manage. It is certainly a lot better than rigidly applying scrum and letting teams fail because it doesn’t fit corporate culture just yet.
