A prevailing belief among Agile and Scrum proponents is that “a great deal of explicit risk management becomes unnecessary when a software development project uses an agile approach.” In my experience, this is a false and dangerous assumption. Project risk is a hungry leopard ready to devour the unprepared. Fleet-footed agilists and die-hard waterfallists alike.
To do agile retrospectives, it is important to understand what they are and why you would want to do them. This helps you to facilitate valuable retrospectives and to "sell" retrospectives in your teams and motivate team members to actively and openly take part in them. As a retrospective facilitator it is important to have a toolbox of retrospective exercises which you can use to facilitate a retrospective. This article describes some possible exercises that help you to facilitate retrospectives that deliver benefits to the teams that you work with.
Are your teams retrospectives really worth the effort? Do the problems you identify actually get solved? If not, your team might need some help learning how to use retrospectives to continuously improve. This article illustrates how Scrum teams can continuously improve by using a combination of their definition of done, working agreements, and the product backlog.
The most ignored attribute of development is reviews. Many Scrum teams compromise on review tasks in order to complete their other tasks in a particular sprint. Though they plan separate tasks for reviews, they frequently ignore them. In reviews themselves, the most ignored is the code review. The shorter the sprint, the less the importance and time allocated to code reviews.
We all understand that Scrum teams should be self-managed and self-organized. Empowered is the commonly used term, because without empowerment it's difficult for self-management and self-organization to happen.
In Scrum, we depend on the team for estimation. It is the team that estimates the efforts and time for each product backlog item; it is the team that, in the sprint planning meeting, breaks down each item into tasks and estimates efforts for each; it is the team that, in the daily Scrum, estimates the remaining efforts. . . .
By conceiving the project from the beginning as an agile project, you can outsource projects effectively and agilely. This paper describes how one team used Scrum to create an agile RFP, discusses what information should be present in an agile RFP and proposes how to find a partner to trust through a lean, Agile selection process.
These four tips for integrating Quality Assurance practices into your Scrum process will support the underlying Agile value. Principles from the Agile Manifesto are applied in ways that affect your approach to software quality. You will learn how to address impediments to adopting those principles and why the approach of testing software as you go, not waiting until the very end of your Sprints, not only builds in better quality but promotes a deeper understanding of the entire application for the entire Scrum Team. Discover the common obstacles involved with Agile adoptions, and learn to apply temporary fixes in your Quality Assurance processes along the way, as long as your team learns from each experience and continually improves.