Agile: What’s Next? A Short Guide for Those Starting a Project in the Agile Methodology. Part 3
In previous articles, we mentioned contrasting approaches to Agile methodology, identifying and delivering on the values of a project.
In the final part of this series of articles on Agile, you will learn:
- How does the Scrum methodology drive the team’s work?
- Which elements of a project should you focus on when working in Scrum?
Scrum is a real productivity engine!
A team that works in the Scrum methodology delivers your product faster.
In order for the team to work effectively using Scrum, it is necessary to impose an appropriate pace on the work performed. The hardest part of the whole puzzle is that this pace depends on multiple factors. The key ones include:
- a tight-knit team and the knowledge held by its members
- the division of work within the team
- the approach Product Owner have to managing the backlog
- collecting feedback
- collecting users who are willing to share feedback
- an organization that does not impose a working framework that conflicts with Agile methodologies
- a Scrum Master, who coordinates the work of the entire team on an on-going basis
Each of these elements sounds trivial separately, but the key to success is to get them all working properly together.
Condition 1: Multitasking must go!
A multitude of threads is not good for productivity and will, in all likelihood, lengthen the process of product development. Do not try to include everything in the first version of your product (that would be extremely un-Agile!). Focus the work on one dominant theme. This will be helped by regularly updating the product roadmap and setting clear goals for future sprints that are aligned with the product development vision. Only then in turn, you can avoid starting too many topics and features without finishing them.
Condition 2: Develop as if this sprint is your last
Try to arrange the scope of the project so as to have the ability to finish it exactly when you feel that what has been done is sufficient for you. Imagine a situation where company X outsources a large application development project to a subcontractor. Work is multithreaded and tasks are not prioritized according to the business need. Two months down the line, company X starts experiencing financial problems and has to shut down the project. However, it is not able to use the money invested in any way. If work was arranged according to the Agile commandments, after 2 months company X would already have a working application (although slightly smaller than assumed) that is even potentially making money.
I do not wish anyone a situation where they have to close projects prematurely. On the other hand, I wish everyone could say “stop” when they feel no more product development work is needed (that is why I became a Scrum Master).
Think if the Product Owner will be able to work as effectively with the stakeholders in multiple components, while also meticulously collecting feedback from users. Scrum’s strong point is iteration – small steps that yet bring you very close to achieving the business goal. Use it!
“Scrum is a simple framework designed to help small groups of people working closely together to create complex products.”
– Chris Sims
If it was that simple, this article would not have been written! 🙂
There are a few elements to keep in mind for Scrum to really help rather than impede
(both for clients and developer teams).
Rule 1: Think, try and decide CONSCIOUSLY
“We do 2-week sprints because everyone does them.”
“We use system X to manage the backlog because everyone uses it.”
“We have a Scrum Master as a separate position because we’ve heard at such-and-such conference it’s better that way.”
“The Product Owner is the client’s employee because, after all, that’s how it’s done.”
When you hear such opinions from anyone, plug your ears and do not listen! Go back to the slogan and think about its message again. There is a reason why Scrum is said to be a framework, as it leaves a whole bunch of areas where you can adapt the methodology to your project’s needs.
Are they telling you that a 2-week sprint is best? It might be for you, too! But make the decision on the duration of your sprint consciously. You are working with a new team – why not choose a shorter sprint to give them more chances to get to know each other and adapt their working pace? There are lots of on-going changes in the project, so it is hard for you to plan your work long term. Shortening the iteration will make the scope of the next sprint more predictable! System X for backlog management is popular, but does it seem too complex for your needs? Start with a flip chart or board – it makes sense to use iterative development here too, before you spend extra money on user licenses.
Rule 2: It is about the DELIVERABLE
Yes, all Scrum is about one thing only – the deliverable. Everything that happens in any agile methodology is aimed at bringing about the best possible deliverable. A Daily Sprint has taken 5 minutes longer than scheduled and you are afraid you are no longer working in Scrum because of it? Nonsense! Think of it as a suggestion to see if the discussion is substantive, realistically needed at this stage, and if all who gathered there should be included in the meetings. Of course, such discussions are not daily anymore, but do not feel pressured to chase people out of a meeting just because it says, somewhere, that time is up.
All Scrum meetings (planning, review, daily, retrospective) are meant to organize the work on the deliverable. If, before the planning meeting the team has done a great preparation for the next Sprint (learned about and identified the tasks, asked the necessary questions, received satisfactory answers and everyone knows how to distribute the work in the next iteration), it may happen that planning will take much less than assumed in the Scrum Guide. Remember, self-organization of Agile teams is not intended to “dissolve” the development team. It’s task is to enable this group of people to decide independently what makes their work easier and how they produce the DELIVERABLE most effectively.
Let us go back to the slogan for a moment. It clearly refers to complex deliverables. Scrum, despite its assumed simplicity, is quite a big (and quite expensive) machine, and before you deploy it, you should determine whether it is worth the investment. Not every product needs this kind of workflow, so do not try to fit your project into the Agile framework at all cost, just because everything is so “Agile” now. When you start working on a new deliverable, explore different methodologies and find one that works both for you and the deliverable.
You will find and hear many more slogans promoting Agile. Remember, there are just as many conditions behind each of them, without which these “golden grails” of agility will be much harder to achieve. I hope I have been able to show these selected elements to keep in mind as you begin your journey toward agility. Just remember not to stop at them!
Analyze, test, think, be mindful of the deliverable and make decisions consciously – only then will you reap the real benefits of being Agile. Good luck!
If you found this article interesting, I encourage you to read the first and second part of the series on Agile.
