I was talking with someone at a conference a few weeks ago and he asked the question:
What do you think about the concept of “Elastic Teams”?
To be honest, I’d never heard teams referred to in that manner, so I had to admit that I didn’t know. I asked, what do you mean by an “Elastic” team? He went on to explain.
He said that these are teams who are formed, dissolved, and reformed around business needs and priorities. For example:
If you had 3-5 teams working on a set of products in your portfolio and the overall business priority changed. Then you could possible shrink each of those teams by 3-4 individuals and assign them to another team (or group of teams) for 2-3 months.
If something else shifted, perhaps something smaller. For example, a customer escalation of a performance problem. Then you might shift members amongst teams to address the situation. In this case, it would hopefully be a shorter-term reassignment, and then things could go back to normal.
One of the new capabilities of my agile coaching practice is the ability to deliver the Scrum Alliance, Certified Agile Leadership (CAL1) class. It’s a relatively new certification for the Scrum Alliance and it targets the management and leadership levels within organizations who are planning to or who have already adopted agile approaches to software development.
I’ve been coaching agile transformations (organizations, groups, teams) for over 15 years. During that time, I’ve noticed that there are literally 3-tiers to any transformation:
- Sr. Leadership Tier
- Organizational Leadership & Management Tier
- Team Tier
Most organizations only focus the transformation or adoption towards the team level. But in my experience, success is in effectively guiding all three tiers towards agile principles, tactics, and leaner agile mindset.
In fact, I think the critical tier is in the middle.
I’ve sometimes heard it called the “frozen middle” because it’s where true agile transformation lies, but it’s the tier that often gets the least attention.
Enter – Certified Agile Leadership
The CAL is solely focused towards the middle-tier. And finally, we’re engaging leadership folks with training and coaching of their agile transformational skills.
It dawned on me the other day. I client asked for role-based guidance around ScrumMasters and Product Owners. One of my pointers was to the Meta-cast podcast that Josh Anderson and I do together.
But there are 100+ and counting podcasts there and I realized that it's very hard to cull through them all to get role-specific advice.
So I thought I'd pull together three lists in this post that align with the three Scrum roles: ScrumMaster, Product Owner, and Team. It's not intended to be exhaustive, but I think you'll find value in the discussions.
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.
Last year I posted my first "Sharpening the Saw" post in June. That inspired me to do it again for 2017, but closer to the beginning of the year. You'll probably see this become an annual post to remind me (and perhaps you) to plot a journey of continuous learning.
In 2001 I was laid off from Lucent Corporation in Raleigh, NC. At the time, I was a software development director leading a group of developers and testers implementing optical networking devices. It was incredibly complex work and the teams were dedicated to doing great things.
This was just post the 9/11 attack and the Telecom bubble burst so to speak. So, all of the large Telecomm companies were impacted.
I was placed on the building close-out crew, so I had a long period of time “managing” the reduction. At that time, I began to write a book. I completed it in 2002 and it was finally published in December 2004. I remember at the time being incredibly impatient as the publisher, Dorset House, took its sweet time in the editorial and printing processes.
In his latest newsletter, Len Lagestee wrote about Even Happier Product Owners. The piece shared 9 conditions of happiness for the Product Owner. Here’s a link to the blog post.
And here’s the list:
- They are immersed with their customers;
- They have the time and space to be visionary and creative;
- They have true ownership over their product;
- They are receiving meaningful feedback about the performance of their products;
- They have a positive working relationship with their Scrum Master;
- They have an even better relationship with technical leads and designers;
- They are proud of what the team is delivering;
- They have embraced their constraints;
- And, they are keeping themselves healthy.
I really like Len’s list as a baseline for the happiness and performance of the Product Owner role. I’d like to compare the list against my 4-Quadrants of the Product Owner role model.
Mike Cohn in a recent newsletter entitled: The Dangers of Definition of Ready made some solid points that have had me “thinking” ever since I read it.
You see, I’ve been a proponent of DoR for at least the past five years or longer in my coaching. I often “couple” the discussion with two areas:
- Definition of Done
- And as an “exit criteria” for Backlog Refinement
I actually consider DoR to be one of the healthier agile practices and I often recommend it to my clients. So I read Mike’s cautionary article with some trepidation. Hoping that I haven’t been misleading my clients in some way.
I’ve captured Mike’s exception to DoR in the below snippet from his post:
This description is intended to help guide the implementations of Scrum of Scrums at Program / Train level.
It all started with this picture that Mike Cohn published over 10 years ago. In the explanation he briefly mentioned a hierarchical structure where multiple Scrum teams get together when they are working on related projects.
Often I explain it as: team-based Scrum behaviors, just up a level.
I’ve been training and coaching agile teams for more than 15 years. While I’ve seen quite a lot of unique dysfunctions, one of the most prevalent is the overall lack of trust leadership trust in their teams.
There, I said it.
Quite often I use the term “little t” trust so that folks aren’t too offended, because really, nobody wants to admit that they don’t TRUST someone in today’s organizations. At least not out loud and visibly.
But the harsh reality is that most leaders do no trust their teams. And the other, even harsher reality, is that the teams know that they are untrusted.
I just read a truly interesting HBR article that focused on the role of management versus team members themselves in fostering an environment of creativity and innovation.
Most of the discussions today in this space, at least in my experience, are focused towards leadership or management being responsible for innovation. That is – in setting up the environment
Very little of the focus is team ward. In that, the team bears some responsibility for its own behavior, energy, and focus towards innovation.
The HBR article had some survey data that puts “the blame” squarely on both shoulders – that of “management” and the “team” in establishing the right climate.
In my view, that’s the right focus since we all play a part in creating an environment of experimentation, innovation, and creativity.