Sven Malvik – I’ve written thousand of lines of code based on lies, lies I hoped were the truth. The truth is that we make false assumptions. Assumptions that kill our business. I’ve built software that was too expensive, I’ve built software nobody wanted, and I’ve built software that never saw the light. If you are like any other developer you probably have lied too. But it doesn’t matter. What matters is the application we haven’t built yet and that we will build based on the truth. We need the truth to create value and to survive. This article will show you 4 ways of how DevOps teams create value.
Focus On Values, Not Solutions.
When you pitch a product to your users, they don’t care about its features, they care about problems and how you solve them. Users often don’t need a high quality product. Often they don’t even want the product we build. We build features and products based on assumptions. And after we have release a new feature our only concern is it to keep that feature alive through so we fix bugs, we maintain. We need to start to look at the values first, then on its solution.
We, the stakeholders should define the value of a feature already at the time we define all of its other requirements. Creating value actually is our only requirement. All the requirements we naturally set are features that at the end should result in value. Value that makes our business better and greater.
Defining requirements means to write down what we want to achieve in a way all of its stakeholders understand its value. How do we do that? We all know user stories. That’s what we’ve learned and practiced for years. Now, I will turn it around. Instead of writing user stories I will make stakeholder stories. Stakeholder stories that focus on value. You will find more information about stakeholders and value on my website sven.malvik.de.
How To Write User Stories.
Let’s start with an example we all might have heard before or have heard in a very similar way: “As an user, I want to be able to confirm payments easier and faster without clicking through the menu first, because it saves me time.”. This user story focuses on the feature itself. The value, saving time, comes second. Let’s now turn it around and see how the value becomes more visible.
How To Write Stakeholder Stories.
Stakeholder Stories focus on value first: “Our system saves the user money. They will have the full overview and a quick access to their payments at all time. With a single click, they can get an immediate overview of their unconfirmed payments and so confirm them. They can feel secure because they will always pay their bills in time and they won’t need to pay any extra fees due to late payments anymore.” How does this sound? The first time I read a stakeholder story like this it made me think of how can I make sure that I’ll meet that target, delivering value. In the past I focused on the implementation of a feature. I focused on solutions, not values.
Define Measurable Values
We need to define measurable values. Take our stakeholder story and take a look again. “Our system saves the user real money”. It is short and concrete but not precise and not yet measurable. “The system saves the user real money because the user won’t need to pay any extra fees due to late payment”. This can be measured if we look at how much fees due to late payments our users paid before the change compared to after the change.
Jess Humble said:
Everyone involved with a product is responsible for determining value, ways of measuring value, and how to establish feedback loops.
Measuring how much money our users save is important to know but it is not enough because the answer to it will come much later when our users have used the new solution for a couple of weeks. Fast feedback is important so we can change the direction quickly and being agile :). “With a single click, they can get an immediate overview of their unconfirmed payments”. The time that the user spends navigating from the first page to the page for unconfirmed payments can also be measured and integrated as part of a delivery pipeline.
Find ways to measure value. It’s not always easy to identify measurable stakeholder values. Keep looking. It is a valuable step towards better and greater business.
Connect And The Value Will Come.
Imagine that you are part of a team and you got the absolute power to put your own code into production. The only question “When to release” is being decided in coordination with the business. No handover, no waiting and no frustration will never ever cross your way again.
When you work for a smaller company, that might be already the case. But when you work for a large company like I do, you need to think about how you can fulfill that dream, being in control of your work, being trusted as someone important and having real responsibility. Achieving a dream often requires to constantly learn and show that you able to do it. Think for a moment of being already part of a trusted DevOps team with real power. How did you get there? And if you are not there yet, what do you think you need to do?
Everyone involved in a delivery chain from development to production should understand why a DevOps team is more efficient, more productive and releases better quality. To change the mind of many and doing a cultural change requires continuous learning. Without learning there will be no change and ergo no improvement.
Lev S. Vygotsky, the russian psychologist said:
Through others we become ourselves.
Your success depends on the people you know and the people you are connected to. Make continuously learning a habit in your organization. Come together and join sessions, do networking and exchange your thoughts. Then, there will be change to the better.
Embrace Freedom.
Be as agile as it motivates you and your team. Running pure Scrum or running pure Kanban or even running a mix of both worlds will make your team maybe only seem agile. The reality may be another. What does agile mean? Wikipedia states: “Agile software development … promotes adaptive planning, evolutionary development, early delivery, continuous improvement, and encourages rapid and flexible response to change”. The Agile Manifesto states: “Individuals and interactions over Processes and tools, Working software over Comprehensive documentation, Customer collaboration over Contract negotiation, Responding to change over Following a plan”. Simply spoken, being agile means being flexible and efficient.
The truth is, we are all human beings and we all have our individual preferences of working and how to get things done. Being flexible and efficient sounds great but that can’t be enough. People are not simple, we are complex. We, as part of a team, need to first understand how we can take responsibility and ownership in order to become flexible and efficient. My hope is that DevOps will change the way we think and work. The team must come first and second the way we work.
I’ve spent three years in a Kanban Team. I have learned that Kanban works great for repetitive tasks. You can change the speed of deliveries through adjusting the work in progress limits in all states. You probably know that already. But for a software development team that works on different tasks all the time, pure Kanban might be the wrong choice. Why? Because Kanban takes freedom. On some days I like to just pick a task where I know what I have to do. On other days I like to expand my horizon and grab a task that is completely new to me. Having this freedom makes me efficient. It also makes me flexible because I can switch whenever I want and whenever a task needs my attention. Scrum embraces this way of working, Kanban doesn’t.
In the beginning when I started with Kanban I enjoyed having less meetings so I could focus on my work. Later I realized that those team meetings are important. But not because your team comes out with a result at the end. It’s because team meetings hold teams together. They make the connection between team members stronger. It’s social to meet and it’s social to talk and discuss topics of all kind.
Don’t make your team work like in a manufacture. Don’t treat them like resources that can easily replaced. There will be no one taking ownership or responsibility otherwise. Focus on individuals and the team first and find the right balance between Scrum and Kanban and other tools. Embrace the freedom even if you sometimes need to break rules.
Create DevOps Masters.
Imagine you are working on an application fixing bugs and you suddenly stuck. You stuck and you need help. To come any further you need Francis, the key developer of your organization. He is the master and you strongly depend on him. Francis is a bottleneck for you because he is very busy and he can’t be there for you right now.
Bottlenecks are bad from our perspective because they prevent us from getting work done. But what do you think, how does Francis see the world? I think he feels great. Francis is needed because he has mastered something and he is important. He always knows what to do when his colleagues come to him and ask him for help or have any other questions. Francis is a master of his domain.
Developers like Francis take ownership because they feel that the people around need them. How can we build a team of developers were all of its team members are like Francis but without creating any new bottleneck?
How To Create DevOps Masters, Not Bottlenecks.
Have you read the book “The 7 Habits of Highly Effective People: Powerful Lessons in Personal Change”? Knowing how to create habits is one of the most powerful tools one can have. Creating habits basically means doing the things you want to master over and over again. Never stop and never give up, just do it. If we work on one and the same application for a very long time like Francis did, we will become very good at it. And when we are very good at something we love to share what we know with the people that acknowledge what we’ve mastered. We love to be needed, that’s human nature.
Today, we talk a lot about knowledge sharing. We say we don’t want to depend on each others. That’s basically true because when we don’t depend on each other we get things done a lot faster, we have no bottlenecks. But it also has some negative side effects. It prevents us from creating masters, masters that take 100% ownership and responsibility. When everybody can do your job, you are not important. You are only one resource out of many that easily can be replaced. Finding a balance between bottlenecks and masters may be a better solution.
There were two periods in my life as a developer were the whole team felt as masters, developers who cared about their work and took full responsibility and ownership of our applications. The first one was when we started with Scrum in 2008. The second one was three years ago when we introduced Kanban. We didn’t run them proper of course. We had a board with our tasks and we hold our Scrum meetings and set work in progress limits in Kanban. Our tasks as such stayed the same. They were big chunks. Sometimes one task took an entire sprint length of two weeks, often also two sprints to get finished. If you work long enough on one task you automatically become better than the others and you will automatically become the first contact of choice people approach when they need some help. I still feel 100% responsible for the application I build together with a colleague three years ago. We still care, we still feel being the owner of that application alone.
Today we want to be flexible. We split our task in small chunks of one day to 5 days. We make sure that every team member knows about most of the tasks, so everyone can work on every task. Being flexible means being replaceable and it is a bad way to prevent to create developers who really care and take responsibility and ownership. Don’t let that happen.
Conclusion
“How DevOps Teams Create Value” is meant to make clear that whatever we do, there is only one element that can come first, the people. Without them will be no value. However, solutions are important and fun and need to be discussed. Exchange your thoughts and opinions and become one great team.
