While many Agilists have been celebrating attempting to adopt Agile as crossing the chasm, it’s been little noticed that we’re on the edge of a new paradigm. While not yet named, it’s been called “FLOW”, “product development flow”, and “business agility”, among others. This paradigm shift goes beyond Lean’s paradigm shift (which Agile has not yet embraced). Essentially, it’s both a different focus on value & a different way of getting there.
The focus is on value to the business (which, of course, is mostly comprised of value to select customers). It also has an organizational instead of team centric. Another difference is a belief that, although, or even because) product development is embedded in the complex system called an organization, it is important to attend to laws and principles of product development. But the biggest shift is that instead of focusing on frameworks to help us, we need to focus directly on the work to be done. Here are the shifts:
- Focus on the system not individuals
- Use science of flow, systems-thinking and lean
- Focus directly on what we’re trying to achieve instead of frameworks Paradigm shifts are shifts in beliefs.
This is not the same as putting flow or Lean into Agile.
When organizations adopt TDD as their development paradigm, early results can be quite good once the teams get over the initial learning curve. Code quality goes up, defect rate goes down, and the team gains confidence which allows them to be aggressive in pursuing business value.
But there is a negative trend that can emerge as the test suite grows in size over time. Continue reading “TDD “Good” Tests Part 3. There must be no other test that fails for this reason”
Here are some things I have learned from Scrum.
- Cross functional teams are good. Just having them achieves a three to tenfold improvement over a group of people working on several projects at once. And they improve innovation by the team.
- Time-boxing increases discipline, visibility and the ability to pivot.
- Small batches are good and breaking work down into small pieces is essential.
- Smaller release cycles improve most everything.
- It is useful to have a team coach.
- Do not expect people to figure out what they need to do just because you have put them in a framework.
- Focus on learning the practices of a framework makes learning what you actually need to accomplish (flow) harder.
- People like to be given a set of practices to use.
- Defining a simple set of practices to use can lead to rigid dogma.
- Take an approach that transitions you to the behaviors you need.
- Approaches that work well in one context may not work well in another even though people them everywhere without noticing this.
- And, just because you can put whatever you want into a framework, that doesn’t mean the framework is not prescriptive. In itself, the framework has things you must do.
Continue reading “What I have Learned from Scrum”
Assessments are not about where you are. They are about where you want to go. By seeing where you are and what challenges you are having a roadmap for improvement can be made more effectively.
Assessing can be done in several ways. The most popular Agile method is to see how well the company is doing from the perspective of the approach they are taking. For example, a common assessment for Scrum is the Nokia test which specifies how well teams are doing Scrum. SAFe® has its own assessments. But consider these as assessments in how well a framework is being adopted, not how well the company is delivering value. We have found that focusing on the work, not the framework, is a better approach.
Because FLEX is based on a model of flow, it can be used to see where an organization is having troubles with achieving flow; that is, performing its work with few hand-offs, turmoil, delays, and rework. Reducing these helps achieve business agility. It is more effective to attend to how work is being delayed or how extra work is being created than how well a practice is being followed. Therefore, an assessment should focus on the value stream and what is impeding it.
For more, see Using FLEX to Perform an Assessment for Small-Scale Organizations
An intermediary practice is a practice that works indirectly on what you are trying to achieve. Before discussing examples and the risks of intermediary patterns, let’s look at some of the things needed to achieve flow (realizing value without delay):
- Removing delays in workflow (hand-offs and waiting for others), feedback, learning, and between getting and using information
- Manual testing
- Technical debt
By working directly on these, here is what you would have. Continue reading “Intermediary Practices vs. Practices That Work Directly on Flow”
I’ve created a new design for my book and am pretty excited about it. There are five parts to it:
- Part 1: Workbook: understanding what’s required for flow in your organization
- Part 2: Workbook: Using FLEX to transform your organization
- Part 3: Topics in depth
- Part 4: Using FLEX w/SAFe
- Part 5: Resources on the Net Objectives Portal
The first two parts cover the basics of FLEX. They present what the effective enterprise of the future looks like, giving a vision for the transformation. They are designed as workbooks to guide readers via a way to learn by doing. They are also relatively short so they represent a quick overview of the entire approach.
Part 3 provides an in-depth explanation of the topics used in the first parts. Part 4 discusses how to take advantage of FLEX’s Lean portfolio & prod management approach for those using SAFe.
The last part of the book is online, providing the latest ideas and practices we are coming up with.
If you are looking for a more effective approach than either SAFe or LeSS, I invite you both to look at the book as it is uploaded. If you are interested in using it to help with your own adoption, let me know as I am looking to work with a few people while it is being written
To see the book, go to Going Beyond Lean and Agile: Introducing FLEX (FLow for Enterprise Transformation) (online book)
Simply put, the Theory of Flow focuses on two areas:
- The steps it takes from conception of an idea until value is realized from it
- Reducing the Cost of Delay, the revenue or opportunity lost because of delays in realizing value
Reducing Cost of Delay (CoD) is essential to the goal of business agility, the quick realization of value predictably, sustainably and with high quality. Continue reading “Using the Theory of Flow to Illustrate Impediments in Two Hours Instead of Two Weeks”
First of all, I like Scrum. I think it can be a great framework when used in the right place. But I also think it must be taught as a tool in your toolbox, not an end in and of itself. This means initial training of Scrum should include more of the flow model (eliminating delays in workflow, feedback and using information) on which it is based. Test-first methods should also be incorporated into this training. This combination allows for teams to avoid most of the pitfalls teams new to Scrum face. I also believe one should look to see if Scrum or Kanban is better for a particular team (or something in between). See first comment for how I do this.
See Why Agile Coaches Need to Know Both Scrum and Kanban.
Continue reading “What I Think About Scrum”
Scrum is a lightweight framework that encourages correct action through performing its ceremonies and practices. While that is great in theory, the lack of the “why” of the ceremonies often has them be not followed.
Consider the “sprint” in Scrum. According to the Scrum Guide, “The heart of Scrum is a Sprint, a time-box of one month or less during which a ‘Done,’ usable, and potentially releasable product increment is created.”
It implies the need to start and finish stories in the same iteration. In other words, one of its objectives is to have a short time between the beginning of a story until it is completed. Here is what this provides. Continue reading “Why Being Explicit in Workflow is Useful: Case Study, Scrum Based on Lean Flow”
Creating software has several aspects to it.
- Deciding what to create
- How creating new software affects existing software
- How people work with each other
- The process being used to build it
Although all of this creates a very complex process, only the first three are fairly unpredictable, the fourth is not.
Continue reading “Time to Say Goodbye to Empirical Process Control”