In many ways, estimating project budgets or dates for agile projects turns out to be irrelevant. If you have a ranked backlog, and you finish features, you can always stop the project if you hit a particular date or cost.
Almost every manager I know wants to know when a project will be done. Some managers decree when a project will be done. Some managers think they can decree both the date and the feature set. There is one other tiny small subset, those managers who ask, “When can you finish this set of ranked features?”
Giving your clients the opportunity to voice their opinions after conducting business with you is a great way to express your interest in continuing to work with them. Just make sure you're earnest in hearing their thoughts and that you don't simply think this is accomplished with a survey alone.
Giving yourself, and your team, the necessary time to adapt to and move on from change is the healthiest way to make sure that everyone is back on the same page in a timely manner. Learn how to avoid prolonging the necessary time to "heal" by minimizing turbulence.
I always recommend to teams newly transitioning to agile that they keep every iteration the same length. This helps them learn to manage their time, and after a few iterations they'll start to get a rhythm. Hopefully, they'll learn to work incrementally, doing testing and coding concurrently as part of one development effort, so that user stories are finished throughout the iteration, and testing isn't pushed to the last day.
The age-old expression "you never get a second chance to make a first impression" is still true to this day. So often the way we greet people, or fail to greet them, sets an irreversible path of leaving others feel completely unwelcome, even if that wasn't the intention.
Have you ever had to contend with a demanding developer? A testy tester? A cantankerous customer? Why oh why do people act that way? Rather than wondering why they act that way, it can be helpful to consider the circumstances that might account for their behavior.
My team is in the middle of one of the hardest projects—we call them "themes"—we’ve ever tackled. We’re a high-functioning agile team that has helped our company grow and succeed over several years now—we “went agile” in 2003. Here’s one thing I know for sure: No matter how many problems you solve, new challenges will pop up.
Giving your customers the opportunity to provide feedback is great, but only if you don't fall into one of the four traps that Naomi Karten describes in this article. Let your customers know that not only do you want their feedback, but that you'll actually use the important info they give you.
Lisa Crispin dives into the "we're all in the same boat" theory and explains how it can't be more true in the software development world. From the need for common goals to going beyond taking responsibility for the team's actions, each team must know that you're going to fail or succeed together.