Using JIRA Does Not Make You Agile
How you
use “Agile” support tools could sabotage your agility
How an organization uses “Agile” requirements management and team
collaboration tools like JIRA is an indicator of how well that organization
aligns its management of software systems development with Agile software
development. The least “Agile-mature” organizations attempt to manage
Agile projects with traditional project management biases and
expectations. Such organizations often use Agile requirements management
and collaboration tools to track and report:
- Traditional
project management metrics
- “To-do”
lists of unprioritized and unsized items written like traditional
requirements or developer work tasks
All the while, organizational
leaders and management assume they are “Agile” because they are using “Agile”
tools.
The Place of Tools in Agile
Before expounding on these two
general misuses of Agile requirements management and collaboration tools, let’s
go over what the Agile Manifesto for Software Development says
about tools. Agile values, “Individuals and interactions over processes and tools.” While Agile teams
institute processes and use tools to manage their work, they value direct
interaction between individuals more. Under this construct, tools are
enablers that facilitate communication between teams members and project
stakeholders. They are not substitutes for direct communication.
Agile prefers face-to-face
communication over emails, phone calls, project tools, formal boards,
documentation, etc. This way of communicating increases agility by
avoiding the use of intermediary channels, documentation, and reporting
structures that often slow and distort communication. It also prevents
formalizing decisions too early, which unnecessarily narrows options and
commits development teams to approaches that may prove wrong after having spent
significant time, money, and resources implementing them.
However, not every interaction in
and among Agile teams can be face-to-face. Agile development teams with
members who work remotely, and enterprises staffed entirely with remote teams,
are common. While Agile best practice is to collocate teams and team
members, it not always possible. For example, the project team may be too
large to depend solely on direct communication between members.
Agile requirements artifacts are
purposely lightweight. They work as reminders for future conversations that
will flesh out details. However, even lightweight requirements become difficult
to manage as they grow in number. Requirements management and team
collaboration tools help document and track requirements, manage work, and
report progress. They also help bridge distances and time zones between
collaborators.
Project Metrics Tracking
The types of metrics
relevant to traditional vs. Agile projects are different. Traditional
project management is concerned with managing the constraints of the Iron
Triangle: Cost / Budget, Schedule, Scope, and QualityFigure 1: The Iron Triangle
Fixing the former three constraints leaves quality as the only variable, opening the door to sacrificing quality to adhere to the other constraints. We can sum up the Iron Triangle with the adage, “I can get it to you cheap, fast, or good. Pick any two.” On the other hand, we manage Agile projects primarily by managing scope. We fix schedule and budget while treating project scope as variable and not sacrificing quality.
Traditional Project Metrics
Keeping the first three
constraints of the Iron Triangle fixed throughout a project requires adherence
to detailed project plans. Changes to those plans are highly frowned upon
since even small changes can ripple across project plans in unexpected
ways. Thus, traditional project managers focus on managing people and tasks to keep projects on track
with plans. This leads to collecting metrics such as the ones shown in
Table 1 below:
Agile Project Metrics
Agile projects hold schedule and
budget fixed while treating scope as a variable. In essence, we have a span of
time, a bucket of money, and the flexibility to build just enough of what is
needed to satisfy customers. When schedule or budget run out, we can stop
development or pony up more money to build more. We also have the
flexibility to stop the project at any time should we decide that we delivered
enough functionality or if the project is no longer viable. Cancelling a
failing or unnecessary project after spending $10 million is much better than
doing so after spending $100 million.
Since Agile teams are
self-organizing, they manage their own work. They do not need management
to allocate tasks, lead estimation activities, or coordinate between teams.
Also, in Agile, “Working
software is the primary measure of progress.” Therefore,
metrics like percentage complete are unnecessary (and nonsensical) since we
regularly evaluate complete and releasable business or mission
functionality. In Agile, a feature is either done or it isn’t and teams do not take credit
for work on incomplete features. What “complete” means to project teams
and stakeholders makes up the “Definition
of Done”.
“Agile metrics” help teams:
- Manage
current work
- Plan
future work
- Communicate
project status across teams and project stakeholders
Many Agile approaches / frameworks exist. In the Table 2 below, I provide Scrum metrics and reports as examples. I avoid discussing the details of tracking, reporting, and using these metrics and reports in this article. Instead, I present these examples to drive home the point that what we measure, track, and report in Agile projects is different from that of traditional project management because the two approaches are fundamentally different.
Quality Metrics
Measuring the quality of
deliverables and acting on findings is crucial to all software development
projects, Agile or not. There aren’t Agile-specific measures of
quality. However, like traditional requirements, well-formed Agile
requirements specify the outcomes and quality characteristics that associated
functionality must meet. In Scrum, for example, quality criteria inform
user story acceptance
criteria.
Tracking Traditional Project
Management Metrics via “Agile” Tools
Many organizations configure and
use tools like JIRA to collect and report traditional project management
metrics. This practice demonstrates a fundamental misunderstanding of
Agile and how it differs from traditional project management. It is also
indicative of organizations that adopt the terminology and mechanics of an
Agile approach or framework without embracing its principles. While tools can enable Agile
practices, agility is not the result of using tools.
Using Product Backlogs as “To-Do” Lists
Tools like JIRA are primarily
designed to support Scrum teams. As such, they organize work through product
backlogs. A product backlog is a prioritized list of estimated
or “sized” descriptions of business or mission capabilities needed by users or
roles (human or automated) to accomplish specific outcomes. Scrum teams typically
write these requirements as user stories:
As <a user or role> I want <some capability> so that <desired outcome>
We write
user stories from the user’s perspective, not from the perspective
of the system we are building or the tasks developers need to do.
Unfortunately, it is quite common
to see user stories written as system requirements or developer tasks.
Many teams also neglect to size and prioritize product backlog items until
sprint planning (and sometimes not at all). Rather than managing a
product backlog, such teams work from what is ostensibly a to-do list.
Doing so takes away the ability of Scrum teams to manage current work, plan
future work, and clearly communicate project status.
Conclusion
Requirements management and team
collaboration tools like JIRA are useful for documenting and tracking
requirements, managing work, and reporting progress. However, using such
tools is not the same as being agile, especially when used to support
traditional project management processes and reporting. Understanding the
differences between Agile approaches and traditional project management is key
to ensuring we avoid contorting Agile to support Waterfall processes and
expectations.
https://agilecheetah.com/using-jira-does-not-make-you-agile/
No comments:
Post a Comment