TDD is typically part of an agile process. This means that we embrace change, that new requirements flow into the team’s work either on a time-boxed pulse, or through some kind of pull system (like Kanban). In TDD, a new requirement always starts out as a new, failing test or “specification.” We write the test to express the requirement before it has been fulfilled.
Then, work is done in the system to make this new test pass. Over time, however, developers begin to experience the syndrome where making the new test pass makes older tests fail. Those tests must be maintained (you cannot leave tests “in the red”) which burdens the team. This problem tends to get worse over time. Continue reading “Sustainable TDD: Part 1”
I have been doing Agile for over 20 years. I see a new path forward, however. One that includes the entire value stream (from concept to consumption) and one that integrates many ideas on the technical side throughout the value stream. This newsletter focuses on two things:
- What’s the next thing after Agile (or, if you prefer, what is Agile morphing into?)
- How to improve your technical agility
For those who want to see what’s coming in Agile at scale
For those wanting to see what’s coming in technical agility
A side note for those considering or wanting to improve SAFe. As a former contributor to SAFe, an SPCT and Gold partner, I know how to make SAFe better. If you’re considering doing SAFe or want to see how to improve it, see Part IX: Using FLEX to both enhance and simplify SAFe.
As always, happy to chat with you about your challenges and how we can help.
Al Shalloway, CEO, Net Objectives
SAFe® is a registered trademark of Scaled Agile, Inc.
Don’t see an offering in your area? Let us know so that we can see about scheduling one nearby!
Here are online courses and workshops being offered now on Net Objectives University.
This is my 48th post in this series on TDD. I wanted to bring some of this material together and engage with the notion of TDD as a sustainable process. In this posting, I will introduce the topic, and then cover some issues that pertain to sustainability and/or the seeming lack thereof. Continue reading “TDD as a Sustainable Process: Introduction”
This is an excerpt from Introducing FLEX – FLow for Enterprise Transformation: Going Beyond Lean and Agile (online book). If you are looking for an alternative to SAFe, this is it. To those who’d like to study along with me as I publish this on linkedin, please ask to join the True North Consortium Linkedin Group where I will be happy to answer any questions or, even more importantly, discuss things you disagree with in the book.
If you want to learn more about FLEX you can watch a webinar on FLEX, take an online course at the Net Objectives University or take a live course in Orange County, CA May 6-8, 2019, or in Seattle in June (both led by Al Shalloway). If you want to learn about how to adopt FLEX in your organization please contact the author, Al Shalloway
This chapter discusses the relationship between ATDD and Design Patterns. Essentially, ATDD provides us with quality acceptance criteria in the form of test specifications. We can use these to design our code from a behavior point of view instead of from an implementation point of view.
Doing this makes for more testable code, a quality highly correlated with other code qualities we want – strong cohesion, loose coupling and no redundancy. Design patters provide us with a method for combining these high quality objects together through the Gang of Four’s mantra’s of designing to behavior, using variation and encapsulating variation – in this case variation of type.
In the Agile world where requirements evolve, ATDD and Design Patterns Thinking work together to enable emerging designs from emerging requirements.
Continue reading “The Relationship Between Acceptance Test-Driven Development and Design Patterns”
This is an excerpt from Introducing FLEX – FLow for Enterprise Transformation: Going Beyond Lean and Agile (online book). If you are looking for an alternative to SAFe, this is it. To those who’d like to study along with me as I publish this on linkedin, please ask to join the True North Consortium Linkedin Group where I will be happy to answer any questions or, even more importantly, discuss things you disagree with in the book. S
If you want to learn more about FLEX you can watch a webinar on FLEX, take an online course at the Net Objectives University or take a live course in Orange County, CA May 6-8 or in Seattle in June (both led by Al Shalloway). If you want to learn about how to adopt FLEX in your organization please contact the author, Al Shalloway
The concept of the minimum business increment (MBI) is key to Agile software development because it provides us with a container for all of the items required to realize value for a business increment. Its focus on being “minimal” provides us with the smallest batches possible, a practice proven to be effective. This alone would make them worthwhile. But they have another value, they tie strategies to the intake process, facilitate the use of ATDD and assist in planning. This chapter discusses both how and why this is so important.
Tying Strategies to the Intake Process
Business stakeholders and product managers provide the development group what to work on. Very often this is with the development group as they may be the originators of what to work on. By using MBIs, the development group gets smaller batches than they would otherwise. This is one of the best ways to manage work in process – have smaller chunks of work come in. The content of the MBI, that is, all of the tasks required to realize value, also provides the development group insights on who they will have to work with to get the software out the door and realize value.
Using MBIs to feed ATDD
ATDD is our recommended way to decompose and refine requirements. MBIs are containers of all of the features and stories that will be developed. By peeling off vertical slices from the MBI using ATDD, the MBI can be used to see what’s left to decompose while ensuring all necessary components of it are defined. By decomposing MBIs into features and then stories, teams also avoid features and stories that are bigger than needed. Without the MBI, team often work on an entire feature even though only part of it is needed for the first MBI.
Planning with MBIs
Big room planning in SAFe has people focus on getting features completed. However, features by themselves may not be releasable where they will provide value on their own. It is therefore possible to schedule features to be completed but not have something to release until the end of the program increment. It is better to schedule the completion of the MBIs, not the features. This manages work in process in a natural manner.
Quick recap (see earlier posts):
- How did Agile get to be so unagile
- take a systems thinking point of view. Use Lean to create a great environment
- Focus on business agility – the quick realization of value predictably, sustainably and with high quality.
Flow thinking is looking to see how to take an idea to realized value as quickly as possible by working on what will achieve the greatest value, educing delays in workflow, by getting quick feedback, and not creating rework. Lean’s mantra of “just in time” guides us in how to make decisions on when to start work. Its “build quality in” has us stop creating unplanned work due to errors.
But Flow thinking also means we have to attend to the work – not a framework. All too many times people adopt Agile by spending most (all?) of their budget on the framework or relegate how to do the real work to 2nd tier training. Einstein would say this is insane given the patterns of challenge this causes.
Ask yourself when you’re considering an adoption – which is more important to know – the framework or how to do the work? A framework sets the stage for the work, but won’t teach you how to do it directly.
if you find this blog interesting you might want to check our upcoming webinars. See NetObjectives.com/events.
In TDD and Code Coverage, we established that code coverage tools do not provide useful project metrics, in and of themselves. In TDD, we don’t use code coverage tools for this purpose because we don’t need to. If all production code is written to satisfy prewritten, failing tests, then by definition, all code is covered.
Still, we do have automated tools that can measure coverage. Are they useful to a TDD practitioner? Yes they are. Here are three things they are useful for. Continue reading “TDD and Code Coverage Tools”
Most companies have gone to some form of Agile in order to keep up with the competition. For large companies the ‘Agile’ method of choice is SAFe. While promoting a project to product mentality, its complicated portfolio & product management approach makes this very difficult to achieve. It devolves to a large scale project management system spouting Agile euphemisms while not truly creating a Lean mindset.
After watching SAFe continue to diverge from Flow & Lean thinking, I am convinced that organization looking at how to be Agile should take an approach that more directly focuses on Flow & Lean & less on a framework purporting to use them.
In my mind jumping to these methods directly, instead of taking the disjointed collection of them is a less risky path than SAFe. Especially due to its insistence on a one-size fits all jump in all the way which is actually not a safe thing to do.
Jumping to Flow and Lean thinking provides a competitive edge. And uses more advanced and mature practices than what has become popular by just using a few of their principles. The risk today is not in taking a lead, the risk is in following the crowd down a comfortable but less effective path.
This is not part of my series of posts on how Agile has become unagile but is, of course related.
if you find this post interesting you might want to check out my upcoming (May 3) webinar on FLEX – not another framework but a thought process you can use to solve your problems.
Agile is a great ideal. It feels good. It is a call to liberation. We should never lose this. But we must also remember Millard Fuller’s observation “It is easier to act your way into a new way of thinking than think your way into a new way of acting.”
This means working together will get you to trust and respect faster than saying to trust and respect each other will get you to working together. The latter is a nice thought but doesn’t work with divergent roles and values.
Continue reading “Step 2: Shift from Agile at the team to business agility”
“We cannot solve our problems with the same thinking we used when we created them” Einstein
The team focus of 2001 is no longer viable. Early adopters could adopt Scrum without regards to the bigger picture. The key was having a cross-functional team that Scrum and XP were designed for.
But as soon as Agile spread beyond one team, it ran into challenges. Team dynamics are different from organizational dynamics. Scrum ran into problems because forming cross-functional teams required committing someone who was needed on several teams to one team. Agilists didn’t have methods that solved this problem.
Continue reading “Step 1: Acknowledge the need to move from a team focus to systems thinking”