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.
In this article, you will learn how to:
Before explaining the development workflow, it is useful to highlight principles found in modern Agile or Lean practices:
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.
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:
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.
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.
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.
An Agile developer’s daily flow is similar to this:
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.
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.
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.
In this article, you learned how to:
In upcoming articles, you will learn the key principles, practices, methods and tools to help implement your workflow.