Baking in Quality

“Quality is everyone’s responsibility” – W. Edwards Deming

Being someone who started their software career in the field of testing and later moved on to lead groups to implement automation within testing groups, I have a strong belief in the value of tested software. That being said, as we have shifted into the world of agility, the idea of “tossing features” over the wall is an antiquated and less productive way of thinking. Software testers, QA or whatever you want to call that domain do NOT assure software quality in isolation. I have been thinking a lot about this lately as we are examining test automation and it has been primarily at a GUI perspective and it makes me wonder if we are fascinated with the tools or actually have a solid test strategy.

When I began my journey towards becoming more agile, I came across a phrase very early on that has stuck with me and helped not only shape my ideas of software quality but also discard some of my previous teaching as a quality domain professional. The phrase is the title of this blog post … “baking in quality”.

I suppose this resonated with me initially based on the bad experiences that all testers face in their career where they are provided features late, largely untested and often in compromised product  schedules.The idea that as a team we would ensure quality appealed to me as it made it a shared responsibility of the team as a whole and not the sole domain of the angry tester telling the developers why their code is full of bugs.

In direct response to this when I began building software teams, I routinely asked the question “how many testers are on this team”? Commonly, I got the answer that only counted the people that had expertise in the testing domain. To which my reply was always, “I see N number of testers” (replace N with the total team number). It took a while but the phrase “everyone is a tester” is something I hear routinely although I do not think it is at maximum effectiveness just yet.

Adding the Right Measure of Ingredients

Mike Cohn in his book “Succeeding with Agile” talks a lot about the idea of testing and how automation is critical to the testing process as teams mature and become more effective. Almost every new team starts out with manual testing of some sort and the pains of this practice show very soon when the teams start hitting a consistent cadence. Without good quality practices many teams, including my own teams, begin emulating a “mini waterfall” method in which test domain experts spend a great deal of time front-loading manual test scripts and being delivered features late in the sprint in which they scramble to get “tested”. Even with the “everyone is a tester” belief ,the primary test expert is often overwhelmed by the wall of days of code development and scrambles to meet the commitments made by the team. Most testers are used to this “stuff rolls down hill” scenario and are often powerless to avoid it. But I think there is a better way to “bake in” the overall quality of a product. Will it be easy? For some, maybe as they are well on there way bt for others it will be a large hill to climb. The great thing about being truly agile is we evaluate small experiments and adapt and adjust as we learn.

Mike Cohn and Martin Fowler both talk about the testing pyramid. If you are well read in quality techniques or have a lot of experience in the test domain, you have likely heard this term. The traditional way I was taught to incorporate this philosophy into testing looked something like this:

invertedPyramid

This stemmed from the idea that testing at the user interaction level would yield the best results in terms of finding problems. This approach was a standard for a long time in many gated project methodologies. I made a career pivot in teaching others how to effectively use testing tools, many of which are targeted at the E2E (end to end) GUI level, to build scripts to do this. But given we are developing the system in an iterative fashion these days, this diagram no longer makes sense. (oh my shattered innocence)

Cohn and Fowler talk about the inversion of the pyramid focus in terms of agile development so that it looks something like this:

test-pyramid

Part of the realization behind this is that with the system being iteratively built, the volatility of the interface (and therefore the GUI script fragility) can be slow and costly to refactor in the midst of building new features. Many teams work to mitigate this through adding a specialized role to focus on test automation, but this is again an increase in cost (as it adds a speciality person to the team) and promotes a decrease of team ownership of the quality of the product through relinquishing this responsibility to “the automation dude”. Some create a shared service that works across teams to take on this responsibility and typically the expanded scope of this person means they need to maintain multi product and possibly platform understanding and therefore defects may come later into the mix once the scripts are shored up. These folks are almost always focused on E2E regression tests and do to their spread scope, they are often just churning out scripts with little quality oversight to their own work. So this is where Cohn and Fowler flip the approach towards a “baking in quality” approach but one that uses significantly more code level testing and less GUI level E2E testing.

Their assertion is that if we are maintaining a solid base of unit tests (maybe even couple with gated code checkins) and upon that building what they call a strong “service” level of tests, which they define as “the points in which the application responds based on a set of input or inputs” that a large degree of code that is small, fast and repeatable is available to exercise the system regularly. This also alleviates working on redundant GUI level tests for validations and the focus can be for more “user journey/smoke tests/happy path” tests for E2E. This means that tests can be adjusted as a part of the overall code base for the most part and that the focused efforts of GUI level testing can be more targeted to perform an overall goal action.

So, what does this mean in practice?

It primarily means that if we want to make a shift towards “baking in quality” our strategy might be to focus on building in quality as we construct as opposed to trying to post build or bring in specialized people whom we entrust to build in this quality. It means that if we think that the quality of our products are important that we build in this discipline to how we work as a whole, not as a sub-process. It means we internalize the concept that “baking in quality” in how we build products, is what we do as a culture.

Before all of the automated tool vendors gather their armies and seek me out (as I have used a lot of these tools and like a lot of them), I do see a tremendous amount of value in both commercial and open source testing tools and frameworks. The thing I do see is the same thing I saw when I was brought into companies to help them with automated tests; either their testing practices were weak or they were amazed by a sales demo and were ready to automate everything based on the sales pitch, which always worked, in the hands of experts and in controlled environments, flawlessly.

But as I am often noted to say, “I think we may have our emphasis on the wrong syllable”. Maybe we should be doing as these agile pioneers suggest and working towards baking in this quality through solid coding practices as a complement to effective use of automated e2e GUI level testing. Maybe we’ll bake in more quality as a whole within our products.

I have spoken to a great deal of testers who have told me all of the amazing things that their automated GUI scripts have found in terms of defects and monies saved. I get it. GUI testing of systems has value. I agree. As a matter of fact I whole-heartedly agree, especially when it comes to becoming even more “dev-opsy” and you can provide operational deployment scripts which run smoke tests so that they can execute them as needed and feel confident about a deploy. So, don’t shoot the messenger here.

However, I do also believe that effective use of code level testing + guerilla and manual testing + GUI regression and smoke tests might be an effective recipe as well. Some of this can be supported with the challenge I put forth in my last blog post ( Just one thing … ) recently.

And will it slow down a team initially? Likely. But I think it can be accepted and will pay dividends in terms of more quality produced code and products overall in which extensions can be tested to effective ensure less “breakage” across a sea of code. And I believe once the practice becomes ingrained, the velocity of delivery will become consistent. It also allows you a terrific pairing mode opportunity for new hires to learn about code under construction.

So as usual, I am up to run an experiment to see if this works and bakes in more quality in products effectively. Are you? Have you already done this?

Just one thing …

Curly: Do you know what the secret of life is? [holds up one finger] This.

Mitch: Your finger? Curly: One thing. Just one thing. You stick to that and the rest don’t mean s***.

Mitch: But, what is the “one thing?”

Curly: That’s what you have to find out.

Jack Palance and Billy Crystal  from the movie “City Slickers”

I always found this scene amusing when I was a kid. The old ranch hand trying to teach a city guy the value of focus for clarity. Of course at the time I just thought it was funny. After all these years, I realize that Curly was teaching a true agile value. Focus.

Focus is that thing that often gives us clarity. It gives us the ability to think deep thoughts and really unravel an idea. It allows us to extrapolate from a big thing into discrete pieces upon which we can undertake. It applies to things in life as much as it does in software development. I have started to really appreciate this as I prepare for an upcoming house declutter and move.

Do I allow myself to always embrace this seemingly simple approach. Nope. I, like others, allow myself to get too “focused” (and I use this term loosely here as it really not focused at all) on too many things. Like those performers that are spinning plates on a skinny stick, I find myself focusing on keeping them all spinning sometimes. But, as I am want to do, which often results in a blog post, I find myself stopping, breathing, thinking, assessing and questioning my current chartered course. So here we are.

Focus is a core value in agility as it allows us to actually be more productive by allowing ourselves to work to accomplish “that one thing” as Curly put it.

Under scrum, we demonstrate this through the user story, the task decomposition in terms of work effort. We use focus in terms of daily risk mitigation through a focus meeting called the  stand-up. We focus on the features committed within the review and the team within the retrospective. If you look closely, focus is woven throughout

Kanban has WIP and the innate concept of “pulled work” which itself a way to focus and measures this through the idea of how effective our focus on delivery is through things such as cycle time.

But there is one dimension in which I often see less focus. In the process of delivery. What I mean by this is often I see scrum development teams use a “divide and conquer” approach in which teams members use their specialized skills to scatter and seek to deliver. They are in no way being less agile in this approach but I have always wondered what would happen if they allowed themselves to focus and iterate just like the larger product. There are examples of this. Just take a look at Woody Zuill’s mob programming or pair programming as outlined in Exteme Programming by Kent Beck.

My latest read, “Joy, Inc” talks about the use of pair programming as the standard way of how they hire and how they work. They see it as not only a way to create shared knowledge by this but also to ultimately be more productive.

So, I have posed this question many times to developers and often get the same response “well, development doesn’t quite work that way” to which I often reply “are you willing to try an experiment and either fail or be wrong”? *smiles*

My logic has always been that if a sprint backlog is supposedly composed of a top to bottom prioritized list of the highest business value, wouldn’t we want to work through the items (given we identify any dependencies and work to minimize those with the product owner) and focus to deliver each story in that manner during a sprint? Or even look at the absolute most complex item and focus on completion of that story and then work on the lower hanging less dense fruit?

I see 4 potentially significant benefits that could result from this:

  1. We get items in front of our team members specialized in quality quickly so they can assess features for compliance to acceptance, note any software issues or quality enhancements and they can become productive more quickly. They are reviewing and testing completed features, even if there are mocks behind some dependent needs of other stories. They also are able to learn a portion of the system under construction and build automation against it for regression more quickly if needed.
  2. If we for some unforeseen reason we are impacted to effectively deliver on all stories for our commitment, we can at the first responsible moment, assess remaining team bandwidth, current deliverable dependencies and make decisions so that we can have that conversation immediately with our product owner so we can remain transparent on the impediment and impact but emphasize our focus on the highest priorities or largest complexity first.
  3. We reinforce iterative development at the lowest level of development (by using refactoring and integration as part of the way we work) and can focus on ensuring that we meet our agreed definitions of done at each story level.
  4. We “should” end up with a set of features tested early which should allow us to as a team to swarm baking in quality for our product and preparing for our review at sprint’s end (given we did not over commit …)

So in my view this approach makes sense to me and I have worked on teams that worked this way and we remained productive and felt like we were accomplishing more towards our product goals. We effectively delivered features regularly for review for the stakeholders.

A lot of folks may be reading this and joining the chorus of previous conversations saying “yeah, sounds good but you don’t really understand” …

So I reply to you all … “are you willing to try an experiment and either fail or be wrong”?

 

Customer Service

“You are serving a customer, not a life sentence. Learn how to enjoy your work.”                      – Laurie McIntosh

This weekend I had to run some errands and I arrived at a local business just as they were opening to pickup a delivery. I stopped at the drive up window, rang the bell and patiently waited. A clerk came rushing in sat her items down and opened the window … “Name”, she asked sharply to which I provided her my name. She fumbled around and said in a tone as if a burden were being placed upon her “We just opened. It will be at least 30-45 minutes”. I thanked her and said I would return in about an hour. She closed the window and walked away.

As I drove to another place where I could occupy an hour (as returning home and then coming back would be pointless due to the drive) I began to think about customer service. Not about this particular incident specifically but what “customer service” really means. Customer service is defined on the interwebs as “the assistance and advice provided by a company to those people who buy or use its products or services.

This being the case, on face value, this woman provided customer service as she indicated how long I should expect before my delivery was prepared, correct? Sure, she absolutely met the definition of “assistance and advice”. But did she delivery it in a way that made me happy to be a customer? I would say not. Her rush into work and exacerbation from that experience translated to how she provided that customer service. I get that we are all human and are affected by life’s experiences but sometimes in the service of others we have to rise above all that. Easy to do, no. But something we should think about in terms of customer service.

The reason I began thinking of this as it made me reflect on a story I had read about Zappos and its early beginnings. One of the values that Tony Hsieh strives to instill in each and every employee is the ideal of amazing customer service as the experience from that places an imprint on people that make them want to return and do business again.

When his company was first starting out, he was courting  all of the major shoe manufacturers to stock his warehouse (as they learned that controlling the shipping timelines was another way to maintain a good customer experience) with their brands so he could provided diversity and brand loyalty names. On one particular case, he had been out for dinner and a lot of drinks with a particular rep from a company and they returned to the hotel at the early hours of the morning. Tony had spent the night selling the representative of this manufacturer on the core customer focus that Zappos had and how their superior customer service. The representative, probably a bit tipsy, told Tony that he wanted to see how “customer focused” his staff really were and if they were as he said, he had their account. Tony agreed to take that gamble.

The representative called Zappos, again in the wee hours of the morning, and got through to a customer service representative. The call center responder answered with zeal and said “This is Zappos, how may I help you”? The shoe representative said; “yes, I would like to order a pepperoni pizza please” in a tone of seriousness, fully expecting the call center to become angered and explain to him :”that is not what we do here sir”.

Instead, the call center representative said in a pleasant tone, “may I have your location sir”? The shoe manufacturer provided it to which the call representative stated “please hold one moment, sir”. The shoe manufacturer waited a moment and the call center came back on the line. “Sir, I apologize that we are unable to meet your need directly, however, based on the location you have provided to me, I have a list of local pizza shops that I can provide to you, the closest being open until 4 a.m. Is there any other way I can assist you sir?” Flabbergasted, the  shoe representative took the number and thanks the call center representative. The call center representative closed the call by thanking the customer for their call.

Over a late night pizza, the shoe manufacturer gave Zappos their business.

This may be an urban legend, but it makes for a good story for sure it demonstrates to me what customer service really entails. The call center representative adapted to situation. They did not become frustrated because some intoxicated person called wanting to order a pizza, clearly not what they did. Instead, they used the situation to continue to provide excellent customer service and potentially establish a customer for tomorrow.

Isn’t that the core of customer service? Our goal is to “help the customer”. This is something that we cannot always do directly but if we go back to the definition of customer service as “the assistance and advice” this means that sometimes we help them by providing them with a direction, not a solution. We have to be willing to maintain that focus to help assist and advise even if out of scope. Does it take more time, sure. Does it mean we may have to try and find information that they could have found for themselves, absolutely. But being focused on customer service means you are there to guide that customer to solve that problem through your direct action or by helping them get a point of direction to that solution if at all possible.

So, coming back to my experience; did the lady provide customer service? Of course she did. She told me when I should return and my order would be ready. And when I returned, it was ready. I thanked her and went on my way.

Could she have left her frustration for being late for work out of the context of her customer interaction with me? Maybe. But that is an area for personal growth for her, not the basis upon which I judged if she provided the end customer service. I weighed this against the outcome. Her brief frustration did not make it a situation where I felt as though I received bad customer service. She was rushed from being late to work. It happens and as a result if we are faced with an immediate interaction, I cannot say that I would have handled it any better.

Are you “advising and assisting your customers” or just merely dealing with them?

 

 

Recommended Read

“If you’re comfortable with the amount of freedom you have given your employees, you probably have not gone far enough”. – Lazlo Bock (Work Rules!)

I recently completed the audiobook of “Work Rules!” by Laszlo Bock (I went back a read passages I really wanted to dig into in the paperback as well). For those of you who are unfamiliar, Laszlo Bock is the Senior Vice President of People Operations for Google. He shares a very interesting insight into how they apply programs, policy and practices that impact employees and surprisingly how much data they collect to understand if they are actually making any real impact to the employees or the culture at large.

Some of the mystery about what/how and why Google does some of the things they do were outlined in the book. A few of them were:

  • Many of the services (like the haircut bus) provided to Googlers are at no cost to the company. It is often a brokerage between people operations and businesses for them to generate business buzz and customers. Many of things are often out of pocket for employees but adds a convenience factor for them to not have to schedule time to go and do these things.
  • The “micro kitchens” famously known at Google that allow googlers to grab a snack, a coffee, water, etc are actually spaced throughout the campus with intention to stimulate “unplanned interactions” where people from groups that might not directly work together might interact or spark and idea in one another.
  • Google has a performance management process and it gets scrutinized for effectiveness and adapted to bring the most value.

There are some really interesting ideas in this book. Not all of them are applicable to every organization but the underlying message is. If we have people focused on the operations of people and people are our greatest company investment, where is the downside?

The spirit of this book will hopefully inspire you to just think differently about how you can impact your culture in small ways and use data to determine if the “perks” you are providing are doing what you intended. I was so inspired by this book that I bought an extra copy so I could share some of this with our human resources, who are progressive thinkers as well.

I would highly recommend this book if you are leading a team, transforming an organization or maybe are part of people operations in your own company.  It will definitely inspire you to think about what things that you might be able to do to enhance the work environment and how you determine if it is working.

Stay Agile! 😀

 

 

 

 

 

 

Being Genuine

“You need to believe in yourself and what you do. Be tenacious and genuine.”

– Christian Louboutin

Genuine. Authentic. Real.

I think about these words a lot. I continuously question myself if I believe what I believe or do I just do what I do. Sounds like a lack of faith and maybe it is. I can exude real confidence in ideas I believe in as ideas are often very meaningful to me and my life.

I love to think, discuss, brainstorm, pontificate, learn, grow, teach, coach and collaborate. So ideas hold a real tangible value for me. But often times, as I awake in the morning or make my drive home in the evening, I stop to question myself as to what my true beliefs might be and if the allure of the idea has me thinking I “think” that way.

You may wonder why so I’ll tell you.

One thing, if I had to identify that thing, that makes my blood boil or loses my respect is people who talk about doing something a certain way or following a certain path and then abandon all those things central to that in reality of what they do.

They “talk the talk” but are unwilling to “walk the walk”. The reason I question myself is that I believe in agility, the power of teams and the ideal that amazing things can happen through motivated, collaborative teams in which the economy of scale is end value and not time. This means something very special to me as I not only believe it, I have seen the power in it actually working.

However, being human, I am inherently fallible. My biases, my environment, my mood, history in general can all push me away from making decisions in alignment with these beliefs I hold. I realize that and always question what I know and what I am doing to ensure I am truly being genuine in my thoughts and my actions. And guess what, it’s a struggle. It’s a battle. You stay on the defense for this creepy crawly to come along and get you.

Just like the dieter who struggles to avoid Krispy Kreme donuts brought to the office, sometimes it takes will-power and the admittance of failure. But my realization of my ability to be wrong and my willingness to admit and learn when at fault keeps me going where I want to go at this point.

I am very fortunate presently to have one particular person that keep me honest that works in my group. They challenge me regularly about my thoughts and often make me examine things that might be uncomfortable to think about from a perspective of an observed flaw. They basically exercise the carte blanche that I extend to the people I work with to call me on my B.S.

But I truly respect and appreciate it, even if sometimes at the onset I may not be too  as often happy, feel annoyed at the challenge or just clouded from the value I am receiving from those conversations. What they do for me though, more than anything, is they force me to evaluate the perception of another about me and probe more deeply into myself to see if my actions are genuine and in alignment to my beliefs and values. This often helps me examine why I might be out of sync to my beliefs or presenting a poor perception of my intentions or actions.

In the grand scheme, I am respect and appreciate this relationship that I have with this colleague. One thing it does is allow me to gauge myself on my skills to actually listen to this feedback without feeling the need to respond. I know that this is a skill that I need to continuously work on. If you have never done a “seatbelt meeting” (where you strap yourself in and just listen to the good, the bad or the ugly feedback without response or defense but simply allow you to hear someone else’s perception) with someone, give it a shot. Not as easy as it sounds to do.

So take a moment and think about yourself and your actions. Are you being genuine?

 

 

 

Draw How to make Toast

Just a quick redirect to something I have stumbled across and found fascinating and wanted to share. This approach is an introduction to systems thinking and what they call “Wicked Problem Solving”. This is another approach from Tom Wujec who outlined another team approach to iterative innovation in the Marshmallow Challenge Website.

I just found this a very interesting way to get to core problems to solve for a group. Check it out:  Draw How to Make Toast Website .

Hope this gives you another tool in your agile toolbox to do great things!

Scrum Alliance Webinar

“One of the most sincere forms of respect is listening to what people have to say”

– Bryant McGill

I was very honored to be asked to conduct a webinar for the Scrum Alliance with my colleague and friend, Mr. Joe Kirk, about our agile transformation work with a state transportation department this week.

I really enjoyed discussing our journey and addressing questions for attendees.  The scrum alliance should be posting a follow-up to the talk soon in which we addressed questions for which we did not have time to do so during our talk.

Agile Transformation at Tennessee Department of Transportation