Scrum Studios
I have a public sector client who started an agile transformation about 6 months go. Their current position is one of WaterScrumFall. They have hired nominal Scrum Masters (some agile terminology has been pillaged), but as of yet are nowhere near implementing Scrum:
- For any given project, there will be an extended period of hierarchical, epic-first requirements decomposition.
- There is extensive up-front design and planning
- In their SDLC, development sprints are encapsulated in a stage gated phase towards the end.
- There will be one release at the very end of a project, with no intermediate releases either planned or to be delivered on demand.
This is quite typical for any large organization that has agile ambitions, but which has political barriers and cultural practices that impede transitioning. There's no easy fix to this; it will take a long time and probably a number of failures before substantial change is attained.
What is interesting though, is that this client has gone some way towards putting a "Scrum Studio" model in place for software development projects:
- There are half a dozen Scrum teams.
- If any project needs doing, one of them will be assigned.
- This model theoretically provides continuity of teams over the course of many projects.
- It's different to having one team follow a project all the way through to maintenance and support.
The Studio model can be effective as an intermediate step in enterprise transformation, and I'd like to encourage it further. However, in this case, it has been compromised by the way each team in the studio is resourced. In short, project managers are making decisions about who goes into which team and when. This leads to instabilities in team identity, inspection and adaptation, and metrics. Retrospectives also indicate it is demoralising to the teams when their members are moved around.
My contention is that it should be up to the teams themselves in a studio to make decisions regarding their composition and rotation. It's all part of being self-managing. I'd observe that teams can handle uncertainty in scope much better than they can handle inconsistency in their membership.
Does anyone else have a view on how best to resource teams in "Scrum Studios"?
I agree with where your thoughts are headed - the people on the teams know best. I would organize a 1/2 day to a full day activity to split up into the teams of their choosing. There may be some political barriers to this move, but there would be many benefits.
I recently joined a 'scrum team' that had about 16 developers, so my first thought was to split the teams up, but how? How would I do that? I didn't know skillsets, personalities, desires, past history or knowledge areas of the application. I empowered the team to make the decision on who should be on what team - the only stipulation was that the team had to be cross-functional - meaning they had to have the skills/ability to deliver a fully fledged product. I did this for a few reasons - firstly, it wasn't obvious to the team members that this was needed and stories were currently not really stories, but more front end or back end tasks, that wasn't directly tied to delivering value to the client.
Also, allow teams the time to learn a new language or coding standard as they deliver value - this would hopefully get rid of people trying to move people around because of what they know, or what language they can do in and would hold the team sacred.
You can also share how context switching is bad for productivity (tonnes of information & games on google).
Maybe introduce a 3 month timebox and have the team commit to delivering SOMETHING of VALUE. No scope commitment at this point, just a commitment to release something to production. This would create the sense of urgency that seems to be missing (only having 1 release at the end isn't very urgent). With a deadline (of time, not scope) only 6 sprints away, team members will enter panic mode a little bit and most likely will start asking if they can develop now, rather than waiting - which is perfect! It should also force architecture & story decomposition to only take place for what is needed for the next 6 sprints (3 months, if on 2 week sprints). It removes the need to discuss architecture which isn't need for 6 or 9 months.
Rather than needing lots of failure to show how it should be done, things can quickly change if you have 1 example of how things are done and having a successful team & release to show that will quickly gather attention across the enterprise and everyone will want to emulate that.
Ask for free reign for 3 months to implement scrum & agile as you see fit, with the promise of delivering SOMETHING of VALUE after 3 months.
Also if you release every 3 months, the company starts to see a return on their investment and the team actually become excited about building & releasing products.
Good luck!! I hope some of what I wrote is useful.