Posted by Robert Merrill on October 6, 2010 under Agile Methods, Estimation, Project Set-Up, Waterfall (SDLC) |
Thank You to the three Wisconsin IIBA chapters who hosted the fourth annual WI BADD™ on Tuesday, 10/5/2010, and the firms that sponsored it. I met some new people and learned some new things, and I know that was a lot of work to put on.
Thanks also to the enthusiastic audience for my talk, “Room To Breathe: The Role of the BA in Shaping Early Project Expectations.” If you would like me to speak with your software sponsors or development group about the project target, estimation, and commitment problem, please contact me and we’ll set something up.
Several of you requested additional material on the estimation problem. Here are a few things:
Thanks again, everybody at WI BADD™, for a great day. I hope to see you again on Tuesday, 10/11/11.
Posted by Robert Merrill on May 4, 2010 under Agile Methods, Uncategorized |
I’m always on the lookout for where I need to be heading with my practice, and the idea of Agile User Experience Development is now on the short list.
I’ve been on teams with some fairly good usability/user experience people over the years, and they love the waterfall. Identify all the users, develop all the personas, and then make a complete set of wireframes and subject them to some level of user testing before doing a whole lot else. The result can be months of calendar time and up to 20% of the project budget gone, and you still don’t have any working code, and therefore the accompanying established team velocity that lets you hold the ever-present launch-date wolves at bay and keep the project from turning into a Death March. Read more of this article »
Posted by Robert Merrill on December 17, 2009 under Agile Methods, Waterfall (SDLC) |
Serhiy Kharytonov published a fine summary of software methodologies for non-technical leaders at Executive Brief. He makes several excellent observations, but he also perpetuates a destructive myth. I’ve worked with all three of Waterfall, RUP, and Agile, and here’s my take.
Excellent observations
Then, stay agile in the approach to the process itself, constantly looking back, re-evaluating and revising the development process until it fits your current circumstances most successfully.
If you learn nothing else from Serhiy and I, learn this. Change from a culture of blame-fixing to a culture of continuous improvement, with no political unmentionables, and you will get a lot more value for your software-development money, and everything else besides.
Then, if you want to learn one more lesson the easy way rather than from a painful and expensive experience, Read more of this article »