Welcome to Agile Savvy

Welcome to Agile Savvy.

       Can your software development team say they truly build GREAT software?
       GREAT software with few, if any, bugs?
       GREAT software that make their customers deliriously happy?
       GREAT software that delivers on budget and on time with a happy customer?
       GREAT software where code can be changed without fear of breaking something else?
       GREAT software built with a happy development team?

If the answer to any of these questions is "no" then you need to become Agile Savvy.

The first sentence of the Agile Manifesto states "We are uncovering better ways of developing software by doing it and helping others do it." That's the difference. Agile continuously causes us to ask ourselves (before, during and after the project) "what features, processes or practices can we change to make our product better?" Agile IS lightweight but it's success requires MORE discipline, MORE reflection and adaptation, MORE collaboration and MORE thought than traditional methodologies.

However, in order to be truly successful you must become...Agile Savvy.

Learning Agile Savvy 101

Understanding Agile is not easy. Mant think that it is easy. Let me tell you that it is not. You wouldn't expect that a methodology that manages complex software development projects would be. Just because it's lightweight doesn't mean it's easy. So here's a clue, if you thought you would learn Agile Development (any flavor) but you didn't put in much work, time or thought into it then it's not Agile. Learning Agile Step 1) Read the Agile Manifesto's 4 Values and 12 Principles (link). OK, you've read them. Now spend some time and understand them. Learning Agile Step 2)    [Read More]

Savvy Customer Involvment

In traditional development methodologies the customer is involved at the very beginning, disappears during construction and reappears in time to test the completed system. The Change Request procedure is make particularly difficult so few, if any, changes are made to cause schedule shift.

Just because this is how it has been done for 40 years doesn't mean it's the best way to create software. IT was done this way partly because it closely follow a business contract. Here's what I want, you do it and I take it at the delivery date..agreed, and we all sign on the dotted line. This may be fine for delivering 10,000 widgets off an assembly line, or for building a office building. But it's not fine with software development. I'm going to show you why continuous customer involvement is so important through a metaphor.    [Read More]

 

Thanks for taking the time to read these and information on my website. I would be happy to receive any comments that you may have.