Videos on Scrum and Agile Project Management
Rich Hickey has stated “The simpler solution is going to kick your butt”, Russ Miles would go further, “The simpler solution is already kicking your butt; no one is more agile than the teams developing with simplicity in mind”.
Agile is founded on people and interactions. This presentation will explain a model to align teams for high performance and give you practical techniques, adapted from clinical hypnosis, that have proven successful with project visioning, goal setting, improved team communication and business collaboration.
How often did you meet a situation when everybody knows about an issue, at retrospective everybody agrees that it should be resolved, but next retrospective brings the same issue and the same action items? Why team of mature developers cannot change a situation on a project, cannot apply new practices or fail to apply innovations? Let me explain it on real project example and get you to the root cause, go from best practices to basic principles and back.
You have been doing Agile and Scrum for a few years now. With a regular cadence you have retrospectives and a lot of problems and great improvement opportunities are raised but nothing seems to really improve. Stop doing retrospectives!
There are a lot of teams out there who started their transition to agile/lean quite a while ago. Most of them did some great steps in the right direction. But after the first view month, after all of the low hanging fruits were harvested, most of the teams struggle with establishing a valuable and sustaining kaizen culture of continuous improvement using retrospectives.
Tired of the claims that Scrum, XP, and kanban don’t scale beyond a few teams? Overwhelmed by management’s resistance to the organizational changes needed to really follow agile principles? Concerned with the lack of proven practices required to scale agile methods to the next level? Exploring the Scaled Agile Framework™, Dean Leffingwell dispels these claims and answers these questions—and more.
What do home ownership and leveraged buyouts can teach us about how to use technical debt to our advantage in Scrum? How can we sleep soundly at night when we have accumulated mountains and mountains of technical debt? When is good enough good enough and when are we just deceiving ourselves?