Last week I attended a 4-day Scaled Agile Framework class with a result of sitting for my SAFe Program Consultant (SPC) test. A few days after the class, I received an email telling me I passed the exam. I am now a proud and newly minted SPC. This enables me to teach several SAFe courses, to kick-off and coach Agile Release Trains (PSI’s), and to generally coach organizations that are adopting SAFe.
But to be honest, I’m still digesting SAFe. It’s not that I’m having trouble with the concepts or approaches. It’s more so that I’m having a challenge fitting them into my own experience in a useful way. You see much of what I learned in the class I’ve been using and doing for a long time in my own agile journey. But I’ve couched those techniques under Scrum of Scrums for agile scaling—and with fairly good success.
In the late 1970’s I worked on an assembly line at Burnham Corporation in Lancaster, PA. This was after I separated from a stint in the US Army and during my tenure pursuing a BS degree in Computer Science.
Believe it or not, I was a “Boiler Maker” at Burnham. I was a member of an assembly line that assembled boilers from parts manufactured in the plant.
I know what you’re thinking. At last, Bob has “lost it”. He’s regressed back to the early roots of his working career, which has nothing to do with his focus today. He’s now become an “old man” telling “old man stories”.
Well I will admit that I’m not as young as I used to be, but I’ve been thinking a lot about this job recently and the similarities or lessons there from an agile perspective. I hope I can connect the dots sufficiently for it to make sense to you too.
I’m a Certified Scrum Coach and I know quite a few CST’s. Many of them offer training and coaching as part of their services. However, the typical client interaction, either with public classes or private training engagements, for many of them is as follows:
- Deliver a 2-day CSM class to a group of mostly client team members
- Rarely deliver a “talk to leadership” as part of the engagement, as theirs is more of a team-centric play…
Then they move off on their merry way. One of the “tag lines” of the Scrum Alliance is “Transforming the world of work”; so many CST’s get a sense of accomplishment at this point—feeling that the world of work has been, well…transformed.
There are two questions that I get more than any others as I travel around sharing on agile topics:
- How does agile work with distributed teams?
- How can agile deal with fixed price, fixed scope contracts?
And these questions are usually not simply questions. They’re thrown down as “gauntlets” that defy agilities promises. Often they are prefaced with – “Hey Bob, but in the real world…”
In our latest Meta-Cast, Josh and I went through a couple of questions from the audience. One of the questions surrounded what to measure for individual developers. To be honest, I was taken aback by the question.
You see, I’ve been preaching for years that when you move to agile metrics, you want to do four things:
(One) Move from individual team member metrics to a more holistic, whole-team view.
(Two) Move from measuring functional teams, for example test team progress, again towards holistic, executing agile team view.
I read a recent article/blog post by Steve Johnson where he made the case for something he calls “market stories”. Here’s a snippet from the post:
Lately I’ve been talking to people about “market stories.” Combined with personas, market stories describe the market problem on an emotional level, before you break it down into product stories and user stories and tasks. They inspire our internal teams to want to help customers as people, not just as buyers.
For example: “My father wandered away from home and we can’t find him.”
If you’ve followed my blogging at all, you know that I’ve worked for several companies in the last 6-8 years that have colored my thinking as an agile coach. Sure, I’ve coached a wide variety of other organizations, but there’s nothing like being an employee of a company and assuming the role of technical leader and agile coach to get your attention each day.
One of those companies was iContact (now Vocus), which develops an email marketing SaaS platform. This story comes from my time spent there working with some wonderful development teams.
I think it was George Dinwiddie that first coined the term “3 Amigos” in agile development around 2009. The analogy was akin to the movie from the mid 90’s by the same name. The Amigos in the agile sense are functional roles:
- Developer(s);
- Tester(s);
- and the Business Analyst or the Product Owner.
It could literally mean more than three as well. The point was, balanced collaboration in agile teams across these roles. George was alluding to these roles from an Acceptance Test Driven Development (ATDD) perspective. He wanted these three constituencies to be heavily collaborative (conversations) around the Acceptance Tests or Acceptance Criteria for each user story.
In my last post I talked about a tendency some organizations (and individuals) have in jumping on the latest fad in building software teams and the methods for producing value. Beyond jumping on tactical or practice bandwagon’s, there appears to be a war going on related to traditional hierarchical organizational structures and traditional line or functional managers
Now to be clear, my context is 90% from an agile adoption and transformation perspective. And this isn’t some new phenomenon, as it’s been tied almost to the inception of the agile approaches.
I remember years ago, Microsoft was considered the benchmark of all things leading edge when it came to software development. They seemed to be the “poster child” for how to build software organizations and software products.
For example, they had a multi-tiered strategy for a code freeze model and everyone seemed to be copying it. And today their Software Developer in Test (SDET) model is also incredibly popular. There were many books written about their strategies and approaches, and everyone seemed to want to “be like Microsoft”.
What’s interesting to me is my perspective. If you’ve been in technology long enough, you see recursive themes unfolding. What today is a benchmark company with everyone jumping on the bandwagon to copy them, in ten years becomes a passing thought. Microsoft is clearly an example of this curve—first being the “darling” of what to do – to falling into a category of status quo or even an anti-pattern. Sure, Microsoft is still a viable company and sometime role model, but it’s no longer seen as the one to emulate.
