3 Agile Scrum tips for content design
I have been nostalgically gratified to read articles from my friends and former colleagues Sol Sender and Charles Chesnut, writing about the challenges of adopting agility. I was in the first Scrum (Cloud Computing) team in the IBM Digital Lab that Charles headed. Sol was the owner of the product. It was an experience of applying agile methods to digital marketing work. Once we fixed the bugs, we extended it to a lot of other teams. Since then, I have worked in over a dozen agile teams, and have been a product manager for several of them. Along the way, I learned a few tips for Agile Scrum that can help managers, individuals, and executives embrace Agile more fully.
Before I get to the hacks, let me preface this: I’m a strong advocate of agility, especially agile melee. Scrum helps me manage projects in a measurable, repeatable and non-arbitrary way. It also helps me manage people by giving them an interest in choosing what to do next and what it means to “do”. I believe in empowering team members to do what they love on the terms they set as a team. When Charles sent a survey to managers about their attitudes towards the agile scrum, I said, “The best project management system ever! “
I really like agile, but I’m not an Orthodox melee practitioner. There are certain aspects of the Agile Manifesto that ring absolutism. Orthodox scrum practitioners claim that if you do not follow the letter of the Manifesto, you are putting yourself in danger. Any deviation from the manifesto is called “scrum but
Scrum masters can instill discipline in a team by helping team members work together even if they do not 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 start-up teams. Ideally, everyone on the team is a jack of all trades and a master of “T” skills, as Sol alluded to in his post. But learning other trades can be slow. And mastery is so hard earned that 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 poker planning breaks down into sizing apathy, it can lead to bad behavior. Some creatives pad their waists to protect against Writer’s Block or the equivalent. Since a team doesn’t get any points if the story isn’t completed, team members also complete the stories to make sure they get their points. Even though the team seems to have high speed based on how many story points they complete, they aren’t doing as much as they can.
The hack for this is what we call “attraction stories”. These are stories the team hasn’t sprinted to, but can work on if they have spare cycles due to addictions. For example, a writer may need to wait for an editorial review before revising an article. If the writer has nothing else to do, they can pull a story from the backlog and work on it until the editorial review is complete. If it finishes the story in that sprint, the team counts the points. If it doesn’t complete it, the story is at least partly over when the team commits to it in the next sprint.
Pull Stories encourage good behavior and team initiative. In the teams I have led, encouraging pull-in stories have increased our speed by 20-30%.
One part 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 a feature showcase every sprint, which is ideally just a bunch of working code demos and nothing else. This tends to maximize speed because developers can spend more time working on code and less time documenting.
Additionally, there is a popular myth in software UX communities that documentation is useless if the product is designed correctly. Anyone who’s tried to teach a beginner how to use an Apple computer – the one who isn’t supposed to need documentation – knows that’s not true. But the myth amplifies the contempt of software developers for documentation.
Outside of software development, executives want to see more than just demonstrations. They want to understand the value of work and how it relates to other work in the business, among others. Plus, leaders love to see 30/60/90 plans for the job at hand so they can understand when they can start reaping the business benefits of the job. Because traditional feature presentations don’t meet their needs, executives often skip presentations after the first ones. The team then suffers from a lack of visibility. I’ve seen strong teams lose funding because executives don’t see the value.
The hack is all about creating compelling feature presentations. They should always include demos as much as possible. But the demos need to be put in context for the executive audience. This means not only telling what you did and how it works, but why it matters and how it relates to other stories in past or future sprints. The team should spend about a tenth of their time (one day per sprint) working on the presentation, but creative teams are actually good at it. And there are many benefits to documenting the value of your work. For example, the feature overview library can be used for other purposes, such as business cases and training materials.
Agile Scrum is a great way to maximize the value of teamwork. But this is not a universal solution. You need to apply it flexibly to make it work best, especially in creative environments. Here I have described three hacks that have worked for me, especially on teams that build microsites. I believe it’s nimble, if not literally, to try new ways to hack scrum, depending on the team you’re leading. It’s certainly a lot better than rigidly enforcing scrum and letting teams fail because it doesn’t yet fit the corporate culture.