Every week one specific business trend examined and explained in compact and detail. In this special CEO Q&A session, Manuel and Daniel are speaking about how quality assurance in agile project management is done and what are important steps when setting up a quality assurance strategy.
Today's topic of our Q&A Session is How to do Quality Assurance in Project Management. We are going to talk about how QA is done in agile project management, why agile does not mean to have no plan, and who is responsible when it comes to the Quality of the project or product.
For our international community. This is an English episode and you can find the transcript of this conversation now in more than 20 languages on our blog, at happyscribe public, or watch the video with subtitles for this episode on our YouTube Chanel.
[00:00] Intro
[06:20] Define the skills, then find the right talent
[10:45] What can go wrong when setting the QA strategy
[17:35] Is assuring the QA a team effort
[20:29] Close the gap between technical knowledge and requirements
Flash Hub provides tools, workflows, and skills to hire freelance experts and set up your first team in a matter of days. Develop virtual leadership skills, solve the digital agency hamster-wheel issue, and build freelance teams with ease. We have selected best practices and the most helpful skills you need to work smart, less, and grow a digital business that is easy to sustain you can work on from virtually anywhere. Visit FLASH HUB to get free access to the virtual business builder training. Learn how to build, grow, and scale your business with virtual teams and global freelancers in this free training.
For our international community. This is an English episode and you can find the transcript of this conversation now in more than 20 languages, on our Blog, at HappyScribe Public, or watch the video with subtitles for this episode on our YouTube Channel. You'll find all the links in the show notes below.
Follow us on Facebook and engage in our daily discussions:
✅ FACEBOOK:
Connect with us on LinkedIn:
✅ LINKEDIN:
Support Virtual Frontier show on Patreon:
✅ PATREON:
Find the transcripts to this episode on Happyscribe:
✅ HAPPYSCRIBE:
Drop us a message:
✅ PODCAST EMAIL: podcast@flashhub.io
✅ BLOG:
Daniel Guaper
Hello and welcome to the Virtual Frontier, the Podcast about Virtual Teams created by a virtual team. Disclaimer, all of our interviews are conducted Virtual I am Daniel your host and I'm part of the team here to Virtual Frontier. Today's topic of our Q&A session is how to do quality assurance and project management. We are going to talk about how Q&A in Agile project management is done, why Agile does not mean to have no plan, and who's responsible when it comes to the quality of the project or product. If you like the show, subscribe on YouTube reviews on Radio Public, follow us on Spotify, Stitcher, Audibel, GooglePodcast, or any other platform you use to enjoy podcasts. You can also engage our community on Discord. All the links you can find below in the description. So without further ado, let's dive into the fourth season, our Q&A session at the Virtual Frontier. Enjoy the conversation.
Daniel Guaper
Yeah, hello Manuel, welcome to this new Session here on Q&A ask the CEO episode. I'm happy to have you again here today. Our topic for today is how to do quality assurance in project management. And I think this is quite interesting for our audience as we have a lot of project managers. And in general, it's a very interesting topic on how to really do quality assurance in a strategic and structured way to ensure that your product projects are running well and the products that you are delivering have a certain amount of quality. To just jump right away into the questions Manuel. What does quality assurance and project management means and what is the difference between quality assurance and quality control?
Manuel Pistner
Tough question. OK. Basically, when we are read... I mean, I think the term project is used for currently for too many kinds of work. So what the project is, per definition, is something that is a unique thing that you have to do with limited resources in a limited available time. So that shows, again, what if you just look at the project, what makes a project successful, which is when you are able to deliver the scope with the requirements that were initially agreed on in the given budget, in the given timeline. So that's what a project is per definition. Now, if you just deliver the scope in a specific timeline with a specific budget, you also want the results to match a specific quality standard. And I think that is what you refer to when it comes to quality assurance. And I believe very strongly in two main things to ensure quality. The first mechanism is four eye principle. When you have two people that review each other's work. In software development, typically that's done with so-called pull requests and code review, where one developer reviews the work of another developer. And you can apply the same for like marketing projects when you have two experts reviewing each other. And I recommend reviews not only when the work is done, but also in the planning phase. Because if you plan the wrong thing and you do it right, you still get the wrong thing as a result. So having a planning and a four eye principle based review in the planning phase and at the result, so in the planning phase, you check with the four eye principle if the current plan, you create, once you execute, it will really help you progress towards the goal you have, OK, you validate your plan and the end result you validate if what you create, it matches what you want to achieve. Basically, you compare it to the plan you had and to the initial requirements. So that is an important thing and there is a quality related to the process. What very often happens, especially in teams that do complex work is that people confuse agile work with not having to plan or Agile work with chaos. And what happens often is that you just have a bunch of people that don't plan because they work, they think they work agile aren't working Agile does not require planning. And then it's just a bunch of people desperately trying to get the work done. Without the support of proper structures of proper Tools, of proper quality assurance mechanisms. And I think processes are very important because they give people orientation and stability to do what works. And when you see failure, you can manifest the solution in the system, in your processes, in your templates, in your checklists, so that in the future people will avoid falling into the same trap again, making the same mistakes and failures. If you don't have that, if you have just people and tell people you need to do this and that better, one person might improve, but still the other people make the same mistakes again. And that's what I refer to a digital leadership system that makes the knowledge persistent and then helps people to improve their quality standard with every failure. And that helps them to have a less stressful job. So these are the two things I would see as main quality assurance mechanisms and projects.
Daniel Guaper
When when you start with a new project, there are just different settings, it could be the team that is already has worked previously together is coming again together and start with a new project or the more critical I see it, when when you have a new constellation of people that are coming together and they maybe have to find their way through this process. What could be done about to help them getting those things right away and running and not like struggling with these points you just mentioned before?
Manuel Pistner
Yeah, yeah. So, you know, the first thing is, of course, understanding which kind of skills you need because that helps you find the right person. You can have the best person with strong skills, but if the person takes the wrong role, he or she will not be effective because you have different requirements. So let's assume you have the right person in the right role. What do they need? Is a proper Onboarding. Proper Onboarding first to the business itself, a cultural Onboarding and Onboarding, who is your mentor and how things work for you? Like, if you if you want to get support, whom to ask? If you want to have somebody who coaches you related to project situations, whom to ask. OK, that's your mentor and your coach. That is the Onboarding to the business, to the company. And then you have a project specific Onboarding where you need to get somehow the knowledge of the project. And that typically happens by, yeah, I would say in the old school set up. People have meetings and then everyone tells something and the person tries to listen with the best intention. Maybe that are two meetings, three meetings, 10 meetings, a lot of meetings to get all the knowledge transferred into the brain of this person. I think in the new set up, completely digital. What you can do is when you work, for example, according to Scrum, you you will have regular Sprint reviews where the team presents the results to the product owner and you can record them. And once you recorded them, you can put them into your knowledge base of the project, and the new person that joins the project can watch all these last 10 videos and get the knowledge from the previous project. Because every item that was developed or created is presented. So that has already to get some knowledge, I would say 60 to 70 percent. But the next thing is that you also not just need the knowledge, but you need to understand how the team works. So what is the quality standard of the team? When do we create a task? How do we create a task? Which task types do we use and when do we transition a task from one state to another? And yesterday we just had a meeting with the entire team, with all squad managers and project managers, because they found quite a lot of problems. They found problems that the client is... Let me give you one concrete example. They found the problem that a client is not satisfied. Why? Because we overspent the budget. OK, why? Because the customer (Success Manager) didn't inform the client that we exceeded the budget. Why is that? Because they didn't have a project report where they can see that the budget is completely used. Now we asked, why is that? Then they said, because we don't have the data in our system, and we asked, why is that? And then it comes to the root cause, which was because people that did the work, developers in this case communicated just in Slack and not in Jira means there was no task. And if there was task there was no status update or time tracking. So we had on the one the top level where the work is done and on the on the bottom level where the work is done, we didn't have the data. And if you don't have the data, all problems stack up. And the higher you get, the bigger the problems you get, the more stressful they are. And you can try to fight all these symptoms. If you don't fix the problem and the root cause, you always hide the same symptoms again and again. And you were wondering why always the same things happen. So really, that is a good technique to really help your people understand the root cause by asking why, why, why, why, why? Until you really get to the core point that if this one is fixed, all other symptoms disappear.
Daniel Guaper
Well, that's great. That's already going into the next question I would like to ask you. Um. What can go possibly wrong? You just mentioned one specific thing, when things are not properly communicated or not in the right channel where they should be. But what could be what could be possibly go wrong when setting up this quality assurance strategy in your project apart apart from that, maybe you have more insights that you can share with our audience.
Manuel Pistner
Yeah. Quality assurance. So that that's the main problem of communication. Right. We have words and you attach a meaning to the word. Now, if you ask one hundred people, what do you mean by quality assurance? What do you think, how many versions you get? One hundred. So the question is, which one is yours? Which one do you want? And before you just tell a person we need you for quality assurance and then you blame the person because you are disappointed that some person didn't do what you want, better be very clear about what that means for you. What is quality assurance? So there are different levels of quality assurance. You can do user acceptance tests. That means you have a software somebody tested from the user's perspective. You can do unit tests. Somebody tests the the code, the modules in the software. OK, then you can do manual tests or automated tests and you can do smoke tests, which means you just use the software without having a requirement that you test against and try to find issues, try to find bugs. Now, what typically happens is that you just have a quality assurance process where you have a ticket or task with requirements, typically user story with acceptance criteria and the quality assurance tests against this acceptance criteria. Now, you mentioned this is the acceptance criteria and you say, OK, quality assurance pass. But on the other side, you see that there are negative side effects, which are bugs, but nobody sees them because nobody tests on the other side. And it's hard to if you just test on one individual item on the task or issue that your forecast is might have an impact on some other features in the software. Because it's complex and complex software or complex work in general, also digital marketing requires a different way of testing. So one good thing in software development is automated testing. Whenever you have a requirement and you're test it, you can write an automated test that makes sure that this one usecase, is tested over and over again, which means when somebody just tests one specific ticket, but we run the automated tests, you see if something else crashes, that should not crash. But that is systematic quality assurance instead of just testing on a ticket level and hoping that somewhere else things don't crash Of course, that takes time and money. And honestly, most people don't see a value in that because they think, OK, developers, they need to do it right in the first place. I agree, but reality shows, it's too complex. Nobody can do that. So now you can say what developers have to do it and you can say that you will always be disappointed because reality shows there is a developer who can develop code without bugs. So you need to use technology to make sure that things don't break. That's how we do it on a deeper level in software development projects, right. And in marketing projects typically, you don't develop things, otherwise it's a software project. But in marketing, I would say four eye principle, it's an important thing.
Daniel Guaper
What is the relation you just mentioned a little bit of that between the quality, cost and time, because as you just mentioned, sometimes the customer expects that that needs to be done or should be done in the first run of its software development related. But there's a relation always between the time and the cost and the quality. Could you mention something about that.
Manuel Pistner
One one important relation that you need to understand this said like this shit in, shit out. So quality assurance starts with the requirements. If you have requirements that just say we need a log in but nothing else is specified or you say we need a feature like this other site has it and you agree to that, but you don't know what is the index of the Features, what are the details, et cetera. And it's all about the details. Because if a project fails it's because of the details, not because the design doesn't look like we want it. It's because of many details. So I would say that requirement quality assurance is one important part to set the project up for success, because if you have weight requirements, you start developing later, you see that you need to give all this information in order to do it as you want it. But this will cause a delay, as if you just have weight requirements and you give an estimation based on this weight requirements were all detailed information on missing your team just estimates what what they can see, and that might be much less than the time they need to spend to really get you the results you really want with all the requirements. And a lot of projects get into trouble because in the beginning, nobody wants to care about the details. They just want to start getting results fast. They are impatient. And then they pay for it later because reality shows, obviously many things were not considered in the beginning when requirements were created. And if you if you give.... So what happens often is that like Product Owners have a rough picture and then they want a requirement and then they want that estimation. So they get an estimation and they get told that there are some gaps in the requirement. And what I typically hear is that, OK, then plan with a buffer. You can do that, but you need to know that this buffer is completely a nonsense. Because, look, if you tell me, Manuel you have to thrill a whole. And I say, yes, the whole can be very deep, it can be very big, it can be very small. So what is it you can take from a day to like five days, right, to ten days? Just knowing there is a requirement missing doesn't mean that it's a small requirement. Even if it's just one requirement. It can be a big thing. Like what happens often with requirements. We need to integrate with the CRM system, or we need to migrate data. OK, which data? How can we access it? How much data is it? How do we map it? Like it's all the details, typically people don't want to hear. But if you don't know them, you cannot estimate them. And if this ignorance starts to influence the project in the very beginning, then you have hough troubles later on because all the details fall on your shoes.
Daniel Guaper
Talking a little bit about responsibility in the project. Is the project management, the project manager responsible, or is this a team effort when we're talking about this of a process of quality assurance?
Manuel Pistner
So the project... I mean, there are two different things, right? It's responsibility and accountability. Responsibility means we need to do the work, and the project manager will not do the work of quality assurance. You have a person in the role quality assurance. This person does the testing work. But the entire team is responsible to do quality assurance by sticking to the workflows that ensure quality. And the project manager is accountable for that. That means the project manager needs to remind people to adjust their behavior, which means they need to comply and work according to the workflows. So it's the responsibility of the whole team to ensure quality related to the process it's typically the project manager or the process owner that is accountable to remind people and maybe to change the processes if quality is not good. But what else also? So there are standard processes for quality assurance. The big problem is just when nobody uses them. Because then you see quality is poor and then either you blame people, you say, OK, these people are not good, or you blame the process and you want another process. But if people didn't use the process the result is neither related to people, nor to the process, because you didn't use it properly. So that can lead to all kinds of false decisions. And that's why, yeah, everyone is responsible to keep people accountable to the process and to work with the right tools and to keep knowledge and data persistent, because only if you have data persistent, you can get proper reports and only what you can make sure you can manage. If you have no idea how your velocity of the team is, if you have no idea how fast your team can deliver requirements, if you have no idea how many bugs get to their release, if you have no idea how much budget and time and money you spent. How do you want to measure it's like driving a car with closed eyes.
Daniel Guaper
Got you. We have one other part, and that's the customer. Who makes the final call when it comes to the amount or the amount of quality that we put into the project or when it comes to the implementation of the quality, who decides about the required level of of quality. And maybe a second question just to put it after. When we talk about that, there's always like this, this gap between the customer's knowledge and the technical knowledge that maybe with the project management or the technical lead, how we can close this gap while preparing for project or while working on the project.
Daniel Guaper
OK, there were multiple questions, right? So let me first answer the gap. Of course, the client should not have the technical knowledge. Most don't have. Still, it should be very clear which role the client takes in the project. It can be the product owner. Then the client is responsible and accountable for the requirements. That means he or she needs to create requirements in form of Epics and user stories if we do Agile software development, needs to put them into the backlog, prioritize them, join the grooming and the Sprint planning with a team where the team gives estimations and commits to a Sprint backlog. So that's the accountability and responsibility of the product owner, and the client could take this. Now, it can happen that the client doesn't know how to write proper user stories and also cannot create the designs. That's why typically the client builds a so-called product management team together with a business analyst and the UX designer. The business analyst creates and writes the user stories according to the top level requirements the client product in this case raced and the UX Designer creates a user interface based on these user stories. And then you have a product management team and they fill the backlog so the delivery team can implement these requirements. That is typically the flow and it is highly recommended that a client takes the position or the role of the product owner. Now, it might happen that the client is just the investor person that gives money and wants the return of investors back. Then he or she needs to employ a product owner in order to manage the product, because there must be somebody who manages the product. And managing the product means managing requirements that have the highest value, because you want to ensure that whenever you spend money, you spend it for those things that have the highest value. And that's what the prioritization of backlog is about. And yeah, I would recommend putting the client in this position and the team keeps the client accountable to create proper stories for proper requirements for delegated to a person that can do this.
Daniel Guaper
Yeah, but what happens when the customer has an idea or the client has an idea about the amount of quality that he thinks is required and the project management or the technical lead sees that there is much higher requirement of quality needed to assure that the end product is valuable. You know, there's there's often this conflict between, OK, we want to have like a really cheap product, but project management will tell you, sorry, we need this amount of quality to assure that you have that and how we can how we can work on that?
Manuel Pistner
Yeah, there is a there's a triangle of time, quality and money. You can pick two, but not three. You can either have it fast and cheap, but not at top quality. You can either have it cheap and at top quality, but not fast. And you need to choose what is your priority. And if that is not done properly and if the team doesn't set expectations to the client properly because typically they don't know, they just want it, but they don't know how it works, then expectations are set wrong and the expectations are wrong that leads to disappointment. So you need to know that these three criteria, they cannot be fulfilled at the maximum. You cannot maximize them. You can take two, but not three. And that's a decision you need to make. And sometimes people don't want to understand that. So they don't make the decision. And I can tell you, when the project starts like this, I can tell you how it ends. It ends with frustration, disappointment with quality, with a waste of money and time, basically, and many frustrated people.
Daniel Guaper
Great. I think we covered some very important steps as towards the quality assurance in the project and how to do it properly. Manuel, thank you very much for your time today and see you next week on the next Q&A session.
Manuel Pistner
Thank you. See you next time. Take care.
Manuel Pistner
Bye bye.
Daniel Guaper
Bye.
Daniel Guaper
I want to thank Manuel for joining us today and sharing his practical experience when it comes to real agile project management. If you want to learn more about how to save your business at any time, deliver projects on time and make work better visit FlashHub.io/start to get free access to virtual business builder training. Learn in this free training how you can build, grow and scale your business with Virtual Teams and global freelancer's. You can subscribe to the Virtual Frontier on Apple Podcast, Google Play, Stitcher, Spotify, YouTube or wherever Podcast can be found. And while you're there, you can give us a review. On behalf of the team here to Virtual Frontier I want to thank you for listening. So until next episode, keep exploring new frontiers.