Tests often establish example values used to compare the behavior of the system with the actual behavior indicated in the requirements. For example, if we had a system behavior that converted a temperature expressed in Fahrenheit to one expressed in Celsius, then the test that specified this might have an assertion along these lines:
However the use of these values directly in the assertion sidesteps an opportunity to express the meaning of those values in the specification. Continue reading “TDD and Naming: Part 2”
TDD is not really a testing activity so much as it is about the creation of an executable specification. Because of this we value different things than testers might. Naming of tests, variables, and the use of well-named customized assertions are examples.
Test names are sometimes provided by the tools we use. Continue reading “TDD and Naming: Part 1”
sAs I’m completing my book the thought that keeps coming back to me is that when you look at things the right way they get a lot easier. And that much of what’s hard about Agile is that people aren’t looking at it the right way. I don’t mean the “being of Agile” which I believe is a red herring. Let’s run a little experiment. Please explain the following:
For those of you who know bases you’ll figure out this is addition in base 8.
Now, show this to someone who can do addition but doesn’t know bases. See how long it takes them to figure it out. I would guess many won’t.
But what if you had an easy way to explain bases and base addition (I do but it’s not important to the point of this post so I won’t bother here). Understanding bases makes a certain problem easy that is impenetrable when you don’t have that insight.
I believe we have this problem in Agile. People are looking at examples of what to do (practices) instead of the equivalent of bases in Agile. I’m not saying it’d be easy (e.g., add 142372341539243 and 524234714234 🙂 ) but it’d be easier. 🙂
I’ve written a chapter in my book on 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.
It’s nice to see the Scrum community finally accepting the importance of Lean and Kanban. But putting Lean/Kanban practices into Scrum does not make Scrum the same as Lean.
Perhaps the biggest different between the two is where our attention is when we have to remove an impediment. In Scrum our attention is “how do we remove the impediment by being faithful to Scrum’s practices.” In Lean, there is no attachment to any practice. Instead we ask “how do we remove the impediment by attending to Lean principles?”
In Scrum’s case, the assumption is that the team will figure out how to alleviate this impediment. But the best solution may not include having a stable team. For example, when multiple teams are working on a common codebase it may be best to dynamically form a feature team to work together (think of this as spontaneous mobbing).
This is a practice that I first used over a decade ago when test platforms were highly constrained. Immediately worked well and adoption was simple. The 7 teams that worked together to do this were following Scrum (with difficulty) before shifting to this model. Afterwards, they were no longer doing Scrum. We had to think in a Lean way to get to a Lean solution.
TDD, when conducted as a specifying activity, is an aspect of Behavior-Driven Development (BDD). Behavior is what we specify and is what we “drive” into the system using tests. Therefore, when structuring the tests in TDD we can be guided by the language of BDD: Given, When, Then.
Continue reading “TDD and Test Anatomy”
SAFe is not Agile if you are planning 3 months ahead
For companies that couldn’t get anything done in a year and are now getting things done in 3 months, SAFe is great. But don’t consider it Agile.
Quarterly planning presumes more certainty than we have. It’s waterfall thinking. Going from 12 to 3 months is an improvement. But don’t stop there.
If you are a development group of less than 300 people you probably could be doing 2 week plannings or even flow. Every now & then you can do a big room planning for the social benefits that provides, but it’s not needed for planning.
Long planning periods:
- require reworking requirements in last couple of sprints
- loses focus on realizing value
- makes it more likely that features will be bigger than needed
- loses focus by teams on releasable value
- results in more work being injected into already planned work
- has the refinement of any stories pushed out of the PI due to new work be waste
- makes it harder to pivot
- causes a loss in a sense of urgency
- requires more refinement up front without advantage of feedback
- establishes a baseline of “not good but good enough” so improvement stops
It’s fine to do high level quarterly planning but then work in a flow model to implement it.
First of all, we have a new website which better explains some of our services. See www.netobjectives.com.
Second, I’m almost done with my book: Going Beyond Lean and Agile: Introducing FLEX – FLow for Enterprise Transformation. While it’s about our approach, we have written a section on how you can make SAFe agile by putting our Lean Portfolio and Product Management on top of Essential SAFe. To learn more, see Part IV: Using FLEX to both enhance and simplify SAFe. You will see how to have much less complexity while having much more effectiveness.
We have created an online workshop: Advanced Scrum Masters / Kanban on-the-job workshop. This workshop is let by Al Shalloway. The cost is only $100 a month and usually takes three months to complete. This workshop is part of the Net Objectives University. A lot more is there beyond this workshop.
We are offering our first workshop on our FLow for Enterprise Transformation approach. FLEX is not another framework but rather an approach that integrates existing solutions to create a custom-fit approach to your needs. More effective, less complicated than preset solutions.
Of course, we are still offering our standard set of ATDD/BDD, TDD, Design Patterns, Scrum and Kanban classes. Note the public offerings of some of those courses coming up in Seattle and California in the next month plus listed in the table below my signature.
If you are considering doing some Agile at scale and think SAFe’s too big (or expensive) please contact me as I would love to chat about some ideas and services you may not be aware of.
There are regular new blog posts on NetObjectivesThoughts.com. Many of these have audio included and are available on iTunes.
I would be happy to chat about anything regarding delivering value to your customers (internal or external) faster.
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.
Developers often remark that the tests may contain the same algorithms that the production code does. This feels like redundancy and makes them wonder if TDD is promoting bad practices.
Example: A system that converts Fahrenheit to Celsius. The code would contain something like this: Continue reading “TDD Replicating Algorithms”
When first adopting TDD, developers can run into some roadblocks that seem to indicate that TDD is a difficult process. In truth, some of these problems actually indicate faults in the system architecture.
For example, developers will struggle to write unit tests of behavior that is embedded in a user interface, or in stored procedures in a database. Allowing a test to “push a button” in a UI involves the user of complex tools and tends to slow down the test execution. The same is true if the test has to spin up the database. Continue reading “TDD and System Architecture”