I’m back to blogging now having returned from our great 6-week trip on our new boat in Canada.

I have been contributing to various Agile LinkedIn and other forums – about what works in Agile, what doesn’t. Whether or not Scrum = Agile, if you can offshore and be Agile, how to develop with agility, etc., etc.

The funny thing is that what I blog about is more often my experiences with our “Practical Software Methodology”, not “Agile”. From what I see in blogs and discussion groups, “Agile” (with a capital “A”) means Agile/Scrum or Agile/Kanban – strict adherence to every step and recommendation like a religion. Whereas there are a lot of processes that can follow the Agile Manifesto’s tenants and principles and not be Scrum or Kanban. I call those “agile” (little “a”) or Agile (without the quotes). I think they are realistic for the majority of today’s software projects.

“Practical Software” was the process implemented at Azerity, my start-up. For years prior to starting Azerity, my goal was to take the best practices learned at Ford Aerospace on Government projects plus leverage the work we did with Carnegie Mellon on SEI Assessments (now referred to as CMMI) but throw out the bulk resulting in a lean and clean process for start-ups. As my start-up company grew I was able to hire a top manager from Ford Aerospace and together we implemented the tools and processes we later coined “Practical Software”.

With our Practical Software Methodology we were iterative, produced code quickly, short release cycles, high quality and high customer acceptance. In parallel, we maintained our on-line DOORs requirements specs, our “bible”, which were part of our process and which were accurate, tested, used by developers, QA, the Call Center, and Consulting. When we sold the company, the on-line DOORs specs were key to the value of the IP. Other developers could be hired, people come and go and even I could quit and the DOORs specs lived on. We were able to maintain those accurate documents with minimal cost because they were part of our development cycle and were iterative. They were not big waterfall Word docs but living breathing statements which matched the tasks assigned to developers to implement/update.

• We were small and we honored individuals, required feedback and interaction. Our process and tools supported and enhanced the interaction, didn’t detract. We had no organizational silos. There was no throwing of documentation over the wall to the development team. We were a cohesive, single entity building an exemplary product. Quickly. With very few engineers.
• Our goal was working software since that’s what the customers wanted and what we were paid for. Our process required us (me primarily) to have the documentation/specs to be in place in time for testing but the docs were a reflection of the code, not the up-front mandates from the waterfall era.
• Because two of the three co-founders plus other key members of the company came from the customer’s industry, we had the unique advantage of knowing what the customers in our space wanted so the software was accepted and loved by our customer base.
• Because I was one of the co-founders, I had the “red pen” and could slash out features if we needed to make a hard release date or visa versa, move the date if needed; thus able to respond to changes, not follow a fixed plan.

We followed the Agile Manifesto tenants:

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

Agile and it’s related methodologies (XP, Scrum) were born in parallel to Practical Software. I was previously a skeptic about Agile because whenever I heard someone talk about implementing “Agile”, they also added “throw out documentation”. Just talk. Sticky notes on a white board. Since my background is building large-scale mission critical software applications with extensive business practices and policies incorporated in the code, where the product was already so large even I was having trouble remembering every business requirement, I couldn’t envision how our product would/could ever be managed, evolved, and maintained. Plus our process which included on-line documentation was so clean and efficient it was hard to understand why other companies were struggling. (I’ve since come to realize that others haven’t found the secret sauce – how to maintain documentation in parallel without impacting development timelines).

A few years ago I was converted from an Agile skeptic to a proponent. The company that bought Azerity was implementing Agile or a hybrid thereof. I became a certified Product Owner. The interesting thing about my Agile training was that my objections to Agile ended up being objections to some form of Scrum or to a misunderstanding others had of the Agile principles or to some other misuse of Agile tenants. In reality, what I learned was that at the core of Agile (the Manifesto) were the very concepts that were at the core of Practical Software. Which makes sense. The initial proponents of Agile were seasoned software professionals who looked at how waterfall/phase-gate projects were being done, saw the issues, and proposed a better way. We at Azerity looked at how the big government waterfall projects were done, saw the issues, and proposed a better way. Many if not most of our findings were consistent.

I now believe the industry is being improved overall by the consistent message and training coming out because of Agile. I still see issues in the Agile communities:

• There is still a tendency for some to convert the statement of “Working software over comprehensive documentation” into “No documentation”.
• Scrum to me seems too rigorous to have innovative iterations on a less structured schedule.
• Agile seems development-focused and thus loses some of the bigger-picture concerns such as delivery, customer upgrades, other organization’s needs.

Both Agile and Practical Software solved what I saw in government and commercial software companies as the main issue – the issue of organizational silos and phase-gate workflow. “Business people and developers must work together daily throughout the project.”

I am now an Agile proponent (or should I say “agile” proponent). Please excuse me if I’m sometimes blogging about my “Practical Software” experiences ☺