Related Content
 |
When Buying New Software, Make Sure You're Getting What You Really Need The first step in any significant software procurement is to assure there is a clear definition of the business problem being solved. If you don’t know what you want, you aren’t prepared to negotiate for it, so you'll end up with a system or tool that isn't what you need—and you'll likely be disappointed at delivery. |
|
 |
The Dangers of Underplanning in Your Agile Projects Agile coaches often stress the importance of not overplanning because work is later changed or never done at all. But consequently, many teams then fall victim to underplanning and aren't equipped for a successful project. Here are some planning activities that are critical to do before your sprints start. |
|
 |
How Do We Land This Thing? Planning for Go-Live and Beyond Some project managers have little experience bringing a project in for a landing, so they can be dismayed or just blindsided by organizational change needs and stakeholders’ expectations at delivery. Here is a checklist of some commonly forgotten items to address when a project goes live, so be sure to plan for them. |
|
 |
Interface Grief: Is It Agile, or Just Bad Software Engineering? There are people who will use "being agile" to justify software engineering practices that could be perceived as lazy or even bad. The specifications are going to change, they say, so it would be a waste to engineer more to begin with than the minimum viable product. What's expediency and what's just poor practice? |
|
 |
Balancing Process and Tools The limits of a tool may lead us to realize that we are not working as effectively as we can, and often, changing a tool is part of the solution. But there are good and bad ways to select a tool and how you use it. In particular there are risks when you focus first on tools before considering the problem. |
|
 |
An Agile Approach to Change Management Many organizations are reluctant to introduce new tools or technologies, or even to update existing ones. The reason is often framed in terms of risk management, but agile teams already have the tools to manage the risk of change: testing and experiments. These approaches together eliminate gaps in risk identification. |
|
 |
Continuous Exploratory Testing: Expanding Critical Testing across the Delivery Cycle Continuous testing entails executing automated tests to obtain rapid feedback on business risks. Where does that leave exploratory testing? Obviously, it doesn’t make sense to repeat the same exploratory tests across and beyond a sprint, but exploratory testing can be a continuous part of each software delivery cycle. |
|
 |
Think through System Changes to Anticipate Quality Issues When you replace or significantly modify components of a larger system, too frequently we focus on whether the code we are building functions correctly. This is important, but it’s also short-sighted. It’s easy to introduce errors because we are changing interactions. Coding bugs are only one quality problem. |
