The Pros & Cons of Adhering to a Single 'Best Practice' Framework: Stories from the Trenches
•Download as PPTX, PDF•
1 like•345 views
This document discusses different project management frameworks and when different approaches are best used. It provides an overview of the waterfall and agile approaches, comparing their key aspects such as scope, planning, roles, and documentation. The document then discusses hybrid approaches and considers when waterfall, agile, or a hybrid may be most suitable for different project scenarios. It concludes by providing tips for making a hybrid approach work successfully, such as promoting communication, making metrics visible, and allowing flexibility within fixed milestones.
More Related Content
Similar to The Pros & Cons of Adhering to a Single 'Best Practice' Framework: Stories from the Trenches
Similar to The Pros & Cons of Adhering to a Single 'Best Practice' Framework: Stories from the Trenches (20)
More from Beyond20
More from Beyond20 (16)
Recently uploaded
Recently uploaded (20)
The Pros & Cons of Adhering to a Single 'Best Practice' Framework: Stories from the Trenches
- 1. #b20Con ITSM DEVOPS CONFERENCE The Pros & Cons of Adhering to a Single Best Practice Framework: Stories from the Trenches David Crouch Project Administrator, Johns Hopkins Institutions
- 3. #b20Con Waterfall Approach Initiation & Requirements • Front-loaded Communication with customer • Charter Design • Logical • Physical Implementation • Code, build Verification Closure & Maintenance Adapted from Winston Royce, 1970 • Test/Control • Redesign/Changes
- 4. #b20Con Agile Approach • Individuals and Interactions over processes and tools. • Working Software over comprehensive documentation. • Customer Collaboration over contract negotiation. • Responding to Change over following a plan. Analyze & Design Test Release Review Plan “light”
- 5. #b20Con Waterfall v. Agile Waterfall Agile Scope • Well-defined • Adapt to changing requirements. Analysis • Performed in beginning. • Performed throughout project. Planning, Design, Architecture • Upfront, Top-Down • Iterative Development/Coding • Coding Phase • Performed throughout project. Testing • Testing Phase • Performed throughout project. (Continuous integration) Roles • PM controls • Scrum master coaches. • Close relationship with customer Sign-Off/Approval • At each stage. • Performed throughout project. Time/Schedule • Specific beginning and end. Project Phases • No specific beginning and end. “Stop when customer is happy.” • Sprints Documentation • Extensive • Light
- 6. #b20Con What do you think? Scenario Waterfall Agile Hybrid Enterprise-wide SAP implementation SAP module implementation New feature online banking website New internal catalogue item to provision virtual desktop New search feature online retail (e.g. Amazon) New Project Management Process and Software
- 7. #b20Con Best Use Scenario Waterfall Agile Hybrid Large, enterprise-wide project; standardized process X _ X Contract-based projects X _ X More than one deliverable X _ X Heavy Engineering Projects X _ X External Certification Needed X _ X Mobile Applications _ X X Customer-Facing/Retail _ X X Time-to Market Critical _ X X High Degree of Change _ X X Unique Product _ X X
- 8. #b20Con Opportunities and Challenges of Hybrid Opportunities Best of both worlds. o Improved Predictability/Governance (Waterfall) o Improved Response to Change/Feedback (Agile) o Empower individuals (Agile) Challenges Who’s in charge? Learn While Doing Reporting Managing
- 9. #b20Con What everybody wants to know May June July What are we working on? What is the current status? When will it be done? How much will it cost?
- 10. #b20Con Questions to Ask • Do your people hide behind processes and tools? • Are your projects for internal or external benefit? • How important is speed? • How much does your organization value documentation over working software? oIs your documentation outdated?
- 11. #b20Con Making Hybrid Work (High-level) • Promote close human interaction and relationships. oOpen/Active Communication, Same language • Make metrics visible. • Teach leadership. • Small, incremental, consistent changes. • Not necessarily 50/50.
- 12. #b20Con Making Hybrid Work (Detail-level) • Publish milestone reports, high-level timelines. (W) • Set budget ceiling. (W) • Set core functionality and features. (W) • Set fixed deadline for delivery of core functionality. (W) • Appoint product owner. (A) • Allow development team flexibility. (A) • Use agile techniques to elicit customer requirements. (A)
- 13. #b20Con ITSM DEVOPS CONFERENCE Thanks for coming! Let us know what you thought!
Editor's Notes
- Introduce myself and outline the session. Today we will focus more on audience participation and story-sharing than slides.
- Before we get started, let’s get a little perspective by watching this funny video . . . “Stupid things that scrum masters say.” This is geared towards agile, but I think you’ll get the idea. Admittedly, this is probably a bit exaggerated . . . But how many of you have been in similar situations? [Audience response].
- Before we dive into the pros and cons of following a single framework, let’s do a quick review. Here is a depiction of the waterfall process. You may be familiar with different waterfall phases . . . Depending on the source, you may see phases collapsed or expanded. Basically, you see that in waterfall, we have a very linear/phasic process, and we do quite a bit of planning upfront. Of course, we all know that in the “real world,” the process isn’t quite so linear. Nevertheless, we do a lot of planning upfront and wait until the end for checking or verification.
- And here is Agile’s answer to project management. Many of you may be familiar with the Agile Manifesto. At first glance, you might see how some of these principles appear to be in direct conflict with the Waterfall methodology. If we look at the Agile approach visually, we see that it is less sequential than waterfall. There is a only a small amount of planning and requirements gathering upfront because in agile we anticipate that requirements and scope will change before the project ends. Testing and verification is done while we are building. After each iteration, we do a retrospective . . . But it focuses on our process (not the deliverables themselves).
- Now let’s compare and contrast the defining characteristics of waterfall and agile. How many people would say that their organization follows a primarily waterfall approach? Agile? Hybrid?
- Here are some scenarios. Which approach would you (audience) take with each of these? Explain why?
- There are some classic cases where waterfall works better than agile and vice versa. Of course, you can see that hybrid is checked throughout since there is always a possibility to blend techniques.
- Waterfall and Agile are both useful methodologies. But individually, they often work best in different situations. Quite often, trying to apply a methodology to a situation that does not play to the methodology’s strong suit is like trying to fit the proverbial “square peg into a round hole.” The same can be said when we try to blend the methodologies. Opportunities: We have the potential to inherit the best of both worlds. The waterfall framework can bring improved predictability and governance while agile can help us to be more responsive to change – in the marketplace, with consumer demands, and also more responsive to feedback from customers and internal teams. There is also often a benefit to empowering individuals to be creative in devising solutions. This ground-up empowerment is most often associated with agile. Challenges Learn While Doing – We normally don’t have the luxury to stop getting work done to learn something new. If we introduce a hybrid approach, everybody needs to continue to do their work while trying to learn something new. This can be challenging to say the least. Reporting – We need to prepare different reports for different audiences. Sometimes this can seem like “double the work” and create overhead. Typically, folks familiar with the reporting tools and the reports themselves from one framework have trouble understanding the corresponding tools and reports of the other framework. Managing – No one PM tool does it all. In other words, although some PM tools have waterfall and agile modules, none really integrate these into one seamless application . . . More are trying to . . . But the marriage is still not perfect. More importantly, the traditional “waterfall” framework gives ultimate control to the project manager whereas agile expects the team to self-regulate. When an executive wants to know “whose in charge,” they tend to want to go to one person (and not the whole team). Who is this in a hybrid world? The Product Manager? The Scum master? Or some other role?
- At the end of the day, regardless of the approach, everybody wants to know four basic things: 1) What are we working on? 2) What is the current status? 3) When will it be done? 4) How much will it cost?
- Here are a few questions that can help determine the best framework to use: If you believe your employees are hiding behind processes and tools but not get work done or not getting it done quickly enough, it might be worth pushing them towards a more agile approach. Are your projects for internal or external benefit? What do I mean by this? Are you developing productivity software to help your own employees work better? Or are you developing software that you sell to external customers? Are you Amazon or Ebay and are not selling software but use software as the primary engine to interface with customers and distribute products? There is no “bright line” here, but if you are focused more on using software as a primary way to interact with or sell to customers, then a more agile approach helps you to be more flexible in rolling out new features that customers appreciate and that help differentiate your company from competitors. How important is speed to you? If it comes to speed or quality, which do you choose. If your organization has a lot of documentation on projects and systems but it never gets updated, you have to ask the question – Do we really need so much documentation? What do we gain from documenting so much? What could we gain if we were lighter on documentation and heavier on producing working software and systems? Maybe in this case, development teams could benefit from a more agile approach. What sort of questions do you ask? What are your red flags that a particular approach is not working?
- If you decide to use a hybrid approach, there are a few things you can do to give it the best possibility for success. Promote close human interaction – This is probably something we should do more of anyway, regardless of the project management approach. Of course, it can be difficult in an age where employees often work from home or “hotel.” But the more we can encourage people to explain what they mean, what challenges they have, where they are on the project, the better our chances of getting the most out of a blended approach and minimizing the risks. After all, we start with people who do the work, and people who need the results. The framework we use should help; not get in the way. In some organizations, agile teams are effectively “siloed” because other teams don’t understand the way they work, their language, etc. Using the same language can be helpful. For example, I have heard many people in my own organization use agile terms loosely or incorrectly. We don’t want to get caught up in jargon; at the same time, if we are going to use it, we need to make sure we are all using it the same way. Just say the word “story” to somebody not familiar with agile and wait for the quizzical expression on their face. This is where professional training can be immensely helpful. Maybe a half-day session on agile or waterfall basics. Make metrics visible – Keep metrics as simple as possible. Realize that not everybody is going to use your PM tools. Developers and IT people might use them, but executives, operations managers, and other stakeholders might not want to learn your tools. We already talked about the fact that different audiences want different metrics, but just about everybody wants to know (at least at a high level) what we are working on, the current status, and when it will be done. For large projects, metrics that lend themselves to “milestones” can be posted visibly. Another good idea I heard is to encourage developers to post their up-to-date Kanban on a whiteboard in their cubes so that other people get a sense, “at a glance,” or what is going on. Teach leadership – This is especially true if you are introducing a new methodology or switching methodologies. Some of the leaders will say, “Agile? What’s that?” And frankly, they might not care about your approach as much as they do about the ultimate results. But to the extent where reporting metrics don’t translate well between methodologies, you need to give a quick primer. This is especially true when it comes to scope. Most leaders understand the waterfall methodology better because it has been around longer and there are more finite aspects to it . . . Fixed budget, fixed timeline, relatively well-known risks, fixed scope. It can be difficult to understand agile’s “scope shifting” nature. Small, incremental, consistent changes – There are stories out there or organization’s forcing everybody to adopt a new approach or a hybrid approach overnight without the proper training, without understanding the consequences, without explaining “what’s in it for me” and making the case for why the company could benefit. In the extreme, this is a recipe for turning a hybrid or agile approach into a fad that everybody ultimately resents and rebels against. Instead, are we able to find a few small changes where introducing more control (waterfall) or more flexibility (agile) gives us immediate value? Is there a way we can test using a couple of pilot groups? Not necessarily 50/50 – One thing that is common across all the literature on hybrid approaches is that it does not need to be (and probably won’t be) a 50/50 split between waterfall and agile. I’ve seen 80/20 in favor or agile. I’ve seen 80/20 in favor of waterfall. It just depends of what your organization needs more right now – control or flexibility. One of the biggest risks of a hybrid approach is that not enough significant new behaviors are introduced and/or new behaviors are not practiced routinely or frequently enough to take hold and become a way of life.
- Milestone Reports and High-Level Timelines – For executives and general reporting. Since people tend to understand waterfall and simple charts best. Set Budget Ceiling – Set a maximum budget or ceiling that is shared with the development team. If core functionality is reached under budget, consider using the balance for additional features and enhancements. Set Core Functionality and Features – The business owner should clearly communicate minimum functionality to developers to help set scope. Set fixed deadline for delivery of core functionality – Set “drop dead” date for core functionality. Be more flexible with optional features. Appoint Product Owner – Make the product owner responsible for setting initial scope/core functionality; agreeing with development team on change process. Allow development team flexibility – Allow the development team flexibility in terms of how they work on the project and which tools they use. Use Agile Techniques to elicit customer requirements – Wireframes, Design the product box Audience – What suggestions do you have? What has worked for you?