agile

What is Devops?

Hi guys, Anatoly from Define Agile here today. In a very high level, I’m going to explain the concept of Devops and I’m also going to answer question that one of you asked me: Is Agile and Devops the same thing?

I’ve been a developer for many years, largest part of developers is job to write code according to an acceptance criteria. Next, to make sure that the customers can see your code, you need to deploy your code to a production environment. For this to have there is a certain tooling required and certain operations required between you writing your code in your computer and this code being deployed to production and visible to end customers.

Deployment and actual coding, in a bigger companies are done by different departments. One is the development department (engineering department) that actually builds the product and the other is operations department – the department that makes sure that whatever you build gets deployed to production with ease, gets monitored, and if there are any issues with your code that you’ll know early, and if something is wrong with production environment – developers are notified right away.

Devops is getting those two departments together, making sure that they work as a one unified team, making sure that they establish rules among each other, making sure that whatever code is deployed is getting monitored for any errors.

Agile is an umbrella of terms and Devops is one of the tools that allow you to move to Agile, to move to iteratively delivered software. Hopefully, now it’s clearer for you what Devops is and Agile is the same thing.

If you have more questions, please ask them in comments to youtube video. If you want me to help to move your teams to Agile, please click on FREE Consultation above and lets talk how I can help your team.

School of Agile

We Don’t Document In Agile!

What is going on, guys? Anatoly, from Define Agile here. Let’s talk about today’s topic. This is a very important one and I think we should talk more about it. It’s about documentation.

Stephan asked me a really good question on LinkedIn.

Stephan asked, “I was wondering if you might have a video where you talk how to handle the documentation when we’re working according to some ISO certification. In Agile, especially in Scrum, we want to minimize the documentation. On the other side, working on some ISO certification is requiring quite some documents. I was wondering how both of those can be satisfied in the very same project.”

This is a very good question and to elaborate on that, a lot of teams when they see the Agile manifesto, which says value working software over a comprehensive documentation, we might think, “Okay, we should probably document as less as possible,” which is totally not true.

What it means is that if we can choose between the two – you’ll have a working software or really documented pieces of all the requirements – we’ll choose a working software. We don’t want to spend all our life writing requirements for something that’s going to change in a month or two and then all those requirements might be obsolete. In Agile, we’re trying to adopt to change as better as possible. However, there are often things that need to be done by the business and these things cannot be avoided.

So what I suggest you do, Stephan, and many others – think about what does “done” means to you? Try to define your definition of “done” for your team. And if ISO certification is part of the definition of done then you need to do it. I know it can be time consuming, but think how to include documentation in the process in such a way that everyone can contribute to.

If business requires something, you cannot avoid it because, otherwise, you might get audited and it can be detrimental for your business. So, I highly recommend just do what is right. If you need ISO certification, explain it to your team. If you need any other audit documents, you still should have it. Agile does not say, “Don’t document stuff.” If it’s required by your business, you should do it. Agile says, “Don’t document lots of requirements ahead.” Don’t document every line of your code because every thing of this is going to change. If you spend all your time doing that, it’s going to change anyway and you might just waste yourself lots of time.

Hope that make sense,

If you want me to help moving your team to Agile, click on FREE CONSULTATION and lets talk!

School of Agile

Should Scrum Master have One-on-Ones?

Hi guys, Anatoly from Define Agile here. Today we’re talking about one-on-ones. Should Scrum Master or Agile coach have one-on-ones with their peers?

First of all, I just want to make it clear, there is no word about one-on-ones in the Scrum guide. So if you’re strictly following the guide – there’s no one-on-ones there.

However, I have one-on-ones with every team that I work with. Right now I’m working with three teams. Those teams have in total about 25 people. I have one-on-ones with every single person in the team, whether it’s a product owner, QA, business analyst, content strategist, content writer, developer, designer, UX designer, visual designer, anyone. Technically, I am having one-on-ones with every single person there. Why do I do that?

First of all, why are we doing our work as an Agile practitioners? We try to remove impediments. Sometimes it’s very hard to gather the problem especially when you joined a new team or you’re a new person in the team and people sometimes are not ready to start speaking up everything on the retros. But you still need to figure out what the core problems are, so you talk to people one on one, you ask them questions, you are honest with them, you understand their problem, you help them solve their problems. This is how the trust begins to establish between you and people in the team.

It also allows you to realize what is not working on a much deeper level.It is important to help every individual on its own and make sure that all their personal things are addressed. Many, times I was able to uncover very big problems that nobody talked about in a team just by having one-on-ones with people.

I always have all my one-on-ones confidential. I never share anything that people don’t allow me to share, but I find this tool to be invaluable.

Are you having one-on-ones with your peers? Is it working or is it not working?

P.S. Do you need help moving your teams through Agile transformation ? Click on FREE CONSULTATION up top, and lets see how I can help your business!

School of Agile

3 Myths about a Scrum Master Role

Hey guys, Anatoly here from Define Agile again. Today we are talking about three myths about the Scrum Master.

Myth #1: Scrum Master is a manager.

This is a very common myth. When Scrum Masters are hired, some people think that they should do whatever a manager should do. This is totally wrong. Scrum Master is a part of the Development Team. In an organizational hierarchy, Scrum Master sits at the same level as the Development Team. Scrum Master role is not to manage anyone but to provide support to the Development Team and remove any blockers. So, Scrum Master is by no means a manager but just a part of the team that’s responsible for team health, promoting Scrum, making sure the processes are clear and well defined.

Myth #2: Scrum Master is here, that’s why the Scrum Master knows all the answers.

A lot of people hire Scrum Masters because they think that they know the answer to everything and that in the first moment they are hired they will start solving all these complicated process problems. Well, this is where very far from the truth.

Scrum Master, as I said, is here to facilitate the discussion and make sure the team themselves realize the right solutions. While Scrum Master will be supporting the team in any way he/she can to make sure that there’s a right environment for the team to come up with good solutions, often when Scrum Masters come to new organizations, they have no idea what is happening. Also most of the cases are very different, so saying that Scrum Master can know everything and come and solve all your problems right away is not true.

Myth #3: Anyone can be a Scrum Master.

It always fascinates me when people say, “Oh, I don’t need a Scrum Master because anyone can be a Scrum Master. What’s so hard in that?”

It’s the same as saying if you have legs you can be a good soccer player, or if you can type on a keyboard you can be a good software developer. We all know that this is not true. Making sure that processes are good, understanding how it will work takes lots of experience.

I know you will say that getting a Scrum Master Certificate is not that hard, but do we really say that all these people who have a certificate are good Scrum Masters? I don’t think so. I think that having deep experience is very beneficial because it gives you insight on how stuff is run and makes your decisions more educated. So, “anyone can be a Scrum Master” is not true.

These are three commons myths about Scrum Master that we debunked just now.

School of Agile

Agile for Non-Software Development Projects

Hey guys, Anatoly from Define Agile here. I’m stoked to see you because this topic is amazing.

Today we’re talking about: can you do Agile in any kind of business not software-related? If it is not a technology company, if it’s a physical product business, monitoring agency, if it’s a hospital, can you do Agile there?

The right answer is definitely yes.

I have a special thing for you, just in the end I created a document you can download that will guide you through that first steps moving any business to Agile. I’ll tell you how to get it right in the end.

Now I just want to give you a little bit of taste of what you can do in any business to give it some Agile flavour.

For example, you can adopt some Agile ceremonies to your business to improve transparency, to improve communication between your team or teams. You can have a daily stand-up in the morning to talk about what you guys did yesterday and what are you going to do today and if there are any blockers.

You can plan your work in iterations. Have a planning meeting every couple of weeks. Sit down and plan your work for the next two weeks with your team, set yourself goal for this timeframe. At the end of those two weeks – demo your work and show how you achieved your goal, also have a retrospective where team will look at what went well, what did not go well.

Agile is all about measuring and making decisions based on data. So you can measure many things in your business. You can measure conversion rate, you can measure your copy before testing.

Agile is all about making sure that the product you release is reliable. There are many ways you can make sure that your product is more reliable. If it’s a physical product, you can do lab testing. If it’s a marketing copy, you can do an AB testing. So there’s a bunch of ways you can test your work to make sure it is reliable.

Documentation. You have lots of process around your office that nobody knows about ? Put them in one place and create this hub of documentation. When new employees join, they always know where to find stuff so this will be very useful for you.

I know it can be confusing. I were just where you are right now. I have my own physical product business and I do apply Agile there, and I have friends and clients who apply Agile to their businesses. And you know what, we all found that when you do Agile, your employees are happier, you have less turnover, you have better decision-making based on data, you have better process, so it’s definitely worth a try.

So, how would you go about starting this? I created a special PDF which is Agile checklist, how you can move to Agile in any company. There’s a link down below, click on it, download it, print out the PDF, read through it, and try those things.

Agile checklist: https://defineagile.com/agile-checklist

If you don’t want to do all of them, try some of them. Implement them in your business and see if they make any difference. Try them for a couple of weeks, see if it works for you or not.

As I said it can be really hard, so if you need my help, please click on FREE consultation and lets see how I can help your business!

Anatoly

School of Agile

Scrum Master KPI – Agile

Hey guys, Anatoly from Define Agile here. Today I’m going to be answering a couple of questions from Sint.

What are the top three KPIs for a Scrum Master and Agile Coach during their three months at a company?

That’s a great question. Not many people talk about KPIs for Agile Coach and Scrum Masters. I think that they should have KPIs. I think that they should plan to do something cool and then make sure that our people will keep them accountable for it.

When I joined the team, that I am currently consulting, my KPI was: “I want to make you the most efficient team in the department in three months.” That was my KPI.

The reasonable KPI’s would be:

“I want to set up Agile ceremonies in one or multiple teams.”

“I want to have an Agile workshop that everyone in the company understands Agile”

“I want to make sure to meet with every team member, understand their concerns and resolve most of them.”

“I want to set up Jira in such a way that people will find it useful.”

“I want to help create a process around interaction with our stakeholders”

“I want to improve transparency and happiness” ( you can measure that by having some happiness with your exercises on your retrospectives).

The next question is:

Scrum Masters/Agile Coaches we are often givers of the team as resources, removing blockers, etc. How does one fuel himself personally with new ideas to experiment?

I fuel myself with ideas by asking my team. I ask people, what would they think would helpful? They might say: “Maybe we should do this, maybe we should do that,” I say, “Definitely, let’s try that.” This is how new ideas would work. I gather information and act on it right away.

Since I have experience working with different teams, I might recommend them some ideas.

Also, I am part of Facebook/Linkedin/Reddit groups. I read books about Agile, about Scrum. I talk to people in the industry and then we share what works, what doesn’t. I have many peers that I know who work in different companies and they have many different ideas, so we share them as well.

Thanks for reading, hope that helps!

If you want me to help your teams be Agile, please click on FREE Consultation above and lets see how I can help your business.

School of Agile

Velocity in Agile Methodology

Hi guys, Anatoly from Define Agile here!

Today we’re talking about velocity in Agile.

A lot of you guys ask me:

“Anatoly, what is velocity?”

“How can you calculate it?”

“What is an average velocity?”

“Do we even need to care about it? Is it something we need to track?”

Those are all amazing questions. I’m going to answer all of them.

Velocity is a metric that shows us how successfully we complete our stories.

Here’s an example:

We are a team of people. We have a two-week iterations or two-week sprint. In these two weeks we thought, “We will complete ten stories,” (stories are features) and we said every story we think is a two-story points value (arbitrary measure of how complex story is + how long it might take). So then if we complete all of them at the end of two weeks, our velocity will be 20 points.

Easy, right? We have 10 stories, 2 point stories each equals 10 * 2 = 20. If that is all that we need to know about velocity, why so many people are confused by it ?

First of all, because velocity is not a precise measure. Velocity is based on estimates, so it can definitely vary. I also find that if you have a small project and you don’t give enough time for velocity to establish itself, for a team to learn how to estimate properly, then velocity will be pretty useless.

However, if you have a team that works together for a long time and that they track everything, they are pretty good at estimating their stories – velocity would be pretty accurate. They will be able to predict how many stories they can complete in a certain iteration, which is very good for road-mapping, for giving expectations to the business and stuff like that.

The most useful metric I find with regards to velocity is an average velocity. To calculate average velocity, we usually take about four iterations, we add them up, and divide them by their number.

Let’s say our team worked for 4 iterations of 2 weeks. First time their velocity was 40, the other week it was 10, next week their velocity became lower: 20, after that their velocity came back to 40, and finally it lowered back to 20.

What we need to do is we have four numbers: 40, 20, 40, and 20. We take all those numbers, add them up. We are having 120 and then we just divide them by the amount of those numbers. So we divide them by 4 and then we know that our average velocity in this case is 30.

I find that average velocity is useful for a team because it shows them how they progress, if something went wrong, and if there’s something that we as a team can improve. So, it’s a good metric for us internally to see if something has gone wrong with the team. Also, when we as a team are doing spring planning, we sometimes think, “How many stories can we take in two weeks iterations?”

If we have average velocity, we can say, “Our average velocity right now is 30, so we should probably take somewhere around 30 story points.” You can go a bit more, a bit less, depending on if people are on vacation, stuff like that. But this metric helps us to know how much work we can take.

Thank you for reading! If you need my help moving your teams through Agile Transformation, please click on a FREE Consultation above and lets see how I can help your business!

Anatoly

School of Agile

Difference Between Scrum Master and Agile Coach

Hey guys, Anatoly here from Define Agile. Today we’re talking about the difference between Agile Coach and a Scrum Master. I’m getting asked lots and lots of times, “Anatoly, what’s the difference? They sound familiar, they both deal with Agile, so what’s the deal there?” So, I’m going to explain to you just that today.

The biggest difference between Agile Coach and a Scrum Master is in the scope of their work. While Scrum Master is focused on a single team, making sure that the team processes are in place and the team operates as one single efficient unit, the Agile Coach, on the other hand, is focused on making sure that the whole organization understands Agile well.

Agile Coach is not only focused on Scrum, the good Agile Coach knows different frameworks and understands that to achieve different results, you can use different tools. So, Agile Coach is more enterprise level working with the executives, working across teams, supporting Scrum Masters, making sure they have everything they need, and making sure that the whole organization is moving to Agile transformation.

It does not mean though that Scrum Master supports the Agile Coach. Agile Coach supports Scrum Masters. Scrum Masters then support their teams. Also, Agile Coach brings to the executives all the impediments that Scrum Masters have that they cannot resolve at their level. Agile Coach should be able to help resolve those bigger issues with the help of executives.

School of Agile

Scrum Master Interview Questions: 3 Most Important Questions to Ask

Hi guys, Anatoly from Define Agile here again. Today we’re talking about three questions you can ask a Scrum Master to understand if he/she is a good fit.

Question #1: What was your worst day at work?

You will tell me, “Anatoly, how does it relates to a Scrum Master?” Okay, let me explain. First of all, Scrum Master is a person who brings Agile into an organization, usually helps organization to transform to Agile. When you work with a constant change and tasked with transformation you deal with lots of conflicts and stress. So if a person doesn’t have enough experience dealing with the high stress situation, it will be very hard for this person to be successful at the job.

I find that people who tell me that they had a really bad time at work and then they were able to overcome it and they still love this work, those are the people that I want to see next to me working as Scrum Masters. If people didn’t have any major stressful change-related experiences in their career yet, I might find that they don’t have enough experience for them to join my team.

Question #2: Tell me the difference between Kanban and Scrum, and when you should use one or the other.

You’ll tell me again, “Anatoly, why would a Scrum Master know about Kanban? Why should he/she care?” You care for the sole reason that the Scrum Master needs to be a well-rounded person who looks around and understands all the other frameworks that are there and makes sure that the Scrum Master can make an educated decision which one to choose. So if a Scrum Master always works in his/her small box of Scrum and not looking around what is happening in the industry, I don’t think he’s the right person.

Question #3: What was the change that you introduced to the team and how did you do that?

This is very important, because the Scrum Master comes to the team and often introduces lots of things that the Scrum Master thinks is right. If you don’t introduce them well, if you force something on people, it won’t work and then you won’t have any good relationship with your team. The Scrum Master is there to support the team, to advice things, and a good Scrum Master should be able to explain to you how he made sure that everyone understood that the change is good and how he rallied people around the change and made sure they implement in such a way that everyone is happy.

These are my three questions I usually ask every Scrum Master.

School of Agile

Difference Between Product Owner and Scrum Master

Hi guys, Anatoly here from Define Agile. Today we’re talking about the difference between a Product Owner and a Scrum Master. A lot of times people are confused between the roles and responsibilities of those two. Sometimes Scrum Masters are taking the role of Product Owners and Product Owners are taking the role of a Scrum Master. So, I’m here to figure out what exactly is the difference and why people confuse them so much.

Let’s start with the Product Owner. Product Owner represents the stakeholder. The role of Product Owner is to go into the field of stakeholders, figure out the requirements, make sure they are clear, and then put those requirements into stories that the Development Team or any other teams can work on. Also, the Product Owner’s job is to make sure that the backlog, which is a collection of stories, is prioritized so that the team has enough work to do and every unit of work they take has everything they need to complete it.

Let’s go to the Scrum Master now.

The role of the Scrum Master is to help the team to understand Scrum. The role of the Scrum Master is to promote Agile, facilitate meetings, make sure that the processes are good, make sure that the team is healthy, they trust each other, figure out the ways on how to make the team more efficient in terms of processes, make sure to optimize things that don’t work, and support the team in anything they need.

So as you might see, those are two very different roles, and if one person starts to do both of them, most of the time it doesn’t really work. If you don’t have a dedicated Scrum Master, my suggestion would be instead of making a Product Owner a Scrum Master, to make one of the developer Scrum Master or make a rotating Scrum Master role in your Development Team because I find it to be much more efficient than to have a Scrum Master and Product Owner in one person.