In the future, you can expect some changes in most product development processes and methodologies. As time passes and schools of thought become more learned, you can expect their lines of thinking to change accordingly. Anything that may have been thought to be beneficial to product and development in the past may be proven otherwise in the future. And consequently, changes will be made. But not everything will change. In this video, the speaker discusses some of the facets of product development that may be altered and others that may stay the same. Agile development is one common thread tying…
One way to resolve a pesky problem during development is to address the issue in a prototype. When you’re knee-deep in the process of creating the first version of a product, and you’re encountering roadblocks, your troubleshooting should involve creating a prototype to resolve your problems. By doing this, you’re releasing your product to users and getting continual feedback. Then you adopt agile development methods and just release iterations thereafter. Eventually, thanks to heady release planning, you’ll have a refined product and a bunch of resolved issues. Instead of struggling with long plans, you can apply the prototyping method to…
Scaling a business is not the same as scaling your Scrum methods.
Why? Because scaling your agile development methods isn’t dependent upon proportions. Scrum principles don’t change according to the size of the company or application. For this reason, you’ll need to make unique considerations. But just because there aren’t any variables within the principles themselves, doesn’t mean you don’t need to take precautions to minimize roadblocks and challenges while scaling Scrum at your company. Here are some suggestions: Don’t be in denial about where your team members stand. Some of them…
With agile development methods, you sometimes encounter a situation where there are competing schools of thought on how to move forward.
Such is the case with story points for legacy bugs. Naturally, there are positives and negatives to weigh on both sides of the debate. By deciding to assign points to bug-fixing, you are making it possible to track the true capacity of the team to accomplish work. By not assigning points, the velocity reading is somewhat muddled because it’s not factoring in the bug-fixing. The author of this post…
Release time. Are you prepared? If you haven’t devoted enough resources to planning your Agile product release, there’s a chance you’ll hit a brick wall and wonder What happened? Joe Little from Agile & Business has some pointers to keep you on track. The article is a tad heavy on double-speak and there’s a blitzkrieg of parenthetical statements, but if you look past that, there are some good takeaways that’ll assist your Agile product development, including the 7 steps of release planning in the Scrum mindset. Here are the first 5:…
When it comes to testing, there are no shortcuts.
Additionally, the more testing you do, the more bugs you’ll catch. Testing is one function of development that can stand to be done in quantity, in addition to quality. You can test a piece of software indefinitely. There will always be fixes to find. But realistically, there is a cutoff date. And that arrives when the product needs to ship. That’s it; testing over. It’s your duty to ensure that testing is part of your best practices process up until the software ships,…
Is your Scrum Team Failing? When adopting Agile and Scrum, many expansion stage software companies take the appropriate steps, employ the processes and tools, and measure their velocity, only to ultimately fail to deliver quality product on deadline. Why is that? It’s usually because those companies neglected the Agile Manifesto’s first value: Individuals and interactions over processes and tools. Software companies can do all of the right things, but if they spend very little time examining the people on their product development team, then those companies inevitably violate Agile’s primary principle—and fail. The people executing the process matter and if…
When dealing with Scrum and agile techniques, teams often have a “but” caveat tagging along, meaning: “We are practicing Scrum, but our sprints are anywhere between 6 and 8 weeks” and “We are practicing Scrum, but we don’t always deliver working code at the end of the iteration.” Joel Tosi examines these “buts” and provides problem-solving answers that’ll help clarify the process and assist agile product development. Some of the “buts”: But Scrum says we need a Scrum Master Tosi says that if Scrum Masters were “making agile software development and delivery so…
When dealing with Scrum and agile techniques, teams often have a “but” caveat tagging along, meaning: “We are practicing Scrum, but our sprints are anywhere between 6 and 8 weeks” and “We are practicing Scrum, but we don’t always deliver working code at the end of the iteration.” Joel Tosi examines these “buts” and provides problem-solving answers that’ll help clarify the process and assist agile product development. Some of the “buts”: But Scrum says we need a Scrum Master Tosi says that if Scrum Masters were “making agile software development and delivery so…
Agile is the gateway to success for many companies.
There are startups that dove head-first into agile development and reaped substantial rewards. And there are other examples of companies that have struggled for years before adopting agile development methods and finding their niche. But with the good, there is bad. Some companies that have adopted agile, but just can’t get their operation running smoothly. For these companies, a best practices process refresher is needed. Here are some agile-related tips: Use velocity to measure your team’s production. In a similar example…
