Modern Business Management: Creating a Built-to-Change Organization

© CA 2018

Doug Dockery and Laureen KnudsenModern Business Managementhttps://doi.org/10.1007/978-1-4842-3261-3_1

1. Agile?

What Does Agile Have to Do with running a Business?

Doug Dockery¹  and Laureen Knudsen²

(1)

Plano, Texas, USA

(2)

Escondido, California, USA

So what’s this Agile thing we keep talking about?

Agile is a mindset and a way of working together to get things done. It officially started in 2001 when the Manifesto for Agile Software Development ¹ was penned. It consists of a set of principles that define best practices for taking an idea and creating a product. These principles cover creating the right level of plans at the right time, ensuring quality is part of every step in the process, and admitting that change is a part of everything we do, so plan for change. Originally, Agile practices were specifically designed for software development, but they have since been scaled to all areas of a company.

Agile Manifesto? The Unabomber had a manifesto. You might be thinking that you don’t want to be part of anything that has a manifesto, but stick with us for a moment.

Agile, in its simplest form, is simply common sense. We have had customers tell us, on a fairly regular basis, that they didn’t want to do Agile. They seemed shocked when we told them we didn’t want them to do Agile either. Instead, can we agree that you would be okay with doing these things?

Working in small batch sizes

Getting done with things before you start something else

Proving that you are done and that you have created what your team committed to create

Taking responsibility and accountability for what you commit to doing

Working together and harnessing the power of your organization vs. that of a single team or individual

Constantly learning

Nobody has ever told us no. That’s Agile, though. It’s not some crazy, new-age process that involves granola and yoga. It means working in the simplest way possible and focusing on the value that we are creating.

If you remember, we defined value as making or saving money for yourself or your company. Agile, therefore, is simply removing everything that gets in the way of creating value and allowing teams of people to determine best how that value should be created.

Simple, right? It’s the simplest thing you will ever try to do, but at the same time, it is one of the hardest things there is to do well.

Agile Manifesto

In February 2001, 17 software developers met at the Snowbird resort in Utah to discuss lightweight development methods. They published the Manifesto for Agile Software Development, which you have most likely heard of by now. The manifesto is often written to be four bullet points, with a very important sentence to start the manifesto.

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

© 2001, the above authors

this declaration may be freely copied in any form, but only in its entirety through this notice.

When we were originally taught the manifesto, way back when Agile was new, it was the first sentence that was the meat of it: We are constantly striving for better ways of doing things (in the original case, developing software) by doing it and helping others to do it. This is the heart of agility, and it works as we bring Agile principles and practices into every area of our businesses and our lives.

Regarding the bullet points on the manifesto, although the secondary concerns were important, the primary concerns were more critical to success.

Please note that the manifesto says over. Many people misrepresent the value statements. People will say things like Agile doesn’t do documentation, or Agile doesn’t plan. Obviously both of these statements are untrue. The manifesto says that documentation is important, but working software is more important. The same is true for each line above: The second item is important, but the first one is critical.

What did the manifesto writers mean by these terms?

Individuals andinteractions: Self-organization and motivation are important, as are interactions like colocation and pair programming. The ceremonies in Agile practices are important because they bring people together and make them have discussions and gain agreements based on consensus. Stories were originally known as placeholders for a conversation. To best communicate ideas and requirements, conversations are far superior to written documents. That doesn’t mean we don’t take notes on what we agree to or include acceptance criteria so we know when something is done, but the conversation is never skipped in favor of a longer written document.

Working software: Working software is more useful and welcome than just presenting documents to clients or executives in meetings. In Agile practices, we have a definition of done so that when someone talks about working software, they mean it meets a certain level of completion, often including being fully tested, the application programming interface (API) is working, and it’s in a ready-to-consume state. Therefore, working software or completed work of any kind is much more beneficial to a company than a detailed written plan. This doesn’t mean we don’t plan—we do planning at the right time and increase the details of the plan each time we do it. Something will have high-level plans at first, but as it is ready to be pulled into an iteration or sprint it will be broken down and details will be fleshed out.

Customercollaboration: How many times have you created exactly what someone originally asked for, only to be told that wasn’t what they really wanted? Agile works to deal with these types of recurring issues. It is assumed that requirements cannot be fully collected at the beginning of the software development cycle, therefore continuous customer or stakeholder involvement is very important. Plans will be updated. Designs will change as we see the results of the initial work. If you do custom work, the contracts with your customers must allow for this, especially if you are using iterative wireframing, iterative prototyping, or other current methods of design. The way we do business is changing to acknowledge and allow for these changes to initial requirements and designs—even contracted and custom work.

Responding tochange: Agile methods are focused on quick responses to change and continuous development. Because we know plans always change, we plan for these changes. No longer do we require heavy change control processes. We acknowledge that every plan will change, so we can develop good enough plans and start working them, knowing we can modify them as we go along. There are very few instances where this cannot happen today—and many of these instances are due to regulations.

Use logic when deciding the level of commitment to these practices for your organization. Be part of the discussion and don’t allow your execution teams to convince you that the things on the right in the bullets are not important or required in Agile practices.

Agile Principles

The Agile Manifesto is based on 12 principles,² and although these principles were originally written specifically for software development, we discuss them in a manner to show you how they can apply to any work.

1.

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Deliver as frequently as your market will allow. If you are still delivering your products on-premises, your release cycles might be longer, but include your customers in design reviews, beta programs, and reviewing along the way. Work to modularize your systems so they can be delivered in smaller increments. How you design your product will play an important role in how satisfied your customers are and in how quickly you can gain some value.

The pictures in Figure 1-1 show why it is important to include your customers in your designs and why it’s important to have the right design as you progress toward your goals.

Figure 1-1.

The importance of customer input and good design

How do you think the customer would react to a design showing the first line of drawings? They gain no real value until the fifth version. Would that work for products you buy? Then why do you accept that for any work done in your organization? The second line of drawings shows how we can release each piece as a product and the customer will gain some benefit from it. They won’t get everything they requested until the fifth release, just as in the first line of drawings, but they will gain some value.

For some percentage of customers, the products you design along the second line will be exactly what they want. Some people only have bicycles. Some have motorcycles and that is sufficient. Many people want and need a car, but giving them the products along the way allows them to experience the direction in which you are heading and make requests for changes or enhancements along the way. This isn’t just for creating products, though. Everything you do should be reviewed early. If there is any part of your organization that is not showing their work early and often, change that. Create an open and sharing environment and save yourself millions in wasted work.

2.

Welcome changing requirements, even in late development. Agile processes harness change for customer’s competitive advantage. We plan for change, even late in the development cycle. This is easier to do when you have automated testing and the changes provide more value to the customer than the initial plan. It is also true for nondevelopment projects. Change is a part of our current world. Frequent change needs to be planned into every process you have. If you are still using heavy change control management or find yourself locking down a plan, stop and think about how realistic it is to be doing that today. Do you really have any part of your business that can afford to be locked down? Is there any part that should not be planning for change?

What if you could harness that change to provide a competitive advantage? We worked with one company that became fully agile. They were not only able to respond to customer requests late in the development cycle, but they were able to see the value of each item of work being done. The chief technology officer (CTO) came up with an idea for a product that added a level of cybersecurity for anyone who used it. They were able to stop less valuable work, and flow the new work to the available teams. This not only allowed them to provide great benefit to their customers, but it added millions in revenue to their own bottom line.

We’ll talk more about changing plans later. Just remember that Agile practices are based on logical thought and don’t require you to do things that make no sense.

3.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timeline. Refer back to Figure 1-1 for insight. The more frequently we can deliver a product, the more value we can provide to the customer and the easier it is for us to get it right (to gain feedback so we can provide exactly what the customers want). Delivering more frequently allows us to ensure we are providing products that customers value and the feedback we receive from the released products helps us make sure all enhancements we plan are the ones requested most by our users.

This is not just about product development, though. Sharing frequently is key. It’s not that we are making products so much more quickly or doing work much more quickly, it’s that we are showing people a less finished product than we used to, which also diminished the cost of failure. It’s easier to redesign part of the scooter shown in Figure 1-1 than it would be to redesign the car. Early and frequent feedback saves you money and it saves you from creating something that no one wants to use.

Many years ago, it was common to not demo or show your work until you considered it fully complete. This is no longer acceptable, nor can you keep up with the market this way. We now find companies using this technique in their marketing departments with campaigns, sales departments with opportunities, and human resources (HR) departments with new training and compensation plans. How we do business is changing, and Agile techniques are being used in all areas of the business.

4.

Business people and developers must work together daily throughout the project. Close, daily cooperation between business people and developers—this should really say both sides of every project, because these principles apply to any project type, not just software development and information technology (IT)—is critical. Every project has a customer and a team that completes the work. The stakeholders must be involved consistently to get the right outcome delivered as quickly as possible.

For software development and IT, the business knows strategy, the markets, and keeps abreast of current trends. The developers (and quality assurance [QA] folks) know how to build great products and they keep abreast of the latest technological breakthroughs. Creating a trusted relationship and team that includes both the business and technical sides of your products is mandatory to doing good Agile practices. They need each other and each other’s knowledge to create the best product in your market.

Look at every part of your organization and make sure they aren’t doing work in a vacuum or in a silo.

5.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. Trust that your teams know what they are doing. If the teams, or your business leaders, or your employees cannot be trusted you have a huge problem, one that cannot be cured by micromanaging or process. One of the best outcomes that we have seen come out of well-followed Agile practices is an increase in employee morale. This comes from people feeling they have ownership in their product and the work that they do. It also brings a respect and understanding of the other people that they might work with and depend on.

Trust those you hire to do their jobs and to do them well. Provide coaching and advice and have discussions so the outcomes are known by all involved. It is really amazing what happens to a corporate culture when employees are trusted and the assumption is made that everyone wants to do a good job. If something goes wrong, maybe someone needs coaching on how to do that task better, but you believe that they want to do their best. Motivate your teams by trusting that they know what they are doing