Geekly Articles each Day
📜 ⬆️ ⬇️

How we met with Agile & Scrum

Introduction


I don’t want to say that this is a guide on how to introduce Scrum - this is only the experience of introducing and adapting Scrum to the needs of one company. This experience can be interesting / useful as a beginner: the main tips, stages, cycles, etc., and professionals: to discuss what went wrong, what was not worth doing, etc. I emphasize that what we have left is just something resembling Scrum.



Background, how it all began, how did you come to the conclusion that you need Scrum


I work as an IT manager (project manager) in one small / medium Tomsk company. The number of employees in the IT department at the beginning of activities: 5 people, at the moment: 24 people.

At the initial stage, I was a game designer, but gradually the project of managers migrated to the camp. Approximately, it happened in the summer of 2014, and we will consider this time as the starting point.
')
Like most novice managers, I rushed to study materials: search the Internet, watch conference recordings, read books, communicate with older brothers from other companies, and acquired a lot of knowledge, as I thought at that time (this was naturally a mistake). And I, ambitious and inspired by new goals and objectives, rushed into battle.

I consider the main problem of a novice manager: the absence or incorrect communication with employees. There can be many reasons for this problem: lack of experience, distrust on the part of workers, lack of knowledge of basic technical / business processes, etc. But I was lucky in this matter. Initially, I worked closely with developers, being a game designer, and before that I worked a little as a programmer with no management at all, so I had a certain vision of what was missing.

How it was before Scrum


Initially, we had an old Redmine deployed without any plug-ins and settings, we can consider it almost pure, TeamCity (free) to provide at least some building, SVN, wherever without a repository. In general, everything worked.

Tasks were set in redmine, as time went on, hours and sometimes percentages of accomplishment were made, but often there were no deadlines or any plans, it was very lucky if there was at least an agreed dead-line.

And then it is my time. The management gave me the go-ahead to use everything your heart desires (it will bring more profit). As I wrote above - this is the summer of 2014.

At that time, we were still poorly familiar with Agile, a university course and a couple of articles. Therefore, we have not yet had any thoughts about some kind of flexibility, and we began to act in the old manner (perhaps thoughts arose, but lack of experience and something else did not allow them to get further). Initially, we fixed our main tasks on the boards that we hang in almost every office. It looked like this:



Naturally, everything was transferred to the electronic form: for some tasks it was recorded in redmine as a feature or epic, for some in the good old Excel, they also set the importance and approximate timing of the tasks. Then we started decomposing and evaluating tasks with each employee who will complete the tasks. The result was a feature set with sub-tasks and an estimate of the timing of tasks. It turned out a kind of backlog, but then you need to somehow work with it, by itself it does not produce results.

Gantt Charts


Some time before that, I came across Gantt Charts (strip charts) in a company where I worked as a programmer. I made a couple of diagrams for our projects, the sketches showed the management, and they liked this technique. And I began to study the tools that would allow me to make these diagrams in the best possible way.

I have been tested:

  • Many desktop programs , for example: gant-planning and much more, which can be easily found on the Internet, some of them were of disgusting quality, some of them are paid. The only one that I can mention is the Gant Project. It is quite convenient, allows you to easily and quickly build the desired charts. Cons: due to the fact that I had a free version, I didn’t allow me to upload in the right format and the lack of team work on one project.

  • 1C Bitrix CRM . At that time, we actively implemented this program in the enterprise. She allowed to build diagrams with some limited functionality. Disadvantages: interface congestion, the inability to change colors on the diagram (I really didn’t like it), again, at that time there was no possibility of uploading in the right format (now it seems to be there). A big plus is the possibility of teamwork, but we didn’t particularly like the work in this program.

  • Redmine. Everything is simple here - you set tasks with deadlines, and the diagrams themselves appear. Cons: if you build hypothetical plans with the involvement of many developers and you want to see from the plans that yes how, then the developers see everything and they all begin to litter the workspace and again, there is no way to make beautiful colors.

  • MS Project . I missed him at that time for some reason, later I actively used it and I liked everything, except for the difficulty of setting up team work.

  • Megaplan . Old company CRM system. Immediately dismissed, it was not all convenient.

  • MS Excel . Good old, for some plans still sometimes use.

Here are the plans:



As a result , having stumbled with some programs and changing them from time to time, we conducted projects for several months with active use of Gantt charts. The management liked it all, they saw clear and approved plans, and, it seemed, everything was fine with everything, except for a small BUT (big one).

This is BUT , the Guide and not only: marketers, sales, etc. constantly pushing any development into the plan at the most inappropriate moments. This led to the fact that it was necessary to completely rebuild the plan and shift the tasks of the developers, with inventing new tasks for idle time, if such a thing appeared. When there were few people in the team, there were no particular problems, nothing much terrible to move a couple of people, but when more than two people depended on the completion of one task, and sometimes the pushing through led to the task disappearing altogether, it became problematic to rearrange the plans.

This is where the need arose for something else.

What needs were


Having collected feedback from the management and the main actors of the company, a certain list of what one wanted to see was formed:

  1. Transparency design. Each department (in particular, managers) had to see what was in development at the moment and when the next result would be.
  2. Making changes to the development at any time. The director wanted to influence the development flow quickly.
  3. Reporting results. Management wanted to see reporting activities.
  4. Task pool with execution time and priority

We also collected feedback from the developers:

  1. A more detailed assessment of the duration of the tasks
  2. Minimizing the effects of interference with the development of outside.
  3. Increase developer awareness of incoming tasks well in advance.
  4. Providing a complete picture of the projects performed.

What is considered yet


  • Introduction of a hard regulated “waterfall”, so that processes cannot be interrupted. But all such an opportunity to interrupt overwhelmed the leadership.
  • Kanban, but somehow it didn’t go further, I can’t give exact reasons.
  • Option: "Well, with God," but he already got everyone!

Why Scrum meets the needs


  1. Flexibility. At almost any time, you can revise the priorities and introduce new features.
  2. Transparency. Sprint-list is on everyone at the post office (at the main characters), and initially I hung it up in each office. You can also go to the office with Scrum-desk and see who is doing what at the moment.
  3. Reporting. Demonstrations at the end of sprint'a, quite a good procedure, which makes it clear (to some extent) what happened as a result.
  4. Detailed picture of the project (depending on the degree of backlog decomposition). Constantly updated gives a certain vision of the project, both to programmers and managers.
  5. Developer safety Developers are safe from outside interference, at least during the sprint.
  6. More detailed design / planning. The task is not taken in the sprint until it is completely understood by the developers, or a mini sprint is arranged - analytics / design.
  7. Continuous, cyclical process improvement. Nobody canceled the feedback after the demonstration. Daily meetings (meetings) also give a positive increase in process improvement. And a retrospective: improve everything that was bad!

As reported to all


The main concepts were understood by the developers from the articles, so there was practically no problem with them, they were accepted with enthusiasm. The main problem was the leadership, but since it practically does not participate in the processes, we also have cards in our hands.

How did you study? What did you watch? What resources? What books?


Communication with professionals


We communicated with managers from other firms, learned what and how from them. We looked at what deviations from the norm they did, looked at how and what can be applied here. To be honest: they didn’t learn much. The main conclusion: everyone acts as they please (which Agile is convenient for them).

Reading articles


We have reviewed a bunch of articles, which exactly appeared, no one can remember. But there were many. There was plenty of time for this. Naturally, everything depends on the Agile Manifesto, most articles and sites link to it, so that we were no exception, and took it as the source. (link is in the sources and links)

Reading of books


Books has not been revised much. Some of those who had glimpsed glances, but found nothing different and stopped reading. The main one (for myself), I think, “Agile and XP notes from the front line” I read it three times, and always, if they ask me the question: “How do I know about Scrum?” - I call it. (link is in the sources and links)

Begin implementation


The document with the main events


We painted the main events and formed a small list with a description of the actions, distributed them to all employees for review. At that time, he was naturally far from perfect. (link is in the sources and links)

Cards


Naturally you had to get some cards for Poker-planning. revised on the Internet a number of stores, the cost of the deck for four people ranged from 1000 rubles to 2000 rubles. I didn’t want to ask for any money from the management, and therefore I made it myself. Plain A4 paper, black and white printer, scissors - that's what happened:



Many times he tried to remake them, a color printer, cardboard and many other things, but these good old maps (not in full composition) still serve.

Interesting fact. I hope I did not confuse. One of the few at that time store for the sale of decks of cards, which I liked - planningpoker.ru. I thought then, what are the cool cards. Later, a few years later at the conference, the director of the company that organized this store gave me one of these decks quite by accident. (link is in the sources and links)

Board


The next important stage is the preparation of Scrum-desk, took the usual paperman, a pair of A3 and A4, markers, scotch, etc. And it turned out pretty good:



What happened as a result of the preparation


  • A team that got acquainted with the main stages;
  • Prepared by Redmine, compiled a list of tasks;
  • Prepared by poker planning;
  • Prepared by Scrum-desk;
  • And a bunch of enthusiasm.

The first experience, the first sprint


Backlog


We built the first backlog in MS Excel, broke everything into columns:



Naturally, there is a number of columns that are not included in the drawing, but this is another story. I emphasize that it’s exactly the tasks (feature) that we got, not the user desires (user-story), as is customary in Agile. The first sprint was decided to make two weeks. Set priorities, sorted, marked green, that I would like to take on the sprint, set the story-points. Hmm, what is a story-point ?!

How brought to the attention of developers. Story-point - day


On the rating system in story-points are ideal days, it is quite difficult and incomprehensible for developers to switch. As we explained, a story-point is a perfect eight-hour developer’s working day, when he has everything at hand, nothing distracts him from work (problems are already visible, everything is there and doesn’t interfere with hmm ...), he is isolated from others a room where there is fresh air, food, tea / coffee, toilet and it productively performs the task, the solution of which is completely clear to him. Some things have been added while explaining to beginners, but they don’t really matter.

Distribution of roles


In our company, there are practically no cross-developers? There are individual testers and we develop for various platforms. Accordingly, we weakly fall on one of the concepts of Scrum, as the unification of workers. We neglected it and in the first sprint we had different developers in the same team.

Planning


All the features from the backlog that were supposed to go to sprint were printed, and we started the assessment.

What actions on planning sprint'a we have taken:


  1. Stick all the leaves on the board.
  2. We declare a goal to which we need to come up with sprint, unfortunately (maybe fortunately) we had several goals, there was no single goal, because the developers from different projects participated in the planning.
  3. The lead developer tells everyone about each feature individually.
  4. If questions arise, they are immediately resolved.
  5. We begin to decompose each feature into subtasks and, again, explain why this is the case and not in a different way.
  6. If all tasks are decomposed and understood, we start the assessment with the help of Poker-planning.
  7. One sub-task is called, and it is explained once again if it is not clear to someone.
  8. All developers who are competent to perform this task (often, almost all), lay their cards face down on the table with a figure that is equal to the story-points to perform this task.
  9. After everyone has laid out the cards, turn over the cards.
  10. If there are strong discrepancies, then the developer, who laid out the assessment diverging from the rest, explains to the others why this assessment arose. If he did not understand something, then everything is explained to him again. Next, revaluation.
  11. If there are no strong discrepancies, then the estimated sub-task is assigned the value that the developers assigned to it.
  12. Thus, all sub-tasks are evaluated, the feature rating is added from the sub-tasks.
  13. If the ratings of features differ greatly from the preliminary assessment, you need to take action later.
  14. We type features on sprint. For the first sprint, we found that our developers can perform approximately seven story-points in a two-week sprint. Accordingly, if there are five of them, then you can take tasks for 35 story-points. We took more - 39, as it later turned out it was a mistake.
  15. We hang out taken features on Scrum-desk.
  16. We assign the time of daily meetings (meetings), the date and time of the demonstration.
  17. Getting started.

The first scheduling was successful, took about 4 hours with the participation of 5-6 people. Naturally (as it turned out for us), far from everything that was originally planned was taken in sprint. The director was present at the planning part of the time, and he and the team really enjoyed the event, and the team eagerly set about performing the features.

Compiled Scrum-list (in MS Word):

(link is in the sources and links)

  • Mandatory name sprint'a and team.
  • The designated goal, the main task of the team, to fulfill the goal.
  • Backlog sprint - features that must be performed to achieve the goal. In brackets score in story-points. The same tasks hang on Scrum-desk.
  • The indicated terms of the sprint, as well as the time and place of the daily meetings (meetings) and demonstrations.
  • Enumeration of team members, in brackets the percentage of employment in this sprint, if there is nothing, then it means 100%.

Initially, I printed this sheet and hung it in each room, and also mailed it to the main actors. But later it turned out that this is just a waste of paper and no one really needs it, one sheet was enough (later more, when it became more offices) in the developers office.

Why do I need a sheet?
In order for other teams and people involved in the project to present what tasks this or that team is currently performing. And also to see what result will be after a certain period of time.

Daily planning meetings


At the first planning meeting, everyone appeared, as if by hours, which is not encouraging (everything was not so rosy in the future). We got together, started discussing one by one, like what was going on, no one had any questions and problems. Moved to Scrum-desk.

Paper Task Board


We started to move the stickers and had already encountered a problem, as the stickers were glued to the paper on the tape, tearing them off and re-sticking was some problem. They coped with this in grief in half (later they acquired a knack and this was not a problem). Began to put down the burned story-points, and then there was a question: not one of the developers had no problems and questions, and the story-points burned is not enough. The reason, as usual, is trivial: someone just took some time to build up and he just didn’t do his job all the time, someone did preparatory work that was not laid in the sprint and in the same vein. As a result, we got something similar:



Initially, the stickers were simply molded onto the board, but over time they began to fasten them additionally on the tape, there were a couple of precedents when everything flew off. Later a couple more columns appeared: in testing, code review, etc.

Why do I need a burn-down?


Burn-down is needed in order to be able to track the progress of the sprint’s performance by the team, as well as to visually see deviations from the executed plan over time. The main goal of burn-down is to show the team (as we have self-organizing teams) that we need to take prompt action if a deviation has occurred.

How to build a burn-down?


Many tools allow you to build burn-down diagrams in electronic form, we used MS Excel, and also built on Whatman paper.

Initially (later additional columns appeared) our table contained:

  • The first column is the dates from the first working day to the last working day of the sprint.
  • The second column - How much is left to burn the story-points. Every day during the meeting the value appears.
  • The third column is the standard of ideal story-points burning by the team during the sprint. Ideally burned per day = Number of story-points taken per sprint / number of days.

Unfortunately, the paper was not preserved, recently there was a global cleaning, all the trash was thrown away.
In electronic form did with MS Excel:



As you can see from the diagram, the first sprint was almost successful, small deviations from the perfect performance. BUT , as the rule says: If at the end of the sprint there are not burned story-points, then the sprint is failed. On this rule, at that time, we closed our eyes and rejoiced at the successful completion of the sprint!

Demonstration


It's time to show the leadership of the results of sprint'a. The “team” (manager) prepared its presentation, and then each team member would do his part. Initially there was no standard presentation. Many viewers gathered: management, part of the sales and marketing department.

The presentation was done in MS Powerpoint:



In the first presentation there were only four slides, for this reason it was hard for the developers to demonstrate, since there were no slides to talk about, but later we corrected.

Where and how was the demonstration held?


As we, at that time, did not have a conference-room, the presentation took place in the developers' office, got a projector and shone on the wall.
Initially, the manager (I) spoke, why everyone gathered here, told the main goals and tasks of the sprint, and the developers began to speak in turns, the manager finished with a demonstration of the burn-down diagrams and questions from the public.

The main tasks of the manager on the demo:


  • Enter all the tasks and goals of sprint'a;
  • To fix all the questions and suggestions during the speeches of the developers;
  • Answer questions by helping the developer;
  • To fix all the shortcomings / positive aspects in the speech of the developers;
  • Sum up sprinta with a burn-down demonstration;
  • To fix and answer all questions at the end of the presentation;
  • Get feedback.

Developers on the first demo


At the first demonstration, as in the other ten sprints, the developers told themselves: the use of complex terminology, a deepening in the subject area, a demonstration of the results not for ordinary people. At the initial sprints, sometimes now, we had to rephrase, summarize the developer demonstration so that interested people could understand what was going on.

Demo audience


On the part of the public, there were many abstract questions that indirectly related to the sprint being demonstrated, to which they very much want to get an answer - this is very delaying the demonstrations to this day. The first demonstration lasted an hour and a half.

Retrospective


The first sprint was also successful for developers. Reviews were only positive.

What improvements were discussed at the first retrospective:

  • Need to do more slides in the presentation;
  • Do not call on a demonstration of people who are indirectly related to the project;
  • Some technical details on the improvement of the equipment of workers;
  • In more detail to discuss the features on the planning, in the course of the sprint'a revealed some nuances that were not taken into account.

Feedback from the management


I liked everything, I need more slides in the presentation. The management wanted to tie the premium part of the developers ’developers to the results of the sprint demonstration: the interested parties put down subjective evaluations to each developer with the inclusion of the criteria for this assessment, the manager’s assessment is the arithmetic average of all evaluations. This system is not really caught on, but this is a completely different story.

How it all went


After the first sprint, a lot of water has flowed under the bridge, many actions have been taken to optimize the processes, some had some profit, many did not.

What measures have been taken

Team unification why happened


Initially, we had two teams of a different development profile, each had its own Scrum with blackjack and Scrum-desk. But since we always, and now, have drawdowns with management (I am actually one), I did not have enough time to organize the planning / management / demonstration processes for two teams. For this reason, we decided to merge the teams into one.

Yes, it helped win some time, but, No, it did not give positive results. This lasted four sprint'a, but since the teams had a completely different development profile, the developers had absolutely no reason to work together.

Command separation


Over time, workers became more and more areas of development, then there were mobile phones, then something else. As I said in paragraph with the unification of teams, people have nothing to work for together if there is no direct connection between them in the development of projects. Accordingly, we divided the teams in different directions. Yes - it gave a productive result for each individual team, but each team devoured a lot of manager time.

Time variation sprints


We tried different variations:

  • Two week sprint. The optimal ratio of work on the development and work on planning. But there is a certain minus - during the time interval of two weeks there are additional (smart or urgent tasks from the management) tasks that we have to do, for this reason, the sprint does not always end successfully.
  • Weekly sprint. The ratio is more towards the work of planning. But there are almost no third-party tasks, all sprints are successfully completed.
  • Four week sprint. It turns out very strong deviations in the results of sprint'a. The most unfortunate for us sprint.

As a result, we stopped at a two-week sprints.

Moved to board with markers


Abandoned the Vatman, looks ugly, the developers did not like it on the wallpaper.



And solves the problem of tearing the tape from the paper. But, a new problem appeared - glue on the board. The burn-down chart in paper form also disappeared, as I began to display the image of the chart on a TV in the developers' office.

Next step: began to write daily rallies with markers on the blackboard:



The table contains: a number, a column for burning tasks not from the plan, a column for burning problems from the plan.

Switch to cloud: google doc


Abandoned MS products, went to google doc cloud solution. Scrum / Sprint -list has also been upgraded. The main difference from the first version of the sheet: the tasks are divided into each employee and they are decomposed. (link is in the sources and links)

Began to keep burn-down charts in google tables. As time went on, more values ​​were added to the table:



Since with a long sprint we had a tendency: we didn’t fit in sprint (we tried to take stocks, didn’t lead to anything good), introduced a new value - off-plan, which shows the schedule with regard to the burning of unplanned tasks.

, : Real, Off-plan (error) Off-plan (extra):



:

  • Ideally. — .
  • Plan. .
  • Off-plan (error). , , — .
  • Off-plan (extra). , sprint'a (smart ).
  • Real. = + + .

google


, :



, , .

Redmine


Redmine, — Backlog's. backlog' sprint' Redmine:



, , . Redmine, — . Sprint «» Redmine. , .




story-points sprint'. , sprint story-ponts. , , , . story-points sprint — .


. .

?


: . . .

?


:


  • .
  • sprint', backlog .
  • , .
  • ( ).
  • , .
  • , , .


, , 1 , . , CRM. - : — scrumban.ru. ( )
MS Project .

Conclusion


, , . , , .

:

» : «Scrum XP: »
» Agile-
»
» Scrum-list ( )
» , Poker planning
» Scrum-list
»

Source: https://habr.com/ru/post/318002/

More articles:


All Articles