Agile Management Guide

Size: px

Start display at page:

Download "Agile Management Guide"

Hugh Douglas
5 years ago
Views:

1 1 Agile Management Guide These days there is a strong push for Agile Management, as opposed to Waterfall. Personally at Castellan Systems we believe that the agility should be applied to the project development lifecycle rather than the project management. A strong project management process is equally, if not more, appropriate to an "Agile" environment. The more agile or dynamic a project environment is, the more important strong project management principles and processes are. In a fast moving project environment things can go wrong very quickly and if the project management disciplines are not strongly applied these problems may not be picked up until it's too late. Agile is sweeping the world. Well, it is if you re involved in product development. It s not new, Agile has been around for over 20 years, but it s seems to have gained traction with each passing year and is trending, as they say in social media circles. But is Agile really the miracle cure for all project woes as it s often prescribed? Of course not, but it s a fine way to manage a project, and Agile offers some unique advantages for the project leader and their team. Agile is a software development approach that has gained momentum over the years, with good reason. It addresses uncertainty with respect to product requirements and development as opposed to Waterfall, which looks to organize the project lifecycle phases in sequential order Initiation, Planning, Execution and Closure. What Is Agile? More and more teams are going Agile these days. Everyone working in software dev is either using Agile or they are learning how to use Agile. And now Agile has spread to be adapted by other kinds of teams, too, like marketing and sales. But what is Agile? Is it a methodology, as some insist, or is it not, as other protest? Well, it does seem to follow certain principles, and however loose and collaborative it may be, remains fixed to those principles. Agile Agile is best known for its manifesto (primarily for software development) where solutions evolve through an iterative, collaborative process. Generally speaking, it is founded on the principles of adaptive planning, evolutionary development and early (and often) delivery with the end user in mind. But Agile isn t a magic bullet that can pierce any project to reap the same positive results. Agile offers a kind of structured methodology, or approach, or whatever definition you prefer. Agile has an almost cult-like following, and many advocates don t believe it s a methodology at all.

2 2 Some say that Agile is a philosophy of software development, and Scrum is a framework to apply this philosophy. Good software development practices are the practical methodologies that make it all work. Agile is a set of values and principles. But whatever you do, don t confuse Agile with Project Management. Agile is about building a product and not about managing a project; there is more to Project Management than simply getting the product built. That may be true, but it s also a system of methods used in a particular area of study or activity, which is the textbook definition of Agile. Controversy aside, Agile is well suited to those continual deployment-type projects where the target is moving, an environment where priorities are constantly changing and you have highfunctioning collaborative teams. However, if your project has hard deadlines and pre-determined product spec, one that is immovable for whatever reason, then Agile may not the way to go. You might need a different methodology, like Lean or KanBan or Waterfall-style structured projects, or you might benefit with a hybrid approach. Even this, though, is debatable, as the proponents of Agile note it can used for fixed project work, as well. Despite the lack of agreement on what Agile is and what it s good for, and even the possible divisiveness of such an argument, Agile remains popular and deserves serious consideration for anyone leading a project. So, at the start of any project, you should figure out if Agile is the best, or only, approach, for you. To determine the proper course of action, ask yourself these three questions. 1. Is my project completely structured? There are projects where the deliverables are set in stone and a project leader can work back from that to develop a linear path to reach that goal. This is not an ideal Agile environment, even if there are those who would disagree. Think of the classic Waterfall projects such as infrastructure improvements or construction projects or building the Hoover Dam. In these types of projects, there are defined plans and sequential timelines requiring a fixed structure, and while Agile advocates say Agile can apply, it may not be ideal. For example, first environmental studies need to be conducted, and approved, and then architectural renderings that define engineering specs all need to be finalized before pouring the concrete. All those deliverables are set in stone, so to speak. 2. Does my project require some structure? There are projects that neither fall under the highly structured or clearly Agile category. They may require a hybrid approach. Portions of the project could benefit from Agile, such as dev required for a new website build related to a new retail store launch. Whereas other parts of the project, might be more structured and be more suited to a traditional planning methodology, such as the construction of the new store interior and the manufacturing of the clothing line. It s possible to use both on a single, larger project, but likely each would be considered sub-projects, and managed distinctly. 3. How hands-on are my stakeholders? There are times when stakeholders are going to want change and want to see that change implemented quickly. They will give their teams marching orders, but are content to step back and allow the team to arrive at solutions in their own fashion. These stakeholders are perfect for Agile projects. Then there are stakeholders who demand a greater control over the course of a project s overall progress. They may be delivering the fixed product requirements and prioritized backlog to the team to implement in a more topdown fashion. This could be either due to leadership style, or that the product or project requires more defined deliverables at the outset. In short, when the roadmap that is immutable and timelines for deliverables are fixed at the start of a project, then Agile may not be the best choice.

That can be helpful in that it keeps one open to the many possible applications of Agile, but it s important that your stakeholders are well informed about the Agile process, so they can understand

3 3 There s differing opinions on that, too, however, and some believe Agile can be applied to projects with immutable and fixed timelines. It s one of the things that s so great and frustrating about Agile: it s a flexible approach with sometimes passionate believers that see its benefits in every potential project application. That can be helpful in that it keeps one open to the many possible applications of Agile, but it s important that your stakeholders are well informed about the Agile process, so they can understand its benefits, too. Agile is a great tool for projects, especial if you re working incrementally, seeking user feedback and charting bugs, so you can adjust the product while in production, Agile can be your guiding principle. But despite of the seemingly fluid definition of Agile, like any tool you have to use the right one for the right job. You want to make sure the research is done to know your stakeholders and know all aspects of the project (or sub-projects) to determine what will be best for you going forward. If it s Agile, then by all means get on board, but being flexible to support to other approaches and hybrid approaches, will better ensure the success of your project. What Are the Right Conditions for Agile? Agile is best used when product requirements are uncertain. Time is used more efficiently to engage the product owner and the Scrum team, starting with the use of user stories. User stories are a brief description of features and functionalities the product owner wants to have developed. The product owner and the Scrum team then takes these software features and creates a to-do list called a product backlog. Once the product backlog is established the Scrum team creates a sprint backlog. These features are then scheduled for release in sprints. Sprints are scheduled releases of features designed to develop and deploy small portions of the product at a time. The product owner and Scrum team will meet daily (daily Scrum) to review the development progress. This approach helps to address the issue of product or requirement uncertainty. Develop some, test, gather feedback and continue developing until the product owner is satisfied with the end results. When is Agile Not the Best Approach? Agile is not always best, such as when there is little uncertainty regarding requirements. Product development efforts where there is a solid history to use as a baseline for a new project may be better suited for a waterfall methodology. Managing the build of a data center is a good example. The planning effort depends on solid requirements and a specific sequence of activities to be completed in order. You cannot build a little and test a little with a data center. It s impractical.

4 4 So, When Is Agile the Way to Go? Now that we have a good idea what Agile is, what kind of environment it s most suited for and those project that are better served with a more traditional methodology, it s time to look at where Agile makes the most sense. There are many, and here are a few: When requirements are uncertain The Agile iterative planning approach allows development to begin sooner and makes the product owner part of the development process. There is no need to spend six months documenting requirements that may or may not result in what the customer wants. In developing a new product feature the product owner can visualize the feature sooner allowing his or her feedback to become a part of the development process to deliver the product sooner. Software development projects are best suited for Agile Software development projects allow for parts of the overall systems to be developed, tested and delivered. This means specific features can be rolled out sooner. Sprints allow these features to be scheduled for testing and deployment separately from each other allowing the development scheduled to be as efficient as possible. Teams that are co-located benefit from an Agile approach (daily scrums) A key to the Agile approach is the daily scrum meetings. The daily scrums allow the team to discuss status, roadblocks and input from the product owner. Having these meeting in person to update the scrum board is optimal. Team members who are co-located can approach and update the scrum board at any time. This helps with team collaboration. Proactive Product Owners Real-time feedback is key for success in Agile. This replaces the need for cumbersome documentation that may never really convey the true requirements of the product owner. A product owner that is engaged and provides the development team with constant feedback allows the team to develop the right product sooner. Product owners should attend the daily huddles and vocalize their wants, likes and dislikes. This will allow the development team to produce a product the product owner wants. Teamwork and collaboration teammates who show initiative Social accountability is a key driver in the Agile approach. Agile looks to create an environment where teams manage themselves to an extent. Scrum Masters look to create a team that is proactive and shows initiative. If a team member is not stepping up to produce or become engaged the Scrum masters expects their teammates to look to help, encourage and motivate each other. The Scrum Master leads by example to set the tone for the team to encourage and hold each other accountable. Willingness to fail and learn Fail fast and learn even faster. Prototyping and feedback are essential tools in Agile. Traditional development attempts to map out all requirements before development begins, which may not be a good use of time, especially when developing what will be a new product. Develop something now! Even if it is not what the product owner wants in order to get feedback as you continue to develop. Management support of the Agile framework and its culture of empowering teams Agile can present a shift in culture and expectations for an organization, as it encourages teams to become empowered to make decisions and take risks. In contrast, a traditional development organization a Project Manager may provide clear direction, while an Agile Scrum master focuses on allowing teams to provide direction and recommend what is best for the development of the product and the product owner. Management must provide the latitude necessary to allow the team to thrive by providing guidance and direction and not try to dictate every move. The embrace of Agile is exciting. It provides one more tool in the project leader s toolbox with which to address the progress of a project. Like any tool, there are tasks that it s better at and those which it is not as well designed for. But we re all better project managers with more to choose from than less. The Case for Managing Agile Projects You want to create the most valuable software possible as determined by your stakeholders in the least amount of time and for the lowest cost. There are many different methodologies you can choose from to deliver your project, from Agile to Waterfall or a hybrid of the two. So, what do you do?

5 The Tension on Agile Projects You need a solid plan and a clear picture of what your project will deliver and a way to control and monitor progress while at the same time being able to release the

5 5 The Tension on Agile Projects You need a solid plan and a clear picture of what your project will deliver and a way to control and monitor progress while at the same time being able to release the most creative and productive energy of your project team. But is it possible to think everything through in advance, or is it better to think things through as you go, and still end up with the results your stakeholders want? There s an inherent tension here, be it a push and shove or a top-down versus bottom-up. It s like the yin and yang of project management. The answer, like Buddhism, is in taking the middle path or approaching things from somewhere in between. That doesn t mean being a project manager on a large Agile project isn t tense. You can feel that tension and you need to resolve it How to Resolve the Tension on Agile Projects Start by answering one of the biggest questions on your project, What is value? Defining value will take a lot of collaborative effort among team members and stakeholders. Together you will determine what you actually want to see in the end, based upon value. Here are some guidelines for determining value: You need something of value that connects what the developers are doing to what the stakeholders want, and a process to negotiate that throughout the development project. You want requirements that are at a high enough level to stay out of the developers way, yet provide value by giving sufficient detail to guide and empower the Scrum teams.

6 6 Top-level requirements must be understandable to allow for clear integrated testing to show if Agiledeveloped features satisfy those requirements and provide the value desired. You need a well-defined end state so that everyone knows where you re going and what value is being created. You need a well-defined yet flexible timeline to get where you re going to realize the value. You need milestones to do value assessments to determine where you are in the project and if course corrections are needed. Agile Case Study Let s say you are on a large and complex software development project. There are numerous Scrum teams, in multiple locations and under different organizations, but all on the same project. The tempo is fast, with new sprints every two weeks. There is a constant stream of meetings sprint planning, design reviews, requirements meetings, integrated test planning, Scrum of Scrums and more! The wheels are turning, but where is it all going? How do you sort through all of the activity and ask the right questions? How do you determine what s going right, what s going wrong and what is needed? Ask these three basic questions: What are we building? What is clear and what not? How will we know when we are done? By when? And how can we monitor our progress toward getting done what we know and prioritize, and clarifying what we don t yet know and make course corrections along the way? How can we do it at the needed quality level, for the least cost, and with the most efficiency? It seems, based on these questions that it s all about controlling what we can in the short to medium term and then figuring out the rest along the way. You want to empower people to contribute along the journey, assuring stakeholder concurrence and moving toward an increasingly clear picture of an end state of value. This last point moving toward a clear picture of the end state is where a lot of Agile projects can come up short, simply because they are too short-term, incrementally focused and lack an eventual longer-term goal. The Value of the Agile Approach The reason for Agile in the first place is that in software development, because of changes in technology, technical complexity and rapidly changing needs, it is hard often impossible to know exactly what you will need at some point down the road. As a result, a healthy acceptance of the fact that you cannot know it all up front can help you to adopt to a more Agile mindset. A drive for clarity on the end state can help you to properly guide the Agile work to a yet unknown place where stakeholders will be satisfied. Back to the case study on this complex and challenging agile project: How do you know when you are getting there? Can you just be satisfied to say that we are making progress? My answer is a bit trite: You cannot be satisfied that you are making progress until you are satisfied. Going a little deeper, you know that you, your team and your stakeholders are on a learning curve. At the same time you need to make progress. In large part, it s all about tempo. It s about setting up a system to ensure that all these things are happening. Agile accommodates this challenge beautifully. It enables you to be managing a relatively short duration project let s say six weeks plus or minus while at the same time chasing after that vision for the ultimate end state. Using a rolling wave, you are constantly managing this short term project that has 95% clarity, and closing out bits and pieces while you push on to the next set of bits and pieces that come into clear view.

7 7 Clarity on the final end state might be 50% at best. It s initially a bit like hitting a golf ball toward the flag. At first, you know that you can hit in the general direction of the flag although often you cannot even see the flag, but just know it s out there. So you start out with a strategy about how to get down the fairway considering wind, slopes, hazards and your own knowledge and capabilities and into a position where, as each shot is taken, you are closer to the green, where you can finally focus on getting the ball into the hole. It s the ultimate balance of short-term and long-term. Strike a Balance on Agile Projects In the final analysis, managing an Agile project is a process. You need to come to grips with what you do and don t know, and create a system for filling in the blanks as the project unfolds. You assemble the team, develop an ecosystem and manage in chunks of short duration while you figure out the rest. In the process, you deliver early and often. The one constant across all methodologies is the use of good tools designed to get the job you re working on done right. There are many tools out there, including those from Castellan Systems. To see how it can help you plan, monitor and report in real time, check out the free 30-day trial. Acknowledgements These articles were originally published by ProjectManager.com Copyright 2015 ProjectManager.com 3420 Executive Center Drive, Austin, USA 78731

Agile Projects 7. Agile Project Management 21

Agile Projects 7. Agile Project Management 21 Contents Contents 1 2 3 4 Agile Projects 7 Introduction 8 About the Book 9 The Problems 10 The Agile Manifesto 12 Agile Approach 14 The Benefits 16 Project Components 18 Summary 20 Agile Project Management