As you read this headline, many things came to your mind, probably. You might have recalled those many hours of meetings as you tried to come up with a time estimate for a project or for a product release. Or, you might have remembered the planning poker sessions, which were intended as a spot-on pragmatic business activity, but in the long run proved to be nothing else than a child’s game, because the estimates attained as a result of planning poker sessions differed 2 or 3 times from what the actual work really took. The sharp question that I want to ask is: how many times did you feel deep inside that when they make you do an estimate (them being managers, or clients, or anyone else in charge), you end up with nothing else but a waste of time, because later in the project you still face the need to explain why your initial estimate proved to be that different from how things actually turned out, and feeling guilty in the process, though probably nothing of it was actually your fault?
Don’t get me wrong. My initial intent was pure and well-behaved. I humbly wanted to write an article to sum up techniques for estimation used in agile, describe their pros and cons, and provide people with a single-point reference for all those techniques. However, as I went deeper into the research, I was astounded. It turned out that there are many more articles and write-ups out there in orthodox agile circles on “How to estimate?” as opposed to “Why estimate at all?” In those few cases, where I saw some attempts at explaining “why?”, they stroke me as incongruent and built on some very loose logic. This very fact of the looseness of “why?” puts a big question mark on the validity of the “hows”, because the “how” is a product of “why?” or “what?’ I’ve cited this in one of my previous articles, and I’ll repeat it one more time, because this axiom is universal, and works for all things life and project management alike: The hows will appear if the what becomes clear.
Let’s take the scalpel of pragmatism and dissect the faulty logic behind all things agile estimates.What is an estimate?
Is it a measure of commitment? Or is it a lazy talk? I tried to find some stats on the actual usefulness of the estimates in story points, and how they’ve proven themselves valid in the bottomline world of business. I found none. From my own experience, I know that estimates never work. I’ve seen this in project-by-project software development and in product development. A slightly modified quote from here:
It’s impossible to estimate something that is being built for the first time.
We never build the same feature twice.
The only viable example of valid use of estimates that comes to my mind goes as far back as to the early 2000′s, when people wanted simple e-commerce web-sites, or dating sites, or something of that kind. Having built a handful of such web-sites, software vendors were more likely to give their clients a realistic estimate of completion, because these web-sites didn’t have a heavy baggage of residual debris, such as technical debt, bulky databases, or an octopus-like architecture, which just spreads, rendering futile any attempts to commit to the bottomline “get the sh..t done on time” stuff.
Next, if any attempts at estimating are futile, then why do most companies continue to play this game, which resembles courting, but unlike courting promises no pleasure ahead, only the ever increasing snowball of mess, feeling guilty, unproductive and unaligned with the only goal that matters: get the job done well and on time?
Stay tuned for the answers and even sharper disclosures in the upcoming part 2 of this article.
In Why Agile Estimates Don’t Work – Part 1 I’ve explained why estimates don’t work if someone sees them primarily as a commitment to timing. And, just as I expected, some aficionados rushed to educate me on the subject of estimates in agile, that they are not a commitment but, in short, a discussion of chances and odds of how the development will go, considering the challenges of this particular production environment. Probably, some of those aficionados have accused me of the gravest sin ever, and namely, not reading Mike Cohn’s “Agile Estimating and Planning”. Relax, guys. I studied Cohn’s book long ago, and time after time I would flip its pages to refresh things in my memories, not to mention other books, articles and from-the-trenches stories. My most reliable source for making conclusions, however, is my work. If someone stays out-of-the trenches and theoretizes about estimates, this is just theory. My view on estimates lies in the practical, pragmatic context: if they don’t work as commitment to timing, but as a discussion of chances and odds, why most companies continue to play this game? What makes them go on with it? Why spending lots of time on discussing chances is valued more than action itself?What Is an Estimate? (take 2)
I’ve cited two options to answer this question in Part 1. Some people, who are, likely, not educated in agile theory, look at agile as a next best silver bullet to complete projects on time and they might wrongly view estimates as a promise of that. They genuinely believe that agile estimates will give them so much sought after reliable reference point about the time of completion. The second group of believers consciously accepts that estimating is a discussion of chances, a probability forecast. The burndown chart provides such forecast based on velocity. Let’s refresh the classical definition of velocity in our memory, quoting from here: “The main idea behind velocity is to help teams estimate how much work they can complete in a given time period based on how quickly similar work was previously completed“. Does it ring any bells now? If we never build the same feature twice, just as you can’t step twice into the same river, then why velocity-based forecast should be relied on? In general, this stands true for all the forecast techniques based on past performance, including forecast models. Yes, there are cases when a team’s work is monotonous, iteration in, iteration out, but from what I’ve been able to observe, it happens very rarely. Mostly, in any company and team, the tasks to be done and challenges to be resolved are unique, for each iteration, and for each release. You never know when something pops up and kicks this neat forecast in the butt.The Devil Is In…
.. not only in the details. The second most common habitat of the said devil, which goes after the details, is human nature itself. Nothing else explains this better than the good old Parkinson’s Law:
Yes, indeed. Having all the time in the world is loose. It’s either you have time, or you don’t have it. It’s either you have the guts and sixth sense to define what should be included to the minimal viable product, for instance, or not. Let’s don’t forget that no one cares about software development for its own sake, except the software developers who view their work as craft. We do things for the market. For customers, and they don’t care about the development kitchen constraints, challenges and brilliant solutions. Same stands true for UX.
Now, how this reasoning fits into the subject of estimates, someone might ask? Here’s the astounding truth. Teams and companies start playing around and messing with estimate rituals when they have some extra fat to burn. There’s no room for activities that are waste in a bootstrapped, mission-oriented, do-or-die start-up squad of several people. If you are in such a team, and tempted to start a planning poker session, don’t do this. Rather than waste your time on playing with probabilities, get some real work done. Write code, do a UI sketch, instill clarity to the work of your team. Some mathematical forecast model surely has it that a brick will fell on your head one day. But you’d hardly be wasting your time to estimate how many more bottles of champagne are likely to slip out of a torn plastic bag, when one of those bottles has already hit the concrete, and there are 3 more in the bag. You’d rush to catch the rest of the bottles, not to let them slip, right? Or will you freeze and estimate the probability of all of the bottles being shattered? This reminds me of the fact, that some business people who are skeptical about shamanism, astrology and other such things, devotedly indulge into what is, in essence, shaman rituals with estimates. Come on, the estimate of completion based on burndown or a planning poker session, is as valid as an astrological forecast. There’s no big difference. It’s either you’re “fat” enough as an organization to afford wasteful rituals or not. In fact, even in large companies that seem to be so safe and secure there’s always the bottomline point of “do or die”. That’s what a recent story with massive job cut by Microsoft proves. Ritual is a waste. If there’s time for rituals left, this is a sign of unhealthy fat. Burn it. If a workgroup discusses development, there’s no need to wrap it in the ritual of estimating, because when a discussion turns into a draining debate of “how probable” this timeframe is, the work suffers. Someone said, there’s a limited number of brains to do the job, and they should be used efficiently. One can suffice with a draft estimated timeframe, there’s no use trying to gauge on the likelihood of this happening, when there’s real work to be done.Worship the Idol: How Do I Tell My Higher-Ups ..?
As life has it, however, most of us have to cope with the fallacy around estimates being employees in fat organizations, and, hard as you might, a mere human being can not move a mountain. There’s no way to persuade a higher-up non-developer manager, or a client, or a stakeholder in the vanity of estimates. That’s why people go on playing games, as they attend to those who expect a feature or a project to be done on time, as derived from estimate-related shamanic rituals. And, that’s where another interesting booster for evolution is hiding. Luckily — and, yes, I mean it, luckily — there are more non-developers in the position of authority than developers. There’s always a point of litmus test, when someone with a developer background (a project manager, team leader, or someone in middle management) meets the non-developer stakeholder. Why I call it a booster for evolution? If every stakeholder were a developer, they would have probably ended up whining on each other’s shoulder about how difficult life is, and how impossible it is to commit to any timeframe. Having to deal with a non-developer stakeholder about a deadline is stimulating. If you’ve been thinking that something has changed from the hunter-gatherer times, I have bad news for you. The seeming “comfort” guises the basic instinct to act. You either act, or you rot. There’s no other option. No one cares for reactive rants. It’s your actions that define you. It’s your choice to agree to play the estimate game by the rules and accept this as a given, or to quit and find a job where they will not f…k your brain with estimates. If you choose to deal with ruthless stakeholders that are oh-so-not-understanding of how hard a life of a true software craftsman is, move the conversation from the level of rant to the level of action. Use every opportunity to spread the awareness of the challenges that software development portends, and why this domain is un-deadline-ifiable by nature. Amazingly, there are so many people in this world who sincerely believe that an estimate is a credible measure for completion date. Write articles, speak on conferences, join the “no estimates” movement. Fix the gap between what you know, and what they now. If everyone has their say, this world will become a better place, with less projects and software screwed. And, even if you’d still have to deal with the waste of estimates, you’d feel better inside, because you’d be doing your all to change things, instead of ranting.
Enough of thought boosters (or busters?). In Part 3 of the series I will give an outline of some techniques, commonly regarded as techniques for estimates, that might work as a tool for workgroup discussions in some teams. Keep in mind the waste-value balance, though.
Lots has been written about backlog refinement (what we in the US used to call grooming), and a lot of it is good. There is lots to say about this practice. However, I’ve not seen any treatment on whether you should do it differently for your initial backlog. Therefore, I’m setting out in this post and in the next to answer these questions:
- How do you refine and estimate the initial backlog?
- How do you refine and estimate additional stories or subsequent backlogs for work that comes along later?
- Wouldn’t those approaches be the same?
Usually, when I spin up a new agile team, they don’t have an initial backlog. Nevertheless, the parent organization just about always knows what they want the team to do The vision or mission or charter is there–though it might not be communicated clearly. Sometimes there are documented requirements in what is often called a PRD, MRD, or BRD. Whatever the case, if there is no backlog of user stories, I typically hold a story writing workshop to get the ball rolling. Now that we have a crude backlog, it needs to be refined.
This post is not about where the ideas come from or even about how to convert what already exists into user stories. The focus here is about how to conduct that initial refinement meeting, then what might be different in subsequent refinement sessions.
For the initial refinement, I recommend compressed refinement. After that, I recommend continuous refinement.Compressed Backlog Refinement
When refining that initial backlog, often after spinning up a new agile team, there is usually someone in the chain of command wondering, “Why isn’t anyone coding yet?” There is a great deal of pressure to just get started already. The team is probably anxious to get started too, unless they are still trying to wrap up the prior project. At the same time, we want to know when we expect to get done with this new work, when we can get to the next release or how much of the backlog we’ll have when the release date rolls around. It’s not sufficient for my clients to tell them they’ll get what they’ll get when they get it. My clients need predictability. We also need to refine the backlog to identify dependencies, risks and items with long lead time. Anyway, it takes some time to create, refine and estimate a backlog, to form teams, to do the sprint-0 stuff and get rolling. We want to do a good job refining the backlog, but we can’t take forever to get it done.
Therefore, we do a compressed approach to backlog refinement.
Stories are written, we have a backlog of crude stories, and we need to refine them all quickly. In the compressed refinement approach, we’ll have a series of refinement meetings. It could be half-day to full-day meetings for the better part of a week. The whole team attends. Please bring in lunch, preferably a good lunch. You may find yourself updating stories in your agile management tool in real-time during the meeting. That’s generally unproductive, so strike the right balance. Some edits might have the whole team collaboratively involved, arguing over wording and meaning. Other edits can be done by someone else in the room on the side. Of course, other edits will be made offline.
This compressed approach tends to be very detailed and slow because we’re going from crude stories to well refined stories during the meeting. Since we’ve talked about them in such depth, we might as well estimate with planning poker as we go.
Because our story discussions are so detailed when using this approach, you might be able to get by with an abbreviated sprint planning meeting for the first 2 or 3 sprints.Punctuated Refinement
Organizations that operate in project mode rather than product mode tend to do this compressed refinement approach over and over for each project that comes along. They spend little time getting the backlog ready for the next project while the current project is still underway.
This is backlog refinement done in a big batch. This is rolling wave planning with big tidal waves. That’s usually not the best approach. After this 1st compressed refinement, let’s move on to continuous refinement.Not Talking About Progressive or Elaboration
I’m not talking about progressive elaboration or even elaboration. Elaboration in an agile sense is more about decomposing epics into features and features into user stories and then providing the details for the stories (the acceptance criteria) and their visual specifications. Adding the term Progressive to Elaboration means we do it more or less just in time over the course of time.
Here’s how we may do both Progressive Elaboration and Compressed Refinement: We may still progressively elaborate epics and feature, then have an intense period of backlog refinement, kick off a project, yet still do more progressive elaboration of user stories, their acceptance criteria, and visual specifications over time. What I’m writing about is whether we refine and estimate most of our stories in a compressed period of time, say, a week, maybe two or whether we do that refinement over time and further in advance.Recommendation
There are some downsides to this. A compressed refinement does not allow for the long lead-times that may be necessary to do some research, figure some things out, learn some new technology, put the necessary architectural run-way in place, work out contracts with 3rd parties, or get other groups to build out dependent pieces. Also, we sometimes need additional time for things to soak in. We need to take a step back and look again at the big picture. Because of these things, we may end up with a poorly refined backlog or a poor plan.
For these reasons, I recommend making the switch from project thinking and punctuated refinement to product thinking and continuous refinement. That’s the topic of my next post.
This year, I’m excited to be returning the Agile Conference. Having organized and participated in the conference from 2001-2005, my attendance became sporadic as the beginning of the youth football season (my other coaching gig) won out over the annual agile pilgrimage. Preparing for the show brings back many memories, but also some lessons learned that I wanted to share for anyone new to the conference or looking to get a little more out it. In true agile form, I’ve made a pithy acronym. Follow these suggestions and after the conference, you’ll be saying, “That’s a PEACH, hon!”
The Agile Alliance Agile2014 Pre-Conference Planner is a great resource for planning your conference activities. Obviously, you’ll get the most out the conference if you review the sessions and target the sessions you don’t want to miss (MoSCoW anyone?). For your most important sessions, check out the room size. As part of a commitment to an open learning environment, the conference does not reserve seats, nor limit your ability to participate. The most popular sessions will fill their rooms, leaving some standing or not able to attend. In your conference guide, you can get a sense of the room size. If your must-see session is in a smaller room, GET THERE EARLY!!
There is great content to choose from. Pick your targets, but include one or two sessions that are out of your box and may give you empathy for someone else’s kind of work. If you need ideas, check out these sessions being given by the nearly 20 speakers from VersionOne and our partners:
VersionOne: Matt Badgely, John Krewson, Steve Ropa
agile42: Richard Dolman, Martin Kearns
Cognizant: Raje Kailasam
DavidBase: Jeffery Davidson
DevJam: Matt Barcomb, David Hussman
Improving: Ken Howard
LeadingAgile: Mike Cottmeyer, Derek Huether
Lithespeed: David Bulkin
SolutionsIQ: Daniel Gullo, Tim Myer, Dhaval Panchal, Charlie Rudd, John Rudd
The conference can be overwhelming with tons of people, tons of sessions, tons of exhibitors (read: free stuff!), tons of activities. Sensory overload. So pick your focus , but try at least one thing that will stretch you a little, socially and intellectually.
If you are new the conference, I highly recommend the First Time Attendee Orientation. At that session you’ll see everyone else who is wondering about the things you are and then some. The Early Registration Meet & Mingle and Ice Breaker Reception (Moscow mule, anyone?) is another great way to start the week. Between sessions, look up from your screen enough to meet some new folks and hang out. Dinner with New Agile Friends is a great way to meet people, especially if you are not attending with a group of colleagues. And, of course, the Conference Party should not be missed.
Don’t miss the Sponsors reception and the booths through out week. Check out our @VersionOne mobile photo challenge on Twitter where you can win daily prizes or a GoPro HERO3+.
You’ll learn new things about the conference as you go through it. Your time is the most valuable thing to manage, with perhaps sleep a close second. Use the Open Space Law of Two Feet to adapt what you do. Is a session not quite what you expected? Don’t be shy, get up and move on. Take the time to find another session, hang out, catch up with those incessant emails and posts, or just take a breather (or nap)
You develop deeper understanding by interacting with others. The conference favors interactive sessions, but there are many other ways to share and learn. Be sure to swing by the Open Jam and catch the latest buzz. The Scrum Alliance is holding a Coaches Clinic each day where you can share ideas and challenges with Scrum experts. Our conference organizers, the Agile Alliance will have the Agile Alliance Lounge open each day.
And if you see any of us VersionOne folks, in our sporty shirts, please stop us, introduce yourself, and mention what a wonderful blog post this is. We love agile and learning by sharing with others.
The most valuable experiences I hear about are the interactions people have hanging out in the hallways. These by-chance encouters lead to amazing insights and relationships. If you are are an extrovert, this will come naturally. If not, here are a few tips:
- The Agile conference has always been known for its community atmosphere and approachable speakers and attendees. Its kinda who we are. So, realize that you are in an environment that specifically values Individuals and Interactions.
- It may be awkward at first. Yes, it can feel very weird to approach someone you don’t know and initiate a conversation. Work to overcome that fear (for the XPers and Scrummers, this is living up to your Courage value). Asking about a favorite session or the basics like what one does in their job are simply ways to get a conversion started.
- Don’t give up. Not every encounter will be amazing. If a conversation does not take off, no worries, the next one prpbably will.
- Approach a group. If you hear a small group talking about a topic of interest to you, don’t hesitate to approach, express your interest in the topic and join in. You’ll be well received and add another interesting perspective to the dialogue.
- You probably know more than you think. Many attendees have told me after the conference, “you know, from our experience, we know as much as most of the people at the conference.” If you are feeling intimidated that others seem to know more than you, realize that either a) they don’t and are just more comfortable talking about what they know or b) were in your shoes just a few years ago and are passionate about helping you learn what they’ve learned.
Do you have recommendations for conference goers? Please share them by commenting below.
Have a great conference. I hope our paths cross during the week.
We use Slack as a team collaboration tool, and it displays cheering messages on load screens. Such as, “What good shall I do today?” or “You got in, and day just got better”. One such message from Slack inspired me to write this post. The message goes like this: “Remember to get up and stretch once in a while”.
There’s no doubt, that with the bulk of our days spent at our desks, we do need some sort of stretching. It’s hardly that any IT worker, or knowledge worker, will question the need to exercise and to keep fit. Media advertise lifestyles where some sort of physical training is a must. So, if we don’t want to be labelled as “couch potatoes”, or if we lack movement, we naturally want to compensate for that. Many years spent studying, and then working, and sitting all the while, require some sort of compensation. At one point or another, any sedentary worker will want to step on the path of exercising. It seems, what can be wrong about it? Everyone is doing this, and it feels so great to exercise! The devil is in the details, as usual, and I want to outline the trend that I currently observe with some of my colleagues, and which, actually, I observed earlier in my own life. This is not a wellness blog, and this article is not about wellness and keeping fit. It is about keeping ourselves sustainable for doing our work in software development. It might sound as a bummer, but if we put too much of our personal energy into exercising, this will not only be of any good, but it will, in fact, sabotage our productivity.
It’s quite hard nowadays to resist following the lifestyle that media impose. We are told to go jogging, or to ride a bike, or to be a triathlete, or to run a marathon. I’m 100% certain that everyone who will read this article is either doing these activities themselves, or has some friends that do. Now, here’s what the trick is. As I was able to observe, people usually start out with their athletic pursuits after they lack physical movement for many years. It’s as if they are let loose from a leash, and it’s a euphoric experience, to feel yourself moving, exercising, pursuing, being an athlete. Until there comes a time when you realize that this euphoria is not endless, and investing too much effort in exercising backfires, and backfires hard. That was the case with me. In my late 20′s I felt some sort of itching to exercise, and I started out with jogging in a nearby park (on concrete, and jogging on concrete is a knee joints killer, no matter how hype your sports shoes are, but that’s a whole other story). Then, I really got into tennis and passionately devoted myself to mastering this sport. I’m a stubborn and persevering girl, and if you’re serious about doing tennis, you need to keep yourself in good physical shape. So, apart from my tennis practice, several days per week, I did jogging, went to the gym, did some tennis-specific workouts, and I used to have 2 or even 3 training sessions per day (!), and I was doing this in parallel with my day job. Everyone cheered me, because it’s a commonplace belief that it’s such a great thing for knowledge workers to exercise. I managed to maintain this regimen for about 7 years, until at one point of time I realized that I can’t do this anymore. Instead of being a joy, playing tennis — this most beautiful, graceful, smart and elegant sport ever — turned into a dull burdensome chore for me. Besides, my health deteriorated, and this prevented me from doing my best at work. I realized that I need to make a choice, and since I had no intention of becoming a professional athlete, I terminated my tennis practice for an indefinite time. Someone might say, come on, you can just play leisurely, once or twice in a week! The point is that with this fatigue from overexercising that has accumulated over those years, I’m happy and comfortable with this indefinite break. Now I exercise as I swim in lakes (no chlorine for me, thanks), or go on walks, and my favourite way to exercise at the moment is to walk barefoot in a park, on a grass lawn.
Why I’m telling this story? Ironically, I see that some of my colleagues in their late 20′s experience the same curve of being fatally drawn to exercising. They suffer from injuries, but still exercise, as if butterflies drawn to a fire. Everyone lives their own life, and it’s their journey. But I can clearly see, and I can tell from my experience that overdoing with exercises is not only harmful for health. It switches focus from work to exercising. If you have friends who show these symptoms, try to talk them out of the exercising madness, if they agree, and help them look at their life from the perspective of holistic personal energy management. There’s a great book that can help with that. We don’t need the overstrain and depression from exercising ourselves to death. This is not a war, and there’s no way that someone will put up a monument on our grave for that. We need some sort of light activity, and it’s a matter of personal preference. As for me, I’d rather prefer not to expose my spine and joints to unnecessary physical load. Sitting in a chair, no matter how ergonomic it is, is bad for our spines, so I’m particularly sensitive about all things spine, and I’d rather do some soft exercises, such as yoga postures, or stretching (I’ve got the whole baggage of cool tennis stretches from the years of my practice :), or use a fitness ball. Or, walk and swim. Skipping, biking, or, God forbid, jogging on a concrete are my least preferred kinds of physical activities. Another bottomline thing is that the healthcare bills are not ethereal. They are real. So, if we do not want to end up being healthcare bankrupts by our 50′s, it’s better to use caution about exercising as early as in the 20′s, or at least 30′s.
Last week-end I had a flashback to this do-or-die exercise mindset. I was walking barefoot in Delaware Park, enjoying the feel of grass and fresh air after the rain, the landscape was so serene, and there were not too many people in the park. Then, I saw a massive guy, who was obviously doing some sort of plyometric training, running uphill in sprints. He was huffing and puffing, and, as I sat nearby, I could hear some hard-and-push music from his earphones. Well, his huffing and puffing was actually breaking the serenity of the moment, but I could definitely empathize with this guy, because he reminded me of those days when I used to be like that myself. Then, after a while, the guy was done with his training and, as if sensing my discomfort, said to me as he passed by: “Now you can have it all to yourself”. I laughed and said: “I hope your workout was good!” He didn’t answer and looking at him one could say that he was rather exhausted than happy and filled with energy after this workout. Then, I proceeded walking barefoot around the loop of the Hoyt Lake, and spotted a beautiful piece of street art as I went:
Now, tell me, who do you think felt recharged and re-energized on Monday? Me or that guy? The answer looks obvious.
If you’ve been paying attention to agile at all, you’ve heard these terms: pairing and swarming. But what do they mean? What’s the difference?
When you pair, two people work together to finish a piece of work. Traditionally, two developers paired. The “driver” wrote the piece of work. The other person, the “navigator,” observed the work, providing review, as the work was completed.
I first paired as a developer in 1982 (kicking and screaming). I later paired in the late 1980′s as the tester in several developer-tester pairs. I co-wrote Behind Closed Doors: Secrets of Great Management with Esther Derby as a pair.
There is some data that says that when we pair, the actual coding takes about 15-20% longer. However, because we have built-in code review, there is much less debugging at the end.
When Esther and I wrote the book, we threw out the original two (boring) drafts, and rewrote the entire book in six weeks. We were physically together. I had to learn to stop talking. (She is very funny when she talks about this.) We both had to learn each others’ idiosyncrasies about indentations and deletions when writing. That’s what you do when you pair.
However, this book we wrote and published is nothing like what the original drafts were. Nothing. We did what pairs do: We discussed what we wanted this section to look like. One of us wrote for a few minutes. That person stopped. We changed. The other person wrote. Maybe we discussed as we went, but we paired.
After about five hours, we were done for the day. Done. We had expended all of our mental energy.
That’s pairing. Two developers. One work product. Not limited to code, okay?
Now, let’s talk about swarming.
Swarming is when the entire team says, “Let’s take this story and get it to done, all together.” You can think of swarming as pairing on steroids. Everyone works on the same problem. But how?
Someone will have to write code. Someone will have to write tests. The question is this: in what order and who navigates? What does everyone else do?
When I teach my agile and lean workshop, I ask the participants to select one feature that the team can complete in one hour. Everyone groans. Then they do it.
Some teams do it by having the product owner explain what the feature is in detail. Then the developers pair and the tester(s) write tests, both automated and manual. They all come together at about the 45-minute mark. They see if what they have done works. (It often doesn’t.) Then the team starts to work together, to really swarm. “What if we do this here? How about if this goes there?”
Some teams work together from the beginning. “What is the first thing we can do to add value?” (That is an excellent question.) They might move into smaller pairs, if necessary. Maybe. Maybe they need touchpoints every 15-20 minutes to re-orient themselves to say, “Where are we?” They find that if they ask for feedback from the product owner, that works well.
If you first ask, “What is the first thing we can do to add value and complete this story?” you are probably on the right track.Why Do Pairing and Swarming Work So Well?
Both pairing and swarming:
- Build feedback into development of the task at hand. No one works alone. Can the people doing the work still make a mistake? Sure. But it’s less likely. Someone will catch the mistake.
- Create teamwork. You get to know someone well when you work with them that intensely.
- Expose the work. You know where you are.
- Reduce the work in progress. You are less likely to multitask, because you are working with someone else.
- Encourage you to take no shortcuts, at least in my case. Because someone was watching me, I was on my best professional behavior. (Does this happen to you, too?)
The effect of pairing and swarming is what improves your products. The built-in feedback is what creates less debugging downstream. The improved teamwork helps people work together. When you expose the work in progress, you can measure it, see it, have no surprises. With reduced work in progress, you can increase your throughput. You have better chances for craftsmanship.
You don’t have to be agile to try pairing or swarming. You can pair or swarm on any project. I bet you already have, if you’ve been on a “tiger team,” where you need to fix something for a “Very Important Customer” or you have a “Critical Fix” that must ship ASAP. If you had all eyes on one problem, you might have paired or swarmed.
If you are agile, and you are not pairing or swarming, consider adding either or both to your repertoire, now.
In Project Management, if one thing is for sure, it’s that nothing is certain. You can try to plan everything to a ‘T’ and account for every possibility, but there will invariably be things that pop up unexpectedly. Sometimes this leads to project managers thinking, “If only I held more planning meetings and spent more time talking things over with my guys, then their best laid plans wouldn’t go awry“. Instead of looking back at the project planning as the issue, we can perhaps learn more by better understanding the nature of uncertainty itself. Uncertainty is a very important topic in quantum physics and understanding the nature of the universe. Since Scrum already uses some physics terminology, like velocities and projected values, I thought it would be fun to run with this idea and take some of the implications of quantum physics and see how they would translate if applied to project management.
Before Breaking Bad brought him back, most of us remembered Werner Heisenberg for his uncertainty principle from high school physics. Mostly that you can you can never fully know the position and momentum of a particle at any given time. This is often misused or confused with the ‘Observer Principle’ meaning that you can’t measure something without actually affecting its outcome. For example if you have an electron traveling in space, the only way that you would be able to detect it would be by having it react with some other particle or detector that would then relay that information back to you.
In order to detect an electron to tell us where it is, we have to transfer or absorb some momentum from the electron, thus changing its momentum. It’s like if you have an overbearing manager demanding constant status updates. Just by getting a status update (taking a measurement to get the team’s position), he or she is consequently affecting the team’s momentum.
So what does the observer effect have to do with uncertainty? Nothing, really, but it’s often misrepresented as a result from uncertainty, so I thought I would address it first. This principle also has common classical examples, like how you can never accurately take your temperature using a mercury thermometer. Because the heat from your mouth flows into the thermometer and slightly cools your body, you can never get a truly accurate measurement.
Heisenberg’s actual uncertainty principle is represented by the formula:
Δx · Δp ≥ ℏ/2
Where Δx is the uncertainty of position, Δp is uncertainty of the momentum, and ħ is Plank’s constant over 2π. If either of these values were completely knowable, then the right side of the inequality would be 0, rather a constant! The fact that it is a positive number means the more you know about an object’s position, the less you can know about its momentum. Granted ℏ is an extremely small value (~1 × 10−34 J·s !), but the more you are checking up on a team’s progress there comes a point where you’re not learning anything new and are just affecting their momentum.
A lesser known relationship (and one that also has implications in Scrum) is:
ΔE · Δt ≥ ℏ/2
Notice that it has the exact same form as the previous equation. That’s because these are conjugate variables and also have to abide by the limit of uncertainty. Just as there is an inverse relationship between the uncertainty of position and momentum, there is a similar relationship between energy and time. The more you know about how much work is required for a particular task, the less you know about the time it takes to complete the task.
Many Scrum teams already account for this by using Story Points for estimates rather than using hours. Story Points removes the rigid constraint of estimating work in hours, and instead allows estimates based on similar user stories you’ve done in the past. I’m not saying that one method is better than the other, or would be the best for your team, but you’re not constrained by cosmic forces like uncertainty.
Since Scrum is an iterative process, you can have great success by focusing on things that you can say with a fair degree of confidence, while still allowing for some uncertainty in all planning and estimates.
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
So, you want to be an Agile shop. You’ve read all kinds of cool stuff about Sprints, and WIP limits, and daily stand-up meetings. You even think you get this crazy User Story and Planning Poker stuff. You put together a room with snacks and lava lamps. You have all of your stories in a cool ALM tool like VersionOne and displayed on a wide screen TV. So you’re ready to go, right? Well….maybe not. You are missing the most important part….the people. Remember that one of the principles of the Agile Manifesto is to “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” In order to be successful, we need more than just motivated individuals, we need motivated Craftsmen.
Lets start with a disclaimer. I use the term Craftsman in a gender neutral sense. If folks feel like I should change this to Craftspeople, let me know and I will. I get a lot of inspiration from the Software Craftsmanship movement, which tends to use the word Craftsman.
So what is a Craftsman, and what does that have to do with Agile? Agile is hard. It is a very highly disciplined approach to software development. It also is very fast moving. If we expect to be able to “welcome changing requirements, even late in development”, we need to have people with a high degree of skills in order to do that. A craftsman is someone who takes the craft of programming seriously. One who will not do garbage work, and will not accept garbage from her peers. Lets take a look at the values delineated in the Agile Manifesto:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
We’ve all seen these many times, but let’s now look at the Craftsman’s Manifesto. You can find a link here: Manifesto for Software Craftsmanship
Not only working software, but also well-crafted software
Not only responding to change, but also steadily adding value
Not only individuals and interactions, but also a community of professionals
Not only customer collaboration, but also productive partnerships
So really, they are symbiotic. A well performing Agile shop will have Craftsmen as the vital part of their team. A team of Craftsmen, by their very nature, will be embracing those values and principles of the Agile Manifesto. So don’t forget the people as you build your Agile shop. Create an environment that encourages those great practices like Test Driven Development and Continuous Integration. Allow your team members the freedom to practice their craft, and the opportunities to enhance their craft. In the end, you will have your motivated individuals who will delight in getting the job done.
Now that I’ve had a week to reflect and let the experience sink in, I wanted to share my thoughts of our first official Baltimore Lean Coffee event.
I’ve participated in ALN DC events and even helped organize a PMI Agile meetup. So, where did our new event fall on a scale compared to the others? Did I feel like attendees received value and did I feel like we got a good return on our investment? Let me give a little comparison.Lots of effort – Too much process – Formal – Minimum ROI
WDCPMI (Washington DC PMI) Agile meetup is a more formal event that is trying to get its legs. Cost will vary, depending if you’re a PMI member or not. It’s targeted to the Washington DC project manager community. To be a host, you have to ask permission to hold an event and jump through some hoops with the local PMI Chapter. It’s a PMI evening event, so you can’t simply order pizza. It gets catered. You have to make sure you’re compliant with PMI Chapter processes. To me, the process and effort put into organizing and holding the event is not worth the value it delivers.Less effort – Not too much process – Less formal – Good ROI
ALN (Agile Leadership Network) DC is a semi formal event that happens once a month in the evening. For $10, you get an evening of pizza, an opportunity to interact with others, and listen to a guest speaker. I like it because it’s casual and it’s good to see others from the local Agile community. What I don’t like is it’s in Washington DC and it’s in the evening. For those who want to see their families after a long day, this can be an inconvenience. I’ll admit, I am not an organizer for this event. I don’t know how much overhead is involved. (I would love to hear from someone in the comments) The group does a good job of not letting the process get in the way.Minimal effort – Minimal process – Informal – Maximum ROI
Baltimore Lean Coffee is a structured, but agenda-less meeting. Participants gather, build an agenda, and begin talking. Conversations are directed and productive because the agenda for the meeting was democratically generated. We don’t charge anything to join us. If you want to grab a cup of coffee (or other beverage) and a pastry, that’s up to you. Our meeting was 07:30-09:00 on a Friday, allowing people who had to go into an office (or even work from home) time to join us. The last voted topic of our meetup was the time and location. In true Agile form, we discussed it, voted, and decided we liked the time and location. Our next meetup is August 8th back at Mad City Coffee.
I've listed a whole series of Kanban Coaching Professional (KCP) Masterclasses for the 2nd half of 2012. These classes are typically residential and can be consumed as 2 x 3-days or in a single 5-day week long intensive class. Typically 4 out of 5 people are choosing the 5-day version of the class since we introduced it at the beginning of 2014. These classes are a big commitment in time and money and we often get asked where the value is? I'd like to explain.
Success has many fathers! Recently, there has been some content published elsewhere on the web that seeks to re-write the history of the adaptation of kanban systems into the field of creative knowledge work. The individuals publishing these alternative versions of history are generally doing it for self-serving reasons or in some cases as deliberate misinformation to try and undermine my business. To put the record straight, I've compiled this definitive history...A History of Kanban for Creative Knowledge Work October 2004
Dragos Dumitriu, manager XIT Sustaining Engineering at Microsoft, asks me to help him. I design a pull system for Dragos' group and coach him on how to introduce it. He "sells' the idea to his bosses and his 4 product managers who act as his customers. The pull system was implemented on Microsoft Product Studio (a forerunner of Team Foundation Server). There was no physical board. The engineering team was offshore in Hyderabad, India. The system implemented was inspired by Theory of Constraints Drum-Buffer-Rope and worked on the assumption that Test was the bottleneck.
Fred Brooks warned us of these dangers nearly 25 years ago in The Mythical Man-Month.
One antidote to the PM schedule crunching technique of throwing warm bodies at the problem is to remove the impediments that are known (or just under the surface) within the structure and environment that holds the team back from performing at more efficient delivery rates. So many times the line workers (developers and testers) are well aware of these issues, and feel as if they have raised them many times and gotten little attention (mostly negative attention) from managers. A classic game (Innovation Game) to expose these impediments is Speed Boat.
I just saw this image of the anvil holding the balloon down and thought it would make a great visual metaphor for the Speed Boat game. See the article by Alan Dayley Velocity is Like a Helium Balloon to get a hi-res poster.
WARNING: Shameless plug for my session at Agile2014 ahead.
I recently got the priviledge to listen to Alistair Cockburn talk to a small group at the VersionOne offices. He told the story about Kent Beck and how the idea of how the user story on notecards was born (I’ve read about this before, but it was great hearing it from Alistair). He talked about how the card was just that — a card with a title that reminded the developer and the target customer/user what they were building, maybe there were a few notes jotted down on the card. The narrative about the story wasn’t captured on the card — the details were verbally communicated because the developer and customer were all in close proximity of one another — they did this crazy thing, they simply walked down the hallway and talked.
In addition to this story, Alistair spoke about his experiences with a team that had development in Singapore and the business folks and architecture worked in the states. The company was having challenges with the team in Singapore at getting things done efficiently and, in some cases, getting things done right. It seemed like there was an inordinate amount of time that had to be spent on discussing requirements and getting questions worked out. The company decided to send some of the business and architect team members to Singapore to work out some improvements. When they did — the quality and productivity went up. When they returned, it took just a couple weeks before productivity slipped and all gains were lost. The reason for these results seems obvious — timezones, communication barriers, and not being able to have impromptu conversations can have a great impact on how well teams understand the requirements especially since a lot of conversations capture the specifics.
Hearing these two stories triggered some ideas in my head, and I thought — why can’t there be a simple formula we can use to gauge the amount of detail (words) we capture in a story to make it work. Through some hard work — I’ve now have that formula.
Here are some factors that I think go into figuring this out:
- Complexity – just how well does the team understand the story and how hard the team thinks it will be, either from experience or flat out guessing. Usually captured as story points.
- Difference in Timezones – the number of hours that separate us greatly impacts how fast communications can happen, especially if the communications occur near the bookend points of the day.
- Auditing Requirements – audits are generally costly and require an additional amount of documentation overhead.
- Multiple Offices – when people are in different buildings, it raises the amount of details that have to be captured.
- Offices on Different Continents – although this somewhat relates to timezones, there is also the fact that people speak different languages. Even if they all agree to use english as the primary business language, there’s still slang, accents, and even cultural differences that impact communications.
How Long the Team has Worked Together – knowing each other is key, we figure out accents, we are able to exchange less verbal words, and we learn how to work with one another — what level of information is required to work effectively as a team.
So I reached out to some friends and the folks at Tagri Tech, and with their help — here’s the formula we came up with:
Amount of Words in Story = (Complexity * (1+ max absolute difference between timezones) * (1 + # of annual audits) * (Total # of locations * # of continents)) / (# of quarters the team has worked together)
And here’s the formula in action:
Multiple simulations have been ran and I found that the formula works in less than 0.01% of the situations. The people I’ve been working with at Tagri Tech’s statistics analysis department have ascertained that every team is different, and every product is different — this means that no matter how much documentation you have — the people involved in creating the documentation or the target consumer of the documentation really are not going to read it. They found that while some documentation like compliance reporting and end user documentation are necessary, much of the collaboration level docs are only consumed by the person that created it.
Ultimately, Teams will generally work together to figure out how much details are truly required to facilitate working effectively. If your teams are having challenges with how much documentation is required within Agile Software Development projects, then please come to Agile 2014 and check out my session on Friday at 9AM in the Sanibel room, we’ll talk about some ways teams can workout their own formula.
Update: Hopefully you read all the way to the bottom of this post and realize, this is just a ruse, a joke, a farce, me not being serious. My point is, agile is hard and the concepts of documentation around building software makes it difficult as well. The right amount of details in our requirements is a trial-and-error thing, sometimes you’ll have too much details and at times too little.
In preparation for my talk, Agile Projects, Programs, and Portfolio Management: No Air Quotes Required, I have created a Minimum Reading List for an Agile Transition. Note the emphasis on minimum.
I could have added many more books to this list. But the problem I see is that people don’t read anything. They think they do agile if they say they do agile.
But saying you do agile doesn’t mean anything if you don’t get to done on small stories and have the ability to change. I hope that if I suggest some small list of potential books, people will read the books, and realize, “I can do this!”
I am probably crazy-optimistic. But that hasn’t stopped me before.
I would like your help. Would you please review my list? Do you have better books? Do you have better suggestions? It’s my list. I might not change my mind. However, if you comment on that page, I would know what you think.
Thank you very much.
Forgive me for bringing up show tunes. I love the old musicals. One of the true classics of American theater is the show Oklahoma. I got to thinking about this in a very roundabout way the other day. The song, called “With Me It’s All or Nothing” got stuck in my head. Let me tell you why…
If you like to cruise the various discussion groups, you will find to time see a question “When it comes to Agile practices, which ones should I do first?” or “Which Agile Practice is the most important of all?” These questions are fun to argue about. They are mental candy. But the bottom line is, just like candy, they can also be bad for you. If we decide that iterative and incremental development is the most important aspect of Agile, does that mean we can get rid of Test Driven Development? Or, if we decide that Continuous Integration is the most important practice, does that mean we can break out the Gantt charts? I don’t think it does.
The most egregious example I have seen in this, and it is unfortunately quite common, is the mistaken belief that we can do all of those nifty Scrum ceremonies and activities, and ignore the development practices that make Agile work. If you have an iterative process that embraces change, even late in development, but have none of the practices that make that possible, you just have a lot of tired, frustrated programmers. This may be the source of some comments we’ve seen on this blog lately that say “I hate Scrum”. I often wonder if it is Scrum that these folks hate, or if its the fact that only part of it is being used.
I’ve always seen Agile, or more specifically the implementation of Agile, as a whole package kind of deal. The real power of Agile software development is not the fact that you do things in smaller increments, or that you write your code test first, but in the supporting power of each of these elements. The whole is so much more than the sum of its parts, that I can’t understand why one would chose to not implement the whole thing. Its sort of like buying a pepperoni and mushroom pizza, then picking off all of the mushrooms. If you didn’t want mushrooms, why did you order the pepperoni and mushroom?
This all came about because of a rather heated discussion around what is more important, Acceptance Test Driven Development, or Unit Test Driven Development. The “antagonist” in this argument was contending that since the Unit Tests are “just for the developers” they really were unnecessary, and Acceptance Tests were all that was required. After a while I couldn’t help but ask “why are we arguing about this?” The real answer is we need Acceptance Test Driven Development, we need Unit Test Driven Development, Refactoring, Continuous Integration, and yes, Pair Programming. You see, with me it really is All or Nothing.
I have an article in a new online magazine, Women Testers, the July 2014 edition. My article is called “Why Testing?”
When I was a tester or a developer, I asked many questions. As a project manager, program manager or consultant, I still ask many questions. One of those is the Why question. This article examines that question from a number of perspectives.
I bet you’ll enjoy it!