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
In the last year or so, we’ve certified an increasing number of SPCs who work in enterprises building really big systems —hi-res image capture satellites, computer servers, aviation electronics and more. In addition, SAFe was developed, in part, in the context of Nokia feature phones (the surviving part that was sold to Microsoft), John Deere (computer controls and embedded software for combines, tractors and sprayers) Nokia Siemens Networks (who executed a most spectacular business turn around), so systems thinking is not new to SAFe.
However, SAFe is optimized for big software, not systems, and while SAFe can be applied easily that way, building a big new banking application that crosses fifty extant applications, and building and evolving large scale embedded systems begs for different words, objects and thinking.
To this end, we’ve expanded the team with the addition of systems expert Harry Koehnemann of the 321 Gang, and we are developing a new variant of SAFe, SAFe for Lean Systems Engineering. We should have a public announcement of a preview in the next few months, with a goal of a MVP release sometime in 2015.The Purpose of this Post
As we’ve been formulating and structuring content, we’ve been asking ourselves the question, what is Lean Systems Engineering? What do we stand for? What are the values, principles and practices that it entails?
To that end, we offer the following Manifesto for SAFe Lean Systems Engineering, and we are publishing it here to open up for broader industry comments.
For those for whom this topic is of interest, feel free to review and comment here. Just as we’ve developed SAFe iteratively and in full public view, we’ll do the same with SAFe LSE, so consider this the beginning, not the end of an important dialogue.============================================================ Manifesto for SAFe Lean Systems Engineering
Lean systems engineering is a discipline whereby empowered systems developers work in cross-functional teams building systems that benefit customers and users. Fed by constant customer collaboration, led by lean thinking manager-teachers, we:
- Understand the economics of the value chain
- Develop systems iteratively and incrementally
- Integrate frequently; adapt immediately
- Manage risk, efficacy and predictability with model- and set-based engineering
- Embrace agile development values and practices
- Decentralize decision-making, synchronize via cross-domain collaboration and planning
- Limit work in process. Reduce batch sizes. Manage queue lengths.
- Base milestones on objective evaluation of working systems
We commit to building better systems and to continuously improving and disseminating our methods and practices
I found myself needing to run a debugger on my Jasmine specs. The really fun part is that I am running these specs through the grunt-jasmine-node plugin for grunt. This means what I really need to do is run a debugger on top of grunt, and have it hit my Jasmine specs when they get around to being executed.
It turns out I can do this through a rather simple, one liner in a bash shell (or command prompt on Windows) and I instantly have access to the built in nodejs debugger when running code from any grunt command! But to get there, I had to follow a few steps down an interesting path and learn how to hijack grunt’s script execution.
Hijacking Grunt Execution
The first step in the solution is to hijack the execution of grunt so that you are running it w/ a call to NodeJS directly, instead of just using the Grunt command line tool. To do that, you need to know what the Grunt command line tool is. On OSX and Linux, you can get the “grunt” file location by running:
As you can see, the grunt command line is located at /user/local/bin/grunt on my box. A quick “cat” of that shows that this is a shell script with a shebang (hash-bang) to tell the shell how to execute the file as a nodejs script.
Now that I know this is a NodeJS script, I have options. I could modify the file to run a different shell command, but that’s a bad idea. Any updates or re-installs would requite me to change that file again. No thanks. The other option I have is just calling the “node” command line myself and telling node to run this script.
I’m now running the “grunt” script directly with node, instead of letting the shell figure out how to run it.Using “which” To Simplify Execution
Again, in OSX and Linux I can use the “which” command line to make this even easier. Rather than having to remember where the grunt command is when I want to run it from node directly, I can use the $( … ) call. This call executes a child script and interpolates the output in to the parent command. At the same time, I’m going to add the “debug” call to the node command line.
When I run this, it gets expanded in to the same direct command line call as above (with the addition of “debug” of course). Only now, I don’t have to remember the path to the “grunt” command line tool. (Sadly, I don’t know how to get this effect on Windows. You might have to hard code the location of the grunt script for that OS.)Making It A Bash Script
As short as the above script is, I don’t want to type it all out every time I want to debug code run from grunt. So I stuffed that one liner in to a bash script with it’s own shebang (hash bang) telling it to use bash to run this script.
Now that I have this in it’s own script, I need to be able to pass command line parameters in to the real command calls. On OSX and Linux, that can be done with the inclusion of “$@” – meaning “all command line parameters”, or “$1″, “$2″, “$..n” (where “n” is the parameter position number). On Windows, the same can be done with “%*” to get all params, or “%1″, “%2″, “%3″ … “%..n” (thanks to Alexander Gross in the comments, for the “%*” tip).
The resulting script on my OSX box looks like this:Running The Debugger On Jasmine-Node
I now have a “grunt-debug” file in my project folder. When I need to debug my grunt-jasmine-node tests now, I just run this:
My break points hit and I can debug in to the code (including my grunt-jasmine-node specs) with the built in NodeJS debugger!
Product Owner Training – New AgendA
Upcoming Learning Events
Other Information and Links
Please feel free to subscribe to the Real Agility Newsletter to gain access to archives and receive future issues.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!
Following on from my last blog post about deriving Gherkin from conversations, I wanted to share some tips on tenses. This is beginner stuff, but it turns out there are a lot of beginners out there! It also isn’t gospel, so if you’re doing something different, it’s probably OK.Contexts have happened in the past
When I phrase a context, I often put it in the past tense:
Given Fred bought a microwave
Sometimes the past has set up something which is ongoing in the present, but it’s not an action as much as a continuation. So we’ll either use the present continuous tense (“is X-ing”) or we’ll be describing an ongoing state:
Given Bertha is reading Moby Dick
Given Fluffy is 1 1/2 months old
It doesn’t matter how the context was set up, either, so often we find that contexts use the passive voice for the events which made them occur (often “was X-ed” or “has been X-ed”, for whatever the past tense of “X” is):
Given Pat’s holiday has been approved
Given the last bar of chocolate was soldEvents happen in the present
The event is the thing which causes the outcome:
When I go to the checkout
When Bob adds the gig to his calendar
I sometimes see people phrase events in the passive voice:
When the last book is sold
but for events, I much prefer to change it so that it’s active:
When we sell the last book
When a customer buys the last book
This helps to differentiate it from the contexts, and makes us think a bit harder about who or what triggers the outcome.Outcomes should happen
I tend to use the word “should” with outcomes these days. As well as allowing for questioning and uncertainty, it differentiates the outcome from contexts and events, which might otherwise have the same syntax and be hard to automate in some frameworks as a result (JBehave, for instance, didn’t actually care whether you used Given, When or Then at the beginning of a step; it just told it there was a step to run).
Then the book should be listed as out of stock
Then we should be told that Fluffy is too young
I often use the passive voice here as well, since in most cases it’s the system producing the outcome, unless it’s pixies.
And that’s it!
Continuous Value Delivery helps businesses realize the benefits from their technology investments in a continuous fashion.
Businesses these days expect at least quarterly results from their technology investments. The beauty is, with Continuous Value Delivery they can get it, too.
Continuous Value Delivery is a practice that makes delivering user value and business value a rapid, reliable, and repeatable process. It’s a natural evolution from Continuous Integration and Continuous Delivery. Continuous Value Delivery simply adds a focus on Value Realization, which addresses planning for value, driving adoption, and measuring results.
But let’s take a look at the evolution of software practices that have made it possible to provide Continuous Value Delivery in our Cloud-first, mobile-first world.
Long before there was Continuous Value Delivery, there was Continuous Integration …Continuous Integration
Continuous Integration is a software development practice where team members integrate their work frequently. The goal of Continuous Integration is to reduce and prevent integration problems. In Continuous Integration, each integration is verified against tests.
Then, along came, Continuous Delivery …Continuous Delivery
Continuous Delivery extended the idea of Continuous Integration to automate and improve the process of software delivery. With Continuous Delivery, software checked in on the mainline is always ready for release. When you combine automated testing, Continuous Integration, and Continuous Delivery, it's possible to push out updates, fixes, and new releases to customers with lower risk and minimal manual overhead.
Continuous Delivery changes the model from a big bang approach, where software is shipped at the end of a long project cycle, to where software can be iteratively and incrementally shipped along the way.
This set the stage for Continuous Value Delivery …Continuous Value Delivery
Continuous Value Delivery puts a focus on Value Realization as a first-class citizen.
To be able to ship value on a continuous basis, you need to have a simple way to have a simple mechanism for units of value. Scenarios and stories are an effective way to chunk and carve up value into useful increments. Scenario and stories also help with driving adoption.
For Continuous Value Delivery, you also need a way to "pull" value, as well as "push" value. Kanbans provide an easy way to visualize the flow of value, and support a “pull” mechanism and reinforce “the voice of the customer.” User stories provide an easy way to create a backlog or catalog of potential value, that you can “push” based on priorities and user demand.
Businesses that are making the most of their technology investments are linking scenarios, backlogs, and Kanbans to their value chains and their value streams.Value Planning Enables Continuous Value Delivery
If you want to drive continuous value to the business, then you need to plan for it. As part of value planning, you need to identify key stakeholders in the business. With the stakeholders you need to identify the business benefits that they care about, along with the KPIs and value measures that they care about.
At this stage, you also want to identify who in the business will be responsible for collecting the data and reporting the value.Adoption is the Key to Value Realization
Adoption is the key component of Continuous Value Delivery. After all, if you release new features, but nobody uses them, then the users won't get the new benefits. In order to realize the value, users need to use the new features and actually change their behaviors.
So while deployment was the old bottleneck, adoption is the new bottleneck.
Users and the business can only absorb so much value at once. In order to flow more value, you need to reduce friction around adoption, and drive consumption of technology. You can do this through effective adoption planning, user readiness, communication plans, and measurement.Value Measurement and Reporting
To close the loop, you want the business to acknowledge the delivery of value. That’s where measurement and reporting come in.
From a measurement standpoint, you can use adoption and usage metrics to better understand what's being used and how much. But that’s only part of the story.
To connect the dots back to the business impact, you need to measure changes in behavior, such as what people have stopped doing, started doing, and continue doing. This will be an indicator of benefits being realized.
Ultimately, to show the most value to the business, you need to move the benefits up the stack. At the lowest level, you can observe the benefits, by simply observing the changes in behavior. If you can observe the benefits, then you should be able to measure the benefits. And if you can measure the benefits, then you should be able to quantify the benefits. And if you can quantify the benefits, then you should be able to associate some sort of financial amount that shows how things are being done better, faster, or cheaper.
The value reporting exercise should help inform and adjust any value planning efforts. For example, if adoption is proving to be the bottleneck, now you can drill into where exactly the bottleneck is occurring and you can refocus efforts more effectively.Plan, Do, Check, Act
In essence, your value realization loop is really a cycle of plan, do, check, act, where value is made explicit, and it is regarded as a first-class citizen throughout the process of Continuous Value Delivery.
That’s a way better approach than building solutions and hoping that value will come or that you’ll stumble your way into business impact.
As history shows, too many projects try to luck their way into value, and it’s far better to design for it.Value Sprints
A Sprint is simply a unit of development in Scrum. The idea is to provide a working increment of the solution at the end of the Sprint, that is potentially shippable.
It’s a “timeboxed” effort. This helps reduce risk as well as support a loop of continuous learning. For example, a team might work in 1 week, 2 week or 1 month sprints. At the end of the Sprint, you can review the progress, and make any necessary adjustments to improve for the next Sprint.
In the business arena, we can think in terms of Value Sprints, where we don’t want to stop at just shipping a chunk of value.
Just shipping or deploying software and solutions does not lead to adoption.
And that’s how software and IT projects fall down.
With a Value Sprint, we want to do a add a few specific things to the mix to ensure appropriate Value Realization and true benefits delivery. Specifically, we want to integrate Value Planning right up front, and as part of each Sprint. Most importantly, we want to plan and drive adoption, as part of the Value Sprint.
If we can accelerate adoption, then we can accelerate time to value.
And, of course, we want to report on the value as part of the Value Sprint.
In practice, our field tells us that Value Sprints of 6-8 weeks tend to work well with the business. Obviously, the right answer depends on your context, but it helps to know what others have been doing. The length of the loop depends on the business cadence, as well as how well adoption can be driven in an organization, which varies drastically based on ability to execute and maturity levels. And, for a lot of businesses, it’s important to show results within a quarterly cycle.
But what’s really important is that you don’t turn value into a long winded run, or a long shot down the line, and that you don’t simply hope that value happens.
Through Value Sprints and Continuous Value Delivery you can create a sustainable approach where the business can realize the value from it’s technology investments in a sustainable and more reliable way for real business results.
And that’s how you win in the game of software today.You Might Also Like
Studies* show that certain memories help us learn and remember more effectively. Combine a course with a team building exercise, an appraised movie, and you have something amazing - a training with lasting impact.
This is exactly what we wanted to achieve with the first Bosnia Agile organised Scrum.org Product Owner training.
The PSPO (link) training was build around two events, the Sarajevo Film Festival and a rafting team building exercise. It does not come as a surprise that this event was sold out 6 weeks ahead.
Between watching a great movie 'The Railway Man' and rafting in this beautiful region, the students where also learning everything important about Scrum, value, lean and agile product ownership. Since I was the trainer it might sound pretentious from me to say how awesome this training was, but in all modesty, it truly was. It was an outstanding and new experience not just for myself. I made many friends and shared many great moments with my fellow students. I am sure that Sarajevo played a big part in this. Sarajevo, the capital of Bosnia-Herzegovina, is a very dynamic and friendly city surrounded by beautiful nature and with good reason was the host for the ’84 Winter Olympics. I for myself cannot wait to go there again.
25 happy Product Owners and a happy trainer cannot be wrong. We have been so pleased that the organisers and I decided to repeat this setup once again next year.
If you live somewhere in the EU you should consider combining education with worthwhile memories. More training content will stick and even better, you will have more fun learning. Consider this: even with budgeting in the costs of transportation and accommodation, it is probably still cheaper than your near-by training provider.
See you next year at the 21st Sarajevo Film Festival …