Jacqueline: This A-Z series for the next 26 days starting in August is going to be related to agile. A is for agile frameworks. A lot of you who may be in technology or the IT industry have heard of Agile. It’s a formal methodology. We refer to that as big ‘A’ Agile because it’s a methodology or an approach. Some of you who know me know that I don’t even like to call it a methodology. Let’s call it a framework. It’s an approach on how you build software and the software development lifecycle. The word agile has been in our dictionary for a long time. This whole series A-Z is relevant to everyone, not just people in IT or who know about the framework. I’m going to give you both sides of topics that we’re going to touch upon as we talk about agile frameworks. I’m going to relate them to software development and software design for my techies, but I’m also going to bring it home to just how agile is important in every industry and every walk of life, especially to my entrepreneurs.

Listen to the Podcast – A for Agile Frameworks

Agile frameworks is about being flexible. Because the world is moving and changing so fast, in order to stay in business or to stay marketable and buyable, whether it’s keeping your skill set, doing a job search, or trying to start or continue a business, you have to be agile. You have to have what I refer to as the agile mindset. That’s two key things: there’s agile the framework and then there’s agile the mindset. The mindset, especially, affects everyone. The opposite of an agile mindset is a closed mind. That is dangerous to you making progress. It also ties to lifelong learning. 10-minutes a day is all it takes to learn a new word and to entertain a new perspective. First of all, don’t close your mind. Just because my alphabet that I’m about to go through is related to agile doesn’t mean it doesn’t relate to you; it most definitely does.

Let me talk about some of the things we’re going to cover. I know some of my IT people, people who work in the digital world, they will be able to relate to some of these terms, but as I mentioned, always tune in because you don’t know what angle I’m going to take here. I always cite my various resources. The agile alphabet that I’m using comes from agilealliance.org. That’s actually a conference I attended: the Agile Alliance Conference. I’ll be bringing you some of the latest and greatest conversations that are taking place with the people who are practicing the agile frameworks in the information technology space. If you want to find out more, go to Agile Alliance. Great website, great resource, and great organization to follow and belong to. They’re going to have the agile alphabet, and you can view it there. But I’m going to take each of the topics there and go into a further deep dive.

For example, when you talk about agile, you talk about: A for the acceptance criteria, B for burndown charts, C for customer collaboration, D for the daily scrum, E for the epic, F for face-to-face communication, G for grooming (not grooming yourself but grooming the artifact that you create in agile, stories and epics), H for high-performing teams and the culture around having a healthy team, I for impediment, J for just-in-time requirements, K for kanban boards, L for lean development, M for minimal marketable feature or minimal buyable product, N for negotiable, O for osmotic communication (that’s a big one, and you’re going to get a little chuckle out of that episode), P for product owner, Q for quality, R for retrospective meeting, S for sprint, T for time box, U for user story, V for velocity, W for working software, X for XP practices, Y for yesterday’s weather, and Z for zero defects.

As I went through that list, if you notice, all of those topics are relatable to any type of business, because businesses are about problem-solving. Of course in the IT industry, clearly we’re using technology to solve problems to help get information and to help decision-makers make better decisions. That’s what IT is all about. The method, approach and framework that we’re using in IT to do problem-solving can also be applied to businesses, consultants, and customer service.

I challenge anyone who wants to call me or send me a message, text or email. You can send it to technologyexpresso.gmail.com. What business is out there and their sole purpose isn’t to solve someone’s problem? We’re all problem-solvers. Trying to say that STEM or STEAM is only for techies, geeks, engineers and scientists—that’s not the case. We’re problem-solvers, when it comes down to it. You’ll see how much we can relate to each other, especially when we talk about efficient approaches to how to problem-solve. That’s what this agile series is about. Tune in and join us.

For my regular SIP listeners who are looking for their letter or phrase for today, not only is A for agile frameworks, but today I want to dedicate this episode to ‘A is for acceptance criteria.’ In the world of agile, we like to focus on just-in-time requirements. Oftentimes there’s something we know as the user story, which is the initial placeholder for what a user needs or the problem they’re trying to solve. When we capture the initial request in what we know as the user story, there’s something called the three C’s: card, conversation and confirmation.

The card is just a brief placeholder of what they need and why they need it. The conversation is the follow-up and the further refinement you need. You’re gathering and eliciting the just-in-time requirements. Those conversations go back and forth throughout the cycles of requirements, design, development all the way to test. It’s all iterative, an interaction conversation. The confirmation is ensuring that you deliver and address the original problem stated on the card. The key way to capture the confirmation criteria is through what we know as acceptance criteria (AC).

When we talk about agile frameworks and when we really get to the heart of what is required, that’s going to be captured in your acceptance criteria. You can’t capture that in a short, brief statement about what and why you want something. That gets captured in a section called acceptance criteria, and most tools in agile frameworks have their own separate section. It can be set apart as bullet points, or you might see given-when-then style statements. The acceptance criteria is mapped to how the testers and quality assurance are going to QA to prove that you delivered what was needed to address the original request. In IT, again, the end result is the software that you’re testing. In your customer service you have to elicit the request, and you have to understand why and how they’re going to use the product or service that they’re requesting. You then have to determine the key criteria that they expect when they get their final solution. Then, you have to validate and verify that it was delivered.

Let me just break that down and make it very simple. Let’s talk about going out to dinner. Your waiter or waitress elicits what your needs are, and you tell them. They then further elicit for acceptance criteria. If you were ordering steak, they might ask you if you want it medium or well. If you ask for a salad, do you want your dressing on the salad or on the side. They might ask you if you would like them to bring bread to the table. These are them doing their further elicitation. Then, once the product is built and brought out to your table, oftentimes during the meal they’re stopping to validate: is everything acceptable; is it up to your expectations; is there anything else that I can get to make your meal enjoyable. That’s them validating and verifying the acceptance criteria back to what was originally requested. Sometimes they have to take it back to the kitchen. You might say, “No, I asked for medium well and this is rare.” Immediately they’ll grab it—hopefully, in a good restaurant. This is acceptance criteria.