Get Started. It's Free
or sign up with your email address
Rocket clouds
Agile Foundation (by Agile Consortium) by Mind Map: Agile Foundation (by Agile Consortium)

1. What is Agile NOT

1.1. Quick and dirty

1.2. Developers party time

1.3. Do what we like

1.4. A method

1.5. Pre-scriptive

1.6. No documentatiton

1.7. Part of the solution

2. Official website

2.1. http://www.certifytoinspire.org/

3. Customer and stakeholder involvement

3.1. Measure customer satisfaction

3.2. Identify and understand project stakeholders

3.3. Setup customer representatives to interact with the development team

3.4. Gather requirements using agile requirements techiques:

3.4.1. user stories

3.4.2. test cases

3.4.3. use cases

3.5. Handle and prioritize changes by interacting with customers

3.6. Engage the right people in decisions

4. Handling team dynamics

4.1. Celebrate small victories

4.2. Bring together the right team skills

4.3. Trust the team

4.4. Encourage individuals to self select tasks

4.5. Setup collaborative work environment

4.6. Create team working agreements

4.7. Preferably co-locate team members

4.8. Size the team based on estimated project effort

5. Prioritisation, planning and delivery

5.1. Establish clear purpose and scope (establish the project charter that gives the overall picture of the product and the business value)

5.2. Deliver running product at the end of each iteration

5.3. Deliver using features based rather than task based approach

5.4. Create and maintain release plans and iteration plans

5.5. Estimate at least one agile estimation technique

5.5.1. user story points

5.5.2. wide band delphi

5.5.3. yesterday's weather

5.5.4. planning poker

5.6. Fix the time, vary the scope

5.7. Prioritize requirements by business value and risk

5.8. Recognize the need to establish a technical environment that supports iterative and incremental delivery:

5.8.1. source control

5.8.2. infrastructure

5.8.3. automated testing

5.8.4. continuous integration

5.8.5. daily builds

6. Feedback and adaptation

6.1. Reflect periodically using a retrospective, introspective, or reflection workshop

6.2. Quick daily meetings

6.2.1. a.k.a. daily standups

6.2.2. a.k.a. washups

6.3. Establish feedback - daily and after each iteration

6.4. Measure and visibly communicate project velocity, plans, and progress

6.5. Converge on accurate requirements by demonstrating features

6.6. Adjust requirements and plans continuously throughout the project

6.7. Handle issues

7. Individual leadership style

7.1. Be aware of the following leadership behaviors:

7.1.1. innovative

7.1.2. strategic

7.1.3. excitement

7.1.4. tactical (immediate results)

7.1.5. communicative

7.1.6. delegation

7.1.7. production

7.1.8. consentual

7.2. Replace negotiation with collaboration

8. Leadership skills

8.1. Control vs facilitating the team

8.2. Tasking people vs self organizing

8.3. Use basic facilitation skills:

8.3.1. how to run a meeting

8.3.2. how to teach people

8.3.3. how to be in a meeting

8.3.4. decision making

8.3.5. team norms

8.3.6. etc.

9. Tailoring

9.1. Choose iteration length based on project characteristics

9.2. Recognize the need to assess and tailor process to project characteristics

10. Testing

10.1. User participation for checks

10.2. Continuous Testing (CT)

10.3. Testing against benefits (verification)

10.4. Automated testing

10.5. Test Driven Development (TDD)

11. This freeware, non-commercial mind map (aligned with the newest version of Agile Foundation qualification by Agile Consortium) was carefully hand crafted with passion and love for learning and constant improvement as well for promotion the Agile philosophy and as a learning tool for candidates wanting to gain Agile Foundation qualification. (please share, like and give feedback - your feedback and comments are my main motivation for further elaboration. THX!)

11.1. Questions / issues / errors? What do you think about my work? Your comments are highly appreciated. Please don't hesitate to contact me for :-) Mirosław Dąbrowski, Poland/Warsaw.

11.1.1. http://www.linkedin.com/in/miroslawdabrowski

11.1.2. https://www.google.com/+MiroslawDabrowski

11.1.3. https://play.spotify.com/user/miroslawdabrowski/

11.1.4. http://www.miroslawdabrowski.com

11.1.5. https://twitter.com/mirodabrowski

11.1.6. miroslaw_dabrowski

12. Agile Foundation is an entry level qualification developed and maintained by Agile Consortium (founded and held by co-author of Agile Manifesto - Arie van Bennekum)

12.1. Agile Consortium

12.1.1. http://www.agileconsortium.nl/

13. Roles and responsibilities

13.1. Legend

13.1.1. Orange

13.1.1.1. Business intrest roles representing the business view

13.1.1.2. Typically taken by business personnel

13.1.2. Blue

13.1.2.1. Management intrest roles representing the management / leadership view

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

13.1.3. Green

13.1.3.1. Technical intrest roles representing the technical view

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

13.1.4. Grey

13.1.4.1. Process intrest roles representing the process view

13.1.4.2. Facilitating the process aspects of the project

13.2. The team is:

13.2.1. Self-sufficient

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

13.2.2. Cross-functional

13.2.2.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.

13.2.3. Small (7 +/- 2)

13.2.3.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..

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

13.2.4. Autonomical

13.2.4.1. Yet SDTs do not work in a vacuum.

13.2.4.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.

13.2.4.3. External Autonomy

13.2.4.4. Internal Autonomy

13.2.4.5. Individual Autonomy

13.2.5. Accountable

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

13.2.6. Collaborative

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

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

13.2.7. Based on trust and respect

13.2.7.1. Trust but verify and then guide

13.2.8. Ideally static

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

13.2.8.1.1. Minimal to zero variations in team members (at least per Increment).

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

13.2.9. Ideally collocated

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

13.2.9.1.1. Body language

13.2.9.1.2. Informal face to face communication

13.2.9.2. Collocated mentally not only phisically.

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

13.3. Business Sponsor

13.3.1. Owns the business case

13.3.2. Ensures ongoing viability in line with the BC

13.3.3. Ensures funds and resources

13.3.4. Ensures decision making process for escalations

13.3.5. Responds rapidly

13.4. Business Visionary

13.4.1. Owns wider implications in business change

13.4.2. Defines business vision

13.4.3. Communicates and promotes vision

13.4.4. Monitors progress in line with the vision

13.4.5. Contributes to requirements, design and review sessions

13.4.6. Approves changes to high level requirements

13.4.7. Ensures collaboration across business areas

13.4.8. Ensures business resources

13.4.9. Promotes the vision into the working practice

13.4.10. Arbitrates in disagreements between team members

13.5. Project Manager

13.5.1. Communicates with senior management and project governance

13.5.2. Ensures high level planning

13.5.3. Monitors progress against baselined plans

13.5.4. Manages risks and issues, escalates when needed

13.5.5. Managing overall project configuration

13.5.6. Motivates and facilitates the team

13.5.7. Manages business involvement

13.5.8. Resources specialists when required

13.5.9. Handles problems escalating from the Solution Development Team

13.5.10. Coaches the SDT

13.6. Technical Coordinator

13.6.1. Agrees and controles technical architecture

13.6.2. Determines technical environment

13.6.3. Identifies and owns related risks, escalates when needed

13.6.4. Ensures NFR are achievable and met

13.6.5. Ensures adherence to technical standards and best practices

13.6.6. Controls technical configuration of the solution

13.6.7. Manages technical issues of go live

13.6.8. Resolves technical disputes

13.7. Solution Development Team (SDT)

13.7.1. Team Leader (Scrum Master)

13.7.1.1. Guides team to meet objectives

13.7.1.2. Escalates to PM

13.7.1.3. Plans, schedules and coordinates at the detailed level

13.7.2. Business Ambassador (Product Owner)

13.7.2.1. From the related business area

13.7.2.2. Provides business related information

13.7.2.3. Specifies, reviews and tests the evolving prototype

13.7.2.4. Promotes to the business area

13.7.3. Business Analyst

13.7.3.1. Fully integrated in the SDT

13.7.3.2. Bridges between business ad technique

13.7.3.3. Ensures business objectives are analysed and correctly reflected to the team

13.7.4. Solution Developer

13.7.4.1. Interprets requirments into a proper solution

13.7.4.2. Ensures both functionals and non-functionals

13.7.4.3. Ideally fully allocated to the project

13.7.4.4. The project is their number 1 priority

13.7.5. Solution Tester

13.7.5.1. Tests the evolving solution

13.7.5.2. Works according to the Technical Testing Strategy

13.7.5.3. Is fully integrated in the SDT

13.7.5.4. Assists Business Ambassadors in their reviews

13.7.6. Business Advisor

13.7.6.1. Often a peer of the Business Ambassador

13.7.6.2. Brings in very specific knowledge

13.7.6.3. Both in development and testing

13.7.7. Technical Advisor

13.7.7.1. Brings in very specific technical expertise

13.7.7.2. Supports often regarding to:

13.7.7.2.1. Requirements, design and review sessions

13.7.7.2.2. Operational perspective for day to day decisions

13.7.7.2.3. Operational acceptance testing

13.7.7.2.4. Development of support documentation

13.7.7.2.5. Training of operations and support staff

13.8. Supporting Roles

13.8.1. Workshop Facilitator (WF)

13.8.1.1. Independent from project team and client.

13.8.1.1.1. Independent of workshop outcome.

13.8.1.2. Managing the workshop process.

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

13.8.1.4. Catalyst for preparation and communication.

13.8.1.5. Responsibilities

13.8.1.5.1. For each workshop:

13.8.1.5.2. Engaging with participants to:

13.8.2. Agile Coach (AC)

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

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

13.8.2.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.

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

13.8.2.5. Responsibilities

13.8.2.5.1. Embedding the Agile framework.

13.8.2.5.2. Providing detailed knowledge and experience of Agile to inexperienced agile teams

13.8.2.5.3. Tailoring the Agile to suit the individual needs of the project and the environment in which the project is operating

13.8.2.5.4. Helping the team use Agile techniques and practices and helping those outside the team appreciate the Agile philosophy and value set

13.8.2.5.5. Helping the team work in the collaborative and cooperative way demanded by Agile and all agile approaches

13.8.2.5.6. Building Agile capability within the team

14. Techniques

14.1. Yesterday’s Weather

14.2. Test Driven Development (TDD)

14.3. Facilitated workshops

14.4. Iterating

14.5. Prototyping

14.6. MoSCoW

14.7. Timeboxing

14.8. Modelling

14.9. Testing

14.10. Lessons learned

15. The 8 habits of highy effective Agile people (Agilists)

15.1. 1. Heartbeat

15.1.1. face2face (F2F) end user participation for validation and verification

15.1.1.1. validation

15.1.1.2. verification

15.1.2. Brings acceptance and a match with the business

15.2. 2. Daily's

15.2.1. face2face group communication on progress and lessons learned

15.2.2. To have almost real time insight on where we are as a team

15.3. 3. Prototyping

15.3.1. Presenting real product to the customer / users

15.3.2. Common language from an early stages of the project

15.3.3. Brings understanding, quality and clarity

15.4. 4. Continuous testing

15.4.1. Continuous valutation of content and process through the project cycle

15.4.2. Brings quality, decreases re-work

15.5. 5. Timeboxes / Sprints

15.5.1. Short delivery cycles for regular checks and acceptance

15.5.2. Brings quality, decreases re-work

15.6. 6. MoSCoW

15.6.1. Continuous selection

15.6.2. Avoids project obesity and therefore brings quality

15.7. 7. Visual Management

15.7.1. a.k.a. Information Radiators

15.7.2. Group information visualized in the team are

15.7.3. To have all stakeholders informed at all times and avoid document redundancy

15.8. 8. Pair and Refactor

15.8.1. Write code for who comes after you, not for the computer

16. Agile Values (from Agile Manifesto)

16.1. Value individuals and interaction

16.1.1. ... over processes and tools

16.2. Value working solutions

16.2.1. ... over comprehensive documentation

16.3. Value customer collaboration

16.3.1. ... over contract negotiation

16.4. Value responding to change

16.4.1. ... over following a fixed plan

16.5. The Agile Manifesto and the principles are about interaction

16.5.1. Agile is an interaction concept

16.5.2. Applying Agile is about facilitating that The right people with different expertise act as 1 empowered team and talk at the right moment about the right content the right way

16.6. What is Agile?

16.6.1. An interaction concept

16.6.2. An umbrella expression covering multiple methods

16.6.3. A disciplined process

16.6.4. Full delivery

16.6.5. Creating organizational or business value

16.6.6. Do what the business needs

16.6.7. Exploring

17. The rationale for using Agile

17.1. Why many projects are percieved as not successful?

17.1.1. The solution does not deliver what the business needs

17.1.2. The solution has a lot of hindering errors

17.1.3. The solution has overall a poor performance

17.1.4. The solution is not accepted by the end user population

17.1.5. The solution is very difficult to maintain

17.1.6. The project runs over time and over budget

17.1.7. WHY? - Observations, the causes

17.1.7.1. No SMART objectives, no course

17.1.7.2. No selection, just growth

17.1.7.3. No end-user participation, no acceptance

17.1.7.4. No validation, lots of rework

17.1.7.5. No verification, no business value

17.2. It solves communication problems

17.3. It avoids a late or delayed ROI

17.3.1. shorter time to market

17.4. It delivers what the business wants / expects

17.5. It delivers what the business needs - based on increasing insight(s)

17.6. It avoids over-engineering

17.6.1. a.k.a. gold plating

17.7. It avoids unused features

17.7.1. a.k.a. fatware

17.8. The success factors of Agile development

17.8.1. Strong Foundations, to create a shared objective and working agreement

17.8.2. Focus on the core of agile to facilitate the HOW

17.8.3. Visual management to avoid redundant silo work

17.8.4. Documentation just enough because we need it

17.8.5. Size, skills and stability of the team

17.8.6. Vertical commitment, facilitate the team

17.8.7. Management commitment, to create a suitable platform

17.8.8. Synchronize all involved, to have a common language

17.8.9. Walk as you talk, to lead by example

17.8.10. Empower people, facilitate the process

17.8.11. Don’t invent the wheel, get a coach

17.8.12. Walk as you talk, role model as management