A couple of weeks ago in Moscow,
AgileDays-2015 was held - the largest conference in the Russian Federation on modern management techniques in development.
- Two days, five tracks, huge halls of the Moscow World Trade Center (not to be confused with the WTC).
- Topics:
- Agile-management - from high-level development management in sluggish monster companies, to a “lean start” in startups.
- The grocery aspect - how not only to develop correctly, but to create exactly the necessary and the right.
- Specific issues of processes and technologies - testing and business analysis, usability and design.
- Modern architectural practices - * DD, and even a little about functional programming.
Revolving in “advanced” circles, it often seems that Agile approaches have already “captured the whole world,” and it's enough to talk about what is clear and well-known. But in real life, of course, everything is much more neglected - there is a successful cohort of “early adopters”, and as can be seen in the well-known picture of the “dilemma of the innovator”, there is a big chasm, and either those who are completely unaware of, or who about Agile “ everything is clear, because the neighbor-Rabinovich sang. " This is evident even in a number of recent publications on the mega brain. Therefore, the real, and even not always successful, experience from those who are in the subject and found all the rakes, and a bunch of nishtyakov - is very useful and much more relevant than even books, as a rule, already obsolete by the time of publication. The speakers were not evangelicals, but practitioners from large companies and start-ups, although yes, there were consultants telling about the “bending of the unbending”, such as the banks' bailout.
It was great there - you missed a lot if you weren’t there. But. Video recordings and other report materials are published and will be available to everyone. My recording is good, everything is as usual - montage, several cameras, a screen, sound from a microphone, animation technology.
And I, as a member of the program committee, making sure that the speakers convey their knowledge to all those interested, I will try to make a series of publications, including the video of the report, abstracts and slides, and my very brief review. An elephant needs to be eaten in parts - not all videos are ready yet, it’s still necessary to watch and reflect, and even large articles scare readers and writers with its volume — I’m ashamed to admit that in a few visits I couldn’t finish writing an epic review of
72 video reports from the past of AgileDays-2014, and even a
review of 2011 mastered only six months later. Of course, the Agile conference review should be done iteratively, as quickly as possible by shipping
value to consumers. And, as is customary in Agile, it is even possible to stop shipments if users do not like the product ...
')
So, look and decide - this format is OK or not ...
Agile basics
This report is intended for those who are just starting to learn flexible software development methods, commonly called Agile.
I will tell the basic things about the values ​​and principles of Agile, on the basis of which the modern Agile-methodology Scrum and Kanban are developed. We will consider the question of why agile development appeared (in the West and in our country), how it differs from the traditional approach to software development, and why iterative methodologies have in fact become the de facto standard in the software world.
In addition to managerial practices, we will add engineering practices from extreme programming, and understand why we understand why there is no flexible development without a flexible architecture.
There will also be covered the topic of Agile implementation and typical problems encountered in this way.
additional materials
Each AgileDays conference always included a brief introduction to Agile development, a certain
crash course , on the one hand for those who were suddenly completely unprepared, and on the other hand, helping to put even the famous in their head correctly. By the way, these introductions have always been popular, despite the fact that they were allowed in parallel with the key and invited gurus, and these reports have always been of good quality - those who ate the crocodile, ate a dog, told about them.
Boris Volfson obviously has this right, for he
wrote a book , has augmented several large companies, and generally looks
solid .
However, you can see a shorter
last year’s introduction or even compare it with the introduction of
2011 .
Basics are fundamentals, retelling is stupid, but in a sense, the continuation of this “Agile 101” course was the next report by Boris ...
Build your own Agile framework within the company
This report is intended for those who are just starting to learn flexible software development methods, commonly called Agile.
I will tell the basic things about the values ​​and principles of Agile, on the basis of which the modern Agile-methodology Scrum and Kanban are developed. We will consider the question of why agile development appeared (in the West and in our country), how it differs from the traditional approach to software development, and why iterative methodologies have in fact become the de facto standard in the software world.
In addition to managerial practices, we will add engineering practices from extreme programming, and understand why we understand why there is no flexible development without a flexible architecture.
There will also be covered the topic of Agile implementation and typical problems encountered in this way.
additional materials
There is already an advanced Agile-course for those who are already in the subject line, and who exactly need to have everything work, take root in the company, sometimes adapting to existing processes and technologies, and sometimes inevitably adapting culture and organizational structure. Here, not only the commandments of the Agile Manifesto and the simple hygienic rules of Scrum / Kanban are considered here and in the context of new-fashioned Lean-frameworks of product management, it is also told about engineering Agile practices, and about managerial aspects of changes - game theory and leadership. Of course, at the end there are a lot of questions from those who really “went to battle for agile” in their companies and the guru's answers to difficult questions (“aaa, what to do with ossified companies? ...” - “Persuade the customer. Or work as he wants. ").
By the way, Boris is on the
mega brain , so if you like the reports, you can thank him in an understandable way. :) And I have more reports of
Boris , I recommend.
Development of project management and quality criteria in IT
This is a great continuation of the theme of the “guru of the history, philosophy and culture of Agile”, from widely known in narrow circles of
Maxim “Gandalf” Tsepkov .
Project management and quality criteria in IT have come a long way in historical development, replacing several models.
It all began with the perfect software (software system) as a result of high-quality design, typical of R & D.
Then there was a period of comprehensive rationing of processes for their development (PMBoK 3, RUP), which was replaced, in part by revolutionary, by flexible approaches to development (SCRUM, Kanban), which emphasized the timing and predictability of delivery.
And now the focus has shifted to customer satisfaction and achieving business goals (OMG Essence of Software Engineering).
But development has not stopped.
The lack of understanding of the place of specific approaches, methodologies and practices in the context of the overall development of the industry does not allow the system to use them effectively and gives rise to many empty discussions among developers on how to properly.
During the report, we consider the main milestones in the development of approaches to the management of IT projects and the evolution of software quality criteria in the world and in Russia, which in the 90s went its own way, but recently approached general trends. And also we will figure out for which projects and teams one or another project management model is appropriate, in what their advantages and disadvantages may lie and what forms of development organization correspond to them. Understanding this will allow not only to set up processes in your project, but also to have meaningful discussions with supporters of other forms of organization that are often found among customers and management.
additional materials
If in the past AgileDays Maxim talked about the
fantastic concepts of Spiral Dynamics , then this time everything is quite historical and scientific.
The history of development, from the time of industrial R & D, through the world of Brooks's man-month, to the rise and final fall of waterfall, from eXtreme Programming, as a desperate and failed programmer's rebellion, to completely working management SCRUMs. All of this Agile-movement is quite reasonable, and could not fail to appear, for a bunch of reasons - and “IT Nature
does not tolerate emptiness interferes with the procedures ©” and the high cost of classical scaling with a bunch of sergeant managers (not to mention the ideal wildly expensive PMBOK-managers , which is vanishingly small), and the variability of the nature of IT development - “while we attack the enemy changes the landscape ©” ... Well, in general, now “sane developers do not go to bureaucratic offices ©”.
The future is foggy, maybe OMG “Omaigot!” Essence from SEMAT, where old concepts at the word level are cut down (clear out all references to “project”), but in the glossary, there are solid “stakeholder” and “opportunity”, but ... “standard descriptors don't have time behind the development of the industry - they are also old © ”.
The Russian path to Agile, in a certain sense, is simple, because it was not coming “from a riot at the plant,” as in the west, but mainly from the “scientific culture” of the ruined scientific research institutes that launched the Russian IT industry. I was pleased that Maxim quoted
my review of “Cultures of software projects”
And you can argue with Maxim in his
post with a review of the conference .
What is this dual-track agile?
One of the great merits of Agile is that it allows you to make the most significant backlog.
But even if we do only the most significant, and we do it by accompanying retrospectives, TDD, code quality procedures, it may turn out that the product will not be valuable for business and will not meet the goals of the user. The fact is that the client doesn’t know well what he is asking for until he tries it.
The approach, called Dual-track Agile, even before a significant investment in the development will help to understand what is really necessary and useful, measure the benefits, change the initial ideas for the best and completely unexpected.
In the report, you will see several cases of applying this approach on a real product at Kaspersky Lab, as well as how product pivots and MVP significantly affect business results.
additional materials
In the report,
Ilya Kuznetsov immediately boldly hit Agile, that he, supplying effective processes “how to do it quickly and efficiently”, does not think at all that it is necessary first of all to “make the right product”. It was probably such a polemic device, for the audience and the audience even tried to argue with the speaker, defending the honor of the
Holy and Cherished Agile Manifesta , and the program committee members (“WAT? What does he bring? Who let him? Who has reviewed his report?”) . After all, labor-Agile is about doing the right thing and the right thing, and the gain always comes precisely from more accurate hitting the target, and the savings are precisely due to the deprioritization of the unimportant, and what he was talking about is essentially “Product Discovery” food practices from Agile and Lean approaches.
But I agree, for those who associate Agile with those who have been learned in the “don't think, do so” mode for Scrum & Kanban in an hour, you can really get the impression that you have forgotten about the product and it is useful to remind you about it.
In fact, it was a retelling, with some variations, of his report “
Template break - Lean Product Management and MVP in a large company ” from SECR-2014, with the same cases (“startup for farmers”, “installer bug in trial antivirus” , etc.), the same flexible practices of Lean Startup, which are symbiotically germinating inside the huge engines of a huge company. In any case, the report is excellent, vigorous, with good grades (
its SECR version was generally ranked first), I recommend for viewing.
It is a little true that such talents and forces are spent on the fear-trading antivirus business. After all, the true purpose of Agile is to bring happiness to the user, and not just to make a “valuable product” that can be more expensive, with cunning hacks with a shadow installation and manipulation of the user. Few people know that the free antivirus pulls the full version in the background, uses it, but as the postman Pechkin “does not give the package, because you have no documents”. And the team is not the fact that good, superheroes - “hipster-hustler-hacker” - follow the stopwatch with the merged behavior of users, deciding when to hook, so as not to leave ... Oh, I'm afraid at the next AgileDays will be SEO / SMM / spam startups, online poker where you can lose your wife, shops selling organs ... Perhaps then I will have to leave the program committee ...
However, I remember how a couple of times we solved potential problems to potential customers with a single consultation (“integration information system? —And can we overload copy-paste here? - Indeed, thank you!”), And they did not give money for it. And happiness must be borne not only by users, but also by all participants in the process - including developers. Then there will be harmony.
If the product theme was close, I also offer
other reports by Ilya +
[1] , and more
than a hundred reports on product management .
Three key skills of a successful Agile team
With a few examples, I’ll tell you about how we moved IT departments of very large financial companies towards Agile.
What worked well, what problems faced and what conclusions from this made.
Regardless of which company you work for (internal development, product, outsourcing), the general patterns of implementation of process changes may seem useful to you.
additional materials
Dmitry Lobasev is a well-known consultant with a long experience of “adapting and kanbanizing” in-house development in large banks, which is essentially opposed to Ilya from the previous report, recalling the basic principles of Agile — customer and customer satisfaction.
What can not be done mechanically is that business celestials descend their levels from Olympus to the developers hold, try to take off, or at least jump in the direction of stakeholders and users, find out what matters to them, how it should look, and even how with Kazan - "the concept of modern development includes advising the customer on what he really needs, and how to do it right ©". Of course, many other issues were also considered, all in a very lively manner, the rating of the questionnaires and the mobile application is 4.5, we recommend. And if you like it, there are
still five heels of Dmitry’s reports .
Me transformer
In the books we read colorful descriptions of how great life is in the world of agile. As everything is done on time, no one distracts from the interesting work, no one demands in haste to erect the pyramid of Cheops with crutches as the main building material.
At the trainings we even manage to try and believe that all this works and is achievable within the framework of an individual reality. And then we return to our jobs and ... Well, you yourself know perfectly well how it happens later. Implementing Agile is not just a process change. This is a change of culture.
This is a new chapter in the history of the company. This is a change in business attitude. And many of you have witnessed tremendous resistance and tension accompanying these changes. No matter who you are - CEO, CTO, Agile-Coach. High resistance and tremendous voltage - this is your environment.
And you in this environment - the Transformer. How to be a Transformer? What knowledge, skills and abilities allow you to make changes? Do resistance and voltage actually interfere? How not to burn out in this field? I will tell about this in my speech.
additional materials
Maxim Gaponov , with a 1001 history of staff corporate pastor psyker, a lifetime of evangelizing pagans and Agile heretics in large companies. From the technician of the combat Orthodox NLP (“warming up ... entering the mode ... contact ... post-contact ..."), to the esoteric -
Tarot cards spiral dynamics and all that. On the sidelines, by the way, evil tongues even suggested measuring agile psyker strength in gapons.
The title of the report evokes electrical metaphors ... and yes, not for nothing - for professional risk, there’s just such a thing - to burn out (“I'm tired, I'm fly-fly ©”). The author has already burned out four times, the professional Phoenix recipe is the main thing to prevent it from burning to the ground.
Pikrelyted:

Why unit tests don't work
Two years ago we found ourselves in an unusual situation. We have a large and complex project (CAD system), several development teams, full Agile (SCRUM), we practice Test Driven Development, that is, we write a lot of unit tests.
And here there seems to be an impossible problem: at the end of the sprint there is no stable assembly, the new functionality works, and the old one falls off.- Why did it happen?
- Why unit testing did not save us?
- What to do in this situation?
Faced with this problem, we developed a solution that is still working on the project and all participants consider it one of the key success factors of the project.
Want to know our story of relief from suffering?
The report is designed for a wide audience, so I will talk about complex things in simple language, with pictures, so that it is clear to everyone. The problems and solutions addressed in the report are universal and can be applied in most program projects. I promise it will be interesting.
additional materials
Alexander Martyushev, AgileDays regular speaker at this time told that
TDD - sucks and does not work , a joke. It works of course, but in a multi-year epic project with a GUI, such as a CAD system, which should survive the change of a heap of technologies and frameworks, it is more important to make a flexible platform and focus on integration tests, including GUI testing. So that it would be non-fragile, of course, the classic Hindu approach with TestComplete screen macro recordings, the task is not overpowered, we need a flexible GUI platform and write “visual” tests based on the interface model that do not break when the button is moved. So many people actually do it, just remember that Netbeans is developing and testing this way, and a number of lesser-known products. But this task is not only technical, but, as always, rather psychosocial - how to convey the need to write automatic tests to the developers and maintain the "green status" of the unbroken build.
Developing the Agile Mindset for Organizational Agility
In the global economic environment.
Modern automated tool suites enable collaboration and emerging priorities. However, it has been noted that many organizations have agreed upon the agile transformations.
This presentation emphasizes agile mindsets and highlights for sustainable agility.
additional materials
Of course, it is impossible not to put in the first iteration and keynote of the invited foreign guru. The report is in English (I only managed to learn “Spaciba” from the Russian speaker), and I haven’t yet had time to look at it, I will still make a version with Russian simultaneous translation. So for now, see for yourself if everything is OK with English.
How a UX specialist shared his tools with agile teams
2 years have passed. Semyon matured and matured (in professional and life terms). During this time, he managed to work with several agile-teams and to see a lot of different scraps and shame, to fill the next cones when introducing the design process into flexible development processes. But in all cases, he saw that some designer tools could be useful to other participants in the process, teams that do not have interface designers on their staff. After all, these tools are easy to understand and do not require much time to work out. And Semyon decided to try First on his team, and then on cats, that is, on familiar teams. All the successful (accustomed in the teams) solutions, he, according to the good old tradition, was recorded in his notebook, which now bore the name UX in the service of Agile.
What topics touched Simon, where and what tools of the UX-specialist he tried to implement:- how else (except for the usual tools) can you collect and record requirements regarding the planned features;
- how can you upgrade the user story in the direction of greater empathy for users and what tools can help with this;
- break up large user stories into smaller ones as much as possible (again, with more empathy);
- how to fix the overall experience of user interaction, so that in the next iteration not to break the wood when implementing new features. After all, it is always difficult to keep in mind the whole picture of human interaction with the product. And when you add all new and new features, often instead of the help sticks are inserted into wheels;
- how you can use your favorite impact map to work out the user's goals;
- How can I check the need for features (or rather, the expected satisfaction with the presence / absence) before placing them in the backlog.
additional materials
Yes, Agile is also usability. But usabilityists are such usabilityists - initially the report was called “Semyon from back”, as if someone in the real world remembers the
author’s report on AgileDays-2013 . And this usability is a hobby for “persons”, when it is necessary to tell about clear things with the help of a special “character”, Semyon, an obvious alter-ego of the author, but mentioned in the third person. Do yuzablists see those around them as “characters”? Brrr. There is something in this from the classic western stand-off performance of a ventriloquist with a doll, throwing up the idea for the speakers for future reports.
But things were told right - as in Agile development, a usability must be active, and without waiting for marketing departments to implant modern development tools of usability and business analysis directly into the development team - User Story Map, Customer Journey, empathy maps, Kano diagrams ...
The report is very well received, "the General Assembly", and in general,
Nikita Efimov, a well-known speaker, a dozen of his reports by
reference .
We also recommend more detailed reports on
Customer Journey ,
Kano analysis , and
Impact Mapping , and indeed a
hundred usability reports .
Why do we need functional programming?
- Did your projects always run on time?
- Have users ever had any complaints?
- Accompanying projects submitted was not time consuming?
- New functionality always fits well with the existing architecture?
If the answers to all the above questions are positive, then you do not need to change anything, your team is an example of the rare harmony of staff, methodology and tools. Otherwise, you should be open to new approaches to solving your problems, including a critical look at the technical tools and programming languages ​​used.
The report on simple examples gives an idea of ​​how the domain modeling and the implementation of functionality differ when using functional languages, such as F #, Scala and Clojure, in comparison with object-oriented C # and Java.- What types of tasks are most suitable for functional languages?
- How best to implement them in the project?
- And how to convince the leadership of the practicality of such an election?
- All this will be discussed in the report.
additional materials
If someone thought that at the conference there was only managerial “blah-blah-blah”, then here is an example of a completely technical report - functional programming, monads, and that’s all from
Vagif Abilov , not the first time arriving from Oslo on AgileDays - last year
talked about automated testing and TDD.
The report played with Conway's Life, played F #, tried to taste the monads ... it would seem, why functional programming in Ajail and in general in the real world, as
written by evil tongues who have not looked at the report.
On the one hand, the reasons are architectural - the functional implementation also provides paralleling and flexibility, compactness and verifiability. On the other hand, functional specifications can often be used, due to their compactness and power, as subject DSL languages ​​for specifying business logic or application tests, and who knows, maybe future business analysts will not only move the squares in Visio, but and will be able to write holistic functional specifications, either testers, what programmers will do, or even to ship smart specifications in to smart platforms, turning off programmers from the process.
So, despite the seemingly some inconsistency with the theme of the conference, the report was well received, the audience sang the monads with the speakers, and the report received the fifth place among all. Discuss the same report with the author in the
appropriate blogpost .
Yes, this year we unfortunately had fewer technical reports, because some of our traditional engineering practices experts did not come from Ukraine, some went to the management and opened their own companies at all - yes, in Russia there are almost no old programmers, only management career. Or not?
Take a look and - technological practices last year's reports on technological Agile practices , and you can try to tell something new and interesting on the following AgileDays - we will wait.
So, for now, everyone, we are looking forward to your views and comments.
You can comment here, or in your blogs and drop them here, or, if you are reading this, and are not registered on the megamind (there are usually not enough comments here) - the link “additional materials” is where to comment on a regular Discus.
For intelligent feedback - a thing very valuable both for authors and for the program committee - we will certainly take everything into account in order to make the next conference better. On the links you will also find the contacts of the speakers, and you can discuss the points of interest directly with them.
The video is still in beta, errors and problems are possible: the sound is gone, the screen is out of sync, or you need a full-screen slide to view small text, or vice versa — show a live screen to see where you are driven by a laser pointer (I have been trying to train speakers trackballs, stylus and so on, which shows large markers on the screen, is written on a screencast, does not require a reversal backwards to the audience, but damn laser pointers are still alive, and I have to guess while installing it, it's so tiring). In general, if you see problems - report them too. In the beta version of the video, red-translucent “true time markers” are embedded — report bugs indicating this time. For all this while you can fix it. Or rather, there are such problems right now, I found a couple myself, I wonder if you will find them faster,than i fix them. Also, I think - maybe for very busy managers, to make audio recordings for non-technical reports, accelerated by 70% (for humanitarian reports, where non-critical info is on the slides, you can listen to most of the information and speed gives you vigor and time savings)?
Well, of course, it depends on your activity whether it is worth continuing the delivery of the AgileDays product to the mega brain, or ... it is worth repivitating and doing something else.
If, on the contrary, “a little!, Let's get faster!” - these are more than a hundred reports on Agile from past conferences , here there are reports initially from AgileDays-2015 , and you can subscribe via RSS .