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.

Thursday, July 3, 2014

Agile Rigor & Autonomy

Value delivery is a skill and the value of knowledge workers is their innovative creativity, passion for their craft and ability to take on large and complex challenges without needing oversight or traditional “Frederick Taylor” type management to deliver.  In other words, knowledge workers can be trusted to deliver but that trust is certainly violated when agile teams start making excuses for failing to keep their promises.

Like something straight out of a Dilbert comic, agile seems to have acquired some convenient excuses for undisciplined delivery.  “We don’t do documentation”, or “We can just push what we don’t get done to the next release” being just a few examples of the memes of undisciplined delivery creeping into a team room. Worse than just perpetuating the IT tradition of failing to meet business expectations*, undisciplined delivery erodes trust and arrests any forward momentum a team has produced toward gaining more autonomy in their determination of team practices.  Less trust, over time produces more oversight, or at least the perception of the need for management oversight.

* Forrester research shows that 66% of IT projects fail to meet business expectations

Traditional product delivery, like for a car or other assembly line product is vastly different than delivery of a knowledge product like software.  On an assembly line, “working hard” is a virtue and overtime is paid “extra” and appropriately so.  Even with software, business commitments need to be made, and sometimes, that means overtime.  However, with knowledge workers, when overtime becomes the norm, innovation and creativity diminishes, and lower quality and burnout are nasty and sometimes unrecognized side-effects. Like a long distance bicycle race, the team needs to maintain a sustainable pace.   

Knowledge workers need autonomy, but not every agile team is ready to take ownership of the P&L and start collaborating with customers directly.  In the tradition of crawl→walk→run, some teams need to work their way toward higher levels of delivery maturity.  Organizational structures and team structures vary:
Organizational Structure
Team Structure
Level 5 - Innovating
Team has ownership of P&L
Team initiates craft improvement practices

No need for Delivery Lead or PM
Self-Referential Teams
Team self-identifies for value and looks to team members for craftsmanship and skill improvement.
Team may demonstrate open defiance of bureaucracy and the status-quo in acts of solidarity that force the organization to confront archaic policies if not change them
Level 4 - Quantified
Fully Cross-Functional Team permeates into all business roles

Product Owner in the Team Room

Less need for Delivery Lead or PM
Self-Deterministic Teams
Teams take ownership of commitments to the business through team ownership of the backlog.
Team will self manage multiple simultaneous projects and how much if not also the priority of what is committed to.
Project Managers or Delivery Leads are no longer required.
Level 3 - Adaptive
Take the work to the team (Teams perpetuate though projects come and go)

Delivery Lead or Project Manager in the Team Room
Self-Organizing Teams
Teams still have managers/delivery leads organizing the backlog, coordinating with a product owner and facilitating reporting, however, the team has ownership of how it will self organize to get the work done. This is necessary first step toward team autonomy
Level 2 Operating
Co-Located Team space established
Teams are still formed for every new project

Still need a Delivery Lead or PM
Managed Teams
Teams understand agile practices, are fully cross-functional and co-located but are still learning, particularly organizationally, how to take autonomous ownership of execution of multiple simultaneous projects as a team
Level 1 - Beginning

People are not co-located
Organized around projects and functional areas
Sequential or inconsistent processes

Reliance on managers
Hierarchy or Command and Control
Clearly separate roles and separation of responsibilities
Task/responsibility rather than team oriented
Traditional project execution with managers determining what needs to be done, by when, by whom, and in what order

Violated trust is the key factor in not making progress toward higher levels of team autonomy, but also a factor in losing previously enjoyed high levels of autonomy.  How a team builds trust, maintains it and recovers trust whenever a breakdown occurs can be different for every team, but the intentional building of trust needs to be as much a part of a teams cadence as retrospectives.  An agile team that does not take delivery practices seriously, or does not perceive the need for higher rather than relaxed levels of rigor is putting itself at risk of becoming a liability rather than an asset for the business.  Agile does not mean do whatever you want and the business is just going to have to deal with it.  It means delivering, building trust and deserving the level of autonomy and latitude the modern business is giving its knowledge workers.

Friday, March 7, 2014

Agile Quality “Whole Team” Ownership




Agile Quality


“Whole Team” Ownership


By Tom Churchwell



Many times, QA is an event that occurs after development is done; like a chef tasting cookies after they are baked.  The common problem with that is finding out we missed a key ingredient after all the mixing and baking and frosting is finished; the worst time to detect a flaw. Good bakers test along the way and maybe even call a spouse in from the living room to taste the cookie dough too!  Getting direct customer feedback during development helps ensure quality throughout the process.  Finding flaws early provides an ability to adjust, adapt or start over with time to recover.  Metaphorically, quality cannot be “tested in”; rather it must be “baked in”.

If your teams are doing a lot of manual testing, or if you have a “QA Testing/Tested” phase after development, then your teams are likely attempting to test rather than bake quality in. It is a common practice and, for most teams and organizations, it is intuitively the way development has always been done. Most traditional IT projects stink; based on Forrester research, more than 60% are unsatisfactory. The QA after development tradition stinks. It is a tradition that produces untold and commonly accepted suffering by the teams delivering solutions and the customers who want to use them.

Breaking this tradition can require some changes to both thinking and practices.  Hiring non-traditional and highly collaborative thinkers, blending and overlapping roles, including the customer when things are still in flux and building for the capacity to adapt rather than “nail things down” are just a few of the changes teams need to work toward. 

Tradition dictates that roles should be clearly articulated and separated. Things should be done in a particular order with specialists doing their particular part in a particular way and at a particular time. Plans and processes should be clear and followed.  Requirements should be captured up front and fastidiously tracked. Being able to predict exactly what will get delivered, by when and how much it will cost is of paramount importance.  Changes should go through a formal change request process. And everything should be captured in writing. Everything should be well thought out, maybe even well documented ahead of time and if anything changes, the implication is that it was likely a failure in planning or execution and someone must have done something wrong.

As good corporate citizens, teams try to work with these background assumptions, knowing all the time that things will change and the team will have to adjust. The teams delude themselves by thinking that with the right people, and just the right amount of heroics, the team will power through the challenges and make the fixed deadlines. In reality however, superior quality falls through the cracks and chasms of miscommunication that exist between even the most well specified roles.  Two people may own their roles and execute in them to a “T” and still miss something major.  Examples abound where the customer says “That’s not what I wanted” and the developer retorts “That's exactly what you asked for in the requirements”.  Deadlines loom and hard choices are forced on the team and in many cases, after a painful deadline death-march, the project goes to production with significant flaws. For teams steeped in traditional software development practices, their suffering is perceived as a “normal” part of doing business.  

Changing the way we own quality

The whole team concept is founded in part on the emphasis on individuals and interactions over process and tools.  In it is the premise that all aspects of quality can be held by the whole team. Teams vary, and the degree to which they are ready to take whole team ownership varies as well.  With an effective and experienced QA Guide, over time, the knowledge, expertise, and capacity to “bake quality in”, can and should be held by the whole team.

Test Driven practices have been gaining momentum and with them, changing the way quality is owned by a team. The “Definition of Done” for Value Stories and User Stories changes significantly.  Meeting quality standards becomes a part of the “Definition of Done” for development teams and like our baker testing for quality all along the way, testing every aspect of a story is now accomplished throughout development.

Definition of Done

Starting with a big picture view of what is ultimately needed for the project to be successful, teams can move quickly to planning the most effective and expedient way to produce it.  Team members can then collaborate to specify what success looks like at the functional level (“Definition of Done”) and how the team might go about producing it for every story from inception all the way through to production.

Specifying a shared definition of done is something the team does collaboratively at the beginning of the project.  It establishes and reinforces beliefs, norms and practices for the whole team throughout development.  It is a reflection of the collective values of the members and the standards to which the team aspires.  Some of the standards may be dictated to the team, like the level of required automated regression test code coverage or some other metrics, but most of the standards should be specific to that team or that particular project. 

Many of the fundamental concerns will be the same from project to project, but the nuance of each project requires that the team come together to ratify a definition of done that the whole team can live with and can agree to hold each other accountable for.  Quality standards should be included as part of that definition of done.  Once specified, a QA lead or any designated team member can track, manage and report quality metrics both to the team and to management.   As much as possible, Big Visible Charts should be used to keep quality metrics a highly publicized part of the ultimate solution.  Big Visible Charts are a straightforward way to help everyone quickly know where the project stands and to foster the culture of quality with the team.  

Inevitably...It comes down to team

Agile solution delivery is a team sport and QA is a contributing member from the start.  As with a traditional project, some events occur in sequence, but with agile, many once segregated responsibilities are now owned by the team and executed as a team.  The agile approach is evolving and so too, is how QA participates on an agile team.  Many QA concerns and tasks are still the sole responsibility of QA, however, depending on a teams “Definition of Done”, many concerns and tasks may be absorbed and owned by the whole team.  In order to become a contributing member of an agile team, QA skills may need to be expanded.  Deep technical and development skills make QA a more powerful team contributor and helps to socialize the role of QA into the team as a whole.  This socialization of QA relieves some bottlenecks that have existed on traditional teams and opens up the possibility for increased velocity for the team as a whole.  The role continues to evolve, and with it, the possibilities for how solutions will be delivered in the future.

Sunday, October 13, 2013

The Best People

The Best People

Organizational Culture

Shaping and purposefully evolving a desirable culture in an organization is a non-trivial undertaking.  Building and sustaining a culture is as much about the art of becoming and reaching our own full potential as it is about the behaviors, practices, and memes of the teams with whom we work.  It is an ongoing seeking of the highest part of our own humanity and that of our organizations.
Developing a positive culture can have tangible business effects.  Daniel Goldman, author of Primal Leadership, reported that a study of service companies found that a one percent improvement in climate correlated with a two percent improvement in revenue; real, tangible results for a sometimes intangible “soft” subject.  A challenge worth undertaking, but producing behavior changes across the board is by no means a short term project.  It requires “seeding” the organization with the right shared values and then the dedicated cultivation of those seeds over long horizons of time. 
Interviewing for the Self is a practice to help maintain cultural rigor.  It is a fundamental practice to help ensure new members are culturally compatible and to reinforce standards, established practices and norms.

Interviewing for the Self

Technical organizations have a propensity to value technical skill over all other skills. If left to happenstance, the Selves that join an organization can, through no fault of their own, dilute the culture and slow the momentum of the teams they join.  Managed effectively, new team members just as significantly enhance the synergy of a team.  In every case, we can rest assured that cultural chemistry will change with growth. 
Successfully screening for values and maintaining culture despite rapid growth and the ongoing introduction of new team members is an art.  It requires an interviewer with a strong understanding of the current culture and norms of the organization and distinctions for assessing the exhibition of those values in others. 

Shared Values

So what are your team values? Every team is different. For some teams, the values are straightforward with a touch of irreverence. One of the teams I work with now clarified their values simply:
  • Courage - Don’t be afraid to piss people off.
  • Caring - Give a damn.
  • Learning - Try new shit.
  • Motivation - Just frickin’ do it.
  • Perseverance - Don’t bitch about it.
  • Passion - Kick some ass!
  • Fun - Have fun dammit.
While these may not pass muster with HR, they are the values this team demonstrates every day. They specified them as a team and they hold each other accountable through them. They may irk the politically correct in the organization, but that touch of irreverence is actually a clear indicator of a mature, confident self-organizing team that takes ownership of challenges and comes together to face them.

What are the values of your team? How do they promote autonomy and courageous teamful action? How do you help your high-performing team maintain momentum and drive for results? I'd like to know.

Tom Churchwell