Reddit reviews Lean Software Development: An Agile Toolkit
We found 6 Reddit comments about Lean Software Development: An Agile Toolkit. Here are the top ones, ranked by their Reddit score.
Intuition's actually a pretty good description of it. See, e.g., Lean Software Development (Mary and Tom Poppendieck), p. 61-62:
> Gary Klein studied decision making of emergency responders, military personnel, airline pilots, critical-care nurses, and others, to see how they make life-and-death decisions. He expected to find that these people make rational decisions in life-threatening situations; that is, they survey a range of options and weigh the benefits and risks of each option, then choose the best one from the analysis. When he started the study, he was amazed to discover that fire commanders felt they rarely, if ever, made decisions. Fire commanders were very experienced, or they would not have their jobs. They claimed that they just knew what to do based on their experience; there was no decision making involved. We call this intuitive decision making.
>
> When experienced people use pattern matching and mental simulation to make decisions, they are employing a very powerful tool that has an unquestioned track record of success...
>
> Klein found that firefighter commanders resort to rational decision making only when experience is inadequate. Deliberating about options is a good idea for novices who have to think their way through decisions. However, intuitive decision making is the more mature approach to decisions, and it usually leads to better decisions as well.
>
> Note that intuitive decision making can yield incorrect results if the underlying assumptions are incorrect or the constraints are not well understood.
>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.
LEAN Software Development by Mary and Tom Poppendiek
https://www.amazon.com/Lean-Software-Development-Agile-Toolkit/dp/0321150783
Who comes up with the deadlines? Does your development team communicate estimates on the work prior to the deadlines being determined? Is your team fixing scope for the release as well?
The development team should be communicating estimates on work prior to deadlines being determined. The development team should also communicate risk and uncertainty in the estimates so the product owner is aware of how much of a buffer is needed for the release date.
If your team is fixing both scope and date for the releases, then that leaves minimal room to adjust when things go wrong. The recommendation from Essential Scrum, Planning Extreme Programming, and Lean Software Development: An Agile Toolkit is to have a fixed date release with negotiable scope. This way, when you get behind schedule, you can just reduce scope. If you started with the highest priority items, you should still be able to release by the deadline when you get behind schedule. You just wouldn't release quite as much stuff as you originally thought you might.
The manifesto principles are about the best you can do as for an 'official' set of rules : http://agilemanifesto.org/principles.html - most importantly, the last point about:
\> At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Everything else comes from there - the team learns what works best for them. However, if you want a glimpse into why teams do certain things, I'd really encourage you to read https://www.amazon.co.uk/Lean-Software-Development-Agile-Toolkit/dp/0321150783 It might appear a bit dated - but in practice the ideas around feedback and waste are very useful lenses in which to evaluate any particular implementation of 'agile' and how to improve whatever it is the team is currently doing.
As for full-stack developers, my opinion is that it's about being able to have empathy in the various individuals for different considerations - the business objectives, UX, front-end practicalities, backend, architecture, operations and so on. That doesn't preclude very separated roles but as an example: if everyone knows what direction we should take the product, why have a product manager? If people can do operations, why have a sys-admin-type person? If the front-end devs can do back-end too, why have back-end devs? There's answers to all of these questions - but they're different for each team.
Consider a 1-person team working on a product by themselves. Imagine they were somehow successfully making money and could hire one more person - do they actually need an extra person? What would they want that extra person to do that would help them grow the most? If they were previously doing everything, they might actually just need someone to go sell the product they've made, or someone to handle meetings with stakeholders and gather data about what to work on next, rather than another developer, and so on. It might just be that they want someone to share everything 50:50.
>How do you all approach designing a solution like this assuming you will not be able to acquire an existing application?
I'll ignore the whole DB selection thing, because this is the real question that you need answered (and will eliminate the need for the DB thing)
My approach would be: focus on solving the clients problem as fast and cheap as possible. Some principles to follow:
I basically just described to you - in a super simplified way - the agile/lean way of building software.
>I am willing to put in the time and effort to learn what I need to learn here -- I just need some guidance!
Here are some book recommendations:
Lean Software Development: An Agile Toolkit
Clean Architecture
Continuous Delivery
I hope it helps. Feel free to reach out to me if you want to discuss this further.