Getting Things Done Right (with Michael Luchen from Crema)

Ben Aston: It sucks when things don’t work, and when we spend weeks a month building a project, only to be let down by a sneaky bug when it comes to the final UAT. But why does that nearly always seem to happen and is there anything we can do about it? Well, if you’re being bugged by bugs, keep listening because on today’s podcast, we’re going to discuss how we can get things done right with an improved product and process and the magic of a quality management plan.

Thanks for tuning in. I’m Ben Aston, Founder of project managers. Welcome to the DPM podcast. We are on a mission to help project managers succeed, to help people who manage projects deliver better. We’re here to help you take your project game to the next level. Check out thedigitalprojectmanager.com to learn about our training and resources we offer through membership. This podcast is brought to you by Clarizen the leader in enterprise project and portfolio management software. Visit clarizen.com to learn more.

Today I’m joined by Michael Luchen and Michael is one of our resident DPM experts. He’s a product coach. At Crema and they are a digital product agency creating web and mobile apps for disruptive companies and industry leaders. And he works remotely normally out of D.C., and he helps him improve their collaboration to analyze and solve complex problems. And he’s worked with Adidas, Callaway Golf among others, and he’s a coach at Crema. And we’re going to talk to him today about building a quality management plan. But hello Michael, and welcome to the show.

Michael Luchen: Hey Ben, how’s it going?

Ben Aston: Yeah, good, thanks. And I’m curious, as we’ve been talking and recording podcasts over, I guess the years, your role has evolved and I’m interested in your coach role that you now have, which is a new job title, I think. So can you tell us a bit about what is this coach? What is a product coach and what does that mean at Kramer?

Michael Luchen: Yeah. Well, like you mentioned, this is coming off of about seven years of hands-on project and product management experience. And really quite frankly, the role is in definition right now. We’re trying to figure out what is a coach role at Crema. Quite simply right now we’re approaching it as a servant leader of helping clients understand Agile practitioning to become better versions of themselves. Typically, I might serve as a facilitator, a product strategist and a design thinker to help them reframe problems and identify innovative approaches. But I think right now what’s really interesting about this new role and this new venture for Crema is trying to try to make a dent in a crowded industry by approaching it from a very unique angle that’s not prescriptive. There’s so much prescriptive coaching processes out there and we want to be different.

Ben Aston:

Okay. So in your role, you go with a small team and work directly with a client. Is that more of a strategic role than when you’re trying to define the project or the products roadmap?

Michael Luchen: Yeah, it’s-

Ben Aston: Or is it more delivery-focused?

Michael Luchen: … It’s similar to what you just mentioned. A little more broad and it’s more focused on the people. And so, one of my things I love about project management is being able to focus really on cultivating a healthy environment for teams so that they can do their best work. And so this is really taking that and just helping give clients the tools and frame of mind that they need to create a healthy, productive culture and environment within their teams to create really great results.

Ben Aston: And so what kind of challenges do you deal with in helping clients, I guess change that delivery mindset?

Michael Luchen: Yeah, I mean there’s a lot of challenges that can come up, but I think it has to do with that results are not always going to be instantaneous. This isn’t something that I can go in and say, do this and things will be better. There’s certainly a lot of that out there, learn the X framework and your team will succeed. But I think what’s important is to have the full context of the culture in the org at play and understanding that when you’re empowering leaders that you’re working with, that it takes time to experiment and figure out how those lessons sit in.

Ben Aston: Yeah, definitely. Yeah. I think it’s so true that there’s not a single process that you can follow that’s going to be absolutely right for your organization or agency. And if you simply follow the steps, you’re going to suddenly get these magical results. There isn’t a magic, there isn’t a silver bullet that you can use that’s going to suddenly fix all your problems. And I think sometimes people think, “Oh well, Agile is the silver bullet,” and then we have to define, okay, well what does that mean? So that sounds like an interesting role that you are pursuing there. And are you mainly doing that remote or do you do that onsite with clients?

Michael Luchen: Definitely a combination. Right now as we’re recording this, definitely 100% remote. But I think relationships can be built in person and so if possible it’s always great to kick off coaching them. But I’ve found the ability to create a really productive and meaningful conversation over Zoom chats or using Loom Screen Shares to provide guidance, or answer a question or collaborating in mural boards. And so it can be really done either way.

Ben Aston: Yeah. So I mean we’re talking about remote working, obviously we’re in the middle of Corona quarantine and you actually recently did a workshop for us on remote working. But for anyone who missed that, or maybe even now as you reflect on life working remotely and how now everyone is forced to say your experience of remote working, for you, what would be the most impactful hack or technique that you use to not go insane when you’re working by yourself, when you’re working remotely, yeah, how do you tackle that feeling of isolation and working remotely? Because I know normally you talked about how go to coworking spaces. I’m sure you’ve got lots of experience of being holed up maybe at your house. What do you do to keep sane in that?

Michael Luchen: yeah, that’s really good and timely question. So I think mentally I try to remember that I’m collaborating with and working with other human beings and so Zoom calls as much videos, Zoom calls as much as possible has been incredibly valuable. It sounds really simple in this time, especially when I saw Zoom is like the number one free, most downloaded app right now, but I think intentionally approaching that from a collaborative perspective, let’s just hop on a Zoom call with my team and talk through things. You can see nonverbal interactions are so valuable, especially as a project manager. And I even go so far as to make it a point to sometimes have a whole second screen if I’m sharing my screen just so I can see everyone’s faces still.

Ben Aston: Yeah. I think that’s solid advice and I think Zoom is a great tool and I think the temptation can be when we also have Slack to simply start typing things away in Slack and we forget that actually we’re missing out on a whole bunch of the communication, and also that ability to build relationships as well. The conversation is different when you have a Zoom chat, so get dressed and have a Zoom call too and I think it definitely pays dividends.

So I mean, you’re talking about coaching and you said that, hey you’re doing this remotely as well as in person. Obviously it’s all remote now, but can you tell us a bit about some of the projects you’re working on now?

Michael Luchen: Yeah. Right now I am transitioning fully from product management over to the coach role. So I’m wrapping up a large multi year enterprise development project right now and it’s really cool to do this and approach it with a coaching mindset because there is definitely a lot of overlap when you bring coaching down into the practitioner level. Otherwise, right now I’m looking ahead to really build out what are these coaching services and specifically what is that key differentiator on how Crema might make a difference in this, and really serve clients with humble confidence.

Ben Aston: Yeah. And so as you’re thinking about what challenges clients might be having that you’re helping to address, what are some of those key delivery snags that you are identifying as potential opportunities for you as you’re building out this role?

Michael Luchen: Yeah, so I’ve bet an interesting metaphor for that as far as what we’re thinking is approaching coaching similar to a semester in a college curriculum. And the reason for that is because I believe that’s so much about effective coaching is by experimentation, by the people that I would be coaching to actually experiment and learn by themselves. What basically my role really serving as a facilitator and a guide and a mentor with practitioner experience.

And so this involves regular cadence of having check-ins, retrospectives, observations and shared notes being, hey maybe you want to check this out or try this on your next meeting. But really just creating a rhythm so that in a period of whether it’s a few weeks or a few months that by the end of it we can all look back and say like, “Whoa. Yeah there is definitely marked improvement from this. I feel that my team is able to produce more.”

Ben Aston: And so as you’re identifying potential areas of an organization to think about becoming more Agile, how do you help them prioritize those areas? Because obviously within a big organization there’s going to be lots of different process going on. How do you help clients identify which aspects of their process or delivery ripe or low hanging fruit for thinking about things in a more Agile way?

Michael Luchen: Yeah, I think it starts with a survey. So just being able to have a conversation. And maybe the survey isn’t just with one client contact. It maybe with some project managers and developers and whoever else is involved or wants to be involved in this process. But it starts with a survey to figure out, what are their perceived notions of what is most important to resolve? And then sometime for my team and I to go back process and look at that survey but also cross-reference it with what are the subtext of what we heard from them so that we can make recommendations that, let’s move forward and these top two or three areas, these are the ones that are going to have some really great outcomes if we move forward with them now.

Ben Aston: Yeah. That sounds pretty smart. Well, good luck with that.

Michael Luchen: Thank you.

Ben Aston: And I want to get back to your post and this topic where we started off quality management. And if you haven’t read the post that we’re going to talk about yet, check it out on thedigitalprojectmanager.com. It’s called how to develop a quality management plan. And in it Michael helpfully goes through a really thorough step by step process for creating the quality plan. And if you guys are members, you can also get access to the quality management plan, target device list and requirements, quality. Check this template so you can put all of this into action super easily.

And we’re not going to dig through the process of creating the plan too much here because that’s in the post. But in summary, Michael talks about how you can go about creating a quality plan for your project or products. But I just want to start with this idea of quality. You start by talking about in your process of creating this shared understanding of what quality means for your project. Why do you think that is so hard to get a grip on?

Michael Luchen: Yeah. So, so first off, just to set the stage of quality and this discussion, I see it as two things. It’s product quality and process quality. Product quality is the quality of your actual tangible or digital product and includes all the results of your design team’s work, or your developer team’s work and more. Process quality is really as PMs what we have a strong hand in, and that refers to the process that we cultivate that then in turn impacts our team’s ability to drive results. An example metric we all might be familiar with is velocity to help measure how process qualities is going.

That said, getting a shared understanding of quality is hard to get a grip on for a lot of teams because of all the subjectivity and emotion that I think can go into it. You’ve got so many different stakeholders and this includes your own team as well of developers and designers coming at it from different perspectives for different reasons. For example, you might have a client stakeholder that desires a certain level of quality that meets expectations, whereas a developer might really value code quality and clean code and want to write the perfect code. And so we have to be able to help facilitate and strike that balance.

Ben Aston: Yeah, I mean let’s talk about that balance. I mean, and for me this is a bit of a Nate conundrum. With Agile we have acceptance criteria for a user story that defines the parameters of that story. Like, this is what the story needs to do. These are the acceptance criteria. It has to do, achieve these things in order to be thought of as done.

And then we also have definition of done where we’re like, okay, everything that applies as a blanket thing across all the user stories. But when we’re thinking about Agile, often we’re thinking, okay, what we’re trying to deliver value, we’re trying to deliver iteratively. And so sometimes for me, at least the concept of quality can be at odds with this Agile delivery approach where we’re thinking about, okay, well what’s more important? Is it taking of all those acceptance criteria and definition of done, or is it delivering value or is it both and just we have to go slower as a result?

Michael Luchen: Yeah, I know that is a really good question and I love this question because I think this gets at the root of why I love diving into things like this so much. So I believe that if focused on quality is not at odds with Agile, I think it actually is an accelerant to teams and an enabler to teams that are focused on Agile practices. And the reason for that is because if you sit down at the beginning of a project with your team and you define what quality means and what it shouldn’t mean, that helps put some healthy focus blinders on your team as you’re actually building and delivering the work. It clearly states what should and shouldn’t be considered.

And then as far as even practical, getting into the weeds of delivery and day-to-day work along the lines of things like acceptance criteria, those also serve as a tool to help support Agile if you’re looking at it in the right perspective. And what I mean by that is say as an example, your team is working on a user story in a sprint and it already has acceptance criteria associated with it, but as you’re developing, your developers are building them out they run into maybe a roadblock or something that they’re able to get around a specific technical challenge, which then in turn changes a piece of the acceptance criteria.

That opens up an awesome discussion. It doesn’t mean we have to slow down and go the old way. We can pause as a team, have a quick discussion, update the acceptance criteria and the acceptance criteria exists to serve quality in that example.

Ben Aston: Yeah, and I think it’s about changing, I guess the mindset of quality rather than quality being something that is at odds with rapidly delivering value. It’s actually, we’re thinking about quality is an important component of value and if we are delivering something of value, then unless it hits that kind of quality criteria that we’ve set, maybe it’s not delivering as much value as it should or could. And so I think reframing our concept of quality is, hey, this actually is a component of the value that we are creating and the reason that we’re defining this in such way is because if it hits that, that’s where we will see value generated.

Michael Luchen: Yeah, absolutely.

Ben Aston: And so in your approaches where you talk about dividing up responsibilities for quality management, and I think this is a fun one because often bigger agencies or organizations will have dedicated QA teams, but often it can actually end up being the PM’s job or the devs job. And you talk about lobbying for that test engineer role, but in your experience, why is that so important?

Michael Luchen: Yeah, I know it’s a good thing to bring up. And I have to say just from a personal background perspective, in my early years as a PM I was doing the QA and now having test engineers that I get to collaborate with, it is a night and day difference and so I think to that end, the reason why that role is so important is having to train in critical eye to quality it’s so critical. The test engineer in a way I think serves as the best, at least from my perspective, PM partner on each project because that role is looking at the details of both what is being built and delivered in a way that no other role on the team is.

They’re focused in the weeds from a technical perspective, but they’re also looking at the big picture impacts, the development, and how what we’re actually doing is delivered to users. And this also helps when you allow a test engineer to actually engage that way, I think they become a core member of the team that really multiplies the value of other roles, developer roles and designer roles, and certainly my role as well.

Ben Aston: Yeah, and I think in my experience, the mindset of a test engineer or QA analyst, it tends to be very different from a PM. As a PM, I always think about the optimal path and when I’m testing something I’ll be like, “Okay, well this is what you do,” because I know the product that’s being built, I know how it’s supposed to work. And also I have a vested interest in it not being broken because I want it to work and therefore for us to not spend any more time on it. But I think that QA mindset or that test engineer mindset where they have experience in breaking things and thinking about that customer experience through exploratory testing, finding ways that actually the ideal path doesn’t really work, and how it can break, can provide a lot more rigor and thoroughness, and really build and increase the quality of the end product that we’re delivering because we know that there’s always going to be bugs in what we produce. Right.

And I guess this leads me onto my question because in your article you talked about, determine your target devices, which I think is always super challenging when often times with our clients they might have an old phone or I think back to the days of when people were still working with Internet Explorer 6 or they had a Blackberry and they were expecting everything to work on their ancient browsers, their ancient phones. So how do you work with your clients to limit when your client wants the product that you’re building to work on all devices in the past and the future? How do you manage that and coach them through that? “Hey guys is not actually going to work on anything, but that’s okay.”

Michael Luchen: So when it comes to determining your target devices, this is actually one of my favorite exercises, especially with my PM background in mind because I think it helps not only narrowing the focus around quality and where the team should invest there, but it also helps narrowing the focus of the outcomes that you’re trying to create and generate for the users.

And the reason for that is, especially when the client maybe wants to have every device ever in every operating system ever supported, it allows you to start asking questions about the users that you’re actually supporting and what those users actually need. And we joke about Internet Explorer support from back in the day, but sometimes those do lead to actual conversations that matter in terms of value for the users that maybe it’s a really niche app that does need that type of support.

And so the target devices conversation allows you and your team with the client to focus on the user, narrow in based on priority and the time that it takes to achieve those priorities at a high level, what matters and what doesn’t.

Ben Aston: Yeah, now I think that’s solid advice. I think one thing, just a word of caution to people who are writing a statement of work or defining acceptance criteria, just be really wary when you all are writing what devices you will support, and just be careful to clarify and not just say, “Hey, this will work on all mobile and I know desktop devices for now and forevermore,” because what you’ll find is not only will it not work on browsers of the past, but what you’ll find is that as browsers evolve, things will also stop working.

And so oftentimes it can be the case that your site or your product might work quite happily. And then Google releases a new version of the browser and then all of a sudden things break. And whose fault is that? Well, it’s worth defining that upfront is no one’s fault, but obviously someone has to pay for the fact of what was working is no longer working.

So it is worth determining your target devices and being really clear on those because that is one thing that can really bite you in the butts if you don’t define it carefully.

So I want to talk about test cases and we’re now drilling down into the details and I’m sure many people have heard of test-driven development, but there’s also testing in the moment and documenting as you go. But then we have this kind of conundrum, okay, do we have a testing plan? How do we manage this? So in your experience, what do you think about test driven development and does that generate the right kind of results in terms of generating value? Did your testing engineers just test in the moment and document as they go, or do you go with a really thorough testing plan? How do you work that?

Michael Luchen: Yeah, so in my experience at Crema, our test engineers have led the company in, so basically the understanding that quality is everyone’s job. And so going from that, our developers are practitioners of test driven development, making sure that those integration tests are written into the code for the components that makes sense. So that when the actual testable functionality gets to a test engineer, they have space to be focused more on manual testing from the user’s perspective, writing automated tests, performing exploratory edge case testing and more.

Ben Aston: Yeah. I mean, and you talk about everyone being responsible, but obviously the enemy of everyone being responsible is that no one’s responsible. So how do you encourage quality I as a value in the organization? How do you? Practically, what does that look like?

Michael Luchen: Yeah. So a lot of it, it starts with a foundation of education, having Slack channels where we’re talking about it, making sure that there’s just an ongoing discussion around what quality is to our projects. But I think from a tactile perspective and especially at an area that project managers can help out with is being able to set up processes that allow teams to be able to have quality checks throughout. So quality becomes a part of that. So for example, we use JIRA and the workflows in there allow us to, if we wanted to set up code review checks, we can enforce those. Although I think enforce is a strong word because it’s really a service of the work, but it allows when something goes from in progress to on staging, it goes through a code review and then when it goes from staging into QA, then we have a whole process for that to ensure that it gets the adequate time and coverage that it needs.

Ben Aston: Yeah. So integrating quality into the process itself, not just thinking, “Hey, it’s about building the component and then it’s done. Then maybe we QA it,” but it’s like, “Hey, part of this being developed is it being tested.” So I think that’s a strong approach. And I mean, you talked about integrating unit testing into your code as you’re developing it. And then that begs the question then for me, we have manual testing that will enable us to do that, but also automated testing. I mean, how strong is your automated testing and how’d you decide when it’s worth doing it? Because it obviously takes a long time to set up. How do you balance that in terms of your workflow?

Michael Luchen: Yeah, that’s a good question. I mean, it leans into exactly how I approached that. And so manual testing is very valuable. It’s low hanging fruit. You can easily dive into that, but I think it’s particularly valuable when compared against automated tests seem to consider it when the user experience is very involved. Or maybe just setting up automated tests wouldn’t be the effort. An example of this might be a drag and drop interaction within an app.

Automated testing on the other hand can be great when you’re doing something over and over again. Long complex information forms are a great example of this. Bonus points, if your test engineer can write auto fill criteria with all those crazy characters that all of our apps are always a fan of.

Ben Aston: Yeah. And so it sounds like your approach for this quality management plan, that’s where we started with this is, hey, we can get things done right when it’s part of our integrated process as part of the development, but also when we’re thinking perhaps rather than a one size fits all approach to quality and how we do testing. But that’s tailored towards the project, that’s tailored even towards the components that you’re working on. So how do you balance that and you’re making the quality management process and planning seem and sound like, hey, this is actually quite organic, it evolves and it changes depending on what scenario you’re in. So how do you get to that point where you’re like, “Hey, I’m really confident that this is the right approach for this thing that we’re building.” In the midst of that organic process, how would you define the actually you’re taking the right route?

Michael Luchen: Yeah. That’s a good question. I think I’m hesitating because I’m a huge fan of the organic process. If you think about how we identify velocity over a period of a couple of sprints or so to set us up for success throughout the remainder of a project, I look at quality the same way. When we start a project, we’re always going to have that first good stab at it. And I think the article I wrote about, creating a quality management plan outlines a really good framework so you can come in with a really solid foundation of how to approach it.

But that’s always just an assumption. And it’s like especially if that team hasn’t worked together before, there’s going to be things that naturally and organically edit and flow throughout those first few sprints or few weeks however you’re approaching the project. And I think just being open to saying like, “Okay, this can’t edit and flow a bit,” not too much. It shouldn’t deviate dramatically. But maybe we get into the initial release of the product and we realize that one of our target devices is not being used by anyone, and so we need to be able to have the flexibility to go back and update that target device list so we can have more time and energy around other areas.

And yeah, so I think just really leaning into that aspect of it is so key. And then of course for me, the next time I start a new project, it’s always going to be based off of the experience of the previous project, although with empathy of the new team in mind.

Ben Aston: Yeah, I think common sense plays an enormous part in quality management and I think often if we’re not too careful we can go down the route of, quality trumps everything. Therefore, we’ll create this really solid quality management plan, put these checks and balances in place. But then it becomes something for me, which is a bit like documentation where we’re doing things just for the sake of it, rather than being a bit more organic about it, which is what you’re talking about.

And somewhere we need to balance this in the middle of, hey, we have checks and balances in place and we have a plan and, but we also need to use our common sense and adapt as we go. Which again, it comes back to this Agile approach that we’re talking about, but not being so blinkered and dogmatic about the quality management plan that we can embrace a bit looser, maybe exploratory testing for things and adapt as we go to ensure ultimately that we’re delivering value and we’re delivering value incrementally. And ultimately the project or the product that we’re working on overtime increases in value and as part of the quality that we’re delivering.

Michael Luchen: Exactly.

Ben Aston: So we actually recently launched a podcast on our sister site and it’s called the QA Lead. So if you’re interested in QA and you work with test engineers and QAs, tell them to check out the QAlead.com and be sure as a PM to start checking out. The post is super detailed and it’s got a sample and templates that we’re sharing through membership and through that.

If you can use a quality management plan, if you haven’t used one before, chat this out. It’s really going to help you think about your process, think about your project or the products that you’re working on and how you can deliver more value by delivering a better quality product.

So I think these tips have all been so valuable, but I think really what resonated with me was really just this idea of actually this is something that in terms of a quality approach, something that we need to cultivate throughout the organization. And whether or not we have test engineers or not, actually having a part of thinking about quality, not just in terms of, is this thing broken or not? But actually, this also is a reflection on our process and something that we need to think about. The entirety of the organization, are things working, how can we improve them? And having more of that iterative mindset. So thank you, Michael so much for your insights on that.

Michael Luchen: Thank you.

Ben Aston: And I wonder what you think. What are your hacks, tips and tricks for delivering projects or products with quality? Tell us what works and what doesn’t work. If you’ve got any fail stories or wins that you want to share, tell us in the comments below.

And if you want to learn more and get ahead in your work, come and join our tribe with DPM membership, head to thedigitalprojectmanager.com/membership to get access to our Slack team, templates, workshops, office hours, eBooks, and more. And if you like what you heard today, please subscribe and stay in touch on thedigitalprojectmanager.com, but until next time, thanks so much for listening.