Tuesday, November 1, 2016

The Breakup

True Story.

It was a painful breakup.  I thought things were going fine, but “it’s not you” she said “it’s me”…. and just like that, our relationship was over.

I really didn’t see it coming. We have been working together for a long time now.

Really?  Really, I said.  You no longer need QA?

She went on to explain that as her team has gotten better and better at building software, the whole team has taken more ownership of quality. They are on a pretty consistent cadence now and have working tested software ready to ship every two weeks...which is just about the time it used to take to just get through a QA testing cycle.  “We are just moving way too fast for that nowadays” she said.

At first I was incredulous. Everyone needs quality assurance!  QA is an essential role!  You can’t just pump out code and hope it is good enough. The customers would crucify us for that. At first, I thought what she was saying was ridiculous, but the more she explained it, the more it started to make sense. Her team had started Test Driving development a couple of years ago and now they have really high levels of confidence in the entire codebase. “It’s a team quality thing” she said.

I knew this team was good. The code is both Clean and SOLID. Their quality metrics are on par with any other team. They consistently produce 90% automated test code coverage, including code branches. Code reviews made sure that everything was covered, and they had automated jobs that broke whenever they decreased that coverage. Ultimately, they have virtually no defects that get into Production; some of the best code there is. They also have automated acceptance tests, UI tests and load and performance tests. They have pretty much automated the entire testing pyramid.

Test Driven Development (TDD) was just the start though. Soon after the programmers were test driving, the QA folks started automating UI tests in Selenium. To learn how, they had been pairing with programmers and their relationships in the team were the best of any of my QA teams. After that, they started using CucumberJVM to build behavior tests with the Business Analysts and the Product Owners. The pace of development with this team was better than any other team and I had pretty much let the team run on autopilot because they never seemed to have the same kind of problems the other teams have.  

“We no longer have a QA verified cycle” she said.  “We have renamed it to ‘Team Verified, because the whole team does testing before we demo it”. She went on. “We’ve also taken ownership of exploratory testing. The whole team does exploratory testing every week and this has really been a place where the QA folks have been a big help.”

“So you do need us” I said. “Oh yes” she said, “your people are great, but let me explain. We still want all the quality experts we can get.  As long as they are committed to the team, are committed to continuing their learning, and stay with the team every day”.  She looked right at me and said, “What we don’t need is all the management oversight we used to have”.

I was beginning to understand. I realized that she still wanted quality. In fact, she was more dedicated to quality than just about any other team in the organization and we are a huge organization. She was advocating for a level of quality the other teams could only hope to duplicate.  
She went on to say, “we’d like to keep some of your team members if we can”.  “What do you mean?” I said. She went on…”Most of your team members have embraced the changes we have introduced.  They love test automation, learning and the collaborative nature of how we produce quality now.  And those folks have a place on our team.” She went on, “The QA folks really took a leadership role with exploratory testing. We want to keep them because they see things differently.  They look for anomalies and edge cases and they really help the team round out all the aspects of testing that we need.”

Granted, this team has really taken agile adoption and self-organization seriously. They really epitomize teamwork. They do not behave like an assembly line, passing work from one role to another.  They’ve eliminated a lot of the limitations of specific roles in the team room through organized cross-training and pairing. For just about any task, most anyone can pair with someone if not complete the task themselves outright.

“But we move fast now, as a team” she said.  “And I guess what I’m saying, is that we want to keep your folks on the team and...well, there’s still a lot more that I can go into, but the short answer is...We just don’t need a QA Lead anymore.”  

I was crestfallen. The breakup wasn’t painful from her perspective. The pain was all in my head.  It was just a matter of my realization that self-organizing teams don’t need as much management as a traditional team.  The whole team owns quality now, and, I suppose, in the long run, that’s going to turn out to be a really good thing.

Monday, October 17, 2016

Yoga and agility

My wife dragged me off to do yoga this morning and I’m glad she did. The instructor really got me thinking with some of her instruction. She had a theme today around how yoga is not the poses or the positions or even the movements, but rather a state of mind.

She repeatedly pressed us to get in a yoga mindset. The mindset of balance, and centering and relentlessly seeking effectiveness with our bodies in such a way that it propels us not just through the yoga session, but through the rest of our lives. Pretty existential stuff really, but it was resonating with me for some reason this morning. Maybe it was because it was early and I just had an open mind, but while she talked, I kept thinking about how what she was saying related to business agility.

I’m an agile transformation consultant, and so this conversation around what constitutes “agile” comes up repeatedly.  I can’t tell you how many times I’ve heard someone say “If you aren’t doing <practice>, then you’re really not Agile”, and I grimace a little, remembering that exact thinking in myself a while back. In 2002, when I first started learning about agile, I eagerly fired off a message to Ron Jeffries. Ron is an original signer of the agile manifesto, and I asked for a short list of the “required” agile practices. His response was unexpected. He said I was focusing on the wrong stuff and to reorient my thinking.  “It is not about agile” he said, “it is about excellence”.

I’d like to say that I “got it” immediately, but I didn’t. I’ve been working with organizations around agile transformations in one form or another for what seems like ages, and I’m still catching myself being a bit dogmatic at times; maybe we all do. I think it is human nature to want to get to some solid answers even when there is no single “right” answer. I guess it goes to show we are all learning all the time.  


Websters defines agile as “able to move quickly and easily”. It does not mention process(es) or practice(s) but rather alludes to skill, or ability; a way of being. Being in the learning, the discovery, the unfolding of how to become excellent is very different from learning the steps to a new process, new templates, or new tools. Learning, whether it is learning to drive a manual transmission, or learning a new approach to solution delivery, requires us to be open to the ongoing discovery of the domain.

This is an important distinction for me because it points to a different manner of adoption. As the saying goes, we have to learn to crawl and to walk before we can run, but that doesn’t seem to stop us from trying to get ahead of ourselves. I’ve witnessed teams where a light has gone off and they become thoroughly committed to Test Driven Development (TDD). The approach is proven to help teams “be” agile rather than just go through the motions. There are real, measurable competitive advantages.

That being said, I’m not big on “Best Practices” without context. Test Driving is a very good practice depending on what you are out to do with it. There is a significant initial learning curve, but it has repeatedly been a way for teams to increase both velocity and agility. It helps them automate in a multitude of ways and be responsive when new requirements emerge or changes are needed.  

It is not however, a panacea to be blindly adopted across the board. I’ve seen teams misinterpret enthusiasm for TDD on new development projects and embark on wholesale efforts to retrofit all of their current codebases with automated test suites. Legacy rescue, is not an effort to be take lightly and trying to do so, in my experience, can end up being both an expensive and a wasted effort.  This is true particularly if it is on a codebase that is going to be sunsetted in the not too distant future. The effort to retrofit automated test suites always seems to be harder and take much longer than expected. I have helped a team do it successfully, though it took years of continuous effort. Your mileage may vary.

Rather than zero in on rituals like standups and retro’s or jumping straight into test driving, I recommend three fundamental changes in thinking:
  1. Impediments and dependencies can bring delivery to a crawl. Clear the runway for teams to go fast.
    • A well groomed and prioritized backlog is one of the most effective ways to help teams focus on the work at hand and quickly get the work done.  
    • This also is an area that scales organizationally. That is because the way we bring work to the teams starts with the Business Portfolio, is vetted, designed & planned primarily by the business, and if done well, has the majority of issues & dependencies addressed or accounted for BEFORE the teams start to work on it. 
    • Well groomed backlogs sounds straightforward, but in my experience, truly addressing dependencies and impediments prior to taking it to the teams is one of the most challenging parts of “being” agile.
  2.  Set teams up for success
    • Teams need a full compliment of skills; this includes architects and DevOps.  They need all of the roles required for delivery, and, if there is any possible way for it to be done, they need to sit together. 
    • Teams need an ability to get work done without impediments, and not having everyone that is needed for execution on the team is a barrier to successful delivery and that means no matrixing. For many organizations, this is a significant challenge, but it is essential to building trust.
    • Teams need to stay together. To gain synergy and increased velocity, projects can come and go, but the team needs to stay together through tough times and good. Teams need trust and the reliable iron will of trust is built, not when things are going great, but rather, through adversity met and conquered...as a team. 
  3. Be clear about the ultimate situation(s) we are out to produce. Get feedback from customers.
    • Working tested software can mean very different things for different organizations. Teams need to know what success looks like. From the satisfaction of the customer, to the satisfaction of the shareholders, teams need to know where the bar is set.
    • Delivery of a project is only the beginning. Teams stay together because customer satisfaction is a much longer game than the last release. Teams need to maintain ownership of having built a solution that will accommodate changing needs and changing markets for the long haul. Solutions need to be built for agility.
Agility is not just flexibility in how to do things, but in what we choose to do. If that were not the case, it would be called “static” rather than “agile”. So, the next time you hear yourself, or someone else, saying “you have to do <blah>, to be agile...question, with all sincerity, whether that particular practice really produces agility.
Websters is helpful. By saying agility is the ability to move quickly and easily, it helps us orient around skill rather than practices or rituals. That yoga instructor was helpful too though. She helped me see that adopting an agile mindset means that we can focus on a few fundamental things while still maintaining the latitude to do them in a multitude of ways.

The yoga instructor was articulating it very well this morning. It is not about the practices we are doing that everyone sees, but rather, our own story, on the inside, of why we are doing them, and our relentless pursuit of excellence. The ability to move quickly and easily is a learned behavior. The world keeps changing and we keep learning, and as such, our answers around what constitutes business agility will likely keep changing too.

Tuesday, May 31, 2016

The Agile Chip

The Agile Chip

I’m a Detroit guy and I like cars, especially fast cars, and nowadays they have computer chips you can install that make your car go faster. Imagine that, just plug in a chip and press on the accelerator and vroooom!

I’m also an agile coach and I see patterns.  With most every agile transformation I see a pattern when we start to talk about velocity and sustainable pace.  Some folks really zero in on just the velocity part.  It feels like they just found a new chip for their car and with visions of caffeine infused programmers they are thinking about hammering their right foot on the accelerator.

Going fast can be a beautiful thing. With these new action cams we can watch an Indy Car Champion take a car through its paces and it’s like art in motion. It is also a beautiful thing when an agile team starts getting great gains in velocity. There is art to that as well, and the teams that are achieving great gains in velocity travelled a long hard road to get there.

Teams that are test driving and producing both Clean and SOLID code from the outset as well as having fully automated test suites are rare. These teams have well-groomed backlogs and they manage their commitments to the organization based on both previous velocity and sustainable pace. They are craftsmanship focused and continuously improving both their practices and their craft. But it doesn’t happen overnight and it certainly isn’t as easy as installing “An Agile Chip”.

Teams need an opportunity to build up their skills and get a stable velocity before they start looking at going faster. And they need help too. They need well-groomed backlogs, dependency free Epics, a clear understanding of what “done” is, and a clear roadmap for wherever they are going. All three of these; backlogs, working testing software, and the strong teams that produce them, take some time to develop.

The backlog is like the roadmap for the journey, and all of the epics and stories are like gas in the tank. Working tested software, is very much like the car we are driving, and of course the team is the driver. Yes, the team is the driver and the team presses the accelerator.
So where does that leave a manager?  Especially a hands-on manager who is used to driving the team or committing to a specific velocity?

The team still needs you to be vested and committed to their success, but the role changes from being hands on, in the car, to more of an owner in the pits. Teams need someone to clear the way for them to go fast. They need someone to help alleviate organizational impediments that can slow them down. They need the commitment, but to a new cause.

Race tracks are designed for speed. There are very few rules around how you drive; you just need to concentrate on going fast. The roadway is clear of impediments and it’s kept clear. Pit crews help, spotters, telemetry, everything around the team basically, the whole environment, is set up to go fast.

A lot of organizations are set up like a busy City Street. There may be some architecture that can be simplified or modularized.  Process overhead can often be streamlined if not eliminated.  Build and Release Management may be ripe for automation.  Testing Automation can be another opportunity, and the list goes on.

A vested owner, helping clear the way for the team, can produce incredible opportunity for the team to go faster because otherwise, the roadways are basically full of impediments and organizational stop lights that slow everything to a crawl. If the environment is not set up for speed you can have the fastest of Indy Race Cars and it’s not going to get anywhere. The team is just going to sit there revving its engine and wasting energy.

Today’s agile teams are brimming with brilliant knowledge workers who don’t need traditional management.  They have pride in what they do and they love seeing what they create getting used out there in the world.  They care about their customers, their teams and their craft, and they can be trusted with the race car.  Give them the keys, clear the roadway ahead and you’ll be pleasantly surprised at where they take you.