- Introduces a series of articles about pragmatically configuring Agile workflows under varying conditions.
- Emphasizes that your agile workflow’s number one goal is optimal communications.
700 words, estimated reading time 6 minutes.
Welcome to the Pragmatic Agile Workflow series. This article describes a pragmatic Agile workflow that can be used with both onsite and co-located teams.
Many books and people define agile and scrum as a very narrow set of practices. In reality, Agile is a collection of principles and guidelines meant to be adapted to a given environment. You should expect to configure your Agile framework until it works well for your team, not adhere to dogmatic processes that were never meant to be one-size-fits-all.
Great Communication is the Goal
Great software is born out of great communication.
The primary goal of Agile methodology is optimal communication among team members. Only through effective communications can the organization iteratively design, deliver and test products in small manageable chunks.
Conversely, poor communication wastes development cycles, creates products with poor usability, and leads to team-wide friction and stress.
Your software development organization may start small, just a few people in a single room, all of them operating as ‘full-stack’ developers. It is often said that software architecture is the reflection of the organization architecture that built them. So, a small team of co-located full-stack developers is likely to write software in which all the components communicate constantly and without intermediation.
If the application is successful, the software development team may grow because pressure to deliver more product sooner prompts the need for more contributors.
As the team grows, communication problems arise. The time each team member spends communicating increases dramatically. This is not a new phenomenon; work at Bell Labs as early as the 1930s led to formalized Communication Theory. Communication Theory proposes that one driver of communication overhead is simply the number of pair-wise communication channels:
Number of communication channels = N(N-1)/2
Furthermore, as the complexity of the software under construction increases, not only do the number of communication channels increase the ‘thickness’ of each communication increases as well. Controlling the ‘thickness’ of communications requires partitioning the complexity of the entire application and it’s supporting infrastructure.
Communication channels and partitioning are described in greater detail in Timeless in Software Development.
When complexity and communications channels increase, you will want to reorganize your organization structure as well as technical architecture to increase partitioning and reduce pair-wise communication channels. Your Agile workflow will have to accommodate multiple teams and enable efficient cross-team communication.
Just as we expect that our codebase and system configurations are easily readable and maintainable, we should also expect our agile project management methods to be clearly communicated and consistent. When we change the development process, we must clearly and concisely explain the change and the reason for it. And, demonstrate the new process.
Having strong practices that allow team members to work in-office, at-home, or in other time zones instils a rigor and forms habits that enable high velocity and team expansion.
Scrum or Kanban?
In the world of Agile there are two primary delivery flows: Kanban and Scrum. While there is a great deal to be appreciated about a Kanban style of continuous workflow versus defined sprints and “chunked” deliverables, I recommend teams start with Scrum flow. Only after they mature as a team, and have the necessary communications processes in place, will they be able to take advantage of Kanban.
This is because visible, achievable short milestones enable team members to sustain the mental energy necessary to bring a sprint to the finish. Many people work better when they have mental milestones and Scrum provides this framing better than Kanban’s continuous flow. Sprints that define a set of work gives everyone something to rally around and to feel that a specific accomplishment was achieved vs. an endless stream of stories, tickets, et cetera.
Pragmatic Agile Workflows encompass many concepts; user stories, story points, and sprint design to name just a few, which can be configured depending on your situation.
- Pragmatic Agile Workflow: Sprint Design
- Pragmatic Agile Workflow: Estimating Story Points
- Pragmatic Agile Workflow: User Story Writing Best Practices
About the Author
John Lorance brings 20+ years of hands-on software and data system development experience, providing technical and executive-level management leadership to multiple early stage startups. As Telegraph Hill’s VP of Engineering he leads development of Telegraph’s Interim CTO practice, delivering critical engineering management support and agile coaching to startups and organizations undergoing digital transformation. He is a particular expert in leading global development teams, with successful outcomes as a result of effective team communication and inclusive stakeholder input.