Not to sound trite, but do we really care what "it" is called?  Last month's newsletter article was about holistic vs. dogmatic agile.  This month the topic is similar.  There are many zealots that will say you have to use Scrum, or Lean, or XP, or...  Our response is "Really?  Why?"

 

The book of the month in the last newsletter was chosen because it is very holistic in its view of agile.  The book talks about Scrum, Agile Unified Process, XP and others with the point being that it is possible to take the best from each of them and use as necessary.  We agree wholeheartedly!  We like to say agile isn't about HOW you do it, but WHAT you get.  If you are building the highest value software, with high quality as quickly as possible, you are most likely being agile in some fashion.  The how doesn't matter as much as the result.

 

It is why the courses we list at www.agileforall.com/courses almost all have a section about agile principles.  The principles (derived from lean manufacturing principles) drive the agile process practices that we all use.  Knowledge of the principles allows us to make principle-based decisions and create principle-based solutions to problems we encounter.  We always tell our students, and show them with real world examples, how agile process problems can be traced back to breaking one or more of the principles.  We believe this knowledge makes the difference between an average agile team and one that can be exceptional!  Continuous improvement happens when teams are able to effectively analyze themselves and find ways to get better.  This can only be done by continuing to build on the foundation created by the principles that drive the practices.  Changes that violate one or more principles will not be improvements.  The great teams know this and avoid those pitfalls.

 

Just for the record, we generally teach a Scrum/XP hybrid approach to agile unless we are requested to do something different.  The lightweight Scrum management wrapper while using many of the common eXtreme Programming practices is easy to learn and can lead to fantastic results in a short time.  But again, we don't really care what you call it, or even on the exact practices, as long as the changes are based on the same principles and achieve the necessary results so the organization is happy, then we will be happy as well!

Recently on my blog a comment was posted about iteration demos. The reader was questioning some of the practices their organization was using for the demo.  In particular were the right people present, do they really dig deeper after the demo to learn from what they heard, and finally was 15-20 minutes enough time to allow for the meeting.  These are all great questions, and I hope more organizations will be asking themselves the same things.  I believe demos can be very useful tools for product improvement if done properly.  To me that means you have the right people in the room, you adequately reflect on what you learn, and you take enough time to have meaningful interaction during the demo.  In other words, you should ALWAYS have these questions!

 

Having the right people in the room seems like it would be the easiest problem to solve.  Is it ever bad to invite more than just a core group of people?  I can't think of a single instance when inviting a stakeholder or user caused a project failure.  I can think of many occasions when doing so helped create a much better product.  Inviting anyone that may have legitimate input seems like the right way to go.

 

How about digging deeper and spending enough time?  These are harder problems to solve because people get into a rhythm which can be hard to break.  For starters I like to ask someone that has never seen the new software to run the demo if possible.  It is amazing how much you can learn by watching someone using the software without ever having seen it before.  I also tell team members not to watch the demo, but to watch the people watching the demo.  Learn from their body language and what they aren't saying!  Spend enough time so everyone believes they have seen and reasonably understand the new features that have been demonstrated.  THEN ask for suggestions and improvements.  Go back over areas if necessary.  This helps people see, process and respond appropriately.  It also helps make sure the time taken has been sufficient.  If we spend time during each feature demonstration to ask questions we run the risk of people hitting a mental threshold where they will simply become unresponsive.

 

Remember, iteration demos are done with one purpose in mind - create a feedback loop for the team so they can iterate toward the best possible solution.  Too many teams see the demo as a way to show the product champion/owner what they have done, and not as a way to get feedback on how to make it even better!