Signed in as:
filler@godaddy.com
Signed in as:
filler@godaddy.com
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:
As a BA, I have delivered a range of documents or technical artifacts that were delivered to production in form or another:
As Product Owner:
As Scrum Master / Sr. Scrum Master / Agile Coach / Scrum Lead
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."