Looking for Agile Success – All You Need is Love

Like any professional should I spend a great deal of my time attending user’s groups, reading professional articles, speaking with leaders in my field, etc in an attempt to find ways to do my job better. This morning I stumbled upon a couple of interesting articles, The Unintended Consequences Of A Leader’s Lack Of Trust (whose link has gone inactive) and Employees leave managers, not companies. While not exactly writing about the love, these got me to thinking about love and its place fostering Agility.

It is the nature of my job to bond tightly with the teams that I work with and also to have to leave these teams frequently, as they achieve a high level of self organization, to pursue opportunities to help other teams. I am currently faced with one of these moments and the feeling, as always, is bittersweet. I am excited about my new opportunity but will genuinely miss the teams I have worked with over the past few months.

Continue reading “Looking for Agile Success – All You Need is Love”

Not Building a Car – The Need for More Appropriate Similes in Software Development

As humans we learn by analogy, metaphor and simile, adding new knowledge by initially relating the new to our existing understanding of the world. When we try to explain the software development process to the initiated (translation business stake holders), we use all kinds of similes to help them understand the process. The problem with similes is that they argue that something is like something else and many times people confuse the similes with metaphor, thinking that one thing is another. Not only do people confuse simile with metaphor, but many of the similes we use in explaining software development are not appropriate because they can cause more harm than good and they are not very accurate in their explanation.

Continue reading “Not Building a Car – The Need for More Appropriate Similes in Software Development”

Thoughts on Agile Coaching

When I tell people I am an Agile Coach, unless they are in IT, I tend to get a lot of strange looks. Most of the time they will say something like, “I get the coaching part, but what the heck is Agile?” It is at this part of the conversation that they experience immediate regret as I launch into an endless barrage of commentary on Agile development.

Lately, however, I have begun to re-examine my own assumptions about what it the Coaching aspect of an Agile Coach is, especially now that there are so many professional coaches looking for work after the end of the regular NFL season.

Continue reading “Thoughts on Agile Coaching”

Agile = Antifragile Part 2

Antifragile by Nassim Nicholas Taleb

I entered my previous post on the subject when I had just begun Taleb’s book Antifragile. As I continue my reading I have run into some very specific passages which lead me to theorize that the reason Agile development works so well is that it is a living, breathing example of what Taleb would call “Antifragile.” I am also coming to the conclusion that Taleb is a truly great contemporary thinker. As I examine my own career, I plan to take to heart many of his suggestions on creating one that is Antifragile.

While I am no in any way paid to sell this book, I encourage all Agile folks to highly consider adding this to their reading list.

Continue reading “Agile = Antifragile Part 2”

Agile = Antifragile?

I am currently reading the book Antifragile: Things that Gain From Disorder by Nassim Nicholas Taleb. I loved two of his other books, The Black Swan: The Impact of the Highly Improbable and Fooled by Randomness: The Hidden Role of Chance in Life and in the Markets so I thought that I would give this one a go.

His central thesis is that there are systems that are not only robust, able to withstand randomness and chaos, but there are those that actually thrive on such events. He calls these “antifragile” as opposed to fragile systems.

Continue reading “Agile = Antifragile?”

It’s Time for Companies to Add Agile to C-Level

larry apke agile doctor chief agile officer

larry apke agile doctor chief agile officer

The more companies, teams and C-level employees that I work with (and I have had the good fortune to work with many), the more I am convinced that implementing Agile can only go as far as the highest knowledgeable company officer who is supporting it.

What we need are some Chief Agile Officers – CAOs.

As an example, I had one consulting job to implement Agile within a team using Scrum framework after numerous internal attempts had failed. While I was able to move them closer to agility, it did not take long (as happens during an Agile transformation) to have it dawn on me what, or who, the problem was. It just so happened that this particular team had a Vice President that played the role of Product Owner.

So, in short, this VP had limited understanding and buy in for the scrum process, therefore we hit the ceiling at the VP level. Bringing a team into the Agile methodology is not that simple, so yes, there will be problems if someone does not thoroughly understand the process.

On another transition we had a Director and VP of Software Development who had different viewpoints on Agility (both correct on some points and incorrect on others by my calculation) and continually undermined each other in that no lasting tactical decisions could be made. To add to the confusion was a strong operations department that did not want to play with others in the Agile world. While the Chief Technology Officer gave verbal support to Agile processes, he proved unable to referee his immediate subordinates successfully and the Agile implementation languished.

And what both of these experiences have taught me is that Agile is about a great deal of things, but is primarily about organizational change around a philosophy. In order for it to work, there needs to not only be support from the highest levels, but a deep understanding of what it takes to be Agile. This means that someone needs to be at the C-level to make sure there are sufficient resources and that conflicts can be resolved.

Essentially, everyone needs to be on the Agile train. Otherwise, they are getting left at the station.

Also one of the reasons that Agile works so well with small companies is that the people in power know Agile and how to harness it for effective change. Decisions that need to be made to change systems are done efficiently.

One of the reasons that Agile has floundered at many large organizations is that it runs into resistance at some level in the organization. Once it hits this “glass ceiling” it needs the proper support from the next level of the organization to clear impediments. In many cases some Agility can be achieved but for the most effective change, impediments must be removed for the entire organization. The only folks with that kind of clout are at the C-level.

Therefore, it is my contention that you will begin to see a new position emerge – that of Chief Agile Officer – along with all the power this position needs to ensure better Agile implementations.

And for those organizations ready for this radical change, I am ready to report for duty.

Larry Apke