I thought you might ask....

An inexpensive, transparent Corp-to-Corp consultancy which generates a solution to two questions:  Why are my teams not delivering as I had hoped and expected? What can be done to make their performance measurably better?

One of my strengths is active listening. When you combine that with astute observation based on working with nearly 40 teams for 11 different firms over 14 years, there is a high probability I will be able to help. The establishment of trust comes first, and as the scrum process reveals everything that needs to be revealed, we will identify what needs to be done.

If you have my back and if your IT platform is reasonably architected to support Lean-Agile delivery practices, I will help your most difficult teams get moving in the right direction and get to the next level on a consistent basis.  

Two things: notoriety and cost.  I have not spent any time on the agile speaking circuit. I have never offered to present at a Scrum Alliance conference, an Agile Alliance conference, or even at a local agile event in New England, where I lived for over 20 years. Honestly, my vocal cords are not built for lengthy speaking engagements. Don't get me wrong - I have enthusiastically attended plenty of agile conferences and training events. I gained a boatload of inspiration and insights from all of them.  But for my work, in a team setting, I can steer everything I've learned and experienced into a team conversation where real progress can be made without a lecture format. 

On an inexpensive Corp-to-Corp basis I will work with one or more of your teams in a transparent way, listening, observing, gaining trust and then coaching my new teammates as a non-directive consultant.

I will confer with you regularly "off the clock" to discuss my progress with your teams. I don't bill my time for conversations that take place with individuals who work solely at the program level or above.

The easiest way to start an engagement is to identify "that team" - you know, the one that has great potential but has not measured up so far. Hire me and assign me to that team and include me in all of the team's scheduled meetings. I bill only for the time I spend meeting with the team or individual team members as stated in our agreement.

I will facilitate these meetings as a "scrum master" or "scrum lead" or "agile coach" if you want, but it is not a requirement for success. I can join the team and serve as a reinforcement to the individual you already have facilitating that team.

In either case, my initial job is to listen and learn. I may ask a few questions strategically, but I will make an assiduous effort not to slow the team down. 

Because I am confidently assuring you that your teams will get "measurably better" you can bet that "metrics" are involved.

Once I was asked, "This is very important: how much experience do you have generating and reporting metrics?" 

My response was "Quite a bit, actually, but I am curious: what exactly are you trying to measure?"

The fact is, for any organization running Jira or any of the other industry standard backlog management tools, all of the metrics you actually need are automatically generated. You probably don't need to pay me or anyone else to create elaborate "custom" metrics. 

So, about those metrics......I agree with the old adage, "What gets measured is what gets done."

Measuring IT teams is useful but it is a double-edged sword. Once a team understands what you are measuring, rest assured they will adapt to the "ask" and will invariably find a way to make sure that whatever you want gets "done."  

But will more value get delivered? 

Here is an obvious example: A scrum team operating in a traditional two-week sprint format (where the work is estimated in points) is told, "We would like to see an increase in velocity." From my experience, you are guaranteed to see velocity go up over time - more quickly than you would expect. Fantastic! But will more value get delivered? 

Two-point user stories become three-pointers, three-pointers become five-pointers, five-pointers become eight-pointers. In the end, I would suggest that the additional velocity is not the same as delivering additional value to the end user.  

I have personally witnessed this phenomenon. 

The best agile metric is actually quite simple: what percentage of the original sprint commitment was delivered before the sprint is completed? Jira calculates this automatically. If it is 90% - 100% then the team deserves a pat on the back. At the next retrospective, we can talk about the small amount of work that was not marked complete.

Any percentage below 90% is an invitation for a very thorough, very candid discussion in the next sprint retrospective so that the team can make the needed improvements.

Since metrics can not only be gamed but can also cause a team to become jaded, I coach teams: "Keep it all organic - nothing synthetic - you are primarily being measured by the value and quality of the code you deploy, as well as the frequency with which you fully deliver as a team on your sprint commitment." 

From my experience, teams really thrive under this approach. We'll use metrics that measure the delivery of value.

I am a steady self-starter who has held a number of different agile roles, faced a variety of challenges working "in the trenches" but learned how to adapt to the challenges in front of me.

As a Tech Support manager:

1. Hired, trained and managed 3 full time and 2 part-time tech support representatives for Boomerang Software.
2. Stood up a Web-hosting service at Boomerang Software to alleviate FTP issues and create a frictionless user experience for end users creating their first internet website.
3. Served as the primary tech support representative for Boomerang Software, Building Engines, ASP Platform Services and the JP MorganChase Global Failed Drive Data Security Program.

As a BA, I have delivered a range of documents or technical artifacts that were delivered to production in form or another:

1. Wrote Quick Start guides for Boomerang Software, Chilliware and ASP Platform Services.
2. Wrote and edited context-sensitive online help files and tools tips for Chilliware.
3. Elicited requirements from end users for Boomerang Software, Building Engines, Chilliware, ASP Platform Services, JP MorganChase and Power Advocate.
4. Using Visio, documented a 21-step data workflow for automated document generation for the M4App real estate Sheriff Sale foreclosure SaaS in Pennsylvania.
5. Wrote requirements and specification documents for Power Advocate in a waterfall system prior to their agile transformation in 2009.
6. Wrote the DiskTracker Quick Start guide, training documentation and process documentation for the $9 million JP MorganChase global failed drive data security program.

As Product Owner:

1. Elicited requirements from end users of the M4App SaaS for ASP Platform Services. 
2. Prioritized feature requests for the DiskTracker (JP MorganChase data security project) web-native application.

As Scrum Master / Sr. Scrum Master / Agile Coach / Scrum Lead

1. Served nearly 40 Scrum or Kanban teams across 11 different firms over 14 years.
2. Spearheaded the introduction of Scaled Agile Framework practices to Commonwealth Financial Network.
3. Facilitated all Scrum ceremonies (Daily, Sprint Retro, Sprint Demo, Sprint Retro) backlog grooming sessions, pre-grooming sessions with Tech leads, Product Owners, Business Analysts and QA Leads, multi-teams Scrum-of-Scrums, Scaled Agile PI Planning.
4. Re-factored automated test cases for NextEra Energy's IT Nuclear organization.
5. Re-organized the product backlog for three nuclear power plant maintenance applications for NextEra Energy.
6. Selected to serve as the facilitator for the 2018 Agile New England Agile Games Restrospective.

I have noticed that in many companies across the application software industry, the role of "scrum master" has changed dramatically.  

Originally the scrum master was always considered non-directive team leadership role, but that is not true anymore. Today I see where the Scrum Master role hass been reduced to a junior-level meeting organizer and meeting proctor with some low-pressure facilitation responsibilities and heavy reporting responsibilities. 

In this new model, the scrum master might carry on a few team traditions and help remove some minor impediments, but at the end of the day, has no influence to advocate at the program level for any constructive changes that would help the team truly evolve and improve.

This dynamic has become commonplace. Jez Humble and Nigel Thurlow (among others) have delivered some compelling "commentary" on this unfortunate development.

In all of my roles I have always made sure that the scrum process is followed and when that happens, all of the issues that can slow teams down are revealed.  

Unfortunately, in a few of my contract roles, no one at the program level had the power, influence or inclination to help resolve those issues after they were raised up at the team level.

In some cases, due to policies enforced in a top-down fashion by leadership, the developers had no authority to "think outside the box" and make changes to the way they went about their business - this lack of autonomy constrained the team's ability to deliver value and had an impact on team morale.

In line with these experiences, I no longer refer to myself principally as a "scrum master" but instead prefer the moniker of "Lean-Agile Success Generator."

 Many agile "experts" have extremely rigid opinions about Waterfall.  My approach is a little nuanced.

I served as a BA immersed in a waterfall software development system, so I know it well. As a devotee to Lean-Agile software development practices since 2009, I have consistently worked to help my teams avoid the obvious and well-documented risks with waterfall. 

The conventional criticism of waterfall from the Lean-Agile perspective is that “waterfall is great for building a bridge but not for software.” In my view, that is generally true, but here is the cold reality: you have to meet the team where they are.

Best example: what happens when the business brings to the Dev teams a high-priority, highly visible capability in response to an unstoppable market trend? If a vision for an “MVP 1” has been shared across the program leadership, accompanied by a calendar release set as a goal, it is highly likely that a deadline-driven, waterfall mentality will consume the entire project. You cannot change that!

I have seen this happen more than once. There are two Lean-Agile tactics that can clearly help counterbalance the obvious risks that are typically associated with a waterfall mindset: 

1) A "firewall" to prevent scope creep beyond MVP-1, resisting the urge to gold-plate the "MVP-1."

2) Frequent system demos at the team level well ahead of the target release date. At the team level this is an absolute must, but it requires an investment.

The first is so obvious I don't need to dwell on it. If a needed feature is "discovered" after the project is underway and all stakeholders agree that without it, MVP-1 will fail completely, then that feature should be added. These things are difficult to estimate but if good product backlog organization has been accomplished, perhaps there is a less valuable feature that can be delayed until MVP-2. Otherwise, the scope creep needs to be as close to zero as possible. 

The second is more nuanced. A sprint demo after each sprint is a given, of course. What is really needed in the run up to an MVP 1 release is a series of system demos and/or end-to-end demos well in advance of the MVP-1 target release date. These demos are a significant investment of valuable time, but unless every single end user is a company employee with no alternatives these investments are well worth it. They will confirm long before Release Day that the correct solution is being built. Even more, they will reveal workflow-centric defects that will help you avoid a flood of workflow related production defects when MVP 1 is deployed.

In short, sometimes a Waterfall mentality can dominate a project when a high-priority, deadline-driven "MVP-type" capability has been embraced by the business.  Lean-Agile thinking should be employed fully as a set of risk-mitigation tactics and complimentary practices.

TRAINING

December 2009 (2 days): Scrum Alliance Certified Scrum Master through Version One (Seattle, WA) Trained by   Brent Barton

April 2013 (2 days): Coaching   Agile Teams with Lyssa Atkins  and Michael Spayd, Doubletree Hotel, Waltham, MA 

June 2014 (2 days): Core Agile Training conducted by Mario Moreira (author of Being Agile) at Commonwealth Financial Network, Waltham, MA

April 2015 (2 days):  Coaching Development Teams with Lyssa Atkins and Michael Spayd, American Air Center, Dallas, TX 

October 2015 (2 days): Scaled Agile Framework, ver. 3.0, Certified SAFe Agilist training through Rally   Software at Progress Software headquarters, Bedford, MA 

March 2017 (2 days):  Scaled Agile Framework, ver 4.6, Certified SAFe Scrum Master training completed   through The i4 Group, Boston Park Plaza, Boston, MA 2018

September 2019 (2 days):  Scaled Agile Framework, ver 4.6, SAFe For Teams,  led by John Pavlov with Tufts Health Plan, Watertown, MA. 

October 2019 (2 days):  Scaled Agile Framework, ver 4.6, SAFe Advanced Scrum Master, led by John Pavlov with Tufts Health Plan, Watertown, MA.,

AGILE CONFERENCES

· Agile Alliance Technical Conference, Raleigh, NC April 2016 (2 days)

· Agile Alliance Technical Conference, Boston, MA April 2017 (2 days)

· Scaled Agile Framework SAFe Summit, San Antonio, TX, November 2017 (2 days)

· Agile Boston Give Thanks for Scrum, 2017, 2018 and 2019 (1 day each)

Conversing directly with Jeff Sutherland and Ken Schwaber in an extended Q and A session was the highlight of these annual all-day events held every year just before Thanksgiving at the Microsoft Training Center in Cambridge, MA.

· Regular attendee, Agile New England monthly events, 2012-2019

· Regular attendee, Agile Boston monthly events, 2015-2019

Michael Tardiff - my first agile coach (and still the best agile coach I ever worked with in person day-to-day)

Brent Barton - my first Scrum Alliance trainer

Jeff Sutherland - Agile Manifesto signatory and co-inventor of Scrum and creator of Scrum@Scale

Mario Morreira - author of Being Agile and a highly effective group trainer

Lyssa Adkins & Michael Spayd -  Lyssa authored Coaching Agile Teams. Their training conferences are extremely insightful, especially Coaching Development Teams.

Jeff Patton, author of User Story Mapping and a true gift to this industry

Uncle Bob Martin, Agile Manifesto signatory, a leading proponent of TDD, and the author of Clean Code

Dean Leffingwell, creator of Scaled Agile Framework, the first and perhaps most comprehensive cross-team dependency management system.

Woody Zuill, author of Mob Programming: A Whole Team Approach 

Arlo Belshee, who inspired me with his presentation "Bugs are Optional" at an Agile Alliance Technical Conference

Laurie Williams, author of Paired Programming

Mike Cottemeyer,  CEO and Founder of LeadingAgile, a gifted voice for everyone trying to understand the mentality of an effective agile consultant.

Jez Humble, Author of "Continuous Delivery" among other important agile-centric books

Back in 2012 I had a six-month contract gig at Cisco Systems in Boxborough, MA. I had less than three years experience in the agile world at that time. It was my second full-time role as a scrum master. I had a delightful colleague who was just as enthusiastic as I was about the challenge we faced: Helping our respective teams deliver working tested software consistently with fewer defects. 

If he observed an obvious anti-pattern, he would say, "That's not agile, that's fragile!" We would both laugh, and I remember telling him, "Say, that's pretty good - I hope you don't mind if I use that."  Over the years it morphed from calling out an anti-pattern as "fragile agile" to extolling the idea of "solid agile."