Agile Camp 2015: travel notes

Hello! Today I want to tell a story about my fascinating journey to the “anti-conference” of AgileCamp 2015.

Before participating in this event, I had no experience in using Scrum and Kanban, so it was very interesting to try out flexible methodologies in practice. I apologize in advance if I messed up with terminology somewhere or changed the meaning of what I heard - first of all I wanted to share my impressions. I will be glad to any of your comments, including comments and additions.

Meeting place can not be Changed

After a long journey: by plane, aeroexpress, subway and transfer bus, I found myself in the Yahonty boarding house near Moscow, on the shore of a very picturesque lake.
')


Beautiful nature, clean and fresh air, cool weather - one can say that the atmosphere at AgileCamp 2015 was special in every sense.

The first day of the “anti-conference” traditionally began with registration and, of course, hot coffee, which dispersed so quickly that it did not have time to pour it into the boilers. Slowly but surely, all the guests of AgileCamp gathered in the local conference room for a welcome line.



After a short introductory word from the organizers, the "leaders" of AgileCamp presented their "pioneer troops":

• Grocery - about the pain of users, market research and work with the audience.
• Engineering - about the most rapid and high-quality development, using refactoring, TDD, BDD and DevOps.
• Process - about project management of the whole chain of product creation.

The topics of the Process Detachment seemed to me the most interesting, so I went to the detachment to such a stellar brigade of counselors, already familiar to me from their speeches, articles and books

Start!

After the introductory presentation, all the teams dispersed in their conference rooms. By this time, counselors have already prepared the first task: each of us received a playing card, from which he had to go in search of the strongest poker combination. I got an ace of spades, a strong card that didn’t fit everyone. I had to go around the whole hall before I found the guys who lacked just such a card for Flash. After that, we teamed up with the next five, sat down at the same table, and so our combat team appeared (“Black screen”, hello!).

The next task was no less interesting: we had to come up with several new products and describe them in this format Geoffrey Moore:


There were many ideas, but when the discussion was still in full swing, a new task was received: to go to the “fields”, to colleagues for feedback on the services we had invented. It is difficult to overestimate the benefits of such even the simplest polls - thanks to the questions and clarifications of other participants, we returned to the table with much more elaborated ideas. But, only one product should have survived. We argued a little more and eventually chose the idea of ​​a single service. After that, it is time to move on.

A simulation game for writing TK

Before embarking on the development of requirements for our service, counselors suggested that we play a game of preparing TK, in which there were many “insights” and “recognitions”.

The rules are very simple: first, participants are divided into teams of 5 people. The following roles are assigned to each team: 2 developers, 2 analytics and 1 postman. Analysts go to the other end of the hall, where they receive a picture with multicolored geometric figures and the task "to write TK for this picture, using only the text." Developers, in turn, should draw a picture “identical to the natural one” using ready-made TK. Communication is carried out exclusively in writing through the postman. Add here another time limit, and you get a very exciting game.

I will not reveal the secrets of our team, so that it would be more interesting for you to play yourself, I can only say that this game allows you to visually see the importance of communication. It will also show all the advantages of iterative processes and prototyping. Try it yourself, “insights” and “recognitions” and the truth will be very much.

Lean Startup Canvas

Our next task was to describe the business model of our service using Lean Startup Canvas:


At first glance, it seems that if you have a brilliant thoughtful idea, then there is no job easier. However, (yes-yes), the implementation of this task took a lot of time for our team. While we were just discussing our product at the table, it looked simple and clear, but it was enough to begin the formalization, as many questions appeared. We argued what problems we actually solve, what we offer and what we spend our money on. As a result, we somehow filled in all the fields of this table and relaxed.

But at that moment one of the counselors approached us and told us that the blocks of this miracle table can (and should) be used for self-testing. For example, features should solve problems, metrics should reflect the parameters of the solution, sales channels should correspond to the audience, and unique advantages should be inaccessible to competitors. It turned out that our first version of Lean Canvas was just teeming with contradictions.

Armed with new knowledge, we once again went over the tablet, and in the final version we got a more or less coherent product concept. In general, self-checking is definitely not superfluous.

Custom story maps

So, we got a formalized view of our product. Next, we had to perform a decomposition of works on the development of our product. We discussed different partitioning options: by architectural components, screen forms, and user stories.

The following task was to create just such a Story Map for the minimum viable product (MVP):


We set to work with great enthusiasm and very quickly forgot about the chosen viability hypothesis, discussing the implementation of individual Tasks with great intensity. Our map has greatly swelled and overgrown with various features. At some point, we remembered our hypothesis, wrote it on a piece of paper, which was pasted on the most prominent place. After that we thoroughly thinned the map - to verify the hypothesis, the minimum of the functions was enough.



The next step was to evaluate the tasks. One half of the team investigated Planning poker, the other - Bucket estimation.



How to evaluate the first and second method is described in detail in many different books, so I will share only the experience acquired during the assignment. Planning poker well eliminates the influence of personalities (you probably noticed that sometimes people express their assessments under the influence of their authoritative colleagues). But iterative card ordinances are not a very fast process. Bucket estimation is easier in this respect, so it is well suited for teams that have already worked together and need to quickly complete an assessment.

After the assessments were made, we were ready to start planning the first working iteration and throwing tasks at the guys from the Engineering Team . But on this positive note, the training on this part ended, and we had to part with our product. In less than one day, we turned the idea of ​​creating a product into concrete tasks with estimated labor costs. I experienced firsthand the benefits of feedback, iteration, formalization and verification of my ideas.

World Cafe

At the end of the day we tried this interesting way of discussing problems.

First, we selected 10 topics for discussion by the voting method. Each of the topics was assigned to a specific table. Participants came to the table with a topic of interest and chose a moderator. Further, all 20 minutes discussed the problem, and the moderator directed the discussion and recorded its results. As soon as the time was running out, the participants went to other tables, and the moderator remained to pass on the accumulated experience to the new team.
After several such rounds the moderators announced the results of the discussions.

At our table, where I was the moderator of the topic, they discussed the “Big Legacy project and Agile in it”. The topic was very relevant for a large audience share: colleagues from various companies shared not only their pain and fears, but also successful stories.

To summarize three rounds of discussions, the following will turn out: Agile can help solve the problem of the Big Legacy, such as a long process of making changes with low quality. But, first, for the implementation of Agile in any project requires the sincere desire of the team itself. Secondly, without the preparatory stage, it will not be possible to implement Agile into a huge monolithic project with an appropriate organizational structure. It is necessary to divide the project into small functional parts, and form small teams for each of them. Thirdly, it is incredibly difficult and not at all fast, so a sponsor is needed for such changes. Some colleagues have become such a sponsor product owners, others have external customers. A further decision comes down to the return of a huge technical debt: someone practices dedicated teams, someone uses a technical tax. The practices of “aggressive” autotesting, the scout rule and the Code Review are very useful in this process.

Whiskey party

At the end of the day, the organizers staged the Siberian Crown whiskey party, where around the fire until late at night the participants discussed a variety of topics: from the perspectives of using Agile in their projects to children's experiences with an assembler, as well as exchanging stories about Siberian frosts, bears, and the Urals forests and secrets of the Stalin metro.

The second day began with an exhilarating recharge in the fresh air, the participants of the Siberian Crown party slowly gathered in the hall of the conference room, the coffee dispersed at double speed. Many decided not to wait for dinner to be discharged from the rooms, and came with backpacks and bags.

On the tables, a fascinating and informative game getKanban was already waiting for us.

Simulation game getKanban

At AgileCamp, I finally managed to play this wonderful simulation game. It seemed to me a kind of entertainment, but in fact it turned out to be no easier than the real workflow :) At the mere study of the rules and the first iteration, it took us 2 hours, but then it all went like clockwork.

It is difficult to overestimate the benefits of this game. I think it makes sense to play both strangers and working teams, because it allows you to feel the “pitfalls” of the Kanban process and see the strengths and weaknesses of your team.



By tradition, I will not reveal secrets, but I will hint that you are not just filling out a bunch of pieces of paper and diagrams at every step of the game, they may turn out to be very useful;).
What came as a surprise to me was the ability to qualitatively predict the execution time of different types of tasks and the convergence of the process according to the basic metrics of the project.

Ball point game

Frankly, this game has become the most fun and positive test in these two days.

The rules of the game are simple: a team of 10 people is given 15 ping-pong balls. 1 ball = 1 ball touched by each team member. Balls can be thrown or rolled, but there is a limitation - it can not be transferred to a neighbor on the left or right. The game consists of 5 iterations: 2 minutes of discussion and 2 minutes of work.

Again I will not reveal the secrets of our strategy, but I will say that thanks to the active participation of each team member, and the improvement of the process after each iteration, we have gone from a simple scheme with 35 points to a streamlined conveyor with 156 points in 2 minutes.

I also remembered and liked the final conclusions from the whole process: if you don’t think up the solutions yourself, you’d just get the manager to give them - it’s unlikely you’ll pass the ping-pong balls so enthusiastically and selflessly.
And it is unlikely that you will get any close results if you give up the iterations and first think 10 minutes and then 10 minutes to work.

Try it yourself to make sure of it;)

Retrospective that works

And Agile ended in two days in a single pension with a story about a retrospective and a cycle of continuous improvements.

We discussed the structure of retrospectives and activities at each of the stages. A detailed presentation on this topic can be viewed here .

And in order to consolidate the knowledge gained, we conducted a retrospective of the getKanban morning game with the help of such an unusual deck of cards, Solitaire retrospectives:


It was not so easy to resist the search for the guilty, but the collective mind defeated these impulses, and we discussed our shortcomings in a positive way, outlined several improvements and thanked each other for their good work.

Conclusion

In this article, I described the most memorable moments of AgileCamp. Of course, many other interesting topics were discussed during the “anti-conference”: from the sprint combustion diagram to the peculiarities of domestic management.

The main conclusion I made for myself: flexible methodologies are a powerful tool for organizing the software development process:

• Restricting Work in Progress, whether it is the Kanban task limit or the scrum backlog in Scrum, removes harmful switchings between tasks.
• Collective responsibility contributes to self-organization and teamwork.
• Self-organization allows you to get a completely different level of responsibility, involvement and motivation.
• Iterations allow you to quickly respond to changing requirements, draw conclusions and improve processes.
• Continuous improvement of processes allows to achieve significant results, due to improvements at each iteration.

However, using this tool is not as easy as it seemed to me after reading a few books. Agile process sets the bar high for the level of self-organization of the team, involvement, responsibility and awareness of each employee. Therefore, it is not enough to just formally follow the rules of a particular methodology; it is necessary to adopt and work these rules in the spirit of flexible methodologies.

Most importantly, it is possible and it works! AgileCamp's “anti-conference” clearly showed that, if desired, even complete strangers are actively involved in the team process and achieve good results all together.

Good luck to you in the field of Agile, and to the guys from ScrumTrek new exciting AgileCamps (and yes, “Black Screen”, hello!).