Blogs on Scrum and Agile Project Management
As the Agile Manifesto stated that it prefers “working software over comprehensive documentation”, some early Agile adopters jumped to the conclusion that documentation was useless. Thus Scrum software developers should only concentrate in creating working software with code that was the most easier to understand.
Agile software development teams often use the notion of “velocity” to measure their ability at delivering value to the customer. In his blog post, Norberto Herz discusses the concept of “predictability” as a measure of the team’s health. His blog post starts with a series of interesting questions: can the company sell “predictability” to its customers? Is predictability a new application feature? Is predictability A team quality or a team goal?
The first value of the Agile Manifesto is about “individuals and interactions over processes and tools”. Communication is fundamental inside and outside the Scrum team. In his article “Watch Your Words: Feedback Analysis”, Tom Bartel give some hints on how to improve the feedback process especially in a negative context.
When do you need to stop coaching an Agile team? In his blog post “An Exit Strategy for the Agile Coach”, Len Lagestee discusses this question and explains how he will gradually work to be ready to leave and let the Scrum team be ready to carry the Agile values on its own.
Scrum and Kaban are two Agile approaches that could be used in software development, depending also on the context of the software development tools. In his blog post “Ditching Scrum for Kanban — The best decision we’ve made as a team”, Grant Ammons shares some thought on why he successfully changed it process from a Scrum to a Kanban perspective.
Having a good Definition of Done (DoD) might be one of the most important technical asset of a Scrum team. This makes the difference between delivering at the end of the sprint fully completed business features or half-baked software. In his blog post “Changing the Definition of Done”, Ken Rubin discusses the situation where a Scrum team might want to change an existing Definition of Done.
Technical Debt is defined as the eventual consequences of poor or evolving software architecture and software development within a codebase. In a blog post published for the Software Engineering Institute (SEI), Robert Nord has provided the keys points discussed in a seminar Managing Technical Debt in Software Engineering, an event that discussed both the past and the future of managing technical debt.
Scrum Expert Copyright © 2009-2024 Martinig & Associates