Videos on Scrum and Agile Project Management
The default use of an “estimate-driven” approach is pervasive in software development efforts. While estimates can be useful, it is worthwhile to scrutinize our use of estimates, and to seek better ways to manage the development of software when estimates are not appropriate.
Large-scale Agile and Scrum transformations are in fashion and senior leadership want their enterprises across the land to “be Agile” or at least be seen to “be Agile”. But what does that mean? What are the risks? What does that cost? Agile transformation is an organizational change that is often assumed to be something much less significant or wide-reaching than it actually is.
To achieve true business agility, leaders must not only grow and support self-reliant, cross-functional, self-organizing Scrum teams, they must also change the way their organizations fund and oversee their agile initiatives. They must believe in feedback and allow that feedback to work. However, old measures like “on time” and “within budget” are not useful when markets and customers are constantly changing, potentially resulting in delivering great solutions to problems that no longer exist.
At some point in your work as Agile coaches, you have to organize some kind of team building event. The brief you get is usually a combination of “fun” stuff with some “work” stuff mixed in. This talk share some alternative ideas for kicking things off with a Scrum team and creating a psychologically safe environment essential for collaboration, without cooking or paintball or escape rooms involved ;O)
The end of the year if often the time for performance reviews. Should you still do this practice when you have Scrum Agile teams where the global results should be more valued than the individual peformance?
Your product roadmap can basically set your life course as a designer/researcher so why is it so often that user feedback can get lost in the discussion over “Feasibility” of implementation. Without a clear roadmap, research and design can often not have the lead time needed for activities. This leads to a state of forever catching up and being reactionary.
The common wisdom is that Agile need Kanban teams to do the work that the Scrum Teams can’t do yet as well as the stuff that you don’t want your Scrum Teams to be distracted by. There is however much more to Kanban than meets the common agilist’s eye.
Scrum Expert Copyright © 2009-2024 Martinig & Associates