Is SAFe Evil? • Henrik Kniberg & Lars Roost • GOTO 2015
GOTO Copenhagen 2015 · 48 min
Vídeo: https://youtu.be/TolNkqyvieE
Transcrição automática do YouTube (inglês, legenda gerada automaticamente). Timestamps em [mm:ss]. Erros de reconhecimento de fala não foram corrigidos (ex.: "safe" = SAFe, "lass" = Lars, "shoe" = Shu, "conbine" = Kanban).

[0:02] [Music]
[0:11] so hello everybody I'm Henrik and I'm lass and I am a consultant part-time at Lego in Bon I live in Sweden but spend
[0:18] some time there and I'm last I work at Lego uh normally I've been there for two years I have the pleasure of having
[0:24] Henrik with us a week every month or so and uh I work with digital markeet
[0:30] and that's where we get to play a lot yes and we are on a very interesting journey and we'd like to share some uh
[0:36] experiences with you um and the course the topic today is is is this right and you're all waiting
[0:42] for the answer right all waiting for the answer and we're just going to cut it short and just give you the answer so
[0:48] are you ready got your notepads right
[0:57] okay oh no no no wait that was the wrong one okay here comes the the real
[1:04] answer so say fash nope nah right thank you very much thank you you're good
[1:12] [Music] [Applause]
[1:18] yeah so I think we're early yeah we made up the time maybe we
[1:24] have time for questions should we do questions or they're they're still sitting here elaborations question you want us
[1:31] to say something more you're not happy with this answer okay okay let's let's
[1:38] try something okay be difficult
[1:43] um yes that's it woohoo this is a tool this is another
[1:51] tool yeah any favorites anyone has a favorite tool Hammer I like Hammer who likes Hammer best hands up Hammer pretty
[1:57] much does the job no no no no saw who likes sace best nobody likes sawce sauce
[2:03] are evil yeah the these are tools right tools are neither good nor evil right it
[2:08] depends on what you do with it my three-year-old had one of those that was evil even the most uh even the most
[2:15] innocent tool can hurt right even most innocent
[2:21] things can be used in a way that hurts you so we look at safe as a uh it's a
[2:26] toolbox right it's a toolbox safe as a toolbox there's a bunch of tools in there you can use tools to hit yourself
[2:32] in the foot or you can use tools for valuable stuff right so no we don't think safe as neither evil nor good or
[2:38] anything else right so maybe we should talk about what what this is yeah why right um this
[2:45] is scaled outter framework any questions it's fairly self-explanatory I
[2:50] assume right now this is the picture you you see when you go to the scale ADW framework site and it's kind of scary
[2:55] right it's like oh big scary big um so we hope to decode this a little bit B and here is the uh very short much
[3:02] shorter version of it or the shorter version of the description um you know the agile thing
[3:07] right it's like an umbrella it's a bunch of great ideas and then there's a bunch of concrete methods that are um that
[3:13] Implement these principles well safe is just another one of those Frameworks that tries to be agile although it
[3:18] encompasses scrum and XP and other methods right that means nothing let's get more concrete um really short really
[3:26] really short in five minutes okay summary of safe safe is assumes scrum at the team level it just assumes people
[3:32] are doing scrum right so it's an agile framework that ass assumes people are doing scrum at the team level and that
[3:37] they have product backlogs although safe calls it team backlogs which actually is a probably a better term right yep um it
[3:44] assumes stories that are supposed to be testable it assumes Sprints that are two to three weeks typically at Lego we do
[3:49] two weeks and it doesn't say much more than do scrum now if you're doing scrum then
[3:56] what safe does what safe adds to the party is this second level called a program level um it basically raises the
[4:02] abstraction level level a little bit and provides some guidance as to well what if we're doing something bigger so it introduced the concept of a
[4:09] team of teams which for some bizarre reason is called an Agile Release Train very confusing but actually it means the
[4:15] team of teams it's an organizational unit right so this team of teams is called an an an art Release Train um it
[4:22] introduces a notion of a program backlog which is pretty much just like a product backlog or a team backlog but at a higher level so here we have features
[4:29] and instead of stores they're just bigger things that's all we mean things that are too big to fit in a Sprint they
[4:34] should be releasable testable uh customer valuable and then um just like you have Sprints that are two weeks uh safe
[4:41] introduce the concepts of product increments which is just a series of Sprints so you take a team of teams uh
[4:47] high high level backlog and you string together three or four Sprints and then that's pretty much the the the program
[4:53] level and safe right so higher level planning um nothing in safe is really
[4:58] new it's just recog izing kind of patterns that people are using and putting some words to it then there's a third level which is
[5:05] really about interfacing with the kind of more corporate side of things with how we do budgeting How We Do portfolio planning say provides some guidance as
[5:12] to how to do that won't go into details but it introduced Notions such as portfolio conun system um ideas such as
[5:18] epic which normally an agile epic just means a big story here they're a little bit more specific and say that an epic
[5:24] is like a mini business case it's something that you might never even finish an epic it's just uh area in
[5:30] which we're we're doing work so think of Epic as as a factory that generates features and a feature is a little Factory that that kind of generates
[5:36] stories so three different uh lenses that you're kind of wearing when you're looking at the world does that kind of make
[5:42] sense because this is buried in hundreds of details but the underlying core idea and safe is pretty much this and it's
[5:48] nothing really strange a lot of companies do this anyway uh safe or not um so the idea of two-tier planning
[5:54] is kind of fundamental in any kind of complex scenario where we got multiple teams building something big
[6:00] you need to look further than just one Sprint at a time so safe gives a little bit of the how you might do
[6:06] that um another idea or more like a Mis misunderstanding a common source of misunderstanding is that oh and safe you
[6:11] got these big batches right you got to work two months and then deliver something huge at the end no that's just a misconception um we have this longer
[6:18] cycle here this cycle that's just a planning cycle so you can uh release
[6:24] have release cand you can do continuous delivery and have release candidates all the time you can do release when when whenever you want so the idea and safe
[6:31] is not we should batch this up the idea is just uh plan and Cadence but release release on
[6:39] demand so that's it that's the theory part now you know everything well okay some parts of what you need to know
[6:44] about safe let's give you an example yeah so just pretty much like going to mass um the devils in the detail and
[6:52] stuff kind of gets more complex with it skills um so uh let's uh let's spend
[6:57] some time at looking at how this actually looks at Lego uh I really like pictures there'll be a lot of pictures F
[7:04] wow yes we made up already um not as awesome as the ones from us but anyway
[7:09] here it goes so let's start with this so the core of the thing is really that two two tier level planning um and the
[7:16] biggest change for us Lego has really been introducing that second tier of an 8we program increment um we kick those
[7:23] off with the a planning event and that's what I'm going to talk to you about um this is the rough agenda for such an
[7:30] event uh don't look at all the details what you really should take away with you here from this slide is it's
[7:36] happening uh every eight weeks there's a lot of kind of like this going on that's all the blue stuff and there's a lot of
[7:43] Team breakouts Sprint planning is kind of activity that's the yellow ones and
[7:49] then there's some icing on top of it management meeting when everybody has left so um how does it look pretty much
[7:57] like this that's large right there Y is um it's a two-day event it's for us the
[8:03] last time 140 people gathered in one big room and it's a lot of experiments still
[8:09] going on but also leading up to it ending looking like kind of like this uh in the beginning this is out looked that
[8:16] was more big is um we had a two little room two few chairs two few seats um
[8:24] really didn't even time it with the releases and stuff uh um but it was a
[8:30] great start so so there's um in order to kind of get these things started like
[8:36] today um we need to kick this off right if you have 140 people sitting a room want them to do planning look ahead you
[8:43] kind of get to have them in the mood so what we start with is looking back so what's what's brought us here um so we
[8:49] kick off these today's events with having our Senior Management kind of making some general statements about so
[8:56] how did it go um where we at um and we we we mix that up with some data uh for
[9:02] the teams giving them a foundation on to build where where we should we go what
[9:07] we we have um and then um also partly
[9:12] because it's Lego and we're doing a lot of cool stuff we show what we've done so we let me see sound doesn't really work
[9:19] so I'll I'll experiment here [Music]
[9:26] yeah make
[9:32] so we pretty much make a little video showing what uh what we've accomplished what has been pushed live throughout the
[9:38] previous cycle and yeah yeah just some highlights not everything no um and this
[9:45] is kind of this is what we start with um when this is done the Looking Back part is done and uh we start at uh um
[9:53] preparing the teams for doing uh planning so um most of the cases where
[9:58] people play safe it's a lot of teams building one product so it's about
[10:04] setting a vision for that product it's about giving information about that product that's not the case for our uh
[10:10] in our situation so digital solutions that does uh digital marketing at Lego
[10:15] we were 14 teams when we started this we're 21 teams by now and we're not building one product we're building a
[10:22] lot of different experiences uh released on a lot of different channels uh we're doing that with the teams uh building on
[10:29] shared components shared backend services but adding a lot of different stuff on top of it and we're doing it in
[10:34] an environment where teams constantly are changing the relationships with whom they work together so that's the
[10:40] complexity that we try to help the teams uh grasp where foro planning and we do
[10:46] that with a lot of lightning talks so safe doesn't say anything about lightning talks uh it's been some of the
[10:52] things that emerged um while we took off of this journey um so we have lightning
[10:57] talks about high level priority for the biggest of the experiences that we're going to work with in the upcoming
[11:03] program increment we have lightning talks about architectural stuff um we're doing something with Lego ID you really
[11:09] all should be aware of that stuff is changing your architecture and you may be affected with it um but we also take
[11:15] the time to um talk about things that affect our teams that they don't really think about um so it's stuff like
[11:22] digital child safety it's Global insights changes in uh privacy laws around the globe so all kind of topics
[11:30] that are related to planning um that the team should think about or be aware of when when looking ahead doing the
[11:37] stories um and we also do again spend some time looking inwards and hey we have this hackathon event coming up um
[11:43] make some time for it uh would be cool if you participate um that's um as I
[11:49] said is a result of experimentation so we do spend uh quite a lot of time throughout these events also to gather
[11:55] uh feedback from all the teams participating so we have feedback board just giving us instant feedback on not
[12:02] as fancy for the app here but anyway um so how should this evolve how should it look next time and these events rarely
[12:10] look the same from time to time so we've done it five times now and it's been really really different each time um
[12:17] it'll be different next time as well um so this is a picture from um from the
[12:22] breakout sessions so when we had the first day started with a lot of from the stage talks uh like this uh we have to
[12:29] launch and the team start breaking out uh into actually looking ahead for the
[12:34] for Sprints so they do kind of Sprint planning like they would we still have Sprint planning um so this is bit more
[12:40] high level and uh it's a bit more outward facing so Sprint planning you really look at your stories you really
[12:47] want to get it n what you to do in the upcoming Sprint this is just as much um
[12:52] looking uh towards all the other teams looking at what changes do we expect uh who do we expect to work together with
[12:59] so the teams will talk with each other um both about dependencies but also about figuring out if we can help help
[13:05] each other um and since this um this takes up about half of the first day and uh it
[13:12] takes up about half of the second day as well that's quite some time and since we have 21 teams they don't all need the
[13:19] same kind of time to plan some will be finish early some will finish late um in general the thing goes L to feed you can
[13:27] do whatever you like at these events um we expect you to deliver a result by the end of the day we expect you to stay at
[13:33] the venue because somebody else may need you but basically in the meantime in the breakout you can do whatever you like
[13:40] that does the job um so that's some kind of things that we do in order to support this uh
[13:47] this event first of all is even though we don't build one product we do have some major products that are come out
[13:53] experiences and for those there's a backlock going into the event so the teams uh each have a prodct owner that
[14:00] prodct owner will be have been part of maturing work going into the event but
[14:05] at the event they kind of pull the stuff that uh that they want to work on so this is this is a program backlog with
[14:11] features that it's that second level we talked about yes um we experiment with that a lot so currently it's a a digital
[14:17] version um it kind of works also yeah you can do that with most tools um but
[14:24] again it's it's it's been a experience kind of building on to going getting
[14:29] here um that's not so new um maybe new uh what what the teams need to deliver
[14:36] by the end of the event is basically this one it's a team board um stating uh
[14:41] PR objectives high level intent of uh in business terms of what the team wants to accomplish throughout the next two
[14:47] months uh some stretch objectives uh of course some risks um and then they they
[14:53] are free to kind of put in the main user stories on these boards these sports are taking with the teams home so it works
[15:00] as a visual uh rad information radi both what the team is doing but also at the event kind of to share them with each
[15:07] other have something visual to talk about um this is a filed out one so you
[15:12] see here they they've added all kinds of information also about load velocity
[15:18] um basically high level plan for each Sprint what the what are the kind of business level objectives you want to
[15:23] achieve and then some risks um just a high level picture of what this team is going to be doing yeah well typically the first one is pretty detailed the
[15:29] rest not so much yeah um things can are allowed to change within reasonable limits um another thing we we really
[15:36] have grown uh grown really happy with is the program board so basically it's a big piece of paper we have the Sprints
[15:43] down here we have all the teams as columns here and as soon as a team uh
[15:48] identifies dependency to another team they get together in front of the both they talk about it and they put up
[15:54] sticky notes kind of indicating well here we need to work together or here you need to have something done before
[15:59] we can start doing our stuff um this grows a lot um which is cool uh it's
[16:05] about 4X 2 m or so um and it's really awesome both for the teams to work with
[16:11] on the event but also for me as program manager coming back home um con
[16:16] recognizing pency so you you'll probably see somebody here having really a lot of dependencies to them um dependencies are
[16:22] from yellow to Red so this is this one and here's some teams who will be pretty independent this upcoming program end we
[16:30] we really hope that this way would help us kind of structuring the event so that we wouldn't have to bring everybody every time but it turns out that
[16:37] dependencies really change from uh program to PR we like to think of this as kind of a uh a a centralized tool but
[16:44] it's it's a centralized to tool to enable a decentralized behavior so thanks to this we don't have to have
[16:49] some genius to figure out all dependencies instead people can kind of self-organize yeah it's really been been
[16:54] limiting all the the overhead done outside of the teams kind of trying to figure this out uh for them in instead
[17:01] of self having them um it's something that we also use uh during the program inment so we we take with with us back
[17:08] and we have our scrum scrumps a couple of times uh each week in front of it uh keeping track of what the stuff uh
[17:15] develops as we as we thought it would um putting up new dependencies removing those that weren't there anyway um yeah
[17:23] and all the typical SC scrum stuff um another one we use is the is a risport I
[17:29] mean the concept of roaming resolve own accept mitigate risks is is is not new um but at least many places I it's it's
[17:36] not something that agile teams uh use a lot at some may um but but this is uh
[17:42] our attempt uh to kind of get them to work with it uh during the event so having agile teams actually think about
[17:49] what risks uh do we see um getting it up as posted involving the immediate management kind of to find a solution
[17:55] right on the spot uh and also keeping track of stuff that that hasn't been able to to resolve been been resolved so
[18:03] by the end of the day um they all all team was will have a a board the team
[18:08] board I showed you and uh safe says now you do a draft plan review so everybody gets to hear everybody's uh story about
[18:16] the draft plan that doesn't really work for us because we have a lot of teams that doesn't necessarily work on the
[18:22] same stuff so that was a really boring hour um instead um what we do is uh have
[18:29] up put up the boards around the room have one from each team stay back uh to be able to present what the what the
[18:36] what their plan is and have everybody else uh give them the opportunity to circle around and talk to what team they
[18:43] think will be most interesting um we structured a bit so there'll be four rounds the first two with 10 minutes the
[18:49] second two with five uh that seems to be a good balance um but pretty much
[18:54] empowering the teams to figure out what they think is important without trying to to micromanagement so basically we we
[19:00] learned that nobody wants to know everybody else's plan but almost all teams want to know some other team's plans the
[19:07] balance so once this is done the first day is pretty much done the teams can go home uh sleep a bit on the plan before
[19:12] coming in on the second day and uh since we have all this visual information the risk Sports the program boards the the
[19:20] plan uh the the backlogs for some of the major experiences um it gives us a pretty unique opportunity to bring in
[19:26] Senior Management and go through risk boards go go through program board go through the backlogs uh having a product
[19:32] owners just say well this I don't see any problem here where I don't have any risks that need to be escalated um I'm
[19:38] pretty okay with what has been pulled from my backlog until now and kind of just um in little less than an hour go
[19:46] through the the top things from the first day um and the great thing about this other than creating some
[19:52] transparency visualization upwards is being able actually for management to get back to the teams on the day uh on
[19:58] the start of the second day and we give back to them what they think are we on the right track is there something that
[20:04] we need to to look more into and especially also so you raised this impediment this risk was really uh
[20:11] painful for you we've done something about it or at least we've put found somebody who's who's going to take a
[20:16] care of it and that I think is is really powerful um about doing this as a two-day event pretty much this the
[20:23] second day is is straightforward there's more team breakouts like the first day
[20:28] um um we have a final plan review and final plan feedback part here we still
[20:33] kind of keep to the the old way of doing things so everybody will hear everybody's plan um this is one of the
[20:40] things that will change because it doesn't yet work for us um of course have a confidence vote also something
[20:47] that I think we're going to change um voting your giving your confidence and stuff that you're not involved in not so
[20:54] energizing um I say and again we don't we take the opportunity to learn from
[20:59] this so the event concludes with a retrospective where the teams do retrospectives on their own and we have
[21:05] the scrum Masters coming in and kind of collecting the data from all teams um into one big Improvement backlog uh both
[21:12] having some data on how they find that this works for them um it works okay I think yeah up there this is basically
[21:19] that's really really happy not so happy yeah so we got most people are fours and fives nowadays some some still hate it
[21:25] but but usually their feedback is very concrete it's stuff we can do things about so what what we what's good to see about
[21:30] this is that generally speaking people seem to like the idea of this type of event the devil is just inside the
[21:36] details yeah so um yeah so the question is is
[21:42] this safe or not are we following the rules or not and the answer is who cares right um because I don't know how many
[21:50] of you follow the building instructions when you build Lego how many of you sometimes
[21:56] don't did you see it did you take a photo of that yeah caught that right okay yeah the thing there's a really
[22:02] useful model just a little bit of theory again let me just check how around time bit behind which should be cool so
[22:07] there's a very useful model called shuar from Japan um it's basically describing different stages of learning and I find
[22:14] it really useful when talking about processes um when you at the shoe level you're basically following the rules um
[22:20] if you're learning to ski you're probably doing something like that right because why because the teacher tells you to it's not giving you any Theory
[22:26] they're saying do like that do what the teacher says and why do you ski like that in the beginning well because it's
[22:32] fairly safe it'll get you down the slope right without dying probably so when you're at the shoe level you don't want
[22:38] someone to give you Theory and options and background you just want someone to say just tell me how to hold the goddamn golf club or whatever it is you're
[22:43] trying to learn right give me the recipe um at high level you're kind of beyond that I kind of get it I can get down the
[22:50] slope now I want to find my own style I want to combine different techniques I want to move faster take some risks
[22:55] right when you're at the high level you don't want someone to tell you exactly what to do uh instead you want to look
[23:00] at different toolkits for example and you want to experiment a little bit and at the real level you don't need
[23:06] rules at all that doesn't mean you're really really awesome it just means that you're at the point where right now you don't need someone you don't need to think about rules so probably most of
[23:13] you are at at the read level when you ride the bicycle right anybody here think about rules and techniques when you're going to ride the
[23:19] bicycle probably not maybe if you maybe if you're going to start uh competing on bicycles you might jump back to the shoe
[23:25] level for a while to get better right but generally speaking this is a useful model because when you take something like
[23:30] safe um you need to think about what at what level are we do we have a basic functioning scaling situation today then
[23:36] maybe you don't need to just go by the rule book however if you feel less confident and you want to you don't and
[23:43] and you you want you want to use like a recipe a you want answers you want someone to tell you what to do then shoe
[23:48] could be very useful so basically if you take shoe level scrum Sho level XP Sho level conbine a Sho level safe they're
[23:54] all pretty good they're not bad but they're not awesome right so take the
[24:00] shoe level it'll get you going it'll get you down the slope but then start breaking and tweaking the rules so we started pretty much at at
[24:06] Shoe Right uh doing by the book doing this right shoe level scaling and then we quite quickly started tweaking and
[24:13] take taking away stuff we didn't like keeping the stuff we like and now we're kind of in some I would say more A hot State we're experimenting a lot yeah and
[24:20] whether or not what we're doing is officially safe it doesn't really matter I would say mostly yes because we're doing most of the stuff in safe but in
[24:26] the end a year maybe it won't even be recognized able okay so yeah a little bit about our
[24:33] actual Journey how we got into this so so why did we end up where we are um
[24:38] when I when I when we started to work with this about a year ago um we well probably heard about Lego it
[24:45] grows a lot um it has been has done for quite some years and it hopefully will
[24:50] do so for some years to come yet um so so stuff just grows and it gets more and
[24:56] more complex and we had a hard time of keeping up um so we had something
[25:01] working at the team level um that scrum thing it kind of worked um so so we
[25:07] really wanted to focus on Simplicity and that collaboration that we have in the teams and try to see if we could bring
[25:13] that to to all the stuff that was happening around the teams um so Team
[25:18] Works um all that stuff around it not so much so what do we do with we have a lot
[25:23] of teams um so we're looking for inspiration and there are definitely a lot and this is not even coming close to
[25:30] being a complete map um of of Frameworks um sources for inspiration on how to
[25:37] scale edgile beyond the team level um now we used um we used the the tools
[25:43] metaphor another metaphor is uh mostly because I really want to show this picture uh is recipes so so we were
[25:49] looking for cookbooks with recipes that we could use uh and saves definitely a
[25:55] really thick cookbook um a lot of good ideas um but but um I I want to
[26:02] highlight a couple of them uh though so so we had we had teams uh some of them
[26:08] using scrum some of them using Canan um and we have a portfolio process running
[26:13] in Lego it's not just for digital stuff it's for all of Lego so it'll if impact
[26:19] uh Logistics and operations and product development all that nonone uh yet digital stuff at uh at Lego but but what
[26:27] we didn't have is this middle part that thing between the teams and the
[26:32] non-digital uh portfolio process and and actually the concept of having that and
[26:38] the picture that kind of conveyed that idea to uh those we needed to convince to get started on this journey um and
[26:44] also the way it does it actually gave us a lot of uh of great inspiration uh so we haven't done all of what's in here um
[26:52] we don't have a formal release Management Group and all that kind of stuff um we have some of them what made sense for us uh we do have a syst
[26:58] systems teams for example um but but the biggest thing we did was actually introducing that guy um the release
[27:04] train engineer or program manager or chief scrum master or whatever you want to call him and that's that guy that's
[27:11] this guy um basically somebody who could speak of behalf of teams of teams um and
[27:18] somebody who could uh try to focus and work with processes that weren't inside
[27:24] the team and also weren't uh traditional management thinking but was something in between finding a bridge between the two
[27:30] of those so it's a facilitation role not not a management role no I don't have line management responsibility um so we what we really
[27:38] really gained uh first and foremost is transparency into a lot of things so everything from details such as not not
[27:46] aligned definition of done uh across teams to
[27:51] um um a lot of waste in the way that we try to get projects from the portfolio
[27:56] to teams um a lot of that stuff kind of pops up when you try to when we try we
[28:01] started running big plan uh big room planning so we all of different things
[28:07] popped up so um one of the first really solid effects we saw is that instead of
[28:12] having a program program management office that was doing a lot of excel sheets calculations and figuring out how
[28:19] to best combine people in order to do the projects at what we thought one a year a year in advance would be the
[28:25] perfect timing uh didn't work since instead now we try to flow the projects to the teams uh let them pull based on
[28:32] business value right now and we actually have found out that the teams start to
[28:37] uh organize themselves so we don't tell the teams to move a developer the teams
[28:42] suggest that we maybe should uh lend the developer AC cross teams uh in this program and command which is really
[28:49] awesome um we also see even though it's uh it's not as as apparent as we hope it
[28:54] would be um increased predictability in the way that um stories flow through our
[28:59] organization so we really had a big impact when we started to started this thing um our first time was here um but
[29:07] since then at least the data indicates that we are becoming more predictable in the way that uh stories flow through our
[29:14] organization and what what this does it calms down stakeholders it takes away some some frustration and waste when we
[29:19] get a little bit more predictability as what's going to be delivered when roughly yeah um we did a survey um
[29:26] asking the teams how they feel about safe and order is done for them so some of the great things is that we experience that uh most are getting a
[29:33] better picture of what our priorities right now so it becomes more visual because we have it open they can see it
[29:39] for all teams not just their own um and they generally believe they are starting to add more value um whether they are
[29:45] actually adding more value or just being more aware of it I don't know but at least it's a good thing
[29:50] um but there are also some things that aren't working out for us yet um so we
[29:56] thought well if we do this big plan meeting will probably need less alignment meetings along the way uh it
[30:02] doesn't really look it like that so we haven't asked the opposite question whether they're actually spending more times on meetings um my gut feeling
[30:10] tells me that a lot of developers are spending more times at meetings but I think that may be also a good thing uh
[30:17] to some extent and we are not and we have not focused on uh limiting our work in progress so we thought or we expect
[30:25] that that we' probably have a better Foundation going forward to to work with the concept of limiting work in progress
[30:31] not on a team level but on on a program level you might say what what what has happened with safe has increased
[30:36] transparency which is making us more aware of the root cause of whip overflow
[30:42] but it's not solving it so just like most agile methodes they show you the problem they don't make the problem go away so we got to keep experimenting
[30:47] with that yeah um and there's some other less tangible things so um the teams are
[30:54] starting to feel uh a momentum so having this event every second month creates a
[31:00] sense of urgency a sense of urgency inwards towards the teams being able knowing that um there'll be a lot of
[31:07] attention on what has been delivered um at that point in time um and it's also
[31:12] creating a sense of urgency towards the organization around us so um previously was well you you're that agile group you
[31:19] you can take in stuff anytime right um somehow knowing that this is when we
[31:26] plan and then that'll be two months kind of helps people to to recognize maybe we
[31:31] should get that last requirement done now instead of waiting just that one week or two weeks and maybe three um it
[31:38] also creates a lot of awareness of change so big change is there um but seeing it uh at the events seeing that
[31:46] stuff has changed it's not the same as last I think helps us
[31:51] um inact that we are in a in a changing environment that we want to do differently tomorrow than did yesterday
[31:58] and that we want to improve and I think this this is really um a great opportunity to show it not just to talk
[32:04] about it um and finally um we do have a corporate it Department those are doing
[32:10] our infrastructure those are hosting our um servers that we re built on top of
[32:15] they are running waterfall um and having this um two second layer of planning
[32:21] with two months increments kind of thing seems to be a a reasonable B um Middle Ground between
[32:28] waterfall and our agile process uh something that we both can work with helping us to to to know these are our
[32:35] synchronization points yep um so we we're not done yet
[32:41] um this will probably look a lot different in a year to um but something that we we do see is that um we bring in
[32:48] stakeholders to these events so some of the people that we are um making it experiences for but also other people
[32:54] that are building software Solutions in uh in Lego and we see that this safe concept the big room concept is sneaking
[33:00] in everywhere um so everybody from Lego education who doing their own thing to to corporate it who are really keen on
[33:07] their waterfall process are kind of starting to look at this and say well this is maybe something we can work with
[33:12] um it's like a virus spreading right yes it's very interesting and it's it's actually pretty I'm actually Amazed by
[33:19] what I'm seeing it's really interesting to see other parts of Lego come to our events look at this they're like wow we
[33:26] we want this not of course exactly this but they see that okay there there is a way to be more agile than we are today
[33:32] and now we see how roughly that can work and a lot of very interesting changes happening so this is a very real thing
[33:38] happening spreading around so yeah uh now we're going to give you some opinions our personal very
[33:45] biased opinions yes on things okay let's start with uh with what we like um first
[33:51] of all being Beyond being just a tool to do planning uh big room plan is actually a big social thing
[33:58] um it's some of the first times we had a we had a director coming in um in the middle of it and wow this this kind of
[34:04] feels like a startup so there's a lot of also energy in this um that I personally really think I
[34:11] like um so this is another one of those it's it's one of those ideas and safe you can do this without safe it's just
[34:16] the idea of planning as a social event as opposed to planning being a bunch of project manager sending emails through each other right so getting everyone
[34:23] into a room it just turns out to be a pretty effective way of doing it um also the program Bo um I really like it as a
[34:30] conversation tool so both having conversations when getting stuff up there having conversations about what's
[34:36] up there and having conversations about what changes are there and seeing patterns I I totally love it so here's
[34:42] another example of evolution in in the first few uh product increments we had a lot of stuff up here all the features
[34:47] what was all the what was each team working on was up there which felt like a really good idea in theory in practice
[34:52] it wasn't because it was just information overload so what we have now is just dependencies yellow is something
[34:57] that depends on pink the red orange shows the the connection and that's all we need where are the dependencies that
[35:03] that need to be sorted out if there's stuff you're going to work on that doesn't have dependencies you don't need to put it up here and again it's it's
[35:09] transparency if you have a maner think why why is that so difficult what you do it it is it is complex we can't just
[35:16] make that go away um and I think talking about risks with ad teams having a
[35:21] formal light white uh tool for that having it visualized um also think works
[35:29] y but it's it's not all yeah so those were some of the stuff we like and it's not just us I think most people we talk
[35:35] to um kind of Point these out as things that that that they like but there are some things to be aware of um don't get
[35:42] stuck in Shu right so you've attended the 4- day or the two-day certification and you come back with tons and tons and
[35:47] tons and tons of manuals and checklists and and whatnot and if you do all that well uh yeah it it can be a huge problem
[35:55] um so be careful shoe can can get you started but don't take the whole elephant maybe right take the parts you
[36:02] need and maybe follow the some of the rules for a while and then start bending them
[36:07] um some things to be aware of watch out for cues and batches right yes so there
[36:13] is if you look in this picture and this picture by the way is pretty much useless unless you've attended a course to understand all the parts in it but
[36:19] once you do have have attended a course it serves as a pretty good reference for remembering what was in it but anyway
[36:25] inside this you see lots of little cues kind of everywhere and they're they can be very they can be a blessing they can
[36:30] be a curse so you got to be careful with that um safe can easily turn into this big monster if you have everything if
[36:36] you have all these lists um and don't believe in hype or or anti-hype that applies not just to safe but most things
[36:43] right there's been a lot of hype around agile in general there's been some anti-hype around the safe which is kind
[36:48] of interesting which brings me to the point where we might insult some people so I apologize in advance if I'm going
[36:54] to insult some of you but that is probably going to happen who's seen this picture
[36:59] before right it's it's a pretty good picture right what it shows you is how much knowledge you have of a topic and
[37:06] correlating that to your willingness to speak up and spread your opinions on that topic right and how loudly and you
[37:13] know what that is those of you have seen the picture what's the name of this
[37:19] mountain it's called Mount stupid this is the Mount stupid this is when oh I I just saw this website and
[37:27] damn I don't like safe safe is crap and then he starts telling everyone safe is crap that was very real for me because a couple of years ago people started
[37:34] asking me randomly out of nowhere Henrik what do you think of safe and I was like safe what what the heck is that what do you think of safe and and I would go
[37:40] find the site and I'm like whoa this big hairy thing um well I I don't know it feels a bit scary but I've I I have no
[37:47] training in it I have no experience in it I don't know how can I think anything of it and then I ask what do you think
[37:52] is safe and they say it's horrible it's it's terrible it's like this big monster eating agile and I asked him oh wow so
[37:58] have you had experience in this uh no have you had any training in it no ah so
[38:04] you're on Mount stupid that's exactly what Mount stupid is uh how can you know if something is good or bad if you haven't seen it or
[38:10] had any training in it at least one of those two I would kind of expect so I've been trying very hard not to be on Mount stupid and just see this as a as a
[38:16] toolkit which may potentially be great or or or horrible or maybe somewhere in between um I don't know until I got
[38:22] contacted by Lego and they were in this journey and I had to help out so okay so uh have I better learn this so I spent
[38:27] some time learning safe attended the certification spent time on the ground now for on and off for 9 months and I
[38:33] think kind of I think we're Beyond Mount stupid now yeah let's hope so probably maybe somewhere here and can kind of
[38:39] more confidently say that no this is not evil this is a toolkit and it can be used for for for for good or bad right
[38:44] so yeah just beware of Mount stupid it's a very common problem right so that was the part where we get to insult
[38:51] people okay let's let's wrap it up um takeaway points
[38:58] one is again just a toolkit learn as many tools as you can right learn how to
[39:03] use them learn when they apply learn which parts apply when that's a good habit especially people doing agile
[39:09] coaching is a good but it we kind of it dependent on what you're what you're what you work with if you're a developer
[39:15] you want to learn as many Frameworks and tools as possible so you can pick the best parts right just tools um neither
[39:20] good nor evil yep and there are certainly certainly a lot of them in there so I I heard the I saw I read the
[39:27] picture about the safe being like a when you cook spaghetti you take it you throw it at the wall whatever sticks you'll
[39:33] keep um it's pric B basically like that so there is lot of lean and agile
[39:39] principles in there um and a lot of this is sound and good so yeah yeah that that
[39:45] was my big takeaway when I did the course because I wanted to go to the source I wanted to talk to Dean lingwell understand what the thinking behind and
[39:51] that's when I realize that ah this is based on L natural principles um so fundamentally Most of It kind of makes
[39:57] sense it's just that there's maybe tooo much of it right so um safe is Sho level scaling a that's my personal kind of uh
[40:05] interpretation or simplification I think of it as Sho level scaling it gives you all the answers which is a blessing and
[40:11] occurs again right it gives you pretty much all the answers you dig around in that big picture you click on somewhere it'll tell you exactly what they mean by
[40:17] by a devop team or what they mean by a program backlog or whatever it is right release train engineer it tells you
[40:22] everything which can be very daunting um so just take just take take the stuff you need
[40:27] yeah um but it does it does bring a lot of useful to the to the to the party um
[40:34] we've we are in the lower part uh a bunch of teams working together on different products that just have a lot of dependencies it helps us kind of
[40:41] manage or self-manage that complexity um but it it's designed for a bunch of
[40:48] teams working together on the same product and I I I think it would make it a lot easier than it has been for us um
[40:54] because you just can be much clearer about what everybody's doing right yeah so so this I guess is the sweet spot for
[41:00] safe that's what it aims towards if you attend a course they'll be kind of assuming a context of bunch of teams working on same product but it turns out
[41:07] that other contexts where you're working on different products but you just have a bunch of dependencies you need some of this stuff anyway with or without safe
[41:13] you need some kind of synchronization some kind of program level planning process some kind of dependency management um yeah and finally again uh
[41:22] don't don't get stuck in shoe right so keep keep experimenting um and that's us
[41:27] and we're very and we finished early how did that happen that's amazing right we we have time for questions we have five
[41:33] minutes of questions anyone have a question we had let's one of them is uh is the
[41:40] planning for the last two sprints actually worth anything or do things changeed too much during the that sounds
[41:45] like our trigger to talk about IP Sprints right yes uh we we didn't talk about IP Sprints at all does anybody know what IP Sprints are a couple of you
[41:53] do well um safe introduces the concept of um have reserving the last Sprints
[41:58] within a program increment for Innovation and planning so basically telling you do not plan the last Sprint
[42:03] because you should have some time for looking ahead and you should have some time for doing other stuff because most
[42:08] of us know great scrum teams kind of get into that mode where they just crunch stuff and and they sometimes forget to
[42:16] breathe think um and be Innovative so what we experience is uh when we plan um
[42:22] three out of our four Sprints in a program increment um we usually deliver
[42:28] what we planned and intended on to do um but it usually also takes a bit longer
[42:33] um so we don't plan the last Sprint but use it as a planning buffer which is a
[42:39] nice and something very interesting about IP Sprint I talked to a lot of people about this also other places where people are using safe and my
[42:45] conclusion about that is that it's it's a brilliant idea they built in slack into the process itself I haven't really
[42:50] seen other methods do that Scrump sort of does it via yesterday's weather but here they're explicitly saying leave
[42:56] this blank don't put anything there right doesn't mean we're going to sleep there just means that we leave space there for hackathons and Discovery and
[43:03] basically stuff that we couldn't really plan for and it has dual purposes one has an overflow buffer if some of these
[43:08] things took longer than we thought they'll flow into there instead of you know busting the whole plan but it also provides a space for Innovation to
[43:14] happen and a place for for this big planning meeting and other training stuff to happen this is like the noise I should probably also say um so so we it
[43:22] depends on the context So within our context we can reasonably assume that the world doesn't change too much within
[43:29] a a two Monon time frame um and also having only four Sprints in there is
[43:34] maybe to the short side uh if you look at what safe um kind of suggests um but
[43:40] has been really a good good thing for you for us primarily um because it allows us to do this quite often and we
[43:47] do change a lot from time to time so it's been a way for us to keep our iterations short um and learn faster so
[43:55] what we noticed there is that I have I haven't seen anyone succeed in doing that anywhere yet doing safe it's one of those things that we should be doing it
[44:01] but we don't really do it uh as in most of the time disappears and you don't get a lot of innovation but what I've concluded is that even just trying to do
[44:08] it is helpful so even if you just do it to 20% it's it's helpful so it's very
[44:13] good ambition to have IP Sprints and I think we're getting a little bit closer every time to we will have the heck this time right we will have the heck ofon
[44:21] pan is going to happen right good question though yeah next question okay we have some more here one of the those
[44:27] are are there specialized teams EG deployment teams or teams cross functional
[44:32] and uh yes to both uh let's find the big picture right
[44:38] there all right yes we have a systems team looking at our deployment pipeline trying to
[44:45] improve tools for everybody so system team is pretty much what most companies have anyway they just call different things yes which is a team that is there
[44:52] to support other teams I work a lot at Spotify we got a whole bunch of teams like that their job
[44:57] is to help other teams become more effective exactly so and safe there's a term called architecture Runway which is
[45:03] which which is a metaphor for that so there are there are a few functions that are considered to be belonging to the Release Train itself and their job is
[45:09] not to be a bottleneck their job is to make enable other teams to to be faster and if you look historically at the
[45:15] development teams um quite a few of them were specialized so there was a specialized uh legal ID team working
[45:22] with um umid yeah
[45:27] um there was a search team there was a analytics team uh pyo team and so on but
[45:32] we've what we've seen is that the concept of having to pull from a common backlog having to figure out how to help
[45:39] each other to achieve common goals has uh motivated the teams along our n month
[45:44] journey to become a bit more willing to work outside their main area of
[45:50] expertise so we're on a journey where the teams bit by bit get more broad um we talk about this t-shape that you
[45:56] probably you heard up yeah uh let's take the last one yeah last question here uh
[46:02] can you describe preparations before Pi event describe what preparations preparations right what do we do before
[46:08] Pi yeah good what in general by the way we don't we we showed you an example of Pi planning that's just a
[46:14] synchronization event during the rest of the time of course people are doing the basically the usual agile stuff so the
[46:19] reason why we showed that specific example is because that's one of the more visible aspects of safe but preparations before that you want to say
[46:25] something about that um yeah so so what it what it requires of us is that we
[46:31] need in order for those common backlogs that are going into the event some kind of synchronization even before that um
[46:37] so the product owners and I said there's one for each team they do spend some time together uh leading up to this
[46:43] event uh talking about the priorities across teams we haven't spent an awful lot of time on the wage to job first
[46:50] technique which is part of this um but we've tried that uh among other things to to make sure that Pro are lined
[46:57] before going into this and then there's a lot of practical stuff yeah just yeah just short notice about there is a prioritization technique in safe called
[47:04] weight is shortest job first it's not really from safe it just happens to be popularized through that and we won't go
[47:10] into through details about it you can read about it it's one of those interesting things because most people who look at it and including me I was
[47:15] like this sells this makes perfect sense we should use this and we did and then I heard just as late as the day before yesterday that they some of the teams
[47:22] have stopped using it and they say we don't we don't need it or it doesn't work for us so now my feeling is maybe
[47:27] that's a good stepping stone to get to a point where stakeholders talk to each other in more more looking at the world
[47:33] in on in a wider perspective than just business value I think it's one of the topics I probably would have focused
[47:40] more on if you were building one product and not a lot of different stuffs it's really hard to really figure out so
[47:45] something for Lego come worth more than um let's say a new app for a certain
[47:50] frame uh franchise it's It's tricky to compare these kind of things got things like business value you got things like
[47:56] time criticality you got things like a risk you got things like how big is the task right so way to shortest job first
[48:01] gives you a little bit of an algorithm kind of shoe level trick to to get uh to get your backlog in priority order
[48:09] right so yeah we'll be there's a break now we'll be happy to chat with people here um who don't want to get drowned
[48:16] and people outside there but thank you for coming yes thank you
[48:25] [Applause]