For years and years, I've been a strong advocate of goal-setting within your agile teams. Ares where I think goals are important include:
- At the daily stand, focusing the conversations towards the teams' goals;
- During sprint planning and at the sprint review, focus towards the sprint goal;
- If you're doing releases, ala SAFe release trains or a similar mechanism, then having a release-level goal is important;
- To me, Definition of Done and Definition of Ready, are goal-oriented. Providing clarity on the teams' constraints;
But...
Introduction
A colleague of mine in Dallas, Jack Schwartz, sent me an email asking the following:
Bob,
I’m working on a presentation focused towards Hiring a ScrumMaster and I wonder if you could provide some insights to the following questions:
- What are the top skills you like to see in a good Scrum Master?
- How can a hiring manager tell if a prospect is truly an agilest and not just using scrum words with ‘legacy’ project management? (other than clairvoyance)
Thanks,
Jack.
Well, Jack here is my initial stab at a response…
What are the top skills you like to see in a good ScrumMaster?
Well, first I’d like to say what I’m not looking for:
- I’m not looking for someone who is strong in a functional area within the team. For example, if I’m staffing for a ScrumMaster in a team with a weak or non-existent Development Team Lead in it, I’m not looking for the SM to fill that role. Or an equivalent, PO, UX, BA, Testing, or any other role. If I have a skills gap or weakness in a team, I need to fill that with someone with those skills.
February 5, 2018
I’m experienced enough in the Scrum community to remember several early attempts at assessing the maturity of agile and Scrum teams.
- Around 2008 – 2010, the Nokia Test was originated by Bas Vodde in his work at Nokia. Jeff Sutherland and others have referenced it.
- Then the Nokia Test evolved into the infamous Scrum-But test around 2010. Aka, “We are doing Scrum, but…”. Below is a publication from 2011 that Sutherland shares about the evolution of the test –
- Around the same time these were evolving, in 2007, Ahmid Sidky wrote his dissertation focusing on an agile assessment framework. He called it the Sidky Agile Measurement Instrument or SAMI. And to my knowledge, it was the first attempt at a holistic instrument or framework.
My point in taking you down “history lane” is that agile assessment tools and frameworks have been thought about since ~2007. So, for the past 10+ years.
The problem is, that none of these, and the ones introduced later, have really done an effective job of helping teams improve.
I came across a blog post by Tricia Broderick in January 2018. I often read Tricia’s thoughts and really enjoy her perspectives. This one was entitled Leadership Is Lonely and it largely lamented this aspect of leadership. To her credit, Tricia shared some activities that leaders could use to combat the effects of the inherent loneliness.
But I wanted to provide a different take or perspective.
I’ve been in leadership roles for over 25 years. In the early days of my leadership journey, I felt very much like Tricia. In fact, it was one of my early and shocking discoveries of leadership.
When I wasn’t leading, I was “friends” with most of my work colleagues.
But when I was promoted to a leadership role, things changed. I was no longer Bob. I suddenly became “the Boss”. And in today’s terms, that often meant being equated to the pointy-haired boss in the Dilbert cartoons. It also meant that it was suddenly a very lonely place to be.
I’m originally from central Pennsylvania, having grown up on a farm in Lancaster County. We were about an hour and a half from Philadelphia. And you couldn’t help but connect to the local Philly teams.
The Eagles are one of those teams that always seemed to struggle, yet the local fan base is incredibly loyal to them. Disgruntled, complaining, obnoxious, whiney, but still loyal. And I am one of those diehard Eagles fans.
Now I moved away from Pennsylvania in the 1980’s. But my heart is still with those sports teams. So, you can imagine how I felt when the Eagles won the 2017 Super Bowl.
Elated, surprised, justified, humbled, fulfilled are some of the feelings that came to me.
My friend and colleague Shaun Bradshaw and I were coaching at a client recently. We started to have a conversation about velocity, not directly driven by the clients’ context, but simply in general.
Shaun was focused on velocity as a relevant metric within agile teams to drive conversations between teams and upper management. And I was struggling to “get there”.
Part of his focus was to create visibility around the difference between average velocity and current sprint velocity. Furthermore, the teams and management would be able to see:
- Velocity gaining stability over time (predictability, low variance)
- And increasing over time (short-term burst)
As part of newly formed and/or newly coached agile teams.
Now I really get what he was saying. And I agree that teams in these contexts should be displaying activity and behavior towards those two results.
One of the things that I’ve come to value in my agile journey is our local Raleigh / Durham agile community. It’s one that I’ve had a hand in creating and guiding over the years. But one that’s taken on a life of its own.
I can’t tell you how many wonderful agilists are here in my local area. Some are:
Mary Thorn, Josh Anderson, Ken Pugh, Jason Tanner, Laurie Williams, Agile Bill Krebs, Andy Hunt, Ken Auer, Catherine Louis, Cory Bryan, Jeff Barschaw, Tom Wessel, my colleagues at Zenergy Technologies, and the leaders of our local AgileRTP and ALN groups. Literally, we have a community of thousands in our Meetup groups and our local TriAgile conference draws 500+ folks annually.
www.triagile.com
A couple of other local folks that I want to call out are Laura Burke Olsen, Arjay Hinek, and Matt Phillips. They are collaborators in a group/website entitled Collaboration Explored. It is a website focused on Collaboration inspired by the late Jean Tabaka. I think it’s wonderful that these folks (and others) are continuing the work that Jean inspired.
In the first part of this post, we explored these “rules”:
- Allow Architecture to Emerge
- Treat it Like a Product
- A Picture is Worth…
- Everyone IS an Architect and Everyone OWNS the Architecture
Now, I’d like to continue sharing the final set of four rules for your consideration in your agile architectural travels.
#5) Keep it Simple and Connect to the Customer
This one is quite near and dear to my heart. Why might you ask? Because I really like complexity. I like engineering complex solutions to simple…complex customer problems. And it’s also quite comfortable for me to fall into that over-engineering, gold-plating, doing more than is required mindset.
Why?
Wow, the title sounds quite bombastic, doesn’t it? And I sound quite full of myself, don’t I? Well…perhaps I am.
Nevertheless, I want to go on record with some simple and pragmatic advice for agile organizations and teams when they’re trying to sort out how architecture “fits” in agile contexts.
In no particular order, here are my guidelines:
#1) Allow Architecture to Emerge
I know you’ve heard this before, but it’s really, really important. The difference is moving from traditional architecture, which –
- Performs Big Design Up Front (BDUF), aka Big Bang;
- Develops a “complete” architectural concept before coding begins;
- Approaches construction horizontally, with delayed layer integration
