Base Company was the third Mobile Operator in Belgium and stayed within the top 3 market leaders, even today now the organisation has gone through a new change. Their IT was part of the technology department that was also responsible for the mobile network, from design to operations. Within the IT organization were a couple of hundred people, a mix of people on the payroll together with externals from several (strategic) partners. Their main integration partner was an Indian company, covered by a managed service contract, working in a strong phase-gate scenario.
Why are there so many IT people out there who have the feeling they're actually a firefighter? Why do they have the feeling to be jumping from one burning house to another? Why do they have the feeling work is driven by fire alarms? Why is it that the loudest voice in the office, the biggest fire, gets things done?
A bunch of questions I asked myself too, and there are some organizational patterns that we should consider. Once you know them, you can beat them!
Our Product Owner came up with new stories to be estimated. 14 to be precise.
It required some preparation however. We have 2 teams, and they do the Backlog Refinement together.
Around 20 people in one room, partly offshore, estimating together is quite a challenge!
Dependencies in Software Development have been an issue since decades and lots of practices have been built to “manage” them, creating an environment that becomes more complicated with longer time-to-market times as dependencies grow (or the product/solution grows).
This is creating an illusion and no dependency management is alwys the only answer! Coordination to remove dependencies is usually a more sustainable outcome with less management.
The end of the year is nearby, time for some New Year’s resolutions! As I experienced a lot of stress within the role of Scrum Product Owner, and as I know you’re busy, I’m going to help you get started…
Here are 20 New Year’s resolutions to get you started:
This blog is different from many others as the author is not really the author at all. We do not see value in telling a customer story by ourselves and as such we let them do it for us, let them explain why LeSS, what challenges and what succesthey see being about 1 year into the adoption.