Articles, Blog Posts, Books and Quotes on Agile Project Management
Trac is an open source enhanced wiki and issue tracking system for software development projects. Trac uses a minimalist approach to web-based software project management. It provides an interface to version control systems (Subversion, Git, Mercurial, …), an integrated Wiki and convenient reporting facilities. As many open source project, Trac has a plugin architecture that allows to extend the core functionalities. Here is a list of Scrum and Agile oriented plugins available in the Trac ecosystem.
The Scrum of Scrums is the key for scaling large, multidimensional projects that cross departments, teams, and traditional boundary lines so that can be managed using the same protocols and logic of a fundamental, small-team project. Bryan Zarnett explains that where most ScrumMasters fail in this large-scale environment is in the nuances of communicating and coordinating multiple teams. The same tool set used to run a small Scrum team cannot be used for a collective of teams. He defines the role of an Agile Program Manager (APM) that will coordinate the program portfolio and its dependencies and manage collective activities, issues, and risks. Regardless of design, the APM cannot operate 100 percent according to a Scrum textbook. Minor modifications to the tool set and the introduction of key new responsibilities will adapt and influence Scrum in minor ways that will allow the larger program context to be applied — and will allow teams to remain Agile even as size and interdependencies increase.
Most of us do the exercise of rating team members every year even if we know that software is built by teams, not individuals. Moreoever, each individual needs to actively collaborate to produce quality software. This means that everyone on the team needs to take collective ownership and help each other, because the motive is not to be a hero but to build an end product of the utmost quality and predictability.
Principles from the Agile Manifesto have been used rapidly throughout industry on software development projects at first, and eventually into projects that are not software centric. This article focuses on the application of Scrum to enable stability for the execution of systems engineering (SE) activities at Boeing and the development of requisite systems engineering work products throughout the product development lifecycle.
Scrum focuses on maximizing Return on Investment (ROI), but it does not define how to manage and track costs to evaluate actual ROI against the vision. A cost measurement that integrates with Scrum would be an additional feedback tool. This article presents the adaptation of the Earned Value Management (EVM) approach to the Scrum framework. The result is called AgileEVM (Agile Earned Value Management) and is a simplified set of earned value calculations. From the values in Scrum, a release date estimate is derived using mean velocity. Using this equation, you can generate a similar equation with traditional EVM techniques, thus establishing the validity of using EVM with the Scrum framework. This technique was applied to two projects to validate the approach. This experience also helped to determine the utility of AgileEVM.
This is an on-going series of blog posts that want to answer the classical question: How is software testing done during Scrum sprints? In the first installments, Clemens Reijnen discusses the importance of having testing knowledge in the team and implementing a collaborative culture. He then presents regression testing, test automation, end-to-end testing, avoiding overlapping tests, product backlog item implementation sequence, risk and business driven tests, writing acceptance tests. Microsoft Visual Studio is used as an example of tools supporting software testing practices in Scrum sprints.
Martin von Weissenberg explains in his blog post that focus and rapid feedback not only improve software development projects but shorten them dramatically as well. He use an experimental setting to compute the ROI for four different approaches: traditional plan-driven project delivering near the end, an unfocused project with continuous delivery, a focused project with an 80/20 Pareto distribution of value and a focused project with an 80/50 Pareto distribution of value. The results prove that focus and rapid feedback in the form of continuous delivery are game-changer.
