How big tech runs tech projects and the curious absence of Scrum
Agile industrial bullshit scale:<p>Level 0, aka &quot;kanban with continuous deployment&quot;:<p>- Tickets in backlog arranged in approximate priority order. Meetings with business stakeholders (e.g. product managers) take place where the most pressing objectives are discussed, and as a result new tickets are refined and added to the backlog. As a result of changing priorities, existing tickets may be reprioritised or deleted in these meetings.<p>- Pull requests are reviewed and then merged to the main branch. After passing integration tests they may be deployed to production either automatically, or at the click of a button.<p>- status update meetings take place a couple of times a week. Or perhaps they are daily but asynchronoulsy via slack or a web app.<p>- there is regular, adhoc communication and planning both within teams and between teams<p>Level 1, aka &quot;scrumban&quot;:<p>- In addition to the meeting(s) to refine tickets, there is also a &quot;sprint planning&quot; session where approximately 2 weeks of tickets are put into the following sprint, and a &quot;sprint goal&quot; is assigned that approximates what the team hopes to achieve<p>- If another team or business representative brings up new requirements half way through a sprint, they are told it must wait until the next sprint.<p>- If the team runs out of tickets towards the end of the sprint, more are drawn in. Other times work will take longer than expected, or be blocked, and tickets will roll over to the next sprint.<p>- There are short daily standup meetings, where each team member gives a brief, free-form statement of what they&#x27;ve been up to, shares any learnings or problems they wish to share with the team, and maybe gives a funny anecdote from their personal life<p>- Every sprint has a retrospective meeting where people talk about what went well, and complain about things that they didn&#x27;t like.<p>Level 2, aka &quot;Scrum as a religion&quot;:<p>- Managers use burn-down charts as a way of measuring the effectiveness of the team&#x27;s organisation and planning. If tickets need to be drawn into a sprint or roll over to another, this is taken as a sign of bad planning. The team is asked how they will go about being more consistent in future.<p>- Developers may be required to vote on a number of story points for each ticket. Managers may become very exicited that story points don&#x27;t estimate the amount of time taken to complete a task, they measure complexity, whatever that is. Even though the creator of story points has stated he meant for them to measure the time taken.<p>- The daily standup meeting requires each team member to follow a precise process, where they give an update on each ticket they have worked on in each column. Any time a ticket has taken more than a day, the manager asks whether there are any blockers. Any time a ticket has been moved to done, they are congratulated by the manager. After these updates, the team must then discuss the sprint goals<p>- the bi-weekly retrospective meetings are required to have outcomes. These often involve either more meetings or more processes<p>Level 3, aka &quot;Am I in a Dilbert cartoon?&quot;:<p>- The senior managers involved in coordinating planning across multiple teams decide to introduce some ideas from the scaled agile framework. Multiple sprints are grouped into blocks of 6-8 weeks. Large numbers of JIRA tickets are refined and divided into epics before the start of each mega-block-sprint. Each week senior management measure the progress towards business objectives with regard to how many tickets remain incomplete in each epic. If a team gets to the end of the 6-8 week megablock having somehow done exactly the same work as they originally planned they are congratulated for being highly Agile. Those that don&#x27;t achieve this are told they&#x27;ve missed their targets.<p>- Releasing any service to production requires filling out a 20-point spreadsheet checklist along the lines of &quot;have any breaking changes been notified to other teams? has this been tested in a development environment? have new tests been added?&quot;. Pull requests must then be made to multiple repositories to actually tag and release a new version, and a series of slack messages must be manually posted on the status of the release.<p>- Making any decision beyond completing work on a JIRA ticket requires scheduling a meeting<p>Level 4, aka &quot;Scaled Agile Framework ®&quot;<p>- The megablock multi-sprints are 10-12 weeks, and are alternated with &quot;hardening&quot; sprints where people fix all the bugs they introduced in earlier sprints, and possibly &quot;innovation and planning&quot; iterations, which is the only place anyone is allowed to do any work that requires any thinking.<p>- Half the employees have titles like &quot;Solution Train Engineer&quot;, &quot;Release Train Engineer&quot; and &quot;Scrum Master&quot;<p>I&#x27;ve just reached level 3, previously couldn&#x27;t get beyond level 2. Anyone managed level 4? Are there bonus levels beyond that?