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
My first piece of advice is this:
DON’T DO IT!!!
Probably the worst possible setup for “team” is spreading them around the country or the world or the universe and expecting them to behave and deliver like a close, cohesive team.
My second bit of advice for those of you that blame it on “Management” and say you don’t have any say in the matter…is:
WRONG, YOU HAVE LOTS TO SAY IN SUSTAINING DISTRIBUTED TEAMS OR CREATING ANOTHER STRATEGY!!!
I hear this situation (excuse) all of the time. An organization has inherited distributed teams yet also wants to move to more agile approaches. They understand that these teams can be less than optimal, but are reluctant to do anything about it. That is but complain about it.
I recently read an article entitled Engineering Culture and Distributed Agile Teams that was published in InfoQ. In it, the editor called out the following strong themes or takeaways:
Key Takeaways
- Team structure reflects in product architecture
- Distributed teams can perform pair programming by using some remote pairing techniques and tools.
- Microservices influence a good distributed team structure
- Increase co-ordination within a team by encouraging T-shaped engineers
- DevOps tools and practices are valuable for Distributed Agile Teams
- Increase efficiency of Continuous Integration and automation testing in distributed teams by using cloud
While the article is titled and implies a focus on culture, it really focuses more on technical tactics or tooling as the key to distributed teams.
