Blog - 6/16 - Agile Doctor

16 March, 201519 August, 2016

The PMO is Dead. Long Live the PPMO!

One of the most enjoyable parts of my work and my life is delivering presentations or giving talks to outside groups. During one particular Q&A session I was asked a question along these lines – “If you had unlimited power in an organization, what would be the very first thing you would do to ensure agility?”

My answer, “Oh that is easy. The very first thing I would do is get rid of the Project Management Office.” At which I unfortunately took a pause. The collective gasp from the crowd filled that void and the ensuing murmur drowned out my next statement. You see, I was addressing a PMI group, and my statement proved to be provocative to say the least.

Unfortunately, what the now somewhat irate crowd didn’t hear (or pay attention to) was the statement, “And I would replace the PMO with a PPMO – a Product and Project Management Office.” Contrary to their thoughts that I wished to abolish the PMO, I was actually giving them more – another “P” as it were – a whopping 25 percent increase in letters!

I have railed against project focus other times because it is not a good model when it comes to creating software products. A project has a definite beginning and end whereas software products do not. Of course, software products are sometimes “sunset ” but such plans are often not realized as quickly as proposed. For example, I was once put in charge of “sun-setting” a software product with a timetable of three years. Now, seven years later I am no longer with that company, the company is no longer in that business and yet that old legacy software chugs along, making money for its new owner.

The funny thing about Project Management Offices in software development is that the majority of their work is really on software products. Of course, there are always some projects thrown in, like update the servers to a new operating system, but mostly we work on products whose future enhancements and support live far longer and cost far more than the original bright shiny objects our projects spun off.

The problem is that when we incorrectly treat our products like projects we tend to produce a huge amount of technical debt. Those bright shiny objects come with a huge hidden cost that project mentality allows to remain hidden. When we acknowledge that we are creating products we tend to take care of the long term health of the product, we make better decisions.

So let’s all say goodbye to the old PMO. It had a good run but its time has come. In its place let’s great with open arms the new and improved PPMO!

– Larry Apke

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Android | RSS

3 March, 20153 March, 2015

The Gang of Four – How Optimization Perseveres

It must be the new year that has me waxing nostalgic again. My last post was of rockstars past and while I was working on that on that one I was also reminded of some others I had a great affection for, a group that I was a part of we called the “Gang of Four”. This was a tongue in cheek nod to the Gang of Four who were authors of a book on design patterns.

The impetus for the Gang of Four was the desire of four agilists to try to do the right things with regards to implementing agile and scrum – to do things that were generally acknowledged as good agile practices but things that were not necessarily politically palatable. In other words, we were something of a clandestine organization. In fact, our meetings, while not in a secret location, were held in a location well off the beaten path – so much so that some of us had to literally walk 15 minutes to get to our meeting room. Over time we added another like-minded individual but kept the original name. Hell, we even had a ironic salute we would give to each other when we would pass in the hall. It was in the company of these wonderfully dedicated people that I spent the most enjoyable time I had on this gig.

What is important and pertinent to this blog is not the nostalgia or shout out to my compadres (though it pleases me to think they might read this and reflect with happiness), but that regardless of your office politics, your cronyism, your brown-nosing, your ladder climbing or your sheer incompetence and general ineptness, there will always (or rather you should hope there to always) be those who will have the uncompromising desire to succeed in spite of your inanity.

Like a tree whose roots will break rocks in order to drink of the water that sustains it, there will be individuals and teams in your company that will persevere against the all odds to do what is right, to do what is best for the company. Seek these out and when you find them give them the environment that they need because if they survive on rocky soil just imagine what they can do on a proper plot of earth.

Long live the Gang of Four.

9 February, 20153 March, 2015

The Difference Between True Rockstars & Pretenders

rockstar, guitar, rockstar team, agile team, larry apke agile

I’ve had the pleasure of working with hundreds of teams during my time as an Agile coach. I have loved and enjoyed working with each and every one of them. There are some though that are more memorable than others.

Frequently it is those teams that I coach first in any organization – in psychology this would be referred to as the primacy effect. Sometimes it is because of the nature of the team. Recently I found myself waxing nostalgic for one very particular team that was my first team and also memorable because they were “rockstars”.

Let me make it clear that the team name was not “rockstars”. I have had many teams in my time self-identify their team with the name “rockstars”, but, somewhat predictably, these self-proclaimed “rockstars” rarely lived up to their own press. The team I am thinking of was one that was hand-picked and put together because they were true high-performers within the organization. They were the best programmers, QA and management.

While the generally accepted belief is that creating a functioning team of rockstars is fraught with difficulties because many have over-sized egos, I did not find that to be the case with a true “rockstar” team. It was the pretenders to rock stardom who had egos and were difficult to manage. It did not take long to figure out the difference between true rockstars and pretenders. It all boiled down to one thing:

True rockstars listen.

(And, of course, they do not refer to themselves as rockstars).

As a coach, a big part of my job is getting people to change their behavior. The true rockstars became the way they are because they have listened, because it is more important to them to be the best then to appear to be the best. The true rockstars know that they will make mistakes from time to time but in order to be the best, they must try new things from time to time, to stumble and fall sometimes. Of course, the true rockstars always get back up, dust themselves off and work until they succeed.

That is not to say that true rockstars will not challenge a coach and take everything that is said without question. They are the best because they question everything, but they also accept that learning can happen anywhere at anytime and can come from any source, even from a coach whose programming chops would never measure up. Once they are convinced that you are not wasting their time, they will not only listen but they will readily adopt ways of implementing new ideas. My own group of “rockstars” were tasked with taking cutting-edge technology and delivering it to customers many times faster than ever before in their organization and they did, not just once, but on multiple occasions. I believe that their success hinged primarily on the fact that they were smart enough to listen, not only to me, but to any and all who might have something, no matter how small, to help them become better.

The pretenders are different. They are closed to new ideas because they have all the answers. They use their experience as a reason not to listen to others. Their ego is so tied with their “rockstar” status that change is a threat. To change would be to admit that they were not the experts, that they do not know everything.

Beware the pretenders.

– Larry Apke

3 February, 20158 February, 2015

Timely Feedback – Why Agile Works

Most folks who know me well know I like to talk.

I especially like the times when I get to speak in front of groups, whether a face-to-face presentation, a small user’s group or 160 on a conference call all over the world (If you have a group and want a passionate speaker – feel free to call on me).

Sometimes my passion provokes long stories, explanations or asides. Lately though when I speak to others about why agile works, I eschew my sometimes verbose ways and reply with two words – “timely feedback”.

These two words refer back to my argument that software development is, as described by Snowden in his Cynefin Model, complex as opposed to complicated. And complexity begs for timely feedback.

Take a look at the most popular Agile processes and practices and you can see why they are effective. They all are merely ways to produce timely feedback.

Daily standup = daily feedback.

Review, retrospective, grooming, planning – all are timely feedback.

What is automated testing on code check in or continuous integration and deployment? Feedback. Pair programming is nothing more than continuous immediate feedback.

Conversely, what is waterfall than a dearth of feedback? Compared to the continuous timely feedback of agile, waterfall is a vast wasteland of opacity.

So next time you are asked why agile works, or why a shorter iteration is better, or why we should do pair programming, or why continuous integration, take the quick route and prove that brevity is indeed the soul of wit and simply say, “Timely feedback”.

– Larry Apke

25 December, 201425 January, 2015

Sony IT Insider Claims Hack Not From North Korea

As a software development consultant, agile coach and someone who has been in the IT industry for nearly 20 years, I’ve had the pleasure of meeting literally thousands of IT executives. One of my contacts, who just happens to work at Sony, reached out to me this week and urged me to “blog to the world what really happened”.

He stated that the recent hack on Sony was not perpetrated by the North Korean government, but was one of a series of attacks that have been going on for over two years. According to my source, these recent attacks were part of a longer term series of snooping breaches that included successful DDoS (denial of service) attacks during the World Cup based on Sony sponsorship of FIFA.

My source was further dumbfounded by the US government’s response and the press briefing given by our President given the history of attacks that Sony has experienced over the years. While he agreed that the threats to theaters was something best handled by Homeland Security, he also stated that Sony has two media companies, Video Unlimited and Crackle, that could handle release of the movie The Interview.

My source goes on to state that the pattern of attacks have been known to Sony and that they have worked with 3rd party vendors to beef up security and have been successful in preventing additional attacks and that Sony is beginning the forensics to understand when and how the breaches occurred in the first place.

My personal opinion is that it is possible that the recent hacks were perpetrated by the North Korean government and that my source is confusing the previous DDoS attacks with the newer breaches. What I find more interesting is the speed with which the culprit was identified and the coincidence that the villain would be the same as the one depicted in the film. Of course, this whole fiasco is a wonderful marketing coup for the movie and with the free publicity in the press (including this blog if you can refer to it as the press), it will garner more revenue than it merits.

The only other time I ventured to blog about current events was the Healthcare.gov fiasco and in both these cases there was a speedy judgement and presidential pronouncement. While the press and politicians like a simple world with clear, black and white solutions (anyone find any weapons of mass destruction in Iraq lately?), my experience has taught me that the world of software development and computer networks is much more complex. In the end, we may find out that the hack was by the North Korean government or that my source at Sony was correct. Only time will tell.

– Larry Apke

10 December, 201425 January, 2015

Technical Debt: What It Is and Why You Should Care

I was recently invited to write an article about technical debt for Software Development Times (SD Times).

My personal experience is that technical debt is rarely understood, especially by our business partners, and is a symptom of the continual misapplication of project-centric thinking in software development.

– Larry Apke