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”
When TDD was first suggested, there were many who were dubious about the wisdom of having developers write tests of their own code. Among the objections raised was that developers will slow down if you burden them with new tasks, namely writing the tests as well as the code.
This seems logical. Give someone more to do, and they will take longer to do it. But the truth is that TDD actually increases velocity once the team gets over the initial learning curve.
How can this be? This is true for three reasons. Continue reading “TDD Yields Velocity”
TDD is a process that provides constant confirmation to the development team.
Writing the tests up-front confirms that there is sufficient understanding of requirements so that they can be expressed in the rigorous form of a unit test. Alternately, it reveals that this understanding has gaps and reveals questions that need to be answered.
The quality of the test mirrors the quality of the system, and so if “good” tests (as I have defined them) can be written, this is confirmation of a good design. Continue reading “TDD Yields Confidence”
This was originally published in June, 2014
|I am enthusiastic over humanity’s extraordinary and sometimes very timely ingenuity. If you are in a shipwreck and all the boats are gone, a piano top buoyant enough to keep you afloat that comes along makes a fortuitous life preserver. But this is not to say that the best way to design a life preserver is in the form of a piano top. I think that we are clinging to a great many piano tops in accepting yesterday’s fortuitous contrivings as constituting the only means for solving a given problem. Buckminster Fuller
Continue reading “The Real Reason the “Agile Wars” Are Destructive – It’s Not What You Think”
This was originally published May, 2017
Note: This blog assumes the reader understands the basic roles and practices of Scrum.
Scrum suggests that the way to improve a team’s workflow and the organization within which it works is to remove impediments to its core roles (product owner, team, Scrum Master) and practices (cross-functional teams, daily standups, and using time-boxing for work, demos and building backlogs). It takes an inspect and adapt approach that requires little understanding of the underlying laws of software development other than an acknowledgement that reducing the time for feedback is essential and that small batches are better than large ones.
Continue reading “Why Shu Ha Ri and Scrum Can Make for a Dangerous Combination”
I had hoped they’d fix the underlying flaws of SAFe but am now convinced that will not happen. Here’s why we only help folks doing SAFe but don’t train it anymore:
1) SAFe’s based on levels & not on the value stream. All companies need the concepts in the top levels (e.g., strategies) but these are overly complex due to factors described in the rest of this list so SAFe’s method to achieve them is unusable for many organizations
2) SAFe has tacked concepts together by focusing on roles & artifacts while misusing/redefining previously useful terms
3) SAFe does not have a concise, well-defined concept of the smallest increment of value used to extend an existing product. MVPs are for new products & epics are too large. This makes prioritization across teams difficult
4) there is no simple way to have the org align around value
5) the Lean principles mentioned are used in a superficial way
The result is a pre-defined, over-complicated solution. SAFe can be a massive improvement for companies whose development group is blocked & it provides low cost training materials. But it will not help achieve true agility except when guided by a real expert who goes SAFe to achieve that. SAFe is often used to gain consistency not agility.
These are not idle comments. If you are using SAFe and finding value at the program level but want to improve its higher levels, you will find value in Part IV: Using FLEX to both enhance and simplify SAFe