[PMI - ACP] Chapter I. Agile Principle And Mindset

 

1. Key topic

• Agile frameworks and terminology
• Agile Manifesto (4 values, 12 principles)
• Agile methods and approaches
• Agile process overview
• Scrum (Activities, Artifacts, Team roles)
• XP (Core practices, Core values, Team roles)
• Lean (7 Core concepts , 7 wastes)
• Kanban (5 principles, Pull system, WIP limits)
• Leadership practices and principles (Management vs Leadership, Servant leadership(4 duties))

2. Why Agile?

When knowledge work projects became more common, people found that the communication and collaboration involved in these projects made the work more uncertain and less definable than industrial work. Agile method were developed in response to this problem.

3. Core Agile principle

• Welcoming change
• Working in small value-added increments
• Using build and feedback loop
• Learning through discovery
• Value-driven development
• Failing fast with learning
• Continuous delivery
• Continuous improvement

If one team in the organization adopts agile principles and practices, it can help the team members become more effective at delivering their project work. However, they will feel inhibited or misunderstood by other groups or systems in the organization, such as the project management office (PMO) or functional silos.

If the entire organization adopts the agile way of thinking, then everyone will be working together to improve agility and the delivery of value. By adopting common goals and values, such as continuous improvement and welcoming change, everyone’s effectiveness will be enhanced.

4. The four value

Individuals and interactions over process and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

The format is A over B, we should intention A than B instead “Do A instead of B”.

5. The twelve principle

• Principle 1 - Satisfy customer with great system: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Principle 2 - Welcome change: Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
• Principle 3 - Deliver frequently: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
• Principle 4 - Work with business: Business people and developers must work together daily throughout the project.
• Principle 5 - Motivate people: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
• Principle 6 - Face to face conversation: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• Principle 7 - Working software: Working software is the primary measure of progress.
• Principle 8 - Sustainable development: Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
• Principle 9 - Excellent Technical and design: Continuous attention to technical excellence and good design enhances agility.
• Principle 10 - Keep it simple: Simplicity - the art of maximizing the amount of work not done - is essential.
• Principle 11 - Self-organizing make the best design: The best architectures, requirements, and designs emerge from self-organizing teams.
• Principle 12 - Retrospective regular: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

6. Scrum

Scrum Pillar and Value

» Transparency: This involves giving visibility to those responsible for the outcome. An example of transparency would be creating a common definition of what “done” means, to ensure that all stakeholders are in agreement. » Inspection: This involves doing timely checks of how well the project is progressing toward its goals, looking for problematic deviations or differences from the goals. » Adaptation: This involves adjusting the team’s process to minimize further issues if an inspection shows a problem or undesirable trend.

Scrum process

Sprints

A sprint is a time boxed (time-limited) iteration of one month or less in which the team builds a potentially releasable product. Most Scrum sprints are one or two weeks long.

During a sprint, no changes are made that would affect the sprint goal. Only the product owner can cancel the sprint for adapt sprint goal.

Scrum Team Roles

• Development Team: The development team is the group of professionals who build the product increments in each sprint (design, analysis, dev, test, deploy).
• Product Owner: The product owner is responsible for maximizing the value of the product by managing the product backlog, or list of work to be done.
• ScrumMaster: The ScrumMaster is responsible for ensuring that the Scrum methodology is understood and used effectively. This person is a servant leader to the development team, removing any impediments to their progress, facilitating their events (meetings), and coaching the team members.

Scrum Activities (Event, Ceremonies)

• Backlog Refinement: This basically means that everyone involved in the project gathers to discuss and update the items in the backlog.

• Sprint Planning Meeting: Everyone gathers to determine what will be delivered in the upcoming sprint and how that work will be achieved.

• Daily Scrum: The daily scrum is a 15-minute time boxed meeting that is held at the same time and place every day while the team is working toward the sprint goal. Each member answer 3 questions:

  • What have I done since the last daily scrum?
  • What do I plan to do today?
  • Are there any impediments to my progress?
  
  
  

  
  

  Scrum of scrums for bigger team. The scrum masters can meet twice a week.

• Sprint Review: The sprint review meeting is held at the end of the sprint and includes the development team, the product owner, and the ScrumMaster. In this meeting, the team demos the increment, or evolving product, that they built in the sprint to the product owner. The product owner inspects the work to see whether it is acceptable - deciding if it is “done” or explaining what is missing. The team and the product owner discuss the increment and the remaining items in the product backlog. Together, they make any changes needed to the backlog and decide what to work on next.

• Sprint Retrospective: After the sprint review, but before the next sprint planning meeting, the development team holds their final “inspect and adapt” activity for the sprint— the sprint retrospective.

Scrum Artifacts:

• Product Increment: During each sprint, the members of the development team build an increment of the solution
• Product Backlog: The product backlog is a prioritized list of all the work that needs to be done to build the product - it serves as the single source for all the product requirements.
• Sprint Backlog: The sprint backlog is the subset of items in the product backlog that have been selected as the goal of a specific sprint.

7. XP

Extreme Programming - commonly referred to as “XP” based on the initials eXtreme Programming - is an agile method that is focused on software development. While Scrum focuses at the project management level on prioritizing work and getting feedback, XP focuses on software development best practices.

XP core value

• Simplicity
• Communication
• Feedback
• Courage
• Respect

XP Team Roles

• Coach: The coach acts as a mentor to the team, guiding the process and helping the team members stay on track.The coach is also a facilitator— helping the team become more effective— and a conduit, reinforcing communication both within the team and across teams. This role is similar to the Scrum master role in Scrum.
• Customer: On an XP team the “customer” is the business representative who provides the requirements, priorities, and business direction for the project. This role is similar to Product Owner in Scrum.
• Programers
• Tester

XP Core Practices

Whole Team: The whole team practice is the idea that all the contributors to an XP project sit together in the same location, as members of a single team.

Planning Games: XP has two primary planning activities, or planning games— release planning and iteration planning. A project typically has one or more releases, with no more than one or two releases in a single year.

Small Releases: Frequent, small releases to a test environment are encouraged in XP, both at the iteration level.

Customer Tests: The customer describes one or more test criteria that will indicate that the software is working as intended. The team then builds automated tests to prove to themselves and the customer that the software has met those criteria.

Collective Code Ownership: This means multiple people will work on all the code, which results in increased visibility and broader knowledge of the code base. This practice leads to a higher level of quality.

Code Standards: XP teams follow a consistent coding standard.

Sustainable Pace: XP recognizes that the highest level of productivity is achieved by a team operating at a sustainable pace.

Metaphor: XP uses metaphors and similes to explain designs and create a shared technical vision. These descriptions establish comparisons that all the stakeholders can understand to help explain how the system should work. For example, “The billing module is like an accountant who makes sure transactions are entered into the appropriate accounts and balances are created.”

Continuous Integration: which means every time a programmer checks in code to the code repository (typically several times a day), integration tests are run automatically.

Test-Driven Development: To ensure good test coverage so that problems can be highlighted early in development, XP teams often use the practice of test-driven development.

Refactoring: Refactoring is the process of improving the design of existing code without altering its external behavior or adding new functionality.

Simple Design: By focusing on keeping the design simple but adequate. XP follows a deliberate design philosophy that asks, “What is the simplest thing that could work?”

Pair Programming: While one person writes the code, the other developer reviews the code as it is being written— and the two change roles frequently.

8. Lean

Lean is not an agile methodology; however, the lean approach is closely aligned with agile.

The high-level principles of lean product development include:

» Using visual management tools » Identifying customer-defined value » Building in learning and continuous improvement

Seven Lean Core Concepts

Eliminate waste: To maximize value, we must minimize waste.

Empower the team: Rather than taking a micromanagement approach, we should respect the team members’ superior knowledge of the technical steps required on the project and let them make local decisions to be productive and successful.

Deliver fast: We can maximize the project’s return on investment (ROl) by quickly producing valuable deliverables and iterating through designs.

Optimize the whole: As part of optimizing the whole, we also focus on forming better intergroup relations

Build quality in: Lean development doesn’t try to “test in” quality at the end; instead, we build quality into the product and continually assure quality throughout the development process, using techniques like refactoring, continuous integration, and unit testing.

Defer decisions: We balance early planning with making decisions and commitments as late as possible.

Amplify learning: This concept involves facilitating communication early and often, getting feedback as soon as possible, and building on what we learn.

7 Lean waste

9. Kanban

“Kanban” is a Japanese word meaning “signboard.”

Five Principles of Kanban

• Visualize the workflow: Knowledge work projects, by definition, manipulate knowledge, which is intangible and invisible
• Limit WIP (work in progress): Restricting the amount of work in progress improves productivity, increases the visibility of issues and bottlenecks, and facilitates continuous improvement.
• Manage flow: By tracking the flow of work through a system, issues can be identified and changes can be measured for effectiveness.
• Make process policies explicit: It is important to clearly explain how things work so the team can have open discussions about improvements in an objective, rather than an emotional or subjective, way.
• Improve collaboratively: Through scientific measurement and experimentation, the team should collectively own and improve the processes it uses.

Pull system

Each time a Kanban team completes an item of work, it triggers a “pull” to bring in the next item they will work on.

WIP Limits in Kanban

Once the limit at the top of a column is reached, no new items maybe moved into that column until another item is moved out. Why is limiting WIP so important? The reason is that lowering WIP actually increases a teams productivity— it speeds up the rate at which the work is completed.

10. Agile Process Overview

11. Agile Leadership

Agile is more humanistic than mechanistic, as evidenced by the agile value of “Individuals and interactions over processes and tools.” To be effective leaders, we need to discover why team members want to do things, understand what motivates them, and then align their project tasks and goals accordingly. It is by aligning project objectives with personal objectives that we can get higher levels of productivity.

Leadership versus Management

The leadership techniques employed on agile projects involve taking an interpersonal approach, rather than directing, command-and-control methods. “Management is getting people to do what needs to be done. Leadership is getting people to want to do what needs to be done.”

Refer: Printing PMI ACP Exam