There’s been a movement afoot in the agile community for a while. It’s about getting back to basics. I characterize it as:
- Agile leadership is nice, but…
- Agile planning & forecasting is nice, but…
- Agile Project Managers are great, but…
- All the certifications are nice, but…
- Scaling frameworks are nice, but…
- Accenture, Gartner, etc. interest is nice, but…
- DevOps and Business Agility are nice, but…
- Adoption, transformation, etc. are nice, but…
- Making $billions is nice, but…
We’ve lost the essence of agility. We’ve forgotten the very things that got everyone excited in the first place. The simplicity. The power of the team. The results that an engaged customer can inspire.
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
I’m beginning to think that we’re too focused on the team when we talk about agile. Everything is focused towards that end.
Team this and team that.
But what about the individual on the team? I contend that they count too.
- Make sure your voice is heard; in many team’s individuals can get lost. Often the loudest of voices seem to become the default voice of the team.
- Make sure you take time for yourself; self-learning, downtime / reenergize, reflection are keys to your personal growth and learning. Always increase your value proposition – you.
- If you’re introverted, give yourself permission to be alone; this includes working from home and “separating” from the team on occasion to work by yourself.
- Gain personal feedback; don’t get caught up in team-only feedback loops. While important, you need personal feedback as well. Make sure you’re getting it from your team and leaders.
I’ve been presenting at conferences for years. Over 20 years to more precise.
One of the common occurrences is that someone points out a typo or grammatical error on one of my slides in the comment section of the feedback form. I recently had this happen in a Certified Agile Leadership class. One of the feedback post-it notes on the first day pointed out a few typos. While I appreciate the feedback, I often wonder if there is more feedback than simply minutia…
If you read the feedback on Amazon for my Scrum Product Ownership book, some of the reviewers say the same thing. They talk about copy edit quality and the errors. These folks are right. I should have spent more time and money on the editing process. But if you look at the vast majority of the reviewers, they seemed to have overlooked those mistakes and received great value from the book.
And the detractors really seem to rate the book much lower based on the simple errors, simply overlooking the real value of the book. It’s as if they can’t see the forest for the trees.
When I first started my agile journey, there was a small set of certifications. The Scrum Alliance was the “lead dog” in the effort. Around 2003-2004, there was only the CSM, CSPO, and CST certifications. Life was quite simple then.
Over the years, I believe folks started to get the sense that there was “money to be made” in this area. Lots of money. So certifications began to “pop up” more and more.
Much of this certification frenzy bothers me because it flies in the face of most of the agile principles. In fact, I’ve found that the money can corrupt even the best of agile trainers and coaches. But that’s not the point of this post.
My curiosity got the better of me and I wanted to see just how many certifications I could find. So here it goes...
I just watched a video by Mishkin Berteig where he clarified that the concept of a Sprint #0 is NOT part of Scrum.
A few weeks ago, a colleague of mine tweeted about the concept of Hardening Sprints. If you’re aware, the Scaled Agile Framework has “dabbled” with hardening sprints and other “extensions” to Scrum. Ron Jeffrey’s strongly, clearly, and repeatedly responded that hardening sprints are NOT part of Scrum. It became physically painful as Ron pounded his point over and over again in tweets.
I’m an insider (a CEC) to the Scrum Alliance CST & CEC discussion group. Some of the most heated discussions I’ve ever seen there revolved around the definition of Core Scrum in the Agile Atlas. This was before the Scrum Alliance centered on the Scrum Guide as the clear definition of Scrum.
I was watching an NHL game the other evening. The team was playing a hockey game without a goalie.
Apparently the team had decided that their goalie was too expensive. So they traded him away to another team.
Then the backup goalie was sick. And his equipment didn’t fit anyone on the team, so they decided to “go without”.
In a pre-game interview with the General Manager, he said that it was strictly a financial decision. They felt that the team could fill in the goalie role by sharing it amongst themselves.
If it worked out as he expected, then they might consider this change as a permanent part of their hockey team structure.
At the very end of the interview, he wondered –
What does a Goalie do anyway? For 90% of the game they’re idle. What a waste of money. Why not get the team to “pitch in” and fill that role? It just makes good sense…
I was reading the latest newsletter by Gojko Adzic this morning. The title of the newsletter was – How to Reduce the Cost of Testing and the themes were mostly focused towards test automation.
It also bordered on that age-old argument that as you automate, you need less and less “testers”, so costs naturally are reduced.
We’ll, I woke up a bit grumpy this morning and I have a revelation to share. If you really want to reduce the cost of testing, then…
There’s a trend in the agile community of influencing folks away from saying no, instead saying: “Yes, And…” as a means of connecting various conflicting points together. I wanted to use the same mechanism for the title of this article, because I think we need to start looking at the basic Scrum certifications in a different way, perhaps the same way we view Peanut Butter AND Jelly. Let me try and explain.
I’ve seen an incredibly alarming trend over the last 1-2-3+ years in my coaching. It involves whoever is teaching Certified ScrumMaster classes; whether they be from the Scrum Alliance, Scrum.org, or elsewhere.
I encounter quite a few organizations and many teams in my travels. Almost universally they are adopting Scrum and have a few to many CSM’s around to guide the transition.
But I’m finding that the “Scrum” that is being fostered and guided in these organizations leaves a lot to be desired. Often:
