Signed in as:
filler@godaddy.com
Signed in as:
filler@godaddy.com
Some people work in this challenging and frustrating space we call "agile project management" and never actually get to experience what it is like to see everything fall into place, resulting in an almost exponential improvement in solution delivery, out-sized sales growth and market share capture. For me, it happened on my very first agile project. That experience informed my thinking for every role I have accepted ever since.
In fact, I can confidently state that I know exactly what it takes to build a high performing "Team of teams" because I have personally played an integral role in such an accomplishment three times with three different firms:
1. Power Advocate (2009-2012; acquired, now known as Wood Mackenzie)
2. Commonwealth Financial Network software division (2014-2019; spun off, now known as Advisor 360)
3. CaseNet (2019; spun off and later merged into Zyter | TruCare)
Each of these success stories is best described as a "case study" and my experiences leading up and following each of these case studies had a direct bearing on how I played my role in each of them.
Boomerang Software
I stepped into the application software space from the business side when I accepted a position with Boomerang Software, a tiny start-up based in Belmont, Massachusetts which was developing a WYSIWYG tool that enables individuals with zero HTML experience to create their own Internet website. We launched our flagship product through a variety of retail channel partners, including online vendors and "big box" stores. I was employee number 11, hired primarily to help with sales and marketing. We had eight offshore developers.
As soon as we had paying customers, it was clear we had serious quality problems with several of the application's key features. The owner of the company asked me to assume responsibility for all tech support in order to prevent product returns by "keeping the software sold." I diffused angry tech support calls and quickly published a "Quick Start" guide that was provided in digital format to every end user that called in and also inserted into every unit prepared for our sales channel going forward.
To better serve our user base, I stood up a website hosting division to resolve confusing functionality in our FTP feature. Despite our ongoing quality problems, we grew sales and headcount doubled. I managed tech support and continued to write Quick Start guides for every version upgrade.
A year later I gathered requirements and wrote a lengthy functional specification document so that our developers could create a new e-commerce-capable version that some of our loyal end users were requesting. We launched that version into the retail channel with success, but the product was plagued by new quality issues.
Unfortunately, the new tech support tickets included complaints directly related to unexpected defects in the online transaction workflow. These defects were proof that our developers were not writing sufficient unit tests and functional tests.
Quality was still not "top-of-mind" with the owner of the firm. He had plans to launch a new product to compete with messaging app ICQ instead of investing in a proper re-factoring effort for our best-selling flagship product. It was late summer 2000 and the dot-com bubble was already losing air. After more than three years with that company, I moved on.
Chiliware
My next role was Production Manager with Chilliware, another software start-up based in Los Angeles. I was brought on board by a former Boomerang Software colleague, who doubled my pay and moved my family to Los Angeles. Chilliware was developing Linux applications. Our flagship product was a desktop-publishing application meant to be compatible with all variants of Linux.
The company was actually controlled by NFL Hall of Fame quarterback Fran Tarkenton along with his former NY Giants teammate Richmond Flowers. I was hired to oversee our product manufacturing and fulfillment vendors operations with a side responsibility of managing two technical writers who authored context-sensitive help files designed to optimize the end user experience.
Shortly after I joined Chilliware, the company's leadership made the crucial mistake of adding two additional Linux applications to the product development pipeline. At that time, Linux was a particularly tricky space for application development due to differences in the Linux OS space. Chilliware was actually taking orders and getting paid. Sadly the defect count for each product was too high to overcome. Fran and Richmond lost faith and soon made other plans for the $700K sitting in our corporate checking account. Without quality, you cannot succeed in this business.
Few people can say that their job was terminated by an NFL Hall of Famer but I can.
I packed up, put my wife and daughter on a flight back to Massachusetts, then followed them home in a 24-foot Budget truck, arriving in Malden just before midnight on September 10, 2001.
Immediately following 9/11, I did a short sales and marketing stint with Unison Information systems, a boutique data storage vendor. That was followed by an 18-month run with Building Engines, a SaaS startup serving the commercial real estate management industry. We had a team of six and I learned so many valuable lessons in that role, the most important one was that I really enjoyed the role of Business Analyst.
ASP Platform Services
I was hired away from Building Engines by another former colleague from Boomerang Software to help him launch a SaaS offering called the M4App. His goal was to create an application that could automate the real estate foreclosure process in Pennsylvania, where county sheriffs handle all real estate foreclosures. Rural county sheriffs with small IT budgets were drowning in paperwork. A paperless system was needed to help all stakeholders: the sheriffs, the foreclosure attorneys and the mortgage lenders.
Working remotely for the next 18 months from Massachusetts, I had a blended role of Business Analyst, Project Manager, QA Lead and Trainer. I managed two developers. While gathering requirements for an initial proof of concept, I discovered a way to use XML to solve our biggest data sharing challenge. I used Visio to document a 21-step data workflow. I created an XML "data hand off" template for the attorneys running MS Word. That XML template enabled digital submission of the crucial Legal Property Description, which means the local newspaper no longer needs to manually re-type the Legal Property Description into their system for public notice advertising. We relieved the paperwork bottleneck for sheriffs and reduced costs for all stakeholders.
During the latter stages of development, my lead developer proposed releasing to our staging environment every Friday morning for me to validate against my test cases. Every Monday afternoon, we released to production. My lead developer referred to this as "XP."
The original SaaS solution I designed, documented, tested and validated for production release in 2005-2006 is still in use today, which reflects my hard-earned dedication to quality.
JP Morgan Chase
My next role was a 10-month contract with JP Morgan Chase on a small data security project involving the disposal of failed hard drives. It was a dream role for someone who is innately curious, as my skills were simultaneously tested in the areas of business analysis, technical writing, product ownership, IT vendor management, and training. That role provided key insights in two important areas: 1) how policies drive process definition; and 2) how a giant financial institution might approach the risk of data theft when a hard drive fails, whether it is part of a tower PC located in corporate headquarters or a single hard drive deployed in a RAID array sitting in a Chase data center.
Agile transformation case study #1: Power Advocate
In August 2007, immediately following my Chase gig, I started a memorable journey at Power Advocate, now a part of Wood Mackenzie. This is where my agile journey began. I was hired originally as a Senior Business Analyst (employee no. 42) to elicit requirements and author specifications documents in a waterfall system. Power Advocate was a ten-year old power industry consultancy with aspirations to launch a "killer-app" SaaS platform to revolutionize the way our consultants could serve our clients. Burning cash each quarter, we truly had the excitement and vibe of a start-up.
Power Advocate's fledgling "Intelligence" platform aimed to answer expensive questions haunting C-suite leaders at every power generation company. The flagship module was a procurement solution titled "Sourcing Intelligence." We competed head-to-head with Ariba, then the leader in that space. The rest of the platform vision included feature modules like Spend Intelligence, Contract Intelligence, Market Intelligence and Supplier Intelligence. I elicited requirements and wrote specification documents for the latter three modules.
My pièce de résistance was an intricate "commodity-roll-up" dashboard for the Market Intelligence module that would essentially answer highly difficult questions confronting the average Executive VP of Finance. For example, one question might be: "How much it should cost to build (soup to nuts) a natural gas-fired power generation plant?"
Given the fact that we assiduously tracked 800 different commodities (including labor) and we knew from our Sourcing Intelligence module what every large stand-alone component should cost, we had everything needed to provide a pretty good answer.
Because our direct competitors were larger and better capitalized, Dan Sullivan and William Conklin (the president and CTO respectively) made the decision in early 2009 to make the leap from waterfall to agile. They had three goals: 1) Increase market share by delivering our solutions faster; 2) Reduce the variability and increase predictability for every new feature proposed; and 3) Reduce the defect rate by 95%.
Version One of Seattle was contracted to guide our agile transformation, with Mike Tardiff, a Massachusetts native, serving as our Agile Coach. The Version One SOW covered six months and Mike stood up four agile teams (one at a time) within 90 days. Initially I was asked to serve as a Proxy-Product Owner for the Market Intelligence team because the Product Owner for that newly-formed team was temporarily out of commission. I quickly transitioned to the role of Scrum Master upon his return.
With 19 Java developers spread across 4 newly-formed Dev teams, every developer adopted Test Driven Development. Every team adopted Continuous Integration. As one of two newly-minted scrum masters, I served at least two teams concurrently. With the support of leadership, Lean-Agile practices were adopted across nearly every aspect of the Power Advocate organization. Dan and Bill attended almost every sprint review for all four development teams and were fully engaged during Q and A.
Delivery of valuable solutions to our clients soon accelerated in frequency while code quality skyrocketed. Every module could pull strategic data from the other modules, which required that we become adept at getting out in front of cross-team dependencies. Each new module rollout was a success and our SaaS sales team started winning routinely against the big boys. Soon we started doing the same thing serving the oil and gas industry.
Beginning in 2011, annual SaaS revenues grew by 40% on average for five consecutive years.
The agile transformation was so successful that Verisk Analytics (VRSK-NASDAQ) acquired PowerAdvocate in late 2017 for $200 million plus $80 million in milestone payments, for a total of $280 million. Everyone who had stock options experienced at least a 1500% return on the exercise cost of their options. Power Advocate was subsumed by Wood Mackenzie, a 2012 Verisk acquisition.
In this business, once a platform is built, you need fewer teams and fewer scrum masters. I exercised my stock options and moved on.
Cisco Systems
Immediately following Power Advocate, I accepted my second scrum master role with Cisco Systems. Although the firm was reducing headcount in Boxborough, I was lucky to get a six-month gig and I made the most of it. Most people (including me) were unaware that Cisco Systems had $2 billion in software sales in 2012, leading the way in the Call Center application space.
I served a tiny niche application called Social Miner, a purpose-built tool built to monitor Twitter and alert paying clients if a customer posted an irate message to Twitter. Think: "@Delta lost my luggage. #veryangry." Social Miner would see the tweet, capture it, and trigger a highly engineered customer service response by Delta.
This was another fabulous learning opportunity, and it cemented my new career path. Cisco had some unique agile practices and I soaked them up like a sponge. The most significant example was the policy surrounding the Sprint Review. Cisco referred to it as a "Sprint Showcase" and the Product Owner was required to enlist one existing customer to join the 30-minute presentation. At the end of the Q and A, the PO would ask the customer while the Dev team was listening, "If this were available today as an incremental upgrade and you had the funding approved, would you buy it? And if not, why not? What is missing?"
IT Leaders may talk a lot about customer collaboration (Agile Core Value #3), but Cisco did a better job getting Dev teams to collaborate directly with their existing customers than any firm I have ever worked with.
Koko Fit Club
Immediately following my six-month gig at Cisco I accepted a full-time role with KoKo Fit Club in Rockland, MA. I served two scrum teams concurrently there and once again it was a fabulous learning opportunity. I took every lesson learned at Power Advocate and Cisco and applied them to my new role, my first role where I was invited to be an "agile evangelist" throughout the firm. The highlight of my short time at Koko was actually not related to one of the Dev teams. It was the experience I had standing up a 7-member agile team comprised of company leadership and marketing/advertising colleagues. In other words, software development was just 15% of the focus of that team. We planned and launched a marketing event titled, "Koko 2.0." I had begun to read about something called "Scaled Agile." I borrowed the SAFe "program board" and modified it for that team to get out in front of their cross-member dependencies, such as advertising collateral cannot be released before training programs have been held, etc. Watching the company founder string up red yarn at my request is a nice memory.
Omgeo Corp.
Koko had some financial pressures, prompting my exodus in mid 2013, and I landed on my feet with a six month contract at Omgeo, then owned 50-50 by Thompson-Reuters and the Depository Trust and Clearing Corporation (DTCC). I served two teams concurrently. One of them was my first Kanban team. We were responsible for critical aspects of the Central Trade Manager system, which clears every trade involving a foreign financial institution purchasing or selling a US-domiciled security. Before my arrival, they had experimented with a remote scrum master facilitating every scrum event by audio conference call. Once again, I learned valuable lessons from this gig, the most important being the lessons surrounding the difficulty managing change management when more than ten scrum teams are involved.
Agile transformation case study #2: Commonwealth Financial Network
The second and arguably most successful agile transformation that I was a part of took place at Commonwealth Financial Network. Commonwealth Financial was already a highly regarded broker-dealer. But in the IT department improvement was needed. The waterfall-to-agile transformation had begun in 2013. I joined in May 2014, assigned to serve the Preferred Portfolio Services Operations team, the heart of Commonwealth's portfolio accounting activities. The lesson immediately learned was that it is hard for employees at a successful firm to willingly adopt more efficient IT practices. After a rocky start, the agile transformation was an unqualified success story. Every operational KPI and every OKR measurement related to Commonwealth's SaaS platform dramatically improved four years in a row. During that period, a large number of successful independent financial advisors quit their existing firms to join Commonwealth, resulting in more assets under management (AUM), higher revenues and higher profits.
The competitive advantage of the Commonwealth SaaS platform became common knowledge throughout the wealth management industry, which only encouraged more advisors to consider joining Commonwealth. As a result of this clear competitive advantage, Massachusetts Mutual Life (MML), a 140-year-old firm four times the size of Commonwealth Financial Network, paid an estimated $30 million to Commonwealth to gain an enterprise software license to enable their 16,000 financial advisors to gain access to Commonwealth's advanced SaaS platform. This was easily the largest single revenue event in the history of Commonwealth Financial Network.
Prior to the licensing agreement, the entire Commonwealth software development organization (six scrum teams and all of their immediate stakeholders) was spun off to form a new company called Advisor 360. Both Commonwealth and Massachusetts Mutual became "clients" of Advisor 360. The birth of Advisor360 and this massive transaction are the direct result of the highly successful adoption of Lean-Agile practices at Commonwealth Financial Network from 2012 through 2018.
Case study #3: CaseNet
My third agile transformation success story involves CaseNet, formerly a subsidiary of Centene (NYSE-CNT). That six-month gig involved the massively successful re-write of TruCare, a legacy app then supporting the healthcare delivery for 22 million Medicaid patients across 40 states.
There were four development teams but no scrum masters and very little agile program structure in place when I joined CaseNet. The four teams were not in alignment and they were behind schedule. As one of two scrum masters hired for this project, I served two scrum teams concurrently beginning on my first day. With the support of Centene's leadership, we instituted a complete agile program that included every scrum ceremony. We emphasized paired programming, TDD and holding regular sprint demos for all stakeholders. We used Scaled Agile tactics to identify cross team dependencies up front to avoid costly re-work.
After my six-month contract ended, the four project teams, having fully adopted the habits and practices we instilled, coasted to project completion on-time and under budget, prompting Centene to make the new Tru-Care solution the centerpiece of their national Medicaid operation going forward. I moved on immediately to Tufts Health Plan for a fresh six-month contract.
Once the Tru-Care re-write was complete, Centene spun off CaseNet completely. As a result, Centene is saving millions of dollars in software license fees.
Following CaseNet, I have worked for four additional firms where I have served as a senior scrum master or agile coach:
Tufts Health Plan (six-month contract on-site pre-Covid)
Monster Worldwide (three years fully remote)
NextEra Energy (six-month contract onsite)
ADT Solar (81 days fully remote) ADT Solar was shuttered by parent company ADT.
In all, I have served nearly 40 teams for 11 firms, mostly in or near Boston, the birthplace of Scrum. In addition to three "long term" FTE roles, there were several times over the past 12 years when an interesting short-term contract was presented to me, and I eagerly accepted.
Why take all of these six-month contracts? I have always been curious. I like discovering what makes teams succeed and what holds them back. I like creating value where things are in a state of underperformance.
The three long-term stints were deeply enriching thanks to the friendships I made, but there is no better agile education than personally experiencing the way different teams seated at different firms approach the mystifying challenge of “being agile” as opposed to just “doing agile.”
My DiSC Workplace Communication Style profile indicates a strong "i" (Enthusiastic, Collaborative and Action-oriented) with additional weighting in both "D" (Results oriented) and "S " (Supportive). This communication style has served me very well across nearly 40 teams and 10 organizations.
The shaded area in the "C" quadrant suggests that my underlying frame of reference is heavily oriented to an attention to detail. This is no doubt why I enjoyed my years serving as a Business Analyst.
To read more about the DiSC Workplace Communication Style and behavioral preferences assessment, click here.
Lyssa Adkins encourages Scrum Masters and agile coaches to take a candid look inwards even while "coaching" outwards.
She recommends a candid self-assessment in eight key areas of agile coaching competency. The result is a summary profile, taking into account each of the eight key skills. It allows each of us to be "up front" about what we offer.
Here is mine.
The further away each arc extends from the center, the more skilled I consider myself in that corresponding area.
My strongest areas are
1. Business Mastery
2. Facilitating
3. Lean-Agile Practices
4. Transformation Mastery (of Agile)
5. Mentoring
Because I believe that a little humility goes a long way in this business, I gave myself a more modest assessment in these three areas:
1. Technical mastery (I am not an ex-developer)
2. Professional coaching (I have not yet pursued a coaching certification)
3. Professional teaching (I do not possess a professional teaching degree
I am 100% confident in my coaching and teaching skills, but I respect the time and effort put forward by those who earned a professional coaching and/or teaching certification.
As for not being an ex-developer, I refer you to the Review Section where you can see what several former colleagues have to say.
Copyright © 2024 Solid Agile Delivery - All Rights Reserved.
Powered by GoDaddy