Agile CanonDan Greening is a serial entrepreneur working on his fourth startup, where he leads implementation of two agile practices, Lean Startup and Scrum. Between the third and fourth startup, he was the lead agile coach for Citrix Online, Skype, Overstock, and other companies. He holds a Ph.D. in Computer Science from UCLA. He is a Certified Enterprise Coach with the Scrum Alliance, and a Scrum@Scale Trainer. He has published innovative work on agile management, parallel processing, and chaotic systems.
Many well-meaning people think they can be the First Person Ever to combine waterfall and Scrum, name their new process with some catchy name, start teaching this Frankenstein system, then cause internal organizational chaos or sloth.
Dan Greening explores the challenges of scaling Agile and Scrum concepts beyond the team level to project portfolios with executive involvement. Along the way, he discusses forecasting beyond sprints, commitments vs. lies, dashboard heresy, waterfall compatibility and failing safely, among other thought-provoking ideas. [Part 3: 26 min.]. Interview by Dave Prior at ProjectsAtWork.
Dave Prior interviewed me on the topic of Enterprise Scrum Thinking. In the second part of three, I discuss the experimental mindset of an Agile-run project, how a Sprint is like a science experiment on production (we make a hypothesis, test the the hypothesis and learn from the results), and why fear of failure can doom Scrum. I also touch on the concept of Shu-Ha-Ri, stages of mastery that can apply to learning Scrum.
In the first of 3 podcasts, I discuss how to spread agile approaches beyond individual teams to the enterprise level, where potential benefits and challenges multiply. In the realm of project portfolio management, decision-making roles can include a Chief Product Owner and Enterprise ScrumMaster.
Estimating lots of work items can help agile teams dramatically: Estimates help Product Owners make trade-offs, help teams gauge capacity, help Product Owner forecast feature releases, and help team members think about architectural issues. However, in too many cases, estimating is painfully boring and slow. It doesn’t have to be.
Agile Abandonment Syndrome is a phenomenon where—after implementing agile practices and seeing direct evidence of their benefits—a company stops improving, its agile behaviors degrade, and ultimately loses market share or productivity. We have seen this in many companies.
Abstract
Agile methods create conflict. So to retain agility, we must actively promote it even after agile has taken hold. How can we equip a company with the cultural and process tools to sustain agility? Your choices may depend on your perspective. Social psychologists teach organizations to reinvent themselves, but this approach may be too slow for a large company. Change agents study, develop and evangelize specific processes, a more promising approach. “Adaptive portfolio management” is a specific process under development that may help sustain agile-thinking. It maximizes value by rapidly adapting to market and company changes. In using adaptive portfolio management, company leaders exercise agile fundamentals. They can become agile advocates for the whole organization, making agility more stable for developers on the ground.
Liz Keogh, Learning and Perverse Incentives: The Evil Hat, QCon London 2011
This 50 minute talk discusses perverse incentives: situations where incentivizing individual behavior causes an organization to become dysfunctional. When we attempt to optimize an organization, but fail to use systems thinking (i.e., when we are optimizing from an internal perspective) we can create inappropriate results.
In my last company, I used to hear people say “We need more people to handle this workload.”
Every group in the company considered in isolation could use more people, no matter what group they are in; at least that’s what most people think. But smart folks sometimes say, “We have too many people.”
In Tradable Quality Hypothesis, Martin Fowler says “as soon as you frame internal quality as tradable, you’ve lost.” At the risk of being rode out on a rail, I argue that making quality non-negotiable lets engineers off the hook for understanding internal quality. Quality is always negotiable, and you should understand the benefits and costs of internal quality so you can negotiate and prioritize well.