When applying validation, should you limit yourself to the end-of-sprint review or demo—the practice most people associate with agile validation—or should you utilize other validation types where customers provide feedback? Where do the customers who attend validation sessions come from? In this article, you will learn about the importance of the ACVV and how to establish a vision to benefit the product and each project therein.
“Business analyst” is not a distinct role on Scrum or other agile teams. And yet, the goal for the team—to deliver high-valued product needs—requires strong business analysis skills. Ellen Gottesdiener and Mary Gorman describe the vital analysis work needed reach the goal, regardless of role.
One of the hardest daily tasks developers, QA, ScrumMasters, and product owners encounter is effective communication with others. Sound implausible? According to many articles, research, and personal observations, the main cause of project failure is not technology or hardware, but inefficient communication stemming from lack of effective communication between team members, incomplete business analysis, imprecise requirements, and vaguely formulated business objectives.
Your applications need to meet business needs, overcome complex processes, and provide instant results to customers. And, ideally, they’ll require minimal rework on your part. The first step to success is requirements definition. Here, Filip Szymanski offers some tips from agile methods that will improve your requirements—even if you haven’t otherwise adopted agile.
Charles Suscheck writes that if you’re in an organization that has signs of post-industrial orientation, now is a good time to take a fresh look at your organization’s underlying (and often oblique) belief system.
Matthew Gelbwaks writes that rather than applying a strategy to agile, you should apply the principles and values of agile to business or organizational strategy. Agile is the new way to compete and the new way to win at every level of the organization—from development to strategy.
Daryl Kulak explains that if we don't ask the right question at the beginning of the project, then no matter how well we answer, it won't be helpful. Perhaps the biggest difference between agile and waterfall is the question being asked. The scope of the project and any judgments of progress are related to this very fundamental question.
Len Whitmore writes on using agile practices for the development of software. In the ten years since the Agile Manifesto, the agile development domain evolved, as evidenced by such things as the six levels of planning: strategy, release, iteration, daily, and continuous, with strategy appearing to be the least evolved of the planning levels.
If you asked anyone in my team what agile practice is most responsible for our success over the past eight years, I bet they'd answer "retrospectives". At the start of every two-week sprint, we spend time talking about the previous sprint, identifying areas that need improvement, and thiinking of ways to overcome obstacles. But I wonder if it's not so much the retrospectives themselves, as the small experiments (to borrow Linda Rising's term) we try to address our problem areas.
The tag-line for Feature Injection is "As we pull value from a system, we inject features." So before we can start, we need to identify the business value. But how do we do that? This edition also expands on the 20/20 vision conference concept.