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.
One of the best ways to ensure that a team grows to be high performing is to get them off to the right start. Read on to learn two team start-up activities that focus on process and help ensure everyone is on the same page from the beginning.
As Agile and Scrum are increasingly used to manage software development projects in large companies, Nancy Nee, VP Global Product Strategy at ESI International, provides us with her viewpoint on how the transition to Agile is going on. She also shares some advice on how make the adoption process as smooth as possible.