Agile’s strength lies in its adaptability and efficiency, yet a crucial principle gets overshadowed – minimalism.
Minimalism extends beyond a reduction in size or scope. It’s a philosophy that permeates every aspect of Agile, from planning to delivery, and encompasses the entire procurement and delivery process.
Embracing minimalism streamlines processes and fundamentally enhances value by prioritizing meaningful outcomes over irrelevant tasks.
We will shape this conversation with the following:
- Definition of minimalism from several different disciplines,
- Pain points, with a few red flags to assess if you’re going off the rails,
- Candidates for Agile minimalism and
- Policy checkpoints to help guide your team.
Core concepts of Agile minimalism
Definitions
Minimalism is a design or a style where the fewest and simplest elements create the maximum effect. It isn’t simply “less is better than more.” A minimalist approach places value on meaningful outcomes over meaningless work. Corollaries exist in art, music, architecture, and software development. It’s a practical focus on what we value rather than consuming and maintaining resources we don’t need or use.
Architectural minimalism
Architectural minimalism is a form of building design that prioritizes sparseness and utility. Ornamentation of almost any type is overkill or waste. Minimalists borrow from ancient traditions. These include the Japanese Zen philosophy of wabi-sabi (or the beauty of impermanence and emptiness). And there is the Scandinavian concept of hygge, where sparseness is paired with comforting and utilitarian elements.
Architectural key elements:
- Lack of ornamentation, or the lack of superfluous features
- Open spaces, or in systems terms, open architecture
- Simple geometric forms are restated as simple and elegant technical solutions
Software development minimalism
In software development, minimalism is an intentional clarity of purpose to avoid unnecessary complexity, designs, dependencies, features, and code. It’s a recognition of Pareto’s law, which in software could be stated that 80% of the features are rarely or never used by its customers.
It’s not about building a Zen Garden in your application but rather about implementing a discipline and practice that doesn’t favor overengineering.
“It seems that perfection is attained, not when there is nothing more to add, but when there is nothing more to take away.”
Antoine de Saint Exupery.
Identifying challenges
Pain points
Consider the following scenario: Your team has grown into an unmanageable mess. Meetings are out of control. Three-point user stories have grown into five and are trending towards 13-pointers. How can you tell if your team is slipping off the rails? Consider a few red flags.
Red flags
- Meetings have insufficient time to cover their intended purpose
- User stories require lengthy descriptions or task lists
- Stakeholders complain about features they never requested or rarely use
- User stories shipped as a package due to dependencies
- The Potentially Shippable Product Increment is just a pseudonym for a release
For a primer on Scrum, see my Scrum Checklist.
Implementing Agile minimalism
Agile minimalism candidates
Minimalism expresses itself in many ways. The most obvious is in functional requirements and time-boxing meetings. This is only the beginning. I will discuss several additional concepts that demonstrate minimalism or that can be used to help encourage a minimalistic approach.
Key principles and implementation structure
What are the principles of minimalism and the structure for its implementation?
- Queuing Theory provides us with the foundations for minimalism
- Open Architecture permits a framework for building manageable, flexible, and maintainable software
Enhancing efficiency and value
Understanding queuing theory in Agile practices
Queuing Theory and practice in Scrum and Lean Kanban encourage small, independent packages of work, called user stories, to flow efficiently through a queue. The queue is the capacity of resources performing work. The resources are the team performing work. The queue’s length is the duration of the sprint, depicted by a Kanban board.
Velocity is work performed over a specific time frame. Large user stories block the queue by inefficiently consuming the developer’s time. Interdependent user stories within or with associated queues have a dragging effect and slow the velocity. Small user stories move efficiently through the queue. Complexity creates inefficiencies and waste.
A few questions to consider:
- Are you using metrics to identify queue inefficiencies, such as cycle time?
- Is there an “On Hold” category encouraging user stories to languish in a holding pattern?
- Does your Kanban board use a pull strategy to trigger a change in the user stories status?
Open Architecture intends to make adding, upgrading, and swapping components easy. It’s the underlying physical and logical structure of an application. Architecture defines the user’s experience. The impact of haphazard and poorly constructed architecture forces the developers to make a series of incrementally contorted design choices. Bad architecture limits scalability, usability, and the user’s future experience. It makes changes more difficult, especially for new developers. Each change becomes a Rubik’s cube exercise, and fixing things will break more things. Well-done architecture allows for flexibility to expand or adapt to meet future needs. In Agile, it relates to the ease of incremental changes without incurring excessive refactoring. The key to providing simple, elegant, and flexible solutions starts architecturally.
Let’s dig into some talking points:
- Are there architectural standards for designing and deploying hardware and software?
- How difficult is it to do the following:
- Learn the standards
- Create new services
- Conduct maintenance
- Change middleware
- Upgrade hardware
- How easily can multiple vendors interact with your codebase?
Implementing elemental units of minimalism in Agile
What are the elemental units of minimalism in Agile:
- Time-boxing all meetings frees up time for more productive use,
- Requirements are the foundation and the starting point for all work performed
- Test Driven Development (TDD) as a code, test, and fail cycle encourages adding only a minimal set of incremental features.
Exploring Scrum ceremonies and time-boxing
Time-boxing recognizes time as a limiting factor in productivity. Events, ceremonies, and working sessions should have the following:
- Purpose, with clearly stated objectives
- Agenda, with a list of decision points
- Time constraints
- Moderation
- Published minutes, identifying resolution of objectives
- Sandbox for off-topic issues
Consider the four classic Scrum ceremonies:
- Sprint planning should stay focused on the following:
- Calculating the team’s capacity Discussion of user stories’ value and priority
- Determining the content for the next sprint
- Daily Scrum is limited to agreed-upon duration and agenda. Schedule off-topic conversations later with those impacted.
- Sprint review is limited to user stories ready for deployment. Stakeholders and product owners agree only to accept or reject the proposed solution.
- Sprint retrospectives are limited to the proposed agenda. Issues discussed are reserved for those doable within several sprints and tracked like any other change request.
After satisfying the above issues, consider a few more questions:
- Does your Daily Stand-up take longer than 15 minutes?
- Does Sprint Planning include User Story Enhancements?
- Does the Product Owner commit to not changing the proposed functionality?
Are your ceremonies out of control?
Consider the root causes and discuss them at your next retrospective.
Optimizing user stories for minimalism
Requirements in Scrum are small, independent work packages called user stories. They encourage brevity over the exactness of detail. Waterfall methodology creates large, highly structured, detailed requirements. Both are prone to imprecise language. A user story’s saving grace is the flexibility provided by its short life cycle.
Does changing User Stories mid-sprint enhance or detract from minimalism? Refining User Stories during a Sprint is a natural outcome of the conversational approach. Whereas greatly expanding the feature set of a User Story agreed upon during Sprint Planning risks creating complex stories where simple ones would suffice.
Are you creating minimalistic user stories?
Split up large user stories into smaller ones based on the following:
- Conjunctions in the name (i.e., and, or),
- Excessive list of tasks
- A large list of acceptance criteria
- Internal or external dependencies.
Ask the following questions:
- Do User Stories lack brevity?
- Do User Stories have non-essential features?
The goal is to create small user stories without losing internal functional cohesion. Maybe your team would benefit from a deconstruction workshop. Pick a few examples and break them down along the lines suggested above. If the sprint has already finished, consider using it as an exercise for future enhancement activities.
Test Driven Development (TDD)
TDD is building code from the ground up. Write a test that will fail. Write the simplest code to pass the test. Improve the code or refactor and check for side effects by rerunning the test suite. It encourages adding only necessary features.
Consider a few questions:
- Are automated tests written first?
- Is just enough code written to pass the tests?
- Does the team focus on one feature at a time?
Translating minimalism into functional streams
Now, the fun part. How do you translate minimalistic principles into streams of new functionality? Several approaches are available, requiring an increasingly greater level of discipline and institutional maturity.
- A Potentially Shippable Product can encourage a discipline of minimalism,
- A Minimal Viable Product (MVP) encourages eliminating superfluous functionality
- Continuous Integration and Continuous Delivery (CI/CD) enforce a discipline of minimalism.
Strategies for implementing Agile minimalism
A Potentially Shippable Product can be released to the customers and used for its intended purpose. It can be shipped but not necessarily released to production immediately. It’s another mechanism for minimalism due to the nature of a shippable product. It encourages small work products with few dependencies.
A few questions to consider:
- Has this become a catchphrase to indicate a software release?
- Is your increment usable by its intended customer?
- Could you ship the product at any time during the Sprint Increment?
Minimum Viable Product (MVP)
MVP has only enough features to attract early adopters and validate a product idea early in the product development cycle. Eric Ries defines this in his Lean Startup.
“The version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”
Not just a proof-of-concept. It’s about deploying a functional prototype, incrementally enhanced, based on market factors, and the user experience. The Product Increment and customer feedback cycle directly support each other. Product Owners must evaluate “Need to have” vs. “Nice to have”. Customer feedback triggers the MVP and considers those features that directly impact their user community.
The goal is not to add more complexity to a minimalistic Scrum framework. Rather, take a page out of Lean Kanban and strengthen customer feedback when evaluating the effectiveness of the MVP.
- Are you implementing a “fat MVP” with “nice to have” features?
- Are you collecting feedback on the effectiveness, customer satisfaction, and user priorities to help prioritize future feature sets?
- Are you continually evaluating the MVP to correct issues and resolve customer demands?
- Are streams of functionality kept to a minimum and enhanced later when core functionality proves operational?
Continuous Deployment/Continuous Integration (CD/CI)
CD/CI is the continuous and automated deployment of individual work products. Instead of deploying functionality batched in release packages, there are daily code drops to production. The CD/CI pipeline requires a rigorous discipline embracing minimalistic principles. Application coding, testing, and deployment are streamlined. It simplifies the software development and deployment process by leveraging automation. Architecture has to support flexible code drops by switching on/off production functionality. A CD/CI pipeline helps bridge the gap between development, deployment, and production.
A few questions:
- Does the team understand its deployment pipeline and version control practices?
- Are your tools deployed to help enforce best practices?
- Is there sufficient test automation?
- Can code be moved into production without going through the CD/CI Pipeline?
Policy checkpoints
Consider establishing a few policy statements as part of your working agreement. It’s not excessive, just something the team can refer to. It’s important to discuss and achieve a consensus. You might put this on the agenda for your next retrospective.
- Keep user stories to a minimum, doable within three business days
- Write user stories with brevity
- All meetings are time-boxed
- The MVP must be scalable and contain only essential features.
Closing thoughts
Scrum is not an implement-and-forget methodology. Compliance to form without function will lead to stagnation. It must embrace the Deming cycle of continuous change. Teams should continuously ask questions about how to perform work. This is a conversational approach to process assessment, not a questionnaire-based one. These questions are a kickstarter for that dialogue.
![[Case Study] Lessons from descaling 25 Scrum teams](https://www.agilealliance.org/wp-content/uploads/2024/12/descaling-teams-1200x630-1-150x150.jpg)
![[Case Study] Lessons from descaling 25 Scrum teams](https://www.agilealliance.org/wp-content/uploads/2024/12/descaling-teams-1200x630-1-300x158.jpg)
