This article is the second in a five-part series.
A healthy, lean, modern application team has a strong and consistent
Development Rhythm.
Developers who apply modern principles, practices,
methods, and tools to software are able to
add new features and fix existing issues faster,
safer and more sustainably than ever before.
If you are a developer new to Agile concepts,
and plan to work with Tanzu Labs on an upcoming
engagement,
continue reading this article,
then go read the reference articles and do the workshops
so that you are ready to be productive on your
first day of work.
What you will learn
In this article, you will learn how to:
- Describe the Agile developer’s workflow.
- Describe the inputs to and outputs from the Agile developer flow.
- Explain the importance of developer discipline and the use of
feedback loops in the developer flow.
Background
Before explaining the development workflow,
it is useful to highlight principles found in modern Agile or Lean
practices:
- Pull-based work model – downstream consumers pull work from upstream.
- Batch sizes are small.
- Use of short, feedback loops to iterate on the work.
- Integrate work with the team at least daily.
It is necessary to understand how the Agile developer’s flow fits into
the overall software delivery cycle.
Let’s talk about upstream dependencies to the developer flow next.
Backlog
The Backlog is a curated list from which the developer will pull their
work.
Before a developer starts work,
the work must be specified and prioritized in a backlog.
The work is specified as discrete User Stories that are:
- Specifications of what to build (or fix).
- Estimated by the team.
- Independent of each other.
- Prioritized.
- Sized small enough to be integrated daily.
Product teams typically organize work around features or fixes.
Either may comprise work that is not small enough
to fit in the confines of a single story.
Agile frameworks specify course grained work as an Epic or
as a Theme, but neither the Epic or Theme directly specify
the work done by the developer.
Stories may be tied to Epics (or Themes) to keep the work to
a specific feature or fix.
Outside the scope of the developer workflow,
use of Epics and their relationships to stories are important when
specifications are not well known,
or when refining in-process work.
The input for an Agile developer workflow is a single story.
Software Delivery
The output of the Agile developer’s workflow is functioning software
that is pulled into a downstream
Continuous Delivery
Pipeline for purposes of being able to deliver features or fixes to
production at any time.
The Continuous Delivery Pipeline may involve various manual and/or
automated steps for testing,
verification,
oversight compliance,
staging,
or perhaps a
secure pipeline towards production.
Note:
There is much more to this topic that is outside the scope of this
article.
The Agile Developer Workflow
While the story provides a form of specification or requirement,
it is up to the developer to translate the specification of the story
into the design, tests, and their associated solutions.
The Agile development workflow compresses design,
construction,
and a substantial amount of testing into a story’s implementation work.
This places more burden on the developer and shows there is a
need for discipline in the developer workflow.
Flow Summary
An Agile developer’s daily flow is similar to this:
- Take the highest priority story from the backlog.
- Review the story details, including its desired outcome.
The story may be for building new features,
fixing defects,
or for an investigation if the problem/solution domain
is not well known.
If the story is investigative,
the developer may use a
Spike
as a way to timebox effort to better understand a problem and/or its
solution. - Iterate on a series of steps using one or more feedback loops to
achieve the outcome of the story.
Developers spend much of their time writing code,
using methods such as
Test Driven Development,
Refactoring and/or the Mikado Method. - Document the work as appropriate and merge it to the source control
repository once you complete all the steps. - Verify the work is successfully integrated.
This entire flow should be run at least once per day,
and ideally multiple times per day to satisfy the goals of
Continuous Integration and
Continuous Delivery.
Developer Discipline
Although there are only five steps listed in the developer flow,
there are many activities going on within it.
It is important for the developer to keep focus during the workflow to
work efficiently and effectively,
yet also with the flexibility to change directions,
as needed.
Even though the stories curated in the backlog are small,
they do not specify the design.
Agile approaches compress the design,
construction and part of the test scope into the development flow by the
same developer.
This places a burden on the developer to be more focused and disciplined
to craft quality software quickly and safely.
Discipline requires a set of clear,
repeatable processes to be sustainable.
Feedback Loops
A common theme in modern application teams and their practices are use
of feedback loops at varying levels in the application development
lifecycle.
You can read more about it in the following articles:
The developers daily workflow also includes a series of fine-grained
feedback loops.
A single story might have hundreds of steps spanning multiple feedback
loops to complete the story outcome.
While some of the steps are identified up-front when building and
estimating the story,
many of the steps are discovered during the workflow process
in the form of multiple feedback loops that include a hypothesis and
an associated experiment to verify that hypothesis.
It is necessary to keep each step in a feedback loop small in duration,
measured in minutes, at a maximum, to run.
There are two reasons for this:
-
The overall work batch size remains small.
-
Humans work more efficiently doing small, well-defined tasks than
large ambiguous ones.
The idea is to use evidence-based approaches to change,
and that changes are easy to define,
implement,
and measure the outcome.
Development Inner Loop
As container and container orchestration technologies are becoming
mainstream,
development,
testing and deployment become more complicated.
Another term you may see that relates to this subject is
Development Inner Loop.
The idea is that the developer will iterate in their development
environment (the Inner Loop),
and then integrate their work in a DevOps Cycle
(the Outer Loop)
for continuous integration automated verification,
and automation to support Continuous Delivery or
Continuous Deployment.
Summary
In this article, you learned how to:
- Describe the Agile developer’s workflow.
- Describe the inputs to and outputs from the Agile developer flow.
- Explain the importance of developer discipline and use of feedback
loops in the developer flow.
In upcoming articles,
you will learn the key principles,
practices,
methods and tools to help implement your workflow.
