Every year I try to spend time on my own training. I usually start thinking about two things the year before:
- What are some knowledge gaps that I have that I’d like to fill, and
- What are upcoming trends that will cause me to become obsolete if I don’t get ahead of them?
Then I review the available courses and I’ll try to come up with 2-3 things that I’ll focus on for improvement.
This year, I’ve planned on the following:
- Training from the Back of the Room, by Sharon Bowman
- The Nexus framework for scaling Scrum, by Ken Schwaber and Scrum.org, in July
- And Leadership Agility 360 workshop, by Bill joiner, in November
I subscribe to Mike Cohn’s newsletter. As you would expect the value is always high and his posts usually make me think a bit about my own coaching experience and ongoing advice.
In a recent newsletter Mike adopted a position on a manager serving as a ScrumMaster that goes contrary to my experience. Here’s what he had to say:
When I first started doing Scrum, I was what we'd call today the team's ScrumMaster and product owner. But we didn't have those terms back then. And without terms or any clarity on the roles, it was easy for me to make the mistake of being both.
I also did some programming. Oh, and I was also the vice president of the software department, so my team reported to me.
I want to address that last role because common advice in the Scrum community is that a team should never, ever report to their ScrumMaster. That is, I could have been the ScrumMaster or the VP -- but I should not have been both at the same time to the same team.
Do you recall the … Jim Carrey movie called Yes Man? In it he was influenced by a ‘cult’ of sorts that recommended an approach, in order to change our lives, where we have to say YES to everything – every question, every opportunity, and every inquiry.
The point is somewhat captured in the agile posture of “Yes, and…” that many coaches subscribe to.
Lately I’ve been thinking about traditional software leaders who are moving towards agile methods. Typically they take a class or workshop to gain a cursory understanding of agility. Some even take more ‘advanced’ workshops, which are focused towards the leadership shift.
I watch my fair share of TV shows that surround real-world business and projects. I’ve noticed a theme that I want to share to see if you see it the way I do. So here are a few examples:
Fast ‘n Loud is a show on Discovery Channel here in the US. It’s about a garage that takes in “needy” cars and refurbishes them for resale.
The owner of Gas Monkey Garage is Richard Rawlings. In the episodes he generally is scouring the countryside for fixer upper cars that have up-side profit potential.
This is a guest post by my colleague: Jim Grundner. Enjoy!
In my daily wanderings, I have been trying to determine a succinct way to think of and describe what successful Agility is at its core and how can we simplify our approach to getting to that goal. My answer is the following, at the end of every Sprint we should have:
"Production Ready, Working Software that Customers Love."
In a nutshell, that is what I have reduced my pursuit to. With that said, I am not sure this approach is perfect, or even the right way to look at things, but for now, for me, it works.
I’ve often held the perspective that there is no real ‘L’eadership roles within agile teams. The entire notion of a self-directed team in some ways confuses the role that leadership plays within agile contexts.
One of the leadership dynamics, at least from my perspective, is at the agile or Scrum team level. I’ve always observed that leadership is one of the central ingredients to a successful agile adoption. In fact, the larger the scale, the more important it becomes.
That being said, the larger the scale, the more incumbent managers and leaders struggle to figure out the new role they need to play in the shift. And quite often the organization really doesn’t support them (coaching, training, funding) in this effort. It’s sort of left as an exercise for the student; which mostly fails.
I spent about 3-years working at a company called iContact from 2009 – 2012. While there I reported to CTO – Ralph Kasuba.
Ralph was a wonderfully skilled leader and I’ve been reminiscing about him of late. Sure, we still stay in touch, but it’s not the same as working together each day.
Ralph had one “pet peeve” that I’d like to share and it involves interviewing. At the time, iContact was growing quite steadily, so it seemed as if we were always interviewing team members for our technical staff. We went through a period where no one seemed to pass our technical screens.
It was frustrating because the recruiters kept saying they were sending us qualified candidates, but the team-based interviews would just chew them up.
The language we started to use was that we were looking for Unicorn’s and not finding any.
I recently received the following email from Dwight Kingdon at Mindtree:
I’d appreciate your thoughts on “Just in time” Product Backlogs. I’ve recently run across a couple teams where the Product Owner is not populating the Product Backlog with user stories until just before they will be worked on. They have themes and epics, but do not break them down any further until a new sprint is about to start.
My thinking is that a robust Product Backlog of “potential” user stories is a good thing, as long as the stories there are viable, and the team doesn’t spend too much time getting into the details until they have moved up in priority to where the value is high enough that they will be worked on soon. It seems to me that having user stories sit in a Backlog until they either move up in priority or get deleted (due to lack of value) is not harmful, and gives the team a preview of potential future work that they can keep in the back of their mind.
What do you think about a “robust Backlog” versus a “lean/just-in-time Backlog”? Thanks in advance – I look forward to hearing your thoughts!
For years as I’ve been getting older, I often refer to myself as a “Dinosaur”. It’s not a bad analogy, as I’m getting quite old in the tooth.
I’m certainly not as technically astute as I once was, nor am I as mentally quick. And please don’t say that I was never all that quick.
But I read a blog post the other day from Jason Little that alarmed me. It brought the analogy home, as he is predicting the extinction of agile coaching.
I was sent a request to gather my idea on what Agile Maturity looked like from a column writer. Here’s her request:
Here's my thinking: In 2015, I heard many software pro's talk about "Agile maturity." But you had to listen hard to hear the phrase. Nobody shouted it from the rooftops; it’s not a buzzword, or even a new idea. It was more of a whisper, an aside that came up in the context of other topics: continuous delivery, better business alignment, mobile testing—to name a few. Yet it seems to me that this whisper is crucially important – that a mature Agile practice is the key underpinning for successful software development.
But what exactly does "Agile maturity" mean? It appears to run that gamut from advanced beginner teams flush with their first solid success to those are that doing continuous delivery, with high levels of test automation that entails.
What is your definition? Is your Agile mature? What are you working toward?
