Just writing this to inform you that I’m switching blog platforms, head over to Medium to read more recent material. 🙂
Part of the reason is that I will soon no longer be a CTO. Starting after the summer I’ll be project / process / change management consultant, and will focus more on that in my new blog.
Shoshin is a concept in Zen Buddhism meaning “beginner’s mind“. It refers to having an attitude of openness, eagerness, and lack of preconceptions when studying a subject, even when studying at an advanced level, just as a beginner in that subject would.
Most of us are quite good at what we do for a living, basically because we do it almost every day. This knowledge and expertise comes with several problems. As agile practitioners, we know that one of the big problems with big, up front planning of projects, is that we don’t know what we don’t know – so our plans for the future can never be perfect. One of the big problems with being an expert, is that we’re not actively aware of what we do know either.
Who would you rather hire to solve some complex business problem – an expert in the field, or a young, inexperienced person with no domain knowledge? The truth is, they can both provide valuable contributions. Without preconceived judgement, the beginner may ask strikingly efficient questions, turning the problem (and maybe the solution) upside down.
But here you are. Unfortunately you’ve become an expert in your field – jumping to conclusions and solving problems at an impressive pace. Now what?
You need to practice having a beginner’s mind. Believe it or not, it’s actually a lot more fun. It’s also a bit scary. You’re used to coming across as the person who has all the answers. Now you will have to behave and feel like you don’t really know much at all. The interesting thing about asking questions, is that you tend to get answers. Even when you think you know the answer already, it often turns out that you don’t.
The thing about beginners, is that they fail a lot. Even the very feeling of not knowing can feel like failure. You’re the expert, right? The cold stare of a boss or a customer when you ask a question you’re supposed to know the answer to. I should know this. I do know this! This beginner’s mind bullshit is going to cost me my job. Then they answer. Perhaps with a sarcastic tone.
And the answer isn’t what you expected.
You’re immediately kicked behind the knee by the feeling of surprise and (yet again) failure that you actually didn’t know. A second later, your feet barely touch the ground as the consequences of this new information floods your brain, mixed with the baffling realisation that the you of 1 minute ago, knew far less than you do right now.
Suddenly you remember what learning feels like.
I know you’re an expert, but why would you want to stop learning? My youngest son is 7 months. He fails a lot. He learns even more.
As a software company, many people are probably affected by the (lack of) quality in the products you provide. If you screw up really bad, the experience can be so frustrating that people almost break down and cry. Instead of helping them get the job done, their computers are actively working against them. Crying is a powerful expression of emotion, one that few share in the workplace. Wouldn’t you feel terrible if you were told that your products triggered negative emotions like despair, frustration and anger in your users?
I’m sure people rarely tell you that. But isn’t that the story we would like told? A story about a human being trapped somewhere out there in that big universe of ours, banging her head against your software for eternity. A story about a dream she is having. A dream of a hopefully not too distant future, where something you do takes at least one of her problems away, and how that makes her happy, if only for a little while. If that’s not beautiful, I don’t know what is!
If you’ve written user stories that for some unexplainable reason didn’t turn out beautiful, don’t feel bad. I have actually made a list that you may find helpful. Since this (as soon will be apparent) is a post about non-violent communication, I won’t call it a list of wrong things (at least not to your face), so let’s call it
A short list of things that may be less than optimal
- You actually write “as a user“. What can be more anonymous and uninspiring than helping out a “user” ? Try describing a real person (persona), her name and her role!
- You’re writing the story, but not telling it. The origin of user stories is attributed to Kent Beck (the guy who came up with extreme programming), “Tell me the stories of what the system will do” – they were originally placeholders for conversation, not written documents. A lot of context and information is lost when you just write it down and email it to someone rather than actually explaining it in person.
- You don’t share how you feel.
Let me explain that last point in a little more detail. Actually, let me introduce what I think is a new (see footnote) variation of the user story.
Introducing the Nonviolent User Story
Nonviolent communication focuses on three aspects of communication: self-empathy, empathy, and honest self-expression. If that sounded a bit touchy-feely, that’s because it is. It’s about being completely open and honest about how something makes us feel, and what we would need from others to feel differently. Yes, even at work. It’s scary, I know.
There are four basic steps to Nonviolent communication:
- State an objective, factual observation that triggers a feeling within you, as well as the need to speak up. Do not include an evaluation, just observe.
- State the feeling that the observation triggers in you.
- State the need that is the cause of that feeling.
- Make a concrete, refusable request that, if fulfilled, will meet the need mentioned in #3.
So, with that in mind, let’s continue.
The traditional story template looks like this:
As a <role>, I want <goal / desire> so that <benefit>
My first draft of the nonviolent user story, looks like this:
As <person in a role>, I experience <emotion> when <observation>. I <need>, would you be willing to <refusable request>?
That probably sounded a bit complicated, and maybe it is. It’s a work in progress, and I welcome any feedback. To make it worse, remember that this isn’t only about writing the stories, it’s about telling them. Maybe even mostly about telling them. I’m not fooling myself, most will probably not write stories in this form, but let’s start by at least thinking about it, and perhaps incorporating parts of it in how we tell the stories. Let’s go through the details, and then try it.
- As <person in a role> – this one should be familiar. Ideally I’m replacing this with Lisa the project manager, and not user.
- I experience <emotion> – Feelings. That’s a bit more difficult. “I feel like the system isn’t working properly” is not a feeling. “I feel like my boss doesn’t like me” is not a feeling. Sad is a feeling. Frustrated is a feeling. Angry is a feeling. I’m trying to express pure emotion, and I trust you not to judge me for feeling this way.
- when <observation> – Pure, objective facts. Not my evaluation of said observation. This is something that happens that I can see, hear or feel.
- I <need> – The emotion typically expressed in a user story like this is negative. Something I observed triggered a negative emotion, and this is what I need to stop that from happening.
- Would you be willing to <refusable request>? – I’m asking if you are willing to do something for me. In return I’m willing to spend time explaining why it will help me and how my world changes if you do it. If you have a different proposal, I will be open to discussing it. The request is refusable, you are not obligated to say yes.
To help articulate your feelings in #2:
Feelings we may experience when our needs are not met
To help articulate your needs in #4:
A list of needs
As Lisa the project manager, I become frustrated when I try to unpublish all products in a product group and realize that I have to manually unpublish each individual product. I need to spend less time managing products. Would you be willing to provide me with a faster way to accomplish this task?
As John the secretary, I become hesitant when I attempt to book a flight for someone else in my organisation, and are unable to figure out how to separately fill in my contact details and the details of the person who is actually going to be on the flight. I need to feel confident that the invoice is sent to me, while the person I am booking for will be able to board the plane. Would you be willing to provide me with a booking interface that clearly separates invoice details and traveller details?
As Maria the surfer enthusiast, I become angry when I am required to provide full personal details before being allowed to join the Big Wave Surfing Community. I need to be able to share my surfing experiences with friends and like-minded enthusiasts without violating my sense of privacy. Would you be willing to change the registration process so that it does not require me to share private information that is irrelevant to the service you provide?
So what do you think? Would you be willing to try it?
also published at www.revio.no
* Footnote: This post has been a draft for quite a while, and when I reached out to Bob Marshall to ask him for input on the idea, I realized he had written a post about a very similar concept called Antimatter stories at about the same time (his post was published February 26th). Bob’s many previous posts about NVC is of course also what triggered this idea to begin with. He also had some helpful feedback on the draft that helped me finalize this post. Thank you! Any errors within this post are of course my own.
The main point of the Kanban board in knowledge work, is to visualise “invisible” work. What exactly is invisible work, you may ask. In knowledge work, the answer is simple: Almost all of it. While work is in progress, it only exists as ideas in our heads or, at best, as lines of code in a computer somewhere. The Kanban board helps us visualise what we are doing, and how far along we’ve come.
That’s only sort of the topic for this post, though. More specifically, it’s about how we can use the board to discuss problems based on where they surface. All processes consist of what we call a “workflow”. A set of steps or stages required to complete the process. Each phase is named based on what we are doing or attempting to find out in that stage of the process. In a software development process, it could look something like this:
- Todo (work ready to be started)
- Analyzing (trying to figure what to solve and how)
- Developing (creating a solution)
- Reviewing (verifying that the solution is free of technical bugs or weak architecture)
- Acceptance testing (verifying that our solution fulfills the need of the customer)
- Production (work completed)
Say we have some piece of work, perhaps a new feature to develop. If a problem should occur with this feature, it is interesting to know how far along we got in the above flow when the problem was identified. It’s probably quite obvious that the more stages we’ve been through, the more work has been done. So the more stages we’ve been through before we identify that something is wrong with the result, the more work has been wasted, and the more serious we should be about figuring out why it happened. With me so far?
Using the above process as an example, finding a problem in the final stage is the least desirable. When the software has been deployed to production we’ve been through a lot of work, and it has also been made available to the customer. So any problem that is present has been exposed to the public. Depending on the nature of the problem, finding it this late in the process may also limit our ability to figure out what happened. If the problem is a technical bug, it’s easy to blame the closest stage related to technical stuff. In this case it’s stage 4, called “Reviewing” above. That stage was responsible for figuring out that the solution was technically sound. Let’s go yell at the guy who did the reviewing. Problem solved! Maybe.
Let’s say that we did find the problem in stage 4, so the reviewing actually worked as intended. The reviewer successfully identified a technical issue. Now what? Obviously someone in the “Developing” stage were sleeping on the job, right? Well, it could also be that the problem is related to insufficient analysis. The development done to implement the new feature may have been fine, but due to limited investigation of the rest of the system, a problem occurred elsewhere in the system. Software development is complicated stuff.
But what if the problem we found in production wasn’t technical in nature? What if the feature we released worked as designed, but it didn’t really solve the customer need? Then what? Obviously someone did a poor job during acceptance testing, but why was it wrong in the first place? The developer could have misunderstood the customer, thus solving the wrong thing. The reason could even be outside the entire process. The description of what to solve could have been wrong or incomplete all the way back in stage 1, when it was delivered to the development team. Note that even though the cause isn’t found within our immediate responsibility, we should actively assist those who can do anything about it.
Another interesting thing that may surface during such an analysis, is that the visualisation of the workflow is inaccurate. Suddenly you find that the problem happened in a stage somewhere in the middle, a stage that isn’t even on the board.
So what’s the point of all this? A useful map for a blame game? As you may have guessed, it’s not an exact science. It is however an interesting way to discuss what went wrong and why. And no, the point isn’t to find someone to blame, but to figure out how to get better. Any individual working in a process like the one above is likely to have good intentions. If something goes wrong while they’re “responsible” for a piece of work, the causes are usually a combination of many different things. A common misunderstanding when looking for root causes, is to be looking for the root cause. Look for as many causes (plural) as you can, and collaborate as a team to figure out what can be solved and improved both in the short and long run.
(also published at www.revio.no)
There are a lot of simple “life lessons” out there. When you hear one for the first time you may feel like you knew it already, you just never really thought about it.
I’ve decided to try to write short posts whenever I get some small revelation about something or other. Here is the first one.
I recently watched an interview with Larry Page and Sergey Brin, and something Larry said created one of those “Aha” moments. They were discussing wether he and Sergey had any fundamental disagreements during their time as founders of Google. Since they know each other well and have great respect for each other, Larry commented that
“(..)if we are disagreeing about something, it is probably because it isn’t obvious what to do”
When you think about it, that’s actually quite profound. During the heat of an argument, most people are quite convinced they are right. But if an argument is heated, someone else are equally convinced that you are wrong. So any time an argument escalates, it could be a useful red flag indicating that the answer probably isn’t that clear cut.
If someone you know and trust thinks you are wrong, chances are you’re at least not 100% right. So instead of butting heads (for too long), give them space to explain and elaborate their point of view. Acknowledge that whatever you’re discussing probably doesn’t have an obvious right or wrong answer, and you may need time and input from other people to come to a conclusion.
It’s time to let you in on The Secret. Don’t tell anyone, but “How long does it take” is the wrong question.
I planned for this post to be about statistics and how to calculate probabilites. Instead it turned into a rant, of sorts. You see, there’s another Secret buried here: If you really take the time to learn how to estimate risk correctly, this will help you learn the following fact about the outcome of your project: It is very uncertain. I guess that’s helpful. Sort of.
“That’s just baloney,” I can hear some of you say. “My projects are consistently on time and on budget,” you continue. Maybe so. Let’s examine the famous “project triangle” for a moment.
Ever wondered why it isn’t a square? Because quality is a result of the other three, some might say. “That’s just baloney,” you can hear me say. I think it’s because cost, scope and time is easy to measure and easy to adjust. Quality? We always deliver perfect quality! We are professionals! Let’s just put that in the middle, and hope no one pays too much attention.
You, the guy who screamed “We always deliver on time and on budget!” a moment ago. How about scope? “Hah! We delivered all the functionality as well! All the developers bitched about them having too much to do in too little time, but my project plan showed them wrong!”
That’s impressive. But even when we go to the painstaking length of figuring out the risk and uncertainty of a project PROPERLY – You know, with Statistics and stuff, not just, God forbid, guessing or anything – it still comes out as being very uncertain. So how come you can consistently deliver your projects on time, scope and budget? Your team don’t have much choice, do they? They have to reduce quality. Luckily for you, no one will notice until the project is over. And they couldn’t really measure it if they did. What IS quality anyway? Sounds like a made up word to me.
So what did I mean by “how long does it take” being the wrong question?
There are a couple of problems. First of all, what is this “it” that we are doing? When you start the project, odds are neither you or the customer knows what the end result is supposed to look like. You may think that you do, but you don’t.
If it is a waterfall project, the customer will say “This is what I want” while dropping the dreaded Complete Requirement Specification on your desk. Then you go away for three months with a team of developers to create whatever is in the specification. “Here is your product!” you exclaim with great enthusiasm when you come back. After the customer has tested it, she goes “Nope, that’s not it.”
If it’s an agile project, your team of developers only go away for maybe a couple of weeks at the time. Each time you come back and show a little bit of the product, the customer tests it and goes “Nope, that’s not it either. And where’s the rest?”
However you go about it, both you and the customer learn a lot DURING the project. Mostly what they don’t want. Needless to say, this process takes quite a bit longer than just doing stuff once. No one knows what done looks like until, well, you’re done. And please remember, we’re not BUILDING a product, we’re CREATING it. The first of its kind. Your developers aren’t packing meat in boxes along a conveyer belt, they’re freaking SCIENTISTS! So stop pretending you are a production facility. The product you’re creating has never been built before. If it has, please go and buy that instead.
And that’s not even half of it. What did you say were doing again? A project, right? Well, most of the time we’re not really creating projects, we’re creating PRODUCTS. The funny thing about products is that they don’t end when the project ends. That’s kind of when they start. In terms of cost, that means roughly 90% of the total cost of a product comes AFTER the initial release. Maintenance, bug fixing, additional development, paying back technical debt, people spending most of their day swearing over how horrible it is, and so on.
Here’s the Third Secret: The less time you spend on quality during the “project” phase, the higher the total cost of the product.
So whenever you pat yourself on the back for delivering “on time” (usually a random point in time decided by anything except the actual amount of work that needs to be done before that date), that probably means you have reduced the overall quality of the project, and increased the total cost of the product you delivered. That doesn’t really sound like back patting performance, if you ask me.
Did you think this series of posts would culiminate in How To Estimate Accurately In 3 Easy Steps? Well, it sort of didn’t. If you’re still looking for that guide, you should probably read “The Flaw of Averages: Why We Underestimate in the Face of Uncertainty” by Sam L. Savage.
I’m not sure it will make your estimates more accurate, but at least you’ll understand why.
On an intellectual level, everyone understands that communication is important.
And everyone in a company is working together with someone else, unless it is a one man company. So without communication, nothing much would get done. Stating the obvious, right?
A recent NTNU (Norwegian University of Science and Technology) Master Thesis concluded that (paraphrased):
“Allthough all organizations think that good communication is vital in order to run projects in the direction of their organizational strategy, most do not have the desired communication systems, culture or skills(..)”
Surely that doesn’t apply to your company. You guys spend lots of time making sure everyone understands what to communicate when, and to who. You naturally share all relevant information to as many people as possible, in a way that makes sure the original message is preserved.
I’m sure that you always make sure that “what is relevant” isn’t defined to tightly, and terms as “on a need to know basis” are generally frowned upon. Informal communication is always encouraged in order to build an environment where anyone will continously voice their intent, their understanding, their worries and their questions without fear of repercussions. Right?
And your managers always make sure everyone involved knows where the team is going and why. When someone does something that is not aligned with the overall goal of the company, they do not blame the individual. They ask “What piece of information did this person not have, and why?” or “What has this person not understood, and how can we help this person understand it better in the future?”
Did I just describe how the concept of information flow works in your company?
I recently had a heated argument with a couple of our developers. They were creating a new module in one of our systems, and were building the UI based on a screenshot from a designer.
Developer: “Here is what was auto-deployed to the development server last night. As you can see it is a somewhat working prototype.”
Me (After picking on several aspects of the design): “..so I guess we’re pretty far away from anything I can show the customer.”
Developer (groans): “As you can see, it’s perfect and doesn’t need any tweaks..”
Me: “Well, were you looking for feedback, or did you just want me to compliment you on your CSS skills?”
Developer: “I was after feedback, but I am allowed to be grumpy when I get it. So, if we change the stuff you mentioned, can we move on to the admin part after that?”
Me: “If we present it like this, we’ll be thrown under the bus. I need it to be as close to the design screenshot as possible. Now that I’m looking at it again, I’m actually worried even that won’t be good enough.”
Developer: “Seriously?! Well, God. I need a timeout. Give me two minutes to grab another coffee..”
After a lengthy discussion while looking at some state of the art, jaw dropping design templates online, we all realize that we haven’t been aiming high enough with the new design. I’ve been giving them a hard time for maybe thirty minutes, even though I know their job isn’t easy. We’re hard pressed for time, and I know I’ve said the functionality is more important. But I also know that the current design simply won’t cut it. I try to calm things down.
Me: “I know I’m being harsh here, but I needed to get the message across.”
Developer: “So, if we don’t even think the design from the designer is good enough, why do we spend time implementing it? I don’t even want to do it anymore after seeing how much better it can be done.”
Me (pointing at one of the crazy designs we checked out online): “I hear you, but can we even do anything remotely like that?”
Developer (looking straight at me): “We can do anything!”
“Most people fail in life not because they aim too high and miss,
but because they aim too low and hit.”
(This is part #2 in my mini series of blog posts about estimates. Part #1 can be found here)
With the help of detailed analysis, an experienced developer may figure out the most likely outcome of a project. But exactly HOW likely is the most likely outcome?
In the previous post we were forced to guess the duration of a project, and ended up guessing the project would take 300 hours. As a side note, the result after detailed analysis will probably be quite close to the same number. This is known as anchoring. In order to keep each post relatively short, we will save that for another post.
Let’s assume you’re given time to do a detailed analysis of the proposed project, consider the risk and are provided with a “complete specification”. You spend maybe half a day thinking about it, jot down some detailed estimates, and add them all together. The total sum is 290 hours, and you figure that to be the most likely outcome of the project. Your assumption may be exactly wrong for any number of reasons, but for the sake of argument, let’s assume you’re actually correct.
You have now figured out that the project will most likely take around 290 hours. But exactly HOW likely is it that the estimate matches the actual end result? 60%? 80%? You may be surprised to learn that the actual number is probably quite a bit lower than that.
Above illustration represents the actual outcome of 42 Norwegian projects from several different companies. (Magne Jørgensen / scienta.no)
Let’s say you have historical data from several past projects, telling you both your estimated, most likely outcome, as well as the actual outcome. If you put them in a graph with the x-axis representing the actual effort in percent of the estimated effort, and the y-axis representing the percentage of the total number of projects, it would probably look something like the graph above. Confused yet? Let me explain that again.
The highest bar in the above graph is the one marked “100” on the x-axis, and the value of that bar is around 33. That means that roughly 33% of the projects were completed on the estimated time. Since it’s the highest bar, being on time appears to be the most likely outcome. The next bar to the right, marked “125” on the x-axis, indicates that a little over 15% of the projects actually spent 125% of the estimated time, and so on.
So why do you care? Because it sheds light on what “most likely” really means. And it may not be what you think. Actually, our most likely outcome (hitting the estimate spot on) is NOT very likely to happen. Yes, it surely is more likely than any other individual result, but it is LESS likely to happen than all the other results combined. We actually have a whopping 67% likelyhood of NOT hitting our estimate, even though (due to some unknown miracle) our estimate is the most likely result of all possible results.
To make matters worse, the combined likelyhood of the bars to the LEFT of the 100% bar (representing actual outcomes that were lower than our estimate) is only about 7%. So we got 33% likelyhood of hitting our estimate, and 7% likelyhood of being below.
If you provide your boss with your “most likely” estimate, you will in this example leave him with a 60% chance of blowing the customers budget.
I’ll leave you with some time to think that through. Part #3 of this mini series can be found here.
I know a whole bunch of developers in different companies and different businesses. What they all love most about their jobs, is when they are asked to produce an estimate. It’s the highlight of their week!
You’ve had a creative discussion with your boss and perhaps a couple of representatives from the customer. It’s all fun and games, until your boss turns to you and asks The Question.
“So, how long does it take?”
Did he just do that? In front of the customer, no less? How on earth are you supposed to answer that reliably without any time to analyse the details? You venture a somewhat vague answer, even though you know it’s no use.
“Hm, perhaps somewhere between 200 and 400 hours?”
“What does that mean, between 200 and 400 hours? Just give me a number!”
“Oh, uhm, I guess around 300 then?” you reply desperately, automatically reaching for the average of the first two numbers you threw out there. Surely that can’t be too much off?
Any one number representing a possible future outcome of something, will never be anything except just that. One possible outcome. That means somewhere out there, you’ve got a whole bunch of other possible outcomes as well. So If you say it might take 200 hours, without the backing of additional data, the chance of it taking more or less is about 50% either way.
So you’re giving your boss a definite number based on your guess on the outcome of something, without any information about other just as likely outcomes. Does that sound like a useful number to you? I didn’t think so.
Estimates are usually needed to figure out wether to invest in something, and to set a budget. If you give me a number where it’s a 50% chance of me blowing my budget, then I’d say you’re not really helping me over here. It’s heads or tails wether I’m in trouble with the customer for overspending. So when I ask for an estimate, it’s implied that I need a number that isn’t very likely to be too low.
So if your boss (or your customer) insists on getting that one number, what to do? First we need to understand more about the problem of “just give me a number”. More on that in part #2 on this mini-series about estimating!