We’ve all heard about Agile, the good and the bad. While to some Agile is relatively new, I started being Agile when I led the Intel Inside(R) Program System in the 1990s, before the Agile Manifesto, XP, Scrum, and the various other approaches were developed. The project taught me the value of minimizing non-value-added deliverables; the value of prototyping; and, more important, the value of giving a product, even if incomplete, to the customer as soon as possible.
I had to do waterfall at one of the companies I worked for after Intel in the mid 2000s but I was able to layer an Agile approach on it. This approach, which I’ve described before, is known as Commitment-Based Project Management or CBPM for short. Based on an approach Intel developed in the early 1990s for its semiconductor development, it is a domain-agnostic (that is, you can developed any product or service, not just software, using it) approach. By layering it over a product development methodology you can bring agility to your project.
At my current company we have been doing Agile for about three years. Joining in the middle of last year, my first assignment was to determine how best to re-energize the use of Agile. Like many organizations, Scrum (the consultants didn’t call it that but it is/was Scrum) was brought in, a simple methodology delivered, training provided, and a “go forth and be successful” message given to the teams. Obviously, as time passed, approaches varied and to some degree had retrograded to waterfall in some cases.
Just before I started with the company the head of QA had formed a small team to address this issue. I joined the team and started leading it. We hypothesized the needs, validated them with an internal survey, and delivered what was needed. As you may suspect, lots of what was needed was training, support, as well as some coaching. Key areas where training was needed: writing user stories; estimating and planning; conducting reviews and retrospectives (if you are not familiar with these terms check out one of the many excellent books on Scrum or check the web.)
My team and I developed and delivered the needed training. Each session averaged 30-40 people during lunch hour, which is significant in a company of about 220 people with about 150 in our IT/product development group. We determined we needed some help training the business side so we brought in Certified Scrum Product Owner training, getting participants certified (a nice incentive for them) as CSPOs or Certified Scrum Product Owners. We scheduled webinars that seemed interesting and set up our training room for people to attend.
On the coaching side we decided we needed an external coach to come and help one of our key projects. Since this coaching is not inexpensive we focused on this critical project to get the successes we needed before deploying further coaching. I’m happy to say that the executives are discussing extending the coaching contract to include at least one other project.
Obviously, I needed to know about Agile so I had refreshed my knowledge and attained my Certified Scrummaster (CSM) designation prior to it. It helped me make sure that I could articulate what Agile was all about. Give it a try if you haven’t.
