Articles, Blog Posts, Books and Quotes on Agile Project Management
Technical debt is the consequence of poor or evolving software architecture and software development within a codebase. The debt can be thought of as work that needs to be done before a particular job can be considered complete. In this blog post, Bastian Buch proposes an agile approach to reduce technical debt. He first declares that technical debt hasn’t improve through agile development methods and principles, but only gained some visibility.
Utpal Vaishnav shares with us his experience as a new ScrumMaster in this article titled “Seven Things I Wish I’d Known When I Started out as a ScrumMaster“.
Project charter discussions and documentation focuses traditionally on project scope and the goals and objectives for the project. To address specificity of Agile project, the author of this article has recently created and successfully utilized an Agile Development Team Charter. It differs from usual project charter as it focuses more on the ‘how’ of the project.
This article discusses the challenges that Agile brings to the appraisal process. Agile methodology focuses on team performance more than on the individual. The objectives of the team aren’t easily broken down by individual; one cannot appraise the individual on the basis of team performance. This article presents a workable solution for appraising Scrum team members. This will address problems raised while remaining within the Agile framework and philosophy. If a team is self-organizing, per the Agile framework, we can empower that team to raise itself to a “self-appraising team.”
This is an interesting interview of Ward Cunningham that talks about technical debt. Ward Cunningham was the first to drew a comparison between technical complexity and debt in 1992. In this interview, he talks, amongst other topics, about the relationship between technical debt and developer experience or when accumulation of debt is a good thing.
As Scrum teams should be self-managed and self-organized, they need empowerment, because without it, it is difficult for self-management and self-organization to happen. In this article, Jerry Rajamoney shares that the high-priority impediment item he has repeatedly faced as a ScrumMaster and struggled to solve is empowering the team. He gives four situations that could be considered as signals of lack of empowerment. He also notices that some issue come from the fact that managers are often asked to play the role of product owner or ScrumMaster, which creates confusion between the organizational role and their Scrum team role. A solution to these issues is proposed.
Scrum Retrospectives are not easy and this meeting is often the first one that will be canceled when there is some pressure to deliver a product. In this blog post, Mitch Lacey explains why retrospectives are so important in Scrum. He presents also some key components of an effective retrospective in a Scrum / Agile project and how to organize a retrospective meeting.