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?
I’m a volunteer for the Scrum Alliance helping to facilitate Global Coaching Retreats. The retreats are for anyone who currently does or is interested in doing agile or Scrum coaching.
You can find out more about them here:
https://www.scrumalliance.org/courses-events/events/coaches-retreats
Now I want to share a funny story, at least to me, that gets to the heart of what attending the retreats is all about.
I hate to admit it, but I’m a relatively ad-hoc agile coach. I don’t use a lot of frameworks or tools. I mean I have a few that are well used and well worn, but I don’t have a toolbox the size of Montana (that’s big for folks outside of the United States).
I compensate for the tools with my overall experience. I’m coming up on 40 years of overall experience and 25 years of leadership experience in software development, so that helps me quite a bit in my coaching. And I’ve been leveraging agile approaches since the mid-to-late 1990’s.
That being said, I’m aware of this gap and I’m frequently looking for powerful tools to add to my coaching arsenal.
