It's difficult to change learned behavior, and even harder to change group habits. This is one reason why it is difficult establish Scrum Most companies understand that Scrum has a lot of potential and bears the chance to shorten time-to-market or the delivery of high-quality software, but. . . . And there we go again: "Scrum, but. . . ."
User stories are not merely an engineering requirement fashion. They are a simple but powerful and sophisticated way to gather requirements. They are also an Agile way to obtain the detail of the software through iterations that will, each time or during each review, gain more detail.
Scrum teams just look different. From their faded whiteboards to their discarded post-it notes, Scrum teams make their mark just by doing their job. Read one CSPs story of how his team's space tells the story of their struggles and their triumphs.
This article discusses the details of burn down and burn up charts: which units to measure, how to adapt to scope variations. He gives some guidelines on how to interpret burndown charts. He reminds that the chart should be objective and visible.
In my travels I spend a good deal of my time discussing Scrum Product Ownership, Product Backlogs, and inevitably User Stories. Stories are containers or artifacts, which have nearly become ubiquitous for handling software requirement within agile teams.
A common perception when working in Agile is, "Welcome changes over following a plan." In the Agile Manifesto, however, the phrases "Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage" still mean you need a plan to begin with. How can we express the product backlog so that we can easily provide enough planning information to management without compromising on Agile principles?
How one CSP discovered that when explaining product backlog items to new teams, it's best to avoid delving into details about the PBI itself and instead focus on the the workflow of a PBI and the interaction with the Scrum framework.
Based on our experience, it is essential that stakeholders be involved in deciding the approach for solution delivery. Agile and Scrum require commitment and collaboration from various stakeholders for successful delivery and customer delight. While teams inspect and adapt their ways of working through multiple iterations, efforts of multiple stakeholders need to be coordinated. Without collaboration, sustainability is compromised. Commitment and collaboration cannot be achieved without setting the foundation early on in the project. At Baker Hughes Incorporated, our processes facilitate the initial conversation between multiple stakeholders to make the project successful. During the initial stage of projects at Baker Hughes, the teams have an opportunity to choose a solution delivery methodology Waterfall, Rapid Application Deployment or Agile. This article presents the different aspects of this conversation - the parameters that we consider. yhy these parameters are relevant in the context of Baker Hughes and the impact of these parameters on solution delivery.
Without any doubt, the heart of a project is the team that supports it. There can be a willingness to start a project, sponsors to start a project, a leader to guide its implementation. But all of this is useless without a team to transform the objective into reality. It is not enough just to have a team that makes the objective reality. This group must be sufficiently motivated, united and comfortable for the objective to be achieved with quality. Thus, a team need to be able to maintain a sustainable, healthy pace. A team rhythm that provides unbelievable deliveries, even for its members.