Chaordic teaching or what is common between Agile and IT education
Good time, habravchane.
I want to share the observations that arose in the course of the track “Usability Engineering & Ubiquitous Computing on mobile devices”, which was held in the framework of the joint Russian-German student school JASS-2012, which was already written on Habré. However, unlike the previous post, I will describe the school through the eyes of the organizer.
In a few words about the school, or rather about the track dedicated to the development of programs for mobile devices. Three international teams of German and Russian students were assembled, and these teams faced a very difficult task - to develop a software project from scratch in a very short time. The teams were limited in time and in total the project implementation took a little less than four days.
')
The organizers had two goals. Firstly, it’s important to understand how it is possible to build effective training for students in flexible development technologies, and secondly, we wanted to understand the conditions in which teams work most efficiently. So, how was the development-learning process built and what lessons we learned for ourselves.
Initially, the organizers of the Russian and German sides came up with several ideas for projects, we discussed their details and got ready to distribute them between the teams. However, at the very first meeting it became clear that we made a mistake. Our task was to create conditions for the maximum interest of each developer in the project being carried out, and we did everything except the most important thing - we didn’t ask the participants (didn’t involve the “consumer / customer” in the development process, using the language of flexible development).
Having understood our mistake, we decided not to follow the initial plans - if we are to be agile, then to be agile in everything, and we began work on the wording of the projects from the brainstorming session.
It looked very fun. Participants were given a few packs of stickers and 10 minutes to generate the most fantastic project ideas. Each idea was recorded on a sticker and glued onto a marker board. In 10 minutes several dozens of ideas were generated. They chose a moderator, who began to read one idea from the board, causing the author to clarify his point of view and interest those present. The author of each idea had about 15-30 seconds to explain. After the presentation, ideas were ranked on the same board by the number of votes received (everyone had the right, as a spectator of a gladiatorial duel, to vote for sending the idea to the basket or for its realization).
In the end, there are some better ideas. It is worth saying that in the course of such a vote we observed a synthesis of new projects. Some ideas were so close that being combined together became just functions (features) of one more general project.
The last phase is the distribution of participants into teams. Everyone could apply for participation in any of the selected projects, but several restrictions were put forward - teams must contain at least one representative from Russia and Germany, and the project cannot have more than 5 and less than 3 people. Thus, we have created highly motivated and rushing teams.
It's no secret that the requirements are the cornerstone of software development. They are so difficult to formulate, convey to each team member and follow, follow, follow changes and changing conditions ... Lots of books that every developer (Brooks, De Marco, Spolsky, Cooper, ...) must read again and again trying to explain the nature of understanding the team of requirements, their management, the relationship between developers never bring final enlightenment to the minds of project managers and programmers.
We applied the following, in my opinion, very effective method of managing requirements - we considered the collection and development of requirements as the creation of a film. Yes, yes - a small video with a duration of 45 to 60 seconds. This video was immediately positioned as a commercial for the sale of the product. Each member of the team participated in the creation of such a video, and on the one hand, its appearance is the result of the command processing of requirements and, most importantly, the fixation of the one and only main use case for which the project is being created. Why does this work better than any other requirements management mechanism in a small team? Yes, if only because the cinematic image is not only simpler, but also psychologically more pleasant to hold in your head than a text, a set of tasks in a tracker, or another formal or semi-formal document. In fact, this is a visualized User Story, and developers do not need to make an effort to understand its meaning, since everyone took part in the creation. I would call the preparation of such a film an emotional enhancer of the perception of requirements.
Since we had a very limited time for development and training, it was decided to test several types of scrum meetings on students (the meeting was from the English meeting, meeting).
The first is collective - participants in all projects listen as each team reports on its status, blocking problems, and takes commitments. This collective form allows teams to align with each other - to correlate the speed of their project with the speed of neighboring projects. The laggards begin to accelerate, seeing that the neighboring team has more progress, and the successful ones begin to accelerate, too, receiving an injection of endorphin from a sense of success at the current stage.
The second type of meeting is project. Only one team in a dedicated quiet room without prying eyes analyzes the status. In this case, the team is more inclined to open and discuss the problems existing in the project, to find their solutions.
The third type of rally used within the school is an attempt to implement the scrum of scrum, when each team determines its own status independently and the selected participant talks about the status of the team at a kind of meta- tion. This exercise gives the feeling of how the process can be scaled in large projects.
Discussing the course of experiments with German colleagues, we were surprised to find obvious analogies to the process of training any discipline with the project development process in a small team. They remembered L.S. Vygotsky, with its learning thresholds and a zone of comfortable learning. In a nutshell, this can be described as follows.
Training and software development is a process that can be practically self-organizing if students are in a comfort zone. The lower boundary of the zone determines the interest - the presence of unsolved non-trivial tasks stimulates the brain to action - the brain likes to learn. The upper limit of the zone is determined by the maximum possibilities of the influence of the team itself. If the team encounters strong uncertainty in the requirements, or the lack of any resources (for example, in our case it was internet access, which once broke), then the project begins to slow down. In all other cases, being in the zone of comfortable learning or comfortable development conditions, the team is capable of self-organization.
We called this approach to teaching Chaordic teaching, borrowing the idea from Dee Ward Hock who, being the CEO of VISA, used such a word derived from Chaos and Order (with English chaos and order), demarcating the boundary between them, considering that innovation and discovery. And we were convinced within our school that it really works, both in the field of training, and in the field of development.
The school ended up leaving, I am sure of it, an amazing feeling for each of the participants and organizers. Three projects were developed, and they were presented at the last festive event. From all my experience I can hardly remember such projects in terms of the quality of elaboration and completeness. Let me remind you that the projects were made completely unfamiliar to the beginning of work by people who also spoke different languages ​​and came from different cultures.
I liked the idea of ​​chaordic teaching so much that we planned to make a small joint report on this topic at the next SECR conference.
In conclusion, I can not thank all the participants and organizers of the event, and in particular the Academic University, which has already been posts on Habré and which is always open for such events and experiments.
I want to share the observations that arose in the course of the track “Usability Engineering & Ubiquitous Computing on mobile devices”, which was held in the framework of the joint Russian-German student school JASS-2012, which was already written on Habré. However, unlike the previous post, I will describe the school through the eyes of the organizer.
In a few words about the school, or rather about the track dedicated to the development of programs for mobile devices. Three international teams of German and Russian students were assembled, and these teams faced a very difficult task - to develop a software project from scratch in a very short time. The teams were limited in time and in total the project implementation took a little less than four days.
')
The organizers had two goals. Firstly, it’s important to understand how it is possible to build effective training for students in flexible development technologies, and secondly, we wanted to understand the conditions in which teams work most efficiently. So, how was the development-learning process built and what lessons we learned for ourselves.
Project Initiation
Initially, the organizers of the Russian and German sides came up with several ideas for projects, we discussed their details and got ready to distribute them between the teams. However, at the very first meeting it became clear that we made a mistake. Our task was to create conditions for the maximum interest of each developer in the project being carried out, and we did everything except the most important thing - we didn’t ask the participants (didn’t involve the “consumer / customer” in the development process, using the language of flexible development).
Having understood our mistake, we decided not to follow the initial plans - if we are to be agile, then to be agile in everything, and we began work on the wording of the projects from the brainstorming session.
It looked very fun. Participants were given a few packs of stickers and 10 minutes to generate the most fantastic project ideas. Each idea was recorded on a sticker and glued onto a marker board. In 10 minutes several dozens of ideas were generated. They chose a moderator, who began to read one idea from the board, causing the author to clarify his point of view and interest those present. The author of each idea had about 15-30 seconds to explain. After the presentation, ideas were ranked on the same board by the number of votes received (everyone had the right, as a spectator of a gladiatorial duel, to vote for sending the idea to the basket or for its realization).
In the end, there are some better ideas. It is worth saying that in the course of such a vote we observed a synthesis of new projects. Some ideas were so close that being combined together became just functions (features) of one more general project.
The last phase is the distribution of participants into teams. Everyone could apply for participation in any of the selected projects, but several restrictions were put forward - teams must contain at least one representative from Russia and Germany, and the project cannot have more than 5 and less than 3 people. Thus, we have created highly motivated and rushing teams.
Requirements
It's no secret that the requirements are the cornerstone of software development. They are so difficult to formulate, convey to each team member and follow, follow, follow changes and changing conditions ... Lots of books that every developer (Brooks, De Marco, Spolsky, Cooper, ...) must read again and again trying to explain the nature of understanding the team of requirements, their management, the relationship between developers never bring final enlightenment to the minds of project managers and programmers.
We applied the following, in my opinion, very effective method of managing requirements - we considered the collection and development of requirements as the creation of a film. Yes, yes - a small video with a duration of 45 to 60 seconds. This video was immediately positioned as a commercial for the sale of the product. Each member of the team participated in the creation of such a video, and on the one hand, its appearance is the result of the command processing of requirements and, most importantly, the fixation of the one and only main use case for which the project is being created. Why does this work better than any other requirements management mechanism in a small team? Yes, if only because the cinematic image is not only simpler, but also psychologically more pleasant to hold in your head than a text, a set of tasks in a tracker, or another formal or semi-formal document. In fact, this is a visualized User Story, and developers do not need to make an effort to understand its meaning, since everyone took part in the creation. I would call the preparation of such a film an emotional enhancer of the perception of requirements.
Process
Since we had a very limited time for development and training, it was decided to test several types of scrum meetings on students (the meeting was from the English meeting, meeting).
The first is collective - participants in all projects listen as each team reports on its status, blocking problems, and takes commitments. This collective form allows teams to align with each other - to correlate the speed of their project with the speed of neighboring projects. The laggards begin to accelerate, seeing that the neighboring team has more progress, and the successful ones begin to accelerate, too, receiving an injection of endorphin from a sense of success at the current stage.
The second type of meeting is project. Only one team in a dedicated quiet room without prying eyes analyzes the status. In this case, the team is more inclined to open and discuss the problems existing in the project, to find their solutions.
The third type of rally used within the school is an attempt to implement the scrum of scrum, when each team determines its own status independently and the selected participant talks about the status of the team at a kind of meta- tion. This exercise gives the feeling of how the process can be scaled in large projects.
Chaordic teaching
Discussing the course of experiments with German colleagues, we were surprised to find obvious analogies to the process of training any discipline with the project development process in a small team. They remembered L.S. Vygotsky, with its learning thresholds and a zone of comfortable learning. In a nutshell, this can be described as follows.
Training and software development is a process that can be practically self-organizing if students are in a comfort zone. The lower boundary of the zone determines the interest - the presence of unsolved non-trivial tasks stimulates the brain to action - the brain likes to learn. The upper limit of the zone is determined by the maximum possibilities of the influence of the team itself. If the team encounters strong uncertainty in the requirements, or the lack of any resources (for example, in our case it was internet access, which once broke), then the project begins to slow down. In all other cases, being in the zone of comfortable learning or comfortable development conditions, the team is capable of self-organization.
We called this approach to teaching Chaordic teaching, borrowing the idea from Dee Ward Hock who, being the CEO of VISA, used such a word derived from Chaos and Order (with English chaos and order), demarcating the boundary between them, considering that innovation and discovery. And we were convinced within our school that it really works, both in the field of training, and in the field of development.
findings
The school ended up leaving, I am sure of it, an amazing feeling for each of the participants and organizers. Three projects were developed, and they were presented at the last festive event. From all my experience I can hardly remember such projects in terms of the quality of elaboration and completeness. Let me remind you that the projects were made completely unfamiliar to the beginning of work by people who also spoke different languages ​​and came from different cultures.
I liked the idea of ​​chaordic teaching so much that we planned to make a small joint report on this topic at the next SECR conference.
In conclusion, I can not thank all the participants and organizers of the event, and in particular the Academic University, which has already been posts on Habré and which is always open for such events and experiments.
Source: https://habr.com/ru/post/141897/
All Articles