When trying to find impediments there is a trap that awaits those of us who are outside of or observing the team. Often, when you are observing a team as an outsider, you may think you see patterns of behavior and obvious disfunction. Naturally enough, not being part of the system often gives us a fresh perspective from which to see problems within a team. Often I have found myself able to rattle off a list of issues that I see a team dealing with after observing them for only a few minutes. Some patterns of team disfunction are suspiciously easy to detect. But wait, here comes the trap. So you make a list, maybe write up a few recommendations and share your “gift” with the team. What team wouldn’t appreciate someone kind enough to share a list of all the ways they suck?
It doesn’t matter if you are right (and you probably are at least 50% of the time). Best case, the team thanks you for your honesty. Worst case, they kick you out of their standup and tell you never to come back. In any case, they aren’t very likely to take your suggestions seriously. The thing about impediments is, in order to really own them and take them seriously, they need to be something the team genuinely care about – and most likely they should be the team’s idea. Ownership is important, because often impediments are pretty tough to deal with, so you need to be really committed if you expect to resolve them.
Often, what I think I see are two different lists of impediments: the scrum master, coach or manager’s list, and the team’s list. The scrum master is scratching their head wondering, “How can I get these guys to engage with these impediments?” Meanwhile, the team is thinking, “Do you really want to eliminate an impediment? Fire a scrum master!”
So I guess the lesson here is that often nobody is all that interested in what you think the impediments are. They already know what the impediments are. They’re just waiting for someone to really listen.
Filed under: Agile, Coaching, Scrum, Teams Tagged: Agile, coach, Impediments, Team
I’ve just added a high level explanation of the anatomy of the Kanban Canvas to the main Kanban Thinking site (where you can downloade the Canvas). I thought I would also post it here.System
How to assess the systemic problem and who is experiencing it.
At the centre of the Canvas is the system being worked on.
Assuming that the current situation is not perfect, and there is always room for improvement, then understanding the scope of the system helps focus on the biggest opportunities for improvement and avoids “rearranging the deck chairs on the Titanic”. By thinking about the situation as part of a holistic system, and having clarity on the scope of the system, we are more likely to identifying opportunities which improve the whole, rather than making smaller, local improvements, which might worsen the whole.
This leads to the question of what is the scope of the system. Defining the system to be too small, might not lead to any significant improvements. Equally defining the system to be too large, might be like trying to “boil the ocean”.
One way of understanding the system is to look at the people involved, and explore what problems those people are having. Narrative is an extremely useful form of doing this – finding and telling stories about people’s experiences and frustration with their work. In particular, the stories related to the customers and stakeholders will start to identify the boundaries of the system.
One fun way of exploring the system through narrative is by using the Pixar Pitch. This approach makes the final “Because of that…” refer to the current kanban system design, and the “Until Finally…” is left blank to be explored in the Impact section.Impacts
How to assess the fitness criteria in terms of flow, value and potential.
The three arrows coming out of the right of the central System are potential Impacts which might be made. These Impacts encourage a focus on what success or failure could look like, before any changes get made.
Given that in most situations, we are dealing with complex problems, where cause and effect are only apparent with hindsight and past solutions are not necessarily repeatable in the future, then we should not try to define a specific future state to solve the problem. However, that does not mean that we cannot determine the characteristics of the outcomes of solutions so we can assess their fitness criteria, or how fit for purpose a solution is.
Impact is an evaluation of fitness for purpose. A successful solution is one which has positive impact and an unsuccessful solution is what which has negative (or no) impact. Impact can be thought of as direction, as opposed to a point solution being a specific destination.
Having explored the scope of the System through narrative, we can also begin to define Impact in a similar way by asking what stories do we want to hear more of, or less off, in the future. When using the Pixar Pitch technique, imaging impossible good and bad endings to the story brings out exaggerated scenarios which can be compared against by asking whether the System is becoming more or less like the suggested endings. Getting both good and bad endings allows both positive and negative Impact to be easily imagined and identified.
When imagining the future, to create a range of diverse possibilities, the Impacts on Flow, Value and Potential are used to encourage thinking from different perspectives.Interventions
How to assess the evolutionary potential in terms of studying, sharing, stabilising, sensing and searching.
The five arrows going into the left of the System are the potential Interventions that could be made. These Interventions provide a frame for appreciating the intent behind various practices, learning and discovering which ways of working are the right ones for the current situation, and transforming those practices as the system continuously evolves.
Working through the interventions encourages continuous curiosity about which tools and techniques to use, understanding when and why they are appropriate, and ultimately collaboratively, co-creating an initial kanban system as a baseline to begin experimenting and improving.
The interventions used are to Study the context, Share the understanding, Stabilise the work, Sense the capability and Search the alternatives.
"As the e-B3-threadComputing I need to call the GarbageCollector in order to improve my memory management performance with 30%"
WOW ! When I first read a story like that I thought : "Great , this is a product about robots and this user story is about E-VE falling in love with WALL-E". As Pixar created "Toy Story", Agile Software Development invented the T-Story ( as "Technical" , of course ) . Some time after meeting the first T-Story of my life I became confused.... Because there were many of them... in all software products, regardless of the company's business that develops that software.Now, that's interesting, how come all humans in the world need exclusively products about wall-E , E-Ve and their cousins? How that did happen?!
Refactoring the Mindset My little idea is that it happened because organisations and companies treated software developers as "translation automates" of "functional requirements" in programming languages. The outcome of this mindset is a target product that is about automates . And the first version of the product risks high to leave business people speechless on a puzzle question : "How the hell did they build such an absurd product "? Well, business people, they built a robotic product that highly make little sense from an user perspective because we might have treated developers as producers of "abstractions".If we want to build products that make sense for humans, there is one think to refactor : the "automate translation" mindset. And grow a software development culture that acknowledges that software products are stories about real people .
Software Products Are Stories About HumansThe "User" side of "User Story" is the key of a great software. Gojko Adzic says that un-experienced teams create T(ethnical) -stories instead of user stories. I think is more than experience , is a question of mind set. Just shift your mind from the T-Story to a real person next to you that experiences the service you're about to implement and think about how does that feel differently. The mind shift from technical layers and composants to small pieces of code that are meaningful from a user experience perspective is hard. Nevertheless , the only way to build shippable products at the end of each sprint is to stick to this rule : every user story is a new - enhanced- experience for the user. How to do that ? If you like methods, Gojko defined the Hamburger Method . It's my favorite. Beyond the "How to" , though, the secret of succeeding is the way we think about the software protect. Because it's not a collection of code, it tells a story where human users are heroes.This is why I strongly believe software developers are writers of stories co-created together with Product Owners, Business People and whoever needs to hang around. Agile people say teams are more performant when they are collocated. If this is true it is because the fireplace where products stories are told needs to stay vivid. The software code embeds a story. Would you like the story your code tell to be awesome ?
Put makeup on your own pig, make it look as good as you can. Don’t go around finding ugly imaginary pigs to stand it beside.
Warning: This article may contain sarcasm and ranting.
Do you have a good idea about how to express something that those guys said a decade and a half ago? Well, then, just say it. You could even set it in context. Here are two ways to do it. One of them is much better than the other in my opinion.Don’t do this
“Individuals and interactions over processes and tools.” That may have been all they knew way back last century, but today we know a hell of a lot more. The real idea is to make decisions about processes and tools at the right level. Often that level is well above the pay grade of the so-called “team”. (And so on.)Instead, do this
“Individuals and interactions over processes and tools.” Here’s one way I like to work with that Agile Manifesto value. We need many tools in the doing of our work. Wherever possible, I like to let each team select its own tools and process. There is a need for consistency in a few areas, but fewer than you might think. (And so on.)What’s going on?
The first approach tries to set you up as smarter than those other guys. You’re trying to set yourself off from others, by tearing them down. Tearing down the other person doesn’t make you taller: it makes you seem small. Maybe your idea is better. Maybe you are smarter. Let your idea show how smart you are. And why set up opposition for yourself. Some people value those old ideas. Do you really want to start by telling them they’re wrong?
The second approach builds on the good things in the past. Referring to the past that way lets you associate yourself with ideas people respect, and makes your ideas seem to fit in with what people already know and care about. You reduce resistance to what you’re saying, making it easier for people to hear you.Straw Man
I often tweet reminders about the straw man from time to time, referring to this picture, entitled “Idea looking comparatively good next to a straw man.
Keep your straw man. Just tell me what you think. There is no need to quote — or more likely misquote — someone else to make your idea look better to me.Exemplum Docet – or, A Rant Begins Here
OK, that said, I’m going to put down some straw men of my own, entirely made up examples no one really said. No one would say them, I’m sure. They’re just made up examples of what not to do, because I need to rant today.
I hate those guys who push Idea X. They’re just doing it for the money. I’m glad I took the high road.
Yeah, well, intercourse you and your penguin. The people who push IdeaX mostly believe in it at least as much as you believe in … in … what is it you believe in, actually? Are you just here to whine about those other unnamed people? Is the problem really that they’re just doing it for the money, or might it be something closer to home, like regret for your own past pathetic decisions? Get over the past. Tomorrow is a new day.
Are you really satisfied with your life? If so, tell me how you managed it. Or are you jealous of someone else’s life? Keep that to yourself.
Those guys had a good idea back at the beginning of the century but what they said should be updated to what we know now.
See previous advice regarding your aquatic flightless bird. Instead of whingeing about what somebody who isn’t you did years ago, why not come up with an idea or two of your own? And instead of using your critique of those people to launch your wondrous and doubtless fascinating advice, come up with a new name.
Tell me your idea. Maybe you can even find 13 other people to help you create your marvelous new idea. Get it out there. See if it can stand the test of time.
Some people think Stupid Idea A. I teach Smart Idea B. Hahaha on those other guys. I am smarter than they are.
Where are all these fish-reeking black and white flappy creatures coming from? It’s starting to bug me. No one with even minimal credibility ever supported Stupid Idea A. You twisted the words of ten smart and sincere people to create that ridiculous idea, which is held by exactly no people anywhere. You aren’t just trying to make yourself, and your idea look good, by any chance?
Just tell me your smart idea. No need to set it up by surrounding it with stupid ideas that your readers don’t believe anyway.TL;DR
Make your own lawn look good. Stop throwing trash onto mine.
Here’s the thing. Suppose you introduce a change X to your workplace, and then business improves noticably. That doesn’t mean X caused the business to improve. Well, MAYBE it did. Or perhaps business improved for other reasons, and X was actually detrimental, and business would have improved even more without it. So did things work out well because of the great X, or despite the lousy X? You’ll never know, unless you could rewind the clock and play out the same scenario without X. Correlation doesn’t imply causation.
So people like me who work with organizational change, we are in the business of pseudo-science. We get customer feedback and anecdotal evidence, but we can’t actually prove that we are doing any good, it’s just opinions and observations and guesswork. I think that’s fine, but let’s be honest about it
I don’t want to get on a rant here, but…In the Agile community and perhaps in the IT community in general there is a tendency to use the term “Continuous Improvement” to describe some sort of mythical state where teams are constantly evolving toward some state of perfection. At least that’s what I think of when I hear the term. Now I don’t know about you, but I don’t think I’ve ever seen such a creature in the wild (or even anything close to it). Furthermore, I’m concerned that using such terminology sets an unrealistic expectation for performance with our customers and stakeholders.
As an example, I’ll use myself. Right now, despite a host of good intentions on my part, I am not continuously improving. I’m typing – my spelling and grammar are showing no discernible sign of improvement (as I’m quite sure you, dear reader, are all too painfully aware of). Honestly, I’m just not improving right now. In fact, I haven’t done anything to improve my blog writing since the last time I wrote one a week ago…a month ago…6 months ago…
“But Tom don’t be so hard on yourself!” You say, “Just by writing more you are improving your writing skill and the content of the blog.” To this my answer would be, “So just writing more code is improving too?” We all know the answer to that question. So no, the only thing writing does by itself, is make the number of words on the page grow.
In fact, I have a confession to make. Nothing I plan to do in the next 24 hours has anything with improvement. Not even:
- Attending meetings (generally the opposite of improvement)
- Writing status reports (ditto)
- Cleaning the house (status quo – just fighting entropy is not improvement)
- Commuting (status quo)
- Watching TV (gently sliding toward entropic oblivion)
- Sleeping (mandatory, but not improvement, at best it’s re-establishing the status quo)
You see, true improvement is really hard work, therefore I don’t do it very often. I certainly have never been able to do it “continuously”. Hah! What a ridiculous notion that is! Nobody can improve continuously. We all need to take a break. Taking a break is actually necessary in order to improve! So the very term “continuous improvement” is at best misleading and at worst an idiotic notion. It can’t be done! Combining the terms continuous and improvement is like the old joke about the term military intelligence – it just doesn’t exist!
Up to this point I’ve just been ranting about continuous improvement, but in the Agile community we use the “continuous” word everywhere. There’s continuous integration, continuous delivery, and I’m sure there are a few more I haven’t even thought of. Take any one of those continuous activities and look at it closely enough, and guess what? Not much is happening. I’m willing to bet that your continuous integration server isn’t constantly running builds all the time (at least I hope not). I’m sure the average integration server spends a lot of time just waiting for the next build request. I hope by now it is pretty apparent that very few things are really continuous. I think we need a better term to describe these processes. I would propose: Periodic, Frequent, Event-driven or my personal favorite – on demand.
I know, I really do get it – continuous sounds just better. Continuous has an aspirational sort of quality to it which you can’t help but admire. I think that it’s just a little disingenuous to use that term for things that may not even take place for an hour or even a day at a time. If improvement is really continuous in nature, I want to see evidence of improvement taking place as I’m watching, when my back is turned, on weekends, and perhaps even when visiting the bathroom. Is that too high a bar to set? I don’t think so. I make that demand of my lowly alarm clock. I’m not saying improvement doesn’t take place. It happens – for some of us it happens pretty frequently. For others, it happens on demand at the end of the sprint.
Improvement may be a never-ending quest, but it is rarely, if ever, continuous.
Filed under: Agile, Scrum Tagged: Agile, Continuous Improvement, Process
You can get the Weekend Edition delivered directly to you via email by signing up http://eepurl.com/0ifWn.
The Weekend Edition is a list of some interesting links found on the web to catch up with over the weekend. It is generated automatically, so I can’t vouch for any particular link but I’ve found the results are generally interesting and useful.
The Scrum Checklist, For the Agile Scrum Master, Product Owner, Stakeholder and…
Scrum Shortcuts without Cutting Corners: Agile Tactics, … http://t.co/WbPQG1ZLAR
The Scrum Field Guide: Practical Advice for Your First Year (Agile So… http://t.co/m6anhQFzT3
Scrum Shortcuts without Cutting Corners: Agile Tactics, Tools, & Tips… http://t.co/7gdWe7hJYa
Scrum Shortcuts without Cutting Corners: Agile Tactics, Tools, … http://t.co/QbUIanWZeg
The Power of Scrum, In the Real World, For the Agile Scrum… http://t.co/VIq06iXrHL
Scrum, (Mega Pack), For the Agile Scrum Master, Product Ow… http://t.co/kkgUHslrsI
Scrum Essentials: Agile Software Development and Agile Pro… http://t.co/SUQg4YExVN
How to Become a Scrum Master in 7 Simple Steps (Agile Proj… http://t.co/mrzu1hoipr
The Scrum Checklist, For the Agile Scrum Master, Product O… http://t.co/DTo1bZJQZ5
Scrum Shortcuts without Cutting Corners: Agile Tactics, Tools, & Tips (Addison-W…
The Power of Scrum, In the Real World, For the Agile Scr… http://t.co/UPPYWasnYT
Scrum, (Mega Pack), For the Agile Scrum Master, Product … http://t.co/uDN3DOX6tM
Scrum Essentials: Agile Software Development and Agile P… http://t.co/eTRG5IMEgI
How to Become a Scrum Master in 7 Simple Steps (Agile Pr… http://t.co/5BFMA3sEMJ
The Scrum Checklist, For the Agile Scrum Master, Product… http://t.co/mpox08osyE
Scrum Shortcuts without Cutting Corners: Agile Tactics, To… http://t.co/Mk69h7axIf
Bacon & Eggs The chicken contributes, But the pig gives his all. I've never been a user of Scrum's Chicken/Pig metaphor. It's a metaphor used by many Scrum coaches and trainers to provide a brief, humorous reminder that the team needs to be free to self-organize in order to accomplish their activities in an efficient and sustainable way. Awesome goal.
Just to be clear where I'm coming from today:
- I get it. A Certified Scrum Master once suggested that I don't understand the metaphor, and offered to elaborate. [I'm actually a little flattered whenever my opinion is interpreted as ignorance.] I'm not expressing ignorance, today, so save your keystrokes.
- My feelings have not been hurt. [It's nice that folks worry about my feelings, too.] Someone once suggested that if I was uncomfortable with this metaphor, I should simply stop using it. [Commonly referred to as "blaming the victim."] I am expressing my opinion, of course, but I'm also conveying the feedback from dozens of behemoth corporations and popular little startups. [Heed my warnings, lest you be visited by three spirits...!]
- It's impolite: A few key people in almost every organization I've coached have expressed their discomfort with folks referring to themselves or other people as farm animals. To do so, even metaphorically, is often considered disrespectful, and unprofessional.
- It's inaccurate: Many people who may not be directly responsible for creation and delivery may still have a critical stake in the success of the team (i.e., "skin in the game"), e.g., the Product Owner. Generalizing the Scrum roles in this way (as a divisive caste system) discourages people from dealing with other people in a genuine way. A coach needs to be careful to avoid subtly encouraging blatant disrespect towards leadership, or subtle disrespect for the team. A coach should be encouraging respect and professionalism at all levels. We're usually there to repair the relationship between makers and leaders. The chicken/pig metaphor does little more (at best) than acknowledge the problem, and frequently (at worst) exacerbates existing bitterness.
- It's limited: To me, the metaphor only make sense with regard to the daily "scrum" or stand-up meeting, and (in some cases, or so I've heard) the retrospective. "Pigs Only! No chickens!" It could be interpreted as discouraging collaboration with leadership.
- It's old: It was Schwaber's clever metaphor about 20 years ago. Using it now would feel dogmatic, uncreative, and clumsy.
And if they all choose Scrum's Pigs and Chickens metaphor, so be it. It is, after all, their restaurant.
I read constantly, but I’ve not reported lately on what I’ve been reading. These are things I’ve read, enjoyed, found valuable. I’ll mention some tools and toys as well. I’ll leave out things I hated. Isn’t that nice of me?Non-Fiction
Drive: The Surprising Truth About What Motivates Us, by Daniel Pink, has inspired a chapter in The Nature of Software Development, coming soon. He tells us that people are motivated by Purpose, Autonomy, and Mastery. This rings very true to me, and I hope it does to you.
Creativity, Inc.: Overcoming the Unseen Forces That Stand in the Way of True Inspiration, by Ed Catmull, tells the story of Pixar and how they maintain creativity in the face of relentless schedules and being part of a big business. I hope never again to be part of a big business, but Catmull’s stories of leadership are inspiring.
Essentialism: The Disciplined Pursuit of Less by Ed McKeown, isn’t yet another book about simplifying your life. Well, it is, I suppose, but his approach to thinking about what really matters is valuable. I’m a sucker for thinking about myself, and if you are as well, you’ll find this book to be quite useful.
The Man Who Knew Too Much: Alan Turing and the Invention of the Computer (Great Discoveries), by David Leavitt, is a very interesting story of Turing, his contributions, and the tragic end he came to. Fortunately, that last bit is mercifully brief and the story is quite interesting. It includes quite a lot about math and code-breaking but you can safely skip over those bits if you find them too heavy. Good story of an important figure in our profession.
The Art Spirit, by Robert Henri, is a collection of writings about art. Henri holds that most anything we do well is art, and that art is the province of any human being. Very enjoyable.
Joy, Inc.: How We Built a Workplace People Love, by Richard Sheridan, is the story of his company, Menlo Associates, and the thinking behind it. Quite idealistic, quite practical. Sheridan has built a very successful company with a focus on Joy. Definitely something to learn here.Fiction
My fiction reading is all over the map. Science fiction, with forays into fantasy and steampunk. Adventure novels, spy novels. Once in a rare while, something like literature. Here’s a small sampling:
The Iron Wyrm Affair, by Lilith Saintcrow, takes place in what seems to be Victorian London in an alternate universe. Emma Bannon is a sorceress in service of the spirit Britannia (and her avatar Queen Victrix), while Archibald Clare, her sometime work partner, is a “mentath”, a master of logic and deduction who rivals the great Holmes. Sounds pretty fluffy but this story and the following ones are strong, a bit dark, and quite enjoyable if you like the steampunk kind of thing. Saintcrow’s novels often please me. These are my faves of hers.
Sniper’s Honor, by Stephen Hunter, is the ninth in his excellent series about Bob Lee Swagger, an aging retired sniper who gets into dangerous adventures, always involving snipers gone bad. The novels usually include a bit of history and are good spy/adventure stories.
Permutation City: A Novel, by Greg Egan, is a hard SF story of people who load their personalities into computers for fun, research, and, ultimately to survive the death of the solar system. I think Bill Tozier (@vaguery) put me onto this one, and I enjoyed it.
Another tip from Tozier was the Bel Dame Apocrypha series by Kameron Hurley, starting with God’s War: Bel Dame Apocrypha Volume 1. Is it set in some kind of a post-apocalyptic desert on Earth? On another planet? In a different universe? Fascinating, and it gets more so as the series goes along. Dark, and I think everyone dies — at least once.
I would be remiss if I didn’t point out the work of Iain M Banks, who recently passed away. His “Culture” series, beginning with Consider Phlebas, is charming, funny, and deep. Truly great hard SF. Worth it for the names of the intelligent ships alone. Very highly recommended.Tools and Toys
I guess I might as well show you some of the toys I’ve recently bought, for fun or profit. You may know that I’m trying to learn to draw, and my theory is that as soon as I get the right equipment, I’ll be able to do it.
I have a fine Derwent pencil wrap for my ten thousand pencils, which come in all colors, textures, and permanence. This Derwent Canvas Carry-All Bag has room for those, my many erasers, and even a sketch book. And I can slip the iPad into it for those days when I can’t just be purely analog. The first one came without the included shoulder strap and Amazon sent me a new one by next day shipping.
Laura Fisher, my webmistress (not as interesting as it sounds) told me about these Staedtler Watercolor Pencils. Since when I draw with Paper(tm), I often use the watercolor brush to color things, I thought I’d try these. You shade as you would with a pencil, then dab on a little water with a brush, and voila. Lots of fun and messy too.
I also have an Parrot AR.Drone 2.0 Quadricopter, which is lots of fun. Parrot’s upcoming Bebop comes with a joystick controller, longer range etc etc. I thought it would be good to practice with joysticks, so I bought Syma X1, the little guy above, as well. So far, I am incredibly good at crashing it.
It’s long over-do, but I finally wrote up my 10 Big Ideas from the 7 Habits of Highly Effective People.
What can I say … the book is a classic.
I remember when my Dad first recommended that I read The 7 Habits of Highly Effective People long ago. In his experience, while Tony Robbins was more focused on Personality Ethic, Stephen Covey at the time was more focused on Character Ethic. At the end of the day, they are both complimentary, and one without the other is a failed strategy.
While writing 10 Big Ideas from the 7 Habits of Highly Effective People, I was a little torn on what to keep in and what to leave out. The book is jam packed with insights, powerful patterns, and proven practices for personal change. I remembered reading about the Law of the Harvest, where you reap what you sow. I remembered reading about how to think Win/Win, and how that helps you change the game from a scarcity mentality to a mindset of abundance. I remembered reading about how we can move up the stack in terms of time management if we focus less on To Dos and more on relationships and results. I remembered reading about how if we want to be heard, we need to first seek to understand.
The 7 Habits of Highly Effective People is probably one of the most profound books on the planet when it comes to personal change and empowerment.
It’s full of mental models and big ideas.
What I really like about Covey’s approach is that he bridged work and life. Rather than splinter our lives, Covey found a way to integrate our lives more holistically, to combine our personal and professional lives through principles that empower us, and help us lead a more balanced life.
Here is a summary list of 10 Big Ideas from the 7 Habits of Highly Effective People:
- The Seven Habits Habits of Effectiveness.
- The Four Quadrants of Time Management.
- Character Ethic vs. Personality Ethic
- Increase the Gap Between Stimulus and Response.
- All Things are Created Twice.
- The Five Dimensions of Win/Win.
- Expand Your Circle of Influence.
- Principle-Centered Living.
- Four Generations of Time Management.
- Make Meaningful Deposits in the Emotional Bank Account.
In my post, I’ve summarized each one and provided one of my favorite highlights from the book that brings each idea to life.
Great metaphor! Scaling Agile – a perfect method.Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to informationPlease share!
A Minimum Credible Release, or MCR, is simply the minimal set of user stories that need to be implemented in order for the product increment to be worth releasing.
I don’t know exactly when Minimum Credible Release became an established practice, but I do know that we were using Minimum Credible Release as a concept back in the early 2000’s on the Microsoft patterns & practices team. It’s how we defined the minimum scope for our project releases.
The value of the Minimum Credible Release is that it provides a baseline for the team to focus on so they can ship. It’s a metaphorical “finish line.” This is especially important when the team gets into the thick of things, and you start to face scope creep.
The Minimum Credible Release is also a powerful tool when it comes to communicating to stakeholders what to expect. If you want people to invest, they need to know what to expect in terms of the minimum bar that they will get for their investment.
The Minimum Credible Release is also the hallmark of great user experience in action. It takes great judgment to define a compelling minimal release.
A sample is worth a thousand words, so here is a visual way to think about this.
Let’s say you had a pile of prioritized user stories, like this:
You would establish a cut line for your minimum release:
Note that this is an over-simplified example to keep the focus on the idea of a list of user stories with a cut line.
And the art part is in where and how you draw the line for the release.
While you would think this is such a simple, obvious, and high-value practice, not everybody does it.
All too often there are projects that run for a period of time without a defined Minimum Credible Release. They often turn into never-ending projects or somebody’s bitter disappointment. If you get agreement with users about what the Minimum Credible Release will be, you have a much better chance of making your users happy. This goes for stakeholders, too.
There is another concept that, while related, I don’t think it’s the same thing.
It’s Minimum Viable Product, or MVP.
Here is what Eric Ries, author of The Lean Startup, says about the Minimum Viable Product:
“The idea of minimum viable product is useful because you can basically say: our vision is to build a product that solves this core problem for customers and we think that for the people who are early adopters for this kind of solution, they will be the most forgiving. And they will fill in their minds the features that aren’t quite there if we give them the core, tent-pole features that point the direction of where we’re trying to go.
So, the minimum viable product is that product which has just those features (and no more) that allows you to ship a product that resonates with early adopters; some of whom will pay you money or give you feedback.”
And, here is what Josh Kaufman, author of The Personal MBA, has to say about the Minimum Viable Product:
“The Lean Startup provides many strategies for validating the worth of a business idea. One core strategy is to develop a minimum viable product – the smallest offer you can create that someone will actually buy, then offer it to real customers. If they buy, you’re in good shape. If your original idea doesn’t work, you simply ‘pivot’ and try another idea.”
So if you want happier users, better products, reduced risk, and more reliable releases, look to Minimum Credible Releases and Minimum Viable Products.You Might Also Like
Wir werden immer wieder gefragt, wie man sinnvoll skaliert, also mit mehr als einem Team arbeitet. Soll man da gleich elektronische Taskboards nutzen, braucht es einen Chief Product Owner und vieles mehr. Hier zehn kleine Tipps – sie können euch dabei helfen, erfolgreicher mit vielen Teams zu arbeiten.
- Synchronisiert die Sprints. Wenn Teams zusammenarbeiten müssen, also voneinander abhängig sind, dann hat es sich bewährt, die Sprints zu synchronisieren. Teams, die nichts miteinander zu tun haben, brauchen bei dieser Synchronisation nicht mitzumachen.
- Infrastruktur. Wichtiger als alle Prozesse ist die entsprechende Infrastruktur. Zum Beispiel müsst ihr in der Lage sein, ständig zu integrieren. Stichwort “Continuous Delivery”. Wenn ihr diese Infrastruktur noch nicht habt, dann wird das Ende des Sprints oder der Kadenz zum Integrationszeitpunkt. Mindestens einmal im Sprint muss alles zusammenlaufen.
- Defects First. Immer zuerst alle Defects lösen und wieder integrieren. Erst an neuen Features arbeiten, wenn die Defects gelöst sind. Am besten täglich dafür sorgen, dass Fehler behoben werden.
- Dann kümmert man sich um die Integrations-Themen – hier liegt die Stärke des Scrum of Scrums. Identifiziert täglich, wo es Probleme beim Zusammenbringen der Applikation gibt. Gebt euch nicht damit zufrieden, dass es möglicherweise später schon funktionieren wird. Löst jedes dieser Probleme sofort. Erst dann macht man weiter.
- Infrastruktur vor Features. Davon abgesehen, dass jedes Team immer ein neues Feature, eine neue User Story pro Sprint liefern sollte – entwickelt eure Instrastruktur zuerst weiter. Ständig. Updates der Server, der Test-Systeme, neue Interfaces nutzen, immer zuerst.
- Erst dann werden neue Funktionalitäten entwickelt. Also etwas Neues wird immer erst dann wieder in die Applikation eingebaut, wenn sie wirklich funktioniert und alle Bedingungen bereit sind.
- Visualisiert die Arbeit der Product Owner. Sie müssen sich auch einmal als Product Owner-Team vor einem Taskboard treffen und ihre Arbeit auf diese Weise transparent machen.
- Der Chief Product Owner entscheidet nur selten über die Reihenfolge: Seine Aufgabe ist es dafür zu sorgen, dass er die besten Product Owner in seinem Team hat. Er sorgt dafür, dass jeder ein Backlog hat, das zum Gesamtprodukt passt. Er identifiziert die notwendigen Skills und arbeitet ständig mit seinem Product Owner-Team daran, dass es immer möglichst viel Wert liefert.
- Entwickelt mit den Architekten oder Lead-Entwicklern ein Konzept, so dass die unterschiedlichen Teams möglichst entkoppelt voneinander arbeiten können. Die Architektur sollte vorgeben, wie zusammengearbeitet werden kann. Nicht umgekehrt.
- Delegation der Verantwortung dorthin wo die Information ist. Arbeitet hart daran, dass die Teams selbst Entscheidungen treffen und sie treffen können. Oft fehlt es tatsächlich an den entsprechenden Kenntnissen. Entwickelt erst die Kenntnisse und dann kommt die Selbstorganisation von selbst.
Diese Tipps haben uns in den letzten Jahren geholfen, in großen Teams erfolgreich zu sein. Sie dienen uns als Anhaltspunkt, worauf wir achten müssen. Lösen können die Regeln für sich allein nichts.
Wer mehr über große verteilte Teams wissen will – wir bieten dazu ein Training an: Scrum International bringt viele neue Ideen und Arbeitsweisen.
The Alternative Burndown Graph is one of the more useful Agile graphs. It’s especially useful for communicating outside of the team, with stakeholders, senior management, etc. This is because it’s can be used to show three important pieces of information; 1. how the team is progressing, 2. changes to the baseline of the Product Backlog, and 3. can be used to determine a completion date. It is a graph that’s generated at the start of every Sprint and shows how work is being completed Sprint over Sprint.
Here’s what the Alternative Burndown Graph looks like.
I’m frequently asked if I have a version of the graph that I can share, so I created a Google spreadsheet to generate a simple and useful version of the graph. You can get a copy of my Google Spreadsheet here.Understanding the Alternative Burndown Graph
The Alternative Burndown Graph is started by adding up the total amount of work remaining in the Product Backlog , and plotting this initial value. There after, any work completed by the team is taken from the top of the graph. By drawing a trend line through the tops of the graph we can show how the team is making progress Sprint over Sprint.
But what about work being added to the Product Backlog? With this style of graph, any work added to the Product Backlog is added to the bottom of the graph. And, by drawing a trend line through the bottoms of the graph we can show how the baseline of the Product Backlog has been changing Sprint over Sprint.
Finally, we can then use all this information to help calculate when we think the team will have completed the work in the Product Backlog. The intersection of the two trend lines is where the Product Backlog will give us the most likely time of completion of this Backlog.Creating the Graph in Google Spreadsheets
It’s a very easy graph to generate with any simple spreadsheet application, but I’m frequently asked if I have a sample version of the graph that I can share. So, here’s a version as a Google spreadsheet.
The spreadsheet contains two tabs. The first tab contains the data necessary for the graph, and the second tab contains the graph. The graph is generated using the data in the rows titled Series A and Series B.
To start using this graph,
- Make a copy of the Google Spreadsheet
- Enter the total of the teams estimates in the product backlog into the first column of Series A.
- There after all you need to record is the total number of the teams estimates completed at the end of each Sprint, and
- The total number of the teams estimates added to the Product Backlog (by the Product Owner) during the sprint.
So, there you have it. A nice simple Alternative Burndown. Let me know if you find this useful.
 Teams will seldom calculate the total amount of work for the entire Product Backlog … because this might be a large amount of work especially for very large Product Backlogs. It is more likely that the Product Owner and team will select some subset of the Product Backlog (say the top 20%, or perhaps sufficient work for the next release) and use then generate this graph for that subset.
 That fact that we need to ‘add up the total amount for work remaining the the backlog’ is often interpreted as an implication that we need a numerical scale. This is not so; we can easily use an abstract scale although it’s something most people are uncomfortable with. To make it easy to generate this graph many teams will adopt a numerical sequence, but its important to remember that it doesn’t matter what scale you use, provided that you’re consistent.
So you’re trying to do Scrum well because you heard it gave you great results. You know that the ScrumMaster role is critical. How do you find the right people to fill that role? Here is a list of several roles that people commonly leave to become ScrumMasters, and a few not-so-common roles as well, all ranked by how well those people typically do once they become ScrumMasters. From Worst to Best:
- Worst: PMI-trained Project Managers (PMPs). Too focused on control and cost and schedule. Not easily able to give teams the space to self-organize. Not able to detach themselves from results and focus on the process, values and teamwork needed to make Scrum successful.
- Bad, but not awful: Functional Managers. The power dynamic can be a serious hindrance to allowing teams to self-organize. But, good functional managers already are good at building teams, and empowering individuals to solve problems.
- Bad, but not awful: Technical Leads. Here, the biggest problem is the desire to solve all the team’s technical problems instead of letting them do it. Now, instead of detachment from results (project managers), it’s detachment from solutions.
- So-so: Quality Assurance people. Good at rooting out root-cause for problems… just need to shift from technical mindset or business mindset to cultural and process mindset. Another problem is that QA is not nearly as respected as it should be and QA people typically don’t have a lot of organizational influence.
- So-so: Junior techies: Enthusiasm can make up for a lot of gaps and naiveté can help solve problems in creative ways, but there will be a huge uphill battle in terms of respect and influence in an organization.
- Good: non-PMI-trained Project Managers: rely on teamwork and influence rather than tools, processes and control (of course there are exceptions).
- Awesome: Executive Assistants. Respected and respectful, use influence for everything, know everyone, know all the processes, know all the ways to “just get it done”. Of course, they don’t usually know much about technology, but that often turns out to be good: they don’t make assumptions, and are humble about helping the technical team!
The ScrumMaster creates high performance teams using the Scrum process and values. The ScrumMaster is not accountable for business results, nor project success, nor technical solutions, nor even audit process compliance. The ScrumMaster is responsible for removing obstacles to a team’s performance of their work. The ScrumMaster is an organizational change agent.
Other things you might want to consider when looking for a ScrumMaster:
- Does the person have experience managing volunteer groups?
- Does the person have good people skills in general?
- Does the person want to create high-performance teams?
- Can the person learn anything – business, process, technical, people, etc.?
Bottom line: try and avoid having PMI-trained project managers become ScrumMasters. Even with good training, even with time to adjust, I often find that Scrum teams with PMI-trained project managers are always struggling and almost never become true teams.Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to informationPlease share!
Everyone Shovels Poop
It doesn’t matter who you are, what you do, or where you work.
I’m here at the end of yet another 3 day weekend with my kids. Last week, my son was at home in between day care and school. This week, it’s Labor Day in the U.S. and school is closed. And it’s days like this, weeks where I lose multiple days, that I miss the regularity of a “normal” job.The Grass Really Isn’t Greener
I sulk at lost time for projects and clients, at my inability to be productive today when today is a part of my weekly plan to get things done. I long for a job where I leave the work at work, and don’t worry about it again until I get back to the office.
But that green pasture I remember and look fondly upon, is only a sales pitch in my faulty memory.It Takes A Little BS …
The truth is, there is no green pasture over there. Nor is there a green pasture here where I am now. In fact, the only green in any pasture that you will come across in your career, is the one where the right amount of crap mixes with the right amount of blue skies, sunshine, rain and wind.
The truth is, it takes all kinds of weather – good and bad – for a pasture to grow green enough that it will be of value for a while. But that value has a limit and it gets used up, so the process starts again.
It’s during the rainy season and the following dry season that we have to do the hard work. This work, shoveling the BS and spreading it around the now dry wasteland of pasture, is what allows the pasture to be green again in the next cycle.How Much Of What Kind Are You Willing To Live With?
You will always face a fair amount of crap in your job – whether you work for someone else or for yourself.
The secret to being happy at your job, then, is not to look at another job, hoping for a greener pasture. That green is temporary. The secret is to recognize the cycles of fertilization, growth and harvest.
Don’t try to find a job without BS – that will never happen. Find a job where the crap you have to shovel is the kind you know you can live with; where the green pasture that comes around once every cycle of seasons makes the hard work and stench worth it.… To A Point
It’s true, you will have to deal with hard work and BS at times. But there’s also a time when you may legitimately be drowning in feces at any given job. You need to understand how much of this “fertilizer” you’re willing to live with, and what kind of fertilizer it is you can live with. Don’t let yourself be swallowed up, but don’t turn and run at the first sign of work, either.
– DerickRelated Stories
There are lots of frameworks and suggestions these days for how to scale Agile to the enterprise. They all miss the point, because the proponents of these methods use the wrong definition for scaling. I have a perfect method for scaling Agile. To describe it I’ll use a fish metaphor. A fishmonger scales fish in just the same way we should be scaling Agile. I actually call this method Scaling and Filleting Agile, or SaFA for short (pronounced “safer”).
SaFA begins with the (quite reasonable) assumption that if you are an enterprise attempting to “do Agile” then you have likely accumulated a lot of crap: expensive tracking tools, various flavors of consultant, painful, pointless meetings, new roles that look exactly like the old roles but with different names, and no shortage of charts, graphs, burnups, burndowns… and burnout.
The fish is your enterprise. Looks good from the outside, but unstomachable within. So start scaling. Remove the veneer of Agile with all its phony buzz words, its bright, shiny corporate artifacts. Then take out the choking hazards, the bottlenecks to actual productivity, the organizational impediments to true engagement, the small annoyances that make people vomit. Finally, remove the guts and gore that represent all the rest of the waste, the remnants of a life you are no longer to be bound to.
Congratulations. The value of your enterprise fish has risen in the market, and now you have something to plan a recipe around.
Kürzlich durfte ich mit einem Team zusammenarbeiten, das Treiber entwickelt und ein großes Problem hatte: Es konnte seine Sprint-Commitments nie einhalten. Nach zwei Monaten war das Team so weit, dass es nicht mehr Scrum machen wollte. Das Framework passe einfach nicht zu ihnen, sagten sie.
Ich setzte mich mit dem Team zusammen und wir begannen, den Prozess, so wie er aktuell ist, aufzuzeichnen. Üblicherweise können Commitments dann nicht eingehalten werden, wenn das Team im Laufe des Sprints viele ungeplante Aufgaben (Support, Change Requests) zu bewältigen hat. Das war aber hier nicht der Fall – der Anteil ungeplanter Aufgaben war mit jenem anderer Teams vergleichbar. Das eigentliche Problem war die Anzahl an Backlog Items, die gleichzeitig in Bearbeitung waren. Je mehr Treiber das Team parallel entwickelte, desto länger wurde die Fertigstellungszeit. Warum aber nahm das Team so viele Treiber gleichzeitig in Bearbeitung? Um der Sache auf den Grund zu gehen, setzten wir Artefakte auf, die den Arbeitsfluss verdeutlichen sollten:
- Das Taskboard: Anstelle der klassischen Dreiteilung (Open/In Progress/Done) fingen wir an, den Workflow der Treiber-Entwicklung darzustellen. Es gab also pro Arbeitschritt eine eigene Spalte. Außerdem begrenzten wir die Zeilen am Taskboard, so dass maximal fünf Treiber gleichzeitig in Bearbeitung genommen werden konnten.
- Das Cumulative Flow Diagram: Hier wird jede Woche gezählt, wie viele Aufgaben sich in welcher Spalte auf dem Taskboard befinden. So entsteht für jede Spalte eine eigene Kurve, die wöchentlich fortgeschrieben wird. Dadurch lässt sich ablesen, ob sich der Arbeitsprozess im Fluss befindet. In unserem Fall hatten wir mit einer flachen “Done-Kurve” zu tun (denn die Anzahl an fertig gestellten erhöhte sich nicht) während z.B. die “Waiting for Test”-Spalte steil anstieg, weil neue Treiber auf den Integrationstest warteten. Dadurch konnten wir sehen, wo die Engpässe im System sind – und was wir verändern müssen, um wieder einen Fluss zu erzeugen. Zudem lassen sich am Cumulative Flow Diagram Lead Time und Work in Progress ablesen (siehe nächster Punkt).
- WIP und Lead Time: Wir einigten uns auf zwei KPIs (Key Performance Indicators). WIP (Work in Progress): Das ist die Anzahl an Treibern, die sich gleichzeitig in Bearbeitung befinden. Die Obergrenze hierfür haben wir auf fünf festgelegt und das Taskboard als quasi physikalische Grenze entsprechend aufgebaut. Lead Time: Das ist die Zeit, die zwischen Aufnahme eines neuen Treibers in die Entwicklung und dem Release vergeht. Hier fingen wir an, jedem Backlog Item auf dem Taskboard zwei Zeitstempel zu geben – “IN” und “OUT”. Je länger die Lead Time, desto unproduktiver ist das Team.
- Release-Burndown-Chart: Der Product Owner hatte für das Jahr mit 13 neuen Treibern (darunter Neuentwicklung und Updates) geplant. Mit dem Burndown-Chart konnten wir die tatsächlich fertig gestellten Treiber visualisieren – und anhand des Kurvenverlaufs erkennen, ob mit der aktuellen Lead Time das Ziel noch realistisch ist.
Vor Veränderung kommt immer die Transparenz. Gerade als erfahrener agile Practitioner sollte man von schnellen Ratschlägen Abstand nehmen. Erst wenn tatsächlich verstanden wurde, wie das Team aktuell arbeitet, können Hebel für Veränderungen identifiziert werden. In diesem Fall wurde klar, dass das Team mit langen Wartezeiten konfrontiert war, da es für die Erstellung von Skripten sowie für die Verifikation und Validation auf Unterstützung von anderen Teams angewiesen war. Das Team füllte diese Wartezeiten, indem es in der Zwischenzeit mit etwas Neuem anfing. Wir kennen das Phänomen, wenn wir zu viele Downloads gleichzeitig starten – am Ende dauert alles viel länger. Deshalb konnte das Team keine Commitments einhalten. In der Außenwahrnehmung wurde das Teams als unzuverlässig gesehen – in Wirklichkeit machte es zu viel gleichzeitig.
Um das Vertrauen in die Planbarkeit zurückzugewinnen, fing das Team mit wöchentlichen Forecasts an. Am Montag stellten sich alle vor das Taskboard und beschlossen gemeinsam, was sie bis Freitag erreicht haben wollten. Das Taskboard, wie es dann am Freitag aussehen sollte, wurde aufgezeichnet und zum Vergleich neben das aktuelle Taskboard gehängt. Das funktionierte gut.
Product Owner und Management erhielten über den Release-Burndown und die Lead Time zwei ehrliche Indikatoren darüber, was tatsächlich geschafft werden kann. Somit hatten sie zum ersten Mal eine verlässliche Planungsgrundlage. Und der ScrumMaster konnte die Impediments beim Namen nennen, die der Produktivität im Wege standen. Mittelfristig wurden diese über eine engere Zusammenarbeit mit den anderen Teams (tägliches SoS) gelöst, so dass Abhängigkeiten sofort adressiert werden konnten und durch bessere Synchronisation Wartezeiten erst gar nicht entstehen. Langfristig geht es darum, dass das Team immer mehr selber in die Hand nehmen kann (etwa beim Testen) und so schneller wird.
- Das Daily Scrum – ein How-To für das kürzeste Scrum Meeting
- Scrum Tools | tinypm | Review
- Das Burndown-Chart – 10 Gründe dafür