Mailinglist Archive: yast-devel (127 mails)

< Previous Next >
[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-agile/

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-to-becoming-agile-at-scale/

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@xxxxxxxxxxxx
To contact the owner, e-mail: yast-devel+owner@xxxxxxxxxxxx

< Previous Next >
This Thread
  • No further messages