The 2 AGILE Methods You Must Know
When talking Agile, the sheer number of methods can be confusing. Lean, LeSS, DSDM, Disciplined Agile, SAFe, Kanban, Scrum, Crystal, … the list is endless. Being a business owner, you will not want to waste time and money in methods that don’t lead you anywhere. So, here are my 2 favourite Agile methods in short. And Gurufix and Bigboss are back too 😉
For those who have missed the episode where Gurufix explained the concept and the idea behind Agile to the entrepreneur Bigboss …
Don’t worry, grab the
Bigboss: “Hi Gurufix, ready to go?” (And without waiting for an answer) “I did some research over the weekend and wow; this Agile thing is more than confusing. There seem to be dozens of methods, but it’s all about software development and we don’t do software!? Are there also methods that can be applied outside software development? And…”
Gurufix (after a short sigh): “STOP. Take a deep breath, sit down and let’s start from the beginning, shall we?”
Bigboss sits down: “OK, tell me all.”
Gurufix: “It’s true, that there are tons of methods and most of them are either not suitable for non-software developers or just too complex and require a considerable amount of time and money for training and to go through the learning curve and we have neither of them.
Funny enough, Agile is promoting simplicity and flexibility, but most of them require a very strict following of the procedures and a certain team size in order to work.”
Bigboss: “Hmm. And which one will be right for us? Do you have an idea?”
Gurufix: “Sure I have an idea. That’s what you pay me for, don’t you?” (grins)
“I have chosen 2 methods that I want to introduce to you. One for its simplicity and the other, because it’s all over the place and you might at least want to know what it is, when someone puts it forward. Let’s start with the second one.
SCRUM is one of the best known and most rigid Agile methods. The key points are, that it’s a pure team approach without a dedicated project manager and that you give a product increment to the customer every 2 to 4 weeks depending on the length of each Sprint for evaluation.
There are loads of documentation around SCRUM, so I will just resume in some words …
How it works:
- You start with a so-called product backlog, which is a kind of catalogue with all the requirements, features, benefits, user stories, etc.
- The product owner and the team put these requirements in a rough order from high business value items to low business value items. The most important is on top of the list. They also estimate the effort for each item.
- At the beginning of each Sprint the team sits together in the Sprint planning and decides which items to work on in the next sprint starting from the top of the product backlog. The result is the Sprint backlog.
- During the Sprint who takes 2 to 4 weeks depending on the type of project or product the items of the Sprint backlog are processed. Each morning a Scrum, which is a short stand-up meeting, takes place, where all team members meet and everybody says what he has accomplished the previous day, what he will work on today and if he needs support in some respect. The completed items are then put in the burndown chart as completed.
- After each Sprint the results accepted as Done are presented in the Sprint Review. What is not entirely Done goes back into the Sprint Backlog for the next Sprint.
- Normally these results should be delivered to the customer for immediate feedback. The customer feedback is then considered in the Product Backlog which is in constant evolution depending on this feedback.
- After each Sprint the team holds a Sprint Retrospective Meeting, where the team discusses what went well in the past Sprint and what didn’t and how to get better.
- And then it’s rinse and repeat until the project is finished.”
Bigboss: “OK, that sounds pretty straight forward. But how do I know when everything will be finished?”
Gurufix: “You don’t. You might have a rough idea once the product backlog is estimated, but with the constant customer feedback things can slide. But if you look at standard waterfall projects you have no clear idea either, don’t you? I mean you have a project plan from beginning to the end, but only to see the milestones pushed back as time goes by.”
Gurufix: “And there is one more point that I need to call your attention to. First, you should not modify the system to make it more digestible for you or the banks or anybody else, because you will completely loose the efficiency and just earn a project management system with more meetings that you have ever seen! So, it’s a take it as it is or leave it altogether thing.”
Bigboss:” What do you mean by that? Do you have an example?”
Gurufix: “I’ve seen companies using Scrum, but actually never implying the customer or other stakeholders to gather feedback. The customer got a release every 6 months and was completely unhappy and they had tons of missed functionalities. But they earned heaps of useless meetings and planning sessions, because the product owner tried to do his planning until the end of the project. Scrum doesn’t work like that.”
Bigboss: “I’d really like to know more about how this works, and I got a little lost in the wording. But I only got an hour, so we need to go into this more in detail soon. What’s this second thing you wanted to show me?”
Gurufix: “Ok, so we should schedule another round on SCRUM, so that I can get you more into the concepts and the wording, which by the way will also help you move our project management to the next level even if we don’t go for SCRUM. Let’s talk KANBAN.
KANBAN is a well-known principle from the production industry transferred into project management. It’s very simple, much less formalised compared to SCRUM and combines well with traditional project management. Therefore, it’s my favourite.
So, how does it work?
- As with SCRUM you start with a Backlog, which contains every requirement, feature, benefit and thing to be produced within the project.
- Then the project manager and his team order the Backlog by priority and perhaps build sub lists following whatever criteria makes sense in the project. For example, they could make a list containing only the task a certain person has to perform.
- Next, we narrow down the items on the list which must be done in the near future e.g. until next decision gate. So that we can refine them, get clarity what’s behind and they become easy to estimate. For the things to be done further down the road we leave them as bigger blocks.
- Then we estimate the duration of those tasks which have been refined.
- And then it’s time to execute. At every project team meeting the project manager will check-in with his team to make sure everything is on track, provide guidance and support if there are any roadblocks.
- In KANBAN it’s up to the project manager to get in touch with the customer and the stakeholders to make sure the team is not running in the wrong direction.
- The advantage of KANBAN lies in its flexibility so that it can be adapted to different project environments and even serve within a standard waterfall planning to minimalize the planning effort. And being very simple to use and implement there is not a steep learning curve for the team, the project manager and the General Management in order to make it work.
Bigboss: “Sounds great, but how would you use it within a waterfall project?”
Gurufix: “I would plan the big work packages and the relations between them e.g. the task “design product” which has to be finished before the task “document product” in waterfall style with a GANTT chart. But for the stuff to be done within each block I would use KABAN combined with a burndown chart to make sure everybody is aware of the effort remaining until one package is finished and to show if everything is on track. That keeps the planning and task shifting to a minimum, but still provides a good amount of control.”
Bigboss:” Ok, would you mind setting up some training for our project managers, so that we can start with this KANBAN thing asap?”
Gurufix: “Will be a pleasure.”
Bigboss:” And then, I would like to spend an hour or two with you next week, so you can get me up to speed with everything I need to be aware of before I decide to go or not go for SCRUM.”
Gurufix sighs: “That would take at least an entire week or two. What if we already talked about the do’s and don’ts when it comes to SCRUM? Then you will know, if it’s worth looking at.”
Now it’s your turn!
Have you introduced AGILE in your company and which method do you use? SCRUM, KANBAN or something else? I am curious to get your feedback on what method you use and how this worked.
And by the way, if you have a question, then you can get my one question one answer product for free. Try it now.
You missed the last episode? It’s here!
If you liked this article, please share it on the social media or give us a great comment below. And don’t forget, you can also send me chocolate. 🍫
Now, go below to the comments, ask your questions or let’s start a discussion! I will be glad to help and as you already know I answer all questions.