How to Agile
Agile like 18f.gsa.gov
If you’re like me you grew as a software developer alongside a novel style of development called agile. I have picked up what I know about agile from reading many blog posts, a few books, and for the last 18 years, being a part of software development teams that attempted, with varying degrees of dedication and success, to be agile. In this time I’ve performed many of the roles, and have learned from many mistakes. It is time for me to document my thoughts on agile development. The only issue is, my thoughts are in agrement with what 18F has already documented, officially, for the United States Government. The below is merely a repost from https://agile.18f.gov/agile-fundamentals/.
Standups: the team meets daily for short meetings which are typically held standing up, face-to-face to encourage brief sessions. This is not a status meeting. This meeting is for people to ask quick questions that will allow them to get information or remove blockers. Long answers and discussions should have follow-up in smaller groups after the standup meeting.
Retrospectives: on a regular basis, at end of each sprint, weekly or bi-weekly, a retrospective allows for the team to reflect and adjust practices. Any team member can voice a problem or propose a solution
Sprints are the heartbeat of the agile process. Small units of work are delivered in short bursts, typically with 1 or 2 week cycles. We aim for visible progress for people from the target audience that is delivered and validated at the end of each cycle, allowing the team to move iteratively toward the goal, with regular opportunity for course correction.
Sprint planning: include the whole team in reviewing stories, breaking down use cases into small user-facing stories
Sprint Review: A ceremony at the end of each sprint when completed stories are demonstrated to team, stakeholders, and users.
Backlog Refinement: An ongoing team activity of collaboratively updating the Product Backlog via reprioritization, adding/deleting/rewriting stories, splitting, and estimating. This practice ensures that the backlog is always actionable. (Note: This practice was formerly known as “grooming”, which term is out of favor.)
Transparency: The idea that information should be shared freely within and between all Agile teams, projects, and stakeholders.
Iteration (Inspect and Adapt): A problem-solving and development approach that solves large problems by decomposing them into smaller, discrete problems which are each easier to solve, then solving the smaller problems. As each smaller problem is solved, new information is uncovered (Inspect) and decisions can be made and re-made based on the new information (Adapt).
Potentially Shippable Product Increment: In Agile software development, a fully tested and usable version of a product that is produced at the end of each sprint.
Self-organizing Teams with Empowered Product Owners: Agile teams are composed of peers who share ownership of the team’s work and decision-making processes. Self-organizing teams in Scrum are given ownership of their work process, their commitments, and their approach to meeting their commitments. Product Owner is the role in Scrum that represents the business and customer directly within the development team. The Product Owner must be empowered to make product decisions in response to feedback from stakeholders and customers. Taken together, a Scrum team has complete control over how it does its work and what work it does.
comments powered by Disqus