PMBOK and Scrum: Best of both worlds

Editor's Notes

1. Winston W. Royce,Managing the development of large software systemsProc. IEEE WESCON, Aug 1970Royce developed the phased delivery model to cope with regulatory requirements set out in the US DoD STD-2167 document, which was so byzantine and bureaucratic that the waterfall was the only way to cope with it;
2. Context at the time of Royce’s paper in 1970:Programming on punch cards!
3. Winston W. Royce,Managing the development of large software systemsProc. IEEE WESCON, Aug 1970Royce’s Son:http://usability.typepad.com/confusability/2006/02/index.html
4. http://www.techdarkside.com/is-there-really-any-rigor-in-waterfallIt is sad that software development philosophies and practices developed in a world of government regulation, punch cards, and very expensive computer time still have such a strong a hold on today’s commercial software development.Ben Simohttp://QuestioningSoftware.com
5. Need faster decision making“The world is moving so fast these days that the man who says it can't be done is generally interrupted by someone doing it.” (Elbert Hubbard) “If everything seems under control, you're just not going fast enough.” (Mario Andretti) “If you wish to travel far and fast, travel light. Take off all your envies, jealousies, unforgiveness, selfishness and fears.” (Cesare Pavese) “Moving fast is not the same as going somewhere.” (Dr. Robert Anthony) “Fast is fine, but accuracy is everything.” (Xenophon)Speed of market and technological changeWorld is moving fast(er)!Real-timeNon-linear activities
6. Can be on time, on budget, on scope, But still built the wrong product that no one needs.
7. The Cone of Uncertainty – ref. http://en.wikipedia.org/wiki/Cone_of_Uncertaintyhttp://www.construx.com/Page.aspx?cid=1648early project estimates are wildly inaccurate: Estimates (e.g. on duration, costs or quality) are inherently very vague at the beginning of a project Estimates and project plans based on estimations need to be redone on a regular basis Uncertainties can be built into estimates and should be visible in project plans Assumptions that later prove to be mistake are major factors in uncertainty Early in a project, specific details of the nature of the software to be built, details of specific requirements, details of the solution, project plan, staffing, and other project variables are unclear. The variability in these factors contributes variability to project estimates -- an accurate estimate of a variable phenomenon must include the variability in the phenomenon itself. As these sources of variabiility are further investigated and pinned down, the variability in the project diminishes, and so the variability in the project estimates can also diminish. This phenomenon is known as the “Cone of Uncertainty” which is illustrated in the following figure. As the figure suggests, significant narrowing of the Cone occur during the first 20-30% of the total calendar time for the project. Effective delivery of projects on time and on budget requires the application of a clear risk management approach throughout the whole project life cycle. The key learning from this approach is that any project estimate is meaningless without an accompanying confidence level. Applying this principle allows the management of both dimensions in project estimation, which in turn improves the identification and mitigation of risks throughout the project life cycle.
8. http://agile101.net/2009/08/18/agile-estimation-and-the-cone-of-uncertainty/Agile Requirements in order of UncertaintyAgile Theme Agile Epic Agile User Story Agile Task In other words estimate SMALL things in hours.Estimating in Fibonacci is the second Agile estimation metric - we call this Story Point Estimation.  We use Story Points to estimate larger pieces of work i.e.  User Stories and Epics.They work as follows:0,1,2,3,5,8,13,21,34,55,89In other words, a ’5′ is 5x more effort than a ’1′ and an ’8′ is 8x more effort than a ’1′.Story Points can measure things we can’t measure in hours – e.g. complexity – do you include a task for every discussion you don’t yet know you need to have, every time you take 10 minutes out to Google an answer? It is however relatively easy (when you get started) to compare the size of one task/cluster of tasks with another task/cluster of tasks.  Estimating in Story Points allows you to take into consideration all sorts of intangible ‘things’ that you sense but can’t quite put your finger on.(See:Software Estimation: The more precise you are, the less accurate you will be)Estimation Using T-Shirt SizesT-shirt Sizing is an Agile Estimation method – it’s used to estimate larger requirements i.e. Epics, but maybe the odd User Story also.In short, you attribute a number of story points to a t-shirt size e.g. an XXL might equal ’55 points’ as shown in the diagram below. T-shirt sizes are great for Product Owners and/or non-technical people as they’re totally abstract and non-threatening (that’s not meant to sound patronising…you know what I mean!). They’re easy to understand.When estimating in T-shirt sizes, it’s still important to set your scale – agree in advance what constitutes a ‘Small’, ‘Large’ and ‘XX Large’.T-shirt sizing will normally take place at the Requirements Workshop – this helps the Product Owner and Product Manager get a sense of scale, which will in turn help with the prioritisation process.As always, the Scrum Team are the people that assign t-shirt sizes to Epics.  The Product Owner and/or Product Manager are not allowed to participate in the estimation process – they can offer insight and guidance but the estimations belong to the Scrum Team.Estimation Using Story PointsOnce the Epics have been estimated and prioritised for delivery, they will be broken down into User Stories by the Product Manager and Product Owner.The component User Stories will then be introduced at a subsequent requirements workshop and estimated in Story Points at Poker Planning
9. Discipline:Structured approach,Plan aheadmodel itself progresses linearly through discrete, easily understandable and explainable phases and thus is easy to understand; it also provides easily markable milestones in the development process.Steve McConnell, in Code Complete, (a book that criticizes widespread use of the waterfall model) refers to design as a "wicked problem"—a problem whose requirements and limitations cannot be entirely known before completion. The implication of this is that it is impossible to perfect one phase of software development, thus it is impossible if using the waterfall model to move on to the next phase.David Parnas, in A Rational Design Process: How and Why to Fake It, writes:[5]“Many of the [system's] details only become known to us as we progress in the [system's] implementation. Some of the things that we learn invalidate our design and we must backtrack.”The idea behind the waterfall model may be "measure twice; cut once," and those opposed to the waterfall model argue that this idea tends to fall apart when the problem constantly changes due to requirement modifications and new realizations about the problem itself. A potential solution is for an experienced developer to spend time up front on refactoring to consolidate the software, and to prepare it for a possible update, no matter if such is planned already. Another approach is to use a design targeting modularity with interfaces, to increase the flexibility of the software with respect to the design.[edit] Modified modelsIn response to the perceived problems with the pure waterfall model, many modified waterfall models have been introduced. These models may address some or all of the criticisms of the pure waterfall model.[citation needed] Many different models are covered by Steve McConnell in the "lifecycle planning" chapter of his book Rapid Development: Taming Wild Software Schedules.
10. Discipline: rhythm, daily scrum, work agreements, consistentAgile approach is Great Risk Management:Risk of not pleasing the customerRisk of poor estimation and planningRisk of festering issues and delaysRisk of over-commitmentRisk of not being able to ship
11. Ref http://drdobbs.com/tools/229401451?pgno=2 S— Mark Kennaley is president and principal consultant at Fourth Medium Consulting, a Canadian IT management consultancy. His book, SDLC 3.0: Beyond A Tacit Understanding Of Agile, won a Dr. Dobb's 2010 Jolt Productivity Award.the four culture quadrants in the diagram. These include: Clan/Family Culture: Here you have a culture that emphasizes collaboration. Your leaders tend to be facilitators and team builders, who value commitment and communication. They think effectiveness is driven by developing people and spurring participation. Adhocracy Culture: Your company emphasizes creativity and has leaders who are entrepreneurial innovators, who value transformation and agility, and have a high level of risk tolerance. They think that innovation and vision are the best paths to effectiveness. Market Culture: Here the orientation is competition. Your leaders are hard-driving competitors, who emphasize goal achievement, market share, and profitability. Customer focus and aggressive competition lead to effectiveness. Hierarchy/Bureaucracy Culture: Your company tends to focus on control, with leaders who coordinate, monitor, and organize. Efficiency, timeliness, consistency, and risk aversion are the watchwords. Control and efficiency are seen as the best path to effectiveness.
12. Recognition of real need for the professionWill bestow PMI credibility and supportAgile is best learned by practicing. I'm not too particular on how one learns, but putting the learning into practice in a team environment with frequent and effective retrospectives to adjust your process is key to internalizing agile. Hopefully the experience qualification ensures real agile project experience, not just observing agile teams. Experience requirement: working on Agile project teams, may be other role than Project Manager.
13. Plan-driven software methodologies use a command-and-control approach to projectmanagement. A project plan is created that lists all known tasks. The project manager’sjob then becomes one of enforcing the plan. Changes to the plan are typically handledthrough “change control boards” that either reject most changes or they institute enoughbureaucracy that the rate of change is slowed to the speed that the plan-drivenmethodology can accommodate. There can be no servant-leadership in this model.Project managers manage: they direct, administer and supervise.Agile project management, on the other hand, is much more about leadership than aboutmanagement. Rather than creating a highly detailed plan showing the sequence of allactivities the agile project manager works with the customer to layout a common set ofunderstandings from which emergence, adaptation and collaboration can occur. The agileproject manager lays out a vision and then nurtures the project team to do the bestpossible to achieve the plan. Inasmuch as the manager represents the project to thoseoutside the project he or she is the project leader. However, the project manager serves anequally important role within the project while acting as a servant to the team, removingtheir impediments, reinforcing the project vision through words and actions, battlingorganizational dysfunctionality, and doing everything possible to ensure the success ofthe team. The agile project manager is a true coach and friend to the project teams.
14. Plan-driven software methodologies use a command-and-control approach to projectmanagement. A project plan is created that lists all known tasks. The project manager’sjob then becomes one of enforcing the plan. Changes to the plan are typically handledthrough “change control boards” that either reject most changes or they institute enoughbureaucracy that the rate of change is slowed to the speed that the plan-drivenmethodology can accommodate. There can be no servant-leadership in this model.Project managers manage: they direct, administer and supervise.Agile project management, on the other hand, is much more about leadership than aboutmanagement. Rather than creating a highly detailed plan showing the sequence of allactivities the agile project manager works with the customer to layout a common set ofunderstandings from which emergence, adaptation and collaboration can occur. The agileproject manager lays out a vision and then nurtures the project team to do the bestpossible to achieve the plan. Inasmuch as the manager represents the project to thoseoutside the project he or she is the project leader. However, the project manager serves anequally important role within the project while acting as a servant to the team, removingtheir impediments, reinforcing the project vision through words and actions, battlingorganizational dysfunctionality, and doing everything possible to ensure the success ofthe team. The agile project manager is a true coach and friend to the project teams.
15. Old solutions may no longer work for new challenges
16. Change Management expense http://drdobbs.com/tools/229401451 Gartner estimates that worldwide IT spending last year was $1.6 trillion, with IT services at $816 billion as the largest component of that figure. Typically, 3% to 10% of the IT services budget allocations can be associated with pro­cess improvement initiatives, so we can estimate that $17 billion in spending is doomed to not deliver the intended results (70% of $24.5 billion). And that doesn't include opportunity costs associated with failed process improvement and costs associated with lost productivity during the change. Gartner estimates that worldwide IT spending last year was $1.6 trillion, with IT services at $816 billion as the largest component of that figure. Typically, 3% to 10% of the IT services budget allocations can be associated with pro­cess improvement initiatives, so we can estimate that $17 billion in spending is doomed to not deliver the intended results (70% of $24.5 billion). And that doesn't include opportunity costs associated with failed process improvement and costs associated with lost productivity during the change. A Pragmatic ApproachOne approach, which I call SDLC 3.0, provides a pragmatic, experience-based approach for integrating the fragmented methodology landscape by using practices that are methodology agnostic. It focuses on yielding a useful, context-specific set of standard work advice for real product development. It also integrates the software development part of IT with the broader enter­prise and functions such as enterprise architecture, IT service management, and project and portfolio management. Using lean as the overarching set of principles, SDLC 3.0 starts with the customer and ends with the accrual of value within IT operations. This focus makes sure that small groups don't try to optimize only their piece of the process, based only on what they know about their roles. Rather, a coherent big-picture view enables traditionally siloed communities to constructively participate rather than get bogged down in in-fighting.
17. http://academic.research.microsoft.com/Publication/4327025/historical-roots-of-agile-methods-where-did-agile-thinking-come-fromBoehm http://academic.research.microsoft.com/Publication/3167904/guidelines-for-verifying-and-validating-software-requirements-and-design-specifications