Author: Tim Runcie PMP, MCP, MCTS, P-TSP, MVP

In this first article in a series you’ll learn about the agile method and related agile technologies for project management with a focus on scheduling technologies, especially Project Online, Project Server and Project Desktop (Standard and Professional). My goal is to help you gain insight and come to your own conclusions about ways that agile can help you — and anyone else in our project and portfolio management (PPM) community of practice. I base my opinions and observations on 25-plus years of working within scheduling, project management offices (PMOs) and the agile space. The series isn’t intended to be definitive — only a bridge between methodology and the PPM technologies we use today. The Agile Method and Agile Disciplines The misconception that agile is just for software development is prevalent. On the contrary, agile has been used for manufacturing, engineering, construction, testing and any other project process that requires iterations or iterative working sessions to reach a final result. What’s exciting about agile technology and its underlying methodology is that it brings an environment for interaction to scheduling and scheduling technologies. Agile allows complex or highly interactive reviews and working iterations with stakeholders and project teams, producing a better product or result. While that result may not have been the original thought or intention, it delivers the value needed by the customer. What Agile Is So what is agile? Before we delve into the layers of definition, you should have the backstory. Understanding where agile came from will help to identify what it is, how it works or can work for you, and what parts or elements you can leverage to improve your projects. Although there are plenty of great articles out there on the topic, let me summarize the basics of where agile came from. Before it came to be called “agile,” this approach was formally discussed during the explosion of software development projects back in the 1970s. One of the main people who helped shape the discussion of agile was Dr. Winston Royce. In 1970 he presented a paper titled, “Managing the Development of Large Software Systems.” In his 11-page paper Royce criticized the then-current practice of sequential development (waterfall) and asserted that in developing software, there are only two “essential steps” common to all programming work: analysis and coding. Nothing else — defining system requirement and software requirements, doing program design, etc. — is vital to the process and, in fact, “drive up the development costs.” As he eloquently put it, “Customer personnel typically would rather not pay for them, and development personnel would rather not implement them. The prime function of management is to sell these concepts to both groups and then enforce compliance on the part of development personnel.” Royce recommended against sequential development, in which all requirements are identified up front and then scheduled, for two key reasons. First, there’s a lack of communication between the specialized groups that must be involved. Second, up-front planning can’t account for all the functionality that may be required by the time the end of the project is in sight. By applying a more agile or iterative approach, a team could describe the goal of a solution, then allow the team members’ creativity and flexibility to guide the project as they adapt or modify the solution based on business realities or requirements that might change or need to change by the time the project is due for release. What’s ironic is that Royce’s paper led to the framing of exactly what he was railing against: the waterfall model of software development. While Royce wasn’t the only one wrestling with this concept of inherent fluidity in programming projects, his paper definitely hit the nail on the head and continued to influence conversation among software engineers as it evolved into full-fledged and different methodological approaches to project work that have been used over the last 45 years. Why to Consider Agile Agile methodology — whether you use it for development projects or not — provides the opportunity to review and assess the direction of a project throughout its lifecycle. You do these activities through regular stages of work, known as “sprints” or “iterations.” At the end of these segments, teams must present a potentially shippable product increment or deliverable functional value. In fact, the prioritization is on delivering functionality, which you can validate sooner rather than later. By having teams focus on the regular abbreviated work cycles, as well as requiring a functional product that must be delivered in those cycles, agile methodology gains its distinctive trait of being “iterative” and “incremental.” In a waterfall approach, project teams spend time up front to map out requirements, document and validate those requirements and then work to deliver on those requirements. What is helpful to understand is that requirements gathering and validation exist in both methodologies. However, in an agile paradigm, every aspect of product development — requirements design, testing, etc. — is continually revisited throughout the lifecycle. When a team stops and re-evaluates the direction of a project every two weeks (or whatever timeframe is assigned to the iteration or sprint cycle), there’s always time to make adjustments and steer the project in another direction. In the next diagram, you can see how the top portion attributed to a waterfall planning cycle compares to the iterations in the bottom part that has several changes and adjustments. While this picture may be a bit humorous, consider how the Microsoft Project team used to deliver their projects. They would begin the process early with ideas of what of value would make their scheduling technology more attractive. Then, they would survey customers and partners to identify pain points, requirements and functionality that would help improve their technology. Then they’d spend the next three years building this functionality and release the product. In that three-year development cycle, they fine-tuned but mostly focused on the core functionality that was requested. After talking with stakeholders, they would release the latest upgrade and say, “Ta-da! This is what you told us three years ago. Do you like it?” As you know, the pace of technology, platforms and functionality changes monthly, if not weekly. (Think about the mobile device world.) This is why services such as Office 365 and the cloud allow instant visibility to iterative builds, releases, analytics and a much faster release time. It also why now, by managing work in a more iterative and dynamic way, the Microsoft Project team can produce solutions that better meet customer needs. Microsoft is hardly alone in adopting this methodology. Every major software company now works in a more agile fashion to meet the millennial appetite for faster gratification and more productive value for technical solutions. As a result, this “inspect-and-adapt” approach to projects greatly reduces both development costs and time to market. In the field of software development this approach is even more valuable because teams can develop software at the same time as they’re gathering requirements. Project teams no longer are stuck, when requirements are unclear or customers aren’t sure; the team can prototype the work and hold working iterative design-and-build sessions to help refine the solution or product. Senior stakeholders, executives and customers no longer have to wait for a solution. They can be sure that time-phased limitations exist so that value or functionality is continually produced vs. waiting for a final product before they get to see if the requirements were met. The ability to re-plan and refine creates a higher sense of satisfaction for both project teams and customers. Ultimately, solutions are delivered that can adapt to changing market conditions, new technologies or emerging requirements. 12 Principles of Agile In agile development, 12 primary principles guide the project teams, interactions and methodologies for delivery: Customer satisfaction is built by early and continuous delivery of valuable software. Teams welcome changing requirements, even in late development. Working software is delivered frequently (weeks rather than months). Close, daily cooperation occurs between business people and developers. Projects are built around motivated individuals, who should be trusted. Face-to-face conversation is the best form of communication (co-location). Working software is the principal measure of progress. Sustainable development — the ability to maintain a constant pace — is factored in. Teams pay continuous attention to technical excellence and good design. Simplicity — the art of maximizing the amount of work not done — is essential. Best architectures, requirements, and designs emerge from self-organizing teams. Regularly, the team reflects on how to become more effective and adjusts accordingly. These principles were defined in a 2001 meeting in the Wasatch mountains of Utah in which 17 insightful software developers came together to discuss lightweight development methods (and ski). From that meeting the group published the “Manifesto for Agile Software Development.” The manifesto stressed the pursuit of “uncovering better ways of developing software by doing it and helping others do it.” That challenge brought them to value individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. Other important values that surfaced: The ability of self-organization and motivation, as well as co-location and “pair” programming; the presentation of working software to clients rather than the presentation of documents; light requirements collection at the beginning followed up by continuous customer or stakeholder involvement; and quick response to change and continuous development. As Jim Highsmith, one of those original participants, explained in a history of the manifesto, “The agile movement is not anti-methodology; in fact, many of us want to restore credibility to the word methodology. We want to restore a balance. We embrace modeling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely used tomes. We plan, but recognize the limits of planning in a turbulent environment.” Eventually, some of the participants formed the Agile Alliance, a non-profit organization that continues to promote software development according to the manifesto’s values and principles. Clearly, this 14-year initiative brought with it a passion for delivering value and results to technical development while avoiding the heavy and sometimes dogmatic approaches of the past. Making Sure Agile is the Right Fit A more dynamic and iterative approach to projects meets business needs when: Designs, solutions and product are done in an iterative and highly interactive approach; and Focusing on less documentation (up front) and more interaction and analysis of the requested solution makes time to adjust and make changes. Development is “time-boxed” — or allocated fixed amounts of time. I can’t state this part strongly enough. Without that in place you risk the prospect of endless rounds of changes and the possibility of working on a product that doesn’t market or user needs within a reasonable time. So it’s important when considering agile to ascertain when an agile process or methodology is the right fit for your project. For example, it doesn’t make sense to use the agile process when the ultimate product is already well specked out, such as the writing of a technical book or documenting a project. I’ll cover this topic more later in the series. The Many Methodologies of Agile A common metaphor for laying out agile methodologies is to show an umbrella under which are the various disciplines: Scrum, Kanban, dynamic systems development method (DSDM), feature-driven development (FDD), adaptive software development (ASD), eXtreme programming (XP), Lean and Crystal. (I’ll also go into more detail on some of these in future articles too.) Each discipline has its own strengths and merits. By the time this series is over, you’ll better understand how to leverage at least some of these methodologies — or elements of them — to fit your organizational needs. What’s This Have to Do with Scheduling Software? Whether you’re tracking tasks, bugs, epics, features or user stories, this action is commonly referred to “demand.” You can manage demand with many different tools and approaches. Some are designed to support the technical teams in a familiar platform such as Team Foundation Server (TFS), Version 1, Jira or other development tools. However, when you work in a PPM environment, you need to address demand — that is, work or tasks — in a forecasting tool that helps you look at time, costs, and resources in a time-phased breakout. In this situation, scheduling technologies such as Microsoft Project and Project Online really stand out. The secret is to create a planning and brainstorming process in which possible details aren’t found in Project but are tracked in their own respective tools. Then you use Project as a forecasting and demand-management or resource-capacity planning tool to keep track of the remaining work or count of tasks completed or remaining. Microsoft certainly isn’t sitting still. Future iterations of its Project portfolio will see increased support for agile project management. In our next article we’ll explore what features Project offers today — including templates — that allow you to become an agile project manager. Have questions? Make sure to post them in the comments below. Image Source