Agile - 7/13 - Agile Doctor

23 October, 201419 August, 2016

Managers from Hell and Agile Transformation

“Here’s something they’ll probably never teach you in business school: The single biggest decision you make in your job — bigger than all of the rest — is who you name manager. When you name the wrong person manager, nothing fixes that bad decision. Not compensation, not benefits — nothing.”

Jim Clifton, Chairman and CEO, Gallup – State of the American Workplace

A few months back I stumbled onto some research done by Gallup on employee engagement quoted from above. I would like to say that their findings were shocking, but having been an Agile Coach at many large organizations, I find the statistics (and conclusions based on the statistics) to track quite close to my own experiences.

For example, Gallup found that only 30% of all employees in the United States are “engaged and inspired at work” and about 20% are what have been defined as “actively disengaged” employees who “aren’t just unhappy at work; they’re busy acting out their unhappiness. Every day, these workers undermine what their engaged coworkers accomplish.” The remaining 1 out 2 workers are defined as “not engaged” and “essentially ‘checked out.’ They’re sleepwalking through their workday, putting time — but not energy or passion — into their work.”

And take a wild guess what the number one indicator of employee engagement is. You got it – their manager. In another article, Gallup estimates that “companies fail to choose the candidate with the right talent for the job 82% of the time” (Why Great Managers Are So Rare). In other words, next time you are in a meeting with five managers, it is safe to assume that only one (maybe two) were the result of good hiring decisions. If you are a good manager meeting with other managers chances are good that everyone you are speaking with was the result of a poor hiring decision!

The fact that management hiring decisions are so poor should be of some comfort to you the next time you are passed over for the management job you know you can do well, but is little comfort to active agile coaches like myself who are actively trying to help a company get agile and stay agile. On the other hand, knowing this goes a long way in explaining why most companies have so much trouble with the transformation.

Without the support of managers, lasting agile transformation will not occur. The fact that the bulk of your managers are poor leaders just makes it that much harder. Gallup estimates that only 1 in 5 current managers have the abilities to “naturally engage team members and customers, retain top performers, and sustain a culture of high productivity.” Agile is all about engagement. It demands leaders who can engage developers.

So you say you want to be agile? Why don’t you start with hiring better managers? Stop relying on third-party vendors to find your talent. Grow your talent. Recruit your own talent. Find CIOs, VPs, Directors, Managers, Coaches who understand agile, can truly lead agile teams and engage developers.

Go ahead. I’ll be waiting for your call. Of course, it may be a long wait.

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Android | RSS

29 September, 201427 September, 2014

How Would You Rate Your Organization?

larry apke, devops, cultural shift, agile doctor, software development

While browsing the 2014 State of DevOps Report, the authors referred to a study by a Professor Westrum of Eastern Michigan University called A Typology of Organizational Cultures. In this article, Westrum studied the flow of safety information within hospitals, how that flow could be classified into an organizational typology and what effect that typology had on organizational safety. His conclusion was that:

“Because information flow is both influential and also indicative of other aspects of culture, it can be used to predict how organizations or parts of them will behave when signs of trouble arise. From case studies and some systematic research it appears that information culture is indeed associated with error reporting and with performance, including safety.”

The table below summarizes Westrums types:

Pathological	Bureaucratic	Generative
Power Oriented	Rule Oriented	Performance Oriented
Low cooperation	Modest cooperation	High cooperation
Messengers shot	Messengers neglected	Messengers trained
Responsibilities shirked	Narrow responsibilities	Risks are shared
Bridging discouraged	Bridging tolerated	Bridging encouraged
Failure leads to scapegoating	Failure leads to justice	Failure leads to inquiry
Novelty crushed	Novelty leads to problems	Novelty implemented

In the DevOps Report, they tracked the ability to be successful with DevOps to the three organizational types Westrum mentions: Pathological, Bureaucratic and Generative.

They found, unsurprisingly I might add, that the ability to successfully transition to a DevOps culture was tied to the organizational culture, with the most success seen by Generative organizations.

“DevOps” is now the new buzzword, but the 2014 State of DevOps Report (and Westrum’s typology) reinforce that DevOps is clearly a cultural shift and that large organizations, which tend to be pathological as a rule (with some of the more noble ones merely bureaucratic) will only implement “DevOps” in name only or as a repackaging of the existing operational silo.

While the authors of the DevOps Report tied Westrum’s typology to DevOps implementation, the relationship between culture and a larger organizational adoption of Agile are crystal (pun intended) clear. I would go so far to say that in my extensive experience with organizational transitions to Agile that until the issues of culture are addressed by upper management (by a C-Level Executive – perhaps a CAO) then even attempting to make an Agile transition is not only destined to fail, but more than likely, fail in spectacular fashion.

At issue is not whether you can get some short term gains at the team level, but that without cultural support, whatever gains made will be unsustainable.

In my experience there are a few things likely to happen:

First, you will optimize the team at the expense of the system. There is little benefit to creating code faster if it cannot be deployed (hence the new DevOps push).
Second, you will optimize team speed at the expense of quality. In Pathological and Bureaucratic organizations the shift to quality is unlikely to be embraced so creating features faster only increases technical debt faster.
Third, as the novelty of the Agile implementation fades (think Hawthorne effect), what you are left with is a group of individuals who are increasingly disgruntled by the consistent failure of the larger organization and upper management to remove even the most fundamental impediments. What’s the point of showing people a better way to create software and then not allowing those people to actually do it? It is at best incompetent and at worst borderline criminal.

I suspect that a great deal of the backlash Agile has received of late is directly tied to Pathological and Bureaucratic late adopters flailing at a transition to Agile.

My advice? Ask yourself, or, better yet, ask your employees to honestly rate your organization with regards to Westrum’s typology

If you are identified as Pathological or Bureaucratic, address your culture issues first before embarking on Agile transformation.

Agile coaches can help if they are allowed to work directly with upper management to help them to change the culture, but having them work directly with teams (without addressing culture) is like sowing seeds on a footpath.

5 June, 2014

One More Big Reason for Adopting BDD

picjumbo, larry apke, joel software, larry apke bdd, bdd adoption, agile, agile scrum

I have always considered Joel on Software as one of the best bloggers on software development that exists.

I absolutely love his approach to software development and should he ever open an office west of the Mississippi I would be the first to send my resume!

While doing research on another blog topic, I came across his famous blog on the Netscape rewrite. As happens from time to time, a universal truth crashes into our consciousness causing a virtual cascade of neural connections to fire, providing in the instant the “Aha!” moment. It came to me as I read the profound truth that is “It’s harder to read code than to write it..”

I was blown away because while my post, 10 Reasons Why BDD Changes Everything, has some great reasons to adopt BDD, after reading Joel’s blog again (which I had done before and did not explicitly make the connection), I think I might have missed perhaps the most important reason for BDD.

So here’s one more reason, inspired by Joel, for adopting BDD, namely: If it is harder to read code than to write it, BDD provides a simple and concise method for making the code that we write frighteningly easy to read (especially when compared with how most code is currently written).

Over the last three plus years I have coached adoption of BDD at all of the companies I have consulted and have constantly asserted that a team (and the larger organization) cannot be agile over time (anyone can be agile over a short period) without adoption of some form of ATDD (my choice being BDD) and continuous integration / delivery.

I challenge anyone to change my mind with solid proof. So far only one inexperienced scrum master has even tried!

Conversely, the more I read from software development professionals whom I admire and trust (like Joel) the more I become convinced that my position is correct.

Tell me your thoughts.

– Larry Apke

18 November, 20131 February, 2014

Why Agile is the Answer for Healthcare.gov

I have purposely tried to not comment about the Healthcare.gov website and it’s issues, but the landslide of wrong-headed information written on the subject has prodded me into adding my small voice on the upside that someone reading my this post will learn from this software development fiasco that we all have paid so dearly for.

Most unfortunate for those trying to learn from this is that the issue is so politically charged that to discuss it objectively is nearly impossible. The desire to place blame is too deeply ingrained in the human psyche to not point fingers – and this, for anyone capable of laying politics aside is the second lesson – the lesson that assigning blame is a human instinct that is not always productive in solving problems. Root cause analysis is essential to fixing systemic issues and may tangentially point to individual failings, but placing blame should not be primary.

And this leads to the first problem – the fact that this issue can rarely be discussed without politics. Once we have chosen sides, not only do we move from objective root cause analysis to finger pointing, but we begin to be tainted with confirmation bias in that everything we hear, read, experience is pulled through this lens. Therefore, this means that anything contrary to our preconceived political leanings are completely ignored or logically forced into their respective procrustean bed.

In my agile world the cautionary tale is about how office politics can certainly derail our best efforts to be agile. It is only in an apolitical atmosphere where true organizational change can occur. Where facts are not valued and the truth depends on the individual posting it, then the frank, brutally honest conversations (borrowing from Jim Collins’s saying in his book Good to Great) that are necessary to effect real change are never had. In some cases the only people capable of such brutal honesty are consultants with no vested interest or employees so fed up with the politics that they no longer fear losing their job.

One other political struggle that this instance has exposed is the continual struggle between the agile and waterfall camps. Each side has cherry picked their arguments in attempt to bolster their claims and for me to weigh in on one side or the other does little to further understanding. Of course, I come down on the agile side and believe that this project’s failures can be tracked fundamentally to the fact that the project was in no discernible way agile. This argument is not even vaguely interesting to me.

The most interesting point I have heard (and agree wholeheartedly with) is that there are a number of individuals, myself included, who feel, given the proper non-political circumstances could accomplish this work for a small fraction of the cost with a much smaller team. The reason for our confidence is that most of us already have. interestingly not a single soul who has accomplished something of this magnitude has done so using anything other than agile methodologies.

While the political right claim it is big government’s fault, this argument is somewhat disingenuous because the entities that failed are precisely the private sector companies that are supposedly our economic white knights. The real problem, when all the red herrings are swept away, is the procurement process itself that only allows for the largest, bureaucratic and bloated from the private sector to win contracts. Those companies who, by the very necessity of being small, are nimble will never get these contracts so failure is to actually be expected at the same rate (or worse) identified over the years by The Chaos Report.

A long time ago, government misinterpreted Winston Royce’s “waterfall paper” and all contracts are written to favor waterfall development which has been shown to be a poor methodology in delivering complex software. Again and again we run into the core issue that the nature of software development is fundamentally misunderstood as being merely complicated so that throwing money and bodies at a problem (and these bodies can reside anywhere, with any company like interchangeable widgets) will lead to success. Because software development is complex it works best under agile which emphasizes feedback and communication. Simply the fact that so many vendors were working this project shows the complete lack of knowledge and gross incompetence of people who are paid well to supposedly understand software development. In fact, if people in charge actually understood software development then they would have known the job would have been done much better with a small band of government workers and not the disaffected armies of “private” companies.

The reason I and my agile friends know we could have done the work for much less and with infinitely better quality is because we know what software development is and we would have used smaller teams, fewer teams and co-located teams. We would have increased feedback and communication. We would have completed the most critical scope first and phased in improvements. We would have used test driven development and continuous integration and testing to ensure performance all along the way. In other words, we would have operated in a completely egalitarian, non-political manner and achieved success.

What are your thoughts?

– Larry Apke

9 September, 20131 February, 2014

Two Time-Management Techniques to Aid Agility

Originally published on ScrumAlliance.org

With Agile as a philosophy and Scrum as a framework, ScrumMasters are sometimes on their own, left out in the cold when it comes to specific tactics. While I heartily recommend such practices as BDD (behavior-driven development), continuous delivery, and so on, there happen to be some simple time-management practices that I have found to be beneficial for almost all of my teams that have chosen to adopt them.

Team time facilitates collaboration

As every Agile practitioner knows, collaboration is essential to succeeding in Agile so that all parties can discuss the work that needs to be done. To increase collaboration, most of us facilitate grooming sessions with our teams to do things like pointing, writing acceptance criteria, and breaking down epics.

But there is one challenge many of us face: how to effectively schedule and ensure participation.

From my experience, one useful way is to establish “team time” every day right after the daily stand-up. Every day for my teams it takes the form of 45 minutes after the stand-up, which allows us appropriate time to sprint plan, sprint review, retrospect, backlog, story groom, and maybe tell a joke or two.

One of the major benefits is that every team member knows when they are going to meet in perpetuity, so they can more easily find productive time unburdened by a great number of ad hoc meetings. It also lends a very nice rhythm to their day! Since this (and my other technique, outlined below) is agreed to by the team and its efficacy discussed in retrospective, it’s a great example of how a team can maximize collaboration. I have had multiple teams use this technique over the past few years, and I honestly can’t recall one that did not feel it was beneficial.

“Office hours” allow team members to focus and find flow

Veteran ScrumMasters know that individual team members should not be scheduled for eight hours a day. In fact, most know that getting five good hours in a day would make for a productive day indeed! Besides, if you are using the team-time technique discussed above, then you’re starting an eight-hour day with only seven. But here’s the big question: How can I make sure I can get in those five productive hours a day?

In order to ensure that individuals get the needed focus needed to achieve a flow state, one that is necessary for good concentration and coding, most of my teams use “office hours.” These are time slots, decided upon by the team, when they are available for productive work only (e.g., tasks assigned during sprint planning). They will usually schedule a two-hour block in the morning and another three-hour afternoon block in Outlook (if you don’t use that, then you can use a real calendar! No, just kidding).

Not only does this eliminate disruptions but it is compatible with pair programming or other team interaction work when needed. As with team time, it is rare for a team to try this simple technique and then choose to go back to, as one team member put it, “scheduling chaos.”

Stronger together than apart

To summarize, using team time as discussed is an excellent way to facilitate engagement while also ensuring that the team’s rhythm is unbroken. As well, office hours provide a great, chaos-free environment for the team to buckle down, since the time blocks are clearly outlined. While each technique, in isolation, is beneficial for many users, I have found that team productivity soars when the two are fused together.

To see what this looks like in action, take a look at my example spreadsheet below. This will give you a starting point for your own implementation of these two techniques (and maybe jog some of your own inspiration!). I hope that this makes the Agile road easier to travel, because believe me, the journey is worth it.

For additional reading, here are two articles I recommend that touch on this subject:

If you have any questions, feel free to reach out with commenting below or with social media. Thanks for reading!

– Larry Apke

21 July, 20131 February, 2014

Message from the CEO: We Must Evolve

The Entrance by nattu, on Flickr Agile — The Entrance by nattu

On the flight home from a recent assignment I fell asleep and had a wonderful dream about a speech that a CEO gave to his employees. It went something like this…

In order to survive long term a species must evolve. So must companies. So must we.

Our company is heavily reliant on our software for survival. These days the new environment of software development is agile. This is an inevitable evolutionary step that we either learn to do or we will eventually perish. There are already a number of our competitors who are further evolved than us but fortunately there are a number who are not. We may be able to catch those ahead but we most certainly must evolve more than those behind. Survival is not only for the fastest gazelle, but we must at least be faster than the slowest.

To date our size has been a saving grace, along with the relative ineptitude of our competition. However, we can no longer rely on either size or dumb luck. We must boldly evolve. The savannah is littered with the carcasses of large and slow companies, ones who were too slow to keep up with the changing landscape. It wasn’t too long ago that Borders and Blockbuster were behemoths and now, they are no longer with us. Those who rely on size would be wise to note that Fortune 500 companies now have a lifespan of 15 years versus 75 years half a century ago, as stated in a Forbes article I read that used the Shift Index.

That is why as a company we must not relegate our evolutionary future to random mutation or genetic drift but instead embrace the values and principles of agile development, the implementation frameworks of scrum and Kanban and the software practices associated with XP, BDD and the like.

I have been told that there have been several attempts to take this company agile in the past but the proponents of these ideas have been thwarted by organizational antibodies such as fear, indifference and outright subversion. My sincerest apologies to these pioneering men and women for not understanding or giving support to your cause.

In order to ensure that our company transformation goes smoothly, I have appointed a CAO, or Chief Agile Officer, to work alongside me. He has my full support and let me make one more thing crystal clear: from this day forward anyone who subverts our essential evolutionary change will have plenty of time to commiserate with former Blockbuster employees.

We must evolve. We will evolve.

Then I woke up. And the speech has not been made and Blockbuster and Borders are still out of business. But I still have hope.

– Larry Apke