Evolving Quality Through A Culture Of Learning with @ailuj876 : a #PNSQC2022 Live Blog

Good morning and welcome to day two of PNSQC from the Melody Center. Last night's festivities were quite enjoyable and I had a chance to go do one of my favorite "Portland Food Things", which is to get out to the various food truck areas. This was my first experience in the East side of the city. Cartopia and Hawthorne Asylum were my destinations and both offered a ridiculous bounty of riches to choose from. Very good, definitely recommended :).

Back to the conference...

Julia Pottinger,
QualityWorks Consulting Group

Julia Pottinger is the lead-off Keynote this morning and she is focusing on how we learn and the best ways to learn effectively. While conferences can be awesome, they do have expenses, not just in monetary costs but in costs related to time, attention, emotional commitment, and just how to translate a speaker's words and slide decks into actionable learning or, barring that, a plan for next steps.

This is an area I have also been struggling with a bit. How do we actively and effectively learn about things? How do we incorporate that learning? More to the point, how do we effectively put into practice what we are learning and what "learning culture" are we part of, either intentionally or otherwise?

A learning culture is not just about what you are expected to learn but how you learn it. I fully realize that some workplaces are both accepting and encouraging of conferences, meetups, and other events but that is just the first point of entry. If you have the benefit of a company that encourages conferences and sending their people to them, that's great. Many companies, however, look at conferences as taking people off of projects and the downtime is seen as a net negative compared to the learning gained. I realize that I am perhaps given more leeway because I was originally hired as someone who was known to speak and present at conferences, so I've rarely received any pushback for going and I'm grateful for that.

Perhaps the most important aspect to look at is how the company encourages learning and how they actually back it up. Many companies will expect their employees to learn what they need to but will not specifically carve out time for them to do it. It's expected that they will figure out how to learn what they need to and do what they must to learn what they must, on their own time if needs be. Fortunately, I don't work for one of those companies :). I think, in part, this comes from the fact that LTG/PeopleFluent makes software that primarily slots into the learning space and the employee performance space. Thus, we do our best to practice what we preach and sell. To that end, I can expect that, in any given sprint, I can slot out a story or two specifically related to training. It does mean I have to be forward with and advocate for my need to make that a focus. Once I have, In our sprint planning, I can look at what is on the stack, consider my time options and what has a pressing need, and based on that, I can carve out anywhere from 10-25% of a sprint to focus on training in some capacity. This is not always the case. Sometimes a time crunch or an urgent need comes up and there are sprints with no training time. However, I am encouraged to cover and discuss the learning and areas that I have mastered, even going so far as having a section in the software we use for performance evaluations so that we can demonstrate what we have learned and mastered. I often put up my conference talks that I have delivered, both for myself and to also share with others in my teams so they can learn from my presentations.

There are a variety of ways that people learn and we need to consider that when we approach both what and how we learn things. Some people prefer reading from books or online articles/sites. Some people prefer videos. Some people learn best from a variety and combinations of methods. Myself, I tend to enjoy seeing/hearing video commentary with on-screen examples because it gives me the option to rewind and re-listen to things as many times as I need to. Still, there's the watching/learning and then there's the doing/learning. As an example, I can read all I want to about how I can optimize my bench press or squat technique. Intellectually, I will know a lot but it won't matter much unless I go into a gym, load up a bar, and actually bench or squat using the techniques I've learned. The same goes for what we learn in tech space, too. We can learn all of the details about a programming language through reading or videos but we won't retain that information if we don't actually write code or implement the coding ideas presented and practice what we learn.

At a certain point, to have a true culture of learning, I feel we all have to get involved, and in some way take the opportunity to teach what we learn to others. This is not just a benefit to those who need to learn the material but it also helps us solidify our learning. There's an old Scouting principle that we refer to as "BOMOTO". That's short for "Buy One, Make One, Teach One". The "buy" is not literal in this case as it covers more than just purchasing an item. It's the acquisition of whatever skill or item is needed. "Make" is also not literal, but it refers to the implementation of whatever item or skill you want to learn/master. The "teach" is literal, in the sense that by teaching what you know to someone else, you solidify what you understand. You also identify the areas that you may still need to work on or learn about, and also recognize places where you may understand something superficially but not be as effective in explaining it to others. BE patient during the teaching stage, as it is not at all uncommon for the "teacher" to realize that they have blind spots or areas they still need to work on. Encourage that interaction. Over time, it will get better and your solidification of those skills will become more apparent. 

In short, champion a learning culture wherever you are, even if it means that "Patient Zero" is you. It's possible that you/me could be the catalyst to either introducing or improving the overall learning culture in our organization.

Señor Performo @SrPerf In Modern Times: A #pnsqc2022 Live Blog with Leandro Melendez

I realize I've been quiet most of today but that was because outside of my own talk, I was moderating the Process and Tools Track today. However, I'm here for the final talk today to hang out with Señor Performo (aka Leandro Melendez).

For those who are familiar with Leandro, you know he has made a name for himself in the performance space and if there's one thing he wants to make sure people understand, Performance goes way beyond load testing. Performance means that systems can withstand various stresses, handle numerous concurrent connections and perhaps most important, hold their functionality as the system scales. The performance also indicates that the availability and speed of transactions are important. In other words, we want to be able to keep our users engaged at a maximal level.

What are we looking for? We want to assure great response times, efficient and stable interactions, and do so in all situations. Big ask? Sure. A better question is, how do we actually achieve this?

Well, we may want to stop thinking about performance the way we always have. We need to step away from just doing load tests. We need to step away from performance testing being done at the end of development as an afterthought. We also need to perform multiple-step tests and actually perform tests that represent real-world traffic and considerations. In other words, we need to be able to see what a real production environment will need to work through. That means that freezing environments and playing hands-off with systems don't tell the whole story. There really is no such thing as pristine performance tests. Systems have to survive all interactions, not just those in sterile and theoretical environments.

Ultimately, Leandro thinks we need to change our perspective on our approach to performance testing. We need to be doing performance testing in a similar way to how we are doing our releases. At least if we are using an agile or DevOps style approach of CI/CD. Instead of big heavy tests on everything, we should be doing small but targeted tests on the actual areas that have changed. In short, we want and need to be able to get a reading on our performance issues not just at the end of a project or release cycle, but as we make each incremental change. In addition, there are many more areas we need to focus on, such as instrumentation, telemetry, and active monitoring. We don't want to just know when the system falls under the weight, we want to be able to see when and where Performance hits are occurring, well before we get into danger territory.

What Leandro is making a point to focus on is that Performance Engineering requires Renaissance Persons to perform. There needs to be a growth and development of skills for performance and rather than looking for one super performance testing unicorn, we should be creating teams of performance (I loved the comparison to a mariachi band :) ). In a true appreciation of the Shift-Left philosophy, we need to see performance be a goal and focus as early in the development process as possible, as every aspect of development (languages, tools, databases, infrastructure, network, cloud speed, and access) all can have an impact on the overall performance of the system. Additionally, every change and modification can have an effect on the system's performance. 

On the whole, this sounds like an exciting premise and focus for modern performance testing. Sounds like a lot of work but could also be quite exciting and interesting to implement. 

 

 

Back in the Saddle: A #PNSQC2022 Live Blog

 

Good morning from Portland!

It feels really good to say that as it has been three years since I've been able to be here in person. It's somewhat comforting to realize that life is, at least sort of, coming back to normal :).

This year is a little different, so I'm going to probably be a little more cattershot with my live blogging attempts this go around. I'm one of the first speakers this go around, as I'm giving a talk on "The Intersection Between Accessibility and Inclusive Design". The cool thing is that I'm part of the "Invited Speaker's track this go around, so if you want to, you can actually hear me speak in real-time and for free :).

If so motivated, go here :

PNSQC 2022 FREE Keynote and Invited Speaker's Track 

Vernon Richards, Quality Coach

We are starting out today with Vernon Richards (hey, Vernon, welcome to Portland :) ). Vernon runs the House of Test in the UK and has been a long time contributor in the Quality space so it's exciting to hear him talk about "Career Choices for Modern Day Testers". 

For many testers, there comes a time when they ask themselves "is this everything I'll be doing? Am I going to be "just a tester"? Let me start with the statement that there is nothing wrong with that and many software testers have very fulfilling careers being "just a tester". However, it has been my experience that we rarely get to have that simple of a career trajectory. It's been my experience that testers are often pulled in numerous different directions and often can have their run of the mill if they are so motivated to :).

Vernon is asking something along the line of my second string of thought, as in "what direction will I be pulled in, or should I pursue if so interested? I have experienced a broad realm of possibilities over the years and really I've often been given my choice of arenas to play in.

Over the years, I've been:

- a Sales Engineer of sorts (more a rapid response/Tiger Team debugger and problem solver but aligned with the sales team)

- a build master and Jenkins maintainer

- an automation specialist

- a customer support engineer

- a team lead for a variety of organizations

- a test consultant pulled into a variety of projects here and there as needed

- a podcast producer and moderator (not really associated with any direct hire job but I spend enough time on it so it counts)

- a writer of articles and book contributions (see above ;) )

The key here is that we each have to take command of and determine what it is we want to do and how we want to go about doing it. We have to be the source of the curation of our careers. No one is going to care more about our progress than we will. Yes, we may have members of our team who can help us and advocate for us, but let's be honest, they have their own battles to deal with and their own careers to chart. Fact is, you have to be a royal pain in the keister to others to get them to move on your behalf.

Additionally, you may well have to make some choices and those choices may require you to step well outside of your comfort zone. Learning and Growth can be pleasant but often it's not. Always reminds me of the Roland Orzabel lyric from Tears For Fear's "Goodnight Song"... "Nothing ever changes unless there's some pain". Also, it's important to realize that "learning" and "integrating skills" are not necessarily the same thing. We can learn things fairly quickly but getting the muscle memory necessary may take significantly more time and practice. I'm often reminded of this whenever I see or make a goal with a LinkedIn Learning course. It says it's a four-hour course. Let me assure you, if you actually want to get what you need out of it, you will be spending a significantly larger amount of time than that four hours to successfully complete it and integrate those skills.

Great talk and a great message. Thanks for coming out, Vernon, and thanks for helping us kick off the conversations :).

Performance-Driven Development: An #InflectraCON LIve Blog

As was once written, all good things must come to an end and as I have to do some interesting maneuvering to make sure I don't arrive late for my flight, this is the last talk I will be attending and my last missive for InflectraCON. It's been a lot of fun being here and here's hoping they'd like to have me back again next year :).

For the last talk, I'm listening to Mark Tomlinson talk about Performance (What? Shocker! (LOL!)). Specifically,  he's talking about Performance Driven Development. Sounds a bit like Test-Driven Development? Yeah, that's on purpose.

The idea behind Test-Driven Development (TDD) (Beck 2003; Astels 2003) is "test-first". You write a test, you then write just enough production code to PASS that test,  then refactor the code. Just as Testing has "shifted left", performance is likewise shifting left. 

Can the adaptive concepts used in TDD be applied to performance engineering and scalability? The answer is yes and the result is "Performance-Driven Development (PDD). 

In short,  we need to think through the non-functional requirements and system design and all of those "ilities" before we write any code. In other words, as we develop our features, we need to not just pass tests but need to have the performance constraints defined and confirmed as development progresses.

Intriguing? Yes, but I'm wondering how this can be effectively applied. Part of the challenge that I see is that most of the sites I have seen use TDD tend to do so in a layered approach. We start with small development systems and then expand outward to demo, staging, and then production (at least where I work). It would be interesting to see how PDD would scale on each machine. Is there an obvious point where one would be seen to be working well and then as we make the step to jump up from demo to staging or staging to production, what tier do we see issues (or do we see issues immediately)? I confess that in many cases the performance enhancements happen after we've delivered the features in question. Often, we have realized after the fact that an update has had a performance hit on the system(s). The next question would be where we are able to put Performance testing into the initial development. I recall from many years ago how Selenium and JMeter can be an interesting one-two punch when developed in tandem, so it's definitely doable (whether or not concurrent Selenium and JMeter development makes sense, I'd have to say "your mileage may vary" but it is something I can at least wrap my head around :) ).

This seems like something that we might be able to address. I can only imagine my manager's face when I bring this up next week when I'm on our regular calls. I can imagine him just shaking his head and face-palming with "oh no, what is Michael going on about now?!" but hey, I'm willing to at least see if anyone else might be interested in playing along. Time will tell, I guess.

And with that, it's off to see just a little bit more of D.C. as I make my way back to National. Thanks InflectraCON and everyone who attended and helped make it possible. It's been fun and I've enjoyed participating. 

Until we meet again :)!!!

Myths About Myths About Automation: An #InflectraCON Live Blog

First of all, thank you to everyone who came to my talk about "The Dos and Don'ts of Accessibility". Seriously, it's been a great feeling to know that a place that has been so pivotal in the lives and futures of deaf and hard of hearing individuals (Gallaudet University) is the setting for my talk. How cool is that :)? I'll sum up that talk at a later date but for right now, let's go to Paul Grizzaffi and talk about the "myths about the myths of automation" (and no that's not a typo, that's the literal title :) )

There are a lot of myths when it comes to automation but are there now myths around the myths? According to Paul, yes, there is. 

Is Record and Playback bad? No, not necessarily. It can in fact be a very useful tool to use in a stable environment where the front end doesn't change. It's not so good for actively under development systems, especially if the front end is in flux/development.

Do you have to be a programmer to use automation tools? No, not necessarily but it will certainly help if you have some understanding of programming or have access to a programmer that you can work with. 

Does Automation Come from Test Cases? Not entirely. It can certainly provide value but it doesn't necessarily make sense to take all of your manual test cases and automate them. For a few valuable workflows, then yes, but if doing so will have you repeating yourself and adding time to repetitive steps, then it may not be the best use of your time. Your test cases can be helpful in this process and they can inform what you do but don't just automate everything for the sake of automating everything.

Does Automation Solve all testing Problems? Come on (LOL!). Yeah, that was an easy one but it can often be seen that running a lot of tests quickly can seem to be a high-value use of time, where it can instead just be doing a lot of busywork that looks like a lot is being done but not much that is meaningful.  

Will Automation Find all of your bugs? NO, 1,000 times NO!!! It can show you if a code change now renders an older test a failure, which you can then examine afterward. It can help you with more coverage because now you might be able to make a matrix that will cover a lot of options and run against an orthogonal array. That can be useful and provide a lot of test case coverage but that's not the same thing as finding all of the issues. 

Can we achieve 100% automation? Nope, at least not in the meaningful sense of 100% automation. You can certainly have a lot of workflows and matrices covered, and machines are much faster than humans. However, there will always be more workflows than you can automate. We're not there yet in regards to being able to automate 100% of the things. Even if we could, it will likely not be a good overall use of our time to automate all of the things. Automate the most important things? Sure.

Is There One Tool To Rule Them All? Absolutely not. Yes, shared code can be a benefit, and yes, buying many licenses can help unify a team or teams but it's highly unlikely that a single tool is going to answer everything for everyone. That's not to say that there isn't value on a standard baseline. We use a number of libraries and functions that allow us to test across a variety of products but no one tool covers everything.

Plain and simple, as in all things, context matters and no two teams are the same. Look at the myths you may be carrying and see how they measure up to the reality of your organization.

Are You Using Your Leadership Voice? An #InflectraCON Live Blog

Amy Jo Esser is starting out her talk by sharing about how she wanted to try out for cheerleading when she was younger and how she did not make the team the first time and why she didn't make it. While she wanted to be a cheerleader, she didn't really realize what it would take to be effective in that role. After she was told the reasons she was not chosen, she took the feedback and applied it to the next year's try out and she practiced many things, the most important being the fact that as a cheerleader, you need to use your voice and it needs to carry.

I have a similar story in that I spent years developing my voice over many years to perform on stage as a singer. I developed a rhino-thick hide (metaphorically speaking) and I focused on getting out there and communicating with people, especially to promote and sell tickets. I jokingly told people that I trained myself to be an extrovert. If that is accurate or not, I do know that learning to project and learning to promote helped me considerably but just as the quietest voice I the room will not be effective, just because I am confident, can project, and can interact with people doesn't necessarily mean I am using my voice effectively, especially as a leader. So what might I learn/consider/apply today and going forward? 

As a lyricist, I tend to place an emphasis on the words that I use but if I'm being frank, strip away the music and just read my words and they more times than not just read like bad poetry. To be fair, most lyrics read like bad poetry when stripped from the music and vocal delivery. It's the emotion of the voice that sells it. More to the point, it's the swelling and falling away, the dynamics and the delivery, that make the difference. IF I sing monotone or quietly for the entire song, much of the impact is lost. Going completely overboard also loses the plot and then no one can take you seriously. It's the ability to measure and gauge when to be quiet and when to be bombastic that makes the song work.

Too often, we suffer from two big issues with our voice. The first is not being assertive and struggling to make ourselves be heard. As a leader, we can't be timid and we can't be shy about speaking out. Our internal voice (what Seth Godin likes to call our "Lizard Brain") tries to keep us quiet and reserved. It also tends to encourage us to couch our words with a lot of filler speech (true story: this resonates, as my most viewed TikTok is me talking about how I mostly avoid filler words in my speech ;) ). To have a more confident voice, eliminating or limiting fill words and also making a point to limit the "semantic bleaching" that we do. What's semantic bleaching? It's when we "overstate" or when we really, completely want to be sure that people really understand the totally valuable thing that we want to share... or I could just say "I want to ensure people understand". The latter is direct. The former is semantic bleaching. 

Something that any speaker can learn from singers is standing and breathing from their diaphragm. This is what singers often call "back breathing, where you feel your lower obliques and spinal erectors expand, and then you expel air by squeezing from the obliques and the spinal erectors. We have a phrase in singing to "sing from your groin". It may sound a little crude but if you do, you will be surprised how well your breathing and breath support is focused.  

One of the things that editing a podcast has helped me do is to stop, pause, and allow my brain and my mouth to synchronize. That pause may feel as though it is forever. Record yourself speaking and review. You may find that the long pause was much shorter in real-time as you listen back. Think about where you would see a period or a comma in your speech. Try to do your best to pause at these points and be deliberate as you speak. I also use hand gestures to help me do this. I often joke that I am part Italian so hand gestures are genetic (LOL!) but they do help considerably.

We have five building blocks we can use to change our speech patterns; pitch, pace, tone, melody, and volume. These are areas there is a lot of play and variation but knowing when and where to make these changes can make a dramatic difference in your received message.

There are a lot of benefits to practicing speaking, especially if you want to be a leader. The key part of leading is encouraging people to follow you and the best way to do that is to have a voice that persuades and encourages people to want to follow you in the first place. The key here is we have to practice it and make it a part of our everyday communication. By doing so, our voices will come across as more confident and that confidence will radiate out and help position us to have people ready and interested in listening to us and what we say.

From Fear To Risk: An #InflectraCON Live Blog

Next up is Jenna Charlton with a realistic look at the rhetoric of Risk-Based Testing. As many may well be aware, there's a lot of branding and promises that surround a variety of terms. Many of the phrases that we like to use have a certain comforting ring to them. Risk-Based Testing is one of them. Think about what it promises. If we identify the areas of greatest risk and test around those areas, we can deliver the best bang for the buck quality and we can do it so much faster because we are not testing every single thing. 

Sounds great, right? However, what does this ultimately tell us? We have said we care about risk but what actually is risky? We are only alert to the risks if we have thought about them. The biggest fear I have when I think about doing a risk assessment is that I have made risk assumptions from what I know and can anticipate. Is that really a good risk assessment? It's an okay and workable one. However, if I'm not able to consider or understand certain parameters or areas that may be blind spots to me, I cannot really do a great risk assessment, so my risk assessment is incomplete at best and flying blind at worst. 

One of the first things that can help ground us in these considerations is to start with a simple question... "what am I most afraid of?" Understand, as a tester, what I am most afraid of is missing something important. I'm afraid of having shallow coverage and understanding. That's not necessarily something that a general risk assessment is going to focus on. How many of us have said, "I don't know enough about the ins and outs of this system to give a full risk assessment here"? I certainly have. What can I do? Much of the time, it's a matter of bringing up my concerns about what I know or don't know and being up-front about them. "I have a concern about this module we are developing because I do not feel I fully understand it and thus, I have foggy spots here and here". Sound familiar? What is the net result of this? Do we actually get a better understanding of the components and that leads to a more lean testing plan because now we know the items better? Do we double up our coverage and focus model so we can "be sure" we've addressed everything? Here's where risk assessment breaks down and we fall back into the "do more testing, just to be sure" approach.  

Something else that often doesn't get addressed is the fact that what is a risk at one point in time, as the organization matures and they have covered these areas, risk in those areas actually goes down. Still, how many of us have continued focusing on the "riskiest areas" because tradition has told us that they are, even though we have combed through every aspect of this area we consider so risky. If you have made tests for a risky area, you've run them for an extended period, and no problems have been found (the tests pass all the time), what does that tell us? It could tell us we have inadequate tests (a real risk, to be sure) or it could also tell us that this area has been thoroughly examined, we've tested it vigorously and now we have a system in place to query multiple areas. In short, this area has been moved into an area where it might be risky if something blows up but as long as it doesn't, the risk is actually quite low. Thus, we now have the ability and the need to reassess and consider which risks are the current ones, not yesterday's.

We have to come to grips with the fact we will never cover every test possible and as such, we will never fully erase the risk. Also, we will never get it perfect. Still, we often operate under the assumption that we will be blamed if something goes wrong, or that we made bad assumptions, and of course, we fear the retribution if we get it wrong. Thus, it helps to see how we can mitigate those fears we have. If we can quantify the risk and define it, then we can look at it objectively, and with that, we can better consider how we will address what we have found. Are afraid of an outcome (nebulous) or are we addressing the risks we can see (defined and focused)? To be clear, we may get it wrong, or we may make a mountain out of a molehill. Over time, we might get better at that. Our goal is to deal with the molehills effectively but miss the entire mountain. 

Again, there's a chance that we will miss things. There's a chance something that matters to our organization will not get the scrutiny it deserves. Likewise, fear may be making us focus on solidly functioning software over and over again because "it just pays to be safe" only to realize we are spending so much time on an older risk that isn't as relevant now. It's more art than science but both are improved with practice and observation. 

Alphabet Soup - What Do DevOps, DevSecOps, DevTestOps, SecDevOps, Etc. Really Mean? An #InflectraCON Live Blog

Good morning, everyone! Day two and a rainy day in the nation's capital. Might make for some interesting maneuvering as I get to go home tonight but there are still plenty of things to talk about for the remainder of the day.

The starting keynote for today is Jeffery Payne talking about the proliferation of acronyms and initialisms related to the outgrowth of the portmanteau of Development and Operations. We all know that today as DevOps. Of course, like any catchy/sticky term, we can't leave well enough alone and we add other aspects to each. With that, we now have (as the title shows) DevSecOps, DevTestOps, SecTestOps, and if we want to get a little more creative (for some definition of the term) I guess we can have DevPerfOps and even BizDevTestSecPerfOps! So what is the point of all of this? If we end up with something like BizDevTestSecPerfOps... how is that really in any meaningful way different from general everyday software development?

Realistically speaking, the whole point of DevOps as it was originally introduced was the idea that by combining the disciplines of Development and Operations, we would be able to more quickly develop and deploy our solutions. By having our Development teams and our Operations teams working in tandem, we'd be able to deploy more frequently, make smaller changes more often, and be able to address smaller changes and test them more frequently rather than try to gather up a bunch of features and drop them all at once. The net goal is that we are able to create a better quality product and deliver value to our customers more frequently and effectively. That's the promise, in any event. How well that is done is going to vary from organization to organization. Additionally, the DevOps methodology is really a balance of accelerating change while providing operational stability. still, even with this rapid change and stable deployment, there are a lot of things that could fall by the wayside. Such as where is the testing performed? Who is doing it? What is the quality of that testing? What is the endpoint of that testing, as in does it actually deliver the quality expected/desired?

Over time, as these principles have been applied and examined, there are a variety of items that we notice are not entirely addressed by DevOps alone. How do we focus on security? How do we focus on general testing? What do we do about performance? What do we do about usability? Over time, we get feedback for the changes we make and deploy. The bigger question is "what do we do with that feedback?" Do we learn from the feedback we receive, do we integrate that feedback into the process of Development and Delivery? How do these processes affect Lead Time, Deployment Frequency, Mean Time to Restore (if needed), and what is our Change/Fail Percentage? The key point is, what are we gaining in benefits when it comes to speeding up this feature delivery?

Additionally, some environments and markets get better benefits considering the risks of implementing these processes. Updating Netflix frequently, even if it may have bugs or areas of annoyance? The aggravation level is low, or not really meaningful in the broader sense of things. By contrast, if we have issues with speed and delivery for a product that monitors a person's pacemaker, bugs or missed features are not just undesired, they can be dangerous and life-threatening. Thus, DevOps and its ilk will not be beneficial in all areas. 

This proliferation is going to continue and over time the differences between software development ten to fifteen years ago and today are very different for most teams. Getting the systems to work the way we want to will always be a challenge and the discipline to manage development and deployment will always be an area of interest. There will certainly be changes and a desire to add more coverage areas and more "ilities" to the list. Ultimately we will have to pick and choose which areas we are able to do well and how quickly. As Jeffrey points out there is a variety of augmentations that can be included but there's nothing really special about any of these. We have to pay attention to what we are doing and how well we are doing it, be early with our development and testing ideas, work with them in a focused fashion     , and once they are out monitor for any issues and be ready to react and update to address the feedback we receive. With that, cooking metaphors fit pretty well and our goal is to make our collective soups in a way that we don't burn it or create something that is dreadful to consume. Recipes require a balance and so does the variety of DevAlphapetSoupOps. Understanding the recipe and how to cook it will spell the difference between a great soup and an inedible one.

Built-In Quality – How Do You Build Quality In? An #InflectraCON Live Blog

I confess that the title of this talk has me instinctively saying, "This is a sarcastic title, right?" Granted, Lean and SAFe have the idea of  "Built-in Quality" as one of their main principles but again, I have been trained and conditioned to be skeptical of such a thing. Still, let's give Derk-Jan de Grood the benefit of the doubt ;). What does Built-In Quality mean and what could it look like? 

In a variety of larger projects, especially in the physical sphere, a lack of quality isn't just inconvenient. It could literally be a matter of life and death. Thus, sure, we want to look at the abilities we can leverage to increase quality. Still, is this a matter of semantics? Can you actually build quality in? Of course, the answer is yes, you can take care while the product is being built to help ensure that the quality of a product is as high as it can be. Again, though, what does Built-IN Quality actually mean, and what does it actually look like?

Ultimately, in my worldview, Quality has to be present from the very beginning. Let's consider something I'm somewhat familiar with in regards to building a guitar. The first and foremost area to consider is the wood that makes up the body and the neck of the guitar. If there are hidden cracks inside of the wood, it doesn't really matter if the rest of the guitar is top notch. An uncovered but spreading crack in the interior of the wood would counteract any and all quality I might put into the frets, tuner,  bridge, pickups, etc. In this example, if I were to scan the wood to look for cracks or imperfections within the wood, eliminating board stock that would not allow me to cut a solid piece without structural cracks, that will "build in" some quality in that instrument. 

Likewise, we need to be able to look at our applications the same way. To build in quality means we as an organization need to be willing to go into our processes and practices with as much attention as my hypothetical luthier and them scanning the wood to look for potential defects before they make cut #1. 

Ii a software example, we of course can and should apply similar ideas. If we have processes that address quality from the very beginning of the software development cycle, we can likewise create processes and practices that will allow us to test effectively from the earliest point of effort. 

Agile Coaches Can Wear Many Hats: an #InflectraCON Live Blog

As I read the description of this talk, I decided I needed to see what this was about. As someone who has been involved in a lot of peripheral roles along with being a tester, I know how it feels to slide into the role of "coach" for a variety of things. Thus I was intrigued with what Steve Moubray would be talking about here.  

While I wouldn't call myself a proper "Agile Coach" I do get the ideas behind coaching and how we can do what is needed in a number of situations. I've been a Scoutmaster, a Ren Faire Performer, a founder of a competitive snowboard team, and a number of other things as well. As such, the discipline of coaching is something I'm intimately familiar with.

There are a variety of situations where we might need to get involved and apply different skills as they are required. We may not be able to cover everything all the time but we may well be actively called upon to wear any number of hats (and by the way, Steve is actually wearing each of these hats as he goes ;) ).

An experienced Agile Coach will put on 12 different hats.

1.       Teacher (Graduation Cap) 

2.       Mentor (Hogwarts Wizard’s Hat)

3.       Facilitator (Party Hat)

4.       Coach (Ted Lasso’s Hat)

5.       Consultant (Surgery Scrub Cap or my Judge’s Wig)

6.       Dojo Coach (Karate Kid Headband)

7.       Project Manager (Hard Hat with Head Lamp)

8.       Auditor (Green Accountant Hat)

9.       Agile Police (NY PD Hat)

10.   Spy (Sherlock Holmes Hat)

11.   Deliver This Product! (Crash Helmet)

12.   Yes Person (Propeller Beany)

This is a great and fun way to bring this point home and props for what I think will be the most creative talk of this session.