One of the core values of Agile development is working software over comprehensive documentation. A common perception is that Agile methods such as Scrum hinder the process of documentation. In reality, there is always an opportunity for Agile teams to create sufficient and valuable documentation.
Scrum itself provides room for some calculated modifications. However, before applying such modifications, pros and cons must be considered.
With the advent of Agile/Scrum methods in project execution, many of the . . . key skills that a project manager was singularly proud of have gradually become less crucial.
We always hear that Agile teams should be self-managed and multidisciplinary. What does that mean?
While executing Agile projects, many Scrum teams use a "hardening sprint." . . . This article maintains that a hardening sprint is not a good idea and highlights why.
This paper suggests different approaches to speed up ERP implementations and support based on scope of work, standard package fit, and organization readiness.
Agile test automation is the application of the Agile development principles to test automation. Accordingly, there are some principles of Agile test automation. . . .
There has been much hype about Dual-Track Scrum, but not much about how it has been put into practice. I hope this post gives you some idea of how the concepts can be applied in your place of work.
I often find that how work gets from the customer to the team is neglected or poorly understood. I would like to talk about this process and provide a framework for you and your organization to experiment with.
I was part of a large-scale Agile transformation recently. It was a great learning experience, and I want to share my experience of the transformation.
Looking at the increasing adoption rate of Agile and the rate at which organizations are heading toward Agile transformation, it is time to formulate a mechanism and a strategy to enable smooth Agile transitions.
Most of these organizations/teams later talk about the failure of Agile. I have heard many hypotheses about why this project is special and why Agile thinking won't work for this project. If we go a little deeper and examine the situation, we will see that they didn't transform the mind-set of the people involved.
Stand-ups happen, burn-down charts are in place -- and suddenly, toward the end of the sprint, things start falling apart. No matter how many times you meet or try to resolve issues, the comeback is never 100 percent. You have failed your sprint.
We've often experienced programmers writing code and the task working perfectly, but later, while we integrated that code with the rest of the application, we faced unexpected results. . . .
When it comes to personal improvement, we impulsively and subconsciously follow the process to change and to improve; but when it comes to teams, we struggle to put it all together. . . . It takes a good ScrumMaster and a collaborative team to conduct effective retrospectives.
Your project is suffering from PODS -- Product Owner Disappearance Syndrome -- when the availability and commitment of the product owner is not enough to help teams complete the planned deliverables on time.
Do we really handle retrospectives in the way we are supposed to? . . . Retrospectives run the risk of becoming repetitive and boring, especially when (in the case of weekly sprints) they are conducted week after week.
There are lots of tools and different types of frameworks available for using Agile in automation testing. Here we are going to look at QTP and SpecFlow integrated with Selenium or WatiN tools. . . .
There will always be memorable moments: post-sprint or project-wrap pizza parties, baby showers for team members (and their significant others), promotion celebrations, weddings, and going-aways. But how many truly proud moments are there?
In the six years that I have worked as a ScrumMaster, I've often been asked if my role is truly essential, and why it should be considered an independent role within the Scrum team. "Why can't the dev manager also perform as the ScrumMaster? Or one of the developers? Or a QA tech?"