Agile Programming

 

Agile Software development is a development methodology orginated in 2001.  It begins with the “The Manifesto for Agile Software Development”

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

The four points of the manifesto are intriguing because it is a fundamental shift in IT of focusing on the human aspect of the development rather than the process itself. 

 

Now I’ve always been an advocate of following the process, but it doesn’t have to be any particular process.  One of the primary leadership concepts is to “Challenge the Process.”  If there is a better way, I’m all for that.  So I have two questions about Agile Development:

 

1.      Is this truly a “process” or a formal way back to “cowboy coding”?

2.      If it is a process, is it the better way.

 

So with question number one, Agile Development seems to be growing up and becoming a true project management process.  There is an attempt to partner with PMI and move into a formal development “process”, in the sense that it would be a set, repeatable, process.  My biggest fear in Agile Development comes from my personal experience with software developers.  Now please don’t be hurt if you are a developer, I was one once too.  However, developers have a tendency to want to do their own thing, or in other words “cowboy coding”, I have yet to meet a developer who would admit that they have developed code with any bugs in it.  “I’ve tested the code myself, and it has zero defects!” 

 

To finish question number one, I am moving toward question number 2:  Is Agile Development a “better way”?  Like with most software development projects, this will depend on the project manager and how well they keep the team on track.  With a cooperative team of developers and strong project management, I believe that the Agile Development principles (see http://agilemanifesto.org/principles.html ) are very sound and can result in happier customers.  But, this is a greater risk if the developers are not disciplined, the development could spiral out of control.

 

So my final assessment is that Agile Development can be a better way, if leadership is applied and discipline is followed. 

6 year olds and a Process Oriented Approach

I am having a wonderful experience this fall in being an assistant coach to my 6 year old son’s football team. I have been truly amazed at just how much they can learn and do at such a young age. While I’ve coached many different sports teams with my sons, this was my first exposure to coaching football.

On a parallel track, I’ve taken on a new position at work as the PMO Director for CDC/NCPHI. Once again this is another new experience. The same week I started my new position the leadership of our organization completely changed. In the process the new director was asking for a landslide of information about the projects within the organization. This request became a significant challenge within the organization, one that would end up falling on my plate.

So how does coaching a 6 year old football team and taking a new position with organizational change relate to one another? It all falls in the category of “what works and what doesn’t”.

Let go back to the football team. If you take 18 6 year old boys and put them on a grassy lawn what do they do? PLAY, not too bad when your 6. (or 40 for that matter). How do you get them to play football? Repetition! Everything our head coach teaches our team is done over and over and over again. He created a standard repeatable process and continuously repeated it, allowing time for process adjustments and continuous improvement. Wow, that sounds familiar!

Back to my new position, when the data call when out to our organization five different groups started to collect the data, organize, and format it in five different ways. By the time I got a handle on the request everyone was upset with all the different messages they wanted to turn in their own work and be done with it.  My group stepped in and started to apply a process to the data collection, developing a standard repeatable process to the data and worked with the data owners and in less than a day, we took all the scattered data and formatted it in an easy to understand format that was useful to our new director.

Whether it’s football (any age) or business the principles are the same, develop a standard repeatable process, allow for performance adjustments with a component of continuous improvement.  It is a formula that works.

Standards

I just returned from the National Immunization Conference in Kansas City, MO. Great BBQ and steaks! However, what I learned most was the affirmation of the idea that standards make the world go around. While speaking to a large group of highly qualified immunization professionals, including doctors, nurses, and highly educated pubic health professionals it hit me like a ton of bricks, they don’t understand what standards are, or what they do for us as information technology professionals.I was asked why developing a new vaccine ordering system was so difficult, when in this day and age we can go across the globe and use our ATM cards and get money from our banks, why can’t we develop an interoperable immunization ordering system. My response was that the banking groups got together decades ago and agree to standard business practices and communication standards. During this process each organization was willing to compromise on certain proprietary business processes for the greater good.In my current reading of Thomas Friedman’s “The World is Flat”, he discusses “10 Forces that Flattened the World”, of these ten forces one that hit home to me was “Work Flow Software”. The discussion of this topic came around to “standards on top of standards” and the two quotes that hit the spot were:

“Once a standard takes hold, people start to focus on the quality of what they are doing as opposed to how they are doing it. In other words, once everyone could connect with everyone else, they got busy on the real value add, which was coming up with the most useful and nifty software applications to enhance collaboration, innovation, and creativity.”And:“…software companies stopped competing over who got to control the fire hydrant nozzles and focused on who could make better hoses and fire trucks to pump more water.”

This illustrates the how we can use ATM’s around the world, the banking community stopped worrying about whose business model was best and focused on interoperability between systems. What a great lesson to learn. If every organization would remember that the work is more important than the process and accept the use of standards and design their systems within the framework of those standards, things would move much faster and efficiently.