Has anyone ever mentioned the two P’s to you? Product and Process? These are two words I have kept in my mind since my early days with Rational Software. I always believed if you could be good in both areas, then you would be seen as one step above many. It seems that most people have one or the other but few have both.
For me, Product came first as I supported customers and assisted them with their ClearCase questions. Product is one thing that has remained with me over the years and my portfolio has grown to show that.
But when did I get involved with that other P-word, Process? The answer to that question is the basis of my post this week.
It’s process time!
MY INTRODUCTION TO PROCESS
Let’s step back in time a bit. Do you remember RUP? The Rational Unified Process? How many years back did that just take you? I remember when RUP first came out. I was on the Suites and Integrations team and I installed RUP. Why not right? Something new to try and experiment with. Boy, was that a mistake.
Reply to this article if you are one of the many who installed all that RUP had to offer and crashed your brain in a web of confusion. I was not a Process guy then, but I did understand what I was reading. Then work took me away from RUP and back deep into tooling.
It was not until many years later when I had another brush with Process. This time I was working for an investment software company in Boston and one of the teams I was supporting at the time was heavy into XP programming. Wow! They were pushing a release every two days.
But, once again, I was pulled from Process and delivered back into tooling. Thankfully my job functions would change ever so slightly so that I would not get bored and want to leave the industry. There is no way I would have been able to stay in support all that time.
Fast-forward a bit and I find myself working side-by-side with the director of infrastructure architecture for a big company. The director was responsible for implementing the entire look and feel of the tools we had in place and for documenting the usage patterns for each tool. I provided guidance on best practices for the usage patterns and documented the newly-defined Process.
While I refer to this as Process work, it was not taking a proven, established Process and rolling it out to the business. We were building the Process from scratch and customizing every piece along the way. Because of this my learning of Process went up exponentially in the two years I spent on that engagement.
JUMPING IN & WATERFALL vs. AGILE
I always say: “The best way to learn something is to jump in with both feet.” People learn things better when they are put in a position that challenges them.
For example, last year I was working with a client in the role of a coach. I was actually one of many coaches. More particularly, I was a tooling coach responsible for Rational Team Concert (RTC) in an environment that was attempting to develop software using Agile methodologies.
Prior to this work I had been involved with Agile projects but none to the degree of this particular engagement. The task at hand seemed simple. We were to implement Agile by establishing multiple teams and then were to train those teams how to develop software the Agile way. This task was made complex and posed interesting challenges simply due to the amount of people who were used to creating software using a Waterfall approach.
For those not familiar with Waterfall see the diagram below:
The approach starts first by creating a bunch of requirements, then designing a solution to meet the requirements, then implementing the solution, verifying the solution does in fact meet the stated requirements and then running into a maintenance mode. There are slight variations to this but the point is that you will spend a lot of time and money before being able to deliver anything in waterfall.
On the other hand, in Agile you are constantly delivering something. A software development team will work together to discover, design, develop and test in a very short period of time and then they will do it again. It is common for an Agile team to deliver something bi-weekly, weekly or sometimes daily.
When I started this engagement I was introduced to a new Process that had been gracing the software development world. This Process was referred to as SAFe Agile and at the time I had never heard of it before.
Fortunately, I was being looked upon for my experience as a tooling coach and I was able to leverage the time I spent coaching people on the proper usage of the tool and turned this time spent into an opportunity to also learn the process. In an effort to be the very best I could be and provide significant value to the client, I did what I have done so many times before.
I started writing!
For me, when there is something new I want to learn I will write it down. Often times, this will lead me in the direction of creating official documentation for training the business. To date I have created many training presentations and documented tooling standards and proper usage of tooling for all of the companies I have worked for.
I saw SAFe Agile as an opportunity to learn something new and I was fired up to take in everything I could about it. Finally, a process I could really get into.
The team I was a member of was large and consisted of tooling and process coaches. In every discussion there was mention of Process by the Agile coaches. I would listen and take careful notes. Then I would go back to my desk and type out what I learned. Constantly doing this left me with a significant amount of material.
DEVELOPING A GUIDE
I decided to take the material I had compiled and started to organize it into a single document with a flow and an outline. This document was then sent out to other members of the team to contribute content and provide their feedback. After several months of back and forth we had a document worthy to present for approval to the business.
This document was identified as the best practices and standards guide; How to use RTC and a SAFe Agile environment. The document was read and accepted by the business and adopted as the governing set of rules for any software development team starting a new Agile process.
Once the standards guide was published, I found myself continuing to document things. While training everyone on the Best Practices and Standards guide, I would get the same questions from people. “Now that you have told me what, can you show me how?”
There was a clear need for some follow-up guides. These would be a series of role-based usage guides. The standards guide was great for showing everyone a set of rules to lead their projects by but I had intentionally left out the instruction on how to do things.
In closing, this is how I got started with Product and Process. How about you?
I welcome discussion and look forward to you all sharing your P-word stories with me. Which one did you start with and where are you today? Are you still focused on one and never got a chance to work with the other?