Scaled Agile Framework - Is it SAFe?

I attended an Agile Leadership Network (ALN-Raleigh/Durham) meeting a few weeks ago where Dean Leffingwell presented the Scaled Agile Framework. It was a solid meeting and quite thought provoking.

As with any "good" meeting, I went away thinking about what I heard, the contrasts against my own experience, and tried to sort through my reactions - both good & bad.

I've written some of them down in this article. I hope it comes off even handed, while still clearly communicating my concerns.

I guess the point is: Is SAFe...safe? I'm not quite sure yet ;-)

Thanks for listening,

Bob.

The Agile Project Manager: WIPping Things Into Shape

I once was leading / coaching a team that struggled mightily to work together as a team. I was the Director of R&D at an eCommerce SaaS product company. We had been leveraging Scrum for a number of years with reasonably good success and had approximately 10 Scrum teams focusing on the various aspects of our online product.

But there were a couple of teams that were really struggling, which often seems to be the nature of things. Out of ten teams, we had about three that were high performing, three that were moderately performing, and three that struggled along. Don’t get me wrong, the team members were solid people and good employees. It was just that this whole “agile collaboration thing” was hard for some of them to grasp and embrace.

One particular team truly struggled. They had failed quite a few sprints in a row and I was intervening as a coach. Let me digress for just a moment on the whole failure thing, before you all start throwing tomatoes:

We measured success or failure not by hours, or points, or stories completed. We measured it by the team meeting their Sprint Goal that was established when they planned and committed to their sprint. There is a lot of angst in the Scrum community over using Pass vs. Fail or even using the word “commitment”. For the purposes of this article, I do not necessarily want to try and debate this practice. You can see references to some related posts at the end of the article. Suffice it to say that, at the time of this example, we measured and cared about sprints passing versus failing.

As they failed, they would talk about adjustments in their retrospectives. But the modifications were often quite trivial or safe. I felt they were not addressing the issues that were truly impacting their performance. I remember in one retrospective, they decided that the estimation units they were using were flawed. So they moved from a modified Fibonacci to Gummy Bears. Needlessly to say, the next sprint was not positively influenced by the adjustment. This went on for quite some time.

I am normally a patient coach and I try to influence teams to observe and improve on their own. But this team truly was not “getting it”. So, after about their fourth or fifth failure in a row, I gathered the team’s Scrum Master and Product Owner in my office for a “chat”. I insisted that the failure pattern that they were experiencing needed to stop. I told them that I felt their root problem was that the team was not collaborating on their work. That they were operating as a Scrummer-fall based team and that individual work was the norm rather than teaming, swarming, collaboration, and teamwork.  They agreed and they voiced their own frustration with the lack of improvement. But they did not know what to do and they were reluctant to “tell” the team what to do.

Click to read more ...

The Agile Project Manager: Agile Basic Training—What is an Acceptable Level?

The agile methods are deceptively simple and common sense oriented. In many ways, that’s one of their great strengths, but its also one of their fundamental weaknesses. I see so many teams convinced that they can “go Agile” just by reading a book or an article and then diving in and “sprinting” towards successful software delivery. The logic goes that agile is simple common sense practices, self-directed, and intuitive—so of course it will be simple to pick up and execute.

I typically categorize these teams as “bad agile” teams in that they adopt a small, superficial, and somewhat trivial set of the core agile practices and then think they’re agile. In almost every case they don’t understand the agile mindset nor how the core principles and practices complement one another to foster improvement. They’re “doing Agile”, but they’re not “being Agile”.

Ken Schwaber coined the term ScrumBut to capture this common anti-pattern, as in—“We’re doing Scrum, but…”. And Ken was solely focused on Scrum in coining the term. I’ve also found the Extreme Programming practices to be a wonderful complementary set of agile practices and they’re often left out of the conversation as well.

One of the core drivers for this is that teams don’t receive sufficient agile training from the right level of experienced coaches and trainers. So, yes, you can pin some of the blame on the teams themselves. But I think some of the assumptions we’ve set in the agile community are also to blame.

Click to read more ...

The Agile Project Manager—Please Sir, May I have some help?

A Sad Story

A seasoned Director of Software Development was championing agile adoption at their company. It was a moderately scaled initiative, including perhaps 100 developers, testers, project managers, BA’s and the functional management surrounding them. They received some initial agile training, seemed to be energized and aligned with the methods, and were “good to go” as they started sprinting.  

Six months later things were a shambles. Managers were micro-managing the sprints and adjusting team estimates and plans. The teams were distrustful, opaque and misleading their management. There was virtually no honest and open collaboration—nor trust. They’d (re)established a very dysfunctional dance.

Funny thing is…

Their agile coach asked many times if they needed help and the answer was always…”No – things are going fine”. Only when they’d failed 10 sprints in a row and team members were mutinying, did the Director reach out for help to their coach.

Their coach came back and in relatively short order brought the team back to ‘basics’ and helped them restore balance, trust, collaboration, and commitment to agile delivery. Afterwards, everyone was asking the questions—why did it take so long—why didn’t we ask for help sooner?

Click to read more ...

The Agile Project Manager--How do you want your Software, Good or Fast?

Picture this…

You are in a software diner one evening after a long day at work. A tired and disheveled waitress walks up to you to take your order—gum smacking as she goes over the daily specials. Nothing really sounds good to you, but you are extremely hungry and short on time. She summarizes the possibilities for you to help with your decision-making.

Honey she says—

You can get mediocre to terrible food fast or slow food that tastes good. But you can’t have both—good & fast food. 

It seems as if we’re always given certain choices in our software delivery challenges similar to what our waitress has given us. We have all heard of the “iron triangle” of Project Management—defining Scope, Cost, and Time as the three critical dimensions for a project. Usually Quality is placed within the triangle as a fourth variable—totally at the mercy of the other three.

What is that old Project Manager joke?

You can hold any two of the dimensions fixed, but not all three of them. But isn’t that exactly what most traditional projects try to do—hold all three constant? What inevitably varies in these is quality, but rarely in a transparent and decisive way. It’s usually compromised slowly and disastrously behind the scenes, one method or component at a time that isn’t thoroughly designed or tested or documented. These trade-offs always, and I mean always, come back to haunt the team, project, and organization with re-work.

Click to read more ...