Table of Contents
Introduction
You’re in charge of delivering your company’s latest and greatest initiative that’s going to change the face of “Widgets International” forever. It’s a software project that’ll engage and enthrall your customers, make your colleagues’ lives easier, and make the company millions in revenue. There’s a great deal of anticipation, fervor, excitement, and expectation. You need to get it done as quickly as possible so your business can start to reap the benefits. The future success of the company depends on you. All eyes are on you. You cannot fail. So ready to get an introduction to Agile Project Management?
At first, you’re thinking to yourself, “Awesome, I’m up for the challenge. Let’s get this thing done!” You pause for a moment, step back, and think to yourself “Okay, so how do we do this?” You start to talk to your colleagues and peers. You spend time searching for best-practice software development and project management techniques, but the options and approaches are countless. There are acronyms and methodologies aplenty. Notable ones rise to the top. Doubt creeps in. Which one should we use? How can I guarantee success? What if I make the wrong decisions?
When it comes to managing software projects, there’s a heady mix of options supported by myriad opinions. Voices from the corners of the room whisper, “Try doing it this way”; others shout, “This is the only way to do it”; and the rest just whimper, “Don’t manage it at all, just get on with it.” In reality, all those voices speak some truth. But what’s important is working out what’s right for your needs, your team, your business, and your customers.
Setting the Scene
There was a time when software project management sat squarely in one of three camps. There were the heavy frameworks that let you make decisions on how you execute and deliver while offering a structure to maintain control and governance. There were prescriptive sequential methodologies like a waterfall that forced you to plan lengthy projects, understand and commit to all your requirements, design and sign off complex systems, write lots of code, and then test (all before your customer gets to see it for the first time). And finally, the less prescriptive but iterative software development life cycles (SDLC) encourage rapid prototyping or larger systems to be designed, built, and delivered in incremental steps, each building on top of the other.
Agile software development and Agile project management were born out of the inadequacies of the waterfall and the benefits of the iterative approaches to software delivery. They can trace their roots to the 1950s, thought leadership in the 70s, maturity in the 90s, and adoption through the 00s. In 2001, a group of practitioners and experts created the Agile Manifesto, aimed at defining 4 values and 12 guiding principles that seek to embody the spirit of Agile software development and to encourage its evolution. And it has definitely evolved.
Now, simply calling something Agile isn’t particularly helpful. The word, even in a software context, means different things to different people or organizations. There are many facets, definitions, implementations, and interpretations. Each body that embraces Agile tends to try to give it its own definition.
Simply calling something Agile isn’t particularly helpful.
Suffice it to say that Agile software development and project management are a group of related behaviours, frameworks, techniques, and concepts that fundamentally favour the delivery of the right working software as early and as frequently as realistically possible.
I mentioned earlier that Agile, as applied to software development or project management, can be different things. In a nutshell, Agile software development takes care of developing great software in a business as usual (BAU) or project context. Agile project management, on the other hand, takes care of the governance and control required to deliver complex projects including but not limited to software.
There are many Agile software development methods available, such as Scrum, Kanban, XP, and Lean Software Development. But just as the game of rugby is about more than the scrum, so is Agile. In isolation, these Agile paradigms do not address the full lifecycle of project management required in complex projects such as governance, resourcing, financial, explicit risk management, and many other important project management concepts. For these, you might want to consider PMI Agile or PRINCE2 Agile—think of it as “Governed Agility.”
Why Do We Need to Be Agile?
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, valuable software that delivers on customer need and expectations while 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 software 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 of progress
- Predictability, transparency, and confidence
- Manageable risk
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 projects, to generate business value. In order to establish if the project is worth undertaking to derive the business value, you need to understand whether it is feasible.
Vision
Is your project 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, and 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.
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.
The second shade of feasibility to consider is whether you, your team or your business has the skills and motivation to make it work. 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 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 project? 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.
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.
Initiation
Awesome. The decision has been made, the project has the green light and you’re ready to build. But consider this—Agile is nothing if not about delivering value early and often while 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
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 third party.
It has been said that if you are from your development team, then you’ve chosen your technology. Depending on where you bring your team together, they’ll come with specific skill sets. So, think carefully about 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 and when individuals pitch in to get the job done regardless of their titles. 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 seven or eight. If you have a need for many more developers, split the team into multiple new teams. Each team might then be responsible for a given functional area. If you 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 one another. 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.
There are many ways a team can be put together to deliver software.
Project Brief
The project brief is the living document that brings together the “why” with the “what” “when” and “who.” It’s “living” because, as you progress, your knowledge, understanding, and path may change.
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.
- A good project brief communicates:
- A common and agreed-upon expectation between stakeholders and team members.
- An understanding of the project, with the same understanding across all parties.
- 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 search questions.
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 some 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.
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 toplay 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 are agreed upon, 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 fit your collective needs.
Consider organizing some appropriate training in the concepts and techniques your team is choosing to adopt.
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.
Defining some ways of working (WoW) within and by the team helps build trust, relationships, and expectations. It should be short and to the point, between seven and ten bullet-pointed sentences. These sentences state clearly how people behave and communicate.
Roadmap and Story maps
At this level, your roadmap shows major goals or milestones to be achieved. A goal is a logical grouping of themes, features, and user stories rolled up in a consumable view that demonstrates tangible value. The roadmap of a software product shares this view and communicates your intent. It doesn’t necessarily show you how or when features will be delivered; only the relative value of the goals and features to you and your business.
One great way to demonstrate a roadmap is to generate a story map. This tool indicates customer-valued prioritization. It lays out the backbone or essential building blocks of your product. The walking skeleton hangs off the backbone and illustrates the features that make it an MVP. All the other features are what add further value and importance to the system. The story map lays features in relative position to each other and is an awesome visual tool.
The Initiation phase is typically performed once in the life of your project. However, many of the tools and documents you created will be revisited and revised throughout the project.
Beyond Agile Project Management
It’s important to know what happens after the project is delivered. Support and maintenance are key to ensuring that, once the project is in customers’ hands, it remains performant; customer feedback can be factored into future releases, and customer issues are dealt with appropriately. A project is a unique, time-constrained endeavor. The product it delivers has a life after the project team has been disbanded. Ensure that you are capable of supporting the product once it is live.
Agile projects co-exist with more traditional approaches. Balancing the requirements for budgetary control and stakeholder visibility with the Agile aims of flexibility and responsiveness.
A governance framework or Agile governance model is used in conjunction with standard Agile processes, such as Scrum. They work in two specific ways:
They provide a wrapper for an Agile project by clarifying the processes that occur outside of development iterations (sprints). This includes providing clear criteria for the successful completion of project initiation and proper validation of the decisions and plan.
They shift the emphasis of specific parts of the standard Agile process and highlight particular principles and techniques that need governance or support governance.
In today’s ever-changing world, organizations and businesses are keen to adopt a more flexible approach to delivering projects and want to become more Agile. However, for organizations delivering projects and programs, and where existing formal project management processes already exist, the informality of many of the Agile approaches is daunting and is sometimes perceived as too risky. These project-focused organizations need a mature agile approach—agility within the concept of project delivery—Agile project management.
Learn and grow with your adoption of Agile. Only ever do what your team is comfortable with, ensure their voice is heard, and act on their requests. Encourage your team to adopt new and more valuable techniques when the time is right. Negotiate with the business and encourage them to understand what it means to be an Agile organization.
