documentation

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!

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

documentation

We Don’t Document In Agile!

Facebook