Do you recognize this early logo from Amazon.com? Future Now has a great article detailing how Amazon evolved their “add to shopping cart” implementation. From reviewing this summary of the evolution of one feature, we can see that Amazon decided there was value in reinvention. The improved the way their product did something over time. Have you?
Ask A Good Product Manager is a new blog just launched by Jeff Lash, who also authors How To Be A Good Product Manager, one of our favorite blogs.
A look back at the best from this week in the past.
Continue reading Flashback: This Week in the Past on Tyner Blain [Feb 23]
Barry Boehm, inventor of the spiral model of software development, may also be the originator of the CRACK acronym for the type of users we want on our projects. When defining (and executing on) projects, we don’t just want CRACK users, we want CRACK stakeholders. And we want them to stick around. In fact, we’re addicted to them.
Continue reading C.R.A.C.K. Users Are Addictive
We’ve been promoting use cases as the right way to approach agile requirements, and in a recent article, Alistair Cockburn stresses the importance of use cases. Over the last three years, he has found that teams that avoid use cases consistently run into the same three problems. We defer, of course, to Alistair as the expert. But we’ve been independently promoting this practice too. So today, we get a cookie!
Continue reading Cockburn Affirms: Use Cases Rule for Agile!
A look back at the best from this week in the past.
Continue reading Flashback: This Week in the Past on Tyner Blain [Feb 16]
A successful agile team requires someone on the team to act as the voice of the customer, someone to lead the developers, someone to lead quality assurance, and someone to organize, coordinate, and assure execution. For an agile team to succeed in an enterprise ripe with political resistance to agile, someone has to be the “voice of the team” as well.
You can approach this by classically assigning roles and responsibilities – but that isn’t the only way. Agile teams are most effective when they have specializing generalists who can mutably adapt to the immediate needs.
Continue reading Specializing Generalists and the Politics of Agile
Too much information about requirements or too little? Too much documentation or too little? Use the NICE framework to get it just right.
Continue reading The NICE Way To Think About Requirements
A look back at the best from this week in the past.
Continue reading Flashback: This Week in the Past on Tyner Blain [Feb 9]
How do you approach starting a small requirements project as part of a large initiative within a massive enterprise? Do you boil the ocean? Your customer knows she needs “requirements” to give to her development team. She asks you – what will you deliver, and how long will it take? Great questions. If you have to write a statement of work, with time/cost estimates, and a list of deliverables – what would you do?