Simultaneous Ajile (under-jail) and Waterfall projects

There are many ready-made time-tested frameworks for organizing the workflow, in which methods and principles are well described. If we assemble a car, use Kanban, prepare a pie - Lean, develop a custom website - PMBoK. It is important to consider that each project is unique and needs adaptation of approaches, but in general, for your case, most likely there are already enough useful solutions. Building processes for myself, I took a little of everything.

It was


He worked in a startup. One product, one small team, there are no strict time limits. Used Scrum and Kanban in its purest form, so to speak. We wrote down tasks in Trello and dragged them on 4 boards: ideas, we need to do it, at work, it's ready. To discuss the progress of work, they called up every day, and once a week they planned tasks for the next sprint. Everything is like people have.

Has become


Having changed the course of development a little, I went for a new experience in a web studio. There, first of all, he was surprised at the flexibility of working with clients, and, if without sarcasm, the lack of any system.

To show the big picture, I will give a very simplified example.
Customer A: I need to develop a landing page for an event of such and such a date.
Project Manager (MP): okay, we’ll do it by a certain date.
Customer B: urgently make the following changes to the site.
MP: OK, add as soon as possible.

Next, the MP agrees the estimate for customer A, writes the tasks to the tracker, creating separate projects and unconnected boards. Tells the team what to do. Developers begin to cut, and upon completion, the manager shows the result to customers.

Entries in the system look like this:
image

Problems


The approach to maintenance is quite logical, but the following problems arise:

  • Lack of visible connection between customer and team
    tasks. Business tasks are usually found in the table, and decompiled in Jira. When a developer writes another API method, to understand who will use it, you need to go to the manager and clarify again.
  • Incorrect prioritization
    Designer reports premature completion of layout (yes, this also happens). He asks: what to do next? MP sets the task of the fourth project, the first on the list. At the end of the day, he realizes that the fourth task from the first project was more important.
  • There is no visual representation of the scope of work.
    Tasks in different projects. Nobody wants to keep them in the head or search the catalogs. It’s easier, when I finished, to ask: what to do next?
  • Uneven load distribution by time and by employee
    It is clear what Vasya and Petya are doing at the moment, it is more difficult to say who will be busy after 2 weeks and whether their tasks will be equivalent.
  • When planning the completion time, tasks from other projects are not taken into account. We were
    asked to change the link on the site. Oh, it's easy, let's do it today. Then the manager recalls that there are super critical bugs on another site. As a result, the change in the link, according to the customer, the team stretched out for a week.

Perhaps in this example with the edits and the landing page it doesn’t look scary, since all this is easy to keep in mind, but in practice there could be 5 projects at the same time with 40 tasks in each. Many projects came from other managers. Boards, types of tasks, methodologies in them were chosen according to their mood.

Convert Melon


To create a system, it was first necessary to bring the data to a single format. Transforming the mass of entities transferred to my disposal, I managed to come to the following concept:

image

I think everything is clear from the picture, but there are small nuances associated with the implementation in Jira. Let's analyze each entity using examples.

With the concept of a project, everything is unambiguous both in the minds of the community and of Atlassian. This is a sequence of actions aimed at obtaining results in a limited time. For example: to develop a website, to support the application for the whole life time, to create an advertising company.

Epic (release)- isolated large pieces of the project: personal account, basket, product catalog. Here the disagreements are already beginning. Jira has an entity - epic, but still I used release.

The fact is that in order to implement the correct structure, it is necessary to have 3 levels of nesting, Jira at the time of writing of the article has 2 + 1 (history and task are located on the same level). +1 is a sub-task, I don’t take it into account, since it carries the function of complement rather than nesting because of the lack of flexibility and strong binding to the parent.

Instead of release, you could use component or sprint, but for my purposes they looked less successful. For the same reason, epic is used to record stories.

History (epic) in this structure is the task of the business (customer's desire). Task- understandable actions to solve business problems.

Also, some counters and fields were added to entities. The most important of them is a scale for assessing the complexity of a task from 1 to 10 in arbitrary units (story point).

System creation


There is data, then you need to decide in what form and how to display it. I created a common project for the team and wrote a JQL query to pull tasks from all of our projects into it (the query is easy to generate in the issues section). Added Kanban boards and statuses corresponding to our technical process to it: Backlog → To do → Doing → Review → Testing → Matching → Done.

The following picture turned out:

image

Now all the tasks go through a single production cycle, which is quite universal (you can not test the design, but immediately transfer it to agreement). In case of failure of any stage, a comment is added to the task and it is sent back to To Do. Each task has visible links to the project, client history (epic) and epic (release).

Using the same JQL query with the BigGantt plugin (or any other) for Jira, tasks can be viewed in the form of a Gantt chart. Change the lead time, deadlines, register dependencies, see the load on the performers. Collapse tasks in history, history in epics, i.e. visualize a roadmap or detailed work plan.

Administrative part


Of the methodologies, Lean is used (a sequence of actions is determined, while the possibility of parallel execution of tasks remains), Kanban (tasks go from specialist to specialist, a bottleneck is easily identified). From Scrum took daily meetings to maintain an understanding of who is doing what. They also assessed the complexity of new tasks in story points. I wanted, but could not use sprints, because the customer sometimes changed the priority of tasks, and it is no longer possible to regulate the amount of work after the start of the sprint.

After the meeting, tasks are prioritized in a backlog, an executor is assigned, and transferred to To do. The developer creates a branch in BitBucket, the task automatically jumps to Doing. Upon completion, the “developer” transfers to Review, the artist switches to another developer. If everything is ok, the “reviewer” makes a merge and the code is on the test server. Jira sends the task to the tester. After verification, QA transfers it to the manager. That shows the customer. The customer is satisfied - the code is sent to the battle server under the close supervision of daily auto tests.

Thanks for such automation, thanks to our devops engineers. I just configured the change of statuses and executors for events from git. This is done in the settings of business processes, if you work within the Atlasian ecosystem. And when using GitLab, Bitrix, Redmine will have to tinker.

Solutions


Let's see what we managed to achieve:

  • The lack of a visible connection between the customer’s tasks and the team.
    Business tasks are recorded in Jira as stories (epic), they can be viewed with a percentage of completion and a Gantt chart. The developer, performing the task, sees to which story it belongs, can go and read the description.
  • Incorrect prioritization The
    designer, having completed the task earlier, takes a new one from the top of the To do list, where they are prioritized by the ratio of story point to cost (business tasks in rubles).
  • There is no visual representation of the scope of work.
    Tasks in one project. Each member of the team sees how they move along the Kanban board, the general course of work. What has been done and what remains to be done.
  • Uneven load distribution by time and by employee
    Gantt charts allow you to plan work on a long horizon (with constant updating). There is a projection on the performers. It can be seen when the executor has 2 tasks at one time, while someone does not have them.
  • When planning the completion time, tasks from other projects are not taken into account.
    Adding a new task to any project, it can be seen in the general backlog. Priority with respect to other tasks is set for her in a single metric.

Plans


Some processes were reduced or automated, but much more remained in the plans:

Generation of estimates for projects time & material


Performing each task, the employee notes the time in it. Knowing the rates per hour of each person, his position, correction factor (by how much to multiply to account for the costs of the company), you can generate a table with a list of jobs and costs.

Automatic settlements between managers


If I have tasks, but there are not enough resources to complete it, I ask another manager for the contractor. When the time comes for reports, I bring as expenses the spent money-hours of the employee into my plan and as income into the plan of another manager.

Every month I had to raise all the work, check with the managers, multiply and subtract without any creative. If all the employees switched to a single data format (the way of conducting projects in Jira), all calculations would be possible to carry out without human intervention.

All Articles