There is a lot of information out there are agile retrospectives. I have a number of articles on them and there are plenty of places with information including blogs, websites, and books.
I’m working on a series about retrospectives, and have included a list of articles that are already written as well as some of the future articles. If you are interested in subscribing to get notified of the next post, please subscribe via email.
Will longer agile sprints or iterations cover up opportunities to improve and cause you to view these opportunities as unsolvable problems?
The typical agile sprint size is 2 weeks. What percentage of teams use 2 weeks? I don’t have statistics on it, but I’d guess over 90%. I’m working on a product where we are doing 1 week sprints. It’s a startup and things are changing a lot so 1 week works well. I also know some teams that use 3 week sprints and it is working for them. I’m not saying it has to be a certain number of weeks – but please don’t kid yourself with what length will actually work for you.
I’ve seen situations where people are doing 3 week sprints, but then have a 1 week “hardening” sprint. Personally, I’m not a big fan of hardening sprints. I can see many “logical” arguments on why people need them, but in the 3+1 week sprints – I’d say stop kidding yourself. You have a 4 week sprint! Maybe that is the best you can do right now and you are ACTIVELY working to eliminate the hardening sprint – but if you believe you will always need one you are likely stuck.
Read This If: You’re looking for some interesting observations on scope, change management, and iterations as well as willing to consider that maybe some projects are not that tough, in perspective.
2009 seems to be moving right along! Was 2008 tough or not so much? Will 2009 be better or 
worse? Are things sometimes LESS challenging than they appear?
The recent inauguration and oath of office that the US President takes has me considering just how small some project problems actually are. I was listening to a NPR story about the oath, and a few things jumped out (note that LISTENING to the podcast provides more than reading the article summary).
So where is the oath found? It is the last paragraph in Article II, Section 1 of the Constitution. It reads “I do solemnly swear (or affirm) that I will faithfully execute the Office of President of the United States, and will to the best of my ability, preserve, protect and defend the Constitution of the United States.”
Read This If: You want to ensure you are basing your project’s value on input from a true subject matter expert (for any type of project).
A fake subject matter expert or SME can derail a project. Improvements to your business should be based on the best information you have access to, not outdated or incorrect information. The acronym “SME” seems to pop-up everywhere. I agree that saying “subject matter expert” does not flow as well as SME, but the phrase drives home that the person should be an expert (and in the right subject)!
Subject matter experts are used on projects from IT strategy, to business process improvement, to software development, to organizational change . . . to name a few. They are supposed to impart the wisdom of what is actually happening, and often, what is needed. But if they are NOT an expert, then what? Are you basing the success of your project on poor information?
So what exactly is a fake SME? The basic premise is that they are someone who appears or pretends to be a subject matter expert, but is not. There are many types, but let me outline some of the more common ones: