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