Videos on Scrum and Agile Project Management
We would like solutions delivered fast without compromising quality, user experience, implicit requirements and non-functional aspects such as scalability and performance. This would have been easier, if we had all the time in the universe. Doing this in a sustainable manner becomes a huge challenge for teams as there are multiple competing forces at play and because software development is very complex.
Microsoft uses Scrum internally as most Agile teams do. Take a serious look at this framework for managing complex projects, such as software development. This video shows how to implement Scrum in Team Foundation Server (TFS) using the Visual Studio Scrum template, new Agile project management tools and related best practices. We create and manage a product backlog, forecast and plan our work for a Sprint and manage our Sprint tasks using the new tools in TFS.
When you explain the iterative/incremental nature of Agile, most people coming from a waterfall lifecycle say “What? No up-front planning at all?” Some Agile coaches would glibly say yes, but the truth is more complex. Sprint Zero is an Agile term for a time-boxed amount of up-front planning. During Sprint Zero, you identify value stories, get a decent backlog of user stories and you do some architectural proof-of-concepts. The trick is to balance between insufficient planning and analysis paralysis.
Are you using Scrum? Can you do better? This video examines essential coaching strategies and techniques for improving your Scrum Teams and how to take the first step in igniting change. It walks you through ways to coach change and most importantly ways to sustain this change and make a lasting impact.
One of the first steps in an Agile adoption is the formation and organization of agile teams. Leadership often struggles to figure out how many people should be on each team, what skill sets should included, and whether the team should be focused on solution components, feature delivery, or a mix.
The nice metaphor of technical debt introduced some 18 years ago by Ward Cunningham has slowly taken roots in our collective conceptual toolbox, as a nice way to express some of the pains that software projects suffer from. Most software developers who have had some experience with significant, long-lived projects can feel it, sometimes point to it, but more than often can’t do much about it. In most cases, technical debt is seen as something very negative, burdening projects forever under increasing amount of interests. But some technical debt can be deliberate, more akin to borrowing to make an strategic investment, and this is especially the case for architectural-level debt.
Pair programming is sometimes the norm, and some developers really enjoy the collaboration, experiencing enhanced productivity. In other teams, pairing is shunned, avoided, or… faked. Angela Harms did a short survey about pairing attitudes and compared successful and unsuccessful pairing experiences.
Scrum Expert Copyright © 2009-2024 Martinig & Associates