Agile Project Management V2 (AgilePM® V2) study guide mind map

1. Current DSDM® Consortium products family

1.1. DSDM® Consortium products history in a nutshell

1.1.1. positioning AgilePM® in comparision to other Agile approaches

2. AgilePM® Fundamentals

2.1. What is AgilePM®?

2.1.1. AgilePM® project delivery framework and method that delivers the right solution at the right time.

2.1.2. An iterative, incremental and adaptive project management method.

2.1.2.1. Less sequential.

2.1.2.2. Different style than waterfall (no better or worst - just different).

2.1.3. AgilePM® V1 method was created in 2010.

2.1.3.1. AgilePM® V1 was derived form another method called DSDM® from it's newest version v5 at the time of creation called DSDM® Atern®.

2.1.4. AgilePM® V2 method was created in 2014.

2.1.4.1. AgilePM® V2 was derived form another method called DSDM®, from it's version V6 called AgilePF® (Agile Project Framework).

2.1.5. AgilePM® is a framework rather than a full methodology.

2.1.5.1. It does not say how things should be done in detail, but provides a skeleton process and product descriptions that are to be tailored to suit a particular project or a particular organisation.

2.1.6. AgilePM® integrates:

2.1.6.1. project management lifecycle

2.1.6.1.1. e.g. PRINCE2®, PMBOK5®

2.1.6.2. product development lifecycle

2.1.6.2.1. e.g. Scrum, FDD, TDD

2.1.6.3. which means that AgilePM® can bee seen as a hybrid method

2.1.7. Right business solution is delivered because

2.1.7.1. The project team and other significant stakeholders remain focused on the business outcome.

2.1.7.2. Delivery is on time ensuring an early return on investment (ROI).

2.1.7.2.1. On time due to short time interval of Timeboxes

2.1.7.3. All people involved with the project work collaboratively to deliver the optimum solution.

2.1.7.3.1. Even lowest level them members like SDTs (developers, testers, graphics designers etc.)

2.1.7.4. Work is prioritised according to business need and the ability of users to accomodate changes in the agreed timescale.

2.1.7.4.1. using PRL document (a.k.a. product / project backlog)

2.1.7.5. AgilePM® does not compromise on quality, i.e. the solution is not over- or under-engineered.

2.1.7.5.1. Solution is fit for purpose

2.1.7.5.2. Quality is set up front at the Foundation phase

2.1.8. AgilePM® agility

2.1.8.1. Avoids cumbersone rigidity of "Big Design Up Front (BDUF)" with the inevitable risks of "no design" up front.

2.1.8.2. AgilePM® advocates that projects should do just "Enough Design Up Front (EDUF)".

2.1.9. AgilePM® flexibility

2.1.9.1. AgilePM® can be used to complement other project management disciplines (PRINCE2®, PMBOK® Guide).

2.1.9.2. AgilePM® can also incorporate other agile delivery approches (development techniques) such as eXtreme Programming (XP) and SCRUM.

2.2. Why using AgilePM®?

2.2.1. Communication Problems

2.2.1.1. Poor communication is highlighted time after time as a major failing on projects.

2.2.1.2. How AgilePM® helps?

2.2.1.2.1. AgilePM® emphasis on human interaction (e.g. Facilitated Workshops), visualisation (e.g. Modelling, Prototyping) and clearly defined roles is at the heart of improved project communication.

2.2.2. Late Delivery

2.2.2.1. Slippage of the completion date causes much frustration, as well as causing significant knock-on effects for a business.

2.2.2.2. How AgilePM® helps?

2.2.2.2.1. Being on time applies to short-term goals as well as the project as a whole.

2.2.2.2.2. AgilePM® sees this issue as one of the most important problems to address and AgilePM®'s approach and many of the AgilePM® practices are geared towards always being on time.

2.2.3. The delivered solution isn't really what the business wanted

2.2.3.1. Frustration is that when the solution is delivered, it doesn't meet the expectations of the business.

2.2.3.1.1. Due to bad requirements understanding, it may have features that don't do what the business really wanted it to do, or contain bugs which prevent the deliverable from performing as business was expecting.

2.2.3.2. How AgilePM® helps?

2.2.3.2.1. Most importantly, AgilePM® teams are encouraged to embrace change, allowing them to deal with problems that occur, to encompass new ideas that appear and to build the solution based on a deepening understanding of the solution detail.

2.2.3.2.2. AgilePM® encompasses practices which encourage collaboration and enable rich communications.

2.2.3.2.3. In AgilePM®, getting the correct understanding of the needs of the business is of paramount importance.

2.2.4. Unused Features

2.2.4.1. Often the low percentage of delivered features that are actually used.

2.2.4.1.1. This often happens because the business tends to over-prescribe their needs during a project.

2.2.4.2. How AgilePM® helps?

2.2.4.2.1. By helping the business to prioritise their needs, AgilePM® keeps focus on what is important. This also avoids causing delays to a project by developing features that are never used.

2.2.5. Building the right thing - the business changing their mind

2.2.5.1. A frequent problem on a traditional project is that 'the users have changed their minds and requirements'. Far from being a problem, AgilePM® embraces change and believes that change often arises as the result of a deepening understanding or an unavoidable external event.

2.2.5.1.1. In line with principle 1 - Focus on the business need.

2.2.5.2. How AgilePM® helps?

2.2.5.2.1. AgilePM® enables change through iterative development, with regular reviews. Requirements change is a natural result of a better understanding, so AgilePM® expects it and plans for it.

2.2.5.2.2. Deepening understanding. AgilePM® capitalises on the greater depth of understanding and so ensures that the deployed solution fits with the true business requirements.

2.2.6. Delayed or late Return on Investment (ROI)

2.2.6.1. Usually, business benefit decreases over time and therefore delivering everything towards the end of a project will reduce the ROI.

2.2.6.2. How AgilePM® helps?

2.2.6.2.1. When appropriate, it can harness the aggressive nature of techniques such as vertical prototyping in order to deliver a partial solution to the business very early and therefore to enable early return on investment (ROI).

2.2.6.2.2. AgilePM® uses incremental delivery to get the most important and most valuable features to the business as soon as it can.

2.2.7. Over-engineering ("Gold plating")

2.2.7.1. There is normally a diminishing return (on value) when trying to make a deliverable 'perfect'.

2.2.7.1.1. Usually the highest business benefits can be derived by getting something that is 'good enough' into a window of opportunity for the business.

2.2.7.2. How AgilePM® helps?

2.2.7.2.1. AgilePM® is a pragmatic approach that focuses on the business need in order to prevent a team being tempted into adding 'bells and whistles' which the business could live without and as a result missing the deadline.

2.2.7.2.2. Prioritisation ensures the whole team are clear about the relative importance of the work to be done.

2.3. AgilePM® vs Traditional Project Variables

2.3.1. Project Variables - Traditional and AgilePM®.

2.3.1.1. Deliver on time.

2.3.1.2. Deliver on budget.

2.3.1.3. Guarantee to meet quality standards.

2.3.1.4. Focus on what business sees as important (not everything is important).

2.3.1.4.1. Agile projects will not necessarily deliver the full scope!

2.3.1.4.2. AgilePM® is about delivering 80% functionality in 20% time.

2.3.2. AgilePM® fixes Time, Cost and Quality at the early phases of a project.

2.3.2.1. Time is fixed e.g. due to short timescale of Timeboxes

2.3.3. According to AgilePM®, most projects have four parameters - time, cost, features and quality.

2.3.4. In the traditional approach to project management (left hand diagram), the feature content of the solution is fixed whilst time and cost are subject to variation.

2.3.5. AgilePM® approach to project management (right hand diagram), fixes time, cost and quality at the Foundations phase while contingency is managed by varying the features to be delivered.

2.3.6. As long as MoSCoW and Timeboxing rules are followed, a minimum subset of features (the Minimum Usable Subset) is absolutely guaranteed to be delivered on time and in budget.

2.3.7. Quality is fixed in an AgilePM® project because acceptance criteria are agreed and set before development commences

2.3.7.1. Each Timebox in AgilePM® has the same level of quality set at the beginning.

2.3.7.1.1. Which means that each deployment will have the save level of quality and whole solution will be build in one level of stable quality.

2.3.7.2. Quality is built in since quality control takes place throughout the project instead of being stuck on the end. Achieved by checking a bit at a time, & checking integration of components as they’re produced.

2.3.8. Contingency, in the form of lower priority features, ensures that on-time delivery of a viable solution can be achieved by protecting the Minimum Usable Subset and dropping or deferring lower priority features, if necessary, in accordance with MoSCoW rules.

2.4. AgilePM® rigour

2.4.1. Too much formality can slow progress down and even cause paralysis.

2.4.2. Too little formality can lead to a seat-of-the-pants approach.

2.4.3. AgilePM® should be tailored to suit a project's individual needs within the organisation's governance needs.

2.4.4. The aim is to have adequate formality, so that waste is eliminated and all activities at each incremental level add value.

2.4.5. AgilePM® project ensures that formality and rigour are there to help rather than hinder progress.

2.5. Why use AgilePM® for Agile Project Management?

2.5.1. Vendor-independent.

2.5.2. Independent of tools and techniques,

2.5.3. Higly scalable - for small and big projects.

2.5.4. Recognises that more projects fail because of people issues than technology,

2.5.5. Fundamental assumption of the AgilePM® approach is that nothing is built perfectly first time

2.5.5.1. AgilePM® team will constantly search for for better style of working.

2.5.6. AgilePM® is a convergent approach, ensuring that basic foundations for the project are agreed at an early stage

2.5.7. Current step need be completed only enough to move to the next step, since it can be finished in a later iteration.

2.5.8. Less agile approaches is the expectation that potential solution users can predict what all their requirements will be at some distant point in time.

2.5.8.1. Based on traditional project statistics lots of functionalities are rearly used by end users, but project costs are based on ALL delivered functonalities.

2.5.9. Solutions built using the AgilePM® approach address the current and imminent needs of the business.

2.5.10. AgilePM® is not only about developing new solutions.

2.5.10.1. Enhancements to existing solutions can be created using AgilePM®.

2.6. Download: AgilePM® - Traditional vs AgilePM® project variables (PDF)

2.7. Summary & Conclusion

2.7.1. Agile is a style of working

2.7.2. Agile world consists of: methodologies, frameworks, tools, practices and techniques.

2.7.3. Unlike a traditional approach, AgilePM® fixes Time, Cost and Quality at the early phases of a project

2.7.4. Contingency, in the form of lower priority features, ensures that on-time delivery of a viable solution

3. AgilePM® - an iterative, incremental and adaptive (change-driven / empirical) agile project management method and framework (not just framework like Scrum) from UK for general (not industry specific e.g. IT or Engineering) agile project management. AgilePM® is seen as a hybrid method, which combines project management / delivery with product development / construction into one lifecycle and method. AgilePM® was derived from another method called DSDM® from its version v5 called DSDM® Atern® in 2010. In 2014 AgilePM® received major update to V2. AgilePM® and DSDM® can be easily managed together within programme using Agile Programme Management method (AgilePgM™). Same as DSDM®, AgilePM® and AgilePgM™ were created by DSDM® Consortium - www.dsdm.org

3.1. AgilePM® first version v1.0 was published in 07.2010

3.1.1. AgilePM® v1.0 was based on another method DSDM® V5 called DSDM® Atern

3.2. Several changes were published in version v1.1 like changes in roles (09.2012)

3.3. Minor updates were published in version v1.2 (12.2013)

3.4. Major update v2.0 was published in 09..2014

3.4.1. AgilePM® v2.0 was based on another method DSDM® V6 called DSDM® AgilePF® - Agile Project Framework

3.4.1.1. see DSDM® AgilePF® mind map

4. AgilePM® V2 method consists of: 1 Philosophy, 8 Principles, 5 Instrumental Critical Success Factors, 6 Project Lifecycle Phases, 13 Roles, 14 Management Products (a.k.a. documentation), 7 Techniques.

4.1. Download: AgilePM® V1.2 Project Phases vs Products (documentation) vs Roles vs Reponsibilites Matrix (PDF)

4.1.1. Download: AgilePM® - Project Health Check Questionnaire (PHCQ) (XLSX)

4.2. Download: AgilePM® V1.2 Document Templates [DOCX, XLSX]

4.2.1. Download: AgilePM® - Project Approach Questionnaire (PAQ) (XLSX)

5. AgilePM® Philosophy (1)

5.1. The AgilePM® Philosophy is that any project must be adopted and adapted or simply aligned to clearly defined strategic goals

5.2. 6P Model (a.k.a. DSDM “temple”)

5.2.1. Philosophy

5.2.1.1. “Best business value emerges when projects are aligned to clear business goals, deliver frequently and involve the collaboration of motivated and empowered people”

5.2.2. Principles

5.2.2.1. Eight principles articulate the core elements of the philosophy

5.2.3. Process

5.2.3.1. A full project lifecycle model that describes the transitions through phases that enable iterative, incremental and adaptive practices

5.2.4. People

5.2.4.1. Facilitation of communication, support of collaboration and the composition and distribution of skills within project teams

5.2.5. Products

5.2.5.1. A set of evolutionary and milestone artefacts cater for different project perspectives

5.2.6. Practices

5.2.6.1. Structured techniques and activities

5.3. Best achieved when key stakeholders understand the business objectives, are empowered to an appropriate level and collaborate in order to deliver the right solution

5.4. Philosophy is achieved when all stakeholders

5.4.1. Understands and buy into the business vision and objectives

5.4.2. Are empowered to make decisions within their area of expertise

5.4.3. Collaborate to deliver a fit for purpose business solution

5.4.4. Collaborate to deliver to agreed timescales in accorddance with business priorities

5.4.5. Accept that change is inevitable as the understanding of the solution grows over time

5.5. The AgilePM® philosophy is supported by a set of 8 principles that build the mindset and behaviours necessary to bring the philosophy alive

5.5.1. The 8 principles are themself supported by people, Agile process, clearly defined products and recommended practices

5.5.1.1. Thanks to the philosophy, principles, configurable lifecycle, products, roles, and key practices of AgilePM® greatly reduces the risk of building the wrong solution, and the final solution is more likely to meet the user’s real business requirements, so users are more likely to claim ownership of the solution.

5.6. Pragmatism

5.6.1. "action or policy dictated by consideration of the immediate practical consequences rather than by theory or dogma"

5.7. Common sense

5.7.1. "sound practical judgment independent of specialised knowledge or training; normal native intelligence"

6. AgilePM® Principles (8)

6.1. Principles are universally applicable statements.

6.1.1. Principles are universal, self-validating and empowering.

6.1.2. They provide guidance to organizations.

6.2. The 8 principles of AgilePM® direct the team (not mandates) in the attitude and culture they must take and the mindset they must adopt in order to deliver consistently.

6.2.1. A way of thinking and working.

6.3. If a team doesn't follow all the principles then they don't get the full benefit.

6.3.1. It increases risk.

6.4. Treat non-adherence to the principles as a risk.

6.4.1. Because breaking any of the Principles will break Agile concept and will be a significant risk to the success of the project.

6.5. The 10 Golden Rules for Successful Agile Projects (by Keith Richards)

6.5.1. https://www.youtube.com/watch?v=P84PqqJV7Es

6.5.2. No. 1: Define the project objective in less than 10 words

6.5.2.1. You must start with the end in mind

6.5.2.2. You need to know exactly where you are going

6.5.2.3. The business case is your best friend

6.5.2.4. This will take you a long time to do

6.5.2.5. It will help you to kill a project going nowhere

6.5.2.6. The scope of the project will map on to this.

6.5.2.7. TIP

6.5.2.7.1. Can you write the project objective on a Post-it note with a flip chart marker?

6.5.3. No. 2: Build a team with those who say ‘can’

6.5.3.1. A lot of being agile is about options

6.5.3.2. If you get the right people you are half way there

6.5.3.3. Choose the right person above the right skill set

6.5.3.4. “If you think you can’t, you’re right” - Carol Bartz

6.5.3.5. You need collaboration and team spirit.

6.5.3.6. TIP

6.5.3.6.1. Ask a team member this question: Can I ask a favour?

6.5.4. No. 3: Go slow early to go fast later

6.5.4.1. This is counter intuitive

6.5.4.2. How much ‘DUF’ is enough? Answer EDUF!

6.5.4.3. Build from firm foundations

6.5.4.4. You must avoid analysis paralysis

6.5.4.5. Try and spot early solutioneering.

6.5.4.6. TIP

6.5.4.6.1. Ask yourself: Is it safe to move on?

6.5.5. No. 4: Look backwards to go forwards

6.5.5.1. Learn your lessons - both good and bad

6.5.5.2. Evolve the process - it has to evolve

6.5.5.3. If it doesn’t work - do something else!

6.5.5.4. Try this! - Review, Plan, Do

6.5.5.5. Share your experiences with other teams.

6.5.5.6. TIP

6.5.5.6.1. Ask yourself how many of your projects have ended with a project review.

6.5.6. No. 5: Change is great!

6.5.6.1. You need to anticipate change and embrace it

6.5.6.2. This allows a more accurate solution to result

6.5.6.3. Do not confuse the breadth of the scope with the depth

6.5.6.4. Evolve and converge on the solution with the right kind of change.

6.5.6.5. TIP

6.5.6.5.1. How do you feel when a customer says “I’ve changed my mind”?

6.5.7. No. 6: To be understood, seek first to understand.

6.5.7.1. Command and control may not work with Agile

6.5.7.2. Facilitation is a core competency

6.5.7.3. Big ears, big eyes, small mouth

6.5.7.4. You have to play with the cards you are dealt

6.5.7.5. This will give you ownership.

6.5.7.6. TIP

6.5.7.6.1. Try the 10 second silence when getting a progress update - nothing else can compete with it!

6.5.8. No. 7: Collect Actuals – this is the oxygen for your project

6.5.8.1. ‘You cannot control what you cannot measure’ - Tom de Marco

6.5.8.2. Meten is weten - to measure is to know

6.5.8.3. Start now - build a metrics database

6.5.8.4. Keep it simple to start with

6.5.8.5. Calibrate your estimates.

6.5.8.6. TIP

6.5.8.6.1. Do you know (to the nearest day) how much time was spent on testing during your last project?

6.5.9. No. 8: Use fat communication channels

6.5.9.1. Shift the communication traffic to bigger pipes

6.5.9.2. The written word is a silent killer

6.5.9.3. Go visual

6.5.9.4. Use workshops

6.5.9.5. “Never write when you can talk. Never talk when you can nod. And never put anything in an email“ (Eliot Spitzer)

6.5.9.6. TIP

6.5.9.6.1. Try turning a document over and take a look at what is on the back

6.5.10. No. 9: Work hard at controlling what you can’t control

6.5.10.1. Continuously manage external risks

6.5.10.2. You may get your team right but what about 3rd parties?

6.5.10.3. Are they playing by the same rules as you?

6.5.10.4. Get the team involved

6.5.10.5. Be ‘a bit of a worrier’.

6.5.10.6. TIP

6.5.10.6.1. Actively manage your risk log - it is not a storage area

6.5.11. No. 10: One more day? NO! We’ll catch up? NO!

6.5.11.1. Time focus is your greatest weapon

6.5.11.2. Force the issue – understand your condition

6.5.11.3. Timeboxes not milestones

6.5.11.4. If you are going to fail – fail early

6.5.11.5. Prioritise with MoSCoW – it should be natural.

6.5.11.6. TIP

6.5.11.6.1. Set a deadline and hit it - never extend it, not even once!

6.6. 1 - Focus on the business need

6.6.1. Every decision taken during a project should be viewed in the light of the overriding project goal - to deliver what the business needs to be delivered, when it needs to be deliveres.

6.6.1.1. Project is a means to an end, not an end in itself.

6.6.1.1.1. Solution products are more important than documentation

6.6.2. In order to fulfill this principle, project teams need to:

6.6.2.1. Explore and understand true business priorities

6.6.2.2. Establish a valid Business Case

6.6.2.2.1. AgilePM® has a formal product called Business Case for which responsible is Business Sponsor (BS)

6.6.2.3. Ensure continuous business sponsorship and commitment

6.6.2.3.1. Business Sponsor (BS) is responsible for finance decisions

6.6.2.3.2. Business Ambassador (BAMB) roles are representatives from client / user side available everyday (~min 15. minutes a day) to Solution Development Teams (SDTs)

6.6.3. Guarantee delivery of the Minimum Usable Subset of requirements

6.6.3.1. Not all requirements must be delivered in AgilePM® project, but as a minimum those having MUST priority

6.6.3.1.1. see MoSCoW prioritisation technique

6.6.4. Deliver what the business needs when it needs it.

6.6.4.1. The true business priorities must be understood with a sound business case.

6.6.4.2. Discover and understand real client / user NEEDS not just requirements

6.6.4.2.1. Go back and ask WHY project is needed and WHY products are needed, what is the purpose

6.6.4.3. Focus on real/true business needs by questioning/challenging initial requirements; go into details; find valid business case for each requirement; confirm each requirement by looking at the value; maintain end user focus

6.6.4.3.1. “There is nothing so useless as doing efficiently that which should not be done at all” (Peter F. Drucker)

6.6.5. Principle supported by:

6.6.5.1. Roles

6.6.5.1.1. Business Sponsor (BS)

6.6.5.1.2. Business Visionary (BV)

6.6.5.2. Products

6.6.5.2.1. Business products (documents) agreed at Foundation phase

6.6.5.3. Techniques

6.6.5.3.1. MoSCoW

6.6.5.3.2. Timeboxing

6.7. 2 - Deliver on time

6.7.1. Delivering a solution on time is a very desirable outcome for a project and is quite often the single most important success factor.

6.7.1.1. Late delivery can often undermine the very rationale for a project, especially where market opportunities or legal deadlines are involved.

6.7.2. In order to fulfill this principle, project teams need to:

6.7.2.1. Timebox the work into manageable chunks of time.

6.7.2.1.1. Timeboxes are planned in advance and the timeframe set.

6.7.2.2. Clear focus on business priorities and needs (not just requirements)

6.7.2.2.1. Question each decision

6.7.2.3. Always hit deadlines

6.7.2.3.1. Time is the only asset that you can't (directly) control in life!

6.7.2.3.2. Build confidence through predictable delivery and maintain reputation

6.7.2.3.3. You can only loose time but never gain ...

6.7.2.3.4. "If you accept the premise that market needs change faster than the software industry‟s traditional ability to develop solutions, you‟re left with the question “what can we do about it?” For me, the answer is Agile." Israel Gat, Vice President, Infrastructure Management, BMC Software, Inc.

6.7.2.3.5. "My favorite things in life don't cost any money. It's really clear that the most precious resource we all have is time." Steve Jobs

6.7.3. Define the breadth (project scope) of your requirements without going into too much detail.

6.7.4. Estimate the relative size, priority and complexity of each requirement.

6.7.4.1. UTH rule (rule not law)

6.7.4.1.1. Units, Tens and Hundreds

6.7.4.1.2. U - Very early on during the initial work you would probably be able to count the (high-level) requirements on the fingers of your hands (<10)

6.7.4.1.3. T - Shortly after this and after more investigation has moved the project further forward, the number of (medium level) requirements would have increased but it would still be less than a hundred (<100)

6.7.4.1.4. H - Finally, as the project fully defines the products in detail (low-level requirements), you may have hundreds of requirements although not thousands (>100)

6.7.5. Principle supported by:

6.7.5.1. Roles

6.7.5.1.1. Project Manager (PM)

6.7.5.1.2. Team Leader (TL)

6.7.5.2. Techniques

6.7.5.2.1. MoSCoW

6.7.5.2.2. Timeboxing

6.8. 3 - Collaborate

6.8.1. Teams that work in a spirit of active cooperation and commitment will always outperform groups of individuals working only in loose association.

6.8.1.1. Collaboration encourages increased understanding, greater speed and shared ownership, which enable teams to perform at a level that exceeds the sum of their parts.

6.8.2. In order to fulfill this principle, project teams need to:

6.8.2.1. Involve the right stakeholders, at the right time, throughout the project

6.8.2.2. Encourage pro-active involvement from the business representatives

6.8.2.2.1. Encourages increased understanding, greater speed and shared ownership

6.8.2.2.2. Actively involve business

6.8.2.3. Ensure that all members of the team are empowered to take decisions on behalf of those they represent

6.8.2.3.1. Even at the lowest level (with agreed boundaries)

6.8.2.4. Build a one team culture (also between supplier and customer)

6.8.2.4.1. Deployment is more likely to go smoothly, because of the co-operation of all parties concerned throughout development

6.8.2.4.2. Teams work in a spirit of active co-operation and commitment. Collaboration encourages understanding, speed and shared ownership. The teams must be empowered and include the business representatives

6.8.3. Business Visionary (BV), Business Ambassador (BAMB) and Business Advisor (BADV) roles bring appropriate subject matter experts (SMEs) into project to contribute to solution

6.8.4. Business Analyst (BA) is responsible for facilitating high level collaboration between team members

6.8.5. Facilitated workshops technique enable stakeholders to share knowledge with the project team

6.8.5.1. "A well-constructed project management workshop should give people a solid foundation to build on." Bentley & Borman, 2001

6.8.6. The risk of building the wrong solution is greatly reduced

6.8.6.1. a.k.a. "fatware"

6.8.6.2. a.k.a. "shelfware"

6.8.6.3. a.k.a. "zombieware"

6.8.6.4. ...

6.8.7. The final solution is more likely to meet the users' real business requirements

6.8.8. Motivation is a key aspect - people want to be part of something

6.8.9. Recommended co-location

6.8.10. Solution Development Teams are:

6.8.10.1. Empowered

6.8.10.1.1. "Get the right people. Then, no matter what else you may do wrong after that, the people will save you. That's what management is all about." Tom DeMarco, 1997

6.8.10.1.2. "Worker are knowledge workers if they know more about the work they perform than their bosses." Peter Drucker

6.8.10.2. Self-directed / Self-disciplined

6.8.10.2.1. Teams commit only to the work they can accomplish and then perform that work as effectively as possible.

6.8.10.2.2. Fully and exclusively responsible for working out how the Timebox products will be developed.

6.8.10.3. Self-organizing

6.8.10.3.1. Teams estimate and plan their own work and then proceed to collaborate iteratively to do so.

6.8.10.3.2. Style of working

6.8.10.3.3. Who is needed on the team and not

6.8.10.3.4. When it needs help resolving Impediments

6.8.10.3.5. Needed process improvements

6.8.10.3.6. Technology practices

6.8.10.3.7. Techniques

6.8.10.3.8. Who does what and when

6.8.10.3.9. Self-organizing rarely means self-managing

6.8.10.3.10. "[...] study by Nonaka has shown that Japanese companies with a self-organizing characteristic tend to have higher performance records [...]" K. Imai, I.Nonaka, H. Takeuchi

6.8.10.3.11. "Never tell people how to do things. Tell them what to do, and they will surprise you with their ingenuity." General George S. Patton

6.8.10.4. Self-aware

6.8.10.4.1. Teams strive to identify what works well for them, what doesn’t, and then learn and adjust accordingly.

6.8.10.5. Self-sufficient

6.8.10.5.1. Having all the skills needed within the team to deliver and test products.

6.8.10.6. No hierarchy within the team

6.8.10.6.1. No bosses or managers.

6.8.10.7. Cross-functional

6.8.10.7.1. Without demarcation by role e.g. analyst, developer, tester, everybody is expected to perform any type of work needed to get the job done.

6.8.10.8. Small (7 +/- 2)

6.8.10.8.1. AgilePM® suggests that the optimum SDT size is 7 +/- 2 people - at this level, the team can communicate with one another with the minimum of formality, minimum of management overhead..

6.8.10.8.2. see George A. Miller: "The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information"

6.8.10.9. Autonomical

6.8.10.9.1. Yet SDTs do not work in a vacuum.

6.8.10.10. Accountable

6.8.10.10.1. SDTs are accountable for fulfilling the goal(s) they have taken on.

6.8.10.11. Collaborative

6.8.10.11.1. Download: 17 Indisputable Laws of Teamwork by John Maxwell

6.8.10.11.2. Improved collaboration between peole correspondingly increases the opportunities for people to learn from one another.

6.8.10.12. Based on trust and respect

6.8.10.13. Ideally static

6.8.10.13.1. Most successful with long-term, full-time membership.

6.8.10.13.2. Subject to re-structuring if team is not working.

6.8.10.14. Ideally collocated

6.8.10.14.1. Most successful when located in one team room (particularly for the first few Timeboxes).

6.8.10.14.2. Collocated mentally not only phisically.

6.8.10.14.3. "Ensure your documentation is short and sharp and make much more use of people-to-people communication." Bentley & Borman, 2001

6.8.11. Principle supported by:

6.8.11.1. Roles

6.8.11.1.1. Business Sponsor (BS)

6.8.11.1.2. Business Visionary (BV)

6.8.11.1.3. Business Ambassador (BAMB)

6.8.11.1.4. Solution Development Teams (SDTs)

6.8.11.1.5. Workshop Facilitator (WF)

6.8.11.2. Techniques

6.8.11.2.1. Facilitated Workshops

6.8.11.2.2. Daily Stand-ups (a.k.a. Scrum meetings)

6.9. 4 - Never compromise quality

6.9.1. A solution has to be “good enough”.

6.9.1.1. Perfect is too expensive

6.9.1.1.1. Definition of perfect can be rarely defined and different among stakeholders

6.9.1.2. If the business agrees features in Minimum Usable Subset have been provided, then the solution should be acceptable

6.9.2. In order to fulfill this principle, project teams need to:

6.9.2.1. Agree the level of quality from the outset before development starts

6.9.2.1.1. Quality level is set upfront and never changes through entire project and all Timeboxes

6.9.2.2. Ensure that quality does not become a variable

6.9.2.2.1. A solution has to be “good enough”.

6.9.2.3. Test early, test continuously and test to the appropriate level

6.9.2.3.1. MoSCoW and timeboxing ensure testing is appropriate, without introducing unnecessary risks

6.9.2.3.2. "Bad programmers have all the answers. Good testers have all the questions.", Gil Zilberfeld

6.9.2.4. Build in quality by constant review with the right people

6.9.2.4.1. Projects must test early and continuously and review constantly.

6.9.2.5. Design, document and test appropriately

6.9.3. Ensure testing is properly integrated into the Iterative Development process, with regular reviews throughout the project lifecycle, helps the AgilePM® team to build a quality solution.

6.9.3.1. The review and quality control products created as the project proceeds help demonstrate that the quality of the solution is meeting the expected standard.

6.9.4. Fail fast.

6.9.4.1. "fail fast, learn fast"

6.9.4.2. Do tests every day, not only before formal sign-off

6.9.4.2.1. Solution Tester (ST) role is responsible for everyday tests

6.9.4.3. User Acceptance Testing (UAT) tests are not enough

6.9.4.3.1. e.g. in IT - use black box testing / Unit testing every day even on unfinished product

6.9.4.4. "I have not failed. I’ve just found 10,000 ways that won’t work" (Thomas Edison)

6.9.4.5. "Failure is simply the opportunity to begin again, this time more intelligently" (Henry Ford)

6.9.4.6. "Testing is more than testing (and should start before testing)" (Dorothy Graham)

6.9.5. If the business agrees features in Minimum Usable Subset have been provided, then the solution should be acceptable

6.9.6. Principle supported by:

6.9.6.1. Roles

6.9.6.1.1. Solution Tester (ST)

6.9.6.2. Products

6.9.6.2.1. Testing products

6.9.6.3. Techniques

6.9.6.3.1. MoSCoW

6.9.6.3.2. Timeboxing

6.9.6.3.3. Daily Stand-ups

6.9.6.4. Early and integrated testing

6.9.6.5. Regular reviews throughout lifecycle

6.10. 5 - Build incrementally from firm foundation

6.10.1. One of the key differentiators for AgilePM® within the Agile space is the concept of establishing firm foundations for the project before committing to significant development.

6.10.1.1. AgilePM® advocates first understanding the scope of the business problem to be solved and the proposed solution, but not in such detail that the project becomes paralysed by overly detailed analysis of requirements.

6.10.1.2. AgilePM® advocates incremental delivery of the solution in order to deliver real business benefit as early as is practical.

6.10.1.2.1. Incremental delivery encourages stakeholder confidence, offering a source of feedback for use in subsequent Timeboxes and may lead to the early realisation of business benefit.

6.10.2. In order to fulfill this principle, project teams need to:

6.10.2.1. Carry-out appropriate analysis and enough design up front (EDUF) to create strong foundations.

6.10.2.2. Formally re-assess priorities and informally re-assess ongoing project viability with each delivered increment.

6.10.3. Incremental delivery (of value to production / live environment)

6.10.3.1. Increments allow the business to take advantage of work before the final product is complete, encouraging stakeholder confidence and feedback.

6.10.3.1.1. This is based on doing just enough upfront analysis to proceed and accepting that detail emerges later.

6.10.3.2. Deliver functionality in stages by focusing on ‘quick-wins’ to gain early confidence and early business support.

6.10.3.2.1. Momentum is built.

6.10.3.2.2. Solution should be delivered in increments that provide the greatest value to the customer.

6.10.4. Increments deployed into operational use for early ROI.

6.10.5. Strive for early delivery of business benefit where possible.

6.10.6. Continually confirm the correct solution is being built.

6.10.7. Implement this principle using AgilePM® lifecycle

6.10.8. "The increment must be completed, meaning the increment must be a complete piece of usable software." K. Schwaber, J. Sutherland

6.10.9. Principle supported by:

6.10.9.1. Techniques

6.10.9.1.1. Iterative Development (IPER cycle)

6.10.9.2. AgilePM® Lifecycle

6.11. 6 - Develop iteratively

6.11.1. AgilePM® uses a combination of Iterative Development, frequent demonstrations and comprehensive review to encourage timely feedback.

6.11.1.1. Embracing change as a part of this evolutionary process allows the team to converge on an accurate business solution.

6.11.1.2. The concept of iteration is at the heart of everything developed as part of the AgilePM® approach.

6.11.2. In order to fulfill this principle, project teams need to:

6.11.2.1. Build business / customer / user feedback into each iteration

6.11.2.1.1. This means that AgilePM® project lifecycle is adaptive to new business requirements gathered after feedback

6.11.2.2. Recognise that most detail should emerge later rather than sooner

6.11.2.3. Embrace change - the right solution will not evolve without it

6.11.2.3.1. “People don’t know what they want until you show it to them” (Steve Jobs, 1955 - 2011)

6.11.2.4. Use Iterative Development to encourage creativity, experimentation and learning

6.11.2.4.1. Iterative approach on all projects

6.11.2.4.2. Previous steps can be revisited as part of its iterative approach.

6.11.2.4.3. This means that AgilePM® project lifecycle is iterative

6.11.3. Do enough design up front (EDUF) to create strong foundations.

6.11.4. Accept that work is not always right first time.

6.11.4.1. It is rare that anything is created perfectly first time and it is important to recognise that project operate within a changing world.

6.11.4.2. Use Timeboxes to allow for change yet continuously confirm that the solution is the right one.

6.11.5. Accept most detail emerges later rather than sooner.

6.11.5.1. "Often end users / clients doesn't know what then need and think they know what they want!"

6.11.6. Be creative, experiment, innovate, test, learn, evolve.

6.11.7. Principle supported by:

6.11.7.1. Techniques

6.11.7.1.1. Iterative Development (IPER cycle)

6.11.7.1.2. Timeboxing

6.11.7.1.3. Prototyping

6.11.7.1.4. Modelling

6.11.7.2. Iteration and constant review

6.12. 7 - Communicate continuously and clearly

6.12.1. Poor communication is often cited as the biggest single cause of project failure.

6.12.1.1. AgilePM® practices are specifically designed to improve communication effectiveness for both teams and individuals.

6.12.2. In order to fulfill this principle, project teams need to:

6.12.2.1. Encourage informal, face-to-face communication at all levels

6.12.2.2. Run daily stand-ups sessions

6.12.2.2.1. Same like Daily Scrum Meetings in Scrum framework. Agile daily team stand-up session are exactly the same.

6.12.2.3. Use workshops, with a facilitator where appropriate

6.12.2.4. Use rich, visual communication (best interactive) communication techniques such as Modelling and Prototyping

6.12.2.5. Demonstrate the evolving solution early and often (as a minimum, the end of each Timebox)

6.12.2.6. Keep documentation lean and timely.

6.12.2.7. Manage the expectations of the stakeholder at all levels throughout the project.

6.12.2.8. Always aim for honesty and transparency in all communication

6.12.3. Modelling and Prototyping make early instances of the solution available for scrutiny.

6.12.3.1. These practices are far more effective than the use of large textual documents, which are sometimes written for reasons other than achieving the business objectives of the project.

6.12.3.2. Present instances of the evolving solution (not perceptions hidden behind PowerPoint presentations or Excel cells) early and often.

6.12.4. Communication, Conversation, Collaboration, Community, Culture (5C).

6.12.5. Effectiveness of different modes of communication.

6.12.5.1. The horizontal axis indicates the “temperature” of the communication channel.

6.12.5.1.1. Warmer indicates that more emotional and informational richness gets conveyed.

6.12.6. Principle supported by:

6.12.6.1. Roles

6.12.6.1.1. Workshop Facilitator (WF)

6.12.6.2. Techniques

6.12.6.2.1. Facilitated workshops

6.12.6.2.2. Daily Stand-ups

6.12.6.3. Clearly defined roles

6.12.6.4. User and business involvement

6.12.6.5. Team empowerment

6.12.6.6. Models and prototypes

6.13. 8 - Demonstrate control

6.13.1. Demostrate control - for customer and users to show that everything is under control

6.13.1.1. “If everything seems under control, you're not going fast enough.“ (Mario Andretti, Italian American world champion racing driver)

6.13.2. The starting point for this is having an empowered team who are actively involved in areas such as estimating their work and helping to create the plans they are signing up to.

6.13.3. In many environments it is not enough simply to be in control, it needs to be able to prove it

6.13.3.1. It is essential to be in control of a project at all times to be able to demonstrate that this is the case.

6.13.3.1.1. This can only be achieved by reference to a plan for the work being done, which is clearly aligned with agreed business objectives.

6.13.3.1.2. It is also vital to ensure transparency of all work being performed be the team.

6.13.4. In order to fulfill this principle, project teams need to:

6.13.4.1. Make plans and progress visible to all.

6.13.4.1.1. Even to lowest level team members.

6.13.4.2. Measure progress through focus on delivery of products rather than completed activities.

6.13.4.3. Manage proactively

6.13.4.4. Evaluate continuing project viability based on the business objectives.

6.13.4.5. Use an appropriate level of formality for tracking and reporting.

6.13.5. The team needs to be proactive when monitoring and controlling progress in line with Foundations Phase.

6.13.5.1. They need to constantly evaluate the project viability based on the business objectives.

6.13.6. The use of well-defined Timeboxes, with constant review points, and the preparation of the Management Foundations product (document) and Timebox Plans, are designed to assist the Project Manager (PM) and the rest of the project team to follow this principle.

6.13.7. Principle supported by:

6.13.7.1. Roles

6.13.7.1.1. Project Manager (PM)

6.13.7.1.2. Team Leader (TL)

6.13.7.2. Products

6.13.7.2.1. Management Foundations

6.13.7.2.2. Timebox Plans

6.13.7.3. Techniques

6.13.7.3.1. Timeboxing

6.13.7.4. Constant review with client and users

6.14. Summary & Conclusion

6.14.1. AgilePM® is an Agile Project Delivery Framework that delivers the right solution at the right time

6.14.1.1. Iterative

6.14.1.2. Incremental

6.14.1.3. Adaptive

6.14.1.4. Empirical

6.14.1.5. Change-driven

6.14.2. The right business solution is delivers because

6.14.2.1. The Project Team and others significant stakeholders remain focused on the business outcome

6.14.2.2. Delivery is on time providing an early ROI and reduced risk

6.14.2.3. All people involved with the project work collaboratively to deliver the optimum solution

6.14.2.4. Work is prioritized according to business need and the ability of users to accommodate changes

6.14.2.5. AgilePM® does not compromise quality

7. AgilePM® V2 Project Lifecycle Phases (6) (a.k.a. 'building blocks')

7.1. Overview

7.1.1. In line with the 5 and 6 principles, the AgilePM® lifecycle is both iterative and incremental.

7.1.1.1. Each phase has objectives and pre-conditions.

7.1.1.2. This configurability of AgilePM® Lifecycle allows the project manager significant opportunity to deliver business value early and to demonstrate progress. The framework is highly configurable, depending on the size and formality of the project being delivered.

7.1.1.2.1. It is sequential for Pre-project, Feasibility and Foundations.

7.1.1.2.2. Can have many iterations of Evolutionary Development.

7.1.1.2.3. Can have many separate Deployments in one project!

7.1.1.2.4. Post Project will be sequential with the last Deployment.

7.1.1.3. Solution may not be delivered to the business in one go, but in a series of increments that increase the breadth and/or depth of the solution with each delivery.

7.1.1.3.1. Urgent business needs can be addressed early while less important features are delivered later.

7.1.1.4. Iterative nature of AgilePM® enables business representatives to see work under construction, comment on it and request changes during the development of an increment of the solution.

7.1.1.5. Each lifecycle phase will deliver Products and, within AgilePM®, delivery of Products (to the appropriate and agreed level of quality) is used to assess progress.

7.1.1.6. It is important to keep the phases of the lifecycle visible to the SDT during the project.

7.1.1.7. Typically, plan for Feasibility and Foundations phases to be shorter than would be the case for a traditional one-delivery project. Allow for just Enough Design Up Front (EDUF).

7.1.1.8. Project phases are 'building blocks' from which you are building project lifecycle. It is a framework.

7.2. AgilePM® provides an iterative, incremental and adaptive framework, with 6 lifecycle phases.

7.2.1. AgilePM® V2 Project Lifecycle Phases with requirements evolving

7.2.2. AgilePM® V2 Iterative development

7.3. 1. Pre-Project

7.3.1. Introduction

7.3.1.1. The work of the Pre-Project phase simply formalises a proposal for a project and places it in the context of other potential work to be, or already being, carried out by the organisation.

7.3.1.2. In most corporate environments projects exist as part of a portfolio of other projects and sometimes exist as part of a programme of projects with a shared business change objective.

7.3.1.2.1. Regardless, projects need to be set up correctly from the outset to ensure success.

7.3.2. Objectives

7.3.2.1. To describe the business problem to be addressed.

7.3.2.2. To identify a Business Sponsor (BS) and Business Visionary (BV).

7.3.2.3. To confirm that the project is in line with business vision, mission, strategy, corporate investment porfolio.

7.3.2.4. To scope, plan and resource the Feasibility phase (only Feasibility phase NOT the whole project).

7.3.2.5. To formulate a proposal for a project and priorities it in the context of other work being carried out by the organisation in line with its strategic goals.

7.3.3. Consider

7.3.3.1. The intended work of the Pre-Project phase should be short, sharp and ideally restricted to the creation of a short statement that has the purpose of justifying and prioritising a Feasibility investigation.

7.3.4. In real life corporate environments this phase is often called Project Kick-off

7.4. 2. Feasibility

7.4.1. Introduction

7.4.1.1. Project management best practice dictates that the viability of the project should be continually assessed throughout the project, ensuring that the benefits predicted from the use of end products of the project outweigh the costs of delivering them.

7.4.1.2. The Feasibility phase provides the first opportunity for deciding whether a proposed project is viable from both a business (Business Sponsor (BS) and Visionary (BV)) and a technical (Technical Coordinator (TC)) perspective by means of a high level investigation of the potential solutions, costs and timeframes.

7.4.1.2.1. The Feasibility phase is intended primarily to establish whether the proposed project is likely to be feasible from a technical perspective and whether it appears cost-effective from a business perspective.

7.4.2. Preconditions

7.4.2.1. The Terms of Reference (ToR) for the project have been approved.

7.4.2.2. The required resources are available to carry out the feasibility investigation.

7.4.2.3. The Business Visionary (BV) has sufficient time available to help shape the project.

7.4.3. Objectives

7.4.3.1. To establish whether there is a feasible solution to the business problem described in the Terms of Reference (ToR) defined during Pre-Project.

7.4.3.2. To identify the benefits likely to arise from the delivery of the proposed solution.

7.4.3.3. To outline possible approaches for delivery, including strategies for sourcing the solution and project management.

7.4.3.4. To describe the organisation and governance aspects of the project.

7.4.3.5. To state first-cut estimate of timescale and costs for the project overall.

7.4.3.6. To plan and resource the Foundation phase.

7.4.4. Consider

7.4.4.1. If you are going to stop work on a project then it is important that you stop as early as possible.

7.4.4.2. The effort associated with Feasibility should be just enough to decide whether further investigation is justified, or whether the project should be stopped now, as it is unlikely to be viable.

7.4.4.3. The Feasibility phase should be kept as short and sharp as possible, remembering that its only purpose is to justify progressing to the Foundations phase.

7.4.4.3.1. The detail of the investigation happens in the Foundations phase.

7.5. 3. Foundations

7.5.1. Introduction

7.5.1.1. The Foundations phase is aimed at establishing firm and enduring foundations for the project.

7.5.1.1.1. The Foundations phase takes the preliminary investigation from Feasibility to the next level.

7.5.1.1.2. In establishing the foundations, the three essential perspectives need to be combined to provide a clear project focus that is both robust and flexible.

7.5.1.2. It is intended to establish a fundamental (but not detailed) understanding of the business rationale for the project, the potential solution that will be created by the project, and how development and deliver y of the solution will be managed.

7.5.1.3. To create solid foundations, it is vital that detail, particularly around the solution, is strictly limited so that it does not unnecessarily constrain the way the solution evolves but still clearly demonstrates how it will meet the needs of the business.

7.5.1.3.1. The aim of Foundations is to understand the scope of work, how it will be carried out, by whom, when and where.

7.5.2. Preconditions

7.5.2.1. agreement of the Feasibility Assessment (if created)

7.5.3. Objectives

7.5.3.1. To baseline the high-level requirements for the project and describe their priority and relevance to the business need

7.5.3.2. To describe the business processes to be supported by the proposed solution

7.5.3.3. To identify information used, created and updated by the proposed solution

7.5.3.4. To describe the strategies for all aspects of solution deployment

7.5.3.5. To detail the Business Case for the project

7.5.3.6. To start designing the solution architecture and identifying the physical or infrastructural elements of solution

7.5.3.7. To define technical implementation standards

7.5.3.8. To decribe how quality will be assured

7.5.3.9. To establish appropriate governance and organisation for the project

7.5.3.10. To describe the solution development lifecycle for the project along with techniques to be applied in managing the project and for demonstrating and communicating progress

7.5.3.11. To baseline a schedule for development and deployment activities for the solution

7.5.3.12. To describe, assess and manage risk associated with the project

7.5.4. Consider

7.5.4.1. Significant business input will be required during the Foundations phase.

7.5.4.1.1. The relevant business representatives must be identified early and their level of involvement agreed.

7.5.4.2. Set a time limit for the Foundations phase and try to stick to it.

7.5.4.3. The aim of this phase is to create a high-level but sound view of the business and technical aspects of the project.

7.5.4.3.1. Only produce the Foundation products to the level that allows the project to move into the first exploratory development phase.

7.5.4.4. For smaller, simpler projects, the Feasibility and Foundations phases can often be merged into a single phase

7.5.5. It may sometimes be necessary to revisit Foundations after a Deployment phase.

7.5.5.1. The decision to revisit Foundations may be planned in from the star t of the project; for example, on a project where the business environment is sufficiently dynamic that the Foundations are expected to encounter significant change during the life of the project.

7.5.5.2. Alternatively, the decision to revisit Foundations may be taken after a Deployment has produced an unexpected outcome.

7.5.6. The Foundations phase also determines the project lifecycle by agreeing how the DSDM process will be applied to the specific needs of this project.

7.5.7. In case of smaller projects sometimes known as Sprint 0 in Scrum.

7.6. 4. Evolutionary Development

7.6.1. Preconditions (for moving out of Foundations)

7.6.1.1. The Business, Solution and Management Foundations products have ben collectively accepted as provide an adequate foundation from which a solution can evolve

7.6.1.2. The environments (physical and, where appropriate, technical) are in plase and adequately set up to support the development of solution

7.6.1.3. All required project personnel and stakeholders are engaged as necessary

7.6.2. The Evolutionary Development phase requires the Solution Development Team(s) to apply practices such as Iterative Development, timeboxing, and MoSCoW prioritisation, together with Modelling and Facilitated Workshops, to converge over time on an accurate solution that meets the business need and is also built in the right way from a technical viewpoint.

7.6.3. Working within Timeboxes, the Solution Development Team create Solution Increments, iteratively exploring the low-level detail of the requirements and testing continuously as they move forward.

7.7. 5. Deployment

7.7.1. Introduction

7.7.1.1. The primary purpose of the Deployment phase is to get the solution into live use.

7.7.1.1.1. Where the end-products of the project are to be sold or distributed outside of the organisation creating it, the Deployment phase is used to get the products ready to ship.

7.7.1.2. A secondary purpose is to act as a key review point prior to Deployment or future development work.

7.7.1.3. The number of passes through the Deployment phase will depend on whether it is sensible and feasible for the business to accept delivery of the overall solution incrementally.

7.7.2. Preconditions

7.7.2.1. The Deployable Solution has been approved for deployment

7.7.3. Objectives

7.7.3.1. A final ‘assembly point’ for the solution - bringing together the business and technical aspects of the change and, where applicable, the potentially shippable product increment outputs of multiple teams

7.7.3.2. A final check point for the integrity of the overall solution - which may include final testing in a controlled production-like environment (not a traditional UAT)

7.7.3.3. To confirm the ongoing performence and viability of the project and re-plan as required

7.7.3.3.1. The essential go/no go’ governance decision point

7.7.3.4. To deploy the solution (or increment of it) into the live business environment

7.7.3.4.1. Formal handover of the solution to operational support staff.

7.7.3.5. Training of end users and support staff

7.7.3.5.1. Where applicable, to train the end users of the solution and/or provide necessary documentation to support the live operation of the solution in the business environment

7.7.3.5.2. To train and/or provide documentation for operations and support staff who will responsible for supporting and maintaining technical aspects of the solution

7.7.3.6. To assess whether the deployed solution is likely to enable the delivery of intended elements of business benefit described in the Business Case (where created)

7.7.3.7. An opportunity for retrospection - similar to a Sprint retrospective - but for a Release

7.7.3.8. A good deployment is:

7.7.3.8.1. Predictable

7.7.3.8.2. Repeatable

7.7.3.8.3. Automatable

7.7.3.8.4. Reversable

7.7.3.8.5. Extendable

7.7.3.9. After the final deployment:

7.7.3.9.1. To formally bring the project to a close.

7.7.3.9.2. To review overall project performance from a technical and/or process perspective.

7.7.3.9.3. To review overall project performance from a business perspective.

7.7.4. Consider

7.7.4.1. If the solution is being deployed incrementally, it is usually appropriate to formally assess whether the project should continue after each interim deployment.

7.7.4.1.1. The Pareto Principle (or 80:20 rule) implies that it is possible that the vast majority of the benefit might be enabled by an early interim delivery.

7.7.4.2. It therefore makes sense to check that investment in the rest of the planned project will provide a reasonable return.

7.7.4.3. Justification to continue is likely to reflect the cost of operating the solution as it stands against the cost of operating a more complete solution.

7.7.5. The release that is deployed may be the final solution, or a subset of the final solution.

7.7.6. Assemble

7.7.6.1. This requires the consolidation of all artefacts deemed relevant for the deployment of the solution. For example, the deployment of a business process may require a new software package, documentation for users and a communication to all stakeholders.

7.7.7. Review

7.7.7.1. This is essentially a quality gate that requires approval of the correctness and completeness of the assembled assets and offers an appropriate point for reflection on the project increment. Most organisations institutionalise such measures as checklists or more formal approval boards.

7.7.8. Deploy

7.7.8.1. This step concerns the actual act of transition of assets into operational use. For example this might entail installation and configuration of a software package, training of users and release of a communication.

7.8. 6. Post-Project

7.8.1. Introduction

7.8.1.1. The Post-Project phase takes place after the last planned deployment of the solution. Its purpose is to reflect on the performance of the project in terms of the business value actually achieved.

7.8.1.1.1. Assessment should start as soon as the value can be measured.

7.8.2. Preconditions

7.8.2.1. The solution has been successfully deployed.

7.8.2.1.1. Phase commences after the final increment has been deployed and is chiefly concerned with an assessment over time of the benefits accrued.

7.8.2.2. After the final Deployment for a project, the Post-Project phase checks how well the expected business benefits have been met.

7.8.2.2.1. Although it may be possible to highlight immediate benefits, most benefits will accrue over a pre-defined period of live use of the solution.

7.8.3. Objectives

7.8.3.1. To assess whether the benefits described in the Business Case (where created) have actually been achieved through use of the Deployed Solution

7.8.3.2. Mostly, the project will have been closed prior to the start of the Post-Project phase.

7.8.3.3. In some projects where the overall solution is delivered incrementally, it is often appropriate to start the benefits realisation process before the final deployment.

7.8.3.3.1. Under such circumstances it may be appropriate to feed any proposals for change or enhancement back into the ongoing project.

7.8.3.4. The Business Sponsor (BS) and Business Visionary (BV) have an ongoing responsibility for ensuring that the benefits enabled by the project are actually realised through proper use of the solution provided.

7.8.4. The Post-Project phase produces one or more Benefits Assessments for these realised benefits in relation to the business case.

7.8.4.1. Benefits may be assessed for individual releases (in which case the assessment of benefit should star t before the Post-Project phase is reached), for the whole project or may be omitted completely, depending on the needs of the organisation.

7.9. AgilePM V2 project lifecycle examples

7.10. Summary & Conclusion

7.10.1. AgilePM® provides an iterative and incremental framework, with 6 lifecycle phases

7.10.2. Each phase has objectives and pre-conditions

7.10.3. Specifically, each lifecycle phase will deliver Products

7.10.4. The acceptance of products enables agreement that the project can move safely from one lifecycle phase to another

7.10.5. The framework is highly configurable, depending on the size and formality of the project being delivered

8. AgilePM® V2 Roles (13)

8.1. Introduction

8.1.1. Roles are not positions, nor are they meant to be.

8.1.1.1. Agile deemphasizes specialized roles and considers all team members equal - everyone pitches in to deliver a working solution regardless of their job description.

8.1.2. The Project-level roles are

8.1.2.1. Business Sponsor (BS), Business Visionary (BV), Technical Coordinator (TC), Project Manager (PM) and Business Analyst (BA)

8.1.2.2. Directors, managers and coordinators of the project work. They will either be on or directly report to any project board or steering committee.

8.1.3. The Business Visionary (BV) and the Technical Coordinator (TC) hold the customer and supplier visions of solution excellence.

8.1.4. The Project Manager (PM) ensures that the funding supplied is used effectively to create the envisaged solution.

8.1.5. The Development roles are

8.1.5.1. Team Leader (TL), Business Ambassador (BAMB), Business Analyst (BA), Solution Developer (SD) and Solution Tester (ST).

8.1.5.2. Jointly these roles form the engine room of the project.

8.1.6. The Development roles shape and build the solution, are collectively responsible for its day-to-day development and for assuring its fitness for business purpose.

8.1.7. The Supporting roles are

8.1.7.1. Business Advisors (BADV), Technical Advisors (TADV), Workshop Facilitator (WF) and DSDM Coach (DC) provide assistance and guidance to the project on a more ad hoc basis throughout the lifecycle.

8.1.7.2. The project may bring in subject matter experts as necessary for their specialist expertise.

8.1.8. There may be one or more Solution Development Teams (SDTs): the membership of each team should be stable and cover all the responsibilities defined for the Development roles.

8.1.8.1. SDTs are team with goals, not set of individuals forming a group of unrelated peoples having different personal goals.

8.1.8.1.1. Team means:

8.2. Legend

8.2.1. Orange

8.2.1.1. Business intrest roles representing the business view

8.2.1.2. Typically taken by business personnel

8.2.2. Blue

8.2.2.1. Management intrest roles representing the management / leadership view

8.2.2.2. Managing or facilitating the management / leadership aspects of the project

8.2.3. Green

8.2.3.1. Solution / technical intrest roles representing the solution / technical view

8.2.3.2. Contributing to technical consistency, design or development of the solution

8.2.4. Grey

8.2.4.1. Process intrest roles representing the process view

8.2.4.2. Facilitating the process aspects of the project

8.3. Role Combinations

8.3.1. Permissible Role Combinations

8.3.1.1. Combinations should not in general be considered transitive.

8.3.1.1.1. The ability to combine two distinct but overlapping pairs of roles does not imply that all three roles should be combined

8.3.1.2. Business Sponsor + Business Visionary

8.3.1.3. Business Visionary + Business Ambassador

8.3.1.4. Team Leader + Solution Developer

8.3.1.5. Team Leader + Solution Tester

8.3.1.6. Business Advisor + Soluton Tester

8.3.2. Non Permissible Role Combinations

8.3.2.1. Business Sponsor + Project Manager

8.3.2.2. Business Visionary + Project Manager

8.3.2.3. Business Visionary + Technical Coordinator

8.3.2.4. Business Analyst + Business Ambassador

8.3.2.5. Project Manager + Team Leader

8.3.2.6. Solution Developer + Solution Tester

8.3.2.7. Workshop Facilitator + any Project level role

8.3.2.8. DSDM Coach + any SDT role

8.4. Project-level roles

8.4.1. The Project-level roles are

8.4.1.1. Business Sponsor (BS), Business Visionary (BV), Technical Coordinator (TC), Project Manager (PM) and Business Analyst (BA)

8.4.1.2. Directors, managers and coordinators of the project work. They will either be on or directly report to any project board or steering committee.

8.4.2. Business Sponsor (BS)

8.4.2.1. Most senior project-level role

8.4.2.1.1. the Project Champion

8.4.2.2. Project Champion who is committed to the project, to the proposed solution and the approach to delivering it.

8.4.2.2.1. This role should be committed, supportive and available for the duration of the project.

8.4.2.3. Committed to project and proposed solution

8.4.2.4. Committed to the approach for delivering the project

8.4.2.5. Provides the overall strategic direction and funding.

8.4.2.6. Hold a sufficiently high position in the organisation to be able to resolve business issues (e.g. to force open closed doors) and make financial decisions.

8.4.2.6.1. High enough in organisation to resolve business issues and make financial decisions

8.4.2.7. Has a crucial responsibility to ensure and enable fast progress throughout the project.

8.4.2.8. (ideally) There should be only one person responsible for this role.

8.4.2.8.1. On larger project or in complex organisations, the Business Sponsor's financial responsibility may be fulfilled by a higher authority such as an investment board or an executive committee.

8.4.2.9. Prime concern is in the value and benefit of the project, rather than details

8.4.2.10. Responsibilities

8.4.2.10.1. Owning the Business Case for the project

8.4.2.10.2. Ensuring ongoing viability of the project in line with the Business Case

8.4.2.10.3. Holding the budget for the project

8.4.2.10.4. Ensuring that funds and other resources are made available as needed

8.4.2.10.5. Ensuring the decision-making process for escalated project issues is effective and rapid.

8.4.2.10.6. Responding rapidly to escalated issues and being the ultimate point for resolution of conflict within the project

8.4.2.10.7. Empowering the business roles within the project, to appropriate levels, within their responsibilities

8.4.2.10.8. Keeping themselves informed of progress and issues, e.g. by attending demonstrations at the end of Timeboxes and asking questions of other roles who are more actively engaged

8.4.2.11. Mappings to other roles in other methods ...

8.4.2.11.1. PRINCE2®

8.4.3. Business Visionary (BV)

8.4.3.1. Senior project-level business role.

8.4.3.2. Should be held by a single individual, since a project needs a single clear vision to avoid confusion and misdirection.

8.4.3.2.1. Single person actively involved to provide a clear vision and strategic direction.

8.4.3.3. Provides the “big picture” and the context for the project.

8.4.3.4. More actively involved than the Business Sponsor (BS).

8.4.3.4.1. Interprets and communicates business needs of Business Sponsor (BS) and ensures these needs are represented in business case.

8.4.3.5. Responsible for interpreting the needs of the Business Sponsor (BS), communicating these to the team and, where appropriate, ensuring they are properly represented in the Business Case.

8.4.3.6. If the project is part of a larger programme, the Visionary is in a position to judge project issues in the light of the programme and the potential impacts beyond the project.

8.4.3.7. Remains involved throughout the project.

8.4.3.8. Providing the team with strategic direction.

8.4.3.9. Ensuring that the solution delivered will enable the benefits described in the Business Case to be achieved.

8.4.3.10. In real life Business Visionary (BV) is often Product Manager

8.4.3.11. Responsibilities

8.4.3.11.1. Defining the business vision for the project.

8.4.3.11.2. Communicating and promoting the Business Vision to all interested and/or impacted parties

8.4.3.11.3. Monitoring progress of the project in line with the Business Vision

8.4.3.11.4. Owning the wider implications of any business change from an organisational perspective

8.4.3.11.5. Contributing to key requirements, design and review sessions (in Timeboxes), particularly where aspects of the solution being considered address key elements of the business vision

8.4.3.11.6. Identifying and owning business-based risk

8.4.3.11.7. Defining, and approving changes to, the high level requirements in the Product Backlog; i.e. any change that affects the baselined scope or significantly alters the balance of priorities.

8.4.3.11.8. Ensuring collaboration across stakeholder business areas within the scope of the project

8.4.3.11.9. Ensuring business resources are available to the project as needed

8.4.3.11.10. Promoting the translation of the business vision into working practice, i.e. ensuring full business adoption of the solution created by the project.

8.4.3.11.11. Empowering the business roles within Solution Development Team, to appropriate levels, within their responsibilities.

8.4.3.11.12. Where the Solution Development Team cannot agree, acting as a arbiter of business differences related to the business need and the way this is addressed in the Evolving Solution.

8.4.3.11.13. ... in general governing WHAT

8.4.3.12. Mappings to other roles in other methods ...

8.4.3.12.1. PRINCE2®

8.4.4. Technical Coordinator (TC)

8.4.4.1. Technical authority for project, providing the technical vision.

8.4.4.2. Technical architecture design authority.

8.4.4.2.1. A good architecture should provide consistent guidelines to system development.

8.4.4.2.2. A good architecture should include all the high-level decisions made to address the systemic quality requirements / non functional requirements (NFR)

8.4.4.2.3. Characteristics of a Good Architecture

8.4.4.3. Ensures technical consistency and coherence across SDTs.

8.4.4.4. Ensures adherence to agreed standards.

8.4.4.5. The “glue” that holds the project together for technology and innovation.

8.4.4.5.1. Advising on technical decisions and innovation.

8.4.4.6. Equivalent to the Business Visionary (BV), ensuring the solution is technically sound and cohesive.

8.4.4.6.1. When the same person is in both roles (BV and TC) there is too much temptation to gold plate the solution with features that are technically interesting but of little or no value to the actual stakeholders.

8.4.4.7. Responsibilities

8.4.4.7.1. Agreeing and controlling the technical architecture.

8.4.4.7.2. Determining the technical environments.

8.4.4.7.3. Advising on and co-ordinating each team's technical activities.

8.4.4.7.4. Identifying and owning architectural and other technically based risk, escalating to the Project Manager as appropriate.

8.4.4.7.5. Ensuring the non-functional requirements (NFRs) are achievable and subsequently met.

8.4.4.7.6. Ensuring adherence to appropriate standards or best practice.

8.4.4.7.7. Controlling the technical configuration of the solution.

8.4.4.7.8. Managing technical aspects of the transition of the solution into live use.

8.4.4.7.9. Resolving technical differences between technical team members.

8.4.4.7.10. ... in general governing HOW

8.4.4.8. Mappings to other roles in other methods ...

8.4.4.8.1. PRINCE2®

8.4.4.8.2. Disciplined Agile Delivery (DAD)

8.4.5. Project Manager (PM)

8.4.5.1. Delivery focused

8.4.5.2. Provides high-level Agile-style leadership to Solution Development Team(s)

8.4.5.2.1. Multiple SDTs at once if project team is dividen on several SDTs

8.4.5.3. Focuses on managing the working environment for evolving the solution.

8.4.5.4. Good communicator, with planning, management and co-ordination skills

8.4.5.4.1. Coordinates high-level management aspects of project

8.4.5.5. Project Manager (PM) is a role - not necessarily the same as a job title that might be used in their organisation

8.4.5.6. The Project Manager (PM) ensures that the funding supplied is used effectively to create the envisaged solution

8.4.5.7. Team Leaders (TL) often do AgilePM® PM role in small projects

8.4.5.7.1. This only works, however, if the PM clearly steps back from any resemblance of a command and control style in favor of self-organization.

8.4.5.8. There is usually only one PM, or at least a single person is ultimately accountable for delivery of the project

8.4.5.9. Responsibilities

8.4.5.9.1. Project Managers (PM) with very strong personal control needs can also encounter difficulties in executing AgilePM® projects.

8.4.5.9.2. Communicating with senior management and the project governance authorities (Business Sponsor (BS), project board, steering committee, etc.) with the frequency and formality that they deem necessary.

8.4.5.9.3. Performing high level project planning and scheduling, but not detailed / Timebox planning

8.4.5.9.4. Monitoring progress against the baselined project and increment plans

8.4.5.9.5. Managing risk and any issues as they arise, or are escalated from the Solution Development Team(s), collaborating with senior business and / or technical roles as required to ensure resolution

8.4.5.9.6. Attending Daily Stand-Ups, as an observer, to keep a current understanding of progress and issues

8.4.5.9.7. Managing the overall configuration of the project

8.4.5.9.8. Project Managers (PM) need to protect the development teams from external interruptions.

8.4.5.9.9. Motivating and ensuring empowerment of the Solution Development Team(s) to meet their objectives

8.4.5.9.10. Coaching the SDTs when handling difficult situations.

8.4.5.9.11. Managing business involvement within the SDTs.

8.4.5.9.12. Resourcing Specialist Roles as required.

8.4.5.10. Mappings to other roles in other methods ...

8.4.5.10.1. PRINCE2®

8.4.6. Business Analyst (BA)

8.4.6.1. Fully integrated with SDT.

8.4.6.2. Focuses on the relationship between the business and technical roles

8.4.6.3. Ensures accurate and decisive direction is provided to the SDT on a day-to-day basis.

8.4.6.4. Ensures that the business needs are properly analysed and are correctly reflected in the guidance the team.

8.4.6.5. Responsibilities

8.4.6.5.1. Managing development, distribution and baseline approval of all documentation and products related to business requirements and their interpretation

8.4.6.5.2. Ensuring that the business implications of all day-to-day decisions are properly thought through

8.4.6.6. The Business Analyst is intentionally positioned as part of the project level as well as part of the Solution Development Team.

8.4.6.6.1. This allows the Business Analyst to, for example, help the business to formulate the Business Case, and also to be involved in assisting the business in defining their requirements during feasibility and foundations, sometimes before the full Solution Development Team. is assigned.

8.4.6.7. see AgileBA® mind map

8.5. Solution Development Team (SDT) (project can have multiple SDTs)

8.5.1. The Development roles are

8.5.1.1. Team Leader (TL), Business Ambassador (BAMB), Business Analyst (BA), Solution Developer (SD) and Solution Tester (ST).

8.5.1.2. Jointly these roles form the "engine room" of the project.

8.5.1.2.1. They shape and build the solution and are collectively responsible for its day-to-day development and for assuring its fitness for business purpose.

8.5.2. The SDT on an AgilePM® project is empowered to make decisions on a day-to-day basis within their agreed terms of reference.

8.5.2.1. They do not have to formally agree each and every decision with the PM.

8.5.2.2. Business decisions (within agreed boundaries are made by Business Ambassador(s), so healthy Solution Development Team does not need to escalate all issues.

8.5.3. The SDT has every competency it needs to deliver a done Timebox / Increment.

8.5.4. The majority of team members should be “generalizing specialists”

8.5.4.1. Also known as “T-Shaped” people

8.5.5. We should allow them to create an environment in which they will thrive as a team.

8.5.5.1. This includes allowing them to set up a work environment that fosters collaboration, use of tooling that they find most effective, and the freedom to customize and optimize their team’s development process.

8.5.6. Solution Development Teams are:

8.5.6.1. Empowered

8.5.6.1.1. A SDTs have to be empowered to make decisions if the rate of pace of development and delivery is to be kept high.

8.5.6.1.2. "Get the right people. Then, no matter what else you may do wrong after that, the people will save you. That's what management is all about." Tom DeMarco, 1997

8.5.6.1.3. "Worker are knowledge workers if they know more about the work they perform than their bosses." Peter Drucker

8.5.6.2. Self-directed / Self-disciplined

8.5.6.2.1. Teams commit only to the work they can accomplish and then perform that work as effectively as possible.

8.5.6.2.2. Fully and exclusively responsible for working out how the Timebox products will be developed.

8.5.6.2.3. Enterprise awareness is an important aspect of self-discipline because as a professional you should strive to do what’s right for your organization and not just what’s interesting for you.

8.5.6.3. Self-organizing

8.5.6.3.1. Teams estimate and plan their own work and then proceed to collaborate iteratively to do so.

8.5.6.3.2. Style of working

8.5.6.3.3. Who is needed on the team and not

8.5.6.3.4. When it needs help resolving Impediments

8.5.6.3.5. Needed process improvements

8.5.6.3.6. Technology practices

8.5.6.3.7. Techniques

8.5.6.3.8. Who does what and when

8.5.6.3.9. Self-organizing rarely means self-managing

8.5.6.3.10. Intellectual workers, including development professionals, are most effective when they have a say in what work they do and how they do it.

8.5.6.3.11. "[...] study by Nonaka has shown that Japanese companies with a self-organizing characteristic tend to have higher performance records [...]" K. Imai, I.Nonaka, H. Takeuchi

8.5.6.3.12. "Never tell people how to do things. Tell them what to do, and they will surprise you with their ingenuity." General George S. Patton

8.5.6.4. Self-aware (personalities/people)

8.5.6.4.1. Teams strive to identify what works well for them, what doesn’t, and then learn and adjust accordingly.

8.5.6.5. Self-sufficient

8.5.6.5.1. Having all the skills needed within the team to deliver and test products.

8.5.6.6. No hierarchy within the team

8.5.6.6.1. No bosses or managers.

8.5.6.7. Cross-functional

8.5.6.7.1. Without demarcation by role e.g. analyst, developer, tester, everybody is expected to perform any type of work needed to get the job done.

8.5.6.8. Small (7 +/- 2)

8.5.6.8.1. AgilePM® suggests that the optimum SDT size is 7 +/- 2 people - at this level, the team can communicate with one another with the minimum of formality, minimum of management overhead..

8.5.6.8.2. see George A. Miller: "The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information"

8.5.6.9. Autonomical

8.5.6.9.1. Yet SDTs do not work in a vacuum.

8.5.6.9.2. Autonomy is the degree to which the execution of task offers freedom, independence and discretion in the scheduling of work and determination of how it is to be completed.

8.5.6.9.3. External Autonomy

8.5.6.9.4. Internal Autonomy

8.5.6.9.5. Individual Autonomy

8.5.6.10. Accountable

8.5.6.10.1. SDTs are accountable for fulfilling the goal(s) they have taken on.

8.5.6.11. Collaborative

8.5.6.11.1. Download: 17 Indisputable Laws of Teamwork by John Maxwell

8.5.6.11.2. Improved collaboration between peole correspondingly increases the opportunities for people to learn from one another.

8.5.6.12. Based on trust and respect

8.5.6.12.1. Trust but verify and then guide

8.5.6.13. Ideally static

8.5.6.13.1. Most successful with long-term, full-time membership.

8.5.6.13.2. Subject to re-structuring if team is not working.

8.5.6.14. Ideally collocated

8.5.6.14.1. Most successful when located in one team room (particularly for the first few Timeboxes).

8.5.6.14.2. Collocated mentally not only phisically.

8.5.6.14.3. "Ensure your documentation is short and sharp and make much more use of people-to-people communication." Bentley & Borman, 2001

8.5.6.15. Skillful (craft)

8.5.6.16. Focused

8.5.6.16.1. Based on Apple company example:

8.5.6.16.2. F - Fewer tasks, rather than many (cancelled 300+ projects/products – 40 to 4)

8.5.6.16.3. O - Organized staff (staff work on what they are the best)

8.5.6.16.4. C - Competitive mind set (competing through better products, services and customer experience)

8.5.6.16.5. U - Urgency (Biannual Apple Worldwide Developers Conf.)

8.5.6.16.6. S - Strategic alignment (All Apple products are aligned with Job’s vision)

8.5.6.16.7. E - Excellence (Products developed through endless iterations)

8.5.6.16.8. D - Discipline (Jobs imposed rigor, discipline and new rules)

8.5.6.17. Team means:

8.5.6.17.1. T - Together

8.5.6.17.2. E - Everyone

8.5.6.17.3. A - Achieves

8.5.6.17.4. M - More

8.5.7. Solution Development Team are similar to Development Team in Scrum but with more defined responsibilities

8.5.7.1. Agile Project Management and Scrum V2 pocketbook

8.5.7.1.1. ISBN-13: 978-0992872793

8.5.7.1.2. Pages: 62

8.5.7.1.3. http://dsdm.org/product/agile-project-management-and-scrum

8.5.8. Team Leader (TL)

8.5.8.1. The agile community has focused on project or team leadership over team management.

8.5.8.2. Leadership rather than management.

8.5.8.3. Person holding it will ideally be elected by his or her peers as the best person to lead.

8.5.8.4. Reporting to the Project Manager (PM).

8.5.8.5. Ensures that a SDT functions as a whole and meets its objectives.

8.5.8.6. Works with the team to plan and co-ordinate all aspects of product delivery at the detailed level.

8.5.8.7. A good team lead is sensitive to personalities (introvert vs extrovert) and encourages team members to be more extroverted and to communicate proactively in a non-judgmental environment.

8.5.8.7.1. e.g. Some technical people are introverted and not comfortable with proactively collaborating and communicating.

8.5.8.8. Mappings to other roles in other methods ...

8.5.8.8.1. PRINCE2®

8.5.9. Business Ambasador (BAMB)

8.5.9.1. similar to Product Owner in Scrum

8.5.9.2. similar to Customer in XP

8.5.9.3. Key business representative within Solution Development Team

8.5.9.3.1. A true “ambassador”.

8.5.9.4. Business role within the SDT.

8.5.9.5. Working closely with the rest of the SDT.

8.5.9.6. Responsible for the day-to-day communication between the project and the business.

8.5.9.7. Guides the evolution of the solution.

8.5.9.8. Generally comes from the business area being addressed.

8.5.9.9. Provides business-related information from the perspective of those who will ultimately make direct use of the solution.

8.5.9.10. Provides the business perspective for all decisions related to the way the solution's fitness for business purpose is defined and implemented.

8.5.9.11. Empowered to make immediate decisions for a wide range of business stakeholders.

8.5.9.11.1. The empowerment issue can be tough for organizations used to a command-and-control management strateg

8.5.9.12. Stress key nature of this role.

8.5.9.13. These are typically very busy people who the business struggle to spare.

8.5.9.13.1. Can quickly become a bottleneck for the team.

8.5.9.14. During Foundations

8.5.9.14.1. Provides significant input into creation and prioritisation of requirements

8.5.9.15. During Evolutionary Development

8.5.9.15.1. Provides day-to-day detail

8.5.9.15.2. Main decision-maker to ensure Evolving Solution is fit-for-purpose to meet business need

8.5.9.16. Responsibilities

8.5.9.16.1. Contributing to all requirements, design and review sessions

8.5.9.16.2. Providing the business perspective for all day-to-day project decisions

8.5.9.16.3. Providing the detail of business scenarios to help define and test the solution being developed

8.5.9.16.4. Communicating with other users, involving them as needed and getting their agreement

8.5.9.16.5. Providing day-to-day assurance that the solution is evolving correctly

8.5.9.16.6. Organising and controlling business acceptance testing of the solution

8.5.9.16.7. Developing business user documentation for the ultimate solution

8.5.9.16.8. Ensuring user training is adequately carried out

8.5.9.16.9. Attending the daily team meetings

8.5.10. Business Analyst (BA)

8.5.10.1. Fully integrated with SDT.

8.5.10.1.1. Not an intermediary between Business Ambassador (BAMB) and team

8.5.10.1.2. Supports communication between the business and the SDT

8.5.10.2. Facilitates relationship between business and technical roles

8.5.10.3. Ensures accurate and decisive direction is provided to the SDT on a day-to-day basis.

8.5.10.4. Ensures accurate, appropriate day-to-day decisions about the Evolving Solution

8.5.10.5. Ensures that the business needs are properly analysed and are correctly reflected in the guidance the team.

8.5.10.6. They do not “own” the requirements (it is important that “ownership” is accepted by the business representatives).

8.5.10.7. Responsibilities

8.5.10.7.1. Assisting the Business Visionary (BV) in the formulation and promotion of the Business Vision

8.5.10.7.2. Modelling the organisation’s current and future state in the area of the solution and identifying opportunities, risks and impacts

8.5.10.7.3. Working with the Business Visionary (BV) and the Business Ambassador (BAMB) to formulate and communicate solution options

8.5.10.7.4. Working with the Project-Team roles in formulating the Business Case, and organising Benefits Assessments

8.5.10.7.5. Supporting and facilitating unambiguous and timely communication between business and technical participants in the project

8.5.10.7.6. Ensuring the requirements are of good quality and are analysed and managed appropriately

8.5.10.7.7. Ensuring that the business and organisational implications of day-to-day evolution of the solution are properly modelled and thought through

8.5.10.7.8. Ensuring the impact of business decisions is reviewed in the context of the project

8.5.10.7.9. Ensuring the business and technical components of the solution collectively provide a cohesive whole for the business

8.5.10.7.10. Liaising with the Business Visionary in organising support for the solution through implementation into live use

8.5.10.7.11. Managing development, distribution and baseline approval of all documentation and products related to business requirements and their interpretation

8.5.10.8. The Business Analyst is intentionally positioned as part of the project level as well as part of the Solution Development Team.

8.5.10.8.1. This allows the Business Analyst to, for example, help the business to formulate the Business Case, and also to be involved in assisting the business in defining their requirements during feasibility and foundations, sometimes before the full Solution Development Team. is assigned.

8.5.10.9. see AgileBA® mind map

8.5.11. Solution Developer (SD)

8.5.11.1. Interprets business requirements and translates them into a deployable solution that meets functional and non-functional needs.

8.5.11.2. Should ideally be allocated full time to the project.

8.5.11.3. Where they are not full time, the project ought to be their first priority - if this cannot be achieved, significant risk is introduced with regard to timeboxing.

8.5.11.4. AgilePM® states that ideally we are looking for true Analyst and Developer in one person.

8.5.11.4.1. Soft skills cannot be underestimated - especially communication, negotiation, selling, listening etc.

8.5.11.5. Responsibilities

8.5.11.5.1. Works collaboratively with Business Ambassador and other Solution Developers and Testers

8.5.11.5.2. Undertakes Iterative Development of the deployable solution

8.5.11.5.3. Adheres to technical constraints laid out in the Solution Foundations

8.5.11.5.4. Participates in quality assurance work to ensure products are fit for purpose

8.5.11.5.5. Tests their own output prior to independent testing

8.5.12. Solution Tester (ST)

8.5.12.1. Fully integrated with the SDT.

8.5.12.2. Performs testing in accordance with the Technical Testing Strategy.

8.5.12.3. Ensure quality solution.

8.5.12.4. Independence of testing is key.

8.5.12.5. Typically the Solution Tester (ST) reports to the Technical Coordinator (TC) in terms of test results and quality. rather than to the Team Leader (TL).

8.5.12.6. Responsibilities

8.5.12.6.1. Works collaboratively with Business Ambassador (BAMB), Solution Developers (SD) and other Solution Testers (ST)

8.5.12.6.2. Carrying out all types of technical testing of the solution as a whole

8.5.12.6.3. Creating testing products, e.g. test cases, plans and logs

8.5.12.6.4. Reporting the results of testing activities to the Technical Coordinator (TC) for Quality Assurance purposes

8.5.12.6.5. Keeping the Team Leader (TL) informed of the results of testing activities

8.5.12.6.6. Assisting the Business Ambassador(s) (BAMB) and Business Advisor(s) (BADV) to ensure that they can plan and carry out their tests well enough to ensure that the important areas are covered

8.5.12.7. Mappings to other roles in other methods ...

8.5.12.7.1. eXtreme Programming (XP)

8.5.12.7.2. Disciplined Agile Delivery (DAD)

8.6. Supporting Roles

8.6.1. The Supporting roles are

8.6.1.1. Business Advisors (BADV), Technical Advisors (TADV), Workshop Facilitator (WF) and DSDM Coach (DC) provide assistance and guidance to the project on a more ad hoc basis throughout the lifecycle.

8.6.1.1.1. The Advisor roles may be filled by one or more subject matter experts.

8.6.1.2. The project may bring in subject matter experts as necessary for their specialist expertise.

8.6.2. Business Advisor (BADV)

8.6.2.1. Often a peer of the Business Ambassador (BAMB).

8.6.2.2. Called upon to provide specific, and often, specialist input to solution development or solution testing.

8.6.2.3. Often user or beneficiary of the solution.

8.6.2.3.1. A potential user of a solution under development.

8.6.2.4. May, for example, simply provide legal or regulatory advice with which the solution must comply.

8.6.2.4.1. Expert knowledge of some aspect of legislation of business rules with which the solution must comply.

8.6.2.5. Working within boundaries of the business vision defined by the Business Visionary (BV), Business Advisors (BADVs) are responsible for helping the Business Ambassador shape the requirements in the PRL, providing depth and detail of the business need and expected characteristics of the solution under development.

8.6.2.6. Responsibilities

8.6.2.6.1. Providing specialist advice on, or help with:

8.6.2.6.2. Providing specialist input into relevant:

8.6.2.7. Mappings to other roles in other methods ...

8.6.2.7.1. Disciplined Agile Delivery (DAD)

8.6.3. Technical Advisor (TADV)

8.6.3.1. Technical equivalent of a Business Advisor (BADV).

8.6.3.2. Supports SDT.

8.6.3.3. Provides specific and often specialist technical input and advice.

8.6.3.4. Working within boundaries of the technical vision definecd by the Technical Coordinator (TC), Tecnhical Advisors (TADVs) are responsible for helping the Business Ambassador (BAMB) shape the requirements in the PRL, providing depth and detail of the technical characteristics of the solution under development.

8.6.3.5. could be in real life for example ...

8.6.3.5.1. IT Security Expert

8.6.3.5.2. IT Security Consultatant

8.6.3.5.3. Business Continuity Expert

8.6.3.5.4. Risk Manager (from organization)

8.6.3.5.5. Support

8.6.3.6. Responsibilities

8.6.3.6.1. Providing specialist advice on, or help with:

8.6.3.7. Mappings to other roles in other methods ...

8.6.3.7.1. Disciplined Agile Delivery (DAD)

8.6.4. Workshop Facilitator (WF)

8.6.4.1. "A facilitator is someone who uses some level of intuitive or explicit knowledge of group process to formulate and deliver some form of formal or informal process design and interventions at a shallow or deep level to help a group achieve what they want or need to do or get where hey want or need to go" (Ned Ruete, International Association of Facilitators (IAF))

8.6.4.2. Independent from project team and client.

8.6.4.2.1. Independent of workshop outcome.

8.6.4.3. Managing the workshop process.

8.6.4.4. Responsible for the context of the workshop, not the content.

8.6.4.5. Catalyst for preparation and communication.

8.6.4.6. Responsibilities

8.6.4.6.1. For each workshop:

8.6.4.6.2. Engaging with participants to:

8.6.4.7. Download: What Do We Mean By Facilitation

8.6.5. DSDM Coach (DC)

8.6.5.1. Key to helping a team with limited experience of using AgilePM® to get the most out of the approach within the context of the wider organisation in which they work.

8.6.5.2. Should ideally be independently to ensure competence to fulfil this role.

8.6.5.3. For teams new to agile, it often makes sense to have a part-time experienced coach working with the team for a few iterations for more.

8.6.5.4. In Scrum, this role is part of the Scrum Master role.

8.6.5.5. Responsibilities

8.6.5.5.1. Providing detailed knowledge and experience of DSDM® / AgilePM® to inexperienced agile teams

8.6.5.5.2. Tailoring the DSDM® / AgilePM® process to suit the individual needs of the project and the environment in which the project is operating

8.6.5.5.3. Helping the team use DSDM® / AgilePM® techniques and practices and helping those outside the team appreciate the DSDM® philosophy and value set

8.6.5.5.4. Helping the team work in the collaborative and cooperative way demanded by DSDM® / AgilePM® and all agile approaches

8.6.5.5.5. Building DSDM® / AgilePM® capability within the team

8.6.6. Specialist roles (not shown on original diagram; were present in previous version of AgilePM - v1.0 up to v1.2)

8.6.6.1. The SDT roles will not always cover every skill needed in a project.

8.6.6.2. Specialist roles may also need to be involved and brought into the AgilePM® project (not only Solution Development Team) on an ad-hoc basis by the PM or TL to fulfil specific functions.

8.6.6.2.1. The required roles will depend on the size and nature of the project.

8.6.6.3. Project level

8.6.6.3.1. Possible to have Specialist roles at the Project level.

8.6.6.3.2. Is less likely to be ad-hoc and would more commonly be throughout the project.

8.6.6.3.3. Common example of a Project level specialist role would be an Operations Coordinator.

8.6.6.4. Solution Development Team (SDT) level

8.6.6.4.1. Need to be properly integrated into the project team as appropriate.

8.6.6.4.2. Required specialist input to the SDT should be formally planned.

8.6.6.4.3. Individuals identified and their availability checked so that they can attend relevant meetings, facilitated workshops, etc

8.6.6.5. e.g.

8.6.6.5.1. Business Architect

8.6.6.5.2. Business Consultant

8.6.6.5.3. Business Modeller

8.6.6.5.4. Business Process Coordinator

8.6.6.5.5. Capacity / Performance Planner

8.6.6.5.6. Compliance Specialist

8.6.6.5.7. Configuration Manager

8.6.6.5.8. Data Architect

8.6.6.5.9. Human Factors Specialist

8.6.6.5.10. Infrastructure Provider

8.6.6.5.11. Metrics Manager

8.6.6.5.12. Operations Coordinator

8.6.6.5.13. Quality Manager

8.6.6.5.14. Reuse Assessor

8.6.6.5.15. Service / Help Desk Manager

8.6.6.5.16. Support and Maintenance team representatives

8.6.6.5.17. Systems Integrator

8.6.6.5.18. Technical Consultants

8.6.6.5.19. Testing Manager

8.7. Summary & Conclusion

8.7.1. AgilePM® identifies roles in 3 categories:

8.7.1.1. Project-level

8.7.1.2. Solution Development

8.7.1.3. Supporting / Other

8.7.2. The business interests are represented by

8.7.2.1. Business Sponsor (BS)

8.7.2.2. Business Visionary (BV)

8.7.2.3. Business Ambassador (BAMB)

8.7.2.4. Business Advisor (BADV)

8.7.3. The solution / technical interests are represented by

8.7.3.1. Technical Coordinator (TC)

8.7.3.2. Solution Developer (SD)

8.7.3.3. Solution Tester (ST)

8.7.3.4. Technical Advisor (TADV)

8.7.4. Management interests are represented

8.7.4.1. Project Manager (PM)

8.7.4.2. Team Leader (TL)

8.7.4.3. Business Analyst (BA)

8.7.5. Supporting interests are represented

8.7.5.1. DSDM Coach (DC)

8.7.5.2. Workshop Facilitator (WF)

8.7.6. One role may be taken by several people

8.7.7. One person may take several roles

9. AgilePM® V2 Products (a.k.a. Artifacts) (for simplicity documentation) (14)

9.1. Introduction

9.1.1. AgilePM® identifies deliverables associated with each phase of the project lifecycle.

9.1.1.1. These are referred to as Products.

9.1.1.1.1. Could be documentation (Word, Excel), could be model (software for PPM) etc.

9.1.2. Not all products are required for every project.

9.1.2.1. Enables the product set for a particular project to be kept to a minimum.

9.1.3. Product represent an information (not files)

9.1.3.1. Product is not one to one equivalent of separate Word, Excel or any other file

9.1.4. Formality associated with each product will vary from project to project and from organisation to organisation.

9.1.4.1. a.k.a. 'Adopt and Adapt'

9.1.5. Some products are specific to a particular phase in the lifecycle, others may continue to evolve through subsequent phases. (see diagram)

9.1.6. The level of documentation required depends on the ease of communication of team members

9.1.6.1. Colocated Agile teams need less detail when writing down User Stories than distributed teams

9.1.7. Formal products definitions specifies:

9.1.7.1. When the product is produced, used, updated and archived. This gives a clear view of the transience of a given product and therefore enables appropriate levels of quality control to be applied.

9.1.7.2. The roles that could be responsible for producing, contributing to, accepting and approving the product.

9.1.7.2.1. These are only suggestions but give an indication of what product responsibilities could be allocated to the people in each role.

9.1.7.3. The product's Quality Criteria, i.e. the set of questions that should be answered positively if the product has fulfilled its purpose satisfactorily.

9.1.8. Documentation in an Agile project should be sufficient for purpose, and only that. The two golden rules of Agile documentation are

9.1.8.1. Do not document unless it is useful to someone specific (a 50 page document that no-one actually reads is not proving useful to anyone)

9.1.8.2. Document in a way that is useful to the recipient (ask how this will be used, and by whom)

9.2. For people coming from corporate environment these products are already used in most of their projects.

9.2.1. Products can have different names but information provided by these products are similar to those which are already used and maintained by corporate governance systems or Qualiy Assuarence (QA) systems internally developed project management method)

9.3. For people coming from non corporate environment these products may be a bit overwhelming (e.g. small projects combining only several people).

9.3.1. Remember - product is just a set a information, how you store (physically) and update this information is up to you

9.3.2. Products information can be stored in a classic Word, Excel, Powerpoint style, as a model built in PPM software or even with no storage at all - it is up to you and your organisation how AgilePM will be tailored.

9.4. "Ensure your documentation is short and sharp and make much more use of people-to-people communication." Bentley & Borman, 2001

9.5. Legend

9.5.1. Icon

9.5.1.1. This means that selected products are Gateway Products, which can be used for Yes / No decision if project should be continued

9.5.2. Orange

9.5.2.1. Business focused products

9.5.3. Blue

9.5.3.1. Management focused products

9.5.4. Green

9.5.4.1. Solution focused products

9.5.5. Evolutionary products

9.5.5.1. They typically, but not always, span a number of project phases and may be baselined more than once during that time.

9.5.6. Milestone products

9.5.6.1. Typically fulfil a specific purpose within that phase as a checkpoint or to facilitate governance processes

9.6. Pre-Project phase

9.6.1. Terms of Reference (ToR)

9.6.1.1. In real life corporate environments this product is often called Project Kick-off

9.6.1.2. Defines at a very high level the objectives and business drivers for the proposed project.

9.6.1.2.1. high-level definition of the over-arching business driver for, and top-level objectives of, the project.

9.6.1.2.2. Outlines the rationale for the project (e.g., business drivers)

9.6.1.3. The primary aim of the Terms of Reference is to scope and justify the Feasibility phase.

9.6.1.3.1. Not the whole project.

9.6.1.4. Very short document (one or two pages).

9.6.1.4.1. Can be less formal - email, verbal agreement.

9.6.1.5. Recommeded content

9.6.1.5.1. A brief outline of the business need and the objectives and scope for the project to meet that need.

9.6.1.6. Recommeded responsibilities

9.6.1.6.1. Produced by

9.6.1.6.2. Approved by

9.6.1.6.3. Produced for

9.7. Feasibility phase

9.7.1. Business Case

9.7.1.1. Describes essential business considerations that justify the project, and then are used to assess the viability of the project moving forwards.

9.7.1.2. Contains the business vision and justification for the project and requires revalidation throughout the project.

9.7.1.2.1. The business vision describes a changed business as it is expected to be, incrementally and at the end of the project.

9.7.1.3. Ought to quantify the costs and value of a project.

9.7.1.3.1. Explain how this value is delivered on an incremental basis and how this is likely to impact existing business processes and organisation.

9.7.1.4. Likely to describe constraints, assumptions, dependencies and risks.

9.7.1.5. Baselines of the Business Case are typically created first as an outline by the end of Feasibility.

9.7.1.5.1. Then as a basis for approval of development by the end of Foundations.

9.7.1.5.2. It is formally reviewed at the end of each Project Increment in order to determine whether further work is justified.

9.7.1.6. Recommeded responsibilities

9.7.1.6.1. Produced by

9.7.1.6.2. Approved by

9.7.1.6.3. Produced for

9.7.2. Prioritised Requirements List (PRL)

9.7.2.1. Describes, at a high level, the requirements that the project needs to address if the Business Case is to be met

9.7.2.1.1. Prioritized backlog of all requirements as derived during Feasibility and Foundations.

9.7.2.2. Baselined at a high level at the end of the Foundations phase

9.7.2.2.1. Consideration of requirements begins in Feasibility and a baseline of the PRL demarcates the scope of the project as at the end of Foundations.

9.7.2.2.2. Change to the breadth (adding, removing or significantly changing high-level requirements) needs to be formally controlled in order to ensure ongoing alignment with the business vision for the project and to keep control of the scope.

9.7.2.2.3. Refined for detail as the project proceeds through project reflecting changes to depth and detail drawn out by the Iterative Development process.

9.7.2.3. PRL is Progressively Refined.

9.7.2.4. There is one PRL for project but each Increment or Timebox can haw it's own PRL (a.k.a. Sprint Backlog from Scrum).

9.7.2.5. Requirements formulated during Feasibility have the character of epics (i.e., outcome based high-level statements that clarify scope).

9.7.2.6. During the Foundations phase the first key non-functionals make their appearance.

9.7.2.7. PRL contains both:

9.7.2.7.1. Functional Requirements (FR)

9.7.2.7.2. Non-Functional Requirements (NFR)

9.7.2.7.3. any related job to be done

9.7.2.8. Recommeded content

9.7.2.8.1. A list of high-level requirements to be addressed.

9.7.2.8.2. A business driven prioritisation of the requirements in accordance with the MoSCoW prioritisation process.

9.7.2.9. Recommeded responsibilities

9.7.2.9.1. Produced by

9.7.2.9.2. Approved by

9.7.2.9.3. Produced for

9.7.3. Solution Architecture Definition (SAD)

9.7.3.1. Provides an overview and architectural framework for both business and technical aspects of the potential solution. This will evolve as the project proceeds.

9.7.3.1.1. High-level solution design from both business and technical viewpoints.

9.7.3.1.2. Primary purpose to establish the scope for evolutionary development including desired maintainability levels.

9.7.3.2. The Solution Architecture Definition (SAD) should be created for any project where there is a systems aspect to the solution.

9.7.3.3. Defines the technical framework within which the solution will be developed and provides a high-level description of the architecture of that solution.

9.7.3.4. Recommeded responsibilities

9.7.3.4.1. Produced by

9.7.3.4.2. Approved by

9.7.3.4.3. Produced for

9.7.4. Delivery Plan

9.7.4.1. a.k.a. Release Plan

9.7.4.2. Provides an initial high-level schedule of Increments and Timeboxes and other activities for development, testing and deployment of the solution.

9.7.4.2.1. For larger projects a single high-level Delivery Plan will deal with coordination of the efforts of multiple SDT teams.

9.7.4.2.2. On smaller simpler projects the Delivery/Release Plan may be integrated with the PRL with User Stories identified as belonging to a particular planned release.

9.7.4.3. This plan is constantly reviewed and revised as the project progresses to reflect the latest business demands and predicted outcomes in terms of timescales and delivered scope

9.7.4.4. The Delivery Plan refines and elaborates on the schedule.

9.7.4.5. Consists of 1 components

9.7.4.5.1. Schedule of Timeboxes

9.7.4.6. Recommeded content

9.7.4.6.1. The incremental nature of the project

9.7.4.6.2. The dates associated with the increments and other key milestones.

9.7.4.6.3. The dates for deployment of the solution and, where applicable, subsets of it

9.7.4.6.4. An indication of the focus of each Development Timebox

9.7.4.6.5. The timing and dependencies of any activities not planned within the Development Timeboxes

9.7.4.6.6. The allocation of resources to timeboxes and other activities

9.7.4.6.7. An identification of the contingency associated with one or more of the key constraints of time, resource/cost or, preferably, scope

9.7.4.7. Recommeded responsibilities

9.7.4.7.1. Produced by

9.7.4.7.2. Approved by

9.7.4.7.3. Produced for

9.7.5. Management Approach Definition (MAD)

9.7.5.1. The Management Approach Definition (MAD) product describes essential governance and organisational aspects of the project and describes precisely how the project will be managed.

9.7.5.1.1. It also describes how the DSDM® practices and techniques will be applied to ensure management of the project through to a successful conclusion.

9.7.5.1.2. Organisational and planning aspects of the project as well as the engagement of stakeholders.

9.7.5.1.3. It reflects the approach to the management of the project as a whole and considers, from a management perspective, how the project will be organised and planned, how stakeholders will be engaged in the project and how progress will be demonstrated and, if necessary, reported.

9.7.5.2. Note: it is important that the Project Approach Questionnaire (PAQ) responses created in Feasibility are reviewed at this point and that any changes to responses are considered when defining how the project will be managed from here on.

9.7.5.3. Describes the approach to the set-up and management of various aspects of the project, including how the project will be organised and governed.

9.7.5.3.1. It also describes the approach to managing Change, Configuration, Communication and Risk.

9.7.5.4. Management Approach Definition (MAD) is outlined in Feasibility and baselined at the end of Foundations and will only evolve beyond that when circumstances change or if review of the approach identifies areas for improvement.

9.7.5.5. Recommeded content

9.7.5.5.1. A validation of the Objectives and Success Criteria for the project

9.7.5.5.2. The project approach - based on analysis of the latest responses to the Project Approach Questionnaire (PAQ) and also including the processes required for governance and, where applicable, contact management

9.7.5.5.3. The project organisation, including roles and responsibilities, empowerment of teams and reporting lines and governance

9.7.5.5.4. Project Management controls for Monitoring and Reporting, Change Control and Risk Management

9.7.5.5.5. An overview of the key deliverables, milestones and incremental staging of product delivery

9.7.5.5.6. An analysis of major project dependencies

9.7.5.6. Recommeded responsibilities

9.7.5.6.1. Produced by

9.7.5.6.2. Approved by

9.7.5.6.3. Produced for

9.7.6. Feasibility Assessment

9.7.6.1. The Feasibility Assessment provides a snapshot of the evolving business, solution and management products described above as they exist at the end of the Feasibility phase.

9.7.6.2. Where created, each of the products should be mature enough to make a sensible contribution to the decision as to whether the project is likely to be feasible or not.

9.7.6.3. The Feasibility Assessment may be expressed as a baselined collection of the products described or as an executive summary covering the key aspects of each of them.

9.7.6.4. Assessing the feasibility of the project both from a business and a technical perspective.

9.7.6.5. Addresses main risks, by providing a description and a mitigation strategy for any risks significant enough to influence the viability of the project.

9.7.6.6. Recommeded content

9.7.6.6.1. The business vision of success.

9.7.6.6.2. The scope and objectives of the proposed project.

9.7.6.6.3. High-level assumptions, dependencies and risk that may impact project viability.

9.7.6.6.4. Any alternatives that were considered and rejected.

9.7.6.6.5. The major deliverables of the proposed project.

9.7.6.6.6. A high-level description of a solution to support the Business Case.

9.7.6.6.7. An initial identification of any technical constraints to which the solution must adhere.

9.7.6.6.8. (optional) A disposable 'candidate' of the solution (or key elements of it), demonstrating how it will eventually work and / or demonstrating the technical feasibility of its more risky or complex elements.

9.7.6.7. Recommeded responsibilities

9.7.6.7.1. Produced by

9.7.6.7.2. Approved by

9.7.6.7.3. Produced for

9.8. Foundations phase

9.8.1. Foundations Summary

9.8.1.1. The Foundations Summary provides a snapshot of the evolving business, solution and management products described above as they exist at the end of the Foundations phase.

9.8.1.2. Where created, each of the products should be mature enough to make a sensible contribution to the decision as to whether the project is likely to deliver the required return on investment.

9.8.1.3. The Foundations Summary may be expressed as a baselined collection of the products described or as an executive summary covering the key aspects of each of them.

9.8.1.4. Recommeded responsibilities

9.8.1.4.1. Produced by

9.8.1.4.2. Approved by

9.8.1.4.3. Produced for

9.9. Evolutionary Development

9.9.1. Evolving Solution

9.9.1.1. The Evolving Solution is made up of all appropriate components of the final solution together with any intermediate deliverables necessary to explore the detail of requirements and the solution under construction.

9.9.1.1.1. Not only of the solution (be it partial or complete) but also the supporting artefacts produced during its creation (e.g., models, prototypes, tests, reviews).

9.9.1.2. At any given time, such components may be either complete, a baseline of a partial solution, or a work in progress.

9.9.1.2.1. They include, where valuable: models, prototypes, supporting materials and testing and review artefacts.

9.9.1.3. The precise nature and composition of the Evolving Solution is entirely dependent on the objectives of the project and the current position in the project timeline.

9.9.1.3.1. At one extreme, at the beginning of a project it could be a preliminary sketch of a new business process on a flip chart.

9.9.1.3.2. Towards the end of a project it may be a fully evolved and documented business process supported by a software application and all documentation to use, support and maintain it. It is simply a convenient term to describe a 'work in progress'.

9.9.1.4. At the end of each Project Increment the Solution Increment is deployed into live use and becomes the Deployed Solution.

9.9.1.5. Recommeded responsibilities

9.9.1.5.1. Produced by

9.9.1.5.2. Approved by

9.9.1.5.3. Produced for

9.9.2. Timebox Plan

9.9.2.1. The Timebox Plan elaborates on the objectives provided for each Development Timebox in the Delivery Plan.

9.9.2.1.1. Plan elaborates in greater detail those elements of the Prioritized Requirements List (PRL) as defined by the schedule found in the Delivery Plan that are to be tackled during the Timebox.

9.9.2.2. Recommeded content

9.9.2.2.1. A definition of the product(s) of an individual Development Timebox

9.9.2.2.2. An identification of key milestones, e.g. technical or user review dates, within a timebox

9.9.2.2.3. An agreed MoSCoW prioritisation of products and activities within a Development Timebox

9.9.2.2.4. An identification of all the resources (human and otherwise) required for successful completion of all work

9.9.2.3. Recommeded responsibilities

9.9.2.3.1. Produced by

9.9.2.3.2. Approved by

9.9.2.3.3. Produced for

9.9.3. Timebox Review Record

9.9.3.1. The formality of this record will vary from official, signed documents to informal notes or emails depending on the project and the organisation.

9.9.3.1.1. However the information encompassed by the Timebox Review Record should always exist in some physical form.

9.9.3.2. The Timebox Review Record is produced / updated at the review points in the Development Timebox.

9.9.3.2.1. They describe what has been achieved and any feedback which may influence plans moving forwards.

9.9.3.2.2. After the timebox has completed any outstanding issues are considered in the context of the Delivery Plan and future Timebox Plans.

9.9.3.3. This is a running review of what has been achieved, feedback, outstanding issues and key decisions and could be constructed to be used for auditing purposes if necessary.

9.9.3.4. Recommeded content

9.9.3.4.1. A record of the success of delivery, against the Timebox Plan, specifically describing what has been delivered and what has not.

9.9.3.4.2. A record of the formal acceptance of the completed deliverables by the business representatives identified to accept them.

9.9.3.4.3. An assessment of the priority of any work not completed and a plan to show whether and when it will be, either as part of the current timebox or at some point in the future.

9.9.3.4.4. An assessment of the effectiveness of the timebox control processes and the Iterative Development techniques in line with the principles of Atern.

9.9.3.5. Recommeded responsibilities

9.9.3.5.1. Produced by

9.9.3.5.2. Approved by

9.9.3.5.3. Produced for

9.10. Deployment phase

9.10.1. Project Review Report

9.10.1.1. Consists of 3 components

9.10.1.1.1. End of Project Assessment

9.10.1.1.2. Benefits Enablement Summary (one or more)

9.10.1.1.3. Increment Review (one or more)

9.10.1.2. Recommeded responsibilities

9.10.1.2.1. Produced by

9.10.1.2.2. Approved by

9.10.1.2.3. Produced for

9.11. Post Project phase

9.11.1. Benefits Assessment

9.11.1.1. The Benefits Assessment describes how the benefits have actually accrued, as the Deployed Solution has been used.

9.11.1.1.1. For projects where benefits in the Business Case are expected to accrue over a prolonged period, it is likely that Benefits Assessments will be produced on a periodic basis.

9.11.1.2. Recommeded content

9.11.1.2.1. A quantitative description of how the benefits of using the Deployed Solution have been achieved.

9.11.1.2.2. An analysis of any discrepancies between what has been achieved and what was predicted in the Business Case for the project.

9.11.1.3. Recommeded responsibilities

9.11.1.3.1. Produced by

9.11.1.3.2. Approved by

9.11.1.3.3. Produced for

9.12. Summary & Conclusion

9.12.1. AgilePM® is a product-based approach

9.12.1.1. This is a more effective way than simple reports, that's way AgilePM® doesn't have massive number of reports.

9.12.2. Projects use delivery of the appropriate products to demonstrate progress.

9.13. Historically AgilePM®v1.0 had 17 products (a.k.a. Artifacts) (17 main / 53 all)

9.13.1. Pre-Project phase

9.13.1.1. Terms of Reference (ToR)

9.13.1.1.1. In real life corporate environments this product is often called Project Kick-off

9.13.1.1.2. High-level definition of the business driver.

9.13.1.1.3. Scope and justification of Feasibility phase.

9.13.1.1.4. Very short document (two sides maximum).

9.13.1.1.5. Recommeded content

9.13.1.1.6. Recommeded responsibilities

9.13.2. Feasibility phase

9.13.2.1. Feasibility Assessment

9.13.2.1.1. High-level overview of the project.

9.13.2.1.2. Assessing the feasibility of the project both from a business and a technical perspective.

9.13.2.1.3. Addresses main risks, by providing a description and a mitigation strategy for any risks significant enough to influence the viability of the project.

9.13.2.1.4. Consists of 4 components

9.13.2.1.5. Recommeded content

9.13.2.1.6. Recommeded responsibilities

9.13.2.2. Outline Plan

9.13.2.2.1. Overview of the project from a Project Management and Solution Delivery perspective.

9.13.2.2.2. Analyses the responses to the incorporated Project Approach Questionnaire (PAQ)

9.13.2.2.3. Povides a detailed plan for the work of the Foundations phase.

9.13.2.2.4. Consists of 2 components

9.13.2.2.5. Recommeded content

9.13.2.2.6. Recommeded responsibilities

9.13.3. Foundations phase

9.13.3.1. Business Foundations

9.13.3.1.1. Evolution of the Business Vision from the Feasibility Assessment

9.13.3.1.2. Provides information for and / or about the business that is fundamental to the success of the project and that

9.13.3.1.3. Needs to be understood by all project stakeholders before development of the solution commences.

9.13.3.1.4. Consists of 2 components

9.13.3.1.5. Recommeded content

9.13.3.1.6. Recommeded responsibilities

9.13.3.2. Prioritised Requirements List (PRL)

9.13.3.2.1. Describes, at a high level, the requirements that the project needs to address if the Business Case is to be met

9.13.3.2.2. Baselined at a high level at the end of the Foundations phase

9.13.3.2.3. There is one PRL for project but each Increment or Timebox can haw it's own PRL (a.k.a. Sprint Backlog from Scrum).

9.13.3.2.4. PRL is Progressively Refined.

9.13.3.2.5. Requirements formulated during Feasibility have the character of epics (i.e., outcome based high-level statements that clarify scope).

9.13.3.2.6. During the Foundations phase the first key non-functionals make their appearance.

9.13.3.2.7. PRL contains both:

9.13.3.2.8. Consists of 2 components

9.13.3.2.9. Recommeded content

9.13.3.2.10. Recommeded responsibilities

9.13.3.3. Management Foundations

9.13.3.3.1. Refinement of the Outline Plan from Feasibility

9.13.3.3.2. The Management Foundations product describes essential governance and organisational aspects of the project and describes precisely how the project will be managed.

9.13.3.3.3. Note: it is important that the Project Approach Questionnaire (PAQ) responses created in Feasibility are reviewed at this point and that any changes to responses are considered when defining how the project will be managed from here on.

9.13.3.3.4. Consists of 3 components

9.13.3.3.5. Recommeded content

9.13.3.3.6. Recommeded responsibilities

9.13.3.4. Delivery Plan

9.13.3.4.1. a.k.a. Release Plan

9.13.3.4.2. Provides an initial high-level schedule of Increments and Timeboxes and other activities for development, testing and deployment of the solution.

9.13.3.4.3. This plan is constantly reviewed and revised as the project progresses to reflect the latest business demands and predicted outcomes in terms of timescales and delivered scope

9.13.3.4.4. The Delivery Plan refines and elaborates on the schedule described in the Outline Plan.

9.13.3.4.5. Consists of 2 components

9.13.3.4.6. Recommeded content

9.13.3.4.7. Recommeded responsibilities

9.13.3.5. Delivery Control Pack

9.13.3.5.1. The Delivery Control Pack comprises reports, documents and logs related to the ongoing status of the project.

9.13.3.5.2. Consists of 3 components

9.13.3.5.3. Recommeded responsibilities

9.13.3.6. Solution Foundations

9.13.3.6.1. Provides information for and/or about the solution that is fundamental to the success of the project.

9.13.3.6.2. Need to be understood by all internal project stakeholders before development of the solution commences.

9.13.3.6.3. Consists of 4 components

9.13.3.6.4. Recommeded responsibilities

9.13.4. Exploration and Engineering phases

9.13.4.1. Deployment Plan

9.13.4.1.1. Schedule of activities for the delivery of project products covering all aspects of Composition deployment of the solution from a business and a technical perspective

9.13.4.1.2. Sometimes included as a subset of the Delivery Plan, the Deployment Plan is the detailed plan for the Deployment phase. Unlike the Timebox Plans used during development, the Deployment Plan tends to focus on specific tasks to be performed by specific individuals, rather than on products to be delivered by the Solution Development Team as a whole.

9.13.4.1.3. Generally speaking it is not possible to Timebox a deployment, as time and resource cannot sensibly be fixed in favour of flexible scope.

9.13.4.1.4. Benefits Realisation Plan

9.13.4.1.5. Recommeded content

9.13.4.1.6. Recommeded responsibilities

9.13.4.2. Timebox Plan

9.13.4.2.1. The Timebox Plan elaborates on the objectives provided for each Development Timebox in the Delivery Plan.

9.13.4.2.2. Recommeded content

9.13.4.2.3. Recommeded responsibilities

9.13.4.3. Timebox Review Record

9.13.4.3.1. The formality of this record will vary from official, signed documents to informal notes or emails depending on the project and the organisation.

9.13.4.3.2. The Timebox Review Record is produced / updated at the review points in the Development Timebox.

9.13.4.3.3. This is a running review of what has been achieved, feedback, outstanding issues and key decisions and could be constructed to be used for auditing purposes if necessary.

9.13.4.3.4. Recommeded content

9.13.4.3.5. Recommeded responsibilities

9.13.4.4. Evolving Solution

9.13.4.4.1. The Evolving Solution is made up of all appropriate components of the final solution together with any intermediate deliverables necessary to explore the detail of requirements and the solution under construction.

9.13.4.4.2. At any given time, such components may be either complete, a baseline of a partial solution, or a work in progress.

9.13.4.4.3. The precise nature and composition of the Evolving Solution is entirely dependent on the objectives of the project and the current position in the project timeline.

9.13.4.4.4. Note: the Deployable Solution is a baseline of the Evolving Solution that is ready for deployment.

9.13.4.4.5. Recommeded responsibilities

9.13.4.5. Solution Assurance Pack

9.13.4.5.1. Consists of 3 components

9.13.5. Deployment phase

9.13.5.1. Project Review Report

9.13.5.1.1. Consists of 3 components

9.13.5.1.2. Recommeded responsibilities

9.13.5.2. Deployed Solution

9.13.5.2.1. The Deployed Solution is an instance of a Deployable Solution from the Engineering phase that is now in operation in the live business environment.

9.13.5.2.2. Recommeded content

9.13.5.2.3. Recommeded responsibilities

9.13.6. Post Project phase

9.13.6.1. Benefits Assessment

9.13.6.1.1. The Benefits Assessment describes how the benefits have actually accrued, as the Deployed Solution has been used.

9.13.6.1.2. Recommeded content

9.13.6.1.3. Recommeded responsibilities

9.13.7. Sample project combining work of two Solution Development Teams (SDTs), showing relationships between Products

10. AgilePM® Requirements

10.1. Levels of Agile Requirements

10.2. What is a requirement?

10.2.1. A requirement is a service, feature or function that the user wishes the solution to perform or exhibit.

10.3. Functional Requirements (FR)

10.3.1. May be expressed in terms of a feature that the solution is expected to have.

10.3.1.1. Features can evolve out of requirements.

10.3.2. As the level of detail increases, the requirement begins to describe how something will be achieved.

10.3.3. Functional requirements should be specified at a high level during the Feasibility and Foundations phases of the lifecycle and decomposed into lower-level requirements that are more specific in later phases.

10.3.3.1. This matches with the exploratory nature of the AgilePM® lifecycle.

10.3.4. The gathering of functional and non-functional requirements starts during the Feasibility and Foundations Phases in order to form the Prioritised Requirements List that is agreed by the end of Foundations

10.4. Non-functional requirements (NFR)

10.4.1. Describes how well (to what level) something is to be carried out.

10.4.2. Some will be global and apply across the whole set of requirements; some will be specific to an individual requirement.

10.4.3. May also emerge throughout the lifecycle.

10.4.3.1. Some of the more critical ones may be evident at the outset, when the objective is established.

10.4.3.2. Others should be actively sought alongside the functional requirements when they are captured during facilitated workshops to establish the PRL.

10.4.3.3. More detailed ones may emerge during Exploration and Engineering.

10.4.4. The gathering of functional and non-functional requirements starts during the Feasibility and Foundations Phases in order to form the Prioritised Requirements List that is agreed by the end of Foundations

10.5. Prioritising Requirements and MoSCoW

10.5.1. Fundamental part of the AgilePM® Philosophy, it is important that the essential work is done (the Minimum Usable Subset) and that it is only non-critical (Should Have and Could Have) requirements that are omitted.

10.5.1.1. Understand the Minimum Usable SubseT

10.5.1.2. It is guaranteed

10.5.1.3. Similar to minimum viable product (MVP)

10.5.1.4. Similar to minimum marketable feature set (MMFS)

10.5.2. The key to ensuring this is the clear prioritisation of the requirements using the MoSCoW rules.

10.5.3. The MoSCoW rules provide the basis for decisions about what the project team will do:

10.5.3.1. during a timebox within an increment

10.5.3.2. within an increment of the project

10.5.3.3. over the whole project

10.6. Team empowerment within MoSCoW

10.6.1. New requirements will often emerge as existing requirements are defined in more detail and as the project progresses.

10.6.2. All requirements need to be prioritised using the MoSCoW rules, no matter when in the project they are defined.

10.6.3. he team has the authority to de-scope Should Have or Could Have requirements, by agreement of the team, including Solution Developers and Business Ambassadors. However, the change of priority of a Must Have requirement in the PRL has to be referred to the Business Visionary and, possibly, a wider group of stakeholders.

10.7. The Prioritised Requirements List (PRL)

10.7.1. The PRL authorises and documents what is to be included in the plan, together with the priorities.

10.7.2. The PRL is an integral planning tool which allows the team to:

10.7.2.1. Establish the basis for agreement between the customers and the suppliers on what the outcome of the project is to be

10.7.2.2. Provide a basis for estimating costs and schedules

10.7.2.3. Provide a baseline for validation and verification

10.7.2.4. Facilitate transfer from old to new working

10.7.2.5. Control and enhance the requirements

10.7.2.6. Indicate which requirement is anticipated to be in which timebox

10.7.3. The Prioritised Requirements List should contain all the requirements that the project needs to address and must be reviewed throughout the project and updated (and possibly re-prioritised) whenever a new requirement is identified or an existing requirement's priority changes.

10.7.4. The requirements in the PRL should be agreed by the Business Visionary and the appropriate stakeholders from the business.

10.7.5. By the end of Foundations, the requirements should be baselined (agreed and signed off) in order to control scope creep.

10.7.5.1. This does not mean that the requirements cannot be changed, but that change is under control and the requirements agreed at the outset are clear, together with their priorities.

10.8. Summary & Conclusion

10.8.1. Requirements evolve and emerge in an AgilePM® project. Detailed analysis of the requirements is deliberately left as late as possible, to avoid unnecessary rework and to manage complexity.

10.8.2. It is important to obtain agreement to a high-level baselined set of prioritised requirements in the PRL from the Business Visionary and key stakeholders.

10.8.2.1. This allows change to be embraced and controlled.

10.8.3. Another essential point is to identify the non-functional (performance attribute) requirements; these are a vital part of the success of the project.

11. AgilePM® Estimating

11.1. Estimating throughout the AgilePM® lifecycle.

11.1.1. Estimating and Planning by the Team (whole team) – Not just management

11.1.1.1. Doing the work estimate as a team using techniques such as Planning Poker (not defined in AgilePM®, just mentioned)

11.1.2. Estimates are not static.

11.1.2.1. They should always be reviewed at intervals throughout a project to re-assess their validity based on actual events and experience, such as further detail being elicited, risks manifesting or going away, velocity (speed of delivery) being higher or lower than expected, assumptions proving valid or invalid, unexpected events occurring, team availability changing, change requests being formally raised and so on.

11.2. A mature agile team intuitively knows what a story point means in terms of the relative size of a user story compared to other stories that it has sized in the past

11.3. Velocity

11.3.1. Measure of a team's rate of progress

11.3.2. e.g. Velocity = sum of User Story Point completed in a Timebox

11.3.2.1. Velocity Range Calculator

11.3.2.1.1. http://www.mountaingoatsoftware.com/tools/velocity-range-calculator

11.3.3. If we sum up the story-point estimates for all desired features (total size) and divide this by the team's velocity, we can determine an estimated number of Timeboxes

11.3.4. Factors Affecting Team Velocity

11.3.4.1. Technical Debt

11.3.4.2. Number of members

11.3.4.3. Unresolved Impediments

11.3.4.4. Unclear acceptance criteria

11.3.4.5. Shifting priorities

11.3.4.6. Interruptions

11.3.4.7. Multi-tasking

11.3.4.8. Skill level

11.3.4.9. New members

11.3.4.10. Team dynamics

11.3.4.11. Vacation/sick time

11.4. Why are Estimates are wrong?

11.4.1. Inexperience of something

11.4.2. Doing something that has not been done before

11.4.3. Inadequate techniques

11.4.4. Optimistic assumptions (Optimism bias)

11.4.5. Wrong person making estimates

11.4.6. Lack of information

11.5. Estimating Approaches

11.5.1. Task based

11.5.2. Product based

11.5.3. Algorithmic

11.5.4. Analogy

11.5.5. Expert judgement

11.5.6. Standard ratios

11.5.7. Function point analysis (FPA)

11.6. Popular agile estimation techniques (not defined and not part of AgilePM, but can be easily integrated)

11.6.1. User Story Point

11.6.1.1. a points scale (possibly using the Fibonacci sequence – 1,2,3,5,8,13,21,etc.) that indicates the size of a story relative to a baseline story

11.6.1.2. allow to completely separate the estimation of effort from the estimation of duration

11.6.2. Planning Poker

11.6.3. Yesterday's Weather

11.6.4. Wideband Delphi

11.6.5. Ideal days

11.6.5.1. the number of days of effort that it would take the team to get a story done if the team worked with no interruptions

11.7. Top 10 Agile Estimation Best Practices

12. AgilePM® Measurement

12.1. Introduction

12.2. Measurement

12.2.1. Download: Top 10 Agile Estimation Best Practices (by Mike Griffiths)

12.3. Understand the purpose

12.4. Keep it simple

12.5. Define measures accurately

12.6. Outcomes not outputs

12.7. Make collecting measures easy

12.8. Change measure during the project

12.9. Examples of measures

13. AgilePM® Delivering Quality

13.1. AgilePM® and Quality - two drivers

13.1.1. Solution quality

13.1.1.1. Agreeing fitness for business purpose (for this solution)

13.1.1.2. Does the solution deliver customer satisfaction?

13.1.1.3. Does it address the business needs?

13.1.1.4. Has it achieved the standards set for it?

13.1.1.5. Has the appropriate support documentation been delivered?

13.1.1.6. Is the level of maintainability acceptable?

13.1.2. Process quality

13.1.2.1. Predictable, repeatable, auditable process (for all projects)

13.1.2.1.1. On-time delivery generally becomes part of the quality acceptance standard for project quality

13.1.2.2. Does the project follow the accepted best practices?

13.1.2.3. Does the solution meet the standards expected of it (e.g. technical and support standards)?

13.1.2.4. Does the project remain under governance?

13.2. How AgilePM® helps to build quality solutions

13.2.1. Engagement of wider group of users and stakeholders

13.2.2. Proper consideration of requirements from outset, in context of wider group

13.2.2.1. Through workshops, business roles, use of MoSCoW prioritization and creating good Foundations

13.2.3. Right people involved at right time

13.2.4. Evolving solution according to business need

13.2.5. Validating solution against requirements

13.3. Maintainability - A key decision for agreeing the Quality Standard

13.3.1. Level 1:

13.3.1.1. Maintainability a required attribute of the initial delivered solution?

13.3.2. Level 2:

13.3.2.1. Deliver first, re-engineer later?

13.3.2.1.1. a.k.a. "tactical deployment, strategic patch" :-)

13.3.3. Level 3:

13.3.3.1. Short term tactical solution?

13.4. Summary & Conclusion

13.4.1. AgilePM® identifies two areas of quality to be addressed - Solution Quality and Process Quality

13.4.2. Agreeing the Maintainability level for each project is a key decision

13.4.3. AgilePM® quality management ensures that every feature that is delivered is good enough to support the business need

13.4.4. An integral part of AgilePM® quality is the understanding that delivering less than a 100% solution is acceptable

14. AgilePM® Planning

14.1. A critical problem with traditional approaches to planning is that they focus on the completion of activities rather than on the delivery of features

14.1.1. Problem with activity-based planning is that customers get no value from the completion of activities.

14.1.2. Features (and Use Stories) are the unit of customer value.

14.1.2.1. Planning should, therefore, be at the level of features, not activities.

14.1.3. Reasons why activity-based planning leads to schedule overruns include:

14.1.3.1. Activities don’t finish early

14.1.3.1.1. Parkinson’s Law (1957)

14.1.3.2. Lateness is passed down the schedule

14.1.3.3. Activities are not independent

14.2. Outline Planning - Feasibility

14.2.1. At end of Feasibility much is still uncertain

14.2.2. To move on, a detailed plan needed for Foundations

14.2.3. Plans next few weeks (the Foundations) in detail

14.2.3.1. Includes Timescale, deliverables and resources

14.2.4. Provide an outline for the first increment

14.3. Delivery Planning - Foundations

14.3.1. At end of Foundations requirements now better understood

14.3.1.1. More detail, better sizing and MoSCoW applied

14.3.2. create a Delivery Plan, focused on 2 areas:

14.3.2.1. Scheduling Work

14.3.2.1.1. A plan for deployment of current Increment and agreed schedule of Timeboxes leading up to that deployment.

14.3.2.2. Defining the Approach

14.3.2.2.1. Delivery Plan describes overall structure and approach to be adopted when working in Development Timeboxes

14.3.2.2.2. Confirms exact resources for the project.

14.3.2.2.3. Outlines number and likely length of Development Timeboxes

14.3.2.2.4. Provide information on the probable focus for Timeboxes and strategy for developing solution

14.4. Evolutionary Development Planning (Timebox Planning)

14.4.1. Lowest level of planning in AgilePM® projects

14.4.2. For the next timebox, Solution Development Team:

14.4.2.1. Agree and record

14.4.2.1.1. What they will be working on in next few weeks

14.4.2.1.2. Teams MoSCoW priorities

14.4.2.2. Predict

14.4.2.2.1. What will be delivered (Timebox Must Haves)

14.4.2.2.2. What is highly likely to be achieved (Timebox Should Haves)

14.4.2.2.3. What may or may not get done in this Timebox (Timebox Could Haves)

15. AgilePM® Project Control

15.1. The Control Parameters

15.1.1. There are several controls that are available to the Project Manager for monitoring progress and ensuring the project is on a safe course towards its goal.

15.1.2. The controls that are most frequently used are:

15.1.2.1. Risk

15.1.2.2. Benefits

15.1.2.3. Quality

15.1.2.3.1. Quality criteria are built into the features, quality is not a control that can or should be changed or compromised.

15.1.2.4. Resource

15.1.2.5. Time

15.1.2.6. Cost

15.1.2.7. Features

15.1.2.8. The resource and cost controls are separate but very closely linked since any resource will necessarily cost money.

15.1.2.8.1. Hence they can be considered the same in their usage as project controls.

15.2. Mechanisms of Control

15.2.1. AgilePM® employs an empowered teams approach to task allocation and control.

15.2.1.1. Team members organise their own work and, since the Solution Development Team includes the Business Ambassador role, close liaison with the business is an integral part of this.

15.2.2. Traditional Project Managers can sometimes feel very uncomfortable with the business/developer consensus approach taken in AgilePM® projects. Indeed enabling the day-to-day activities in an AgilePM® project can be challenging for any project manager.

15.3. Adjusting the Controls

15.3.1. AgilePM® Project Manager must resist the temptation to over-control and over-react.

15.3.2. He/she should set the objectives for the teams but leave them to get on with it unless the controls exceed any tolerances that may have been set by the project's governing body (e.g. a project board or steering committee).

15.4. Dealing with Issues

15.5. Communication is the Key

16. AgilePM® Project Management

16.1. Introduction

16.2. Managing the AgilePM® approach

16.3. Monitoring progress

16.4. Targeting and motivating the teams

16.5. Management of business involvement within the Solution Development Team

16.6. Escalation in AgilePM® projects

16.7. Summary

16.7.1. Managing AgilePM® projects relies on having a Project Manager who focuses on motivating and supporting their empowered teams, rather than micro-managing at a task level.The AgilePM® Project Manager helps keep the team on track, by ensuring AgilePM® best practice is being followed. Progress is demonstrated through frequent delivery of products, rather than by production of progress reports. However, when problems occur, it is also important to have a clear escalation process in place to enable fast decisionmaking.

17. AgilePM® Testing

17.1. Introduction

17.1.1. Testing is an important practice in upholding the AgilePM® principle to 'Never compromise Quality'.

17.1.2. It takes place throughout the lifecycle and supports software engineering principles.

17.2. Concepts for AgilePM® testing

17.2.1. Fail fast

17.2.1.1. "fail fast, learn fast"

17.2.1.2. The earlier a defect is found and fixed, the less it costs therefore the aim is to ‘Fail Fast’.

17.2.1.3. Early testing through reviews and inspections of requirements

17.2.1.4. Regression testing following changes and fixes

17.2.1.5. Do tests every day, not only before formal sign-off

17.2.1.5.1. Solution Tester role is responsible for everyday tests

17.2.1.6. User Acceptance Testing (UAT) tests are not enough

17.2.1.6.1. e.g. in IT - use black box testing / Unit testing every day even on unfinished product

17.2.1.7. "I have not failed. I’ve just found 10,000 ways that won’t work" (Thomas Edison)

17.2.1.8. "Failure is simply the opportunity to begin again, this time more intelligently" (Henry Ford)

17.2.1.9. "Testing is more than testing (and should start before testing)" (Dorothy Graham)

17.2.2. Collaborative testing

17.2.2.1. In line with the principle to Collaborate

17.2.2.2. Collaboration of all stakeholders on the project to increase the productivity of the test-fix-and-retest cycle

17.2.2.3. Ideally teams will be dedicated to the project and collocated for the duration of the Increment or Timebox

17.2.3. Repeatable Tests

17.2.3.1. Testing needs to support iterative development approach

17.2.3.2. Tests need to be designed to be repeatable

17.2.4. End-to-End experience

17.2.4.1. Collaborative working, modelling and regular demonstrations provide the ability to review the end-to-end experience from an early stage

17.2.4.2. Allows changes to be made in order to enhance and maximise the end-to-end experience

17.2.4.3. Testing the end-to-end experience includes

17.2.4.3.1. usability testing

17.2.4.3.2. process walkthroughs

17.2.4.3.3. performance testing

17.2.4.3.4. …

17.2.5. Independent testing

17.2.5.1. Product should be tested by someone other than its creator

17.2.5.2. More effective than testing performed by the creator of the product, since the creator is often limited by their own understanding

17.2.5.3. Ensures that the understanding of a requirement is tested

17.2.5.4. Active involvement of the business roles in an Atern project ensures that an independent perspective is applied

17.2.6. Prioritised tests

17.2.6.1. Tests need to be prioritised because it may not be possible to exhaustively test all products to be delivered within a Development Timebox

17.2.6.2. The primary method of prioritisation will be by using the MoSCoW rules

17.2.6.3. Each test should be aligned to a requirement which in turn will have a MoSCoW prioritisation

17.2.7. Risk-Based Testing (RBT)

17.2.7.1. With the majority of IT projects, testing can be both resource-hungry and expensive

17.2.7.2. Testing on risk as most IT projects are subjected to constraints of time, resource and money

17.2.7.3. In essence, RBT is covered by the following steps

17.2.7.3.1. Identify the risk areas

17.2.7.3.2. Assess the impact of errors

17.2.7.3.3. Plan for RBT

17.2.7.3.4. Reduce the risk of errors

17.3. Using AgilePM® Key Techniques in Testing

17.3.1. Iterative Development

17.3.2. Timeboxing

17.3.3. MoSCoW Prioritisation

17.3.4. Facilitated Workshop

17.3.5. Modelling

17.4. Testing AgilePM® Products and Testing Roles

17.4.1. Business Products

17.4.1.1. Business Testing Strategy

17.4.1.2. Business Testing Pack

17.4.1.2.1. Business Test Scenarios

17.4.1.2.2. Business Test Plans

17.4.1.2.3. Business Test Scripts

17.4.1.2.4. Business Test Records

17.4.2. Solution Products

17.4.2.1. Technical Testing Strategy

17.4.2.2. Technical Testing Pack

17.4.2.2.1. Technical Test Scenarios

17.4.2.2.2. Technical Test Plans

17.4.2.2.3. Technical Test Scripts

17.4.2.2.4. Technical Test Records

17.5. Summary & Conclusion

17.5.1. DSDM Atern testing should always be aiming to ensure the solution is fit for purpose

17.5.2. Testing should be validating the business solution as it evolves

17.5.3. Testing in Atern is based around a number of concepts which help ensure focus remains

17.5.4. Testing allows delivering the maximum benefit to the project

18. AgilePM® Official publications

18.1. Agile Project Management Handbook (v1.0 - v1.2)

18.1.1. ISBN-13: 978-0954483241

18.1.2. ISBN-10: 0954483243

18.1.3. http://www.amazon.co.uk/Agile-Project-Management-Handbook-V1-1/dp/0954483243

18.1.4. Pages: 176

18.1.5. The most important, key position on AgilePM® preparing for Foundation and Practitioner exams

18.1.6. Since AgilePM® v1 is a derived method, Agile Project Management Handbook, it's 90% of content is identical to content provided in DSDM® (v5) Atern® Handbook.

18.1.6.1. DSDM® Atern® The Handbook

18.1.6.1.1. http://www.amazon.co.uk/DSDM-Atern-Handbook-Consortium/dp/0954482220/

18.1.6.1.2. ISBN-13: 978-0954482220

18.1.6.1.3. ISBN-10: 0954482220

18.1.6.1.4. Pages: 201

18.1.6.2. That's because AgilePM® method was derived from DSDM® Atern® in 2010.

18.1.6.2.1. Same consortium created both methods and similar way of thinking.

18.1.6.3. DSDM® Atern® The Handbook is available online for FREE.

18.1.6.3.1. http://www.dsdm.org/dig-deeper/book/dsdm-atern-handbook

18.2. AgilePM V2 - Agile Project Management V2 Handbook

18.2.1. http://www.amazon.co.uk/Agile-PM-Project-Management-Handbook/dp/B00QTR9B6W

18.2.2. Pages: 240

18.2.3. The most important, key position on AgilePM® preparing for Foundation and Practitioner exams

18.2.4. Since AgilePM® is a derived method, Agile Project Management Handbook V2, in it's core is similar to DSDM® (v6) AgilePF® published in 2014.

18.2.4.1. DSDM® AgilePF® The Handbook

18.2.4.1.1. http://www.amazon.co.uk/DSDM-Agile-Project-Framework-Handbook/dp/0954483294

18.2.4.1.2. ISBN-13: 978-0954483296

18.2.4.1.3. ISBN-10: 0954483294

18.2.4.1.4. Pages: 179

18.2.4.2. That's because AgilePM® V2 method was derived from DSDM® AgilePF® in 2014.

18.2.4.2.1. Same consortium created both methods and similar way of thinking.

18.2.4.3. DSDM® AgilePF® The Handbook is available online for FREE.

18.2.4.3.1. http://dsdm.org/dig-deeper/book/dsdm-agile-project-framework

19. AgilePM® Techniques (7)

19.1. MoSCoW Prioritisation

19.1.1. One type of relative prioritisation

19.1.2. Helps in discovering customer / users needs priorities

19.1.3. Used as a tool for always hitting deadlines (Timeboxs / Increments), by dropping requirements of lower lever priority.

19.1.4. MoSCoW prioritisation is a powerful technique for helping stakeholders to understand and clearly define priorities, with a shared understanding of what the priorities mean.

19.1.5. The specific use of Must Have, Should Have, Could Have, Won’t Have this time provides a clear indication of the importance of an item and the expectations for its completion.

19.1.6. The MoSCoW Rules

19.1.6.1. The 60:20:20 ‘rule of thumb’

19.1.6.1.1. It is just a guide – not to be taken literally

19.1.6.1.2. Less than 60% is very important

19.1.6.1.3. It relates to effort

19.1.6.1.4. Understand the Minimum Usable SubseT

19.1.6.2. Must Have

19.1.6.2.1. Describes a requirement that must be satisfied in the final solution for the solution to be considered a success. The assessment of business value against Must Have requirements is straightforward. By definition, they are “priceless” as far as the project is concerned. If they are omitted, the project fails.

19.1.6.2.2. Cannot deliver on target date without this.

19.1.6.2.3. Core requirements.

19.1.6.2.4. No point in delivering on target date without this.

19.1.6.2.5. Delivered sollution is unusable without this.

19.1.6.2.6. Not legal without it.

19.1.6.2.7. Cannot deliver the Business Case without it.

19.1.6.2.8. No more than 60% effort

19.1.6.3. Should Have

19.1.6.3.1. Represents a high-priority item that should be included in the solution if it is possible. This is often a critical requirement but one which can be satisfied in other ways if strictly necessary.

19.1.6.3.2. Important but not vital.

19.1.6.3.3. Not critical.

19.1.6.3.4. May be painful to leave out, but the solution is still viable.

19.1.6.3.5. May need some kind of workaround e.g. management of expectations, some inefficiency, an existing solution, paperwork etc.

19.1.6.3.6. Normally classed as mandatory when more time is available, but without them the business objective will still be met.

19.1.6.3.7. Do not create complicated rules to define what a Should is.

19.1.6.3.8. @ 20% effort

19.1.6.4. Could Have

19.1.6.4.1. Describes a requirement which is considered desirable but not necessary. This will be included if time and resources permit.

19.1.6.4.2. Wanted or desirable but less important.

19.1.6.4.3. Less impact if left out (compared with a Should Have).

19.1.6.4.4. Work arounds easy/cheap

19.1.6.4.5. @ 20% effort

19.1.6.5. Won't Have (this time / maybe next time, next Timebox, next Increment)

19.1.6.5.1. Represents a requirement that stakeholders have agreed will not be implemented in a given release, but may be considered for the future. (note: occasionally the word "Would" is substituted for "Won't" to give a clearer understanding of this choice).

19.1.6.5.2. This is not “Would like to have” nor is it “Won’t Have ever, ever, ever”

19.1.6.5.3. These are requirements which the project team (not only SDT) has agreed it will not deliver.

19.1.6.5.4. Won’t Haves are excluded from plans for the current delivery MoSCoW Prioritisation is the key AgilePM® technique which provides the basis for decision making about project team activity at all levels.

19.1.6.5.5. They are recorded in the Prioritised Requirements List (PRL) where they help clarify the scope of the project and to avoid being reintroduced 'via the back door' at a later date.

19.1.6.5.6. Requirements are still in scope of project.

19.1.6.5.7. Out of Scope for this timeframe / Timebox / Increment.

19.1.7. AgilePM® MoSCoW recommendations

19.1.7.1. Use all the priorities.

19.1.7.2. Challenge Must Haves.

19.1.7.3. By default, at beginning, everything is Won't Have.

19.1.7.3.1. Start small with Enough Design Up Front (EDUF)

19.1.7.4. Agree what the priorities mean early in the project

19.1.7.5. Control the percentage of Must Haves - the target of 60% is to assure predictability. As the percentage of Must Haves increases above 60%, the predictability of the project decreases and the risk of failure increases

19.1.7.6. Agree how priorities will work

19.1.7.6.1. Prior to requirements capture, the definitions of Must Have, Should Have, Could Have and Won't Have need to be agreed with the business.

19.1.7.6.2. Must Have definition is not negotiable.

19.1.7.6.3. Must Have will have a critical impact on the success of the project.

19.1.7.6.4. Agree escalation or decision-making processes, e.g. Business Ambassador to Business Visionary to Business Sponsor, and agree the level of empowerment around decision-making at each level.

19.1.7.6.5. At the end of an increment, all unsatisfied requirements are reprioritised in the light of the needs of the next increment.

19.1.7.7. The Business Sponsor's perspective

19.1.7.7.1. The MoSCoW rules have been cast in a way that allows the delivery of the Minimum Usable Subset of requirements to be guaranteed.

19.1.7.7.2. A rule of thumb often used is that Must Have requirements do not exceed 60% of the effort. If this rule is followed, then that ensures contingency represents at least 40% of the total effort.

19.1.7.7.3. Whilst understanding that there is a real difference between a guarantee and an expectation, the Business Sponsor can reasonably expect more than this to be delivered except under the most challenging of circumstances. This is where the split between Should Haves and Could Haves comes into play.

19.1.7.7.4. If the Should Haves and Could Haves are split evenly with 20% of the total effort associated with each then the Musts and Shoulds, in combination, will represent no more than 80% of the total effort. The remaining 20% of effort associated with the Could Haves is now the contingency available to protect the more important requirements.

19.1.7.7.5. Sensible prioritisation, combined with timeboxing leads to predictability of delivery and therefore greater confidence

19.1.7.7.6. Keeping project metrics to show the percentage of Should Haves and Could Haves delivered on each increment or timebox will either re-enforce this confidence, if things are going well, or provide an early warning that some important (but not critical) requirements may not be met if problems arise.

19.1.7.8. MoSCoW and the Business Case

19.1.7.8.1. The best way to address prioritisation initially is with a quantified Business Case. This should support Feasibility and be revisited during Foundations.

19.1.7.8.2. If a Business Case does not exist, the Business Sponsor and Business Visionary need to articulate the business drivers, preferably in a quantified form.

19.1.7.8.3. A final consideration with regards to MoSCoW and the Business Case relates to the overall viability of the project.

19.1.7.8.4. Where there are very few Must Haves there may be a need to specify that a proportion of the Should Haves need to be delivered if the project is to remain viable. It is better to do this rather than to artificially raise specific Should Have requirements to Must Have status as it allows the best decision on precisely what requirement to work on to be deferred until later when its relative benefit may be more readily assessed.

19.1.8. Levels of prioritisation (granularity)

19.1.8.1. A Must Have requirement for the project as a whole may not be a Must Have for the first increment.

19.1.8.1.1. For example, even if a Must Have requirement for a computer system is the facility to archive old data, it is very likely that the solution could be used effectively for a few months without this facility being in place.

19.1.8.1.2. In this case, it is sensible to make the archive facility a Should or a Could Have for the first increment even though delivery of this facility is a Must Have before the end of the project.

19.1.8.2. Many consider this approach to be sensible as it allows the more important requirements to be addressed earlier rather than later but, if taking this approach, beware the risk of confusion.

19.1.8.3. Each deliverable effectively has two or even three priorities in different timeframes and the Project Manager needs to ensure that the team do not lose sight of the real business priorities.

19.1.8.4. The best way to deal with this is to create a Timebox PRL, a subset of the Project PRL that is specifically associated with a timebox and leave the priorities unchanged on the main PRL for the project.

19.1.8.5. The priority for the project may be different to that of an increment or timebox

19.1.8.6. Understand YAGNI, KISS

19.1.8.6.1. YAGNI

19.1.8.6.2. KISS

19.1.9. What to prioritise

19.1.9.1. Every item of work has a priority.

19.1.9.1.1. Priorities are set before work commences and kept under continual review as the work is done.

19.1.9.2. As new work arises either through introduction of a new requirement or through the exposure of unexpected work associated with existing requirements, the decision must be made as to how critical they are to the success of the current work using the MoSCoW rules.

19.1.9.3. All priorities should be reviewed throughout the project to ensure that they are still valid.

19.1.10. How many of each priority?

19.1.10.1. The aim is to get the percentage effort for Must Haves (in terms of effort to deliver) as low as possible and to be wary of anything above 60%, i.e. 60% Musts Haves, 40% Should Haves and Could Haves. Won't Haves are excluded from the calculation, as they won't be part of this project/increment/timebox.

19.1.10.2. Levels of effort above 60% for Must Haves introduce a risk of failure, unless the team are working in a project where estimates are known to be accurate, the approach is very well understood and the environment is understood and low-risk in terms of the potential for external factors to introduce delays.

19.1.11. Hierarchies of priorities

19.1.11.1. Requirements are identified at various levels of detail, from a high-level strategic viewpoint (typically at Feasibility) through to a more detailed, implementable level (typically during Exploration and Engineering).

19.1.11.2. High-level requirements can usually be decomposed and it is this decomposition that can help resolve one of the problems that often confront teams: that all requirements appear to be Must Haves.

19.1.11.3. If all requirements really were Must Haves, the flexibility derived from the MoSCoW prioritisation would no longer work. There would be no lower priority requirements to be dropped from the deliverables to keep a project on time and budget. In fact, this goes against the whole AgilePM® ethos of fixing Time and Resources and flexing Features (the triangles diagram). Believing everything is a Must Have is often symptomatic of insufficient decomposition of requirements.

19.1.11.4. A high-level Must Have requirement frequently yields a mix of sub-requirements, each with a different priority.

19.1.11.4.1. Flexibility is once more restored and some of the detailed functionality can be dropped from the delivered solution so that the project deadline can be met.

19.1.11.5. Where a requirement has a Must Have below a Should Have for example, this would signify that if this requirement were to be delivered, it must have the lower level requirement to be acceptable.

19.1.12. Tips for assigning priorities

19.1.12.1. 1. Work closely with the Business Visionary to ensure they are fully up to speed as to why and how AgilePM® prioritises requirements.

19.1.12.2. 2. Consider starting with all requirements as Won't Haves, and then justify why they need to be given a higher priority.

19.1.12.3. 3. For each requirement that is proposed as a Must Have, ask: 'What happens if this requirement is not met?'

19.1.12.3.1. If the answer is 'Cancel the project. There is no point in implementing a solution that does not meet this requirement', then it really is a Must Have. If not decide whether it is Should or a Could.

19.1.12.4. 4. Ask: 'If I come to you the night before deployment and tell you there is a problem with a Must Have requirement and that we can't deliver it - will you stop the deployment?'

19.1.12.4.1. If the answer is 'yes' then this is a Must Have requirement. If not decide whether it is Should or a Could.

19.1.12.5. 5. Is there a workaround, even if it is manual?

19.1.12.5.1. If there is, then it is not a Must Have requirement. Compare the cost of the workaround with the cost of delivering it, including the cost of any associated delays in determining whether it is a Should or a Could.

19.1.12.6. 6. Ask why is the requirement needed - for this project and this increment.

19.1.12.7. 7. If there is a Business Case in sufficient detail, can it be used to justify the intended priority?

19.1.12.7.1. If not, consider creating one.

19.1.12.8. 8. Is this requirement dependent on any others being fulfilled?

19.1.12.8.1. A Must Have cannot depend on the delivery of anything other than a Must Have because of the risk of it not being there.

19.1.12.9. 9. Allow different priorities for levels of acceptability of a requirement.

19.1.12.9.1. For example. 'The current back-up procedures will be followed to ensure that the service can be restored as quickly as possible.' How quick is that? Given enough time and money, that could be within seconds. They may say it Should happen within four hours, but it Must happen within 24 hours, for example.

19.1.12.10. 10. Can this requirement be decomposed? Is it necessary to deliver each of those components to fulfil the requirement? Are the decomposed elements of the same priority as each other?

19.1.12.11. 11. Tie the requirement to a project objective.

19.1.12.11.1. If the objective is not a Must Have, then probably neither is the requirement relating to it.

19.1.12.12. 12. Remember that team members may cause scope creep by working on the fun things rather than the important things. MoSCoW can help avoid this.

19.1.12.13. 13. Does the priority change with time?

19.1.12.13.1. For example, for an initial phase it is a Should Have but it will be a Must Have for the second increment.

19.1.12.14. 14. Prioritise defects / bugs, using MoSCoW.

19.1.12.15. 15. Prioritise testing, using MoSCoW.

19.1.12.16. 16. Use MoSCoW to prioritise your To Do list.

19.1.12.16.1. It can be used for activities as well as requirements.

19.1.13. Summary & Concusion

19.1.13.1. MoSCoW (Must Have, Should Have, Could Have, Won't Have this time) is primarily used to prioritise requirements, although the technique is also useful in many other areas. AgilePM® recommends no more than 60% effort for Must Haves for a project, with 40% Shoulds and Coulds. Anything higher than 60% poses a risk to the success and predictability of the project, unless the environment is well understood, the team is established and the external risks are minimal.

19.1.14. Watch: Master the art of MoSCoW prioritisation (by Keith Richards)

19.1.15. Watch: Agile in Practice: Prioritisation using MoSCoW

19.2. Daily Stand-ups

19.2.1. This is the Solution Development Team’s opportunity to share information with the whole team and to do any day-to-day re-planning and reorganising necessary when issues occur.

19.2.2. The Stand-Up usually takes place at the same time and same place each day (with the Timebox Plan visible), so that others who are not part of the SDT may listen in

19.2.3. Normally run by Team Leader (TL), is opportunity to understand progress against objectives at detailed level and to expose issues and blockers that may be getting in the way.

19.2.3.1. Rather than writing reports and reading mails where text does not represents body language communication during F2F meetings

19.2.4. Recommended same time everyday at the same place

19.2.5. Often standing up at the Taskboard

19.2.6. Teleconference Stand-Ups (Dial-ins) may be necessary where the team is split across multiple sites.

19.2.7. Attended by all SDT members.

19.2.7.1. Possible to combine several SDTs on daily stand-up.

19.2.7.2. Has the following active participants:

19.2.7.2.1. all members of the SDT, including Business Ambassador(s) and Business Analysts (BAMB)

19.2.7.2.2. any Business Advisors (BADV) actively involved in this Timebox

19.2.7.2.3. any Technical Advisors (TADV) actively involved in this Timebox

19.2.7.3. May be attended by other roles e.g.

19.2.7.3.1. The Business Visionary (BV) – in order to keep in touch with progress, to provide on-going visible support

19.2.7.3.2. The Project Manager (PM) – in order to observe progress and pick up escalated issues

19.2.7.3.3. The Technical Coordinator (TC) – in order to keep abreast of technical decisions and pick up escalated technical issues

19.2.8. Strict and simple format

19.2.8.1. Is ideally held with all participants standing in a circle by their team board

19.2.8.1.1. This is sometimes called an Information Radiator

19.2.8.2. What I have done since the last stand-up to help achieve the Timebox objectives?

19.2.8.2.1. Each member describes what they’ve done since last standup.

19.2.8.3. What I will be doing until the next stand-up to help achieve the Timebox objectives?

19.2.8.3.1. What they plan to do.

19.2.8.4. What problems, risks or issues (blockers) do I have that will prevent me or the team achieving the Timebox objectives?

19.2.8.4.1. Any problems, Risks or Issues, slowing progress.

19.2.9. Short

19.2.9.1. No longer than 15 minutes (2 minutes per person).

19.2.9.2. 2 minutes per participant + 2 minutes is a good guide

19.2.10. What order do we talk in?

19.2.10.1. Last Arrival Speaks First

19.2.10.2. Round Robin

19.2.10.3. Pass the Token

19.2.10.4. Take a Card

19.2.10.5. Walk the Board

19.2.11. GIFTS (goals of daily stand-ups)

19.2.11.1. Good Start

19.2.11.1.1. "Good standups are crisp and motivating. A lot of standups are bad. They have the enervating effect of an hour-plus weekly status meeting, only spread out over a week." Brian Marick, "Latour 3: Anthrax and standups"

19.2.11.1.2. Good Start means that the stand-up meeting should give energy, not take it.

19.2.11.1.3. Energy comes from instilling a sense of purpose and urgency; a clear sense of the purpose and a clear understanding what needs to be done to achieve it.

19.2.11.2. Improvement

19.2.11.2.1. "The purpose is not to meet... it is to improve." Joe Ely, "More on Daily Start-Up Meetings"

19.2.11.2.2. We can't fix problems we don't know about so a large part of stand-ups is about exposing problems to allow us to improve.

19.2.11.2.3. Improvement is not just about problem solving though.

19.2.11.2.4. Sharing better techniques and ideas is also important.

19.2.11.3. Focus

19.2.11.3.1. Focus on the baton, not the runners

19.2.11.3.2. The stand-up should encourage a focus on moving work through the system in order to achieve our objectives, not encourage pointless activity.

19.2.11.4. Team

19.2.11.4.1. Effective teams are built by regularly communicating, working, and helping each other.

19.2.11.4.2. This is also strongly tied with team members helping each other with shared obstacles.

19.2.11.4.3. The stand-up should be supporting the creation of an environment that encourages people to raise problems by constructing a narrative of other people helping when problems are raised.

19.2.11.5. Status

19.2.11.5.1. Status is about answering a couple questions:

19.3. Facilitated Workshops

19.3.1. Introduction

19.3.1.1. Facilitated Workshops are a specialised type of meeting, with a clear objective (product), a workshop owner, who needs the outcome of the workshop and is the driver for it to happen, a set of people (participants) who are chosen and empowered to produce the product and an independent person (facilitator) to enable the effective achievement of the objective.

19.3.1.2. Facilitated Workshops are a process in which a neutral facilitator, with no stake in the outcome of the workshop, enables a group to work together to achieve an agreed goal, whether that be solving a problem, building a plan, gathering requirements or making a decision.

19.3.1.3. Facilitated Workshops ensure a team-based approach to rich communication and collaboration and achieve results with speed and commitment and buy-in to the outcome.

19.3.1.4. Facilitated Workshops are an extremely efficient and effective way of achieving this enhanced communication.

19.3.2. Benefits

19.3.2.1. Rapid, high quality decision-making

19.3.2.1.1. Can reduce the elapsed time required to achieve objectives, such as the identification, agreement and sign-off of requirements.

19.3.2.2. Greater buy-in from all stakeholders

19.3.2.2.1. Lead to participants feeling more involved and committed to the end results due to having an opportunity to participate in, and contribute to.

19.3.2.3. Building team spirit

19.3.2.3.1. Output of the workshop benefits from the participants building on each other's ideas and gaining a better understanding of each other's viewpoints.

19.3.2.4. Building Consensus

19.3.2.4.1. Provides an opportunity for participants to discuss the relevant subject matter, including the major issues and problems, and reach a consensus on important.

19.3.2.5. Clarification of issues

19.3.2.5.1. Help to minimize ambiguities and misunderstandings, in the facilitated environment, participants can explore and model ideas, which in turn will simplify and accelerate the review and sign-off of the workshop deliverables.

19.3.3. CSFs for Facilitated Workshops

19.3.3.1. An effective, trained, independent Workshop Facilitator.

19.3.3.2. Workshop owner

19.3.3.2.1. Identify the workshop owner and ensure that they work with the facilitator to focus the workshop; Ensure time in the plans for preparation for the workshop in addition to the workshop itself

19.3.3.3. Flexibility in the format of different workshops, but clearly defined objectives.

19.3.3.3.1. Ensure that workshop participants are appropriately empowered

19.3.3.4. Thorough preparation before the workshop by Workshop Facilitator, Co-facilitator and Participants.

19.3.3.5. A mechanism for ensuring that the results of previous workshops are built in, where appropriate.

19.3.3.5.1. Keep metrics of the time taken to arrange, run and follow-up workshops and of the effectiveness of workshops in achieving their intended product

19.3.3.6. Decisions and agreements that are not forced.

19.3.3.6.1. If the workshop participants cannot agree on a point within the workshop (perhaps due to lack of information or time), the Workshop Facilitator should recognise this and elicit from the group the appropriate action to remedy the shortfall.

19.3.3.7. Participants receiving a workshop report, detailing decisions, actions and the product of the workshop, very soon after the workshop (ideally within 48 hours).

19.3.3.7.1. Monitor that workshop outputs are appropriately recorded and circulated.

19.3.3.8. Important for Foundation exam!

19.3.4. Further reading (outside AgilePM® exams scope)

19.3.4.1. see Facilitation (based on Process Iceberg®) mind map

19.3.4.2. Facilitation - An Art, Science, Skill or all three?: Build your expertise in Facilitation

19.3.4.2.1. ISBN-13: 978-0955643507

19.3.4.2.2. Pages: 235

19.3.4.2.3. http://resourceproductions.com/books

19.3.4.3. Facilitation - A Manual of Models, Tools and Techniques for Effective Group Working

19.3.4.3.1. ISBN-13: 978-0955643514

19.3.4.3.2. Pages: 269

19.3.4.3.3. http://resourceproductions.com/books

19.4. Timeboxing (a.k.a. Sprinting from Scrum), DSDM V6 recognizes 2 types of Timeboxes

19.4.1. Introduction

19.4.1.1. Timeboxing is a key technique in AgilePM®.

19.4.1.1.1. It's like Sprint from Scrum.

19.4.1.2. It is more than just setting short time periods and partitioning the development work.

19.4.1.2.1. It is a well defined process to control the creation of low-level products in an iterative fashion, with several specific review points to ensure the quality of those products and the efficiency of the delivery process.

19.4.1.3. By managing on-time delivery at the lowest level, on-time delivery at the higher levels can be assured.

19.4.1.4. Initial MoSCoW prioritisation of the work within the Timebox and continual re-assessment of what can be achieved in the agreed timeframe ensures that Timeboxes finish on time, every time.

19.4.1.5. If the team can demonstrate they are in control, and are following the process, the PM should not need to interfere or try to direct them.

19.4.1.6. Manage iterative development by exception. Ensure the Team is confident and comfortable to raise issues to you for resolution

19.4.2. Timebox

19.4.2.1. similar to Sprint in Scrum

19.4.2.2. similar to Iteration in XP

19.4.2.3. Every Timebox can be considered as beginning with a Kick-off and ending with a Close-out meeting.

19.4.2.4. In general Timebox = fixed amount of time

19.4.2.5. Each Timebox lasts from 1 to max 6 weeks.

19.4.2.5.1. RERO - Release early, release often

19.4.2.5.2. Industry sweet spot is 1/2 weeks

19.4.2.5.3. It is recommended that each Timebox has same length - builds Cadence and habits

19.4.2.6. Each Timebox has it's own Timebox Plan.

19.4.2.6.1. Created by Team Leader

19.4.3. Each Timebox has Kick-off and Close-out steps/meetings, yet exacution of Timebox can be either using DSDM Structured Timebox or using Free Format Timebox

19.4.3.1. Kick-off

19.4.3.1.1. goal

19.4.3.1.2. length

19.4.3.1.3. Meeting of the Solution Development Team (SDT) to confirm the: objective(s), content, priorities and responsibilities within the Timebox and set review points and criteria

19.4.3.1.4. Input from all members of the Solution Development Team

19.4.3.1.5. The Business Analyst works closely with the Solution Tester and Business Ambassador to clarify the Acceptance Criteria for the Timebox

19.4.3.2. DSDM Structured Timebox

19.4.3.2.1. Each DSDM Structured Timebox had 3 Iterations (not confuse with Increments or Scrum iterations).

19.4.3.2.2. Timebox control with 3 iterations:

19.4.3.2.3. Each execution of the cycle (iteration) yields a result successively closer to desired outcome.

19.4.3.3. Free Format Timebox

19.4.3.3.1. Daily stand-ups occur every working day so there is a detailed review of progress to date.

19.4.3.4. Close-out

19.4.3.4.1. goal

19.4.3.4.2. length

19.4.3.4.3. Short meeting where the final formal acceptance of the Timebox products is agreed, particularly by the Business Visionary (BV) and Technical Coordinator (TC)

19.4.3.4.4. If Must Haves are incomplete, the effects on the whole increment need to be assessed; if it is forecast that the project will not achieve at least the Must Haves, this must be drawn to the attention (i.e. escalated) of the next higher level of project governance

19.4.3.4.5. At the end of each Development Timebox, it is also worth running a short "Retrospective Workshop" with the Solution Development Team (SDT) and other relevant stakeholders, to gather feedback and lessons learned for the Timebox

19.4.4. Planning and Scheduling Timeboxes

19.4.4.1. A primary purpose of the Delivery Plan is to provide a schedule of the increments and, within them, the Timeboxes that make up the project.

19.4.4.2. The schedule should reflect the likely number and duration of each Timebox in a current or imminent increment and also states, at the highest level, the planned focus for each of those Timeboxes.

19.4.4.3. Application of the Timeboxing in conjunction with the MoSCoW prioritisation technique will ensure on-time completion of each Timebox and the delivery of a fit-for-purpose product in that timeframe.

19.4.4.4. If each Timebox completes on time, then each increment will complete on time and thus the project as a whole will complete on time.

19.4.4.5. When creating a schedule of Timeboxes, the primary driver should always be the business priority. However it is advisable to consider other factors when working out a delivery order.

19.4.4.6. Such other factors will include:

19.4.4.6.1. Business and technical risk

19.4.4.6.2. Solution architecture and external dependencies

19.4.4.6.3. Ease of implementation and the drive for an early return on investment

19.4.4.6.4. Availability of critical or specialist resources

19.4.4.6.5. Constraints associated with business process or corporate policy

19.4.4.6.6. Quick wins

19.4.5. Reviewing Timeboxes (when using DSDM Structured Timebox)

19.4.5.1. Investigation Review

19.4.5.1.1. Solution Development Team (SDT) share results of their investigation with Business Ambassador, Business Visionary (BV) (possibly) and Technical Coordinator (TC)

19.4.5.1.2. Team validate what they are intending to deliver by end of Timebox

19.4.5.2. Refinement Review

19.4.5.2.1. Solution Development Team (SDT) share results so far with Business Ambassador, Business Visionary (BV) (possibly) and Technical Coordinator (TC)

19.4.5.2.2. Agree and prioritise work to be completed by end of Timebox

19.4.5.3. Consolidation Review

19.4.5.3.1. Share final results of Timebox with Business Ambassador, Business Visionary (BV) (probably), and Technical Coordinator (TC)

19.4.5.3.2. Confirm deliverables are fit for their intended purpose (i.e.. meet agreed Acceptance Criteria)

19.4.6. Summary

19.4.6.1. Timeboxing is one of AgilePM®'s key Practices and is used in combination with the Practice of MoSCoW prioritisation to ensure on-time delivery.

19.4.6.2. At the lowest level, the Development Timebox maintains focus on delivery in the short term (weeks or even days).

19.4.6.3. If Development Timeboxes are delivering at least the Must Haves on time every time, then the estimating process is working, the team is working, the Delivery Plan is being validated and the risks should be reducing.

19.4.6.3.1. This low-level confidence feeds upwards to instil confidence at the increment and the project levels.

19.5. Iterative Development

19.5.1. Iterative Development is one of AgilePM®'s key techniques.

19.5.1.1. It allows the high-level requirements established during Foundations phase to be explored and evolved in more detail during Development Timeboxes of Exploration and Engineering.

19.5.1.2. It ensures that the cycles of iteration in the Development Timeboxes are controlled, and that a feedback loop is build into the way of working within these Timeboxes.

19.5.2. Iterative Development cycles are typically short - days or even hours!

19.5.3. The cycles of Identify, Plan, Evolve and Review, combined with the structure of the Solution Development Timebox, comprising iterations of Investigation, Refinement and Consolidation, ensure that the iterative process is well controlled without stifling the autonomy, creativity and productivity of the Solution Development Team (SDT).

19.5.4. The three approaches described below explain how this iterative and incremental development can be achieved in the creation of a solution

19.5.5. a.k.a. IPER cycle

19.5.5.1. Identify

19.5.5.1.1. The team agree the objective of the current work

19.5.5.2. Plan

19.5.5.2.1. The team work out what needs to be done, by whom, to meet that objective

19.5.5.3. Evolve

19.5.5.3.1. The team work on the solution

19.5.5.4. Review

19.5.5.4.1. The work is tested to see if the objective has been achieved

19.5.5.5. The feedback afforded by the cycle ensures that the solution evolves, over time, in a controlled manner

19.5.5.6. in general ... it's like a Deming Cycle.

19.5.6. It enables a growing understanding of the requirement and convergence on an accurate solution.

19.5.7. Top Tips

19.5.7.1. Team empowerment is key to successful agile projects - the team has all the necessary skills and knowledge within the team

19.5.7.2. Monitor the business involvement during iterative development. This may be easier if the amount of business involvement expected is made clear and explicit in the early stages. That way it is easy to see quickly if the amount of time being given is as expected or less than expected

19.6. Modelling

19.6.1. Modelling and Prototyping are closely linked cocepts.

19.6.1.1. A prototype is always a kind of a model.

19.6.1.1.1. In IT, prototype often refers to a funstional software but in ALPHA / BETA stage or some wireframing model

19.6.1.2. A model is not a necessary a prototype.

19.6.1.2.1. In IT, model often refers to a set of diagrams (but not a part of functional software)

19.6.2. A model is:

19.6.2.1. A simplified view of a complex reality or concept.

19.6.2.2. A description or analogy (to help visualise something that cannot be directly observed).

19.6.2.3. A small but exact copy of something.

19.6.2.4. A pattern or figure of something to be made.

19.6.2.5. Examples:

19.6.2.5.1. Storyboards

19.6.2.5.2. Flowcharts

19.6.2.5.3. Swim-lane diagrams

19.6.2.5.4. Process-models

19.6.2.5.5. UML / SysML diagrams (IT)

19.6.2.5.6. Archimate diagrams (IT)

19.6.2.5.7. OBASHI Business & IT (B&IT) diagrams

19.6.2.5.8. OBASHI Dataflow Analysis View (DAVs) diagrams

19.6.3. Models should help in determining (Viewpoints/Perspectives for Modelling):

19.6.3.1. Why

19.6.3.1.1. Rationale, ends and means

19.6.3.2. Where

19.6.3.2.1. Locations and Links

19.6.3.3. Who

19.6.3.3.1. People, Tasks & Responsibilities

19.6.3.4. What

19.6.3.4.1. Business procedures (Data & Relationships)

19.6.3.5. When

19.6.3.5.1. Business events, time & scheduling

19.6.3.6. How

19.6.3.6.1. Processes & Outputs

19.6.4. Modelling

19.6.4.1. Many industries benefit from the use of models, prototypes and mock-ups to establish requirements, confirm expectations and test the achievability of objectives.

19.6.4.1.1. Significant benefits in making ideas, situations and options visible.

19.6.4.2. Modelling can range from very informal models (post-it notes on a table) to very detailed, complex models using specific notations.

19.6.4.3. These can be as different as a storyboard to represent an advertisement or a scale model of a proposed hospital.

19.6.4.4. They can be temporary, transient or throwaway or may be a prototype which forms a part of the eventual solution.

19.6.4.5. AgilePM® advocates the use of models to improve communication and to create or challenge ideas by making developing products visible.

19.6.4.5.1. Emphasis on ensuring models enhance communication.

19.6.4.5.2. AgilePM® advocates clear and continuous communication, using rich communication techniques, of which the development of models and prototypes is a key element

19.6.5. Using models for the AgilePM® products

19.6.5.1. The AgilePM® framework has identified a number of products that may need to be generated by the end of each phase of the lifecycle.

19.6.5.1.1. Of necessity, these products are a combination of technical information, project objectives and constraints.

19.6.5.2. Models and prototypes will help to analyse and present some of the required technical information in manageable increments and to test the developing product.

19.7. Prototyping

19.7.1. Prototyping is one of the many ways by which AgilePM® ensures effective communication between stakeholders, whether from different parts of the business, different organisations or sometimes different cultures, languages and / or countries.

19.7.2. A prototype is something that serves to illustrate the typical qualities of the eventual solution

19.7.2.1. It may evolve into eventual solution (an evolutionary prototype) or may always be intended to be an experimental model (a disposable prototype)

19.7.3. A prototype in AgilePM® is a piece of work that demonstrates how a given objective can be or has been achieved

19.7.4. Disposable prototypes

19.7.4.1. Example is an IT-based solution such as Architectural Spike, a.k.a. Proof of Concept prototype, which is a thin, end-to-end mock-up of the pathway through a solution

19.7.4.1.1. AgilePM® calls these Capability/Techniques prototypes

19.7.5. Evolutionary prototype

19.7.5.1. All Iterative Development on a particular deliverable, carried out in accordance with the Iterative Development cycle, can be considered to be prototyping, because elements are constantly being build, shown, modified and revisited.

19.7.5.1.1. Iterative Development technique is sometimes referred to as Prototyping

19.8. Other techniques used in Agile (not defined in AgilePM® method, but can be easily implemented)

19.8.1. 10 Intristic Motivators

19.8.2. Burn-Down Chart

19.8.3. Burn-Up Chart

19.8.3.1. Watch: Agile in Practice: Burn_Up Charts

19.8.4. CHAMPFROGS

19.8.5. Circle

19.8.6. Circles of Concern and Influence

19.8.7. Facilitated Workshops

19.8.8. Feature Progress Report

19.8.9. Five dysfunctions of a team

19.8.10. Future Backwards

19.8.11. Hapiness Metric

19.8.12. Kanban wall

19.8.13. Mad, Sad, Glad

19.8.14. Perfection Game

19.8.15. Personas

19.8.16. Planning Poker

19.8.17. Predictability Measure

19.8.18. Problem -> Goal -> Advantage

19.8.19. Product / Release Burndown Chart

19.8.20. Relative Weighting

19.8.21. Run your ass off

19.8.22. Speed dating

19.8.23. Sprinting / Timeboxing

19.8.24. Starfish

19.8.25. The Sailboat

19.8.26. Theme Scoring

19.8.27. Theme Screening

19.8.28. Timeline / Emotion Graph

19.8.29. Value vs Effort Matrix

19.8.30. ...

19.9. http://retrospectivewiki.org/

19.10. http://tastycupcakes.org/

19.11. http://www.funretrospectives.com/

20. Agile fundamentals (agile in general not AgilePM® fundamentals)

20.1. Agile Manifesto

20.1.1. http://agilemanifesto.org/

20.1.2. 17 It industry veterans met at Snowbird Resort on February 11-13 2001 and created Agile Manifesto

20.1.2.1. Introduced 4 Values and 12 Principles defining Agile for Software Development

20.1.3. disciplines that gave rise to the Agile Manifesto

20.1.3.1. Extreme Programming, SCRUM, Dynamic Systems Development Method (DSDM®), Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming.

20.2. Agile Alliance

20.2.1. http://www.agilealliance.org/

20.3. Agile currently is buzzword, a marketing term

20.3.1. Agile is like any other newly introduced popular concept. “… Everybody is talking about it. Very few are doing it and those who are, are doing it badly” (James O. Coplien)

20.3.2. Sadly... Agile as a word by it's own simply means - nothing more than merketing term.

20.3.2.1. there are so many Agile methodologies, Agile standards, Agile techniques, Agile tools, Agile good / best agile practices, Agile frameworks etc., that 'Agile' word itself is to general

20.3.2.1.1. see Agile World mind map

20.3.3. Agile is a generic description of a “Style of Working” and Philosophy.

20.3.3.1. Not only style of working on project but rather culture in ENTIRE organization including also it's management level, clients and partners

20.3.3.2. ‘Agile Project Management’ is perhaps an oxymoron

20.4. The Agile Mindset, Values and Principles

20.4.1. 4 Agile Value

20.4.1.1. 1. Individuals and interactions over processes and tools

20.4.1.2. 2. Working software over comprehensive documentation

20.4.1.3. 3. Customer collaboration over contract negotiation

20.4.1.4. 4. Responding to change over following a plan

20.4.2. 12 Agile Principles

20.4.2.1. 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

20.4.2.2. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

20.4.2.3. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

20.4.2.4. 4. Business people and developers must work together daily throughout the project.

20.4.2.5. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

20.4.2.6. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

20.4.2.7. 7. Working software is the primary measure of progress.

20.4.2.8. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

20.4.2.9. 9. Continuous attention to technical excellence and good design enhances agility.

20.4.2.10. 10. Simplicity - the art of maximizing the amount of work not done - is essential.

20.4.2.11. 11. The best architectures, requirements, and designs emerge from self-organizing teams.

20.4.2.12. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

20.4.3. The unlimited number of Agile Practices

20.4.3.1. The 'forest' of Agile Methods, Frameworks, Standards ...

20.4.3.1.1. see Agile World mind map

20.4.3.2. Being Agile vs Doing Agile

20.4.3.2.1. Being means understanding by intuition

20.4.3.2.2. Doing in a bad manner means repeating blindly one of the methodologies without embedding core values, principles and leadership practices - simply saying Agile culture

20.5. Agile is a umbrella term enclosing different methodologies, tools, techniques, practices and frameworks

20.5.1. In Agile community umbrella symbolizes different approaches in implementing Agile Manifesto but yet all from them are "Agilelish"

20.5.2. SCRUM, Lean, KANBAN, XP are not ‘Agile Project Management’ practices but rather team level practices

20.5.2.1. No Project Manager role

20.5.2.2. No project definition and etablished project / programme governance

20.5.2.3. ...

20.5.3. see Agile World mind map

20.6. Plan-Driven Projects vs. Change-driven Project Projects

20.6.1. Traditional (waterfall or sequential) Project Management metaphor

20.6.1.1. Railway metaphor

20.6.1.1.1. Moving forward, based on delivering predicted upfront requirements in accepted tolerances with limited tolerance to change, destination (final product specification) is known upfront and it will hardly change to any other destination

20.6.1.1.2. Changing course of train based on requirements

20.6.1.2. a.k.a. Plan-driven

20.6.1.2.1. build around paradigm of process

20.6.1.3. defined process control model

20.6.1.3.1. All work is understood before execution

20.6.1.3.2. Given a well-defined set of inputs, the same outputs are generated every time

20.6.1.3.3. Follow the pre-determined steps to get known results

20.6.2. Agile (iterative + incremental + adaptive) Project Management metaphor

20.6.2.1. Sailing metaphor

20.6.2.1.1. Embracing change of requirements, finding TRUE value for stakeholders by experimenting, testing, changing status quo.

20.6.2.1.2. Adapting / changing course of sailing based on business TRUE business needs and priorities, which could be different than requirements

20.6.2.2. a.k.a. Change-driven

20.6.2.2.1. build around paradigm of change / adaptation

20.6.2.3. empirical (adaptive) process control model

20.6.2.3.1. Frequent inspection and adaptation occurs as work proceeds

20.6.2.3.2. Processes are accepted as imperfectly defined

20.6.2.3.3. Outputs are often unpredictable and unrepeatable

20.7. Agile is best for complex projects

20.7.1. Simple (straightforward)

20.7.1.1. Everything is known and predicatable

20.7.1.2. Characteristics

20.7.1.2.1. Repeating patterns and consistent events

20.7.1.2.2. Clear cause‐and‐effect

20.7.1.2.3. Well establish knowns

20.7.1.2.4. Fact based management

20.7.1.3. Leader’s/Manager’s job

20.7.1.3.1. Use best practices

20.7.1.3.2. Extensive communication not necessary

20.7.1.3.3. Establish patterns and optimize to them

20.7.1.3.4. Command and control

20.7.2. Complicated

20.7.2.1. More is known than unknown

20.7.2.2. Characteristics

20.7.2.2.1. More predictability than unpredictability

20.7.2.2.2. Fact‐based management

20.7.2.2.3. Experts work out wrinkle

20.7.2.3. Leader’s/Manager’s job

20.7.2.3.1. Utilize experts to gain insights

20.7.2.3.2. Use metrics to gain control

20.7.2.3.3. Sense, analyze, respond

20.7.2.3.4. Command and control

20.7.3. Complex

20.7.3.1. More is unknown than known

20.7.3.2. Characteristics

20.7.3.2.1. More predictability than unpredictability

20.7.3.2.2. Fact‐based management

20.7.3.2.3. Experts work out wrinkle

20.7.3.3. Leader’s/Manager’s job

20.7.3.3.1. Create bounded environments for action

20.7.3.3.2. Increase levels of interaction and communication

20.7.3.3.3. Servant leadership

20.7.3.3.4. Generate ideas

20.7.3.3.5. Probe, sense, respond

20.7.4. Chaotic (unpredictable)

20.7.4.1. Very little is known

20.7.4.2. Characteristics

20.7.4.2.1. High Turbulence

20.7.4.2.2. No clear cause‐and‐effect

20.7.4.2.3. Unknowables

20.7.4.2.4. Many decisions and no time

20.7.4.3. Leader’s/Manager’s job

20.7.4.3.1. Immediate action to re‐establish order

20.7.4.3.2. Prioritize and select actionable work

20.7.4.3.3. Look for what works rather than perfection

20.7.4.3.4. Act, sense, respond

20.7.5. See also Cynefin framework (by Dan Snowden)

20.7.5.1. different view on Cynefin Framework

20.7.5.1.1. Five domains

20.7.5.1.2. Can be used to assess the output, outcome or benefit

20.7.5.1.3. Can be used to assess the project environment

20.7.5.1.4. Collaboratively assessed to avoid people’s natural tendencies.

20.7.5.2. https://www.youtube.com/watch?v=N7oz366X0-8

20.7.6. Relating Complexity and Management Style

20.8. Agile is about delivering "best possible value" not maximum possible value

20.8.1. VALUE is NOT the same as BENEFIT

20.8.1.1. Benefits

20.8.1.1.1. Benefit is about outputs

20.8.1.1.2. Benefit is a objective

20.8.1.1.3. Benefit is an advantage to stakeholders (internal or external to the organization)

20.8.1.1.4. Benefit can be financial and non financial

20.8.1.1.5. Benefit can be ...

20.8.1.1.6. Benefit MUST be measurable and observable

20.8.1.1.7. Benefits are identifiable and quantifiable

20.8.1.1.8. Benefits SHOULD have baselines

20.8.1.1.9. Benefits SHOULD have priorities

20.8.1.1.10. Benefits types:

20.8.1.1.11. in general benefit = delivered requirements on time, on budget, within scope etc.

20.8.1.2. Value

20.8.1.2.1. Value is about outcomes

20.8.1.2.2. Value is subjective

20.8.1.2.3. Value can be measurable (if required but not natural to use such techniques in any Agile approach)

20.8.1.2.4. Value can be ...

20.8.1.2.5. Values SHOULD have priorities

20.8.1.2.6. in general value = designed fit for purpose, as small as possible solution

20.9. Agile is about focusing on business value / outcome, not strictly project plan / output

20.9.1. Focusing on value delivery not on fixed product definition or strict adherence to plan

20.9.1.1. That's why most Agile approaches define Project Vision

20.10. Agile respects the urgency and importance of priorities conveyed by the customer / user, most prominently by incremental delivery and flexible sequencing

20.11. Agile respects the common sense that all requirements can not be known at the outset, particularly when the outcomes are intangible and subject to an evolving understanding.

20.11.1. “People don’t know what they want until you show it to them” (Steve Jobs, 1955 - 2011)

20.12. Agile is about empowering people, treating them as intellectual individuals

20.12.1. “You have to learn to manage in situations where you don’t have command authority, where you are neither controlled nor controlling. That is the fundamental change.” (Peter F. Drucker)

20.13. Agile is about working closely and constantly (active two side collaboration) with customer throughout (including more than just feedback loops)

20.13.1. “Never write when you can talk. Never talk when you can nod. And never put anything in an email“ (Eliot Spitzer)

20.14. Agile is about change, constant change which leads to better value

20.14.1. “If a process is too unpredictable or too complicated for the planned, (predictive) approach, then the empirical approach (measure and adapt) is the method of choice“ (Ken Schwaber)

20.14.2. "Move Fast and Break Things" Mark Zuckerberg, Facebook

20.14.3. "Change is the only constant." Heraclitus, Greek philosopher

20.15. Agile thinking / approach often requires mind change and cultural shift

20.15.1. Not every organization is ready for that change!

20.15.2. "It is quite difficult for a highly structured and seniority-based organization to mobilize itself for change, especially under noncrisis conditions. this effort collapses somewhere in the hierarchy" (K. Imai, I. Nonaka, H. Takeuchi)

20.15.3. "Scrum exposes every cultural dysfunction that impedes developing software [...] It is not an approach or process that can be modified to fit the existing organizational culture; the culture must change to enable Scrum" (K. Schwaber, J. Sutherland)

20.15.4. “We cannot become what we need by remaining what we are.” (John C. Maxwell)

20.16. Why Agile Works?

20.16.1. 1. The customer's representative is in the driver's seat

20.16.2. 2. Quick reaction to the changing market and needs

20.16.3. 3. More visibility

20.16.4. 4. Ideal environment for development

20.16.5. 5. Self-manged teams

20.16.6. 6. Removes confusion and distraction

20.16.7. 7. No fortune tellers; Plan as you go

20.16.8. 8. Issues are less disruptive

20.16.9. 9. Continuous improvement

21. Interactive AgilePM® Glossary

21.1. Interactive AgilePM® Glossary

22. This freeware, non-commercial mind map (aligned with the newest version (v2) of AgilePM®) was carefully hand crafted with passion and love for learning and constant improvement as well for promotion the AgilePM® method and as a learning tool for candidates wanting to gain AgilePM® qualification. (please share, like and give feedback - your feedback and comments are my main motivation for further elaboration. THX!)

22.1. Questions / issues / errors? What do you think about my work? Your comments are highly appreciated. Feel free to visit my website: www.miroslawdabrowski.com

22.1.1. http://www.miroslawdabrowski.com

22.1.2. http://www.linkedin.com/in/miroslawdabrowski

22.1.3. https://www.google.com/+MiroslawDabrowski

22.1.4. https://play.spotify.com/user/miroslawdabrowski/

22.1.5. https://twitter.com/mirodabrowski

22.1.6. miroslaw_dabrowski

23. AgilePM® Official resources

23.1. AgilePM® sample exams, available online

23.1.1. Foundation

23.1.1.1. http://www.apmg-exams.com/index.aspx?subid=87&masterid=26

23.1.2. Practitioner

23.1.2.1. sample Practitioner exams are not available online

23.2. AgilePM® examination syllabus

23.2.1. EN

23.2.1.1. http://www.pmweb.co.uk/wp-content/uploads/2013/01/AgilePM-Syllabus-v1.4.pdf

23.3. AgilePM® glossary

23.3.1. EN

23.3.1.1. http://www.agilechangemanagement.co.uk/wp-content/uploads/2013/09/agile-glossary.pdf

23.4. AgilePM® White Papers

23.4.1. Agile Project Management White Paper

23.4.1.1. http://www.dsdm.org/sites/default/files/Agile-PM-White-Paper.pdf

24. Instrumental Critical Success Factors (ICSFs) of AgilePM® V2 projects (5)

24.1. When these factors are not met, they represent a significant risk to AgilePM® approach.

24.1.1. It is important to identify these risks early and consider hot they could be mitigated.

24.2. Factors need constant monitoring as they form the key risks to the project.

24.3. 1. Embracing the DSDM® Approach

24.3.1. In order for AgilePM® projects to be successful, project stakeholders and participants understand and accept the AgilePM® project approach.

24.3.2. Best business value emerges when projects are aligned to clear business goals, deliver frequently and involve the collaboration of motivated and empowered people.

24.4. 2. Effective Solution Development Team (SDT)

24.4.1. In order for DSDM® projects to be successful, it has to be recognized that people are at the heart of successful projects.

24.4.1.1. Solution Development Team is instrumental in ensuring the development of the right solution.

24.4.2. Building an effective team for successful delivery focuses on 4 elements:

24.4.2.1. Empowerment

24.4.2.1.1. Teams are empowerment to make decisions based on their expertise and team as a whole empowered to make decisions within the boundaries agreed during Foundation phase.

24.4.2.1.2. Business Sponsor and Visionary must agree to delegate day-to-day decision-making to Business Ambassador(s).

24.4.2.1.3. Without business empowerment team progress will slow down.

24.4.2.2. Stability

24.4.2.2.1. Solution Development Team brings together business and technical knowledge through the iterative development process.

24.4.2.2.2. Solution is a evolving product, it evolves dynamically and this places great emphasis on conversations between team members, rather than relying on documents (as a primary source and focus of communication).

24.4.2.3. Skills

24.4.2.3.1. Solution Development Teams are contains skilled people, both in terms of business knowledge and technical expertise.

24.4.2.3.2. Team should also have a good communication skills and the willingness to work with others.

24.4.2.4. Size

24.4.2.4.1. AgilePM® suggests that the optimum Solution Development Team size is 7 +/- 2 people.

24.4.2.4.2. With such small teams, teams can communicate with one another with:

24.4.2.4.3. Bigger or smaller teams of course are possible but they can introduce risks

24.5. 3. Business Engagement - Active and On-going

24.5.1. In order for AgilePM® projects to be successful, it is vital that the business is actively engaged and commits to necessary amount of time at all levels, and that commitment is maintained through the project.

24.5.2. Ensuring active and on-going business engagement relies on 3 elements:

24.5.2.1. Commitment of business time throught

24.5.2.2. Day-to-Day collaboration involving business roles in the Iterative Development process

24.5.2.3. A supportive commercial (e.g. contractual) relationship (where appropriate)

24.6. 4. Iterative Development, Integrated Testing and Incremental Delivery

24.6.1. In order for AgilePM® projects to be successful, testing has to be fully embedded as part of the iterative and incremental development approach is key both to reduction of project risk and to the success of the project,.

24.6.2. It has to be ensured that individual elements of the solution are technically fit for purpose and meet the business need, builds confidence in the direction and the quality of the Evolving Solution.

24.7. 5. Transparency

24.7.1. In order for AgilePM® projects to be successful, building confidence is a key aspect of DSDM® projects.

24.7.1.1. AgilePM® is all about building confidence in the Evolving Solution, and in this way reducing the risks of the unknown or the invisible.

24.7.2. Demonstrations of the Evolving Solution provide physical, objective and unquestionable proof of progress (compared with a progress report showing a subjective % complete).

24.7.3. "The great thing about fact-based decisions is that they can overrule the hierarchy." - Jeff Bezos, Amazon.com

24.7.4. "Transaprency is neither good or bad. Things and increments just are. They may not be what you want, but that means hard decisions are required. You have to have a firm grasp of the real facts to make solid decision.." - K. Schwaber, J. Sutherland

24.8. Understand your constraints

24.8.1. Consider the AgilePM® Principles

24.8.1.1. Will the organization support this way of working?

24.8.2. Consider the AgilePM® project variables

24.8.2.1. Is there flexibility in depth and detail of features?

24.8.3. Think about the people

24.8.3.1. Are all roles capable of and committed to the project approach?

24.8.4. This is rarely a black and white decision

24.9. Project Approach Questionnaire (PAQ)

24.9.1. AgilePM® provides a simple questionnaire - the Project Approach Questionnaire (PAQ)

24.9.1.1. PAQ helps to identify and confirm the level of achievement of all the above factors and to assess potential risk areas to be addressed

24.9.2. PAQ is completed during Feasibility phase and re-assessed as part of Foundations phase

24.9.3. PAQ is original document from DSDM® method

24.9.4. PAQ is based on Instrumental Critical Success Factors (ICSFs), AgilePM® Principles and other situational factors

24.9.5. PAQ Supports assessment of:

24.9.5.1. to what extent ISFs have been met

24.9.5.2. what level of risk exists

24.9.5.3. what needs to be done to manage those risks

24.10. Download: AgilePM® Project Approach Questionnaire (PAQ) (XLS)

24.11. Historically AgilePM® v1.0 had 9 Instrumental Critical Success Factors (ICSF)

24.11.1. 1. Acceptance of the AgilePM® philosophy before starting work

24.11.1.1. Includes the concept that in order to deliver the right thing at the right time and handle change dynamically may result in delivering less than 100% of the possible solution - this needs to be agreed by all parties.

24.11.1.2. Accepting new philosophy in a new organisation may be difficult - piloting the philosophy (perhaps on a less critical initiative) first helps to win acceptance.

24.11.1.3. All stakeholders must be prepared to accept that change is inevitable.

24.11.1.3.1. Change will calibrate project course on 'true' Value.

24.11.1.3.2. It is important that the Business Sponsor and senior management understand and accept the AgilePM Philosophy.

24.11.2. 2. Appropriate empowerment of the Solution Development Team (SDT).

24.11.2.1. The senior business management must agree to delegate an appropriate level of decision-making to the Business Ambassador(s) in the SDT or to take that role themselves. (WHAT)

24.11.2.1.1. Similarly, the Solution Developers in the team should also be empowered to make appropriate technical decisions. (HOW)

24.11.2.2. If this is not possible, they would need to participate in the team themselves (i.e. in this circumstance, the Business Ambassador role may need to be taken by a more senior person from the Business).

24.11.2.3. Without business empowerment, team progress will slow down while awaiting decisions being made elsewhere and to a different timeframe.

24.11.2.4. The Business Ambassador(s) should be empowered to make decisions without referral to higher authorities outside the team.

24.11.2.5. Solution Developers in the SDT should also be empowered to make decisions.

24.11.2.5.1. It is important that the concept of empowerment does not give all SDT members complete freedom to do whatever they want, whenever they want. In reality, empowerment is within agreed boundaries of decision-making.

24.11.2.6. Where a decision is outside the agreed boundaries, this would still need to be formally escalated.

24.11.2.7. However, this is the exception and the majority of day-to-day decision-making should be within the remit of the SDT.

24.11.2.8. Empowerment is two-way - it is not enough to tell people new to AgilePM® that they are empowered -they may need constant reinforcement and coaxing to make their own decisions - the daily stand up will show whether there are risks here.

24.11.3. 3. Commitment of senior business management to provide the necessary Business Ambassador (and Business Advisor) involvement

24.11.3.1. The level of business commitment for this project should be quantified and discussed in the early stages.

24.11.4. 4. Incremental delivery

24.11.4.1. To achieve an early return on investment, the organisation needs to be amenable to the incremental delivery of solutions.

24.11.4.2. Another benefit of the incremental approach is a reduction in risk (compared with the big-bang, large drop of a 100% final solution).

24.11.4.3. Delivering a partial solution allows the business to take on the solution in manageable chunks and also ensures the solution builds on previous increments, i.e. building from a position of confidence.

24.11.4.4. It is still possible to gain all the project-focused benefits of incremental delivery even if the business chooses not to deploy the solution incrementally: for example building and, potentially, accepting the solution incrementally, ahead of a single production release.

24.11.4.5. All stakeholders must be prepared to deliver a fit-for-purpose solution.

24.11.4.5.1. Not 'all of nothing' solution.

24.11.5. 5. Access by the Solution Development Team (SDT) to business roles

24.11.5.1. The best communication occurs if the SDT - including the Business Ambassador - are collocated in their own dedicated environment, free from daily interruptions.

24.11.5.2. Collocation is recommended.

24.11.5.2.1. Even if co-location is not possible, it is often useful to have a room where everyone can come together from time to time. This gives a focus for the project.

24.11.5.3. Developers are in a different time zone from the Business Ambassador(s), there will be periods where it is not possible just to pick up the phone and this potential delay presents a risk to the AgilePM® approach which needs to be addressed.

24.11.6. 6. Solution Development Team (SDT) stability

24.11.6.1. The overlapping development skills required (i.e. business and technical knowledge in use concurrently throughout the Iterative Development process), the speed of development together with AgilePM®'s emphasis on rich communication at the SDT level, rather than communication driven primarily through documents, means that an AgilePM® project will be put at serious risk if staff are swapped in and out. Specialists may be called in as long as the core team remains stable.

24.11.7. 7. Solution Development Team (SDT) skills

24.11.7.1. Progress is significantly enhanced when the SDTs contains skilled people, both in terms of business knowledge and technical expertise.

24.11.7.1.1. Cross-functional team members.

24.11.7.2. This does not mean that every team member needs to be a multi-skilled expert.

24.11.7.3. All team members must have good communication skills if a team with diverse skills is to function as a coherent unit.

24.11.8. 8. Solution Development Team (SDT) size

24.11.8.1. For this to be effective, AgilePM® suggests that the optimum SDT size is 7 +/- 2 people - at this level, the team can communicate with one another with the minimum of formality, minimum of management overhead..

24.11.8.1.1. see George A. Miller: "The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information"

24.11.8.2. Bigger or smaller SDTs of course are possible but they can introduce risks

24.11.8.2.1. team is very small (3/4 people)

24.11.8.2.2. team is 9+

24.11.8.3. Where the SDT size is going to be greater than 9, splitting into a number of smaller teams may be a better option, although this in itself will introduce an overhead to manage the various teams.

24.11.8.3.1. Larger teams (SDTs) can be subdivided into smaller teams if the products can be split accordingly.

24.11.9. 9. Supportive commercial relationship

24.11.9.1. Where the supplier and the customer are from different organisations and development is covered by formal contract or where Solution Developers are from the same organisation but working within a service level agreement, the relationship must accommodate the evolution of the solution's requirements without imposing onerous change management overheads.

25. AgilePM® Foundation exam prep questions

25.1. http://miroslawdabrowski.com/downloads/AgilePM/Exam%20prep%20questions/

26. Watch: official AgilePM® introduction video (by Keith Richards)