The only constant is change
The one thing that all agile development teams have in common is that they are all different. And not just different from one company to the next, but also from team to team within any given organisation. Obviously, this is largely due to the unique mixtures of skill sets and development experience within each team, and the varying objectives and requirements of the project they are working on.
But if you look even deeper than that, most truly agile development teams work quite differently at the end of a release compared to how they started out. This is due to the last — but certainly not the least — of the 12 principles behind the agile manifesto, which states:
At regular intervals, the team reflects on how to become more effective,
then tunes and adjusts its behavior accordingly.– 12th Principle, Agile Manifesto
What this means is that every team, if considered “agile”, is constantly improving. Constantly evolving. Constantly changing.
With flexibility comes agility
We all know that agile development teams are encouraged to value individuals and interactions over processes and tools. I think the main reason tools get a bad wrap is that most tools are traditionally rigid, forcing users to follow a particular process and leaving very little room for being “agile”.
I also think the main reason why GreenHopper for Jira is one of — if not the — most popular planning tools for agile teams is because it’s not rigid at all. In fact, it’s probably the most flexible agile project management tool available today.
For example, GreenHopper provides a template for Scrum teams to get started with all of the basics, but we know that no two teams are going to practise Scrum exactly alike. By your first retrospective, we know you’ll probably start tweaking things to suite your needs.
Top 5 “flexible” features
Since “flexibility” can be a vague buzz-word that nearly everyone claims to have, let me break down the top 5 “flexible” things that make GreenHopper truly agile:
- Configurable cards and fields – GreenHopper lets you create different card types to capture all of the things you are working on. Typically, this may include user stories, tasks and epics; however, you can set up cards for anything that belongs on your backlog, from bugs and feature requests to domestic chores.
Each colour-coded card can be configured to display any field of any type in any view. This flexibility provides limitless possibilities for managing your backlog, tracking your tasks and reporting on progress.
- Nested versions and statistics – GreenHopper lets you break up each release (aka Version) into iterations by creating any number of nested sub-versions. You can even create nested versions within iterations to further subdivide work. (The same “nested” concept also applies to components, too)
Each iteration rolls up all of the statistics for any numerical fields that the team wishes to track — typically, things like story points, business value or technical complexity — allowing you to set limits and markers measure capacity and assist with planning.
- Custom workflow – Configure the GreenHopper task board to map to your team’s workflow. Most teams start simple by displaying the cards on the backlog (“To Do”), in progress and done. As your workflow evolves over time, you may add more columns to indicate cards in QA, awaiting code review or any other state you care to track.
For teams doing Lean Development, you can create a Kanban board to map out every step of your team’s process and set capacity limits to indicate bottlenecks and/or idle resources.
- Shareable views – Given the variety of cards available in your backlog, different members of your team may wish to only look at a subset of cards at a given time. For example, a product owner may want to focus on Epics and User Stories, while a developer may only want to see technical tasks and bugs for a particular component. This can be accomplished by setting up contexts to filter the cards viewed on the planning and task boards.
Sharing these contexts with other team members ensures that everyone is working off of the same list(s) and nothing slips through the cracks.
- More than just burndown charts – Typical burndown charts display the number of cards that are considered “done” throughout an iteration or release. Many teams also find value in charting the amount of hours or story points burned throughout a sprint in order to determine the team’s velocity and future capacity.
GreenHopper automatically generates burndown, burnup and value charts for any numerical statistic being tracked.
Choose your own adventure
No matter what type of agile development process you implement, no one expects you to get it right form Day 1. Keep it simple from the start and adapt as you go to meet your specific needs.
To learn more about GreenHopper, try it free for 30 days or play around in the Jira Sandbox. Small agile teams can get started for just $10.