Agile Principles and Mindset - Part 2
As discussed in Part 1, the agile methodology provides guiding values and principles for today's project teams working through empirical processes. An agile mindset allows its practitioners to adapt to unexpected obstacles by providing a framework for what aspects of the project to direct focus, emphasis, and consideration.
This part will look at the most popular agile methodologies, including their key concepts, teams, activities, and deliverables. Many of these techniques incorporate iterative and incremental approaches that are often appropriate for ever-changing knowledge-based work. The methods generally emphasize:
Short feedback loops
Frequent adaptation processes
Reprioritization
Regularly updated plans
Frequent delivery
Scrum
Scrum uses the scrum framework methodology and includes a set of practices, roles and responsibilities, events, artifacts, and rules. Scrum is a popular agile model that bases itself on three pillars:
Transparency: Giving visibility to those responsible for the outcome. An example is a shared understanding of the Definition of Done (DOD).
Inspection: This involves timely checks of how well the team progresses toward its goals, quickly identifying issues or differences from the plans.
Adaptation: This involves adjusting the team's process to minimize further issues if an inspection shows a problem or undesirable trend.
In addition to the pillars, Scrum recognizes five fundamental values - focus, courage, openness, commitment, and respect.
Sprints
A sprint is a timeboxed iteration (typically lasting one to four weeks) where the team works on a potentially releasable product. During a sprint, no changes are made that would impact the goal of the sprint. A sprint's cancellation, determined by the product owner, may occur if a change in the product goals makes the sprint goals obsolete. If cancellation of a sprint occurs, the remaining work items are returned to the product backlog and reevaluated.
Scrum Team Roles
Development Team. A group responsible for understanding the business requirements specified by the Product Owner, estimating user stories, and working toward the project deliverables. Development Teams are cross-functional and self-organizing. The team decides the amount of work to commit to in a Sprint and determines the best way to perform the work. The Scrum Team consists of cross-functional team members who carry out all the work involved in creating potentially shippable Deliverables, including development, testing, and quality assurance.
Product Owner. The Product Owner represents the voice of the customer. This person is responsible for achieving maximum business value for the project, articulating customer requirements, and maintaining business justification.
Scrum Master. The scrum master acts as a facilitator who ensures that the development team operates in an environment helpful to completing the project successfully. The Scrum Master guides, facilitates, and teaches Scrum practices to everyone involved in the project, clears impediments for the team, and successfully executes the Scrum processes.
Scrum Activities
Backlog Refinement. Everyone involved in the project discusses and updates the backlog items to ensure a shared understanding of project requirements and expectations.
Sprint Planning. This meeting determines what the team will work on for the upcoming sprint. The sprint team works to understand the items in the backlog and communicates feasibility with the product owner, and both groups work together to define a sprint goal.
Daily Scrum. A timeboxed meeting that takes place at the same time every day during the sprint. Each development team member answers the questions that follow to synchronize efforts and increase transparency for the team:
What did I work on yesterday?
What will I work on today?
Is there anything hindering my work?
Sprint Review. A meeting at the end of a sprint showcases the work and progress made throughout the sprint. The product owner reviews the work deciding if it satisfies business requirements.
Sprint Retrospective. After Sprint Review, but before the next sprint planning, the team takes time to reflect on the sprint and discusses:
What went well?
What did not go so well?
What can we do differently next time?
Scrum Artifacts
Product Increment. The product increment is the agreed-upon work discussed during sprint planning and executed during the sprint by the development team. These are demonstrated and approved by the product owner during the sprint review meeting.
Product Backlog. A prioritized list of all the work to complete the product. This list changes throughout the project and serves as the single source for all the product requirements.
Sprint Backlog. The development team maintains a subset of items from the product backlog.
Extreme Programming (XP)
While Scrum supplies tools, techniques, and processes tailored at the project management level, the XP method focuses on best practices for software development. XP has five core values:
Simplicity - reduce complexity, extra features, and waste. Find the simplest thing that could work.
Communication - Ensure the team understands expectations.
Feedback - This should be early and often and serves as an opportunity to improve the project.
Courage - Programmers feel comfortable sharing and correcting each other's code.
Respect - Everyone is responsible for the success/failure of the project.
Teams that utilize XP base their requirements around "user stories," describing the features and interactions that end-users can expect in the final product.
XP Team Roles
Coach. This role is similar to the Scrum Master in the Scrum methodology. They guide and keep the team on track while helping them become more effective and removing obstacles.
Customer. This role is similar to the Product Owner in the Scrum methodology. This role represents the business and outlines the project's requirements, priorities, and direction.
Programmer. This role works on the outlined tasks and user stories by writing and implementing code.
Tester. This role provides QA and helps the customer define and write acceptance tests for the user stories. Programmers can also fill this role.
XP Core Practices
Whole Team.
XP team members are collocated.
Generalizing specialist, not role specialist
Efficient sharing of information
Planning Games.
Planning activities
Release planning is the release of new functionality
Iteration planning is similar to sprint planning
Small Releases.
Minor releases introduced into the testing environment
Increases visibility to customer
Helps to deploy functionality to the end-user
Customer Tests.
Definition of the required functionality
One or more test criteria for the software to be working
Collective Code Ownership.
Any pair of developers can improve or amend the code.
Multiple people will work on all the code
Improve defect resolution in discovery
Knowledge is shared, not isolated
Code Standards.
A code standard is defined and adhered to by the team to provide consistency throughout the project.
Sustainable Pace.
Optimize productivity by providing a sustainable pace.
Consistent overtime and long hours are not sustainable.
Metaphor.
Metaphors and similes are used to explain designs.
Metaphors help communicate the software to the customer
Continuous Integration.
Compiling the code frequently throughout the day
Programmer check-in code to the code repository
Integration test run automatically for immediate feedback
Test-Driven Development.
Acceptance tests are written before developing new code
When the code has been written correctly, it will pass the test
Refactoring.
Cleaning up the code
Removing duplicated code
Lowering coupling
Increasing cohesion
Simple Design.
What is the simplest thing that we can do?
Simple does not mean easy.
Simple design is a risk mitigation approach
Pair Programming.
One person writes the code during the second review the code
The two people change roles frequently
The pair will catch each other's mistakes
Lean Product Development
While not technically an agile methodology, the lean approach is very similar. Originating from the Toyota Production System as a manufacturing framework, it was applied to software development and, eventually, other types of knowledge work. The high-level lean principles of product development are:
Using visual management tools
Identifying customer-defined value
Building in learning and continuous improvement
Lean centers on seven core concepts:
Eliminate waste
Empower the team
Deliver fast
Optimize the whole
Build quality in
Defer decisions
Amplify learning
The primary focus of lean is to eliminate waste. Lean experts Mary and Tom Poppendieck have outlined seven wastes that can be associated with knowledge-based work and include:
Partially done work
Extra processes
Extra features
Task switching
Waiting
Motion
Defects
Kanban
The Kanban method, developed by Toyota, is a Japanese word that translates to "signboard." It organizes work tasks in defined states and illustrates the natural progression of that work from "identified but have yet to start" (ToDo) to "work is complete" (Done). The agile team can tailor the different states but typically organize themselves into "ToDo," "In Progress," and "Done." Tasks on a Kanban board move from left to right, signifying the progress of the work. Moving tasks utilize Kanban's "Pull System," which specifies that the team should pull in the following item they intend to work on next when a task is complete.
Another mechanic that might be useful to agile teams working with Kanban is WIP limits. Introducing limits on tasks in production can increase the team's productivity.
The Kanban method has five core principles:
Visualize the workflow.
Limit WIP (work in progress).
Manage flow.
Make process policies explicit.
Improve collaboratively.
Feature-Driven Development (FDD)
Feature-driven development is an approach for building out products or solutions. Like the Work Breakdown Structure (WBS) in traditional project management, the team identifies the overall product model and seeks to break down the complexity by identifying the work involved.
The team will build a feature list and a plan for the work and execute the work through the design and build iterations. Feature-driven development prescribes a set of practices taken from software engineering and includes:
Domain object modeling: The team begins to identify the business requirements and context for the problem to be solved.
Developing by feature: Identify related work components and group them as features.
Individual class (code) ownership: Unlike XP, the practice advocates for a single owner when dealing with code areas.
Feature teams: Small, dynamically formed teams discuss and select designs and help reduce risks associated with individual ownership.
Inspections: Reviews help ensure quality design and code.
Configuration management: Tracking changes to design and code repositories.
Regular builds: The team can demonstrate features via code integrations.
Visibility of progress and results: Provide visibility on progress made by demonstrating work completed.
Dynamic Systems Development Method (DSDM)
DSDM, one of the earlier agile methods, covers many aspects of the project life cycle, from business cases to implementation. DSDM influenced agile development by popularizing early architectural considerations and agile contracts. DSDM focuses on eight principles as outlined below:
Focus on the business need
Deliver on time
Collaborate
Never compromise quality
Build incrementally from firm foundations
Develop iteratively
Communicate continuously and clearly
Demonstrate control
Crystal
The Crystal methodology addresses that each project may require a slightly tailored set of policies, practices, and processes to meet the project's unique characteristics. Factors influencing a team's customized approach include the criticality of an introduced product defect or a team's size. The various factors and their severity or scope relate to different categorized colored names that signify increased complexity, such as Crystal Clear (low complexity) or Crystal Magenta (high complexity). This methodology reminds us that the tools and techniques used by an agile team might need to be adjusted to accommodate the project environment.
While new to agile teams might stick to only one methodology, it is essential to note that many teams tailor their processes to a form of agile that works for them. In general, there are two strategies to fulfill agile values and principles:
Adopt a formal agile approach, designed and proven to achieve the desired results.
Implement changes to project practices that fit the project context to achieve progress on a core value or principle.
While tailoring processes can be effective and productive, risk is involved. The team can mitigate these risks by:
Get used to the standard, out-of-the-box agile before attempting to change it.
Carefully examine the motivation to drop, amend, or append a practice.
Related
