Global Agile Summit 2025
#GlobalAgileSummit 2025 has begun
The Lizard Optimization panel at #GlobalAgileSummit is interesting because of the real-world examples from work.
What's interesting is that we've already arrived at a lot of this in practice ourselves, or I have.
It started with identifying what's a bug and what's a feature.
One of the examples was a complaint from a user who couldn't use the app on her fridge. At first we didn't understand what the user wanted. But then it turned out that the user had a new fridge with a big screen and Android, and she wanted to watch the meetings on the fridge while cooking food for her kids, because that's more convenient than looking at a laptop on the table that was further away.
When they optimized the app's UI for fridges, it made the app more convenient for many other categories of users, and the number of users grew noticeably after that.
The panel Breaking Bad: Creating Powerhouse Organisations Through Better Behavioral Habits at #GlobalAgileSummit was quite triggering for me personally. Because at the start it described a lot of toxic situations and behavior that I run into regularly at work. My employer pays for my courses and other things, is interested in my growth, but the biggest impact I can have is on the team I manage. Whereas my direct top manager himself does a lot of toxic things and influences me with his behavior. I'll try to apply the arguments I heard here — that micromanagement demotivates and reduces productivity, while the top manager consistently demands that I micromanage, because he micromanages himself.
It's interesting that by the end of the day at #GlobalAgileSummit I no longer had the energy to write up impressions and notes about the presentations. Being among people is very exhausting and drains your resources, and I barely even tried to socialize. You shouldn't think about socializing at events like this — there are definitely no resources for it.
So much goes into processing and understanding the presentations as it is — at least I manage that, though it could be more efficient. I see some people use mind maps for taking notes, I should look into that.
There were quite a lot of jokes along the lines that Agile gets called dead more often than Musk promises self-driving cars)
Besides that, there was talk that thanks to AI, developers will no longer be tied to teams and will be able to easily switch teams and places of work, the way surgeons do, for example. Because AI will offload the mental burden of immersing yourself in context, AI will provide the context and the setting, and the developer will only do what's required of them without spending hundreds of hours immersing themselves in the project and settling into the team.
Current AI is a tool, it can be used for good, or for something inhuman, the way Amazon uses AI to punish its workers, although I see customers get punished too.
Personally, I was just reminded of the popular story about Amazon, where one AI mistakenly issues a refund, and another AI permanently bans the customer for receiving a wrongful refund.
There was also the idea voiced that Amazon could use AI to print different versions of books depending on purchase history, since books aren't stored in warehouses now but printed when ordered.
For example, including a paragraph about Musk for those who ordered a Nazi flag, and removing it for those who ordered a rainbow one.
Overall, AI has already replaced juniors in law, copywriting, design, development.
The problem is that senior experienced workers pick up knowledge about new things from beginners, because it's the beginners who know and take an interest in what's new, and with AI that disappears.
Also, you need to have enough qualifications to check the results of AI's work, and when you use AI, your skills keep declining and eventually you no longer know whether AI gave the right result. In theory, you'd need to regularly go through certification that checks that you can verify AI's work.
In the future we're in for networks of AI, AI agents, and people working with one another, but for that the questions of memory, security, and protocol need to be solved.
I see there's skepticism about whether order can be made out of all this, or whether they'll manage in time?)
It was interesting to hear about Agile Clinics, I hadn't heard of that.
The board for experiments is also a good idea, I like experiments, could put it to use) Experiments that are short, safe, cheap.
Also, all change leaders need someone to talk to. This part is interesting — should you talk to someone who supports you, or who challenges your views and questions them, who pushes back?
Generally, do we even need to be agile and put people at the center, if Agile is dying, and the ones winning are Trump and Russian principles, where nobody reckons with people at all, and people are just a resource that gets no consideration.
Overall, I'll try to take away the important steps for a stable transformation of myself:
1. Do something for the first time every week
2. Work with people you can learn something new from
3. Remember that this is a journey, an ultramarathon, not a sprint, not a dash.
And the obvious one, that you have to prioritize your own life, balance it with work, do the things that are enjoyable and that recharge you specifically.
The presentation Building a Successful Agile Team in a Waterfall Company and How to Scale It at #GlobalAgileSummit turned out to be quite interesting
An interesting account of how they developed and added a dating simulator to the looter-shooter Warframe.
Essentially, online games work on Agile principles, because the player doesn't stop playing them but keeps getting something new.
The developer company itself didn't work under Scrum, and a few years ago there was a big failure when they tried to switch to it, so it wasn't possible to apply it in developing the expansion.
It was interesting to hear how the process was organized purely in Slack without meetings, there were no meetings at all, even though the work was done remotely from different parts of the world.
For developing the dating feature there was an open channel in Slack, where the summaries of discussions were pinned, and then at the end of the week unpinned after the summaries were written up.
The main thing was putting people over processes and full trust in the team, so that it would self-organize.
You have to find an individual approach to your subordinates. Open up the shy ones, so that they express their vision and then work effectively according to their vision.
Also keep in mind in Slack that someone replies during working hours, while someone else will react to a message in the middle of the night on a day off, and for those you need to send scheduled messages. I forget about this myself, because I'm trying to reach a balance and decide whether to react to messages right away or during working hours, while some people always react and act regardless of the time.
Also a good manager is always watching and aware of everything, but doesn't interfere, waits to be asked.
For example, the women were against highlighting which answer option in a dialogue is correct after it's chosen, while the men insisted there should be a reaction when the right option is chosen in a dialogue on a date.
Here they had to turn to the manager, and even though she's a woman, she made the right decision for the business, because 80% of Warframe players are men.
This is an example of the danger of self-organized teams, when in 1 out of 10 cases such a team makes the wrong decision.
I found the time and energy to write down thoughts and notes about the last talks of #GlobalAgileSummit 2025.
The presentation Can the Elephant Arrive on Time? wasn't dense and concentrated in detail on just one question with various examples.
In the newly created technical support team of a startup, we went through these mistakes, though now I have a different problem, which I'll cover at the end of the thread.
The main example of the talk is a road filled with cars. If there's no free space on the road, then the speed of the flow drops to zero, even though in theory everyone could be moving.
The same goes with completing tasks on time. If you don't leave gaps in the plan for unplanned tasks, then all the tasks will be completed late.
Now the developer-side panel from Atlassian called Developer Joy: How Great Teams get S%*t done at #GlobalAgileSummit was dense and packed with topics in the same amount of time as the previous business panel, which stands out even more by contrast.
It all started with the question of who uses JIRA, most of the room used it, and when they asked who likes JIRA, a few hands went up. The speaker noted that they should probably talk to those people, to fix whatever it is they like about JIRA)
These days a developer has to use a pile of different services, which creates a big mental load that didn't exist 10–20 years ago. If you look at how productivity was achieved in the times of the industrial revolution, it's worth noting that a developer's productivity isn't the productivity of an unskilled factory worker. Developers love to craft.
The first of the big things they noted was that there should be a code review culture. Previously in the Confluence team it took an average of 3 days to review code. This was improved by having the team lead remind the responsible people to do the code review at the start of the workday, then this was replaced by a bot that automatically sent reminders at the start of work if a review was in the queue. As a result, the average review time was cut to 1.2 days.
I'll add personally that I myself love making reminders like this. And it bothers me that the manager has a negative attitude toward this, that supposedly I should spend my energy and remember a million things that I'm supposed to do myself, rather than making bots that send reminders. A strange approach, in my view.
Also, ideally teams should be autonomous, every developer team should have its own QA, but in practice at Atlassian it's 1 QA per 30 developers. After this I realized that things at my work aren't all that bad, and why JIRA is so JIRA.
At Atlassian they improved this by tasking developers with testing more, if developers test it themselves and their task doesn't get stuck at the QA stage, then this raises developer satisfaction. The question remains that a developer can't foresee everything, especially if they wrote the code themselves, but when there isn't enough QA, then it's better this way than an overloaded QA who doesn't have enough resources and attention.
I'll add that in my support team we've long since started testing each other's fixes, though we then hand it over to QA and it sometimes gets stuck there, but it's an interesting idea to make this part of the process. Although not everyone enjoys testing someone else's code, while you're already too close to your own code.
There was an interesting example that everyone has probably run into, that you need to clarify the end goal of a task. For example, the manager asked for a data export into a table, then it turned out they needed it specifically in CSV, and then it turned out it was needed for transfer to a CRM, when the CRM has an API and you could just do the transfer of the data through the API.
Also an interesting idea, that when presenting new functionality, the developer records a demo themselves and makes the recording available to everyone, instead of holding a meeting with everyone, and then in Loom each viewer can leave comments and start a discussion.
I really liked this part, because I'm an analyst, I analyze everything deeply and slowly, but I'm expected to instantly react to a demo and ask questions and I'm constantly criticized for being a bad manager because I don't ask questions at the demo. Now I'll have something to propose in response to the criticism.
Overall you need to look at what's important for the company and measure that, track the metrics, usually it's 4–6 metrics.
Then they went on to say the thing that we've arrived at, what we have: that you need to check the metrics weekly and discuss them, understand the reasons for changes in the indicators. It's normal for something to dip when there are corresponding reasons for it.
At Atlassian there's one shared metric for all teams — it's how much time the team spends on developing the business, changing it, and how much on support. Their goal is 55% new and 35% support, and 10% on developer satisfaction. During the period when they needed to raise developer satisfaction, the latter had a target of 20%
It's clear that different teams are different and have different priorities, I've got a support team over here so a lion's share goes to support.
Also at Atlassian a developer survey is conducted every month, to fix things and improve the team's work, at first the surveys were monthly, now every two months. The survey results themselves are publicly available. The survey is also an interesting idea — I'll need to study all of this on the Atlassian site.
