My Agile 2014 Book Report
I don’t do conferences. The last Agile conference I was at was five years ago, in 2009. So although I’ve been engaged in the work, I haven’t spent much time with large groups of Agile practitioners in some while. I thought it might be useful to folks if I wrote down my observations about the changes in five years.
- We’re starting to engage with BigCorp environments in a more meaningful way. There’s still a lot of anger and over-promising going on, but the community is grudgingly accepting the fact that most Agile projects exist inside a larger corporate structure. If we want to have a trusting, healthy work environment, we’re going to need to be good partners.
- Had one person come up to me and say something like “You know, you’re not the asshole I thought you were from reading you online.” It would do well for all of us to remember that for the most part, folks in the community are there to help others. It’s easy to be misunderstood online. It’s difficult to always assume kindness. Being snarky is just too much fun sometimes, and people don’t like having their baby called ugly. In fact, it’s probably impossible to fully engage with people online the way we do in person. We should know this!
- I’m continuing to see creative things emerge from the community. This is the coolest part about the Agile community: because we don’t have it all figured out, there is a huge degree of experimentation going on. Good stuff.
- In many ways, Agile has lost its way. What began as a response by developers to the environments they found themselves in became a victim of its own success. It’s no longer developers finding new ways of developing software. It’s becoming Agile Everything. I don’t have a problem with that — after all, my 2009 session was on Agile in Non-Standard Teams — but there’s going to be a lot of growing pains.
- The dirty secret is that in most cases (except for perhaps the biz track?) the rooms are filling with folks who already agree with the speaker. But speakers spend time justifying their position anyway. For such a large group, there was quite a bit of clanning. Sessions were already full of cheerleaders. It might be good to clearly understand whether we’re presenting something to the community for their consideration — or presenting something they already love and showing how to get others to like it. These are incompatible goals for the same session.
- Maybe it was just me, but for such a relaxed group of facilitators, there was quite a bit of tension just under the surface. For a lot of folks, the conference meant a big chance to do something: to get the next gig, to meet X and become friends, to hire for the next year, to start a conversation with a key lead. It was all fun and games, but every so often the veil would slip a bit and you’d see the stress involved. I wish all of those folks much luck.
- Dynamic Open Jam areas were awesome. Even though nobody cared about my proposed session on Weasels, I thoroughly enjoyed them.
- I saw something very interesting in Open Jame on Wednesday. We were all doing presentation karaoke. A big crowd had formed to watch and participate; perhaps 40 folks. But our time was up. So the leader of the freeform session said “Our time is up, we should respect the next person, who is here to talk about X”The guy gets up and somebody from the crowd says “Hey! Why don’t we just combine the two things?”So we spend another five minutes doing both presentation karaoke and talking about the new topic. That way, we maximized the number of people that stayed involved, while at the same time switching speakers. It was a nice example of both being respectful and adapting to changing conditions.
- The party on the last night was most enjoyable. I think this was the most relaxed state that I saw folks in. Not sure if the alcohol had anything to do with that Lots of great conversations going on.
- Where did all the developers go? Maybe it was just me, but it seemed like there was a lot more “meta” stuff presented. It didn’t seem like there was as much technical stuff.
Good and Bad
- People really hate SAFe (The Scaled Agile Framework, a detailed guide supposedly describing how to run teams of teams in an Agile manner) — to the point that some speakers had a shtick of opening mocking it. I’m process agnostic — I don’t hate anything and all I want is to help folks. SAFe, like anything else, has good and bad parts. Keep the good parts, ditch the bad parts. But for some, SAFe seems like a step backwards.
What concerns me about watching both sides of this is the emotional investment both groups have in already knowing how things are going to turn out without the necessarily huge sample size it would take to determine this for the industry as a whole. One group might think “Why of course Agile is going to have to evolve into more traditional product management. How else would it work?” The other might think “Why of course we would never put so much structure into what we do. That’s what prompted us to become Agile in the first place.”
Look, I don’t know. Give me 1,000 examples of SAFe actually being deployed — not some arcane discussion about what the textbook says but how it actually works in the real world — and I can start drawing some conclusions. Until then? This is just a lot of ugliness that I’m not sure serves a greater purpose. Sad.
- UX, or figuring out what to build, is making waves. Some folks love it, some folks think we’re back to imposing waterfall on the process. I tend to think a) because it takes the team closer to value creation it’s probably the most important thing the community has going right now, and b) it’s just not baked enough yet. At least not for the rest of us. (I don’t mean that practitioners don’t know what they are doing. My point is that it is not formed in such a way that the Agile community can easily digest it.) That’s fine with me, but not so much with others. I’m really excited about seeing more growth in this area.
We are realizing that any kind of role definition in an organization can be a huge source of impediment for that organization growing and adapting. You’re better off training engineers to do other things than you are bringing in folks who do other things and expecting them to work with engineers. So much of everything can be automated, and whatever your role is, you should be automating it away.
Having said that, I don’t think anybody really knows what to do with this information. We already have a huge workforce with predefined roles. What to do with them? Nobody wants to say it directly, but there it is: we have the wrong workforce for the types of problems we need to be solving.
Finally, it’s very difficult to be excited about new things you’re trying and at the same time be a pragmatist about using only what works. It’s possible, but it’s tough. If Agile is only love and goodness, then you’re probably doing it the wrong way. Agile is useful because the shared values lead us into exploring areas we are emotionally uncomfortable with. Not because it’s a new religion or philosophy to beat other people over the head with. It should be telling you to try things you don’t like. If not, you’re not doing it the right way. Enough philosophy (grin).
August 5, 2014