You have been doing Agile and Scrum for a few years now. With a regular cadence you have retrospectives and a lot of problems and great improvement opportunities are raised but nothing seems to really improve. Stop doing retrospectives!
User stories and their size are often the basis for planning a Sprint in Scrum. You can use a relative estimation and planning poker or a more classical approach to define the effort for each user stories. As such, they are also the basis for the metrics of progress and the velocity of the Scrum team.
This article discusses the differences between quality assurance and software testing. If the developer uses techniques like TDD to prove that his program can work, you shouldn’t ask him to prove the opposite. This article advocates having a separate software testing function, even if you are using an Agile software development approach like Scrum.
There are a lot of teams out there who started their transition to agile/lean quite a while ago. Most of them did some great steps in the right direction. But after the first view month, after all of the low hanging fruits were harvested, most of the teams struggle with establishing a valuable and sustaining kaizen culture of continuous improvement using retrospectives.
One of the principle of the Agile Manifesto is that “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” In this article, Glen Wang explains that ” the Scrum retrospective is a great platform for inspection and adaption, or knowing and doing. Know yourself and adapt to the world.”
Tired of the claims that Scrum, XP, and kanban don’t scale beyond a few teams? Overwhelmed by management’s resistance to the organizational changes needed to really follow agile principles? Concerned with the lack of proven practices required to scale agile methods to the next level? Exploring the Scaled Agile Framework™, Dean Leffingwell dispels these claims and answers these questions—and more.
Agile practitioners are aware that Scrum has three roles: developer, ScrumMaster and product owner. In his book “Executable Specifications with Scrum”, Mario Cardinal also discusses how you can use the role notion in Agile to better understand stakeholders that have a different perspective, a concept that is also named “personas”.