Tag: Agile

Attending the PMI Global Congress a couple of weeks ago reminded me that good ideas have staying power. There were several presentations on managing agile projects. As I listened, I was reminded of some of my past projects. Here are a few principles that have always worked for me and that can apply to agile projects.

Divide and Conquer

When I was first promoted to project manager, I was given a large new project to tackle. One of my colleagues told me that he was glad I was assigned the project. He said that he dreaded hearing of a new initiative, because he imagined a large dragon with its head peeking around the cubicle wall. I loved being a dragon slayer. I took that fire-breathing beast and cut it into several pieces, which we prioritized and completed more or less successfully. The “less” had more to do with not getting input from enough business subject matter experts, but the principle of breaking a large project into smaller chunks worked wonderfully.

The Project Management “what” vs. “how”

Deliverables have always counted more on my projects than activities and tasks. Deliverables focus on what needs to be done. Tasks provide actions – how each deliverable will be produced. In his Global Congress presentation, Why Agile Focuses on the Work-Breakdown-Structure and Frequent Communications, Clement J Goebel described the application of the Work Breakdown Structure (WBS) to the agile environment. I continue to believe that the deliverable WBS is one of the most useful concepts in the PMBOK, and I was delighted to hear how it applies to agile projects. As a project manager, I was the only one I knew who never used a Gantt chart. Sure I had activity lists, but each task was tied to a deliverable. A feature if you will.

Whose Project is it, anyhow?

I learned early in my project management career that trying to control scope was a losing battle – one I fought courageously, but never won. I learned that requirements, the basis of the project scope, needed to be prioritized by the business, not by me. On some agile projects features are prioritized by the role of the product owner, or business representative, not the acting project manager.

The Three “I’s.”

In the mid-90s I worked on a large project, one of the organization’s early “RAD” projects. RAD stood for Rapid Application Design/Development. We were trained by a consultant, who taught us the principle of the Three-I’s” – Iteration, Increment, and Involvement. We learned to do iterations, focusing on prototyping as a way to drive out requirements, although in all honesty, our iterations were more of a hybrid approach than is used today.  The increments were time boxes. Again, our time boxes were longer and looser than those today, but they certainly helped.

Perhaps the most important of the “I’s” was Involvement. We were fortunate, indeed, to have a full-time business expert move from her office in the merchandising department, where she was one of hundreds of buyers, to our IS area where our team was co-located. Her presence was invaluable to the project. Today we would probably call her the product owner, but we called her a BUC– Business User Coordinator.  She facilitated the requirements workshops, prototyping sessions, and user acceptance testing. As code was developed, she brought other client representatives into our area to show them prototypes and ensure they were on board with the new system. She participated in sponsor meetings, particularly when there was conflict between SMEs.

Our BUC worked in true partnership with the business analyst who ensured that the requirements were clear, that dependencies were taken into account, and that the design, code, and testing addressed the approved requirements. She also helped ensure that the interfacing systems and programs were completed, since there were many hundreds of programs that needed to be changed to accommodate the new system. There was virtually no conflict between these two roles. The term “collaborate” was not in our vernacular, but that’s exactly what they did.

Although the project was considered highly successful, one of the main missing ingredients had to do with me, the project manager. In retrospect, I should have spent more of my time removing obstacles (of which there were massive numbers) and let the team figure out how to get the project done. I should have worked for the team, instead of viewing the team as working for me.

Final thought. It seems to me that agile was built on some pretty solid principles, but these have been taken to a whole new level, vastly improving the software development process.

Don’t forget to leave your comments below

I have co-led the development team responsible for the writing of the first edition of PMI’s “The Standard for Portfolio Management”, first published in 2006. Its second edition was published in December 2008. The standard, as most standards on processes, explains how the process works (or should work). It does not explain how to put it together and implement it. So you have to look somewhere else for that.

Part of my work involves coaching organisations in implementing and improving their portfolio management processes. I religiously buy and read most of what is published on the subject in English or French. More than often, I had to conclude that the book or article I just read, I could have written myself… and done only a half-job doing so. Most of the literature on the subject I have seen up to now, talked a lot about mathematical scoring models, tools and techniques, addressing mostly the mechanics of the process. It never addressed the soul of the process, the humans, and how to deal with the main challenge of portfolio management in this area, namely: “How do we get a whole organisation to live a common vision and be truly aligned and willing to make it happen through project work”. Most of the books, that have been published, focus on best practices and techniques and do not discuss behavioural aspects as a key issue…..up to now! 

I have talked a lot about Agile/Lean project management in this blog, often explaining that it was addressing human aspects of project management very well. The Agile/Lean community has recently entered the portfolio management arena with two pretty good books, in that context.

The first book, published less that a year ago, is “Agile Portfolio Management” by Jochen Krebs (http://jochenkrebs.com/agileportfolio/), Microsoft Press, 2009 (ISBN-10: 0735625670). It gives a good introduction to Agile project management and then goes on to explain how portfolio management works and how to implement such a process. For me, a major contribution of this book is really how the author explains what can go wrong trying to do portfolio management using traditional project management techniques. This leads the author to redefine the three variables of the “Iron triangle” of traditional project management , Quality-Time-Cost, into a new set of three variables, Quality-Progress-Team Morale,  taking into account the importance of dealing with humans, their expectations and their perceptions. Jochen Krebs goes farther than philosophising on the subject; he provides metrics and explains how to measure, monitor and act upon all three variables. The first chapter of the book is titled “Motivations”, which tells of the importance the author gives the human aspects of portfolio management. Later on, he also gives a good view of the various portfolios interacting in an organisation (Project, Resource, Asset). He finishes the book explaining how you can extend the SCRUM technique from project to portfolio management.

The second book still smells of fresh ink, since it was published a few days ahead of schedule on August 19, 2009. This is “Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects” by product development guru Johanna Rothman (http://jrothman.com/blog/mpd/), Pragmatic Bookshelf, 2009 (ISBN-10: 1934356298). This is Johanna’s third book. Her first two, “Behind Closed Doors: Secrets of Great Management” (ISBN-10: 0976694026) and “Manage It: Your Guide to Modern, Pragmatic Project Management” (ISBN-10: 0978739248) are real gems and won prizes for their quality and usefulness. I do not hesitate to say that “Manage It” is one of the best books around for giving practical advice to project managers. Her last book, as her two others, is full of real life examples and little case studies that support the principles, concepts and techniques offered. “Manage Your Project Portfolio” is really a very complete “How-to” book on how to set up and manage your project portfolio. As Jochen Krebs’ book, this book addresses human aspects very well, including a very nice chapter dedicated to collaboration work in a portfolio management context (chapter 6). The chapter on metrics and measurement is also straight to the point (Chapter 10). Johanna’s top-notch practical advices and examples are found all over the place up to the last page, with a great last chapter titled “Start Somewhere…But Start”, one of the best things to do when it is time to go forward with taking charge of your portfolio of projects. A very inspiring book!

I do believe these are two books that, at last, give a more complete view of what is at stake when dealing with project portfolio management and will really help organisations move forward faster with implementing and improving this key business issue of the 21^st century, the Project Age.

Traditional project management involves very disciplined and deliberate planning and control methods. With this approach, distinct project life cycle phases are easily recognizable. Tasks are completed one after another in an orderly sequence, requiring a significant part of the project to be planned up front. For example, in a construction project, the team needs to determine requirements, design and plan for the entire building, and not just incremental components, in order to understand the full scope of the effort. Traditional project management assumes that events affecting the project are predictable and that tools and activities are well understood. In addition, with traditional project management, once a phase is complete, it is assumed that it will not be revisited. The strengths of this approach are that it lays out the steps for development and stresses the importance of requirements. The limitations are that projects rarely follow the sequential flow, and clients usually find it difficult to completely state all requirements early in the project. This model is often viewed as a waterfall.

Figure 1: The Waterfall Project Life Cycle Model

Today, business processes are more complex, interconnected, interdependent and interrelated than ever before. Additionally, they reject traditional organizational structures in order to create complex communities comprised of alliances with strategic suppliers, outsourcing vendors, networks of customers and partnerships with key political groups, regulatory entities, and even competitors. Through these alliances, organizations are able to address the pressures of unprecedented change, global competition, time-to-market compression, rapidly changing technologies and increasing complexity at every turn. Because of this multifaceted nature of businesses, projects that implement new business systems are also more complex.

For years, economists have been warning that success in a global marketplace is contingent upon the capability to produce small batches of tailored products on a tight schedule to meet growing demands in emerging markets. However, huge cost and schedule overruns have been commonplace in the past.¹ Looking at the numbers, the past project performance record is troubling:

• $80 -145 billion per year is spent on failed and cancelled projects (The Standish Group International, Inc.)
• 25% – 40% of all spending on projects is wasted as a result of re-work (Carnegie Mellon)
• 50% are rolled back out of production (Gartner)
• 40% of problems are found by end users (Gartner)
• Poorly defined applications have led to a persistent miscommunication between business and IT. This contributes to a 66% project failure rate for these applications, costing U.S. businesses at least $30 billion every year (Forrester Research)
• 60% – 80% of project failures can be attributed directly to poor requirements gathering, analysis, and management (Meta Group)
• Nearly two thirds of all IT projects fail or run into trouble. (See Figure 2 for the results of the 2006 CHAOS Survey.)

Figure 2: Project Performance Track Record – The Standish Group 2006 Chaos Report

Improving these performance records is a goal for any organization. However, if traditional project management is somewhat ineffective, it’s time to examine other methods of designing and delivering projects.

Agile Project Management

For projects involving a significant software component, traditional project management can be somewhat ineffective since the requirements are elusive, volatile and subject to change. An alternative approach, Agile Project Management (APM), is emerging in the industry. APM is a highly iterative and incremental process, where developers and project stakeholders actively work together to understand the domain, identify what needs to be built, and prioritize functionality.² Agile methods are used when these conditions are present: project value is clear; the customer actively participates throughout the project; the customer, designers, and developers are co-located; incremental feature-driven development is possible; and visual documentation (cards on the wall vs. formal documentation) is acceptable. Figure 3 depicts the Agile Development Model.

Figure 3: The Agile Project Life Cycle Model

The Agile approach consists of many rapid iterative planning and development cycles, allowing a project team to constantly evaluate the evolving product and obtain immediate feedback from users or stakeholders. The team learns and improves the product, as well as their working methods, from each successive cycle. After a streamlined planning, requirements definition and solution design phase is completed to get the project underway, iterations of more detailed planning, requirements, design, build and test take place in waves. This approach allows for immediate modifications of the product as requirements come into view. APM requires a dedicated full-time project team that includes a customer or end user, where team members work from the same location.

The Agile Project Management Environment

Unlike traditional project management, which emerged from the construction, engineering and defense industries and dates back to the 1950s, APM was born in the twenty-first century. In 2001, prominent software developers from both IT and software engineering domains, convened to arrived at a consensus on how the software development industry could produce better results. This meeting produced the Manifesto for Agile Software Development, which states that the “highest priority is to satisfy the customer through early and continuous delivery of valuable software.”³

APM development is conducted collaboratively, with a small co-located team. This core team usually consists of two developers who write code in pairs (for quality control), the customer/end-user, IT architect(s), a business analyst and a project manager. The work is accomplished through a series of sessions where the team writes code, then tests working modules of the system and repeats the process. There is minimal documentation as the team relies almost exclusively on informal internal communication. Again, this differs from the traditional approach where a considerable amount of time is invested in planning and a significant amount of requirements documentation is produced. The Agile team identifies and prioritizes the features based on business value, and after high-risk components of the system are produced, works on the highest value features first. This approach works if the solution can be delivered incrementally to the customer. If this is not possible, features still can be built incrementally and then integrated into the first release of the system.

Agile Management Components

There are several key elements that provide the basis for APM. It is important to note that these techniques can also be used in traditional software development methods to improve project performance. They are:

1. Visual control. This is a “cards-on-the-wall” method of planning to assist a team in organizing the work of the project. For example, one successful Agile project team placed different color groups of cards that represented the features of the solution on the wall. The features that were designed, developed, tested and in production were one color, the features that were designed, built, tested but not yet put in production (but ready to go) were another color. The team was able to see at a glance where they were with each feature set. Visual control is a valuable technique for all projects, since it ensures that every member of the team views the project the same way.
2. Co-located high-performing teams. In Agile development, all the key team members are co-located, including the customer/end-user, preferably in a work room. This approach greatly increases the quality of coordination and communication. However, this may represent a significant cultural change for IT developers. In traditional development methods, the developers typically work independently, and rarely interact with the customer until the solution is fully developed. Since project managers are responsible for building a high performing team, they need to ensure everyone is working well together and that they have been assigned developers who truly can work in this collaborative manner.
3. Test-driven development. In cases when the customer is having a difficult time articulating requirements, Agile teams often use test-driven development. Using the same successful Agile project team mentioned above as an example, the test cases were often developed first, and then the team backed into the requirement. This obviously requires more iteration between requirements, design, development and test. The entire four-stage cycle is collapsed. In any case, Agile teams almost always develop test plans at the same time they define requirements; if a requirement isn’t testable, then the requirement is not yet fully developed. This is a best practice that can be used in traditional development to ensure requirements are complete, accurate and testable.
4. Adaptive control. Everyone on the team is constantly adapting, which may make some team members nervous, especially those that crave structure. Because of this dynamic environment, the project manager needs to be seen as a leader, not a taskmaster. Instead of setting rigid instructions for the entire team to follow, the project manager facilitates the team in establishing working relationships, setting ground rules and fostering collaboration. Agile team members continuously adapt to improve their methods as they incorporate lessons learned from the previous cycle into the next iteration, also a best practice for any project.
5. Collaborative development. APM relies on collaboration among all team members to deliver the results, capture candid feedback and implement learnings on the next iteration of the solution. This is one of the strengths of APM – constant feedback and improvement. The project manager completes the initial planning and the business analyst defines and prioritizes the solution features in collaboration with the customer and technology representatives. Then the Agile project teams collaborate on the design, development, testing and reworking of each incremental build. It is this constant collaboration with the customer that promotes project success.
6. Feature-driven development. This practice greatly reduces complexity, because it allows the team to focus on one feature and only one feature at a time. For example, one team is working on Feature #4 and that’s the team’s only focus. They don’t concern themselves about Features #1-3. It is the business analyst and project manager who ensure the next feature in the backlog is truly the next priority, based on business value and risk. Typically, high-risk components or core infrastructure pieces are built first, and then everything else is prioritized based on business value. The goal is to build the feature-driven components with only a one-way dependency to the core system; therefore, specialized components are independent of each other and can be created in any order or even in parallel.
7. Leadership and collaboration rather than command and control. “The principles of APM are timeless. If you look at APM, it links much more closely to leadership. It addresses a lot of the steps that facilitate leadership much more than traditional management,” says Sanjiv Augustine, Managing Director of the Lean-Agile Consulting Practice at CC Pace Systems in Fairfax, VA. The project manager works with the client management, the IT management and the key stakeholders to ensure they know the project’s status. Additionally, the project manager removes any barriers hindering the core Agile teams. The business analyst manages the business benefits of the project and continually focuses the Agile team on the business need.
8. Move from C (cost) to R (revenue) focus. Features are prioritized based on value, such as increased revenue or market share. It’s the business analyst’s role to ensure the Agile project team is not investing too much into the development of the new solution. If so they will have eroded the business case and the project will cost more than the organization will gain. While the project manager focuses on project costs, the business analyst focuses on the total cost of ownership that includes not only the development or acquisition costs of the new solution, but also the cost of operating the system after it is deployed.
9. Lessons learned. After each cycle, the team holds a lessons learned session to determine what they can do better on the next iteration. As the team learns, it adapts how the members are working together to continuously improve team performance.

The Value Proposition

“The traditional project management approach,” Augustine reports, “is a linear approach where you try to get it all done at one time. You do a lot of very detailed planning at once up-front and then deliver it in what’s known as the ‘Big Bang’. That industrial age thinking has spilled over from software development to other projects as well.” This is the heart of the difference between Agile and traditional project management.

The ‘Big Bang’ now comes from the greater flexibility and collaboration APM provides. “Just enough” planning is done up-front. As each increment of the system is built, the team gathers input and learns from customer feedback. Since the customer sees and/or experiences a working prototype, he or she is better able to refine or redefine requirements and describe to the team what the organization really needs. The Agile method embraces changes that add value, and reduces the cost of change through iterative development. Making changes to a small module is very cost-effective, compared to designing and developing a huge system and then trying to make changes to it.

Can Agile Project Management Work?

“At its heart, project management, whether you are doing traditional or Agile has very similar principles. It’s about doing a good job for the customer. It’s about leading a team. It’s about delivering measurable business results,” says Augustine. Many of these principles or practices can be implemented into most team-structured environments. Yet, some project management professionals may discard the principles of Agile management if they are unable to adopt all of the components and practices. This is a mistake. For example, what happens if they cannot get the user to sit full-time with the team in the workroom? It doesn’t mean they can’t incorporate some of the other pieces of Agile management such as visual control and feature-driven development. Besides, even if a user cannot be involved on a full-time basis, most users are willing to participate on the team, especially during the testing and feature prioritization. The rest of the time, the business analyst can represent the user while the full-time core team continues to work together.

Incorporating Agile management techniques into projects fosters a focus on the benefits of each feature. In traditional project management, the teams strive to finish the project on time and under budget and often lose sight of the overall benefits the entire effort is intended to bring the organization. It’s important to remember the strategy the project is expected to advance as well as the total cost of ownership and not just the project costs. In this way, the benefits of the project will be obvious, whether the team is constructing a building or developing a new business solution.

¹ New York Times, 11 July 2002 “Cost overruns (totaling hundreds of billions of dollars) for large public works projects have stayed largely constant for most the last century.”
² Ambler, Scott W. Agile Analysis. http://www.agilemodeling.com/essays/agileAnalysis.htm
³ www.agilemanifest.org/. Accessed April, 2007

). She is the author of Managing Complex Projects: A New Model (Management Concepts, October 2008). Since 1973, Management Concepts, headquartered in Vienna, VA, has been a global provider of training, consulting and publications in leadership and management development. Management Concepts is a Gold International Sponsor and an IIBA Endorsed Education Provider For more information, visit http://www.managementconcepts.com/ or call 703 790-9595.

 

 

---

Kathleen B. Hass, PMP is Senior Practice Consultant for Project Management and Business Analysis, and Director at Large and Chapter Governance Committee chair for the International Institute of Business Analysis (http://www.theiiba.org/