In the first installment of this Introduction to Agile Project Management series, I wrote about Setting the Scene, why we need to be Agile, Feasibility, Vision, Justification, and Initiation of Agile Projects. Consider checking out that article first before reading on in the series. In this installment, I write about the Project Team, the Project Brief, the Culture and the Way of Working, Backlogs, and managing projects to a high level of Estimation and Prioritization.
The Team
In sports, 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, and 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. Depending on where you bring your team together from, they’ll come with certain 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 – when individuals pitch in to get the job done regardless of their “title.” Try to build a team that is self-sufficient, with 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 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.
There are many ways a team can be put together to deliver software.
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 consigns 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:
- A common and agreed 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 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 with 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 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.
- 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 budgeted, 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 on 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.
- Defining some Ways of Working (WoW) within and by the team helps build trust, relationships, 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 expects 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.
By now, your team should be super excited, energized, and motivated. Now engage them further with your backlog of User Stories.
Backlog
Have no doubt in your mind that there’s uncertainty involved in your project. You can’t possibly know exactly what it will take to build the right product for your customers so early in its life. You cannot gaze wistfully into a crystal ball and predict the future.
The “backlog” or “product backlog” is where your requirements live. Agile favors the writing of short pithy statements that capture the essence of a “requirement.” The backlog is simply a long list of entries, each entry defining a single, discrete “requirement” as a User Story. And from now on, we’ll be using the word User Story, and not “requirement.” You’re probably asking “why?” That’s a good question. For life eternal, stating the features or facets needed in a software project by a customer, have always been referred to as a “requirement” (ah, i used it again! Last time. Promise) That word has an interpretation that has no value in Agile. The Oxford dictionary defines it as:
“A thing that is needed or wanted.” Or, “A thing that is compulsory; a necessary condition”.
And unfortunately, if we set out defining what our solution should be, stating that things are “compulsory,” we will end up in trouble. It’s too easy to say that all these User Stories are compulsory. If we take that view, we run the risk of running over schedule and over budget in the attempt to deliver all of a given scope. It’s not a problem to say that, for this product these stories are needed for the solution to be viable, we just want to avoid the interpretation of that particular word.
- Always write stories from the perspective of apersona. A persona represents a user or stakeholder of the solution. It’s a good idea to develop these personas before you start a backlog.
- At this stage, only write short simple statements that basically suggest a reminder to have a deeper conversation about the User Story when the time is right.
- Real people think in terms of tasks that they need to get done to achieve a goal. Write your stories from the persona perspective and in terms of what they need to get done.
- You don’t need to write the full backlog, just write as much as you can imagine your customers will need for your product to be viable.
- You’ll discover later on through the life of the product that User Stories will change, become more or less important, or can be deleted completely. Releasing often, getting feedback, and assessing what’s a priority will inform this behavior.
- Don’t write stories in isolation. Engage your team, stakeholders, even your customers. Stories can be updated at any time in the life of a project, but should avoid being changed once development work has started on them.
- Some of your stories may be considered “Epics.” These are large stories that cover a lot, and will be broken down closer to the time of delivery into smaller stories.
- Consider using theINVEST model, a checklist for validating the quality of a good User Story.
- Anybody can add a story to the backlog. It should be placed at the bottom, or in a specially created “Parking Lot.” This added story serves as a prompt to discuss with the team and the business. If the business and team support it, it can then be estimated and prioritized.
- You may also consider those parts of the system that are most risky. If you have a User Story or feature that is complex, new, or technically unknown, prioritize these to the top of your backlog. This way you won’t be attempting to deliver the challenging and critical parts of your product just weeks before your first release.
Once you have a backlog that fulfills your needs, you can estimate the stories in it, rank them in order of priority, and build a release plan.
High-Level Estimation and Prioritization
High Level Estimation is the process of sizing your backlog. How “big” is the project, and what value does it deliver? Prioritization is the process of deciding which stories are most important to you, the viability of the product, and the interests of your customers. We want to deliver the highest value items earliest to deliver the most value to the business, get feedback from the customer, and to not sweat the small stuff. The output will be an ordered backlog that is ranked in priority and sized.
- Stories at the top are considered most valuable. We want to deliver the most valuable items as early as possible.
- There are many techniques for sizing and estimating, but at this point you just want to get a good indicative feel of the size of a story.
- Use t-shirt sizes, relative sizing, ideal days, or story points.
- You won’t have all the available information at this point either, and that’s okay. Just run with it.
- Engage your business stakeholders or product manager if you have one, and the team that will be doing the work.
- We want those that will be designing, developing, andtesting the work to size it, because the best people to estimate are the experts.
- The team may start to break stories down into smaller parts. If this happens, write stories that are more granular but discrete.
- The team may also start to rank some stories, as naturally some things have to get delivered before others to support the technology or a given user journey.
- Between you and the team, you may also start to find holes in the backlog that need to be filled. Just fill those holes with new stories and estimate and prioritize as appropriate.
- Prioritization is most easily performed using a MoSCoW analysis. MoSCoW is a simple technique that helps you decide which stories are “must haves” for your product to be successful.
- You may do a prioritization pass before estimation begins. However, the sizing of certain elements may also determine a decision on priority and real business value. So play estimation and prioritization off of each other, but don’t squabble over it!
- No two stories can be as important as the other. The story at rank 1 is more important or valuable than the story at rank 2.
- A great way to demonstrate the importance or value of a story is it to add a monetary value to it. If for example, story A is thought to bring in $5000 of extra revenue, and story B might attract $100, then story A is more valuable. Equally, if story C saves the business more than story D, story C is more valuable.
- Once you’ve sized your backlog, you’ll be left with a number. When we come to release planning, that number will help us understand how much can be delivered by our team within a given timeframe.
Remember that you don’t need to know all your user stories up front. Also, remember that it’s not necessary to deliver all of your stories before a customer sees your product. You want to remain Agile – and that means only creating what you need to when you need to, wasting as little as possible, and responding to changes in customer needs and market conditions. A roadmap will help you lay out your product and plan your objectives for the next 3, 6, 9, and 12 months.
In part three of this four part series – Introduction to Agile Project Management – I will write about Roadmaps and StoryMaps, Product Iterations, Adaptive Planning, Story Creation, Sprinting and Defining Done.
