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. |
||
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. |
||
5 Tips for Choosing Your First Agile Project When transitioning to agile, applying agile methods to a single project is a great way to get started. However, care must be taken to ensure the project you choose is appropriate—it shouldn't be too large, take too long, or be too risky. Here are five tips to help you pick the right project for your agile pilot. |
||
Driving Continuous Improvement to the Entire Organization In traditional agile approaches, retrospectives are valuable to team improvement. However, when teams encounter organizational issues beyond their control, such as project structure, interorganizational communication, or resources, it's more difficult. Here's how to expand continuous improvement to the whole company. |