Agile Teams, Work Environment & Scrum Overview

1. Collectively responsible

   Nota:

   • The entire team will be collectively responible for the success & failure of an agile project
2. no individual should be blamed

   Nota:

   • no individual should be blamed for project failure

Nota:

• An Agile team does not differentiate between traditional roles such as "developer" "analyst" and "tester" Since the entire team is accountable for outcome, everyone in the project will do what is needed to complete the project.   e.g. a developer can perform activities at various time such as clarigy needs with stakeholders, write code, and test code. 
• Does not mean not to have the primary expertise.  But they should not be constrained to their primary role, but should be cross trained to perform different tasks in an Agile project

Nota:

• The team should be cross-functional: - incl: capability to perform all tasks needed to complete the agile.  - includes both technical capabilities (setup infrastructure, design, code, test) and business capabilities (domain knowledge, decision making).

1. Fewer narrowly focused specialists
2. More "generalizing specialist"
3. Multi-disciplinary / cross-functional developers
   1. One or more technical specialties
   2. General knowledge of software or systems development
   3. General knowledge of business domain
   4. Actively seek to gain new skills
4. Advantages
   1. Improved communication & collaboration
   2. Less internal project documentation
   3. Improved flexibility
   4. Less project risk as u're not as reliant on specialists

Nota:

• The people who do the work are best suited to organize how they're going to do the work

1. Command and control approach
   1. Manager assigns work to people
2. Self organization approach
   1. The team is responsible for self-management
   2. The team estimate the size and complexity of the work
   3. The team determines the technical solution
   4. The team commits to the work they can do in a time box
   5. The team is responsible for product delivery
   6. The team is responsible for product quality
   7. The team is responsible for product quality
   8. The team is continuously commited to finding ways improve

1. Core ROles
   1. Stakeholder

      Nota:

      • people who has an interest in the project.  THey will affect a project and /or be affected by the project in some way, shape or form
      • Stakeholders typically include: end user business managers project sponsors operations staff support staff consultants development team (excluded agile development team
      • Stakeholders often have conflicting views of what system should do
   2. Team Lead

      Nota:

      • responsible for the success of the project and for employing the process to build a system or product
      • also called team coach / scrum master
      1. At project initiation

         Nota:

         • - Estabilhes the right team and product owner - Facilitates creation and evolution of the work item list - Facilities creation and evolution of a release plan - Facilitates iteration planning
      2. Daily

         Nota:

         • - Conducts Daily Stand-up meeting - Remove impediments - gauge progress - steer the team
      3. Plans & conduct interation review
   3. Product Owner

      Nota:

      • Existing Business Analysts often transition into this role
      1. defines and promotes the vision, goals and capabilities of the product to team can make decisions
      2. Ultimately responsible for the value of the end product
      3. Owns the product Backlog / work Item List and defines acceptance criteria for work items
      4. determinss the scope / content of the release (release planning)
      5. Defines acceptance criteria for the release and determines when the system is ready for release
   4. Team Member

      Nota:

      • Everyone else on the team
      • Often referred to as "developer"
      • cross-functional, collaborative, self-managed
      • Mandatory participation in the Daily stand -Up Meeting
      • Provides "relative size" estimates for items in the product backlog
      • Actively involved with interatin planning
      • Maintain the iteration backlog and / or taskboard
      • Update "work remaining" estimate daily
2. Additional Roles
   1. Architecture Owner

      Nota:

      • Responsible for teh architecture of the system or subsystems that the team is working on
      • Mentors and guides the developers in architectural issues, and leads them through technical issues
      • Understands the architectural direction and standards of their organization and helps to ensure that the team adheres to them appropriately
      • Not solely responsible for the architecture, but is the technical leader of the team
      • Has the final say regarding technical decisions, but tries to avoid ditacting the architectural direction in favour of a collaborative, team-based approach
   2. Domain Expert

      Nota:

      • Has detailed knowledge about one or more aspects of teh problem domain
   3. Technical Expert

      Nota:

      • has detailed technical knowledge needed
   4. Independent tester

      Nota:

      • Focuses on complex testing efforts, working parallel but independent of the team
   5. Integrator

      Nota:

      • Responsible for building the entire system from its various subsystems
   6. Specialist

      Nota:

      • Sometimes component subteams require people focused on narrow specialties

1. Removes distractions & increases focus on business mission
2. Reduces communications and interactions to minutes
3. Speeds decision-aking, issue resolution, produce development
4. Increases clarity and understanding and reduces surprises
5. Fosters teaming

   Nota:

   • e.g. 
6. Effective knowledge sharing
   1. Tacit Knowledge

      Nota:

      • Overheard Corridor chats Pair programming
   2. Document Knowledge

      Nota:

      • Formal not complete
7. Tackles common decelerators head on

   Nota:

   • e.g. requirements clarity, high chrun, getting right people at right time
8. Enables other key mechanisms

   Nota:

   • alignmnet of business and I/T, timebox focus, prototyping

Nota:

• A time-boxed milestone that teams use to measure project progress, based on working software increments
• A sprint is typically 2 - 4 weeks.  But it is agreed by the team and shorter / longer sprints are possible.

1. Sprint Planning Meeting
   1. Before the meeting

      Nota:

      • Product owner develops the vision and translates it into product backlog
      • The Product Owner orders the Product Backlog
      • The development Team with the support of teh Product Owner estimate the relative size of the each product backlog item
   2. During the meeting

      Nota:

      • The Developmnet Team determines its available capacity and Velocity (Velocity = number of pts completed in previous sprint)
      • The Agile Team collaborates on the development of a plan for the work to be performed during the upcoming Sprint
      • The Agile Team estimates the points per user story, and breaks down user stories into smaller tasks with effort estimates
   3. After the meeting

      Nota:

      • The Agile team begins work on the Sprit
2. Sprint Backlog
3. Daily Scrum
4. Sprint Review
5. Sprint Retrospective