Cees Roele - Case Study: How Process Follows Product
•Download as PPTX, PDF•
0 likes•29 views
Large products can be created only by chopping them into smaller pieces to be worked on by separate teams. In this presentation I will share my observations in a product company of how the chosen architecture of the product influences the processes of four different teams. This affects both the processes of specific teams and processes between teams working on different parts of the product. Aim of the presentation is to illustrate the dynamics of the relation between product, organisation, and processes.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Cees Roele - Case Study: How Process Follows Product
Similar to Cees Roele - Case Study: How Process Follows Product (20)
More from Agile Lietuva
More from Agile Lietuva (20)
Recently uploaded
Recently uploaded (10)
Cees Roele - Case Study: How Process Follows Product
- 1. Case Study: How Process follows Product Cees Roele
- 5. Organisation
- 9. Conway’s Law Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations. Melvin Conway If you have four groups working on a compiler, you'll get a 4-pass compiler. Eric S. Raymond
- 11. Evolution Gaming
- 12. Experience: “Introduction to newcomers” The changing topic of my presentation to newcomers: Our general processes What teams really do Why organised this way?
- 13. Our general processes ● Organisation: Product Owner, Scrum Master, development team ● Sprints, daily stand-ups, planning meetings, retrospectives ● Two-weekly release process
- 14. What teams really do ● Kanban instead of Scrum ● No Scrum Master ● Either Product Owner or Scrum Master fulfils many project management tasks ● Release-when-ready ● OKRs for planning ● Different communication preferences for dealing with other teams ● Different outcomes: product artefact, infrastructure, or service.
- 15. Why organised this way? ● Why this division into teams, rather than another? ● Is there a better explanation for actually followed processes than iterative inspection & adaptation by teams? ● What is the role of the team’s “product” in all this?
- 18. Scaling with natural separation
- 19. Four cases 1. Archetypical “game” team 2. Video team 3. Common Cores: back end 4. Changing position of RNG
- 20. Case 1: archetypical “game” team ● Create new games ● Maintain existing games ● Scrum framework ● Two week release cycle ● Cross-functional: graphical design, business analysis, front-end, back-end, QA ● Natural split of teams over different games
- 21. Case 2: Video team Streaming video Game Interaction Playable Game integration
- 22. Case 2: Video team ● About 30 people, no PO, no SM ● Partly single people working on individual R&D projects ● Support for specific features / problems of games teams ● Release-when-ready ● Numerically specified goals ● Objectives and Key Results (OKRs) as basis for planning
- 23. Comparison 1. Game team ● Outcome is a releasable product ● Multi-disciplinary effort ● Certainty about outcome of effort ● Uncertainty about value of outcome: stakeholder input needed 2. Video team ● Outcome is measurable improvement ● Research: uncertainty about outcome of effort ● Certainty about the value of outcome: just measure it
- 24. Case 3: Common Cores: back end / front end ● Shared functionality between games ● With crystallisation of games ever more shared functionality defined
- 25. Case 3: Common Cores: back end / front end Back end ● Architecture ● Can impose technical interface on games teams ● Relatively easy to create automatic tests for Front end ● Dependency on devices actually used by end user ● All code ends up in the user’s device
- 26. Case 3: Common Cores: back end Team A Team B Single code base
- 27. Case 3: Common Cores: back end Team A Team B Product A Product B Team C Common Core
- 28. Case 3: Common Cores: back end Team A Team B Product A Product B Team C Common Core
- 29. Case 3: Common Cores: back end Back end clustering DB messaging Common functionality Roulette Blackjack …..
- 30. Case 3: Common Cores: back end Back end clustering DB messaging Common functionality Roulette Blackjack ….. Games Features
- 31. Case 3: Common Cores: back end Back end clustering DB messaging Common functionality Roulette Blackjack ….. Production Operations Numbers
- 32. Example 4: Changing position of RNG Team goal: Recreate existing games, but with 3D animation rather than video. Technological project: ● Technically innovative ● New architecture: anything on the front end and back end can change ● No integration with existing game code ● Scope already defined ● One team and one Product Owner
- 33. Example 4: Changing position of RNG Stability of architecture allows for different distribution of work over teams All can change Common back end 3D Common front end Specific front end
- 34. What we have seen The architecture of our product can influence our processes by: ● Making splitting of total effort into teams effective ● Reducing need of individual interaction by code interfaces ● Allowing specialization ● Increasing focus of a team (narrow down), or ● Extending freedom to change code by a team (widening)
- 35. Lessons If: ● If goals are confusing … ● If processes are too complicated ... ● If a team is not productive … Then: See if a change of the product can help.
Editor's Notes
- Overall structure: - brief introduction: I will be talking about the relation between organisation, processes, and product - Evolution Gaming as context for the talk - Four case studies from teams/departments in Evolution Gaming - Two more examples of changing the product to be able to change the organisation or process - Take aways
- Before I start a question: what is odd in this picture?
- To make anything we need some kind of organisation. A team, with people working in specific roles. A department. Or a whole company. At a team level, we can think of a Scrum Team, consisting of Product Owner, Scrum Master, and developers.
- To produce any outcome, this organisation has to do something. Not just anything, it has to follow some processes. Both within organisational units and between them. We can think of releasing a working increment iteratively, having daily stand-ups, agree on and respect definitions of done, inspect the result, and possibly adapt.
- If we want to talk about “agile frameworks” we are looking at a combination of organisation and process.
- The normal account in Agile theorising goes like this: when we get our organisation and processes in order, we can create any product we happen to want. From the viewpoint of having clear roles that one can get educated in, train for, and be hired for, there is good sense: the Agile Coach understands about processes and how to transform the organisation, independent of any knowledge of preference of the product.
- Conway’s Law comes down to “The organisational structure will influence (or even determine) the structure of the product.
- What I want us to look at today is the other direction: given the product we are trying to create, what combination of organisation and processes would be most suitable for creating it? Getting back to Conway’s Law: if we want to create a four-pass compiler, how should we organise our teams?
- I will tell about my observations on the relation between process, organisation, and product in Evolution Gaming, a company that provides “live casino” to online businesses. These brand the games and present it to game players. Think of Evolution Gaming as primarily a big film studio in which the majority of its about 5000 employees are game presenters, like the man at the Roulette wheel on the picture. Some 300 people work in IT to create and operate the software that optimally streams the video from the studio and brings it together with the user interface that allows game players with computers, tables, or mobile phones to actually play the game as in a casino.
- In my role as Scrum Master lead I have given a number of introductions to newcomers in Engineering. Based on feedback in those meetings I gradually changed the topic from what we say we do to actual practices and to the way teams fit into the overall organisation.
- … after the list: this is not meant as a contrast with the earlier account. It is not that many teams lost the way and deviated from Scrum. The point of the changing focus is just that it turned out to be of more interest for people to hear about actual practices than to hear a recount of what is in the theory books.
- After recounting actual practices the next step is finding answers to the question why the situation is as it is, with these differences per team.
- Growing start-up: How do we get from ten people creating a single product to three hundred people creating a variety of related products? How about all being one big team? Everybody interacts with everybody and all are team mates. QUESTION TO THE AUDIENCE: Would that be good?
- Rather than having one huge team, we create a number of smaller teams. Now, we get communication lines within teams and between teams. But how do we split the larger development organisation into teams? What should these teams be responsible for?
- Division of police patrol districts for the city of Portland. The patrolling police teams are all doing pretty much the same thing, but in a territory of their own. Territory makes sense, because that is what patrolling is all about: you go from one place to the adjacent one. Police teams don’t patrol specifically red brick buildings or apartments buildings with more than 8 floors. We don’t have such a natural division for teams working on a large software product. Let’s look at a number of teams that I have seen from close by.
- A “game” team produces a game like Roulette, Blackjack, Poker, or Baccarat. It creates features that come in the hands of game players, let’s call them end users. A Product Owner is responsible for the team creating the right thing. A Scrum Master - not always there in practice - leads the team through its processes. The reason for having a team per game is that features require decisions, that is, there must be an active Product Owner per game, who understands the market and translates it to a playable game.
- The video department’s goal is “continuous video improvement”. Think: minimising “stuttering” of video and optimising the sound experience for game players. Here we seem to have a natural technologically imposed distinction: we have game interaction teams on one side and the team supporting the streaming video on the other. The results of their work are merged in code and at runtime. What struck me is that there is not just a separation of teams, but that processes are very different. My initial stance was: each team can define its own processes, so I will not comment on what they have decided to do. But gradually it came to me that it is important that they got to different ways of working.
- What I want to emphasise here is that this is not a mere division into “features” and a “component”. Due to the nature of the sought outcome we get to a completely different way of setting goals, measuring progress, and organising work.
- The teams have a different focus. But also a different relation with stakeholders (feedback cycles), they have different technological challenges (good looking vs effective algorithm), and deal with different uncertainties. Now, we can take this at face value: this is just how different teams work. But imagine that they are not different teams, that such differences are brought together in a single team: different focus, different release rhythms, different demands for stakeholder feedback, different uncertainties to address. I have seen such a situation in practice and this is detrimental to a team’s cohesion. What we see here is that the different outcomes games teams and the video team have as their goal, they have different ways of measuring the result of their work and different processes of getting their work done.
- For now I will not go in the common core of the front end
- Now image that we have a single code base. If “Team A” gets into the same code as “Team B”, because they share functionality, this might give rise to conflict. Now we can have interactions between members of the teams like “you broke our code” and “this is the best way to implement that”. Additionally, if the teams create distinct products, they might each have their own backlog and own Product Owner defining desired features and priorities. If these Product Owners want different things, they need to resolve it. That might well be possible, but there are no clear standards for what would be a good way to go forward.
- From the previous situation with different teams with different products working on the same shared code, we now make an architectural change: we add a new Team C that has ownership of common code that is split off from products A and B that are now getting a separate code base. What is more that separate code base has a defined interface that is offered to other teams, while the rest of the code is hidden and under the full ownership of Team C. Our change in product lead to changes in processes. Typically, team C will have its own backlog and Product Owner. If a Product Owner of Team A wants changing in the common core for Product A, the conversation with be with Team C, which has its own Product Owner and own backlog. But in addition to “individual interaction” there is now a common core with a defined interface. Typically, we talk of such an interface in technical terms, but there is good sense here to see it in terms of processes: Team C offers opportunities, sets expectations, agrees not to break existing interfaces, works according to a ranked backlog, has a Product Owner with whom to discuss features and priorities. Part of what previously an open discussion between Teams A and B is now solidified in terms of code. Availability of code is reducing the amount of individual interaction.
- This model is scalable. If we include Team B again we see that it can enter into the same processes of an interface to code and a transparent backlog for changes in the common core.
- Let’s start with the common back end for games.
- From the viewpoint of games teams, they are all sharing common functionality. If they want something specific for their own game from the back end team, they are competing with what other games teams want. Such changes take place in a situation where much is stable. It is already working for multiple earlier products. APIs are taking over what would otherwise be communication between teams.
- Another side to the back end is a two-way communication with production operations. From the view of the back end team, it is representing games teams: we want such-and-so facility and it seeks to get them working through having well-configured systems. In production. Meanwhile, production operations seeks to optimize speed, throughput, and uptime. Very specific requirements are progressing “upward” to games teams. As earlier with the example of the video team, we see that the backend and production operations can focus on results in terms of numbers, leaving it to games teams to focus on features.
- Common code for different RNG games Integration in common front end code 3D and specific front end are both clearly in the game domain and can be picked up by the game team with direction of the game Product Owner. Specialism: through experience and generalization we have a more stable architecture now, which work to be split over different teams.