[yast-devel] A multi-billion company living SCRUM?
Moin, Today I came across these two great articles (see below) about SCRUM in a really big company, they've been developing in this way for 4-5 years already. I've quoted some parts of these articles, maybe you find it interesting. As we are going to have new retro meeting next week and plan new sprint after that, we might try to "get inspired" by these articles. http://www.forbes.com/sites/stevedenning/2015/10/27/surprise-microsoft-is-ag... There would be two distinct phases: a coding phase, and then a test-and-stabilization phase. They would have a big celebration at a milestone which they called “code complete.” They would hold a big party, because it was a big achievement. It was when they moved on to testing and stabilizing and delivering the beta version of the code that the trouble started. They would find an unexpectedly large number of bugs in the code. And they kept discovering more bugs. They would also get feedback that some of the features they had built were not quite right. What they hadn’t realized in those celebrations at the end of the coding phase is that they were actually sitting on top of a mountain of unresolved quality problems. They had no idea that instead of a huge achievement, they had just incurred a massive amount of technical debt. If there is a problem, the team fixes it if they can. If they can’t, they just don’t deploy that feature. The team decides. The team does its own stress testing and documentation. http://www.forbes.com/sites/stevedenning/2015/10/29/microsofts-sixteen-keys-... The team is talking about the issues and discussing with the managers and reviewing what they have learned. In every sprint, they are taking a fresh look at things from the user’s viewpoint. Of course, if you ask an engineering team, as Aaron does, “What does leadership make you do that is slowing you down?” he gets a ton of stuff, not just one or two things. They often pull out a whole scroll of issues. They were just waiting for him to ask! They tell him everything he’s doing wrong and they have a conversation. The point is that the conversation takes place and it’s a safe conversation to have. Continuous delivery has meant more modularity in design and a change in architecture. “In the old days,” says Aaron, “when the code had been written, the team had a party. They were celebrating. They felt they had accomplished something. But in reality, they were sitting on a mountain of bugs. In fact, they hadn’t even found all the bugs. Now they had to go back and find them all. And fix them. And they were still months away from delivering software. It was a nightmare.” “Now the bugs never grow. There ‘s a Key Performance Indicator (KPI) we call ‘the bug cap.’ It’s the number of engineers on your team times four. So if you have ten engineers, your bug cap is 40. If you get to 40 bugs, the team needs to stop work on new features and the next sprint, get the bug count back down below 40. It’s self-managing. Teams know this. It means that we can ship product all the time now, because we know we’re always in a healthy state.” The sales teams hooks the developers up with customers. The program managers talk to customers on Twitter all the time. Get good at the science of Agile and Scrum but don’t be overly prescriptive; Don’t copy others: learn from others; Stop trying to predict the future; Optimize around customer feedback. Maybe I've spoiled the whole thing by quoting these parts, but hopefully not. Also please, don't take these as "those that are the most important for Lukas and we need to argue" ;) These are just "interesting" for several reasons. Happy reading & Have a nice weekend Lukas -- Lukas Ocilka, Systems Management (Yast) Team Leader SLE Department, SUSE Linux -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
participants (1)
-
Lukas Ocilka