Examining Test-First

“Test-first “sounds like it’s about testing, but it’s really about collaboration, shared understanding and better design. Test-first originated with eXtreme Programming (XP) with the focus was on writing tests before code. Fortunately, a natural law of software development is that programs written by first considering their behavior are more flexible and robust than programs written by considering their implementation.

Since then, test-first has expanded to be used between product owners and the team by specifying the requirements in the form of acceptance tests. This is called Acceptance TDD (ATDD)

ATDD requires the collaboration of all parties involved. This collaboration on understanding behavior prior to implementation clarifies what is being required while removing the delay between specification of requirements, their implementation and then their final validation. This both helps ensure the right functionality is built while increasing efficiency.

The benefits of ATDD are

  • improved collaboration
  • clear acceptance criteria
  • prepared for automated testing
  • improved developer-tester communication
  • reduced time for feedback
  • agreement on requirements
  • improved code quality

It’s one of the best steps towards building the right thing in the right way.

For more information see:

Benefits of Acceptance Test-Driven Development using Behavior-Driven Development

How to Start with ATDD using BDD

Unexamined Assumption: use Essential SAFe for small and mid-scale companies.

The following is an excerpt from the chapter  Adopting SAFe at Small Scale in Al Shalloway’s new book – Achieving Agility at Small to Mid-Scale

The Challenge of Essential SAFe

SAFe proponents suggest Essential SAFe be used for small companies. The reason for this is that small companies don’t need the complexity that full SAFe entails. But even small companies have the issue of taking their strategies to fulfillment. This means that the concepts of strategies, epics, solutions, capabilities, and MVPs are still needed. The challenge, of course, is that these are defined at the levels above Essential SAFe.

Most small companies adopting SAFe are mostly attracted to:

  • the program increment and its planning event
  • the role of the release train engineer (RTE) to coordinate teams
  • having teams work in cadence with synchronization

These can be used as the cornerstone of their SAFe adoption. However, a simple Agile Product Management approach that takes the company from strategy to realization of value is still required.

See chapter above for more.

Unexamined Assumption – Developers spend a lot of time fixing bugs.

I’ve been delivering talks at conferences & user groups for over 20 years. One question I ask at most of my talks for developers is “how many of you spend most of your time fixing bugs?” Throughout all of these years, I get about 9 out of 10 telling me they do. But they don’t.

I go through this conversation with them:

  • Consider a time you were notified of a bug.
  • remember the time you spent trying to reproduce it
  • and then figured out how to fix it and did that
  • And then undid it because it broke something else
  • And then found the real cause and fixed it
  • Now, how much time was actually spent fixing the bug?
  • I’d suggest that most of your time was spent finding the bug.

Now this is not just semantics. Consider from when you write a bug (and yes, do you write them even though you say “I found a bug” as if someone else wrote it 😊 ). And let’s say it was found right away (maybe you have automated testing). It likely wouldn’t take very long to fix, because it’d probably be due to the last thing you did. But if you discover it weeks later, even if nothing changed, it might take you hours or days to find and fix it. If things have changed, it’d take longer. And think of the wasted time you would have caused others.

The moral? Spend a little time so that you don’t have to look for bugs.

Examining How to Adopt Scrum

Scrum presumes it is effective to give all teams a simple preset, immutable framework that each team must follow until they figure out how to manifest it.

Scrum is designed for and requires cross-functional teams doing work that is plannable. If these conditions aren’t met it is presumed that manifesting Scrum’s rigid framework will achieve Agile in all situations if people are motivated.

An underlying believe is that teams can’t initially understand what they are supposed to do so must be given a predefined set of rules that must be implemented without change until the team understands what’s happening.

While this approach works when cross-functional teams can/should be created & work can be planned, it can causes resistance & abandonment of misunderstood practices when teams have challenges adopting the framework or attached to their roles.

Alternative
Have expert have 2 hr discussion w/ team&their management to see what alternative or additional practices would be useful. Use these to provide a set starting point and provide teams a guide on how to improve/change practices when they encounter challenges. While coaching still advisable, significantly less will be needed.

I invite people to discuss these alternatives.

What I Am Trying to Destroy

On a twitter thread there was an implication that perhaps the reason some people don’t engage with me is because they perceive my purpose is to destroy. I have told myself that as a good person that is not my intent. But I now realize it is.

Over the last 20 yrs I have observed many patterns of challenge & success in the adoption of Agile. I am convinced that Agile adoptions do not have to be as hard as they usually are. Most of the time they are difficult I see unexamined assumptions as contributing to this. This includes both beliefs underlying the approach used & how to teach it as well as if/when to introduce certain practices.

You destroy unexamined assumptions by examining them (they become examined beliefs). That’s what I am doing.

But many people make their livelihood on frameworks & methods that I believe are based on these unexamined beliefs. And this causes a cycle of poor Agile adoption w/o serious reflection. Unfortunately, as Upton Sinclair has observed, “Its hard to get a man to understand something when his salary depends on his not understanding it.”

My mission is serve the practitioners and consultants who have an aligned mission – making organizations and their people more effective regardless of approach.

Let’s stop trying to get leadership/management to ‘be’ Agile

I’m often hearing how Agile is failing because leadership and management won’t adopt Agile values & principles. I would much rather they just keep some basic agreements:

Let’s stop for a minute and ask ourselves, do we want them to ‘be’ Agile or to do the following:
1-create clarity on what the most important work to do is
2-define these as a sequence of small increments for which we can realize value. Have each of these increments include technology &any other groups needed to realize value
3-provide technology clear acceptance criteria on these items
4-provide guidance across business units as to which are most important based on cost of delay
5-allow technology to self-organize & pull the work to be done in the sequence of greatest importance when technology has capacity
6-have an agreement with technology on how to handle emergencies
7-provide feedback when needed

We have come up with the following agreements we call the guardrails:
* Focus on realizing value
* Collaborate with each other in order to maximize the realization of value
* Make all work visible
* Sustain or increase predictability.
* Keep the work within capacitythroughout the value stream
* Encourage everyone to strive for continuous improvement.


For more information on the guardrails, go here.

To see guardrails tailored for leadership and management, go here.

This blog is an excerpt from my upcoming book –Achieving Business Agility at All Scales

 

When It Is Visualization and Not Reorganization – Verticals feeding horizontals

In my earlier post I discussed the relationship between visualization and reorganization & discussed how orgs should not limit themselves to visualization but should reorganize after visualization as appropriate. But in some situations reorganization is often not a real possibility.

Consider when vertical applications drive horizontal support systems & at scale. In a financial company one might have verticals for – banking, credit cards, signature programs, loans. These feed horizontals such as – payment processing, transactions across accounts, client account setup and maintenance …

In a situation like this, splitting up the horizontals into trains to work with the verticals won’t necessarily work well – either when you run them as separate trains or as part of the vertical train. Running the horizontals as separate programs doesn’t solve the problem either as they are each pulled in multiple directions.

In these cases, it is often best to create visibility on the work to be done by using Minimum Business Increments as the guide for what to work on across the organization.

n is often not a real possibility. Consider when vertical applications drive horizontal support systems & at scale. In a financial company one might have verticals for – banking, credit cards, signature programs, loans. These feed horizontals such as – payment processing, transactions across accounts, client account setup and maintenance … In a situation like this, splitting up the horizontals into trains to work with the verticals won’t necessarily work well – either when you run them as separate trains or as part of the vertical train. Running the horizontals as separate programs doesn’t solve the problem either as they are each pulled in multiple directions. In these cases, it is often best to create visibility on the work to be done by using Minimum Business Increments as the guide for what to work on across the organization.


This blog is an excerpt from my upcoming book –Achieving Business Agility at All Scales

Rethinking ScrumBut &ScrumAnd

This is an excerpt from a chapter my new book Achieving Business Agility at Small to Mid-Scale.

Scrum.Org defines “ScrumBut” as meaning “that Scrum has exposed a dysfunction that is contributing to the problem, but is too hard to fix. A ScrumBut retains the problem while modifying Scrum to make it invisible so that the dysfunction is no longer a thorn in the side of the team.”

But ironically, Scrum limits the options of how to fix this dysfunction by requiring its immutable roles, rules, artifacts and events be followed. If one fixes the dysfunction by dropping a Scrum practice while adding a non-Scrum practices the team is still doing “Scrumbut” even though they’ve eliminated the dysfunction. But now, by not doing Scrum they are in unfamiliar territory since Scrum does not provide insights on the intention of each of its practices. This tends to have new teams in particular, that don’t understand the intentions of the Scrum practices, have to stick to Scrum or go outside of the range of Scrum.

If people just abandon practices without adopting a new one to fulfill its intent ScrumBut is likely a bad thing. Substituting practices requires understanding the intention of the practice being substituted &a set of alternatives to choose from.

This is an excerpt from Lean-Agile at the Team: A Lean Approach to Scrum &Kanban. See 1st comment for url

The Relationship Between Visualization and Reorganization

This is an excerpt from a chapter of my new book Achieving Business Agility at Small to Medium Scale.

An advantage of using Lean-Thinking behind both Scrum and Kanban is that both tend to ignore one or the other in their own manner. Scrum prescribes reorganization into cross-functional teams while LKU Kanban says reorganization is “orthogonal to Kanban” most likely because LKU Kanban is based more on theory of constraints which does not focus on reorganization.

Lean-thinking suggests using cross-functional teams in product development. But you should only do this you can see what is happening. This delay may be measured in hours or months.

You don’t need to reorganize when you use Kanban, but that doesn’t mean you shouldn’t when it’s appropriate. Don Reinertsen tells us “flow when you can, pull when you must.” Reorganization to achieve flow instead of needing kanbans is a tenet of Lean.

Lean suggests the use of ‘workcell’s (teams in product development). This enhances flow while enabling more innovation. Reorganization when guided by visualization & the theory of flow can be a very effective tool. It should not be ignored.

If you know Scrum or Kanban your next course should be in a course that covers what you don’t know

I’ve written recent posts about stoping the binary thinking & a Manifesto for Agile Learning. The key point of both is that breadth is more important than depth. If you’re an SM you may have the concepts of Scrum & Agile down, but may not have what you need regarding Kanban. If all you’ve done is Kanban, there are concepts in Scrum that are quite useful as well.

I co-founded Lean Kanban University w/David Anderson (I’m no longer affiliated). One reason I left the organization was what I perceived to be a tunnel-vision view. “Visualize, don’t reorganize” is limiting in my mind. Cross-functional teams have shown to increase innovation and reduce handoffs. I’ve always like Don Reinertsen’s statement “flow when you can pull when you must.” Flow is not just about using kanban &visibility.

This is why we’ve created Team Agility, a blend of the 2 and The Net Objectives Coaching Academy for Scrum Masters and Agile Team Coaches. It’s more about effectiveness using all of the methods available instead of mere certification.

Let me know if you’d like to learn more.

NOTE: i know many Scrum & Kanban trainers who teach both, I am referring to the orgs that promote only one.