Reddit mentions of Lean from the Trenches: Managing Large-Scale Projects with Kanban

In the book Lean from the Trenches the author made the experience that using T-shirt sizes (S/M/L) was perfectly sufficient and no less accurate overall than using finer point scales. And this was in a huge government project with several teams doing a Scrum of Scrums.

>Problems arising in development for which we have trouble finding or creating a good solution. This may take a few extra hours but in some cases it has taken days to figure some things out, and this is time that is 'unaccounted for' because these tasks have specific hours/points assigned to them.

This is an issue with planning. Things can and do happen, but if they are happening frequently you have an issue with planning.

One thing you can try to do is assign a 'champion' to each ticket during the first discussion. (backlog grooming usually) The champion is responsible for gathering all the needed information and essentially the go-to person for understanding what needs to be completed and all of the dependencies. This person should also work with product to break an epic or story into the appropriate scope and subtasks. If a problem does arise, this is the person responsible for working with relevant stake holders to come up with a potential solution to take to the group.

>Time spent going back and fixing previously-completed components when new components break them. Our app is comprised of many components that work off of each other and sometimes changes to one either break another one or require some further changes to other ones to prevent breakage.

This is another planning issue. if you have to frequently go back and fix stuff that was completed then you didn't accurately capture the dependencies. (or someone else released something without checking your dependencies. still an issue with planning, just maybe not yours)

This is harder to fix. a champion can alleviate this to a degree, but it depends on the nature of the dependency. either way, not enough communication is going on.

>From the UI side, going back and fixing/updating/improving components that were functionally in a completed state. This one doesn't take up much time, but it is still not 'tasked' time.

Then task it. you should be capturing as much of your work on paper as possible.

if UI is outside of your team, it should be accounted for as a dependency the team is responsible for.

Again, not enough communication is going on. UI people should be part of your planning and you should be accounting for this time.

>The biggest problem comes when we have to make changes to multiple components simultaneously because they share functionality or work together, and this appears to cause a delay because 'neither of them are being completed on schedule'.

guess what I'm going to say. :p

sounds like you need to work with your SM to re-establish communication chains. they aren't there.

>We are all talented developers and we know what we are doing, but the seemingly 'results-driven' approach of SCRUM is not making a lot of sense to us right now, and morale is low.

your SM doesn't know what he's doing, sadly. Sounds like a converted PM that hasn't crested the learning curve yet. It sucks that Morale is low. You can do things to help him out and keep morale high. unfortunately this also depends on his willingness to accept the fact he doesn't know what he's doing.

You should really sit down with your SM and talk to him about this. It's his job to remove impediments. low morale is an impediment. how do your retro's go?

One of my favorite stories to tell, is one of the first retro's I was observing. (normally only the team should be present, but we made an exception for training purposes. I was there to observe, not to add) The company I was at was in the middle of a transition to Agile. They weren't prepared to hire dedicated SMs, so we were training within and having volunteers be SMs on teams temporarily.

Anyway, during the course of the retro, the team talked about how the current SM was not meshing well with the team, and wasn't really embodying Agile/Scrum as everyone else understood it. They decided in the Retro that the SM wasn't right for the team, and they needed a new one. So that's what they did, switched SMs right in the middle of the retro.

>Sometimes unexpected and time-consuming shit happens, and tasks cannot be completed 100% in one sitting. It just doesn't make sense to me. Can someone please explain how to handle these scenarios?

This largely depends on the group and the environment. if things are changing as frequently as you say, and they always will, then you should explore other models than Scrum. Specifically lean/kanban is better suited to volatile environments.

Within Scrum, when an event occurs that drastically changes the scope of a sprint you're supposed to bust the sprint. This is, by design, a painful process. you should immediately go into retrospective. talk about what went wrong. go into planning and re-establish baseline. figure out what the team can get done with this new information and restart the iteration.

Again, this is painful by design because it is a last resort. if these events happen frequently, then there's something else going on that needs to be addressed and talked about. mostly because you lose two days every time you bust a sprint. it paints a giant target on you that screams 'we didn't have our crap together. so now we have to go back and get our crap together' and no-one likes that. This is the main mechanism used to 'force' a team to fix their problems. granted, most SMs and most companies don't bust sprints even when things are going very poorly. but this is what scrum has in place for what you described. (so start doing it.)

In reality, Scrum tries to prevent these scenarios by enforcing better habits around planning and commitments. if you're new to scrum, or don't understand it yet, this can be extremely chaotic as Scrum assumes you have certain things already worked out. Scrum training generally does a woefully inadequate job of explaining this. the point is to highlight your main problem areas so you can fix them.

It's doing that very well. you've identified your time sinks. have some problems. Scrum's job is done. now it's your turn. talk about the issues as a team and figure out a solution based on the context of your environment (team/project/company/organization).

-------------

Recommended reading:

Phoenix Project: https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/0988262509

Crucial Conversations: https://www.amazon.com/Crucial-Conversations-Talking-Stakes-Second/dp/0071771328/

Lean from the Trenches: https://www.amazon.com/Lean-Trenches-Managing-Large-Scale-Projects/dp/1934356859/

When you're ready for something more advanced:

Tribal Leadership: https://www.amazon.com/Tribal-Leadership-Leveraging-Thriving-Organization/dp/0061251321/

Toyota Production System: https://www.amazon.com/Toyota-Production-System-Beyond-Large-Scale/dp/0915299143/

Lean Software Development: https://www.amazon.com/Lean-Software-Development-Agile-Toolkit/dp/0321150783/

Note: This last book is 'advanced' mostly because of price. It's worth it.