Why Agile should not be scaled
 |
Artem Bykovets Artem is in Software development since 2007 acting as a QA and ScrumMaster. He has 8 years of teaching his program at courses & providing workshops. Artem is a winner of IT Awards Ukraine 2015 (Best QA of Ukraine). Artem helps many companies as an Organizational Coach on Agile frameworks/ approaches, actively shares experience by speaking at conferences and by providing workshops. He is a founder and producer of Simplicity Day conferences (One of the biggest in Ukraine, focused on hot topics from QA and Agile world presented by top practitioners in a simple way). |
|
Artem holds CSM, CSPO, CSP certificates, CAL-I certified by ScrumAlliance, Certified LeSS Practitioner by LeSS (learned from Craig Larman), and PSM I Scrum.org & certified KMP-I by LKU. Artem is a guest lecturer at MBA (Kyiv Mohyla Business School) and has a video channel on youtube. He is just a person who likes to share experiences and continues to learn personally. |
|
Description:
Agile and Scrum, in particular, have clearly become almost the gold standard for building software development processes in 70-80% of companies around the world today. But despite the fact that Agile celebrated its 20th anniversary in February, and Scrum celebrated its 25th anniversary last November, quite often at the scaling stage, there are very "unique" examples of adapting both the principles of the manifest and a minimalistic framework that introduces and requires only basic fundamental rules: 3 roles, one product backlog, one sprint and sprint backlog + 4 main events per team on a regular basis.
Have you ever seen when someone is a member of several teams at the same time:
"In general, he is a member of the "A" team, but 30% more in the "B" team this quarter..."?
And what about the Team that takes tasks from 3-5 backlogs in the Sprint?
And what about a team with 5 Product Owners with whom you need to agree on priorities?
And what does it all turn into when there are 5-10 teams, and even in different locations?
Unfortunately, I also happened to see various "adaptations for the uniqueness of the context," but fortunately, I managed to help such teams and organizations optimize and evolve their processes over time.
PDUs: 1.0 Technical
Learning Objectives:
In this webinar, we'll talk about:
- The most common anti-patterns that occur "in fields"
- Why they might not be the best solution to the problem we want to solve with them
- What are the alternatives to these solutions, if your company is "too unique" to take a ready-made scaling framework in the form described by the authors
- How these decisions can be reached evolutionarily, and not from a position: "I am an expert, and I know how to do it right, but you did everything wrong!"
Please be aware that a pre-registration email address is required. We look forward to seeing you there!
It is no longer possible to register for this event
