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.
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.
I was facilitating a full-day Leadership Summit at the Agile Development conference in Orlando in November.
There were ~70 leaders in the room and I wanted to surface their expectations for the summit so that everyone could understand the most important topics to the entire group.
I decided to do an exercise called “The 1-Thing” in homage to the movie City Slickers. I asked each table group to:
- Pick a facilitator;
- Have each table member write down the 1-thing they would like to learn from the workshop. I.e., their #1 challenge, question, or interesting topic;
- Then the facilitator would collect all of the 1-things from their tables;
- Next, each facilitator would read all of the 1-things;
- Finally, we discussed as a group, the major themes we heard. We found about 10 compelling themes to keep an eye on.
One of the topics that I've typically avoided at agile conferences and in discussions with colleagues is software capitalization. Particularly in agile contexts.
The first reason is that it's usually used as an excuse to undermine agile principles and as a means of continuing old practices.
The second is that I find it somewhat...boring. Yes, it's often necessary for many enterprise or larger-scale contexts. But I'd rather the teams focus on innovation, customer value, and deliver than on capitalization.
And the third reason, which is somewhat embarrassing, is that I never had a succinct recommendation for folks on how to handle it in agile contexts. I always felt that I said "it depends" too often.
Excuses
But all of those reactions were excuses. And I do realize that it's a serious topic for many folks. So, imagine my delight when I came across a real-world blog post from Stephanie Davis of Valpak in Tampa Florida that explained how they've been handling it.
And not only that, the post contains some reference post that nicely provides additional capitalization examples and advice.
Wrapping Up
I've shared this post to be my "Go To" reference for capitalization. Thank you, Stephanie, for sharing!
Stay agile my friends,
Bob.
I’m beginning to think that we’re too focused on the team when we talk about agile. Everything is focused towards that end.
Team this and team that.
But what about the individual on the team? I contend that they count too.
- Make sure your voice is heard; in many team’s individuals can get lost. Often the loudest of voices seem to become the default voice of the team.
- Make sure you take time for yourself; self-learning, downtime / reenergize, reflection are keys to your personal growth and learning. Always increase your value proposition – you.
- If you’re introverted, give yourself permission to be alone; this includes working from home and “separating” from the team on occasion to work by yourself.
- Gain personal feedback; don’t get caught up in team-only feedback loops. While important, you need personal feedback as well. Make sure you’re getting it from your team and leaders.
I’ve been speaking at TechWell events since around 2000. First, I started out with track talks. Then I started sharing full-day and ½ day workshops. I’ve also been invited to deliver several keynotes at the Star and Agile Dev / Better Software conferences.
All-in-all, it’s been a professional relationship that I’ve really enjoyed.
Recently, the long-time program chair, Lee Copeland, stepped aside. I truly want to thank Lee for the years he invested in helping me grow this side of my consulting practice. I owe him a great deal.
Program Chair & Talent Scout
Given my history and experienced, TechWell approached me to help fill the Program Chair role for the:
- Agile Development
- Better Software
- DevOps
Conference series going forward.
The conference has a West / East format. The West version is held in Las Vegas, typically in early June. The East version is held in Orlando, typically in early November.
The programs are usually developed 8 months in advance of the conference, so you need to reach out to me early if you’re interested in participating.
The program chair is responsible for pulling together approximately:
- ~4 Keynote presentations
- ~4 full-day workshops
- ~20 ½ day workshops
- ~60 60-minute track talks
across the four major themes (Agile Development, Traditional Software Development, DevOps) of the conference.
And the talent scout part of my role will focus on looking for new and interesting topics, speakers, and formats to introduce to the conferences.
There’s a famous Mike Tyson quote:
Everyone has a Plan
until they get Punched in the Mouth
It reminds me of the ultimate futility of estimating and planning. Or investing too much in both of those endeavors. Particularly in the area of software product development.
Another related quote is from Eisenhower. It surrounds the value of plans (artifact) vs. planning (activity):
I have always found that in preparing for battle that
Plans are Useless,
but Planning is Invaluable
That is:
- The activity of exploring requirements via user stories and acceptance criteria;
- The activity of minimizing (MVP) the results so as to learn;
- The activity of making estimates as a vehicle to explore size, scope, risk, and design approaches;
- The activity of discussing construction and deployment strategy;
- The activity of delivering work to stakeholders and gaining their feedback.
Are all more valuable than fixed or static plans, which are intolerant of the punches that are inherent in software development - learning and discovery.
Wrapping Up
The next time you find yourself getting “stuck in” your plans or thinking that planning is more important than doing and adjusting, then please remember these two quotes. Also remembering, that Tyson and Eisenhower weren’t practicing agile software development. But they were indeed…agile.
Stay agile my friends,
Bob.
