Simple clients' guide to Agile development methodology

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.   

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

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

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:

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.

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:

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.

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:

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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!