He's response was right on for me. He basically said that Crystal Clear is dead and pointed me to an article of his called "The end of methodology". Instead of trying to buy in on a whole package you should have a toolbox of good practices that you use to build the best methodology for your team in your current project with your current stakeholders. There's no way any off the shelf product will be the best choice, and most agile methodologies aren't even comprehensive enough to be called a methodology - it's just a set of practices that you need to complement with other practices to run a project.
That being said there are a few practices I'll never leave out.
- First is the story. Be it a user story or a light version or even a use case, but something that explains the functionality we desire in words that make it valuable for the stakeholders. And then make that story 100 % done before going to the next feature. This is where I've had most problems before going Agile. Sitting with a project that is almost done in every single end and then having months of work just tying it all up.
- Second is priority. That's really the essence of agile: Do what's most important first. If you do it in sprints, if you have burndown charts, if you code test first, if you have continuous integration - its all "processes and tools" and something we should value less. For every new story you start, ask if that's the most important thing to do - if this would be the choice if only thing could be added to what we already have.
- Third is the retrospective meeting. Without that we won't achieve the continuous improvement that makes the process ever better. This is where problems are brought to surface so we can do something about them and make our team gel. This is also, not to forget, where we can scratch each others backs about all the good things we do, making the team gel even more.
- Fourth is the demo. This is the developers moment of pride, and the product owners opportunity to make sure the assignment was carried out properly. Two good things make a right! Even a small bug fix may be understood incorrectly by the developer and it's a lot better to find it now than after the release. It's also a thousand times more time efficient to show what's been done and get immediate feedback that can be addressed and discussed than to just send over the software and wait for an email with comments. And if that isn't enough you should also see it as an opportunity to read each others satisfaction level.
- And finally the fifth, and that's the stand up meeting. If it is a low pace project it might be enough with a weekly stand up, but most projects benefit from a daily stand up. But remember to keep it brief! This is not the time or place to discuss designs or what you did last night. Also make sure everyone shows up, and that they show up on time. And remember, this meeting is for the production team to coordinate today's work and bring up immediate problems, not a status meeting to report progress to the project manager.
Best of luck, and I would love if you took some time to comment my post!