Tag: Why

The ‘Why’ of Scientific Development

Can we use our backlog for professional growth by tracking and talking about what we want to learn? Stories are nice, but… As an agile coach I’ve spent a lot of time teaching and helping people practice writing stories in the classic format “As a […] I Want […] So That […]”. The virtues of this format are well known, so I won’t waste words there. But, what about the shortcomings? Keeping Busy Because stories represent conversations, they’re intended to defer discovery until the last possible moment. However, classical thinking still demands that we think of them as deliverables. Once we begin down that road, it can be very easy to begin treating stories just like a queue of work to keep people busy. We’re not comfortable with uncertainty, so we research everything then write and estimate stories for projects upfront. Roles and teams get put in place to ensure that the stories are written, vetted, and prioritized with enough of a buffer that the engineering team never stops coding. In planning, we question whose best suited to get work done so the most value is being delivered. After all, we want our velocity and utilization to be high. We optimize ourselves for speed and turn ourselves into a small team of specialists. You Get What You Optimize Those outcomes aren’t accidental. They are a direct outcome of trying to optimize a system to maximize the utilization of a limited resource (team member time). We want to keep them busy. Unfortunately, optimizing to keep everyone busy, makes it very hard to manage other aspects of our work. Are we doing the right things? Are we doing them the right way? Are people growing? Of those, concern about team member growth is the biggest miss. Most companies know this already, and to fix it they add team member development as a separate activity. Every year there is a review. In many companies, every few weeks there’s a one-on-one meeting between the team member and leader. These are the forums for facilitating growth. Ironically, as we make headway with iterative delivery and agile practices for our work itself, our people development is still firmly rooted in a waterfall-like annual cycle with few feedback loops. A Backlog of Growth & Learning Opportunities What would it look like if our backlog wasn’t a list of things to do? What would it look like if it was a list of things to learn and ways to grow? What would it mean to our organization if leaders were prioritizing and discussing opportunities for team member growth rather than deliverables? These are the questions that led me to propose the idea of scientific development. Read On The ‘What’ of Scientific Development The ‘How’ of Scientific Development The ‘Who’ of Scientific Development

Knowing why OVER knowing what

What does it mean to know why over what? What I do A focus on “what” we do creates many problems. It’s easy, though. It’s the first thing that comes to mind. I write code. I test. I gather requirements. I manage projects. Unfortunately, when we do this, it’s easy to lose sight of why we do it. You’ll notice this when project managers take people off the floor for hours (or days) to get the plan perfected. They’re so focused on what they do (manage the plan), that they inadvertently take too much time and attention away from value delivery. The client doesn’t want a plan. We will use plans, but the value we’re delivering is software. 7. Working software is the primary measure of progress. This isn’t a project manager problem; it’s a human problem. Engineers may try to sequester themselves for weeks to perfect something because “what” they do is write code. They see all those client conversations as waste and don’t want their skill to be called into question if there’s a defect. Clients want problems solved and value delivered today, not something perfect years from now. 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. We could harass analysts and testers as well, but hopefully you get the point. Thinking about what I do is a distraction from our real purpose. What To Do Too often teams have a backlog of solutions awaiting engineers to simply write the code. This is a symptom of an organization built around “what we do”, but the practice can exist in other environments. A focus on “what needs to be done” is destructive. It makes the assumption that we understood the problem when we wrote down an answer. It assumes that the need and the tools won’t change between writing the answer and implementing it. It assumes, that those designing the solution know the right architecture better than those implementing it. It assumes that the engineer has no creativity to bring to bear. It assumes we don’t need to work with the client anymore, we already did. It assumes we won’t learn more about the solution as we go. We should. 11. The best architectures, requirements, and designs emerge from self-organizing teams. The key concept here is emergence. If we focus on what to do, we will be anchored on a particular solution. Our goal should be tapping into our collective talents and creativity to arrive at the best possible minimum solution. No matter how smart or creative the person who wrote the solution, a team of skilled and creative people working together will create a better solution every time. By focusing on why we are doing the work (the problem that needs to be solved), we invite collaboration. We invite creativity. We invite better solutions. Using Why It can be hard to focus on “why” over “what”. It’s easier to “just write code” or “just manage projects”. Worst of all, the constant focus on “why” can turn into a tireless process of always questioning everything. To be successful, you need to get more comfortable with this. But there are some simple steps you can take. The easiest, is to start practicing writing and working with user stories. These are a good way to think about why we’re doing things to invite a discussion. As to what we do (our actual role) and how we invest our time, there is no easy answer. Always ask yourself if what you’re doing is adding he most value to the client of all the options in front of you. The horizon for this measurement should also be near term; today, this week, this sprint. That’s it. If what you’re doing is adding the most value for six months from now, you’re doing it wrong. Challenge Is what you’re doing today the most valuable thing you can do for the client? Are you doing the work you have because it’s your role, or because what you’re doing is contributing client value? Is there some other role you could take on, some assistance you could offer, or something else you can do that would deliver more value to the client than you are today? Why do you do what you do?

Why Manifesto

Because people in software like “manifestos”, try this as a litmus test for the decisions to make sure you’re thinking about value and not just staying busy. As in the agile manifesto, the things on the right have value, but not as much as the things on the left. Working WITH clients OVER working FOR clients Knowing why OVER knowing what

The Why of Lean

Conventional lean tools include timing a process and tagging each action as value added or waste. That may work in a factory, but not in software development; or can it? The same precision and clarity is not possible in a knowledge industry. You cannot apply a stop watch to mental problem solving. Sometimes getting away from the keyboard for an hour is the most valuable thing you can do. Few (if any) six sigma black belts will put that in the value added column, but maybe they should. There are a few problems with this technique, but they stem from confusing a lean tool with the purpose of lean. Client Value In lean, being able to categorize tasks as value added or not relies on a value stream. We know what the end client wants, so we can see if each second along the way is contributing to that want. The purpose is to make sure we’re only investing energy into what is adding value. The stopwatches are just a tool to support that goal. At a basic level, this “knowing what is valuable” is what software teams are establishing when they start with why. Once they know that, they can evaluate each deliverable (or task) as helping that cause or not (adding value or not). Again, this is to ensure that the energy they’re investing is delivering value. That may seem much fuzzier than lean manufacturing, but it’s actually the same. The difference is what you’re not seeing in lean and what is ignored by many software delivery teams. The Why of Lean In lean manufacturing, we see and talk about assembly lines, plants, and other artifacts as being what lean is. We see the lean experts and plant tours as representing lean. True, lean principles are made quite visible there, but this is not where lean starts. The best lean organizations aren’t just lean for lean’s sake. They have a purpose that transcends what they do. They have a why. Take the example of Toyota North America’s purpose: 1. As an American company, contribute to the economic growth of the community and the United States. 2. As an independent company, contribute to the stability and well-being of team members. 3. As a Toyota group company, contribute to the overall growth of Toyota by adding value to our customers. Notice that it says nothing about designing, making, or selling cars. Cars are somewhat irrelevant for fulfilling Toyota’s purpose. Cars are a great way to support the Anerican economy, communities, team members, and the parent company. Toyota has a purpose that has nothing to do with “what” they do. Now being lean in manufacturing is less about saving money, it’s about making sure that the purpose is fulfilled and not wasting time waiting and not wasting money on inventory is a good way to better fulfill that purpose. With that clarity, all of the decisions and activities that precede and support the plants are also improved. It is this part of a wholly lean operation that is oft ignored. Clarity of purpose helps ensure decisions are aligned to supporting the cause Should we lay people off and save money? That would be harmful to community, and destabilize team members (even those retained). Unless absolutely necessary to survive, no, we won’t lay them off. Should we open this plant? Maybe. It would help that community and America. It could offer new opportunities for team members. Primarily, we just need to make sure it will add the most value to our customers of all investments we could make. It is at this level of strategic investment that software delivery teams, even very small ones, exist. Software delivery is a creative process. They must make sure their investments are aligned to a greater purpose. Every deliverable a team begins is a strategic investment. The team must make sure that the deliverable is the most value added thing they could do with those minutes if the team wants to be truly lean. This is just like Toyota deciding whether the best investment it can make to fulfill it’s purpose is a new plant. The Lean of Software Delivery When software folk talk about lean operations in software delivery, they often talk about how the work is non-repetitive, cannot be scripted, is very creative, etc., and so this “lean” stuff doesn’t apply. There are a few problems with that. The first, is that the lean stuff certainly applies and in a hundred ways. There are repetitive aspects to software delivery that deserve standards and structure. But, the idea of timing software engineers like line workers is ridiculous. Or is it? If our delivery teams are deciding the investments and making strategic decisions like the lean leadership at Toyota, then who are the laborers we could time in our system like factory workers in lean? The users of the software. They clearly have a structured and semi-repetitive job. If not, software wouldn’t work. Some things they do add value to their client and some don’t. The software may help with this, but the principle remains. If you want to apply all of the lean six sigma skills employed at a factory, apply them to the users of software. If you want to help a software delivery team, give them the output of that client analysis, but when prioritizing actions to improve the client process, remember to prioritize based on why.

Why > Busy

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.