Why Do We Need To Be Agile?

Editor's Note: I received an email from Irena Papuc from Toptal Corporation this week, asking me to post this article from their blog about expectation management and planning. Even though this article is specifically about software development, it also applies directly to strategic planning. Read on and enjoy. As always, you can find all my blog posts from 2013 to the present on my website at http://stevemarshallassociates.com/steves-blog/

Long ago, we roamed the land to gather food and shelter to survive. They were simple needs, but pretty agile. Some time later, countries and economies grew and prospered on the back of the Industrial Revolution. This was the birth of management and control and the loss of agility. Now we’re in the Information Age or Revolution, where businesses employ knowledge workers. Knowledge workers are you, your partners, your colleagues, and peers that endeavor to create great solutions to the customer, business, social, economic and world problems. Knowledge workers apply analysis, knowledge, reasoning, understanding, expertise, and skills to often loosely defined and changing needs. These businesses and workers need methods and techniques that cannot be met by old Industrial Age processes and procedures. Agile supports interactions.

Virtually no company can confidently set out at the beginning and know all that it needs in order to deliver valuable products without change. Change presents both opportunities and risks to the success of a project. Unmanaged opportunities can mean the difference between a great company and an awesome company. Unmanaged risk spells disaster and ruin. Agile manages change.

Adopting agile allows you to be responsive to changing or new requirements. It empowers development teams to be the experts and make decisions supported by an engaged, trusting, and informed business. It enables you to deliver to customers what they really want. Ultimately, it puts you and your organization in control of delivering high-quality products that deliver on customer need and expectations whilst extracting a return on your investment dollars as early as possible. Agile creates value.

There is a cost to adopting agile. It doesn’t come for free. Transforming to an agile approach for product delivery can be a hard path to follow. However, if you internalize the agile philosophy, tread carefully, engage the right team with the right attitude, break things down, make it achievable and realistic and respond to feedback, you will reap rewards. Agile emphasizes collaboration.

The following lists some benefits you can expect:

  • Speed to market
  • Earlier revenue generation
  • Regular delivery of real value
  • Protection for your investment
  • Data, data, data
  • Better product quality
  • Manageable expectations
  • Greater customer satisfaction
  • Higher performing teams
  • Improved visibility on progress
  • Predictability, transparency, and confidence
  • Manageable risk

“Success is not final, failure is not fatal: it is the courage to continue that counts.”

Winston Churchill may never have actually said this, but I think it’s a pretty good summation of Agile. We know Agile is the best foot forward for most projects. It encourages you to strive for success, but we always iterate and keep building on it. Agile will encourage you to fail, but fail early and move on. Having the courage to continue and to build the right solution based on insight informed by your customer is what brings the reward.

The thing to keep in mind is you can tailor Agile to your needs. Use the method and governance that is right for your business. Wherever you start, be true to the content, context, and spirit of the method you use - keep it vanilla. If you’re just starting out - Learn. If you’ve been doing it for a while - Understand. If you’re becoming awesome - Apply. Finally, if your business and your projects are complex and interdependent - Govern. Over time, you and your teams will figure out what works best for your business.

Feasibility

So now you’re thinking, “Okay, I get it. How do I start? Where do I start?”. Well, with all good things, we start at the beginning. And with Agile, it’s by asking yourself, “What business value do I want to deliver?”. After all, that’s why we undertake new ventures, to generate business value. In order to establish if the venture is worth undertaking to derive the business value, you need to understand whether it is feasible.

Vision

Is your venture projected to increase revenue, enter a new market, acquire more customers, improve customer perception, or make life easier for a given problem you’ve identified? With this in mind, you can state your “Vision”.

  • Your vision may come from different sources - your own bold startup to fix a common problem, business management strategy, your CEO’s pet project, a specific product team, or even your customer’s needs.
  • Try to take a step back from your own shoes and “see” what the future looks like with your new product or service in the hands of your customers.
  • Engage your stakeholders - the CEO, product guy, and customers. Workshop it, don’t attempt this in isolation. Challenge assumptions and validate arguments.
  • Write it down, keep it short. Focus on the business value.
  • Refine it until you all agree the vision resonates with everybody and meets a common interpretation that states where you’re heading.
  • Your vision, if valid, rarely changes. How you get there most certainly will.

People don’t buy what you do, or how you do it. They buy the “why” you do it. This is what creates the emotional connection between your business and your customers. The vision will help illustrate this.

Is it Feasible?

Feasibility comes in at least a couple of shades. Typically, you’ll want to understand if your vision of a brighter future for your business and customers is both technically feasible and that it’s feasible for your business to make it happen.

  • If your vision is to make travel to anywhere across the world in under an hour, you may have a problem with the technical feasibility. Since science, physics, and technology haven’t quite caught up with that dream yet, your technical solution may not be viable in anything other than theory. In addition, if your solution was new, this would go well beyond the idea of a Minimal Viable Product (MVP).
  • To test the technical feasibility of your product, consider either exploring it further in a Discovery prototype project or by running a spike in the early stages of the project. You’ll know which method to use by thinking about the scale or complexity of the solution you have in mind.

    “Some of the best knowledge my teams have gained in understanding technical feasibility have come from performing a spike. And often, it’s the simplest solution that wins out!”

  • The second shade of feasibility to consider is whether you, your team or business has the skills and motivation to make it work. Using an example, if you’re great at baking cakes at home for your kids birthday, that’s sweet. But if you want to turn this into a business selling the finest cakes to the world, you need to understand if you can make it scale, handle the business as well as the production, manage distribution and fulfillment, and take care of customer service.
  • This type of vision might be achievable in the long run. But for now, possibly not. So scale it back, think small, take a small chunk that looks realistic and concentrate on delivering the best but smaller aspiration you can. If that manages to engage and delight your customers, get them coming back for more and telling their friends, then scale it up from there using your customer feedback as your guide and compass.
  • Also, you need to know if your project is feasible in terms of budget and timeframe. Can your business afford to deliver this product? Is the timeframe achievable? Time and money are two of the three constraints in an Agile project that are fixed. We aim to deliver within a given fixed time and within a given fixed budget.
  • The quality of a product refers to the end product that your customers use and the engineering practices your team uses to deliver great, robust, and reliable software. Quality is also something we don’t short change on. Quality criteria, on the other hand, can change. If you’re not setting out to build a Ferrari, the product may not have a high-quality perception. If you’re not building space rockets, then the tolerances attained in production terms may be much higher. Set the appropriate tone and expectation early on.

So now you’ve confirmed your dream is more than chocolate fancy, set about testing your assumptions, and proving to people that this endeavor is worth investing in.

Justification

Now depending on your circumstances, justification will come in different forms. But essentially, you want to prove that this venture will satisfy customer success criteria, has a chance of success, will deliver value, and is affordable.

  • State your assumptions based on your customer need, then validate them. The Lean Startup gives great guidance on identifying and proving that your product is needed by your customers and will create value.
  • Write, test, and validate your business plan. Now, this looks nothing like the ones your bank or Business and Finance major told you to produce. Don’t use them, they will be out of date before the ink is dry. Instead, check out the Business Model Canvas. This is essentially a short form business plan that keeps your focus on your value proposition, your customers, revenue, and costs. Use it to validate if you have a business that will work.

    “I ignored this advice once and spent a long time writing a lengthy traditional 50 page business plan. It got me nowhere. All the assumptions I had made were unfounded, and all the projections I made couldn’t be validated. It was a painful and expensive experience that taught me to never do it again.”

  • If you’re in a mature business with portfolios of projects being delivered in a complex environment, then financial modeling may be necessary. If you must, do this only after you’ve proven the above.
  • Once you’ve built your MVP, there may be a case for creating a more traditional business plan. For example, if you have to go for funding or selection within your company’s portfolio of competing projects and resources. But this will be a business plan based on and informed by the tools used above. It will be lighter too.
  • In any case, use these tools as living, breathing artifacts. Use them as your guide and bellwether. They are never static. Refer to them and revise them as your project or business evolves.

Once you have your justification and all your stakeholders are onboard, you’ll be on fire.

The Feasibility phase is typically performed once in the life of your project. You may find you revisit the vision and feasibility of the project, especially if your data, customers, market or business indicate so. At the very least, they will be your guiding lights throughout.

Initiation

Awesome. The decision has been made, the project has the green light and you’re ready to build. Well, nearly. I know you’re thinking, “C’mon already, really? If we don’t do this now we never will. Let’s get this show on the road!”. But consider this - Agile is nothing if not about delivering value early and often whilst delighting your customers along the way. Taking some time to figure out the best way to deliver your project is the best-laid foundation for success.

The Team

In sport, by thinking about your favorite team game you’ll be able to recognize key roles that enable the team to perform as they do. Traditionally you’ll find a manager, a captain, and the rest of the squad. Outside of that, you’ll find coaches, physios, nutritionists, and an assortment of supporting staff. But if we look at the game of rugby, there’s a team within a team. The players that make up the scrum. This pack is made up of designated players whose job it is to win the ball back and continue play. When a scrum is in play, the players from each side then work, with no leader, as a single unit as collaboratively, communicatively, and efficiently as possible to get the ball back in possession. It is the game of rugby that inspired Jeff Sutherland to name his software development methodology, Scrum.

  • Scrum is not the only software development method in the Agile playbook. But it is the one that best describes the Agile concept and behaviors of working as a team, motivating individuals, creating trusting relationships, self-organization, servant-leadership, communication, transparency, and collaboration.
  • Your team will be formed largely by the circumstances you find yourself in. You may have developers available to you, some, none, or all of them may be familiar with Agile to varying degrees. You may want to hire a new team or partner with a 3rd party.
  • Other roles will be required too, but we’ll discuss those later.
  • It has been said that if you form your development team, then you’ve chosen your technology. As depending on where you bring your team together from, they’ll come with certain skill sets. So, think carefully how you form your development team and whether you need to perform a technical evaluation before you get to this point in your journey.
  • This brings us to cross-functional teams. Teams work best when they work together when individuals pitch in to get the job done regardless of their “title”. Try to build a team that is self-sufficient and individuals that take on more than one role.
  • Build an environment, culture, and relationship center. A place where the team can deliver, unencumbered by constraints or restrictions. Give the team the tools, people, resources, and space to be effective and performant.
  • Keep team sizes to no more than 7 or 8. If you have a need for many more developers, break the teams down. Each team might then be responsible for a given functional area. If you have multiple teams in multiple locations, consider holding a Scrum of Scrums. And where these are numerous in complex environments, use Agile project management.
  • Ensure that the team, business, stakeholders, and even customers have access to each other. Ensure they communicate and collaborate, and remove anything that gets in the way of progress. Daily communication is the best cure for project ailments. When people speak, they get stuff done.

Project Brief

In Feasibility, you figured out the “why” of your project and either built your confidence to forge ahead with your startup or got backing to proceed. The project brief is the living document that brings together the “why” with the “what” and “when” and “who”. It’s living, because as you progress from hence forward your knowledge, understanding, and path may change. To leave this document once written and never to return to it, just consign your thoughts to a point in time. In an Agile world, your point in time reference may change weekly or even daily early on, so it’s important to keep this fresh.

  • A great tool for encapsulating and maintaining your project brief is something that Jonathan Rasmusson calls the “Inception Deck” in his book “The Agile Samurai”. Here you’ll find great advice on ensuring that everybody that is interested in, affected by, or involved with your project is on the same page.
  • The greatest enemy to delivering projects is in having an unclear, inconsistent, or just plain different understanding of what the project is and what “requirements” are to be satisfied. If even one important stakeholder has a different understanding or view of what you’re doing, the consequences can be substantial.
  • A good project brief communicates:

    1. A common and agreed expectation between stakeholders and team members.
    2. An understanding of the project, with the same understanding across all parties.
    3. The goal, vision, objective, scope, and project context.
  • You’ll have a lot of good information for the brief gathered from Feasibility. The project brief will help you define and find the answers to searching questions. It will bring together stakeholders, your raison d’etre, high-level scope, risks, target solution, budget, timeline, expectations, and your priorities.

“A colleague stopped me in a corridor once and asked me where he could get the project brief for the project. I quipped ‘We don’t need a brief, we’re Agile’. He looked confused, as if he was questioning my sanity or authority. He was right to do so.”

Before you proceed, ensure you’ve got everybody on the same page, workshop it, ask the difficult questions, and nail it somewhere where people can stop, read it, comment on it, and help revise it.

Culture and Ways of Working

You know the way your business works and its culture, the way it likes to get stuff done. Agile, by its very nature, may challenge some of these ways of working that your business has cultivated over the years. Don’t expect Agile to be implemented and for everybody to lovingly adopt it from the outset. Some people may find it confusing and view it only with dread and fear. Some people may openly refuse to engage in it. These are challenges and perceptions you must overcome. But in your early days, don’t go around waving the Agile stick beating anyone that won’t listen to it. That won’t build trust, adoption, or engagement.

“I was a fan of waving big proverbial sticks once, and it earned me a lot of negative press. I turned it around, but not before suffering considerable pain first.”

As you set out on your path of adoption, tread carefully, respectfully, and with empathy. If you’re in a creaking old traditional business, perhaps it won’t be the best approach to get the whole business aligned. Start small and incrementally earn respect and recognition. Start with your team only. Once you start delivering quicker software with better quality than ever before, people will start to notice and will want to come play your game. When they do, offer them the ball, take them out for a coffee, and ease them into your new world. Help them.

With your team, now that they know what the project is about and your plans for Agile adoption agreed, let the team decide how they wish to behave and operate as a team.

  • Guide your team to identify the Agile concepts, techniques, behaviors, and frameworks that you feel fits your collective needs.
  • Take requests from your team members as to what requirements they have to help them perform as best they can. Some of these requests you’ll be able to resolve immediately. Others, you may need to get budget or outside help. Do what you can to make it happen.
  • These are your first steps to becoming a true servant-leader.
  • Consider organizing some appropriate training in the concepts and techniques your team are choosing to adopt. This is the best way to ensure all of your team, even stakeholders, are on the same page and get the same message. Work with a supplier organization that can tailor their offering to your needs.
  • Be prudent. Nobody will be an Agile ninja after a few days in a workshop learning how to become Agile. Your path will be long. The word “become” is quite defining. Only when you truly embrace Agile will you see its value. It should excite you. If it excites you, then go excite others too.
  • Now that your team has agreed with the concepts and techniques, had their wishes fulfilled and in Agile training, turn your team’s attention to themselves and what they expect from you, the business, and each other.
  • Define some Ways of Working (WoW) within and by the team helps build trust, relationship, and expectations. The WoW is no War and Peace. It should be short and to the point, between 7 and 10 bullet pointed sentences. These sentences state clearly how people behave, communicate, collaborate, support, deliver, and perform together. It should also state what the team to expect from the business.

Agile is as much a mindset as it is guiding principles and concepts. It helps you develop in the way you behave, think, negotiate, interact, communicate, perform, and improve. It relies on motivated individuals supporting each other to reach a common aim, together as one. There is an African proverb:

  "If you want to go quickly, go alone. If you want to go far, go together."

Enjoy the journey.