Business Agility Q+A with Miquel-EN

We all know agile was initially designed with software development teams in mind. However, business agility is only possible if an organization has a quality-oriented culture that collectively shapes what we do as an organization and how we do it. To accomplish this, agile team practices have had to spread to all areas of an organization, so that now agile teams now exist in a wide variety of departments beyond IT, all with different functions and skills. Agile teams can now be found in HR, Marketing, Finance, and even Legal departments!

Ensuring that teams across an organization work with common practices inspired by the Agile values and with a Lean mindset is not easy. Teams are not always clear about what it means to be agile and which practices best fit their needs and enable them to respond to change efficiently and sustainably.

Our expert, Miquel, recently presented a webinar, 7 Business Agility Practices That Work for (Almost) Any Team, to share 7 Lean Agile practices that are essential for any agile team who wants to respond in a sustainable way to the changing needs of its customers! During that webinar, he received some awesome questions and provided some equally awesome answers, and we wanted to share!

Since most of the questions were asked about a specific practice that Miquel recommended, here are the Cliff’s Notes:

Establish, normalize, visualize, and prioritize the flow of work

Collectively own the work delivered

Explicitly agree on standards and policies

Automate work

Create and maintain a Definition of Done

Conduct Peer Reviews and Pairing

Establish learning cycles and continuous improvement

We also hope you will go beyond summary version and listen to the full recording!

Miquel Answers Business Agility Questions

What do you recommend for doing peer reviews and pairing?
Let me give you an example. For this presentation, I had some pairing, and I had some peer review. I did pairing with one of our visual thinkers to help me choose the appropriate images. And she always makes great suggestions – not about the content, but about the visuals and the experience of the presentation.
And let’s say I had a colleague who has the same skills and abilities as me; that person may have delivered that presentation herself, so she reviews it for me, and then she suggests, “Oh I like this idea. I like this other one. Why don’t you change the order here?” Because I know the content.
This is peer review, and pairing – two examples of this technique, Practice #6, that I recommend.
What is a good way to get the Product Owner to engage?

Let me change the question for a moment. As we’re talking about business agility practices that work for any team, my first question would be: is your team going to deliver more and going to be better by having a Product Owner? Do you need a single individual to prioritize and organize the work?

The Product Owner role is great for software development teams, but does that mean that it works also in other teams? I’m just challenging the role of Product Owner on every team, because this is quite a – what I call a non-brain decision, an immediate (assumed) decision. I hear people say, “Oh, let’s do agile across the company. Let’s have some business agility – let’s have Product Owners!” That decision may break the dynamic of a team that is already working great. So first, make sure that you need the Product Owner, and then, let’s go for your question – what is a good way to get the PO to engage?

In fact, this week, we’ve been talking with one of our customers about the Product Owner role. We started by looking at the PO description as it is in the Scrum guide, the PO description in other companies, and in their own current Product Owner role description. We compared to find the similarities and differences. And when we found something similar, we’d think, “Okay that may be good,” or we may challenge it even though it’s similar. And when we found differences we’d think, “Hmm, why is this team doing this while that team is doing that?”

For example, one of our customers said, “The Product Owner is in charge of the team.” I’ve seen that on a PO description, and that may work. I’m not saying that that doesn’t work. But what you need to do is agree on the role of the Product Owner and agree on that with the PO themselves. If you involve that person in their role description, in their job description, they’re going to be more engaged with the team and with the work. Make that person feel like they’re providing value and are doing a valuable job for the team. Make that person feel appreciated for what they’re doing.

What are your thoughts on team charters to help with Practice #3?

Having a team charter is related to Practice #1 (“Establish, normalize, visualize, and prioritize the flow of work”) as well, in my opinion, because the team charter is making your agreements explicit. “As a team, we do this.”

There’s also a great tool called Team Canvas that you can fill out with your team to facilitate agreement on your values, your thoughts, and your roles, and to understand what and how every individual is contributing to the team. So, I think a team charter is great for Practices #1 and #3.

Do you have any recommended templates or formats for “Definition of Done”?

I have two suggestions on this that are related to Practice #5 (“Create and maintain a definition of done”) and #1 (“Establish, normalize, visualize, and prioritize the flow of work”).

The Definition of Done is not a static definition; it’s an evolving definition. And it evolves every time there is some kind of misunderstanding about what you deliver. So, you deliver something, and it’s “Boomerang work,” because it comes back to hit you in the head again. When that happens, we review what happened and say, “Oh yeah, that’s because we forgot this.”

So, this thing that you forgot, is it already in the definition of done? If yes, then figure out which guidelines/rules you didn’t follow so that next time you are sure check all. If not, should it be added to our Definition of Done? And then the definition evolves.

When it comes to starting a Definition of Done from scratch, let’s say you finish many similar elements of work. Ask yourself: What do they have in common? What have we done to those elements of work that was needed in order to finish them? Did we publish them on our internal documentation system? Did we check that process? Whatever we did, let’s collect those ideas – now we have a starting Definition of Done, then you review it.

This is something that’s related to Practice #1 (“Establish, normalize, visualize, and prioritize the flow of work”). In fact, the Definition of Done is the last step of your workflow. So, if you want to establish and understand your workflow, I start with the Definition of Done.

I recommend building it backwards, from the end – okay this item is done. Is it done-done? Yes, it’s done-done. Okay, so what was the previous step before being done-done? The previous step was getting the acceptance from this, this, and this. Okay, so that’s the previous status of that work. And what was the previous step before that? And then you go backwards from there.

Something that I’ve seen a lot of times is that people try to do the workflow forwards, from beginning to end. But I always suggest designing the flow of work going backwards, from end to beginning. I think you will realize it’s easier, and then you can also have a Definition of Done of each state of the work if needed.

We also have a quick tip on our website that you can download to help you know when you’re done.

How do you recommend flow of work for non-task-related work, such as Human Resources employee relations? i.e., conflict management, negotiations, coaching, etc.

There are product teams that are building something. Then you can have service teams. Then you have teams that do a lot of unstructured stuff. They do something that is completely different from other teams. Maybe your flow of work means that you have 17 different flows of work. Does it make sense to have 17 different workflows? Probably not. However, you can start from a simple “To Do, Doing, Done.”

And from there, you can say, “I need to do a coaching session with this person.” Okay, To Do: coaching session. “I need to do a negotiation with that customer.” Okay, Doing: negotiation. And there’s going to be a miscellaneous mix of work in there, but at least you have a visual place to know what’s going on. So maybe you can’t go deeper, but for sure you’re going to have a nice picture of the flow of work and what’s going on in your team.

What if you have a team member that constantly misses meetings?

When we said, “7 business agility practices for almost any team”, we didn’t mean that these were the only business agility practices needed. What I haven’t included here, and it’s really, really important even though it’s a completely new topic – it’s about soft skills. Human behavior, soft skills.

So, if someone is constantly missing the meetings, there are a few things I would consider:

• Which kind of meetings?
• Is it an important meeting or a non-important meeting?
• What happens when we talk to that person?

There’s a lot of soft skills that need to be in place here to solve that conflict. And for sure, having someone in here like a Scrum Master will help to solve this; however, that doesn’t mean that you should have a Scrum Master on your team. This is a really open question that I wouldn’t dare to answer with one of these practices we’ve covered in this webinar. I would suggest going deeper with soft skills to solve this kind of problem.

Please let me know below if you have other questions that I can answer to help your team!

— Miquel

Do you have a question about business agility?

Let us know and we’ll get you an answer!

Ask a Question