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.
“In Scrum we <insert Scrum practice here>, would we still do that if we switched to Kanban?”
Occasionally I’m approached by people curious about Kanban, and more often than not they are already familiar with Scrum. They may have read some brief blog posts about Kanban, but are left wondering what it’s really about. What are the rules? What do we have to change? Can we still do Scrum? Help! So I decided to write a blog post looking into some of the stuff you would usually be doing in a Scrum team. Would you still be doing it if you were doing Kanban, or would there be an alternative approach to achieving the same goal?
“In Scrum we divide our project into sprints. I’ve heard that you don’t do that in Kanban?”
The answer to this is, it depends. Many teams find it useful to establish a regular delivery cadence to either test or production, while others deliver when it makes sense to do so. The general rule is, the more often you deliver value to the customer, the better. The biggest difference is that with Scrum, all the practices (planning, retrospectives, releases) are tightly coupled to the sprint. With Kanban it is 100% decoupled, and everything is optional.
“I heard that with Kanban, you don’t do estimates. How does that work?”
There are no rules in Kanban explicitly saying that you can’t do estimates. In many situations it will make sense to do some form of estimating up front, or during a project. If feasible in your setting, we would however prefer to focus on what is important, and the assumed cost of delay . What would it cost us either in direct cost or lost revenue to NOT do this task now? In 3 weeks? In 3 months?
“I attended a conference once, and some weirdo on stage claimed we shouldn’t prioritize items in our backlog?”
In a large project you may well have tens, or even hundreds of individual items in your backlog. For the sake of argument, let’s say you have 50 items. To follow Scrum, you need to order all 50 items according to priority. This is typically done several times during the project, maybe as often as once per sprint. Let’s say that you on average deliver 5 items per sprint. So in reality, for any given sprint it adds little (no) value to order anything below the top 5 items in the backlog. In Kanban we prefer to ask our product owner “What is the most important task(s) for you right now?”. Answering that question is usually easier (and faster) than ordering 50 items.
“In Scrum we have a Scrum Master. Is there such a thing as a Kanban Master?”
In Kanban we recognize the fact that change is hard. People naturally resist anything that threatens their identity. Asking people to change their professional roles would do just that. When implementing Kanban, everyone involved keeps their current roles and titles. There are no formal roles. A basic principle is “Start with what you do now”.
“In Kanban you apparently have a board to visualize tasks, like we usually have in scrum?”
Yes, but with one crucial difference. Scrum has a lot more formal “rules” than Kanban, but they’re missing one – and it’s an important one. Limit Work In Progress. In Kanban we define a workflow, and we limit the work allowed in each state. As a result, we implement a pull process. Whenever there is room for more work in a board column, more work can be pulled from an upstream state (typically to the left on the board). Limiting WIP and pulling work prevents overburdening, reduces multitasking, decreases lead time (the time it takeS from we start something until it is finished) and increases flow through the system. It will also quickly uncover flow problems. If an item is impedimented for some reason, it will quickly stop or limit the flow of the entire system.
(illustration below stolen from Henrik Knibergs excellent post One day In Kanban land)
“That answered some of my questions, but I’m still a bit confused. What are the RULES of Kanban?”
I’m not sure there is an answer to that. Kanban is a management and change management technique that require some time to fully understand. There are few explicit rules as to exactly what to do, but Kanban will help you figure out what works for you. There’s no one right way, the context of your situation is always unique. Does it make sense to always have sprints with a committed list of deliverables? Probably not. Does it make sense to have stand up meetings? Probably, but maybe not every day in any context. Does it make sense to have a retrospective after each delivery? Who knows what’s right for you? Only you.
“So are there any rules at all?”
We have what we call principles:
- Start with what you do now (No set rules or processes. Start from where you are, and improve from there)
- Agree to pursue incremental, evolutionary change (Make a small change, see if it is an improvement, then try another)
- Respect the current process, roles, responsibilities and titles (Don’t manage by fear and force, build trust and understanding. Respect persons and identities)
- Leadership at all levels (Delegate, build trust, encourage acts of leadership at all levels of your organization)
And six core practices:
- Vizualise the workflow (Without understanding what happens, it is hard to implement change)
- Limit work in progress (Implement a pull system, typically a kanban system)
- Manage flow (monitor and measure how work flows through the system, in order to detect problems and opportunities for improvement)
- Make policies explicit (Document how the system works, thereby creating a common basis for understanding and improvement)
- Implement feedback loops (Regular collaboration and review at both team and company level is important to facilitate continous improvement)
- Improve collaboratively, evolve experimentally (Involve and inspire everyone to suggest improvements, and experiment to validate theories)
If you are ready to dig deeper into how Kanban may help you and your organization, I suggest you start by reading: “Kanban” by David J. Anderson
Now you may proceed with your day, I wouldn’t want you to miss your daily Scrum!
The guys in the agile community have been writing, talking and moaning about estimates for ages. “Accurate estimates are impossible! What’s the point? Let’s stop estimating, it’s just guessing anyway!“
Let me try to explain.
We all agree that we’re basically guessing, right? That may be the case, but if you live in the real world, you actually sell stuff for a living. In order to sell stuff, you need to have customers. And what’s the problem with customers? They usually demand to know what something costs before it’s produced. Go figure. Anyway, that means we need to estimate wether we like it or not.
A rough estimate from a developer or architect is usually the basis for a fixed price offer. If the estimate is good, you’ll make money. Sometimes it’s not, and then you’re up shit creek. If bad luck and an inexperienced developer team up, rough estimates can be several hundred percent off the mark. So why do we keep working like this?
The big problem with this transaction is trust. The customer rarely trust the software company enough to pay for a project by the hour. The history books are full of dishonest companies who have destroyed the trust in the IT industry. Now we all have to work hard in order to regain that trust. You need to convince each and every customer that you actually want to add value to their business by creating great software. That’s what we’re all about. Right?
If you gain enough trust within your market, I strongly suggest that you attempt to operate with budget limits instead of a fixed price. Agree on a minimum scope, and explain to the customer that you will do your best to include as much functionality as possible within the budget you have agreed upon. This way you reduce the risk on your end, and the customer doesn’t have to pay for the built-in risk premium of a fixed price. A better deal for everyone.
Great stuff, happy campers all around! Now we can stop estimating and focus on real work.. But wait a minute. How can you (or the customer) know wether the project will be worthwhile? How do you establish a reasonable budget? When presented with the required time to market, how can you tell if you will be able to deliver on time? You guessed it, by estimating. Seems like there’s no way to win this game.
To make matters worse, the game changes as you go along. As your company grows, your development process will change. You add quality assurance, you add a project manager. Your team grows, and suddenly lots of time is spent talking about how to do stuff instead of actually doing it. Challenging SLAs means more time spent on release management and server maintenance. The environment surrounding your team changes all the time, and the correct answer to “how long will it take to..” changes with it.
At the end of the day, an estimate can never be more than an educated guess. But fear not, all is not lost: If you manage to build a team with focus on quality, keep the turnover low and maintain a stable, honest environment with room for making mistakes – you might just end up with a bunch of guys that are amazingly good at guessing.