Simple clients' guide to Agile development methodology
As a product owner or if you decided to become one, you probably read about Agile software development methodology. If you still hesitate about the viability of its usage or don't understand all terms then this article is for you. In our article, we'll clear up the concept of Agile, what roles are here, the risks, which exist in creating a product and how communication affects on the product.
Let's form the Agile methodology principles
Before 2001 IT teams all over the world mostly used Waterfall model for the software development, where each stage goes one after another, as a sequence. From requirements analysis, design, construction, testing, production to maintenance. But it all changed with the publishing of Agile Manifesto on the February, 18.
The fundamental difference between these approaches lies in priorities the methodologies are built on. Unlike Waterfall Agile values and principles are about:
- Flexibility - everything can be changed anytime.
- Focus on people and collaboration, not on instruments.
- The methodology doesn't require much documentation, so there is no need to spend hours on materials which you might not need if you decided to replace something.
- Communication between the key players is vital.
Everything about our own approach to successful project delivery and how to control it is here
These doctrines made Agile one of the most appreciated path for mobile and web development as it stands for efficient and deft development process under informal and relaxed working conditions.
Everything about our own approach to successful project delivery and how to control it is here
Agile team roles, basic definitions and frameworks
To understand how it works we need to deal with the main terminology in Agile. As we know - Agile is almost a game and everyone here has a role, lower we define the most important
Roles in Agile
Depending on the Agile framework and tool, which you chose for your team, you can find lots of different roles like Architecture Owner or Team Lead or Domain Expert. However, lower we will consider basic roles, which are crucial for the development with Agile:
The role of Product Owner in Agile is crucial, as he/she is not only the initiator of development but also a person with a clear idea of the future product. PO supervises the whole process and discusses every detail with his team.
Future users, people who are interested in the product, they will support it or will be involved in development process.
People, who will build the product. It is usually a team of five-seven highly motivated specialists, that can build a working prototype without external help.
As well as with the roles, there are tonnes of terms in the methodology. Nevertheless, we need to discuss a few of them to grasp the idea of Agile.
Explanation of what this feature should do. According to the Agile principles, they can be changed, added or deleted anytime.
To clarify the idea of the Agile development process we should also mention what the Capacity is. In Waterfall model, all user stories are collected and then processed at once, in our case development team processes and releases them as often as possible. The number of the stories one team can handle a week calls the capacity. It's an average number based on past experience of one team, not on the will of stakeholders or Product Owner.
To tell you the truth, we can spend hours talking about frameworks and practices in Agile. You might have heard of XP, SaFE, LeSS and Dad, but if you new in Agile, I would advise you to read about two the most common and easiest to apply practices:
One of the Agile branches. Scrum teaches us to work with small self-reliant groups instead of large teams, the tasks should also be small and clear, so a group can fulfil it easily and fast. Such tasks form Sprint with fixed length (usually about 2 weeks). After each Sprint PO gets a working prototype with features from a particular sprint. Scrum Master - the main character in Scrum, is an intermediary between the Product Owner and the team. Scrum Master has lots of duties, he has to organise the team(s), he watches what they did and what is necessary to do, explains the wishes of PO and vice versa interprets to the owner what issues the developers have.
Kanban works with cards or stickers for visualisation. Columns help you to see what stage is the task on. The simplest table would have columns To do, In progress and Done. Moving the card you see what time it takes to complete one or another assignment. In future, this data will help you to improve the time and to make predictions about the project duration
Kanban - Agile framework
Agile includes not only Scrum and Kanban, but these two ways are the most popular and effective ones. There is no right or wrong formula. You can choose any Agile development approach or principle you like and you think is best for your team, or to mix them.
Do I need any agile development tools?
Of course, you can take post-it notes and stick them to the wall, but the problem is that the wall is one and your developers have to come to you and watch what is their task for today, and how will they assign or inform other team members? Online web apps solve the problem. There are so many agile software tools, each has advantages and disadvantages, so there is only one way to choose. To try each, or at least, to make a small research on them. Here are some of the most popular Agile management tools:
Jira - Agile instrument
This piece of software allows you to administrate, control or just to view the progress of development (depends on your access level). It has few boards like Backlog, Team Scrum Board, Issues, Reports and Kanban, so you can do almost everything in one place. The other advantage is that you can easily create your own boards, add or delete tabs you don't need.
Redmine - Agile instrument
Is a web app which you can use not only for the project management but also to track bugs, manage few projects at the same time, add new users, count hourage, create forums where all involved can discuss the details of the task.
Trello - Agile instrument
Here you can see pure Kanban approach. Cards you stick to the doer and move from column to column. This is the most visual program, you see what your tasks are, their priority and other involved team members.
EasyBacklog - Agile instrument
The interface is really intuitive so you do not need to read a long description to start your work. Scrum master or Product Owner can easily create user stories and order them in the backlog, however here it's impossible to assign a task to a person here, which is a real pity.
Probably you will test a few software tools and get some bumps before you find a perfect one for your developers. As always - what works for one team can kill the work of others. To tell the truth, there are much more options, modern variety of Agile management tools allows you to keep your hands in.
To puzzle out Agile risk management
Just like in every production risks are essential components of any development process. In terms of our project we can talk about Technical risk - can we develop this feature in time with the people we have. Business risk - are we creating right thing. Social risk - do people actually need this. Deadline and cost risk - do we have enough money and time. As well as this, the owner should reconcile between long term and short term thinking to see what must be done now and then.
Way of thinking in Agile
It's like going through a minefield, you need to balance between making a product correctly, making a correct product and making it fast. If you managed to combine all three - it's excellent, however, usually we can bridge only two of them. Excluding the speed trying to build the right thing correctly, you risk to break the deadlines and run out of the budget. An attempt to do right product fast will leads you to multiple technical crashes. And if you lose the seeing of what users really need, you might build a perfect app which no one wants to use. As a rule, PO wants the product to be advantageous and useful, developers vote for quality and stakeholders for speed. As we know controversy served the cause of truth, all decisions should be well-considered and made by all.
How to develop with Agile
The other frequent issue here is too many eggs in one basket. It occurs when there are much more user stories then the team can cope with in a week. We can prevent it by not trying to do everything at once, but to manage the usual amount. In such a case we arrange our tasks in order according to which our team will process tasks, this list is called Backlog. Backlog needs to be controlled otherwise it becomes too long. As a product owner, you need to refuse some ideas and to choose top-priority ones. To make task easier PO needs to discuss it with the team and stakeholders. Especially size and value of feature should be taken into account. Unfortunately, these metrics are relative and there is no way to calculate them precisely, so the only way out is guessing, of course, developers' experience might help, however usually it's just a shot in the dark.
More about how to apply Agile Methodology For Mobile Development you can read here
Keeping Backlog neat is hard and it needs to be checked from time to time. So the owner has not only prioritise tasks in the Backlog but also to organise them and expel needless assignments. He needs to balance between the complexity of development and user story value.
As you see - communication is crucial. The Product Owner is obliged to discuss what user story he wants to be developed next, which he doesn't want to create any more, how much time will take the development of this button and that layout. Meetings in agile methodology allow you to avoid the potential traps and difficulties on the way.
Agile communication and delivery plan
Well-build conversation is a passport to success. All top negotiators can tell you that the key is the truth, you should never lie to your team and to investors it is a fundamental law. Nevertheless, stakeholders ask us hard questions, our task is to provide them with full and complete reply using all data at hand. To make it visual you can draw the chart with optimistic and pessimistic trends, showing time and number of user stories your team processes.
Graphic with optimistic and pessimistic trends
If the question is "When will feature 4 be developed?", then your answer should contain not a date but a period, like in June or October.
Question with fixed scope
If the question is "What will be done by the end of June?", then the answer should include optimistic and pessimistic calculation, like first two features will be done and possibly third too.
Question with fixed timeframe
These data isn't just guessing or PO's desire, the owner predicts the outcome based on past experience and real information. And the most important - he doesn't lie. To keep the chart fresh PO has to update it every week.
From time to time we have the situation when our stakeholders want to have something done by a fixed date. In such a case it is better to cut the size of the project (functionality) instead of increasing the time. We can at first release particular set of functionality when it is needed, and then add new logic.
As a company we sometimes meet Product owners who don't want to participate in the process of web and mobile development, they behave like customers after they ordered pasta, as a result, they get the same dish as others in a restaurant. Of course, it's not a problem to create a typical application or a site, however, if you decided to make a unique, fresh and eye catching product you must interact, actually be a part of a development team.
You can read more about our own experience of communication with customers in our article
Our task today wasn't to persuade you that Agile is the best methodology ever and the only right solution for you as a Product Owner. There are many various practices and you are willing to choose one which fits you more, moreover, you can use none or you can create your own and apply it. Yet, we wanted to focus on the most unclear terms and roles in Agile and to suggest you the simplest solutions in real life situations if you defined Agile methodology as your path. If you still find it difficult to apply Agile in your project, contact us and we'll share all our vast experience with you!