10 reports from AgileDays-2015 - Iteration-01

    A couple of weeks ago in Moscow AgileDays-2015 took place - the largest conference in Russia on modern management methods in development.
    • Two days, five tracks, huge halls of the Moscow World Trade Center (not to be confused with WTC).
    • Topics:
      • Agile management - from high-level development management in slow-moving monster companies, to a “lean start” in startups.
      • The product aspect - how not only to develop correctly, but to create exactly the right 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.
    Rotating in “advanced” circles, it often seems that Agile approaches have already “captured the whole world”, and it’s enough to talk about what is understandable and well-known. But in real life, of course, everything is much more neglected - there is a successful cohort of “early adopters”, and as you can see in the well-known picture of the “dilemma of the innovator”, there’s a big chasm, and either those who are not at all aware or who are talking about Agile “ everything is clear, for the neighbor Rabinovich sang. " This is evident even in a number of recent publications on the megamind. Therefore, the real, and even not always successful, experience from those who found the rake and a bunch of nishtyakov in the subject is very useful and much more relevant than even books, which are usually already outdated by the time of publication. The speakers are not evangelists, but practitioners from large companies and startups, although yes, there were consultants,

    It was cool there - you missed a lot if you were not there. But. Video recordings and other materials of reports are published and will be available to everyone. My recording is solid, everything is as usual - editing, several cameras, a screen, microphone sound, animation technology.

    And as a member of the program committee, making sure that the speakers convey their knowledge to all interested, I will try to make a series of publications, including video reports, annotations and slides, and my very brief post-review. You need to eat the elephant in parts - not all the video is ready yet, you have to watch the edited video and reflect on it, and large articles scare readers and writers with its volume - it’s a shame to admit that I, in a few visits, but couldn’t finish writing an epic review 72video reports from the past AgileDays-2014, and even the 2011 review mastered only six months later. Of course, an Agile conference review should be done iteratively, shipping value to consumers as quickly as possible . And, as is customary in Agile, it is even possible to stop deliveries if users don’t like the product ...

    So, look and decide whether this format is OK or not ...


    Agile Basics

    This report is intended for those who are just starting to learn the flexible software development methods commonly called Agile.

    I will tell you basic things about the values ​​and principles of Agile, on the basis of which the modern Agile methodologies of Scrum and Kanban are developed. We will examine the question of why flexible development appeared (in the West and here), how it differs from the traditional approach to software development, and why iterative methodologies have actually become the default standard in the software world.

    In addition to management practices, we will add engineering practices from extreme programming, and we will understand why without a flexible architecture there is no flexible development.

    The topic of Agile implementation and typical problems encountered along the way will also be addressed.


    dopmaterialy

    Each AgileDays conference always included a brief introduction to Agile development, a kind of crash course , on the one hand for those who turned out to be completely unprepared, on the other hand, which helps to put even the right thing in your head. By the way, these introductions were always popular, despite the fact that they were launched in parallel with the key and invited gurus, and these reports were always sound - they were told about by those on the Adjayle who “ate a crocodile and ate a dog”.

    Boris Wolfson clearly has a right to do so, for he wrote a book , aggilized several large companies, and generally looks solid .

    However, you can see a shorter last year’s introductionor even compare with the introduction of 2011 .

    The fundamentals are the fundamentals; retelling is stupid, but in a sense, the continuation of this “Agile 101” course was the next report by Boris ...

    Building your own Agile framework within the company

    This report is intended for those who are just starting to learn the flexible software development methods commonly called Agile.

    I will tell you basic things about the values ​​and principles of Agile, on the basis of which the modern Agile methodologies of Scrum and Kanban are developed. We will examine the question of why flexible development appeared (in the West and here), how it differs from the traditional approach to software development, and why iterative methodologies have actually become the default standard in the software world.

    In addition to management practices, we will add engineering practices from extreme programming, and we will understand why without a flexible architecture there is no flexible development.

    The topic of Agile implementation and typical problems encountered along the way will also be addressed.



    additional materials

    There is already an advanced Agile-course for those who are already on the topic, and who definitely need everything to work, take root in the company, adapt in some places to existing processes and technologies, and in some places inevitably adapt culture and organizational structure. It’s not just about the Agile manifest commandments and the simple hygienic rules of Scrum / Kanban, it’s all considered in the context of the new-fangled Lean product management frameworks, it also tells about Agile engineering practices and managerial aspects of changes - game theory and leadership. Of course, at the end there are a lot of questions from those who really “went into battle for agile” in their companies and the answers of the guru to difficult questions (“ahh, what to do with ossified companies? ...” - “Persuade the customer. Or work as he wants. ").

    By the way, Boris is onmegamind , so if you liked the reports, you can thank them 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 “guru about the history, philosophy and culture of Agile”, from the widely known in narrow circles of Maxim “Gendalf” Tsepkov .
    Project management and quality criteria in IT have come a long way in historical development, changing several models.

    It all started with perfect software (software system) as a result of high-quality design inherent in R&D.

    Then there was a period of comprehensive standardization of processes for their development (PMBoK 3, RUP), replaced by, in part, revolutionary, flexible development approaches (SCRUM, Kanban), which emphasized delivery times and predictability.

    And now the focus has shifted to the satisfaction of stakeholders and the achievement of business goals (OMG Essence of Software Engineering).

    But development did not stop.

    The lack of understanding of the place of specific approaches, methodologies and practices in the context of the overall development of the industry system does not allow them to be used effectively and gives rise to many empty discussions among developers about how to do it right.

    During the report, we will consider the main milestones in the development of approaches to managing IT projects and the evolution of software quality criteria in the world and in Russia, which went its own way in the 90s, but has recently come closer to general trends. And also we will figure out for which projects and teams one or another project management model is appropriate, what their advantages and disadvantages may be, and what forms of development organization correspond to them. Understanding this will not only allow you to customize the processes in your project, but also conduct meaningful discussions with supporters of other forms of organization, which are often found among customers and management.


    additional materials

    If at 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 days of industrial R&D, through the world of “Brooks man-month”, to the rise and final fall of the waterfall, from “eXtreme Programming”, as a desperate and failed riot of programmers, to fully functioning managerial SCRUMs. All this Agile-movement is quite justified, and could not but appear, for a bunch of reasons - and "Nature IT does not tolerate emptinessinterferes 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 are disappearingly few), and the variability of the nature of IT development -" while we advance the enemy changes the landscape © "... Well, in general, now "sane developers do not go to bureaucratic offices ©".

    The future is foggy, maybe there is OMG “omaygot!” Essence from SEMAT, where they cut down old concepts at the word level (they clear all references to the “project”), in the glossary there are solid “stakeholder” and “opportunity”, but ... “standard descriptors do not have time behind the development of the industry - they are also old ©. "

    The Russian path to Agile, in a sense, is simple, because they did not go to it “from the rebellion at the factory” as in the West, but mainly from the “scientific culture” of the bankrupt research institutes that launched the Russian IT industry. I was pleased that Maxim quoted my review of "Culture 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 Agile’s major strengths is that it allows you to do the most significant of what’s backlogged.

    But even if we do only the most significant, and do it accompanied by retrospectives, TDD, code quality procedures, it may turn out that the product will not be valuable to the business and will not meet the user's goals. The fact is that the client does not know well what he is asking until he tries it.

    The approach, called Dual-track Agile, even before a significant investment in development will help to understand what is really needed and useful, measure the benefits, change the initial ideas to the best and completely unexpected.

    In the report, you will see several cases of applying this approach to a real product in Kaspersky Lab, as well as how product “pivots” and MVP significantly affect business results.


    additional materials

    In the report, Ilya Kuznetsov immediately boldly bumped into Agile that he, delivering effective processes “how to do it quickly and efficiently”, did not think at all that he had to “make the right product first”. Probably, it was such a polemic trick, because the audience got caught even trying to argue with the speaker, defending the honor of the Holy and Treasured Agile Manifesta, and program committee members ("WAT? What does he carry? Who let him in? Who reviewed his report?"). After all, Tru-Agile is precisely about doing the right and the right thing, and the gain always comes precisely from a more accurate hit on the target, and the savings - precisely from the depriorization of the unimportant, and what he talked about is essentially “Product Discovery”, known product practices from Agile and Lean approaches.

    But I agree that for those who associate Agile with learned “don't think, do it” mode in an hour of Scrum & Kanban, you might really get the impression that you somehow forgot about the product, and it’s useful to recall this.

    In fact, it was a retelling, with some variations, of his report “ Break of the template - Lean Product Management and MVP in a large company”With SECR-2014, with the same cases (“ start-up for farmers ”,“ installer bug in trial antivirus ”, etc.), the same flexible Lean Startup practices that grow symbiotically inside the tough colossus of a huge company. In any case, the report is excellent, peppy, with good grades ( its SECR version generally took first place), I recommend it for viewing.

    It’s a little pity that such talents and forces are spent on the antivirus business of “trading in fear”. After all, Agile’s True Goal is to bring happiness to the user, and not just to make a “valuable product” that can be more expensive by cunning hacks with shadow installation and manipulation of the user. After all, few people know that the free antivirus pulls the full version in the background, uses it, but, like the postman Pechkin, “he doesn’t give the package because you don’t have any documents.” And the team is not a fact that kind, superheroes - “hipster-hustler-hacker” - monitor the merged behavior of users with a stopwatch, deciding when to hook, so as not to leave ... Eh, I'm afraid the next AgileDays will have SEO / SMM / spam startups, online poker where you can lose your wife, organ trading stores ... I guess then I have to leave the program committee ...

    However, I remember how one of the companies we solved potential customers a couple of times with a single consultation ("Integration information system? Can it be overloaded with copy paste? - Indeed, thanks!"), And they did not give money for this. And happiness should be brought not only to users, but also to all participants in the process - including developers. Then there will be harmony.

    If the product topic turned out to be close, in pursuit I offer other reports by Ilya + [1] , and more than a hundred reports on product management .

    Three key skills of a successful Agile team

    I’ll tell you a few examples about how we moved the IT departments of very large financial companies towards Agile.

    What worked well, what problems were encountered and what conclusions were drawn from this.

    Regardless of which company you work for (internal development, product development, outsourcing), general patterns of implementing process changes may seem useful to you.


    dopmaterialy

    Dmitry Lobasev, a well-known consultant with a long experience of “agglomeration and kanbanization” of house development in large banks, is actually essentially opposing Ilya from the previous report, recalling the basic principles of Agile - customer and customer satisfaction.

    What can’t be mechanically done here that business celestials lower their levels from Olympus into the hold for developers, you need to try to take off, or at least jump towards stakeholders and users, find out what is important to them, how it should look, and even how with ca - “the concept of modern development includes consulting the customer on what he really needs and how to do it right ©.” Of course, many other issues were considered, all in a very lively manner, the rating on profiles and the mobile application is 4.5, we recommend it. And if you liked it - another five reports of Dmitry .

    Me transformer

    In books we read colorful descriptions of how great life is in the agile world. As everything is done on time, no one distracts from interesting work, no one demands to whip up the Cheops pyramid 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 a single reality. And then we return to our jobs and ... Well, you yourself know very well how it happens later. Implementing Agile is not just about changing processes. This is a cultural change.

    This is a new chapter in the history of the company. This is a change in attitude towards business. And many of you have witnessed tremendous resistance and tension accompanying these changes. It doesn’t matter who you are - CEO, CTO, Agile Coach. High resistance and tremendous tension - this is your environment.

    And you in this environment are the Transformer. How to be a Transformer? What knowledge, skills and abilities allow you to make changes? Do resistance and voltage really interfere? How not to burn out in this field? I will talk about this in my speech.


    dopmaterial

    Maxim Gaponov , with 1001 stories of a full-time corporate pastor-psyker, all his life evangelizing pagans and Agile heretics in large companies. From military Orthodox NLP techniques (“warming up… access to the mode… contact… post-contact…”), to esoterics - Tarot cards, spiral dynamics and all that. On the sidelines, by the way, evil tongues even offered to measure agile-psyker-force in gapons.

    The title of the report evokes electrotechnical metaphors ... and yes, not in vain - because there is a professional risk, it’s exactly there - to burn out (“I’m tired, I’m a fly muffler ©”). The author has already burned out four times, the professional recipe for the Phoenix - the main thing is not to let it burn to the ground.

    Pickrelated:


    Why unit tests do not work

    Two years ago we were 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 a seemingly impossible problem arises: 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 did unit testing not save us?
    • What to do in such a situation?
    Faced with this problem, we have developed a solution that still works on the project and all participants consider it one of the key factors for the success of the project.

    Want to know our story of getting rid of suffering?

    The report is designed for a wide audience, so I will talk about complex things in a simple language, with pictures, so that it is clear to everyone. The problems and solutions considered in the report are universal in nature and can be used in most software projects. I promise it will be interesting.


    additional materials

    Alexander Martyushev, a regular speaker at AgileDays this time said that TDD sucks and does not worka 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 bunch of technologies and frameworks, it is more important to make a flexible platform, and focus on integration tests, including GUI testing. To make it a non-fragile, of course, classic Hindu approach with screen recordings of TestComplete macros, the task cannot be overpowered, you also need a flexible GUI platform and writing “visual” tests based on it that understand the interface model and do not break when the button is moved. Actually a lot of people do this, I remember for sure that this is how Netbeans is developed and tested, and a number of less well-known products. But this task is not only technical, but, as always,

    Developing the Agile Mindset for Organizational Agility

    Agile development methods continue to gain popularity with the increasing pace of change in today's global business environment.

    Modern automated tool suites enable collaboration and rapid software solutions delivery in response to emerging priorities. However, as organizations embark on agile transformations, many fail to harness the full potential of agile because they focus on process change while neglecting the underlying agile values ​​and principles.

    This presentation emphasizes the importance of adopting an agile mindset and highlights the organizational paradigm shifts and commitment to continuous learning that are essential for sustainable agility.


    additional materials

    Of course, it is impossible not to lay out the invited foreign guru in the first iteration and keynote. The report is in English (only Spaciba managed to learn from the Russian speaker), and I have not had time to look at it yet, I will still make a version with Russian simultaneous translation. So for now - see it 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 (professionally and in life). During this time, he managed to work with several agile teams and see a lot of different scrum and shame, fill up new cones when introducing the design process into flexible development processes. But in all cases, he saw that some of the designer’s tools can be useful to other participants in the process, teams that do not have interface designers in their staff. After all, these tools are easy to understand and do not require a lot of time to study. And Semyon decided to try First on his team, and then on cats, that is, on familiar teams. According to the good old tradition, he fixed all successful (settled down in teams) decisions in his notebook, which now bore the name UX in the service of Agile.

    What topics did Semyon touch, where and what tools of the UX specialist did he try to implement:
    • how else (besides the usual tools) you can collect and fix the requirements regarding planned features;
    • how to upgrade the user story in the direction of greater empathy for users and what tools can help with this;
    • how to break large user stories into smaller ones with greater efficiency (again, with more empathy);
    • how to record the general experience of user interaction so that in the next iteration not to break firewood when implementing new features. It is always difficult to keep in mind the whole picture of human interaction with the product. And when you add more and more features, often instead of help sticks are inserted into the wheels;
    • how you can use the beloved many impact map to work out the user's goals;
    • how can you verify the need for features (or rather, the expected satisfaction from the presence / absence) before placing them in the backlog.


    additional materials

    Yes, Agile is also usability. However, usabilityists are such usabilityists - the original report was called "Semen from back", as if someone in the real world remembers the author’s report at AgileDays-2013 . And this is a usability hobby for “persons”, when you need to talk about understandable things with the help of a special “character”, Semen, the author’s obvious alter ego, but mentioned in the third person. Can it be that the usabilityists see those around them as “characters”? Brrr Something in this is from the classic western stand-up performance of a ventriloquist with a doll, I throw the idea to speakers for future reports.

    And the things were told right - as in the Agile development, the usability must be active, and without waiting for the approval of the marketing departments to directly implement the modern usability and business analysis tools - User Story Map, Customer Journey, empathy maps, Kano diagrams directly into the development team ... The

    report is excellent adopted, "fdisyatke", and in general, Nikita Efimov known speaker on the link a dozen of his reports.

    We also recommend catching up with more detailed reports about Customer Journey , Kano-analysis , and Impact Mapping , and indeed a hundred reports on usability .

    But why do we need functional programming?

    • Have your projects always been completed on time?
    • Have users ever had a complaint?
    • Maintenance of completed projects was not time consuming?
    • Has new functionality always been a good fit in existing architecture?
    If the answers to all of the above questions are positive, then you do not need to change anything, your team is an example of a 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 means and programming languages ​​used.

    The report, using simple examples, gives an idea of ​​how domain modeling and functional implementation are different 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?
    • What is the best way to incorporate them into the project?
    • And how to convince management 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 a managerial “blah-blah-blah”, then, here’s an example of a completely technical report - functional programming, monads, and that’s all from Vagif Abilov , who’s not coming from Oslo at AgileDays - Last year talked about automated testing and TDD.

    We played with Conway's Life on the report, played F #, tried to taste the monads ... it would seem, why functional programming in agile and in general in the real world, as evil languages ​​write , who did not watch the report , write .

    On the one hand, the reasons are architectural - functional implementation provides parallelism and flexibility, compactness and verification. 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 with the mouse in Visio, but and they will be able to write integral functional specifications, either testing ones, that programmers will overload, or even shipping smart specifications into smart platforms, turning programmers off of the process.

    So, despite the fact that there seemed to be some inconsistency with the topic of the conference, the report was well received, the audience sang Monad hymns with the speakers, and the report received fifth place among all. To discuss the report with the author in the corresponding blog post .


    Yes, this year we unfortunately had fewer technical reports, because some of our traditional experts in engineering practices did not come from Ukraine, some went to management and completely opened their own companies - yes, there are almost no old programmers in Russia, only managerial career. Or not?

    Take a look and - last year's technology practice reports on Agile technology practices , and maybe you can try something new and interesting to tell at the next AgileDays - we will wait.



    So, for now, we are really looking forward to your views and comments.

    You can comment here, or on your blogs and dump it here, or, if you read it, but are not registered on the megamind (and there are usually not enough comments here) - there is a place where you can comment on the usual “Discus” link on the “additional materials” link.

    For a meaningful feedback - a thing very valuable for both authors and the program committee - we will certainly take everything into account in order to make the next conference better. Using the links you will also find the speakers' contacts, and you can discuss the points of interest directly with them.

    The video is still in beta version - errors and problems are possible: the sound has disappeared, the screen is out of sync, or you need a slide on the full screen to view small text, or vice versa - show a live screen to see where they are driving a laser pointer (I’ve been trying to train speakers for many years trackballs, styluses, and so on, which shows large markers on the screen, is written on a screencast, it doesn’t need to be turned backwards to the audience, but the damn laser pointers are still alive, and I’m forced to guess when editing something when there is something on the screen, it's so tiring). In general, if you see problems, report them too. Red-semitransparent “true time markers” are sewn into the beta version of the video - report bugs indicating this time. For all this can be corrected so far. Rather, even such problems exist right now, I found a couple myself, I wonder if you will find them faster, how do I fix them. Also, I’m thinking - maybe for very busy managers, I can make audio recordings for non-technical reports that are accelerated by 70% (for humanitarian reports, where the slides are non-critical info, you can listen to most of the information, and speed gives energy and time saving)?

    Well, of course, it depends on your activity whether it is worth continuing to deliver the AgileDays product to the megamind, or ... it is worth repotyping and doing something else.

    If, on the contrary, “not enough !, let's get it faster!” - here are more than a hundred reports on Agile from past conferences , then reports from AgileDays-2015 initially appear , and you can subscribe via RSS .

    Also popular now: