Hi guys, Anatoly from Define Agile here. I keep on answering your questions. The question of today is“What are the best tips for efficient daily stand-up meeting in a job project?”
Tip #1: Make sure that everyone in your Development Team is present on every stand-up.
Why is it important? It’s because a stand-up is all about finding dependencies. If somebody is not present, we might not state some dependencies, which might be detrimental for the team later on.
Note: If you find that the team is late for stand-up, maybe talk to them, and move stand-up to a later time. If you have remote workers, make sure you accommodate for their time zones.
Tip #2: A stand-up needs to be short.
Make sure that the stand-up is not longer than 15 minutes. Make sure that somebody in your team can track time.
Note: If you see the conversations are going for too long, make sure to let people know that they can talk about it after stand-up and they can just catch up later.
Tip #3: Talk about things that are related to other people work.
Make sure that everyone who talks during a stand-up, they talk about things that are related to other people’s work. Stand-up is all about making sure we’re finding dependencies, we need to unblock all those things that bother us.
Those would be some of the main tips for you to have a successful stand-up.
Hey guys, what’s going on? Anatoly from Define Agile here.
I keep answering your questions and this one is: “How do I get started with Agile and Scrum?”
It’s a very, very good question. A lot of people are just starting out, a lot of teams are just starting out, and they are not sure which way should they go. There are so many options and I’m going to navigate you through a couple of them so at least you have some idea where can you start.
Option 1 if you have lots of time: Be a Self Starter, try it with your team and lean from your mistakes
First of all, how did I start with Agile and Scrum?
In 2011, I was a software engineer, when I have realized that a lot of our projects have changing requirements. Very often client would change their mind, and we would have to re-plan everything. I have realized that, doing a typical traditional Waterfall method did not work very well for us. At this time, I was reading about Agile and Scrum and I decided to ask my team to try it.
We were trying it for about five months. At first we made lots of mistake, we did not follow Scrum the way it was written, then in about five months, we were able to finally get to a good version of Scrum and Agile. It was pretty cool. We tried it. I learned a lot.
Mind you, not everyone has that amount of time or able to fail that much. You might have stakeholders, you might have executives, who won’t be happy with that, but I had this option- so I took it.
Option 2 for individual, if you don’t have much time: Get Certified
The other option would be, if you want to learn about Agile and Scrum as an individual, you might consider getting certification.
To prepare for certification and to understand what you are getting yourself into: there are two things you need to read. First one is Agile Manifesto which states all of the principles of Agile, the other thing, if you have decided to do Scrum isScrum Guide .
Certification will give you credentials, but mind you it is not necessary. You can learn it all yourself, and for the most part you can facilitate meetings without having a certifications.
If you are looking for certifications, the one I would recommend Certified Scrum Master (CSM) from Scrum Alliance. You will learn in a class the basics of agile and scrum and will get certification upon completion. The price varies per vendor, but on average it is about $1,500 + travel expenses.
The drawback of certification course is that you will be the only one who understands Scrum and Agile, and it might be tricky to explain it all to your team. From my experience, much better approach is to transform your whole team to agile, that way everyone can be a Scrum Master.
Option 3, for team, if you don’t have much time: Transform your whole team
The third option would be is to hire a company that would onboard your whole team to be Agile. And there are many different solutions. I cannot speak for other ones but I can speak for what Define Agile recommends.
We have our own two-day Agile Introduction Course led by our two Agile Coaches. They have about 20 years of experience moving many, many teams for Agile transformation. We cover things like:
What is traditional Waterfall method?
What is Agile?
What is Agile Manifesto?
What is Agile mindset?
What is Scrum? What are the ceremonies?
What is Kanban? How can you choose between those two?
When should you use certain frameworks ?
How to persuade your boss ?
How to implement Agile with tools like Jira ?
For the team of 11 it is cheaper per person than certification.We are doing it all over the world. We have lots of happy customers. If you’re interested in that, please go to here and schedule a FREE Consultation.
Today’s question is, “How do I practice my Agile facilitation?”
That’s a great question. If in a company that is interested in Agile, the easiest way to practice your Agile facilitation is to talk to your boss and say, “Let’s do some retrospectives.” A retrospective is a best way to practice Agile facilitation. You can incorporate some exercises – they’re cool, they’re fun, and it gives you a lot of experience.
Say to your boss: “I want to make sure that everybody’s happy with how they are doing things. Can I take an initiative and do a retrospective? We’re going to meet with the team and then talk about what works, what doesn’t work for us.”
When you get a green light – find some good exercises ( this website would be an example of some exercises).
What if your company does not want to practice Agile, or you don’t want to practice on your colleagues (which I recommend is the best way) ? Get a couple of friends and then do a retrospective with them about your friendship. It is important to practice as much as possible.
You can also do it for your goals and plans. If you want to plan a vacation – do the planning in a retrospective format – “Where I want to go ? What I want to do ?”. Collect information from your spouse and kids. You can definitely do that. Then after the vacation, you might have a retrospective. Talk about what worked well, what didn’t work, and what do you want to improve.
So, I highly recommend to do it as much as possible because the more you practice it, the better you become.
The question that I got asked yesterday was: “Most often job postings are written as a Scrum Master/Project Manager. What is the main difference between Scrum Master and a Project Manager? How can you apply those two skillsets to fulfill the needs of the organization?”
That’s a great question. I see those postings up and then people say, “I need to be a Scrum Master and a Project Manager.” I’m here to tell you these are two very different roles. It’s the same as to say “I want to have QA/Developer,” you might think it’s the same but it’s definitely not.
Scrum Master is here to help and support with the process. Scrum Master supports the Development Team while Project Manager is here to manage the project, making sure the project is on time, on budget, making sure the stakeholders are informed about how the process of creating projects or completing project. Scrum Master has nothing to do with that.
Usually when a person tries to fulfill both roles, I don’t find it successful. I find that Scrum Master and Project Managers are on a different sides. They have different accountability. A Project Manager is accountable to external stakeholders or to upper management, while Scrum Master is accountable to Development Team. If one person has too many people he or she is accountable to, there’s a conflict of interest. So, I don’t recommend having a Project Manager and a Scrum Master being the same person.
As an option, which I talked about in “What is the Difference between Product Owner and Scrum Master,” I recommend having a developer to be a Scrum Master if you can’t find a dedicated Scrum Master. Because the developer is a part of the Development Team, developers have an interest of having their Development Teams happy.They are interested in having good process, because it benefits themselves.
Hope that helps!
If you want me to help your teams with Agile, please click on FREE Consultation, and lets see how I can help your business!
Hello again, my friends. . Anatoly here from Define Agile. We’re discovering the world of Agile together, and today we’re talking about the topic that is a big one. Most of people are confused by it. Most people are asking lots of questions about it. What is the difference between Agile and Waterfall methodologies ? I will cover on a very high level.
If you look at the difference between Agile and Waterfall from the very high level – Waterfall is a project that you must delivery in full by Cretan date. You go through stages of your project and in the end you deliver the whole project to your client. You know the scope, you know the budget in advance and itself is very well defined.
Agile, on the other hand, is iteration-based. It’s you deliver a little bit of value – often. In Agile end scope might not have been defined and funding may not have been defined. You even don’t know if this is going to succeed or not. You’re just testing stuff up until you figure out what works, working with your clients and your team to iteratively delivery solutions to certain problems.
Now, let’s go and look at the detail and look at different categories and how they stuck to each other.
Scope
Scope in Waterfall is very well defined. You have a contract of work that you need to do, you know exactly the whole scope from start to the end.
In Agile, you know the scope of the first iteration or several iterations ahead, got some vision, but you don’t know if you’re going to implement it in a certain way. You iterate and base your decisions on data.
Funding/Budget
In Waterfall, funding and budgeting should be done up front. You gather requirements, and get your budget for the whole project.
In Agile, your funding might be for a certain iteration. And then you’ll see, if you have enough traction with your product, you may put more funding. Since the end scope is not defined, the funding can be as big or as little as you want it to be or as the market receives your product.
Client Interaction
In Waterfall, you interact with your clients at the start, you plan everything with them and then you might have some touch points to see, if you are on track, to deliver this contract of work that we decided right away. There should not be any surprises with the client. If stuff changes, there might be a little tweaks but they need to change all that funding and you need to change the scope and stuff like that. So, it’s a big work if any change is happening.
In Agile, you constantly talk to your clients. You deliver a little bit, the client looks at it, if they like it then you move on. If they don’t like it, you repeat the same process until client is satisfied. i
This is my quick rant on Agile versus Waterfall. It was a very high level overview of those two just to get your feet wet in deciding which one to choose.
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.
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!
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!
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.
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.
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!
