Introducing Scrum can be fun, but can also be quite a challenge. There are numerous hurdles to overcome, new practices to master and problems to solve. In this article, we will present some of the mistakes we have seen made, or made ourselves when introducing Scrum at various companies. In this last article, we'll discuss the meta-ScrumMaster role, cowboy behavior, and why agile is not easy.
Good testers don't just question the final product. They question the product before work has even started and while it is being developed. And they also challenge the team itself. While this is true of many traditional testers, These lines of questioning to be more prevalent on agile teams because a "whole team" mentality is encouraged and quality is a team responsibility.
Ask any Scrum trainer and they'll tell you the same thing: Adopting Scrum is hard. There are many reasons for this. Chief among them is that Scrum is so dramatically different—in terms of practices and principles—from traditional project management paradigms that it requires team members to truly reorient their attitudes and working behaviors. One common way to initiate a Scrum transformation is through a pilot project. But even then, how does a team that's never used Scrum before tell if a project is a strong candidate for a successful pilot?
Lately I've noticed a fair amount of discussion surrounding the utility of task estimation. The question seems to be: is it really useful to estimate the time required to complete tasks, or is it unnecessary and counter productive to estimate such small units of work? If we're already using some form of estimation for stories, is task estimation really all that useful, or is it in fact thinly veiled micro-management?
An Exercise in Agile Facilitation
A leader is best when people barely know he exists, when his work is done, his aim fulfilled, they will say: we did it ourselves. Lao Tzu, Chinese philosopher (604 BC - 531 BC).
The project manager leads. The project manager directs. The project manager plans. The project manager manages. These are the expectations set upon, and sought out by those that take on the responsibility for delivering software projects to the Business. While unquestionably a critical role in the overall delivery mechanism, a project manager who becomes the central figure in the team can unnecessarily place the team in a position of risk. In fact, the project manager should approach the process with a less intrusive style, facilitating the team towards success from within and figuring out ways to develop systems that will survive any one person, themselves included.
What happens when your application software change cycle time shrinks from months to hours or days?
Over the past four years, we have overseen the deployment of hundreds of Web business applications all following agile methods. During the course of these projects, we have faced many challenges and found some surprising benefits.
This article describes some of the lessons we have learned and provides advice on how you might overcome some key challenges in your own agile projects.
A lot of heated debate is going on topics such as "Can we develop software using an offshore model with agile methodologies?" This article is my humble attempt to give more insight on this question using a story to describe a real scenario with some assumptions and with not so real people.
Twenty years ago, Clarke Ching fell in love with programming. Then he got a job doing just that and fell out of love within five years. Fifteen years later, Clarke sought the help of a well-known programmer for advice on how to rekindle his dormant passion for programming. The advice Clarke received led to a greater discovery.
Before you schedule or moderate another retrospective meeting, read this column by Esther Derby. In this week's column, Esther offers five tips that will help improve the productiveness of retrospective meetings. You'll also learn how letting the meeting participants run the conversation will solicit more feedback and ownership than traditional moderation methods.
Few agile sprints go exactly as planned. Many sprints encounter problems that must be corrected, and some go smoother than planned. The key to future successful sprints is to learn from past mistakes. The process of formally reviewing your sprint is called a retrospective. Learn best practices for retrospectives from this article.
Recommended Web Seminars
Agile Connection is one of the growing communities of the TechWell network.
|Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery. Join the conversation now!|