A few flavors for Agile project management methodsApril 12, 2021
Sign up and try it out for free!Sign Up For Free
In the early 1990s Kent Beck was hired as a consultant for the Chrysler car company to improve the Chrysler Comprehensive Compensation System (C3) payroll project. At the time, the software industry was facing a small crisis in the fact that traditional waterfall project management for software development had large lead times, and projects had little to no room for mid development changes. Beck’s introduction of Extreme Programming started a project management movement toward what we know as Agile Project Management. In 2001, Beck and 16 other members of the software community got together and drafted what we now know as the Agile Manifesto. Today there are at least 50 different variants or methods of agile management.
Agile management requires 4 core principles that include:
- individuals and interactions over processes and tools;
- working software over comprehensive documentation;
- End user / client collaboration over contract negotiation;
- responding to change vs holding firmly to a plan.
To understand Agile project management, you need to be familiar with where we came from – Waterfall project management. Waterfall offers a less flexible, almost rigid approach to guiding a project. It handles a project in predetermined “phases” with little room for iteration from the original project plan. Projects are built to plan regardless of what happens around them during that process, internally (staff / resources) or externally (client / market), and QA is the last step to shipping – not an ongoing practice.
Agile project management is vastly different from the Waterfall method, breaking projects into smaller “sprints” that are open to adjustment by the manager or client as needs or outcomes change. Agile focuses far more on addressing what we know now in a project versus what we may have decided months ago. From a client retention perspective, it gives clients far more ad hoc input toward a project or build, can pivot easier to new conditions, or demands, and makes cash flowing a project more manageable for a client paying by sprints rather than 50% upfront on an entire project.
Now there are over 50 different approaches to agile management. This article will touch on 4 popular methods that have manifested from the origins of agile project management.
5 Principles for (Agile) Software Development that improve Agility:
- Just in Time Design & coding;
- Think, write, test, refactor;
- Unit testing & QA;
- Write Object-Oriented code (OO), not procedural code;
- Apply Agile Design Patterns and Principles.
Agile management and extreme programming
Extreme programming was an early concept introduced by Kent Beck at Chrysler but was soon adopted by organizations such as IBM. Its essence is the inclusion of on-going internal and user-driven testing mid build, code refactoring to reflect needed changes, paired programming, and collective ownership over the project by all main team members.
For those unfamiliar with ‘paired programming’ it is, in simplest terms, one software developer programming source code while a support developer sits over their shoulder offering oversight and advice. Over the course of the build, pairs will swap back and forth to complete the build.
The clear drawbacks to extreme programming are that it demands heavier human resources to produce a project, and it can take a longer build time. However, its growing popularity speaks to its advantages such as far better oversight by four eyes instead of two, with on-going room for project improvements. The outcome is a software product with far fewer bugs or UX issues.
The scrum method of agile project management
Scrum project management has become increasingly popular in guiding more complex product builds. Scrum teams are traditionally composed of a Product Owner, a Scrum Master, and a product development team. Ideal scrum teams are compact, co-located, and follow the two-pizza maxim coined by Jeff Bezos. Your team should not be so big it cannot share two pizzas.
Scrum team management tries to foster an environment that encourages inner learnings and the exchange of on-going project information across project members. Scrum projects are often built into 2-week sprints, or a Sprint Cycle, with specific planning and meeting stages within the framework.
As mentioned above, projects are executed over multiple sprints. But in the very beginning a Product Owner and Scrum Master must address Sprint Planning – essentially, the main outputs and outcomes of the project in the form of brand, context, UX, and product features for an intended audience.
Sprint planning forms a project’s Product Backlog, or the grocery list of what is needed for project completion. A Product Backlog is then broken down and prioritized into what can be accomplished within a sprint. This smaller list of required tasks makes up a Sprint Backlog.
Sprint Backlogs are referred to over the life of a sprint during Daily Scrums (standups) where a team gets together and has honest discussions about what is being done in the moment of the project, what is still needed, what unknowns have appeared (software bugs), and “blockers” prevent the team from carrying out a task. These team exchanges proactively reprioritizing the Sprint Backlog to reflect the current needs for the sprint to be successful.
Upon a sprint being concluded, there is a Sprint Review meeting with all team members where the ‘increment’ or output can be demonstrated as complete. This is a milestone meeting where stakeholders discuss with the development team the good and bad of the current output and whether it will satisfy the needed outcomes, and what will be required from the team in the next sprint.
Sprint Retrospective meetings are held immediately after a Sprint Review but only focus on the team’s development process, communication, positives, and negatives in producing the sprint. This should be a more brief meeting than a Review, but is important in helping the team become more efficient in working together.
The following are a few very popular scrum project management tools currently on the market:
- monday.com – Best Scrum tool for automations and integrations
- Wrike – Best scrum tool for teams of all sizes
- Scrumfast – Best scrum tool for intuitive UI and UX
- MeisterTask – Best Scrum tool for beginners
- Nutcache – Best Scrum tool for managing time, expenses, and billing
- Jira – Best Scrum tool software for software engineering and testing
Kanban and visual production management
Kanban is a very popular visual approach to product development originating in Japan and translates to billboard or sign board. Developed by Toyota in the 1940s, it was a physical post-it note system supporting just-in-time production. Producing products such as vehicles on-demand requires that manufacturing be nimble to the flux of requested production.
A visual layout of a Kanban is made up of “Requested”, “In Progress”, and “Done”. In its nature, Kanban is intended to be integrated with existing systems, as a supplemental tool that overlays your current operation with the intent of creating incremental change over time rather than shocking the current system. It also strongly encourages that leadership qualities be pursued, expected, and respected from all levels of the team, not solely management.
When executing the Kanban method there are several elements that come into play. First, you need some type of physical board or digital board service to place your task items, issues, and needs into a visual workflow. It’s important to control your In Progress hopper, not to overload it with request items. Your Work-In-Progress (WIP) should have some degree of limits on what can be effectively done within a restricted project timeline. Kanban also places heavy emphasis on managing production flow rather than micromanaging the team. It also ensures that production methods and goals are clear to the team. This clarity will gain buy-in and confidence from the team working on the project and will free up management resources allowing teams to move faster through the scheduled work. Finally, there needs to be a solid feedback loop that team members can flex in addressing concerns and bottlenecks in the build process.
Crystal agile management for all shapes and sizes
The Crystal agile method to project management was created by Alistair Cockburn while working on a software development framework at IBM in the 1990s. Cockburn found that teams, depending on their skills and size, behaved differently in their efficiency in completing projects, as well as the needs they had for reaching optimum performance.
He broke the team segments into colours as follows:
- Crystal clear – Teams with less than 8 people
- Crystal yellow – Teams with between 10 and 20 people
- Crystal orange – Teams with between 20-50 people
- Crystal red – Teams with between 50-100 people
The principles of Crystal agile management are fairly direct:
- Ship code / product to real users as it is produced and tested. This avoids producing unwanted products or features;
- Constant reflection on the process of project production – is this working for us?;
- Have team members working under the same roof to facilitate seamless sharing of project information, or osmotic communication;
- No bad ideas. No bad questions. No fear by team members to engage one another or management;
- Provide a clear path of work and expected goals or milestones for team members;
- Access by project team members to on-going feedback from the intended end-user.