The End of my Career
•Télécharger en tant que PPTX, PDF•
2 j'aime•434 vues
The document discusses the transition away from fixed titles and positions at one company. Over time, various teams experimented with different approaches, such as abolishing fixed team lead roles, allowing teams to select their own roles, and having employees sign a document renouncing their titles. By 2013, all teams were selecting and defining their own roles. This emergence of roles replaced the previous rigid structure with one that was more flexible and adapted to the needs of teams and individuals.
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à The End of my Career
Similaire à The End of my Career (20)
Plus de Johann-Peter Hartmann
Plus de Johann-Peter Hartmann (20)
Dernier
Dernier (16)
The End of my Career
- 1. The End of my Career.
- 2. „Why we no longer have (fixed) titles and positions“
- 3. „The employees do not want that.“
- 4. „There must be leaders and decision-makers.
- 5. „Employees need titles and positions for their career.“
- 7. What actually happened I 2005 Yes, the management (!) introduces Scrum 2006 Half of the company (Würzburg) abolishes Scrum again 2007 20% of all colleagues become certified Scrum-Masters. Including all Managing Directors & Teamleads 2008 Agile Fluency Level 1 and Cargo Cult 2010 XP-Practices: TDD, Pair Programming, CI/CD, Sustainable Pace etc, DevOps Community of Practice 2011 Scrum-Master != Teamleads (finally), Scrum by Heart <3 2012 Servant Leadership & Stewardship instead of Transactional Management
- 8. What actually happened II 2012 The „Allstars“ Team decides to abandon fixed positions. 2012 A lot of discussion in our internal confluence. 2012 Other Teams switch from a Teamlead role to an elected team representative role 2012 A colleague creates a wiki page „I renounce my title.“. 85% of the employees sign on that page. 2013 All teams in munich select and define roles on their own. 2014 Salaries and Feedback are done using agile tools 2015 I wrote a blog article what my colleagues did back in 2012.
- 9. There is no masterplan.
- 10. „Agile“ is what‘s left of the experiments if you take the mistakes away.
- 11. Cynefin In complex systems the relationship between cause and effect can only be understood retrospectively.
- 12. Cynefin In complex systems the relationship between cause and effect can only be understood retrospectively. Ok, let‘s try to understand.
- 16. What we had to learn ...
- 18. Senior-Architect: did alone or in pair for approx. 40% of the Storypoints of a 7-head team. Then he left the team. What happened to the team performance?
- 19. +20%
- 20. Senior vs Junior
- 21. Senior Developer Senior Junior Offical AccountabilityCompetence Why my colleagues ask for help with architectural questions?
- 23. Unclear requirements Ambitious architecture Technical Debt++ Former Supplier bankcrup
- 24. Setup: experienced colleagues & „a people team lead“
- 25. It worked out.
- 26. He is no longer needed
- 27. The Scrum Master who wasn't one.
- 28. There is something wrong here.
- 29. Allergilic Reactions Stuff that happens when agile makes things transparent.
- 30. This is how Agile should be introduced
- 31. This is your last chance. After this there is no turning back. You take the blue pill, the story ends, you wake up in your bed and believe whatever you want to believe.
- 32. The best architecture emerges continuously through the work of the team(s). Decisions are the result of collaborative discussions and on-demand modelling. The architect decides on the architecture.
- 33. It‘s better if the team decides how to work. The scrum master supports them, and the product owner figures out what needs to be done. There is a superior, and (s)he is authorized to give instructions …
- 34. You should do the most valuable thing You can contribute. Your team decides in the sprint planning II. You should do what your employment contract and your superior expects from You.
- 35. Together with Your team you figure out what roles are needed right now, and you try to fill the role with the best fit in ability, need and personal interest. Your role is defined by your position.
- 36. Software is far to complex to be understood by a single person. Everything is interconnected, has side effects and relies on other things. Individual accountability does not help. We need to have clear responsibilities. If nobody is in command nothing happens.
- 37. The success of the project is a joint effort. The team is as successful as its cooperation. The team leader is responsible for the overall success of the project. He needs it for his bonus, too.
- 39. Unlike my manager and my HR department, the colleagues in my team actually know what talents and interests I have. Your manager and your HR department are responsible for Your personal development.
- 40. If You are very good in Your current role you are obviously in the right place. If you did a very good in a certain role You should be promoted to a higher level.
- 41. Leadership is an organizational function that happens everywhere, all of the time. Most of the functions work better close to the actual work. Leadership is so important that it should be done by higher paid persons in hierarchical functions not involved in the actual work.
- 42. It takes months to understand a complex software and become a performing team. It is cheaper to learn new skills inside the team than to change the team. If there is a certain knowledge missing within the team i need to hire somebody with this knowledge.
- 43. Hmph. The red pill version sounds very elaborate, I'd like to avoid that.
- 44. That's just Agile Romanticism. Fancy Laloux New Work Esoteric. Grassroots democratic daydreaming.
- 45. Complex systems behave in a complex way - even if the management disagrees. Agile dirty trick
- 46. Self-Organisation Inspect & Adapt Emergence Learning Systems Agile dirty trick
- 47. Self-Organisation Inspect & Adapt Emergence Learning Systems Positions, structures, roles, leadership
- 48. Positions, structures, roles, leadership Individuals & Teams .
- 51. Roles, not Positions Use retrospectives to adapt: - document demand - Decision Matrix to rate Options - internal or external? - Consensus & implementation team
- 52. Roles, not Positions Swapping roles change role characteristics Create missing roles staffing team
- 53. Document shared Understanding Role: Technology marketeer Purpose: Create buzz about company & skills Domains: - Social-Media Accounts, Mailingliste - Content on Website & Blog Typical tasks: - Build relationships with potential customers - Promote services and company on the channels - Find & enable Speakers & Writer inside
- 54. Roles, not Positions When it stops working stop doing it.
- 55. Positions, structures, roles, leadership Organisational Structure and Leadership.
- 57. team team team team team team Value Creation Organisation Emergent Organisation Structure Market & Customers
- 58. HR Quality Assurance Accounting Marketing BusinessDev Development Central Services Team Team Team Team Team Team Value Creation Organisation Market & Customers
- 59. HR Quality Assurance Accounting Marketing BusinessDev Development Central Services Team Team Team Team Team Team Value Creation Organisation Market & Customers
- 60. We can‘t do that. It won‘t work for our organisation.
- 61. If You see a lot of change in Your organisation – this is probably already happening. team team team
- 62. The trouble with managed organisational Structures
- 63. Every growing startup 2019: We need the Spotify-Model!
- 64. Classic Organisation Scrum and Spotify Model Setting Goals Teamlead Product Owner / Data! Assign Roles Teamlead(s) Team + People Lead Initiate Actions Teamlead Team Coordination Teamlead Agile Coach / Team Direction & Motivation Teamlead, Techleads Product Owner & Chapter Lead Link to Organisation Teamlead Product Owner, Agile Coach, Communities of Practice Personal Development Teamlead People Lead
- 65. Leadership Task What we expected to get What we actually got Setting Goals Product Owner / Chapter Lead There still is a Teamlead. The management overrules the PO all the time. And the chapter lead thinks (s)he is the architect. Assign Roles Team There are contracts & job descriptions with fixed tasks and privileges Initiate Actions Team The team doesn‘t do it. The agile coach tried to, but actually the CEO took over, again. Coordination Agile Coach / Team The agile coach is inexperienced, so nobody takes her/him serious. Direction & Motivation Product Owner There are user stories of interesting quality, but we don‘t get the overall idea of the product. Maybe the priority board does. Link to Organisation Product Owner, Agile Coach, Communities of Practice I use my personal network. We‘ll be around when this management fad isn‘t anymore. Personal Development People Lead My teamlead and HR talk about this. Maybe it‘s useful for my next job. ... and what really happened
- 66. It worked at Spotify, Why didn‘t it work for us?
- 67. Decision Culture
- 68. Existing StructuresPre-Existing Structures Contracts, Formal Documents Formal Power Informal Power Personal Networks Politics „Stuff that already worked“ Confidence in new things
- 69. The emergent structure of Spotify, Snapshot October 2012. You can‘t copy that.
- 70. The emergent structure of nobody, never.
- 71. Part of the emergent structure of some companies, sometime.
- 72. 1 - How to figure out what Your emergent structure is. Shared Perception • Shared understanding of • Elements involved • State of these elements
- 73. Shared Perception Shared Comprehension • Shared interpretation of • Overall structure • Patterns 1 - How to figure out what Your emergent structure is.
- 74. Shared Perception Shared Comprehension Shared Projection • Shared expectation of • Future actions and • their effects 1 - How to figure out what Your emergent structure is.
- 75. Sounds Familiar? 2. Gather Data 3. Generate Insight 4. Decide what to do
- 77. 2 – Ability to change your organisational structure together. • Ashbys Law: „Variety absorbs Variety“ More Complexity needs more Freedom
- 78. 2 – Ability to change your organisational structure together. • Together is not Bottom-Up and Top-Down
- 79. 3 – Repeat . Shared Perception Shared Comprehension Shared Projection
- 80. Structures to provide 1, 2 & 3
- 81. Complex systems behave in a complex way - even if the management disagrees. The agile meanness.
- 82. To Long; Didn‘t Listen Complexity kills fixed Positions, fixed career paths and fixed organisational structure.
- 83. To Long; Didn‘t Listen Provide space, time, people & formats to adjust your structure on every level.
- 84. To Long; Didn‘t Listen If You do it right: No classic career anymore - but better fitness for purpose.
Notes de l'éditeur
- This is a talk about what happens if you take agile seriously.
- It‘s already 4 years ago when we published a blog article on our company blog where we documented what happend in our company and why. And we got a lot of feedback, where were newspaper and radio interviews.
- One of the common remarks was that our colleagues do not want that at all.
- „there must be leaders and decision makers, leadership roles and a hierarchy to get a company up and working. There is no other way.“
- And that my colleagues would hate it, because they need titles for linkedin, business cards and recruiters.
- That was interesting: most of the comments had the same hypothsis: the management level decided to do that. Sorry, that‘s not how agile works.
- In fact it happened in a different way. In 2005 we introduced Scrum to the company in the classic – and stupid – way it was done back then. The management sent a memo, documented the scrum practices, there was a workshop and trainnig.
- In 2012 the most innovative team at this time decided to abandon the official team lead role. Including their current team lead at this time, Sebastian Springer. A discussion in our blog came to live, and other teams made the move from a teamlead role to an elected team representative role, too. Sometimes it has been exactly the person that has been a teamlead before, sometimes a different person. Then one colleague created a wiki page „i renounce my title“, and within a few days 85% of the employees put their signature on that page.
- So, no management master plan, no decision to go fully agile. It just happened, based on discussions and retrospectives.
- Why did it happen that way? Because that‘s what agile is all about. It‘s the methods that work most of the time when you are experimenting.
- That‘s what cynefin want‘s to say with this sentence: you can‘t plan in complex enviroment, you need to figure out what works.
- That‘s what cynefin want‘s to say with this sentence: you can‘t plan in complex enviroment, you need to figure out what works.
- My Name is Johann-Peter Hartmann, you‘ll find me on twitter and Slideshare.
- In the sense of Scrum, I am a real pig and not a chicken on the subject today. I founded the company I work for today 18 years ago, founded a security company and was an investor in two start-ups. Agile leadership and its mistakes are therefore a question of one's own money, I have done practically nothing but these things in my life and would therefore be reluctant to break it.
- When I founded the first company I became the CTO as a hacker of the service. The agile story from the top means that this is almost completely over, because the teams themselves decide on how - and thus also on the methods, solutions and tools used. So since 2012 I have been called "Chief Tailwind Officer", which is in the sense of Servant Leadership and, to overstretch the maritime metaphor even more, Stewardship. I got some startup experience, too, as investor, interim management and board member.
- Ok, I'll try to explain how it all turned out.
- A nice mistake of ours: we had a developer in a team who is very experienced and a very good developer. He brings a really good know-how to most topics, and because he is also friendly everyone likes to listen to him.
- And he actually performed through the ceiling. In a team of 7 developers he has achieved an average of 40% of the storypoints. Every problem was first discussed with him, and one could also see his handwriting in the classes developed by his colleagues. Then he left the team and the company, for private reasons and in good friendship. Our customer came to me immediately and expressed his panic. And I immediately made him a much higher offer of money. All deadlines were wobbling and fear was spreading. Then what do you think actually happened?
- Exactly, within the next 5 sprints the performance of the team rose to 120% of the original performance. The remaining colleagues not only absorbed his performance, but even made up for it.
- The next story. In one team we had a very experienced senior. His name can be found in many open source libraries, he is the database guru and regularly speaks at conferences. In the same team, we had a trainee who was not only pretty smart, but also dedicated - at the weekend he liked to clean up the source and build prototypes. Commitment was high and after a short time he knew his way around very well. He came up with good proposals for adapting and designing the architecture, and because they all liked it, they were also implemented.
- If you were on this team, who would you have asked for advice on architectural issues? The one with the official role, or the colleagues with the detailed knowledge? It was exactly the same with us - the developers always turned to the colleague with the concrete know-how, not to the experienced colleague who was far less familiar with the application.
- And a third example from us: When staffing a new team it was clear that it would go through hairy times. The company that had started the project had gone bankrupt with him, and all those involved were at the end of their rope.
- Everything looked really bad in this project. The customer was a group in which the specialist departments were not entirely in agreement. Accordingly, the requirements were unclear. For this reason, the first service provider on this project had also assigned its best architect to the project, who also demonstrated his abilities in an ambitious architecture. Delivery pressure and complexity combined to ensure that the technical debt increased rapidly, and in the end there was what was needed. Failed launch, second attempt also fails, the service provider goes bankrupt.
- When we inherited the project, we therefore put together a team of experienced colleagues - and an emphatic team leader - to survive. The task of the team leader was clear - to change the mood and restore the ability to deliver.
- And it worked - the colleagues captured the project well and put it on rails, and with the first successes the good mood came back. It wouldn't have worked without Teamlead, he actually saved the project. But he was no longer needed after that. The critical path was no longer the team spirit, but the operative work. And the management tasks automatically moved there - to the experienced senior in the team, who was able to discuss and negotiate architecture well with his colleagues, and to the senior, who had vision and alignment for the product fully under control and enjoys good trust.
- And then we were in an interesting situation. The old team leader was there, generally respected and recognized. But you didn't need him anymore. Because the team was very mature in the meantime, no replacement was necessary. Formally, every team in our team needed a team leader at that time, and that's why there was one - but in fact the role for this team had been done, there were no more tasks left.
- And another story. We still had the classic career at the time - Junior, Developer, Senior, Team Leader, Scrum-Master and Scrum-PO. The further development was mainly carried out by the superiors. This has led to interesting effects. A colleague wanted to become a Scrum Master, and the feedback from his colleagues was not bad at all - they thought he could do that. We then sent him for certification and to agile conferences, and at the next chance he became a Scrum Master in the team that confirmed this role for him. In fact, this colleague is a classic Asperger case, a nerd of the purest kindness. Any instinct for other people's emotions is missing, communication is difficult in the scrub context. That didn't work out, of course. But the position was filled and the colleague already had the title in his CV.
- We have seen many more such stories. My colleague Albrecht talked about our best mistakes at the OOP, and we have a much bigger collection in the Wiki.
- We have found that many things break when thrown with agile work. There agile work behaves alternatively like Pandora's box or the Borg - once one begins with it everything comes into motion, and suddenly one notices, how things do not function in truth at all in such a way, as one thought so far. It's a bit unfair that I'm being agile here - agile only makes transparent what really happens, and we see the complex world that was already there.
- Deshalb sollten die anwesenden Herrn Gloger und Wolf eigentlich bei jeder Scrub-Einführung erst einmal folgende Frage stellen:
- Dies ist deine letzte Chance - danach gibt es kein Zurück. [öffnet seine Hand] Schluckst du die blaue Kapsel, ist alles aus. Du wachst in deinem Bett auf und glaubst an das was du glauben willst. [öffnet die andere Hand] Schluckst du die rote Kapsel, bleibst du im Wunderland, und ich führe Dich in die tiefsten Tiefen des Kaninchenbaus. [Neo greift nach der roten Kapsel] Bedenke: Alles was ich dir anbiete ist die Wahrheit, nicht mehr. [Neo schluckt die rote Kapsel] Folge mir."
- And that's exactly what happened to us. Until now, we assumed that the architect would decide what the architecture would look like. This no longer made sense with agile methods. Architecture was no longer a one-off action, but happened all the time, and the architect was replaced by the cross-sectional function of architectural gardening, which happens all the time.
- Previously, we assumed that the superior could give instructions - after all, he also bears responsibility for what the team produces vis-à-vis his management level. In the agile world, the team is responsible for the process. The supervisor is no longer allowed to give orders. The Scrum-PO is still allowed to announce which work happens in which order, the Scrum-Master himself has degenerated to a better genie.
- So far I have chosen a job according to the tasks so that I could do what suits my interests and abilities best. Instead, the team with me in Sprint Planning 2 looks every 2 weeks at who should do which tasks. And if my backend architecture skills always cause trouble in the frontend, then I'll paire with the UXler on his tasks so long that it won't happen again.
- So far, I've had a clear career path where I move from level to level, and each level is an upgrade in power, reputation, and money. I'm doing what's in my position. In the agile world there are not always defined tasks for all positions, and this cannot be planned. So you need t-shaped - or M-shaped people who have several possible roles. And depending on requirements, they serve the role that the project needs.
- So far there have been clear responsibilities. Clear accountability ensures that people feel responsible. Without this responsibility one would not be able to control, punish and reward. In the agile world, the responsibility is on everyone. The team result in the product counts. When I end up in a networked world in search of a culprit, I always end up in embarrassment, and anyone can construct why he was the father of success. However, it is not really clear in practice.
- So far, we have assumed that responsibility was a cascade coming from the very top and being distributed step by step downwards in the hierarchy. In a complex and networked world, this clear responsibility no longer exists. I don't even know for which things I will need responsibility everywhere in the end. Therefore, responsibility changes not only from the individual to the team, but also from partial responsibility to overall responsibility.
- Many probably know this team performance curve of Katzenbach and Smith. How can I explain individual success as a goal if cooperative success is much higher? What is the individual performance in the High Performing Team?
- In the past, the superior - or superiors - had the power over my development. They judged me, evaluated my performance and developed me accordingly. In complex environments, the effect of individual performance from the outside is virtually undetectable. In fact, my self-image and my external image are often not close to each other. A continuous discussion is necessary for an appropriate picture.
- Up to now, careers were largely linear upward movements. If I have proven myself somewhere, then I have earned it honestly to slide one step up and move more with more influence and power. In complex environments, the effectiveness of a hierarchically high-order position is not also higher. Quite the opposite: if a colleague with a certain task generates a lot of benefit for the company, he should not be removed there. If you yourself - or someone in the company - expect a higher benefit elsewhere, then you should also change. Also to prevent bore-out.
- So far, we have assumed that leadership is a hierarchical function assumed by a person in a hierarchical position. Sometimes, in matrix organizations, this task is also performed individually by 2 people. Complex worlds can only be effectively served with self-organization, external control is not possible. Management is therefore ineffective, and management tasks can only be identified from within the system - and there it is also possible to identify who is best to take on this task.
- Until now, it was assumed that colleagues with skills such as Lego bricks could be put together to form a large whole. That we can spontaneously add a new frontend developer or a new Scrum master if he is missing. Today we know that not only the familiarization with a complex domain or software can take months, but also the creation of a high-performance team takes a long time. If the performance is there one should do the devil and not destroy it by chess, but rather build up the know-how locally with the existing colleagues.
- After we saw all this, our first reaction was like this: It's too expensive. Firstly, I don't get the culture of the company turned around so quickly that it would work, secondly: is that even secure?
- I mean, other companies don't do that either, and still make a lot of money. Let's face it, it's just modernist Agile Romanticism. NewWork esotericism with which coaches now drive the next cow through the village. This is grassroots democratic do-goodness in companies for the time after the asylum seekers.
- And that's exactly where the agile meanness strikes again. Complex systems behave like complex systems even if you don't want them to. And with that, I have all the patterns on my neck that can be found in these.
- I have success strategies for these worlds - namely self-organization, Inspect & Adapt, emergence in structures and methods and antifragility through learning qualities.
- Our task is actually quite simple: Since these rules are universal for complex systems, they also apply to positions, structures, roles and leadership itself.
- Let‘s have a look at positions and roles – how would that look like with Self-Organisation, Inspect & Adapt, Emergence and Learning Systems ?
- We are talking about M-Shaped colleagues - yes, this is also due to the company name. Usually a colleague has more than one competence, the database person is also good in system engineering, the product owner is also good in the UX of the user journey, the Scrum master can also work as a product owner or as a coach for another team.
- The distribution of roles within the team takes place via retrospectives. Often we have two retrospective formats per team - one is the normal retrospective for the iteration, the other is the basic retrospective every two months, which deals with the overall system. There a customer can be deselected with us e.g. from the team. The rolls are also adapted there if necessary.
- The distribution of roles within the team takes place via retrospectives. Often we have two retrospective formats per team - one is the normal retrospective for the iteration, the other is the basic retrospective every two months, which deals with the overall system. There a customer can be deselected with us e.g. from the team. The rolls are also adapted there if necessary.
- The things that can happen is a simple role reversal - we have teams where the Scrum Master has become the Product Owner, the System Engineer has inherited the database, and so on. The role can also be redefined, new roles can also be created that did not exist in the team before. Staffing requirements also arise when the team cannot do it alone. Most of them are colleagues with whom you have already worked in order not to destroy the performing level.
- That‘s something with missed when started to abandon fixed positions.
- And there is one nice thing about roles instead of positions – you can stop them when they don‘t work anymore. And this happens a lot more often in an dynamic environment.
- So, if the internal structure of my team has to be able to adopt to changing environments, how about my organisation?
- There is a lot of knowledge how an organisational structure that is able to deal with change looks like today. Holacracy, the betacodex/Value Creation Organisation, the „Kollegial geführtes Unternehmen“ from next-u, the Wertschöpfungsrechnung of Götz Werner in every other example from Reinventing organisations – they are organisations that are able to adopt.
- Since the main idea is to have a fluid and flexible infrastructure you don‘t see a lot of organigrams in this area – but a lot of circles. Every circle is a group of people, in the best case it‘s a team. And they are dealing directly with the customer or the market to be able to learn fast. The rest of the organisation has it‘s purpose to support them.
- So what you find in the center of the organisation is a set of services that are needed by the teams that interact directly with the market.
- Like every German agile company, we also ended up with a peach model from Niels Pfläging, in which largely autonomous teams use the company centre as a service. The teams are usually stable.
- And that's exactly where the agile meanness strikes again. Complex systems behave like complex systems even if you don't want them to. And with that, I have all the patterns on my neck that can be found in these.
- We work with a lot of startups, we invested in some and sit on the board of some. And there is something all of them are discussing whenever they are growing – the spotify-model. And we are talking about a startup with between 30 and 100 people here, on average.
- It‘s a nice model. It fits pretty well with agile organisations.
- So the startups ask: why doesn‘t it work here? It worked at spotify, why shouldn‘t it work here?
- Most of the startups have an informal, but a strong decision culture. If you use the william e schneiders core culture questionnaire, this would be around the decision culture you would have found at spotify. Spotify has been agile for years when they documented the model. Everybody was already used to collaboration and culture. For the most startups there is control – since the founder sees everything – and competence, because the technical cofounder knowns everything about the software, but did not document a lot. Everybody is used to ask the founders. And now they should use completely different structures? They don‘t believe it. And it usually does not work out
- And there is a lot more of that - ßßßßßß
- Spotify is a company that has a lot of excellent agile Coaches. So they are always on their way uncovering better ways to create software. Spotify does not look like this anymore, they are a lot more data driven today. This is all you build it you run it.
- Actually SaFE is rather a collection of individual emergent structures, that worked somewhere at some moment in time. So it‘s not bad, but it should not be understood as the universal solution for large scale software development. That‘s why you see a lot more „We used Elements from SaFE“ than using SaFE itself.
- The Nice thing about Less, Nexus, Scrum at Scale is that they are smaller – they give you less answers, so they tend to have a better compability with your company. On the other hand there is a lot more things you need to sort out on your own.
- Endsleys Model
- Endsleys Model
- Endsleys Model
- Endsleys Model
- Does anyone know the moltke alignment vs autonomy diagram? Thats
- There is a lot of knowledge how an organisational structure that is able to deal with change looks like today. Holacracy, the betacodex/Value Creation Organisation, the „Kollegial geführtes Unternehmen“ from next-u, the Wertschöpfungsrechnung of Götz Werner in every other example from Reinventing organisations – they are organisations that are able to adopt.
- And that's exactly where the agile meanness strikes again. Complex systems behave like complex systems even if you don't want them to. And with that, I have all the patterns on my neck that can be found in these.
- This is a talk about what happens if you take agile seriously.