Yesterday I have visited an IT Spring Conference. It’s the largest annual conference in Belarus on Agile methodologies, project & product management, Software craftsmanship and software development practices. The usual audience of this conference is Scrum-masters, team leaders, managers, HR specialists, etc. This year there were 3 flows at the conference with self-speaking titles: “Agile at Scale”, “Team Coaching and Facilitation” and “Engineering Practices”. Here is a short summary on reports I have listened to and the key ideas I have learned.
“Johnny – the developer, which is not promoted” by Eduards Sizovs.
This lecture is quite different from all the other topics presented on IT Spring this year because it’s oriented toward Software Engineers, not Scrum-masters or managers. But this report impressed me strongly, so I’ll describe it a little bit more than the others. The author explained why a lot of good Software Engineers get stuck at their positions having minimal salary increase from year to year and facing constant ignoring by their bosses. The key answer is that these engineers speak to their chiefs the wrong language. Bosses don’t actually want to hear about Test-Driven Development, Software craftsmanship and other programming stuff that developers learn. They just don’t understand this language. The best way for a software engineer to prove his excellence is to be customer oriented, speak the language of “customer’s value” and just quietly use all cool technologies and practices he learns to produce more reliable software in shorter terms than his peers do. Then, when asked about the root cause of his success, he can share his knowledge about best development practices that help him to outperform his colleagues. But doing it in first place without showing real results is just a waste of time and energy not mentioning others who might consider you a jerk and upstart.
Another interesting idea of this lecture is: “It doesn’t matter how “Senior” in the company you are. It’s a local measure”. The author argues that every Software Engineer should validate his seniority at the company against the rest of the industry. The title of “Senior Software Developer” should not calm you down. You should constantly evolve and educate yourself.
“Cultural change that sticks” by Victor Podzubanov.
The author is an Agile Coach and he shared his experience in solving specific problems in a large distributed project that works by Kanban. The problems discussed are:
- Communication difficulties with colleagues from China who don’t speak English.
- Numerous Product Owners who cannot agree on feature priorities.
- Problems with employee involvement.
- Basic process flaws (lack of Retrospective meetings, showcases, etc.).
- Difficult and painful integration with backend.
- Huge number of In-Progress stories.
From this report I liked the idea of Product Area Owner. It’s a Product Owner that coordinates the work of several other Product Owners in some specific area of the product. Of course, it’s applicable only for huge products that have multiple Product Owners who can’t reach consensus in priorities of their User Stories. In spokesperson’s example there were 17 Product Owners and coordination problems were solved by reducing this number to about 10 and adding a Product Area Owner position.
“How to make Agile products in big companies” by Vladimir Gorshunov.
The author is a Senior Technical Program Manager in Amazon and he told us about the integration of the Agile program management in this company. Studying the experience of such a huge and successful company like Amazon really impresses. Vladimir came up with the following key success factors:
- Senior Management Support
- Community of Practices
“Solution to 5 practical cases caused by the scaling process. SAFe implementation Experience at Fitbit” by Anna Barzakovskaya.
Anna shared Fitbit scaling experience when company grew up from 2 to more than 1200 employees. She listed five major problems they faced during this growth and told how they overcame these difficulties. The described cases are:
- Control and elimination of dependencies between teams.
- Teams efficiency in terms of multiple teams.
- Continuous improvements.
- Keeping business priorities.
- Increasing transparency.
“SW Development for Financial Institutions: you have to do it right, or why banks not always can be agile!” by Werner Klomfar.
The author explained why Banks do not incorporate Agile methodologies in their Software development process. It turns out that Agile approach is inconsistent with Banks reality that includes:
- Fixed budgets and fixed timelines.
- Many things are changed in cycles (yearly updates, rulebooks, etc.) at fixed dates.
- Responsibilities are shared over different departments (business, process owner, development, operator, etc.).
- Solution proposals which cannot be changed during implementation.
- Existing application complexity and infrastructure.
- Tests have to follow clear definitions and must be auditable and comprehensive.
Then the author contraposed FinTechs to Banks: “Banks might never really be agile. FinTechs have to be Agile!” FintTechs are different because they:
- Focus on single needs vs. full service retail banks.
- Develop systems based on feedback from users.
- Focus on short time to market.
- Use interfaces and partnerships to handle non USP-relevant things.
- Leave the dirty work to “old” market players (e.g. clearing, compliance)
As a result, FinTechs challenge the Banks and force them to reconsider their business processes and value chains.
After this lecture the statement of German Gref, the head of Sberbank of Russia, that all banks should transfer to Agile methodologies, sounds really funny.
“Scaling Product Company the Agile Way” by Timofey Yevgrashyn.
This is the topic I was interested most of all. The author described Agile scaling approaches and challenges that arise during this process. There are numerous Agile scaling frameworks, like Scrum-of-Scrums (SoS), LeSS, SAFe, Scrum at Scale and others. In this lecture SAFe was discussed. Timofey listed four key factors in Agile (that he called “Heart of Agile):
and explained how these activities transform in the SAFe.
“Leading the Lean-Agile Software or Systems Enterprise with SAFe®, the Scaled Agile Framework®” by Michael Stump.
The last lecture continued the discussion of SAFe. The author described nine Lean-Agile principles:
- Take an economic view
- Apply systems thinking
- Assume variability; preserve options
- Build incrementally with fast, integrated learning cycles
- Base milestones on objective evaluation of working systems
- Visualize and limit WIP, reduce batch sizes, and manage queue lengths
- Apply cadence, synchronize with cross-domain planning
- Unlock the intrinsic motivation of knowledge workers
- Decentralize decision-making
Michael also described different levels of SAFe introduction. He told how organizations could start from simpler SAFe processes and add complexity when (but not earlier) required.
In conclusion, IT Spring 2016 has been a great conference with a bunch of interesting topics presented. As usual, such conferences do not give you step-by-step recipes but show the current tendencies in the field and provide great source of further self-education and studying.