Tag: Trust

Earlier, we talked about how busyness works against agile & lean.  Today, we’ll look at how to replace busyness with value delivery (the heart of agile & lean). Given that busyness has been framed as the enemy, you may be thinking:  That sounds great, but there are still salaries being paid and clients expect results; if I’m not making sure everyone’s time is fully utilized, how do I make sure we’re adding value? The first problem that needs to be overcome, is that you may be confusing busyness with value creation.  It is true that to deliver value, you must do something.  It is not true that by doing something you’re delivering value. To even talk about value delivery, though, we first need to know what “value” actually is to us. To start understanding, let’s borrow some wisdom from the great entrepreneur, David Packard  I want to discuss why a company exists in the first place. In other words, why are we here? I think many people assume, wrongly, that a company exists solely to make money. Money is an important part of a company’s existence, if the company is any good. But a result is not a cause. We have to go deeper and find the real reason for our being. As we investigate this, we inevitably come to the conclusion that a group of people get together and exist as an institution that we call a company, so that they are able to accomplish something collectively that they could not accomplish separately – they make a contribution to society, a phrase which sounds trite but is fundamental – David Packard In short, companies don’t exist to make money.  Companies are created to serve some purpose and in doing so they make money.  Making money means they can keep fulfilling that purpose (or do more of that purpose if they make a lot of money).  You can think of money in a company as acting like blood in your body.  You need blood to stay alive, but you don’t live for your blood.  Likewise, your team does not exist to write code.  Your team writes code in order to serve some greater purpose. Challenge Why does your software delivery team exist? If your answer includes the phrase or idea “writing code” (or anything like that), then you’re missing the point.   YOU ARE NOT WHAT YOU DO WHAT YOU DO IS NOT WHY YOU DO IT If all you understand is what you do, then you will never get beyond busyness; merely doing more stuff to stay busy.  Unfortunately “what” we do is the most obvious thing about us.  We see developers write code.  We know how to write code.  We’re trained to write code.  When people ask us what we do (which they always do), we say we write code. It’s absolutely true, that is what we do. Because this is such a simple thing to observe and understand, it begins to become the default way in which we view ourselves, our role, and if we’re not careful it becomes our purpose.   It is not enough to be busy. So are the ants. The question is: What are we busy about? -Henry David Thoreau If you want to get beyond busyness then your first step, which may be very uncomfortable, is to find out why your team exists. Discovering Why If the answer is not obvious, there are a few things you can try to get at the answer. The easiest thing is to just talk to everyone and look for a unifying purpose or motivator. If you want to make it a more interactive experience, then bring your whole team together.  Give everyone an index card and have them all write down why they think the team exists.  Collect and shuffle the responses.  Read them aloud and have a conversation to find which idea, if any, the team generally agrees as being why they exist.  Not only will you (hopefully) arrive at a purpose, you may learn a lot about why disagreements and conflict exist on the team.  If people are applying different values to evaluate the same opportunities, then they may be talking past each other and seeing the other person in a negative way rather than understanding that it is a difference in the values being applied rather than a real difference of opinion about the opportunities. Hopefully something emerged organically in that talk.  If it didn’t (or you don’t feel comfortable running that game), you may need to reverse engineer your team’s purpose. Consider your current trajectory (look at your backlog).  What launched you in at direction?  What problem were you trying to solve?  What opportunity were you pursuing?  For whom is this intended?  If anything appropriate comes out of that, then embrace it.  Now you can stop assuming that your current trajectory is the right way forward and you can start looking for new ways to better fulfill your purpose. Still have nothing?  If you can’t find a singular purpose, then it’s up to you to create a cause.  Sound silly?  It’s not.  Consider the custom software company Menlo Innovations out of Ann Arbor Michigan.  There is no one client.  There is no one industry.  There is no one technology.  So why do they do what they do?  To put it in their own words, Our mission as an organization is to end human suffering in the world as it relates to technology™. What does that mean?  They try to make the creation and use of technology a joyful experience for their team members and their clients and their clients’ clients.  That’s a purpose that doesn’t depend on industry or technology.  So how would a Menlonian (their word for themselves) evaluate a project as being worth doing?  They don’t take work to be busy.  Since they strive for a joyful experience, clients need to want the same thing.  The client must be willing to work with Menlo in a way that is respectful to the Menlonians.  The project must allow the Menlonians the latitude to create a solution that helps end human suffering as it relates to technology, which means letting Menlo take the time to deeply understanding the problem the client is solving rather than doing what the client says they want.   Will that “why” work for you?  Probably not.  But it doesn’t matter what your “why” is as long as you have one and your team can understand and rally behind it. Start with Why Once you’ve discovered (or created) your “why”, start talking about it.   Make it something you talk about regularly. Put up posters. Put it on mugs. Buy t-shirts. Buy stickers. Make it visible. Make sure it’s known by everyone. Why is that helpful?  It gives everyone on the team a frame of reference from which every decision (big or small) can be evaluated.  It gives you a way to prioritize a backlog that is tied to values rather than just dollars.  It gives you a way to evaluate future team members.  It gives future team members a way to evaluate you.  It gives you a way to evaluate clients.  It gives potential clients a way to evaluate you. There is a vast amount of dialogue that could be had on this topic.  More than can be covered in this article.  If you want to go deeper (you should) then visit https://www.startwithwhy.com/ and get Simon Sinek’s book by the same name (Start with Why).  Once you understand the power of this way of thinking, it will help you to break free of busyness and deliver value in a way you haven’t ever done before. Reflection Knowing why is more than just a way for the team to look at the outside world, it should be a way for the team to look at itself.   How does your team measure success? If a team values unwavering predictability, then perhaps up-time will be a key metric.   If a team values saving their clients’ time, then perhaps each sprint they’ll calculate the number of yearly-human-hours of manual effort they’ve removed from a process and judge their success on that number.   Both are good, but only if they align with your purpose. As a question, “How do you measure success?” is a trap if you don’t know your purpose.  How can you measure being successful if you don’t know what “success” is?  Once you know what you value, you can figure out what success looks like, then you can figure out how to measure that.  Once you’re measuring it (if you’re into that), you can make sure you’re being true to your purpose. Prioritization The most precious resources we have are our time and creativity.  Teams prioritize backlogs to make sure that these limited resources are applied to things that will deliver the most value.   If I can’t measure how many dollars will be returned by something in our backlog, is it worth doing?   I’m not sure.  Against what standard are we evaluating it?  Not knowing the dollars only matters if our purpose is to make dollars.  Dollars are something we need, but it’s not why we do what we do. Knowing how we evaluate our work gives us a way to consistently prioritize as a team.  Even if the entire team does not prioritize the backlog, every day every team member is making decisions about where to invest their time and mind.  By making sure everyone understands the values and can prioritize on their own, then everyone will be making the investments that will maximize the value created by the team.  Those decisions may be about the backlog, which meetings to attend, who to talk to, what to document, how to engineer a solution, or almost anything else in their day.  In other words, it helps us to follow the agile principle 10. Simplicity – the art of maximizing the amount of work not done – is essential. In lean terms, getting rid of all this busyness helps us work down all 8 wastes (at least, it stops exacerbating them).  It’s also helps us to understand which things we do that add value, and which things don’t.  In turn, that means we work to create a process that maximizes the output of whatever it is we value and stop doing things that don’t contribute to our values. How does starting with “why” help us to get rid of non-value added tasks?   By aligning decision making.  There is no better way to ensure that distributed decision making is aligned than to make sure everyone is using a shared value system.  Once everyone is using the same values, you can have much more confidence in the decision making of each individual.  That makes it much easier to embrace the agile principle  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. Starting from where we are, how do we establish a shared value system? Start with why.