I formed RGalen Consulting Group in 2001. It was an independent software development and testing consulting firm that provided training and consulting services focused on sharing my experience for client improvement. Even though I had many permanent leadership roles, I maintained and grew the practice with the intent to eventually focus 100% on my coaching and consulting.
The focus of our client improvements were around:
Software Development & Delivery
Software Requirements, Planning & Execution
In the early days of the practice, I became “Agile” and that has permeated all of the above ever since. And not just agile in word or because it’s a “hot topic”. No! I’ve got agile in my bones, in my DNA, and I’ve been fortunate enough to be part of several companies where we changed the entire culture, not just technology.
Over the years, I’ve partnered with several firms to increase my bandwidth and ability to serve my clients AND have a broader influence than a sole proprietorship. They were:
Now, I’ve decided to move on from Zenergy and begin a new chapter in my agile and client journey…
February 5, 2018
I’m experienced enough in the Scrum community to remember several early attempts at assessing the maturity of agile and Scrum teams.
- Around 2008 – 2010, the Nokia Test was originated by Bas Vodde in his work at Nokia. Jeff Sutherland and others have referenced it.
- Then the Nokia Test evolved into the infamous Scrum-But test around 2010. Aka, “We are doing Scrum, but…”. Below is a publication from 2011 that Sutherland shares about the evolution of the test –
- Around the same time these were evolving, in 2007, Ahmid Sidky wrote his dissertation focusing on an agile assessment framework. He called it the Sidky Agile Measurement Instrument or SAMI. And to my knowledge, it was the first attempt at a holistic instrument or framework.
My point in taking you down “history lane” is that agile assessment tools and frameworks have been thought about since ~2007. So, for the past 10+ years.
The problem is, that none of these, and the ones introduced later, have really done an effective job of helping teams improve.
I’ve been speaking at TechWell events since around 2000. First, I started out with track talks. Then I started sharing full-day and ½ day workshops. I’ve also been invited to deliver several keynotes at the Star and Agile Dev / Better Software conferences.
All-in-all, it’s been a professional relationship that I’ve really enjoyed.
Recently, the long-time program chair, Lee Copeland, stepped aside. I truly want to thank Lee for the years he invested in helping me grow this side of my consulting practice. I owe him a great deal.
Program Chair & Talent Scout
Given my history and experienced, TechWell approached me to help fill the Program Chair role for the:
- Agile Development
- Better Software
Conference series going forward.
The conference has a West / East format. The West version is held in Las Vegas, typically in early June. The East version is held in Orlando, typically in early November.
The programs are usually developed 8 months in advance of the conference, so you need to reach out to me early if you’re interested in participating.
The program chair is responsible for pulling together approximately:
- ~4 Keynote presentations
- ~4 full-day workshops
- ~20 ½ day workshops
- ~60 60-minute track talks
across the four major themes (Agile Development, Traditional Software Development, DevOps) of the conference.
And the talent scout part of my role will focus on looking for new and interesting topics, speakers, and formats to introduce to the conferences.
Every year I try to spend time on my own training. I usually start thinking about two things the year before:
- What are some knowledge gaps that I have that I’d like to fill, and
- What are upcoming trends that will cause me to become obsolete if I don’t get ahead of them?
Then I review the available courses and I’ll try to come up with 2-3 things that I’ll focus on for improvement.
Last year I posted my first "Sharpening the Saw" post in June. That inspired me to do it again for 2017, but closer to the beginning of the year. You'll probably see this become an annual post to remind me (and perhaps you) to plot a journey of continuous learning.
I’m often asked why I do what I do. It’s simple really.
In the late 1990’s I was an early adopter of Extreme Programming while working at Lucent. I was in a leadership role, leading software development and test teams, and it seemed to me to be an interesting way of effectively building software.
I had struggled with Waterfall approaches for years. I’d even worked hard at refining my estimation processes. But my projects were inevitably challenged and many failed to meet critical criteria. That is – projects that met all aspects of our stakeholder expectations.
When I stumbled on XP, it just…resonated with my experience. It also resonated with my leadership style and beliefs that PEOPLE were the central success proposition in software efforts.
Not: risk plans, test plans, project plans, management spreadsheets, cost accounting, estimates, system requirement specifications, metrics, status reports, etc.
Potential clients often approach me with an immediate request for coaching. Usually they’ve attended one of my classes or heard about me from a colleague. Literally 90% of my business comes from these two sources.
Now usually they’re in a hurry to get me in. Often they want me to “drop everything” and come in for emergency agile training / coaching within a few weeks. I have to explain to them that my pipeline is usually fully engaged 3-4 months in advance, particularly for longer engagements.
Quite often I’ll try to recommend a solid colleague, but they often have the same constraints as I do. So the client usually will schedule something and wait. Often that waiting interval will allow “things” to calm down and for us to better plan our engagement.