Development Management *

Dealing with priorities is a constant necessity in product management and development processes. In order to improve professional skills, product managers should find time to explore and try using simple and complex methods and frameworks to determine priorities.

The Lean Prioritization approach is one of the simplest and most accessible methods that help product managers with managing task backlog, especially when it needs to be done quickly and efficiently. This post is about the power of Lean Prioritization.

What is prioritization about? Product managers will agree that it’s rather critical to choose the right features for development, filter the most important of them and skip less urgent ones. This is all about the art of prioritization.

If you are not sure about your prioritization skills and want to get more, this quick guide will assist to discover how to find the evaluation criteria for your product and how to select appropriate strategic growth metrics. You will also find out how to offer more value to customers and establish all internal processes inside your team with the help of prioritization methods.

Every «hype» thing or event has a certain regularity: the more people talk about it, the less they really know about it. Scrum is not an exception. You may find hundreds of relevant articles and IT news, where it may seem that there is only one best Agile methodology and this is Scrum. A large Agile family contains various powerful methodologies and Scrum is not the sole system of implementing Agile principles. However, this methodology is still actively used all over the world.

People go mad about Scrum: many IT blogs write about it, many practical courses promise to teach all Scrum features, many companies want to see a working experience with Scrum in CVs, and so on. Scrum conquers them all. In this post, we define why.

Is it always easy for you to prioritize the tasks of the huge project? What if five or more tasks have the main priority and urgency?

Experienced project managers and product owners know that intuition is not enough in such cases. In order to avoid missing deadlines, today, managers are able to apply useful methodologies for determining priorities, as well as modern tools that help to visualize data and not miss anything in their workflows.

Given: A company which uses the Scaled Agile Framework (SAFe) to scale Agile development across the organization; 10 development teams combined into one big team (Agile Release Train, according to SAFe terminology) to deliver a common product; the need for a two-day quarterly planning (PI Planning) to determine the work plan of IT teams for the next 3 months *; three development offices with the distance between the most remote ones exceeding 6 thousand kilometers and corresponding working time difference of 5 hours; previous planning experience which implied usage of analogue boards / whiteboards / highlighters / sticky notes and respective physical presence of all key employees in the same room.

* This heavyweight construct “The work plan of IT teams for the next 3 months” threatens to increase the size of the text significantly, so hereinafter I’m going to replace it with “the commitment”. Accordingly, to draw up and adopt a work plan will be “to commit”.

Why do we need this?

1) Fatigue with analog methods of work. While spaceships are plowing the Space, and Elon Musk is boring his tunnels, we, the IT guys, have been persistently writing with highlighters on sticky notes sticking them on the boards — there is really some kind of dissonance in this, isn’t there? That’s what our commitment looked like a while ago:

Disclaimer: This is a translation of an article. All rights belongs to author of original article and Miro company.

I'm a QA Engineer in Miro. Let me tell about our experiment of transferring partially testing tasks to developers and of transforming Test Engineer role into QA (Quality assurance).

First briefly about our development process. We have daily releases for client side and 3 to 5 weekly releases of server side. Team have 60+ people spitted onto 10 Functional Scrum Teams.

I'm working in Integration team. Our tasks are:

• Integration of our service into external products
• Integration of external products into our service
  For example we have integrated Jira. Jira Cards — visual representation of tasks so it's useful to work with tasks not opening Jira at all.
  
  

How the experiment starts

All starts with trivial issue. When someone of Test Engineers had sick leave then team performance was degraded significantly. Team was continued working on tasks. However when code was reached testing phase task was hold on. As a result new functionality didn't reach production in time.

Going onto vacation by Test Engineer is a more complex story. He/she needs to find another Test Engineer who ready to take extra tasks and conduct knowledge sharing. Going onto vacation by two Test Engineers at the sane time is not an applicable luxury.

What do you get when you cross an IT department, a faulty Sprint review, determination, and pizza? Greatness, that's what.

Occasionally, we're asked a question, what monetary value the company will receive from using PVS-Studio. We decided to draw up a response in the form of an article and provide tables, which will show how the analyzer can be useful. We cannot prove absolute accuracy of all calculations in the article, but we suppose the reader will agree with our thoughts, and it will help to make a decision in the matter of getting the license.

Russian version

Let's imagine that you are developing software and hardware appliance. The appliance consists of custom OS distributive, upscale servers, a lot of business logic, as a result, it has to use real hardware. If you release broken appliance, your users will not be happy. How to do stable releases?

I'd like to share my story how we dealt with it.

Иногда молодые команды разработки охватывает неразбериха.

Это случается в тот момент, когда они ещё не до конца разобрались, что такое эджайл; проджект и продакт спорят, кто из них кто, а задачи каждый ведёт сам по себе. Или все уже всё знают, но планировать спринты не получается — задачи не прорабатываются, демо и ретро проходят нерегулярно.

У нас тоже была похожая история, но мы нашли свой путь.

Это рассказ от команды личного кабинета Яндекс.Кассы, и подробнейшая инструкция для тех, кто хочет улучшить своё планирование.

Как всё было