Scaling Scrum Adapted from The Enterprise And Scrum by Ken Schwaber
- Support, Infrastructure, Networking, Development, Testing.
- C#, Web services, WCF, WPF, ASP.NET, C++, Java, LPC, Lua, DirectX, XNA
- Existing organization product owner voice only considers 10,000 foot view items
- Work items all become priority #1!
- Incremental spans quarters instead of rapid feedback loops needed for true agility and to expose real roadblocks.
- Operations work is done by development departments inside of the project work loop
The meeting madness
- A meeting to communicate some ideas to a manager
- Who meets with the worker to communicate the ideas to worker
- Who meets with vendor to communicate ideas with vendor
- Closer communication with requestor to the worker creating the product.
- Closer communication with Ops those doing the work.
- Functional managers see their roles change
- More removing organizational roadblocks
- Making sure the worker is in contact with the source of work.
- Some functional managers may find themselves “bored” but given opportunity to monitor and improve their team.
- Driven By network operations
- Driven by support ticketing
- Work orders better communicated to workers who own them.
- Driven by Configuration Management System
- Baseline hours set by scrum team velocities and backlog item sizes
- Enterprise wide ‘ideal day’ = story point
- Documentation level/template
- Managed by enterprise backlog
Enterprise Product backlog
- Integrate at least once per sprint (30 days)
- Difficult for engineering organizations especially those who have long running regression tests.
- Multi layer system work organized by functionality
- Create a local version utilizing existing infrastructure
- Refactor to use new infrastructure development
Integration of Multiple-layer systems
- Interface changes need communicated at scrum meeting(standup) in scrum of scrums
- A team focused around each area of the system
- An integration layer team (if not the UI team)
Integrating with non-scrum work
- Stubbed/simulated systems
- Simulated interfaces act as ongoing update to the Statement of work with the provider.
- Organizing people to do enterprise work
- Teams with distributed members
- Scarce skills needed by many teams
30 years in the making
- Consider this on your own merit
- Then consider steps needed to adopt
Organizing people to do the work
Organizing the people
- The integration team is developing integration tests to verify all of the functionality integrates properly.
- They’re the final say in whether the software is Demo-able or not. Generally a group of team leads from the different functional areas.
- Scrum master and product owner first
- People who have succesfully worked together previously
- People who understand the product or business domain
- People who know the selected technology
- People who can fulfill the ‘done’ requirement. For example a tech writer for documentation.
- 45 crossfunctional ‘developers’ at Woodgrove bank
- They were all thrown in a room with no managers
- Told follow scrum rules to organize into teams
- Trust from team that management wasn’t ‘selling them down the river’
- Self organizing will flourish
- Decide how they’ll get requirements
- Formed rules of etiquette (Working agreements/values)
- Formed rules on engineering practices
- Tentatively formalize sprint process for turning backlog items into something “Done”
- Team needs trained on resolving conflicts.
- Conflicts about how things are done
- Conflicts about who does things
- They also need to be able to identify the source of their conflicts and not blame
- No ‘You’ language, try “It” or “we”
- No “But” language, try “and”
Norming and performing
- Performing is not permanent.
- Storming will arise from time to time.
- When it does they will need the skills to identify the cause and resolve it.
How people are managed
- The product owner sets goals
- The scrum master ensures the ‘framework’ of scrum is followed
- The rules of the organization cannot be ignored.
The product owner
- Responsible for node one of the tree and setting goals. Responsible for ROI
The scrum master
- At node 1 the scrum master should be educating the product owner on how to maximize ROI utilizing the scrum framework
- Scrum master should be making sure all scrum masters in below nodes are encouraging self direction.
- How do I keep functional skills sharp now that functional managers are scrum masters?
- You could let ‘the team decide’ or…
20% to ‘self research’
- Or allow them to dedicate 20% to self research and improving themselves.
- Don’t just say “Seek training”
- Remember your teacher: “Write me a paper” and you said “How long does it have to be?”
- Be surprised like 3m and Google were!
- Total incentive amount pooled and sent down through the teams via the product owner.
- Some managers left over after all were assigned as scrum masters
- Idle hands are the devil’s workshop
- Managers attending sprint planning
- Committing for team members
- Managers making sure there was no slack time
Teams with distributed members
- We can’t collocate our team
- Can you simulate it? Yes!
- Sync up with representatives from each office.
Scarce skills needed by many teams
- Don’t let the shared resource work in isolation.
- Their knowledge won’t get shared
- No accountability to a team
Relationship between Product manager and the dev team
- Shortening the time to release through managing value
- The mother of all problems
- Backlog items can be measured in ROI
- Product owners can determine what value they are delivering and deliver highest value first
- Projects ending before the unused features even get delivered… move on to other projects.
21 32 item 33 12 50 item 32 … … … 13 60 item 9 22 60 item 8 20 65 item 7 13 70 item 6 34 70 item 5 13 74 item 4 21 75 item 3 34 75 item 2 13 80 item 1 effort value backlog
- Place them into all the backlog items of the project.
Earned business value
Just do it
- Tells managers, devs aren’t on board!
- Speed is improved up to 3x!
- Maintenance cost can go upwards of 4x more.
- Decrease value of enterprise asset
- The product owner meeting!
- All the core engineers and product owners in the room
- How do I move this beast faster!
- Form teams and refactor it aggressively
- As bugs are fixed refactor, clean, and heavily comment code
- Live with it longer but put automation around it to tell when it breaks.
- Rebuild with new tech and good design with test harnesses.
How did this happen?
- Bad engineering practices
- Choice to hit market fast
How can we see when this is happening?
- Trending of slower velocities over time.
- I don’t know steve but let’s talk about what he points out as ‘signs’ of good agility.
Signs of good agility in play
- No true managers, just team leads
- Peer reviews influence the team
- Goals are communicated through an incentive system (I would imagine an enterprise product backlog with highest value giving highest incentive for completing)
- Meetings are reduced to 1-3/week
- Meetings only happen in the middle of the day so people can do what they need to do early or late.
- It also ensures that late or early comers always get ‘meetings’ that are needed
- Note they have free meals for everyone so that would help the meeting during mid-day situations.