Over the past several years, as I’ve been helping teams and organizations improve their ability to deliver software products that are desirable, viable, and feasible, I have been experimenting with a Behavior Framework that has proven to be rather effective. And I’d like to share it with you in hopes that you find it useful and that you provide me feedback on your experiences with it.
The Origin
I was once engaged with a large company that was probably nine years into an agile transformation. There was a primary consultancy, whom I did not work for, that was heading up this round of the transformation — I think they were on round four or five.
Anyway, as a part of this transformation effort, all teams were being measured through an agile assessment process. This process included answering dozens upon dozens of questions about specific activities the team was expected to engage in. Teams had to complete the assessment at least once per month — typically a several hour process. The assessment was also a requirement for a team to be recognized for reaching the next level of agile maturity. The consultancy insisted it wasn’t a maturity model, but it clearly was.
I was in a conference room with some folks in management positions with the client when I went on a bit of a rant about the agile progress theater.
“Well, Doc, how would you assess teams? How would you know where they are in their agile progress?”
“I probably wouldn’t assess them.”, I said. “But if I were to, I don’t know… I suppose I would look for certain attributes on the team. Certain behaviors to show up.”
“Such as…?” asked one of the managers.
So I grabbed a dry erase marker and I wrote a few things on the board.
“Well, they’d know the problem they’re solving. They’d be working together a lot. They’d be paying attention to composition. They’d be releasing often. And… um… they’d be validating as they go.”
A couple of days later, I refined the list a bit and took it to one of the teams. We posted it on the wall in the team room and we checked in with each other on how we were doing expressing these “behaviors”. It resonated. It gave them some latitude and they thought more about how they could approach things rather than what the model said they had to learn or do next.
Over the years, the list of behaviors has been modified and updated as I’ve used it more places and with more teams. For the past few years, it hasn’t changed. I think, it is ready to be shared more broadly.
The Behaviors
Know the problem you are solving.
Make the work visible
Work together.
Create simple things in small steps.
Be meticulous about composition.
Validate before, during, and after.
Release ridiculously often.
Favor automation over documentation.
I’ll be diving into these behaviors quite a bit in future articles. But today, I want to acknowledge a couple of things.
First, this list is by no means comprehensively exhaustive. I am sure there are things that could be added. In fact, I know there are. But in my experience, this list contains enough of the necessary behaviors, that it is sufficient. And I have not found a context were any one of these behaviors is detrimental. Difficult, perhaps, but not harmful.
Second, this list is not mutually exclusive. There is a lot of crossover between the items on the list and I think that is a good thing. For example, creating simple things in small steps would improve overall composition, but not as much as being meticulous about composition. And both of those enable releasing ridiculously often, but neither of them mandates it.
A request
I’d really appreciate it if you could think about the list for a bit and then share with me any thoughts you have about what each of the behaviors means to you.
More specifically:
What activities would you see teams engaging in for these behaviors — for example, Test Driven Development for “Validate before, during, and after”?
What tools would support one or more of these behaviors — for example, Backlogs for “Make the work visible”?
If you want early access to these articles, come on over to https://docondev.substack.com/ where I’ll be publishing articles a month or two ahead of other platforms.