Agile Practices for Waterfall Projects: Shifting Processes for Competitive Advantage
352
Agile Practices for Waterfall Projects: Shifting Processes for Competitive Advantage
352eBook
Available on Compatible NOOK devices, the free NOOK App and in My Digital Library.
Related collections and offers
Overview
Product Details
| ISBN-13: | 9781604277326 |
|---|---|
| Publisher: | Ross, J. Publishing, Incorporated |
| Publication date: | 10/01/2012 |
| Sold by: | INDEPENDENT PUB GROUP - EPUB - EBKS |
| Format: | eBook |
| Pages: | 352 |
| File size: | 7 MB |
About the Author
Read an Excerpt
CHAPTER 1
Why Agile Now?
Project managers are like sharks. We have to keep swimming to keep alive and employable in a constantly evolving workplace. Despite our occupation's solidified need to brace ourselves and our teams to avoid unnecessary changes, the reality of the future looms clearly: projects will be managed with a hybrid process of Agile (flexible) and formal (traditional) practices. So, we need to think about how to evolve our approach to managing projects. The project managers who are visionary and practical enough to learn how to do this will have a huge career advantage over those who lag behind.
To understand how to update our own skills in the most efficient matter, we will need to consider these five questions:
1. Why change our project culture now?
2. How do we blend new Agile ideas into familiar, traditional project management processes?
3. What additional skills do we need as project managers if we make these changes?
4. What background information and sales techniques do we need to convince those above, below, and next to us in the organizational hierarchy to support an evolution to Agile?
5. What changes need to happen in our organization to allow Agile and traditional approaches to merge?
Why now? The answer is obvious if you look around to see the challenges that organizations are facing in today's economy. First, there is a tremendous push to accelerate the time to market. Second, we have to enhance our own ability, and that of our team, to manage quickly changing priorities and requirements. The world has changed dramatically, and there is too much competition to succeed by merely producing things faster and cheaper. We need to focus on adding innovation and creativity to our products and services.
Adding to these challenges is globalization, when in order to expand markets our organizations are opening branches all over the world, or perhaps adding remote teams in an attempt to reduce costs. These realities add the burden of managing projects and project teams within cultures foreign to our own, adding more layers to the stack of issues we already juggle on a daily basis.
Companies also face new issues of employee retention and engagement. Currently, with unemployment rates high in many parts of the world, people are staying put. But recent surveys estimate that about 60% of employees plan to look around once the economy stabilizes. Since these team members may not be invested in the company long term, it stands to reason that they may not be fully engaged and productive.
An additional consideration is the need to plan for New Millennium, or Generation Y, people coming into the workforce. When surveyed, their "work ethic" is self-fulfillment; they like collaborative leadership, and they view change as inevitable and increasing. This new generation of workers is already bringing a mindset tuned to Agile values with them. Rather than needing to educate and convince them to adopt Agile principles, the focus will shift to convincing them that our organization operates in harmony with a belief system that they already have.
The reason that we, as project managers, need to make our project processes more Agile, is not because it is the "flavor of the month," but because it allows us to:
• Drive business agility,
• Respond to a fast-changing business environment,
• Increase alignment of projects to business strategies to create the best return on investment, and
• Impact employee hiring and retention issues.
We achieve these goals by becoming more flexible in the way that we manage projects. Do not be concerned that the word "Agile" has become connected to the software industry. In its pure form, the one we will use, it means to be more versatile and able to adjust quickly to change. Some organizations have been using Agile approaches for over 10 years with amazing success.
John P. Kotter, a professor at Harvard Business School, who is regarded as an authority on leadership and change, and James L. Heskett, professor emeritus of Harvard University, wrote Corporate Change and Performance. They examined more than 200 organizations, including Hewlett-Packard, Xerox, the Investment Company Institute (ICI), and Nissan. They found that in companies with a strong and adaptive Agile culture:
• Revenue grew more than 4 times faster,
• The rate of job creation was 7 times higher,
• Stock profits grew 12 times faster, and
• Profit performance was (take a moment and get a number in your mind, then read on) 750 times higher than those companies who were less nimble. Would you guess even close to that number?
Thus, what we need to discover is a way to add Agile to organizations, but not wipe out the traditional processes sometimes known as "Waterfall" and replace them entirely, due to the huge investment we have in our current processes, training, and certifications. We can add the most appropriate parts of the Agile philosophy to specifically address some of the major problems facing our employers and ourselves, not only for software developers, but in all parts of the organization.
In recent years, there has been a heated debate between the Agile and Waterfall proponents, which often became quite passionate. On the one hand, the software development world has found a much needed solution to their woes in an Agile methodology, but other departments in the company may feel it is not robust enough to meet their needs. It is true, at first glance, that Agile and Waterfall may appear to be two competing, or even warring, project management approaches that would seem an unlikely mix. But when you know the evolutionary history of project management and the business theory on which it is based, it is easy to see that both Agile and Waterfall are more like loving siblings who come from the same hearty stock.
How do you justify moving to a more Agile technique when your company or industry is more heavily invested in a traditional project management approach? We need to remember that one of the most important focuses for all of us as project managers in today's world is to be innovative. We all want to explore new ideas and find different ways to support our executive management and teams, and to find better ways to do projects. So what are the big project problems that Agile solves?
Three Current Project Questions
There are three big questions to ask about your current projects. Be honest! First, have you ever had a project finish pretty much on time and pretty close to budget, but after it was all over, the customer was not thrilled with what you delivered? With the Agile methodology, your customer is involved, sitting next to you, being a part of meetings from the beginning of the project to the end. The customer approves a few features and functions every 1 to 2 weeks. So, you are confident that you know exactly what they want before you build it. If they are unhappy or not totally pleased along the way, you know it immediately — in plenty of time to fix the problem.
Here's the second question. Have you ever run out of time and money, but the project was not complete? If you answered yes, you are in the same situation as the majority of project managers. With Agile, you are working first on the features and functions that bring the most business value and are the most important to the customer. If you run out of time and money, and don't get finished with the entire list of requirements that may appear to be ideal, at least you have a working product or service that includes the most valuable parts: finished, tested, and useable or sellable.
The third question: Did you ever feel you could solve a project problem better than your boss, but your corporate roles have such ironclad boundaries that you are not asked or allowed to be a part of solving problems or making suggestions? With Agile, you are part of a dedicated, self-organizing, self-directed, crossfunctional team that is authorized and empowered to run the project. The idea is that the people actually doing the work know the best way to solve problems that arise. Your boss, or even you as the project manager, have new roles — to remove obstacles and roadblocks to success for the project team. Most people are more motivated by achievement, by being appreciated and valued, and being free to work on interesting things, than by money. Today's teams are made up of smart people. You do not need to hand out work to them one tiny bit at a time. For the most part, teams are capable, willing, and able to know what to do and do what it takes to get the work of the project completed. They can find solutions to hard problems on their own.
If you answered "Yes" to any of the three questions, you are an honest project manager. We have all had these things happen if we've spent any time actively working in the profession. If you have had any of those problems, you should consider adding Agile to your projects to create a hybrid approach. In fact, Agile is addressing and solving quite a few common project management issues. As you read further, you will probably see that many of your own or your team's daytoday frustrations can be solved, or even avoided in the first place, with a more Agile process.
Agile has been around for more than a decade, and most project managers have at least heard about it. Agile teams on average provide products and services faster, at a higher level of quality, at a lower price, and with more satisfied customers. And the people who work on these teams are happier and stay with the organization longer.
Agile simply means that you are more flexible in your approach to doing projects. You are able to adapt and change your project quickly when your project team, or your customer, finds it necessary. In 2008, the research group QSM Associates assessed the performance of 29 Agile development projects against 8,000 plan-based or Waterfall averages in three key areas: productivity, time to market, and quality. They found that the Agile projects were:
• 37% to 50% faster in delivering software to market,
• 16% to 35% more productive as a team, and
• Able to maintain normal defect counts despite significantly shorter schedules to complete the work of the project.
Statistics such as these have captured the attention of management level decision makers around the world.
Project Management Certifications
Project management in a traditional fashion has been around in one form or another for over 100 years. You might hold a certification such as PMP(Project Management Professional), CAPM (Certified Associate in Project Management), PgMP (Program Management Professional), PMI-SP(Project Management Institute Scheduling Professional), or PMI-RMP(Project Management Institute Risk Management Professional).
If you are European, you might be a PRINCE2 (Projects IN Controlled Environments 2) Registered Practitioner. There are hundreds of thousands of certified individuals who have had to work hard to learn PMI or PRINCE2 processes. They scheduled, took, and passed rigorous tests (perhaps after several tries). They worked to get additional training and experience to maintain their status, and most importantly, they used the principles successfully, for the most part, for a number of years.
A newer certification is the PMI-ACP (Project Management Institute Agile Certified Practitioner). The Project Management Body of Knowledge — Fifth Edition includes Agile in a more integrated way than earlier editions. Just as there is a PMI Construction Standard, Government Extension, and Project and Portfolio Standard, to mention a few, you may see an Agile body of knowledge standard at some point to support the new PMI-ACP certification.
Be aware that among other criteria, the PMI-ACP requires experience working on projects using an Agile approach, or time spent on an Agile project team within the last three years, in order to qualify to take the exam. When you begin to include some of the new ideas in this book with your team, be sure to record those hours spent in order to meet the exam qualification requirement. You can view the other requirements at www.pmi.org.
Part of earning the PMI-ACP certification is a three-hour test, and once you pass it you need 30 Professional Development Units (PDUs) from training, or other experiential activities, to keep your certification active, rather than the 60 PDUs required by some of the other PMI certifications. If you are already a PMP certificant, the good news is that PMI-ACP PDU hours and PMP PDU hours can overlap. In other words, you can count the same hours toward recertification for both, as long as the subject matter of the training is appropriate.
So, that is the PMI-ACP certification, but what is Agile itself? Agile means that your team is more pliable. You are able to adapt and change the project quickly when the project team, the product owner, or the customer finds it desirable. The information technology world, in particular, is moving toward a more flexible approach to project management with fewer formal documents and less administrative overhead, while other parts of the organization may still use the more familiar, traditional project management processes.
Agile is in all of our futures. Even the most traditional project managers and organizations who insist on abiding by only the processes distributed by PMI will need to be ready to adjust their day-to-day actions. Agile is becoming mainstream, and all departments and industries are being touched. What can we learn from these new, Agile processes being used successfully by software developers? Is there a way that we can blend their new approaches into the more traditional project plans, which we as project managers must have to manage our own projects, to give us faster and more measurable results? How can we mix Agile ideas and processes into our more traditional Waterfall team's current way of doing things?
One of the first concerns to surface when considering Agile is that organizations have spent a lot of time and money accepting, training, and implementing their current project management processes. So, they are going to be less than anxious to dump that all overboard and start fresh. Our goal is to keep what works about the traditional processes and augment what does not, ending up with a hybrid approach that uses the best ideas from each practice.
Scrum advocates need not be concerned that we are speaking heresy. Scrum, which is an excellent and successful approach to project management and software development, is covered in Chapter 17, "What Are Scrum, XP, and DSDM?" Be assured that the hybrid approach that we will be discussing will not alter or infringe on Agile software development methodologies, but rather lead us to understand, support, and work in harmony with them throughout the other parts of the business environment.
The Genesis of Project Management
The traditional project management approach has been in place to some extent for a long, long, long time. As far back as 5,000 years ago, when the Egyptian pyramids were being built, there were unskilled day laborers doing the physical construction work who needed to be managed. Actually, most were farmers who owed annual taxes to the Pharaoh. The tangible items of value or agricultural products used as payment were of some interest to the crown. But that payment form really did not work to fulfill the Pharaoh's main vision: an elaborate and impressive tomb to ensure that his spirit would be safely transported to the next world.
A better solution to the tax issue was to have the farmers pay their obligation in the form of a certain number of days of labor, giving the Pharaoh the workforce needed for his construction projects. They probably had architectural drawings back then, and you have to imagine that someone smart had figured out the sequence in which tasks should be done, planned the materials, and then listed the jobs to be done on a daily basis. There were also the challenges of managing a large, uneducated, unmotivated, and disengaged workforce.
If we really knew what happened with project managers in ancient Egypt, we might wonder if the pyramids originally started out to be a rectangular tower, just like the architect's drawings showed on the papyrus scroll, accompanied by his technical and functional requirements written in colorful hieroglyphics. Like on our projects today, constraints and resource problems probably came up somewhere around the mid-point of the endeavor.
You can easily imagine the Egyptian project manager ranting to his construction foreman, "I knew we didn't have enough stones for this project, but the Pharaoh just wouldn't listen." So, instead of building a tower like the architect planned on the original drawings, he ended up working with what they had and redesigned the project "on the fly" to end up with a pyramid-shaped deliverable. The results have lasted until the present time, so this project management approach cannot be called a failure. But still today many modern projects are not completed to match the original vision.
(Continues…)
Excerpted from "Agile Practices for Waterfall Projects"
by .
Copyright © 2013 Barbee Davis.
Excerpted by permission of J. Ross Publishing, Inc..
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.
Table of Contents
Preface ix
About the Author xi
Chapter 1 Why Agile Now? 1
Three Current Project Questions 3
Project Management Certifications 5
The Genesis of Project Management 6
The Need for Change 8
References 10
Chapter 2 What Is Agile? 11
"Big Agile" and "little agile" 11
Iterative and Incremental Development by a Dedicated Team 13
Embracing Change 14
Working Closely with Your Customer 16
References 17
Chapter 3 Where Did Agile Ideas Originate? 19
Frederick Taylor 19
Frank and Lillian Galbraith 21
Henri Fayol 22
Henry Ford 23
Henry Gantt 24
Winston Royce 25
Peter Drucker 25
Eliyahu Goldratt 26
Abraham Maslow and Douglas McGregor 27
James Reddin 29
Hirotaka Takeuchi and Ikujiro Nonaka 29
Sakichi Toyoda, Kiichiro Toyoda, and Taiichi Ohno 30
References 35
Chapter 4 What Are Agile Practices and How Do They Work? 37
Find Errors Early 41
Prototyping 43
Early Customer Involvement 45
Agile vs. Waterfall 48
Plan, Do, Check, Act 49
References 53
Chapter 5 What Are Some More New Agile Concepts? 55
Favor the Simple Over the Complex 55
Phase-to-Phase Relationships 58
The Non-Software Agile Process 59
User Stories 62
Progressive Elaboration 67
References 70
Chapter 6 Should My Projects Be Agile? 71
Waterfall Process Candidates 74
Agile Candidates 75
The Agile Evaluator 77
Hybrid Products 80
The New Marketing Strategy 82
The Google Car 83
Hybrid Medical Devices 85
The New Product or Service Measurements of Quality 88
References 90
Chapter 7 How Does an Agile Team Get Started? 91
Create Team Operating Rules 91
Select Techniques to Reach Consensus 93
Confirm Initiating Processes 95
Planning Agile Work 96
Iterative Development and Risk 97
The Agile-ish WBS 98
Moving User Stories Into Iterations 101
Chapter 8 How Do Agile Teams Estimate? 107
Team Estimates 107
The Fibonacci Sequence 108
Planning Poker 111
Team Estimation Game 113
Dog Estimates 115
T-shirt Sizes 115
Selecting Tasks 115
Tracking Agile Progress 116
Daily Agile Stand-up Meetings 119
References 122
Chapter 9 What Agile Tools Are Important? 123
End-of-Iteration Practices 123
Velocity 124
Social Loafing 129
Interacting with Traditional Teams 132
Getting Started with Agile 133
Iteration Time Breakdown 136
References 138
Chapter 10 How Does Agile Scale to the Enterprise Level? 141
One Backlog-One Team 141
One Backlog-Mixed Teams 143
One Backlog-Many Teams 144
Multiple, Independent Product Backlogs 144
Separate, But Cooperating Teams 146
Collocated Teams 146
Chapter 11 How Do I Work With Distributed Teams? 151
Distributed Teams 151
Casual Conversations 154
Story Cards 155
Time Zones 156
Language 156
Communications Tools 158
Work Tracking Tools 160
Remote Daily Stand-ups 160
Travel 161
The Lone Expert 161
References 162
Chapter 12 What Do I Use for Agile Documentation? 163
Earned Value Method 163
Agile Earned Value 165
Software Documents 169
Burndown Chart with Scope Changes 171
Burnup Chart 174
Cumulative Flow Diagram 174
References 176
Chapter 13 What Needs to Change in My Own Skill Set? 177
Self-managed Teams 177
Collocated and Dedicated Teams 178
Facilitation Skills 179
Sales Skills 180
Coordination Skills 181
Collaboration Skills 181
Team Building Skills 182
Conflict Resolution Skills 182
Training Skills 184
Group Decision Making Skills 184
Social Styles Skills 185
Servant-Leader Skills 192
Millennium Management Skills 194
Process Tailoring Skills 199
References 200
Chapter 14 What Needs To Change In My Business Skill Sets? 201
Six Changes to Embrace 201
Cost of Failure 203
Aligning Projects to Strategic Objectives 205
Maximizing Revenue Streams and Flexibility 208
Handling Cancelled or Deferred Projects 211
Agile Budgeting and Forecasting 212
Actively Seeking New Technology 214
Documenting Team Authority 218
References 220
Chapter 15 What Shifts in Business Will Affect Me? 221
Common Team Workspaces 222
Design That Matters: Junkyard Incubators 225
Microsoft Research Division: Space Design 226
Steelcase, Inc.: Furnishings Design 226
Skype: Virtual Space Design 227
Explicit and Tacit Knowledge 228
References 231
Chapter 16 What Changes Are Needed in My Organization? 233
Authorization 234
Resource Management 235
Communications 236
Metrics 236
Contracts 237
High-level Involvement 244
Cost Accounting and Other Reports 245
Team Member Reactions 247
Radical Management Shifts 247
The Growing Importance of Intangible Assets 249
A Need for PMO Refocusing 249
A Change in Human Resources Practices 252
References 254
Chapter 17 What Are Scrum, XP, and DSDM? 257
Software Development 257
Scrum 259
Extreme Programming 264
Dynamic Systems Development Method 270
References 275
Chapter 18 What Are Lean, Kanban, Crystal, and Other Agile Practices? 277
Lean Manufacturing 277
Kanban 278
Toyota Production System 283
Lean Software Development 284
Rational Unified Process 284
Crystal Methodologies 287
Feature Driven Development 288
References 290
Chapter 19 How Do I Jumpstart Change? 293
Choosing a Pilot Project 293
Train the Product Owner 294
Sell Up, Down, and Sideways 294
Talk the Talk 297
Learn the Change Process 298
References 300
Chapter 20 Who Has Made Agile Work? 301
CH2M Hills Rocky Flats Project 301
Boeing's 787 Project 303
The Kauffman Performing Arts Center Project 307
AccuRev Agile Sales Team 308
GVK's Mumbai, India Airport Project 308
The Sydney Opera House Project 310
References 312
Chapter 21 Parting Advice 315
Glossary 321
Index 333