Is there life for an IT specialist in a development company? Diaries of a Systems Analyst, Part 1
How do IT specialists live in service departments of large companies whose main profile is not directly related to IT? In this article, the first in a series, I will talk about how the work of IT specialists at Sminex is structured. Our company specializes in the construction of expensive real estate in the center of Moscow – it is creating a collection of houses around the Kremlin in the historical districts of the city. The company builds and designs more than 460 thousand square meters. m of luxury real estate.
Hello! Alexander, leading systems analyst at Sminex, is in touch. IT for our company is not the main area of activity. However, we are still cool, we work with a large technology stack and solve important problems. Today I will tell you how we apply the Agile approach in our daily work, what we do well, and what we plan to develop further. I hope it will be interesting and the information will be useful.
At the company, I am part of a group dedicated to the digitalization of processes in construction. My main area of responsibility is the development of the Plan.SX product. I am developing a tool for managing schedules and plans for the implementation of development projects.
How we came to Agile
One day we realized that the times we live in are characterized by constant change, and businesses need to be flexible in order to adapt effectively. Therefore, we decided to switch to flexible methodologies for developing IT solutions, which allow us to quickly adjust the software creation process. Despite the challenges that emerged during the transition that began a couple of years ago, we were able to create a successfully functioning system.
How teams are structured
Our teams have implemented a role model that ensures effective product management:
Lead Product Owner / Team Leader: This person acts as a team leader and is responsible for the overall coordination of work, communication with all stakeholders and resolution of controversial issues;
Product Owner/System Analyst: This specialist manages his product, interacts with customers, identifies their needs and collects requirements. The Product Owner also actively influences the development of the product, for example, helping customers formulate their “wants” for the harmonious development of the product and meeting business needs;
Developers: The team is divided into two areas – 1C and web development. Although we have a formal distribution into groups, it may change if necessary, such as high workload or a change in the technology stack. Developers lead the tasks set by analysts as part of product development. In large teams, the role of Team Lead, who coordinates developers, is also highlighted;
QA Engineer: These specialists are responsible for checking the quality of development, working through various scenarios for using software improvements, writing bug reports, and preparing cases for automated testing.
How we manage tasks
To manage tasks we use:
Tasks and errors form a backlog. Jira acts as an issue tracking system – each team has its own space. We have learned in practice that analysis tasks are difficult to manage within sprints because their effort is often difficult to estimate. Therefore, each analyst uses a Kanban board and moves tasks into the appropriate columns – from “Backlog” to “Ready for development”.
As soon as the analyst prepares the tasks, he draws up a draft sprint, agrees on it with the customer and sends it for evaluation. Two days before the start of the sprint, the draft should be ready to be handed over to the development team. Developers with a team lead assess the tasks and the overall effort of the sprint during the planning session.
For sprints, we took the gold standard – two weeks, which also optimally fit our release cycle. And, by the way, we have a release manager who swears (and how!) when they try to add unscheduled tasks to the update.
To complete the picture, we transferred requests from users from the old Manage Engine Service Desck Plus to Jira Service Management. The result is a very convenient link: if development is necessary, the ticket is tied to the task. This is how we managed to get selections based on the status of the application’s life path. We also set up a cool dashboard that shows the dynamics of receipt and resolution of tickets by product.
Like:
transparent process;
each task has its own life cycle;
convenient tracking, you can always track your progress.
Growth points:
there may always be a “priority” task that can be thrown into a running sprint;
tasks poorly developed at the analysis stage affect the dynamics of sprint combustion.
What about Scrum events?
At Sminex we practice Daily Scrum, Planning Poker and Retro.
Daily Scrum. We hold daily events regularly. Their format may vary depending on the size of the team. Previously, daily events were daily for everyone. Now we have divided them:
Daily for developers: in the morning we get together and share what we managed to do, what problems there were and what we are going to do today. For simplicity, we made it a habit to worklog expenses, this makes it easier to remember the results of the past day;
Every other day for analysts: everything is the same – we share pains, victories and plans.
A little history about our Daily Scrum. When we first started, creating a separate space in Confluence seemed like a good idea. In it, each team member filled out all the information before conducting the daily meeting. Six months later, we came to the conclusion that too much time was spent filling out the daily report, even though it solved the issue of reporting on the team’s work.
At the same time, the implementation of working time tracking for developers began, and since in worklogs the developer actually records what he did yesterday, we decided to set up a convenient desktop for conducting daily work sessions. This allowed us to avoid filling out unnecessary forms and work with Jira data.
Thanks to the tracking of working hours by developers, we were able to create a space for holding a daily meeting using the Daily Scrum methodology using the Worklogs plugin.
On the daily, team members talk about:
Your achievements over the past day, using Worklogs as a detailed reference about the work done;
Plans for the current day, looking through the task board and making sure the statuses are up to date.
The team management received an excellent tool that, as part of a daily event, allows you to inspect the amount of time spent by each developer, evaluate the quality of filling out the Worklog (no more “WORKED for 6 hours, honestly”) and make sure that the statuses of tasks in the sprint are up to date.
Like:
helps improve self-discipline;
less chance of missing something important;
after some time you realize that planning your workload for the day is great;
we share pain points, and colleagues can give valuable advice.
Growth points:
There are periods when daily meetings turn into a routine, the motivation to hear and be heard by each other drops, and it may seem like we are talking into nothingness.
Planning Poker. Before the start of the sprint, the development team evaluates its capacity and sets story points in hours. By the way, right now, while I’m writing this article, my colleagues have gone to plan the 6th sprint.
It was also not easy to arrive at an established planning process. We started by assessing tasks directly on the list.
In this version, the exchange of opinions was difficult, due to the fact that there was no possibility of “hidden rating”; everyone gave them, focusing on the first speaker. Then we tried the online service, but due to the fact that it was impossible to “drive” tasks from Jira into it, setting up the game and saving its results was very difficult and inconvenient.
Ultimately, we came up with the Planning Poker for Jira plugin, which allowed us to standardize the event and simplify the saving of evaluation results. It is worth noting that, in addition to instrumental problems, at the very start we made a typical mistake – we played poker without first familiarizing ourselves with the tasks. As a result, the guys did not have time to understand them, and the accuracy of the assessment was low.
Initially, not all of the team's developers saw the practical application of poker and treated it as a waste of time. However, practice has shown that this event increased the accuracy of assessments and, as a result, the predictability of the team’s work.
Retro. Once every three sprints, we organize a retro, discuss the results of past sprints, reflect, and prepare for new achievements. We try to make retro fun. For example, last time we read horoscopes, solved crossword puzzles and ate pizza.
We are experimenting with the retrospective format: face-to-face or online meetings using Confluence, Miro or a plugin in Jira.
The plugin option proved to be the most consistent. In addition, it allows you to track history. We definitely give the priority to the most fun format to face-to-face meetings – horoscopes and pizza, yes!
Customer in Scrum
Not all customers – we have internal ones, from the business – know how to use Scrum. And my customers are no exception. Although not immediately, they merged into the basic processes and terminology. We regularly demonstrate the functionality being developed at demo sessions, and also plan sprints. Colleagues understood our approach to development and the release cycle. It's interesting to note that the usual question, “When will it be ready?” began to sound like “Which sprint will we plan this for?”
A little about metrics
Thanks to a consistent approach to work, we were able to track team and role metrics. Teams now have tools to track how their actions impact performance.
Conclusion
To create beautiful houses in which to live comfortably, the work of every employee of a development company is important. At Sminex, great attention is paid to the development of IT systems, since they also allow us to follow our philosophy – to build exactly what is promised. So we can create the houses are the same as in the renderings. Within IT, we plan to further develop Agile practices. For example, we want to introduce scoring, choose the Scrum scaling framework and improve the product approach.
And, of course, we are looking forward to new people on our teams. Current vacancies – Here )
