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.
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.
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 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.