Blog - 4/16 - Agile Doctor

8 April, 201612 April, 2016

“We Can’t Find Good People” Myth and the Rise of Trump and Sanders

Working for a staffing company and living the life of a consultant for many years, I believe it safe to say I have learned a great deal about how employment is done in our country, and particularly, how it is done in IT. I don’t think it takes a genius to see it is broken.

I have been doing some recent work with NOVA (with SIS support I conducted a one month deep-dive into Agile and Scrum with NOVA participants) and was introduced to ProMatch by Jennifer Cheyer of NOVA. I have also been working with Fred Fowler and his Scrum training class that recently completed a public/private partnership with Silicon Valley Polytechnic Institute (SVPI), Coding Dojo (a coding “bootcamp”), NOVA/ProMatch,, the Taylor Family Foundation (a non-profit) and SIS, Inc. It is an amazing story of what can be accomplished when people work to align motivations. I encourage you to check out their story.

Since some of the work was done with ProMatch, I was curious to see what they did and how I could help them. I went to one of the ProMatch meetings yesterday in Sunnyvale, California and it was then I was reminded of just how sorely broken our employment system is. According to its website “ProMatch is a collaboration between EDD (Employment Development Department of the State of California) and the NOVA Job Center” and “is a powerful networking program for unemployed Silicon Valley professionals … over 200 active members and a waiting time of approximately one month to join.”

I hope that you take a moment to let that sink in. Companies complaining that they cannot find good people, so much so that they have to go outside to United States through programs like H1B (or worse yet, ship work completely offshore), while there are over 200 people actively looking for work. There are so many good people looking for work that there is a waiting list to enroll in a program that helps them to find work. Hate to veer to political, but if anyone is still mystified by the Trump and Sanders “phenomenon” they should look no further than a ProMatch meeting in Silicon Valley!

The number is more staggering when you actually show up in person. The meeting is held in the Sunnyvale Council Chambers and the place is overflowing with people. The demographics are all over the board and seem to be a homogeneous representation of society at large with one exception – the age of the participants skews much older. Each new member spends a short 15 seconds to introduce themselves and what they are looking for. Not only do the individuals have diversity of race and gender, they also have a great variety of skills, high tech included. Words cannot express the amount of talent and experience in that one room.

And yet there is one thing that I found conspicuously absent – employers. Though there may have been more that I was unaware of, it appeared that the only two people representing real jobs were a former SIS, Inc.. colleague and myself. I spoke briefly with Robert Withers, a full time ProMatch employee, and he was as perplexed as I was that more employers and staffing agencies were not there. He wonders, as I do, why they do not see what he and I do when we look out at the over one hundred well-qualified applicants in the council chambers that morning.

This is why I know the “I can’t find good talent” argument is a myth. Right there in downtown Sunnyvale was a treasure trove of immense talent just waiting to be employed. The problem is that we, as a society, no longer seem to know how to invest in our people or our infrastructure. Companies no longer train their employees, but use them up and spit them out so that when they come to ProMatch their skills might be slightly outdated. They look for the “perfect” fit and don’t invest in making a close fit better. We look for cheaper through younger and overseas workers, oblivious to the fact that knowledge management is won by the best, brightest and most experienced.

The American public screams for change which is why we have seen the rise of establishment “outsiders” like Trump and Sanders. The ProMatch meeting I witnessed yesterday was the personification of the change that they American public seeks. The American public desires a world where employees are valued for their experience, where they are invested in instead of harvested. America dreams of a day when instead of a waiting list to be part of ProMatch, a meeting has been cancelled due to lack of attendees. The public/private partnership work that I am part of and alluded to at the beginning of this post is merely one small dent. What is needed is the participation of more people, more companies. We need to make this issue viral. Share it, comment on it, like it so that maybe next time I go to ProMatch (and I will keep coming back) the room will be literally crowded with representatives from all these companies crying and complaining “we can’t find any good people.”

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Android | RSS

14 March, 201628 June, 2016

Will Your Development Practices Shield You From Malpractice?

There are a number of reasons why companies who develop software should use Agile. Agile is superior to phase gate approaches like Waterfall in quicker time to market, the practices associated with Agile produce a much higher quality product with less technical debt, maintenance of software (which is the bulk of the SDLC in terms of time and money) is much easier, the engagement of employees is much higher and results in less employee turnover, frequent feedback results in better risk mitigation (to name a few benefits). As I look to the future of software I believe we can begin to add one more thing –protection from software malpractice litigation.

The thought came to mind recently as I was listening to an NPR segment on autonomous automobiles. According to the story, a large segment of the American public is hesitant to trust their safety to autonomous vehicles, even though there are some estimates that cite a potential 80% reduction in traffic fatalities. As human beings we are comfortable with the notion of human error, but find it difficult to find comfort in computer, especially software, errors. We find it especially difficult to accept those that would result in loss of life, even if the average loss of life were greatly reduced. I think that the potential for litigation (and concurrent drag on profits) of such defects is quite high. Not only do I expect software defect litigation to be increased because of autonomous vehicles, the Internet of Things (IOT) and the corresponding explosion in software in all areas of our lives will also create scenarios for increased litigation.

In some research for this article, I unearthed a paper by Cem Kaner that speaks directly to this issue. While I do not possess the legal mind that he does, I believe I can understand the two potential issues of Negligence and Malpractice he outlines. In regard to negligence, he states, “How do we decide whether a product was developed or tested negligently?…A critical issue to keep in mind is that the plaintiff must prove that the failure to use some ‘best practice’ actually caused the defect in the system.” As software becomes ubiquitous, the methods used to create software will begin to be questioned more often. I believe there to be overwhelming evidence that software developed using Waterfall methods tend to result in greater technical debt, and therefore, the possibility for being on the losing end of a lawsuit is greater. In other words, improper development methods that have been (and continue to be used in many places) not only result in greater technical debt, but also will expose companies to more potential lawsuits. Should I ever be called as an expert witness it would cause me no compunction to reveal poor development processes and practices. We have all heard of lawsuits that have been filed, litigated and judgments made for less.

With regards to malpractice, Kaner states, “Before calling for the professionalization of software quality advocates, please consider the problem that we need a solid basis for distinguishing unacceptable from acceptable practices.” Of course, this paper was written back in 1997 so the amount of evidence available for determining unacceptable from acceptable is growing and the evidence is strong that Waterfall development is no longer the best or accepted practice.

My argument is this – most software development is complex. It is a well-established truth that complexity is best attacked through frequent feedback, the kind supplied by the agile methodologies and frameworks, as well as the commonly applied practices associated with XP like pair programming, BDD/TDD, code reviews, etc. Software that has been written using methodologies other than Agile generally result in greater number of defects and higher degree of technical debt. As these things are generally accepted by software development professionals as better ways to produce quality software, companies that do not use Agile will become exposed. Furthermore, studies indicate hours worked beyond about 30-40 per week can result in increased numbers of defects. Companies employing this already counter-productive measure have yet another reason for adhering to the agile principle of sustainable development in avoiding potential litigation.

Perhaps malpractice litigation will not affect the realm of software development as I anticipate, but that does not mean it is not appropriate. In some cases, people who with authority to make decisions regarding software development show a willful ignorance of the nature of software development. I believe their behavior is not only detrimental to the production of quality software and the satisfaction of customers and employees alike, but certainly borders on the realm of malpractice. Maybe the hint of malpractice will incentivize people making software development decisions to treat development and developers in a manner more congruent with the true nature of software development.

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Android | RSS

3 March, 201630 June, 2016

Cooks, Chefs and Agile Scaling Models

A few years back my doctor gave me some somber news. He told me my cholesterol was too high and I must get it lower. It was then that I decided I would make changes to my less than stellar diet. At the time, we had a large family in the house – seven including my father and mother-in-law. My mother-in-law had become the default cook for the family and, while she made some very tasty dishes, it was not exactly healthy fare. I knew that if I were to reach my goal of a better diet I would have to become the new cook for the family.

Originally I thought that my mother-in-law would be upset if I banished her from the kitchen, but if she was, she did a good job of hiding it. That aside, there was only one more small problem – I had not the first clue about how to cook, let alone cook healthy. Obviously I needed help and what does someone do to find help these days? That’s right. I googled it. I found my salvation on a website that not only had thousands of recipes, but each had a rating and comments. I could print out a list of ingredients, create a shopping list, scale recipes to my large family. Most important, I could choose recipes by food type (in my case – healthy foods, low in sodium and cholesterol). Without the internet my plans to eat healthy would have died in infancy.

While I went into this quest as one who was not even a functional cook, I was able to read and follow directions well enough to create some very tasty dishes that the family enjoyed. The plan paid off. My cholesterol and blood pressure went down, as well as other family members including my mother and father-in-law. Over time I even became a functional cook. However, I never became a chef (and to this day I am still not).

The difference between a cook and a chef can be summed up in conversations I would have from time to time with my wife. She would ask, “Can you make this dish without this or that? Or maybe substitute this with this.” My response would always be the same. “Sorry honey. I wish I could help you, but I am not sure what this ingredient does and not sure what would happen if I don’t follow the directions to the letter.” I was a cook. What she was looking for was a chef; someone who had a deep culinary knowledge that would allow them to not only modify recipes, but someone with the ability to create new dishes from scratch or show creativity with existing ingredients. I could not do this. I got very good at the motions and following a recipe, but I never cultured a deeper understanding of the why behind the individuals ingredients and actions. I could not “see the big picture.”

I am often reminded of the difference between a cook and a chef in my agile practice. I have used this story numerous times with developers to explain agile development practices. Like me, it seems that some developers will always be cooks. While there are some who don’t know the difference, I have even run into some that prefer to be cooks instead of chefs. Not that there is anything wrong with choosing to be a cook, but it helps when one is aware of the choice and makes a conscious decision to be one.

I was reminded of this again recently when I went to a talk on scaling agile. The presentation was supposed to last about an hour, but ran long because of the numerous questions and comments from the crowd. It wasn’t until the following day when I was explaining the presentation to a group I was coaching that I realized why the presentation was peculiarly long. The crowd at the presentation were novices with respect to this scaling model and the questions they asked were ones that we would expect cooks to ask. They wanted to know a prescriptive recipe for scaling and wondered how it could be applied to their unique circumstances. Without having the deeper knowledge of a chef, the scaling model recipe didn’t make a great deal of sense to the crowd.

Of course, this phenomenon has been observed and named the Dreyfus Model of Skills Acquisition. In this model, “cooks” could best be mapped to the “Novice”, “Advanced Beginner” and maybe even the “Competent” categories while “chefs” are referred to by the name of “Proficient” and “Expert”. The Dreyfus Model helps us understand one of the biggest problems facing Agile scaling models today. The scaling models I have some experience with present the world with software development recipes. Unfortunately, the majority of individuals being presented these recipes are cooks (“novices”) and not chefs (“experts”). While one can function adequately as a cook by merely following directions, software development is much too complex. People trying to do Agile scaling are too new to scaling concepts to make successful adaptations should their “ingredients” not match exactly with the Agile scaling “recipe”.

There are a number of Agile scaling models including SAFe, LESS, Nexus, DAD. Since there appears to be quite a bit of money in creating scaling recipes, training people on the recipes and certifying that people have been given and understand the recipes, I expect to see many more in the coming years. Each scaling model claims to have many companies successful in using their model. I am dubious because I have seen overlap among the companies claimed to be successes with the different scaling models (“the usual cast of characters” a person said to me once). I would guess the companies where success is claimed are merely the ones where people paid for the training and certification. What actually happens vis-à-vis scaling models is probably far from what the proponents claim. I expect over time many of these scaling models will be spectacularly unsuccessful. It may be the luminaries of agile have created the perfect scaling “recipe”, but there are too many cooks and not enough chefs for lasting success.

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Android | RSS

23 February, 201628 March, 2016

Yahoo! – Some Thoughts on Regaining Former Glory

I try my best not to call out particular companies in my writing though from time to time I have done so. I do so when only absolutely necessary to make a point that I would like to make, basically because it’s not great business to have people (or entire companies) upset with you. Also, though I work for enlightened people who have given me freedom to express my personal ideas through presentations, blogs podcasts, etc., I don’t want to strain that relationship. As always, the thoughts expressed here are my own and not necessarily endorsed by my employer.

Caveats aside, I wanted to address something that has been weighing heavy on my mind. I have found that expressing myself through writing has a tendency to clear my mind so you can view this blog as a form of self-therapy. My topic this week is the fall of a company I (still) have a great deal of affection for, one that I continue to support. To me this company “was” the internet and their rise and past prominence represented what was best of Silicon Valley. More troubling is their subsequent lack of direction and downfall represents what can be thought of as the worst of Silicon Valley. I am not the first (and will not be the last) to weigh in on the tragedy that goes by the name of Yahoo!

I have often stated that when a company has hit “rock bottom” (as in my previous blog) it is time to acknowledge some core truths about their business and, only then, can the healing process begin. There is much to heal at Yahoo! I speak not simply about financial concerns. Although these are paramount, in many respects financial difficulties are merely the symptoms of much larger problems, for instance, confidence in Yahoo! as a brand. While many, myself included, continue to use Yahoo!, it has, for some time, lacked the cache’ that brands like Google, Facebook, Apple (and even Microsoft) have. Not only does it not seem to have a particular direction, if it had some direction, that direction would not be seen as “cool”.

This begs the question as to what direction should Yahoo! take. This is where I believe Yahoo! has squandered some opportunity because I believe that the only mission worthy of enticing talent back to a failing enterprise must be a bold one, a moon shot if you will. To date, Yahoo! appears to have taken no real bold moves (with the exception of over spending on Katie Couric). Their competition, the ones “eating their lunch” have – Alphabet (formerly Google) has multiple moon shots, including self driving cars, Elon Musk is in Fremont forging a new future of electric cars and rockets, Apple is rumored to be developing their own car, etc. Technology IS talent and talent will go where it is inspired. I thought of this the other day when I attended an event at AOL. Tell someone that you attended an event at AOL and the first thing out of their mouth is “you mean they are still in business?” Yahoo! will be the same in very short order unless they can change perception. To me that will begin when they find their own “moon shot.” It will not happen anymore with only incremental change.

I remember reading somewhere that the problem with Silicon Valley is there is a tendency to solve the problems of no longer living with your mother. There are a ton of startups not taking on the larger battles society is facing (and many like global warming that society is currently losing). I think there are two lessons for Yahoo in this; one, they must begin acting more like a startup, and two, they must be a startup that is actually solving problems whose solutions will be meaningful and impactful to society at large.

While there are a number of societal problems Yahoo could choose to tackle, like global warming or clean and safe drinking water, let me suggest one that I feel would be a good fit – education. In fact, I have a great name for it, Yahoo University (or as my wife affectionately calls it – Yahoo U). Why education? Yahoo is now primarily a content provider so a great deal of infrastructure is in place to begin solving the problems of the current educational system. I think that smart acquisition or partnerships with a number of companies operating in this space (think Khan Academy and the various coding bootcamps) could give Yahoo University an advantage. It would certainly have name recognition (which is one of its few convertible assets outside of Alibaba).

Attempts to solve the problems of education for the way we work today have been made by many parties, but no satisfactory solutions have been made. At issue is creating education that is actually useful to the general populace in positioning them for gainful employment in our quickly shifting, knowledge-based economy. Traditional classroom education has suffered because it still dictates “what” to learn instead of “how” to learn. For example, what good is it to teach someone Objective C when it is no longer being used or desired in the real world? What happens when the world has moved on to Swift? The real issue is to teach someone how to teach himself or herself to learn Objective C so that when they need to learn Swift they have the skills to teach it to themself. In other words, we must move away from content for content’s sake and teach the mental agility necessary to survive. Technology has existed for sometime to solve this particular issue yet we have done little to use technology for this goal. Instead we have used the technology to shovel content. It’s as if we teach people to drive a Ford and when given a Chevy they cannot drive it.

While I could rant more on this topic, I feel it is important to also address how one would go about making real money from such an endeavor and how Yahoo can reinvigorate its sagging stock prices. It would be most obvious that Yahoo University could borrow the model from existing online educators such as the University of Phoenix, but this would be a mistake. Anyone paying attention to this space would know that the fortunes of private sector online educators is bleak. I, myself, worked for the Apollo Group, the parent of University of Phoenix and personally know some of the problems that have crippled them over time – things like over-reliance on government-backed student loans, high tuition costs, students with high debt and poor prospects of repaying debt, etc. Online education was a brief success and made some wildly prosperous – just not necessarily the students.

I propose a more radical solution for Yahoo University – free education. But how can you make money providing education for free? You can, if the education you provide actually has a value to the world at large. I propose that students entering courses that have a good prospect of being placed in real jobs be given a free education with the stipulation that Yahoo University be reimbursed when they student is placed in a job related to their education. This aligns the motivation of the educator in doing what is necessary to provide marketable skills and the motivation to actually ensure that the student get a job! Being in the staffing industry I know that a properly educated and placed individual can provide enough compensation on the back end to justify the expense on the front end. In talking with my friends in software development, this is exactly what is happening in countries outside the United States with H1-B candidates taking the jobs that could be filled with Yahoo University graduates.

As to the issue of stock value, I think that taking this course of action will make it much easier to increase shareholder value. If I were the CEO of a company on the course described above, I would take my argument not only to Wall Street but to Main Street. The incredible societal value of providing free and meaningful education and job placement would inspire investor outside of Wall Street. While I am the last to wrap myself in the flag, there is certainly not only something not only highly practical to this plan, but something downright patriotic in solving American problems with American citizens. I don’t find it hard to imagine that people would want to purchase shares of a company that had such a unique and worthy vision. Of course, it would not hurt that as Main Street bought shares that Wall Street would join.

I do not know Marissa Mayer and it may be that where Yahoo! is now has nothing to do with her leadership. She may be the most competent individual on planet earth (we all know she was successful at Google), but what matters is perception, and right or wrong, the perceptions of Marissa Mayer are predominantly negative, both with the public at large and within the employees (and ex-employees) of Yahoo! I cannot see how Yahoo! could make the necessary transition without removing the current CEO.

I guess you can file this blog under the title of a modest proposal. I wish Yahoo all the best and I am sure that there are many others who agree and would like to see this once proud company bounce back. If you, dear reader, agree, I would suggest that you take the time to share this post with others, like this post, or feel free to leave your comments. Perhaps the folks at Yahoo will take notice. Perhaps if they did they might find something valuable as they face the tough times ahead. At the very least one can hope.

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Android | RSS

26 January, 20161 February, 2016

The 3Ps of Agile Software Development

I am often faced with explaining the various aspects of Agile to people new to Agile and I have come up with a very simple way to remember (and explain) Agile. I present to you now the “3Ps of Agile Software Development” with the hope you find this useful to your own understanding and an aid in your ability to explain Agile to others.

Philosophy

“The world as we have created it is a process of our thinking. It cannot be changed without changing our thinking.” – Albert Einstein

At the core of Agile is the Manifesto. A few years back, I even took the time to create business cards that contained the four values and twelve principles. When I heard people say that this is or is not Agile, I could hand them a card and say, “This is Agile.” This is where I start in explaining (and training) Agile because without the philosophical underpinnings one is most certainly lost. I couldn’t give an exact number, but I do know that a high percentage of companies trying to move to Agile are unable to fully embrace and promote the philosophy behind Agile. I wrote my first book, Understanding The Agile Manifesto: A Brief & Bold Guide to Agile, because I have witnessed firsthand the struggle companies are having with adopting the Agile Manifesto. I have seen companies rewrite the Manifesto to omit or change things that they find too difficult to embody and watched good people punished for having the temerity to post the Manifesto at their workplace. The philosophy is the base upon which the other two Ps rest.

Process

“This strange dichotomy, this agonising gulf between the ought and the is, represents the tragic theme of man’s earthly pilgrimage.” – Martin Luther King

It is not enough to have the basic philosophical understanding of Agile, we must find ways to embody the principles. There have been a number of ways to embody this philosophy over the years. Take for example, Scrum. Technically it is a framework, but it contains ceremonies (actions) that allow us to realize the Agile philosophy. Why do we do retrospectives? Because the last of the Agile principles state, “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” While Scrum has claimed a high level of mindshare, there are numerous other processes and frameworks that also help organizations embody the philosophy of Agile (Kanban, DSDM, Crystal, etc.). In fact, Agile’s history is one of empiricism with people “uncovering better ways of developing software by doing it.” This means it was actually Process (and the 3^rd P) which came first. It is Agile Processes that help us to realize the philosophy of Agile.

Practices

“Practice does not make perfect. Only perfect practice makes perfect.” – Vince Lombardi

Sometimes when we classify things, people can certainly disagree with our classifications, but when I explain the term “Practices” I am referring specifically to software development practices that are done within the processes and frameworks. It is into this category that I would put things like Extreme Programming (XP) practices as well as something like BDD. What separates these things (which could be argued to be processes) is there more technical nature and the needed expertise of software development professionals (developers and QA) to implement. Processes are things that embody the Agile philosophy which any intelligent individual could understand and facilitate. For example, though it might be optimal for a scrum master to have a development background, one could be successful as a scrum master without it. On the other hand, one could not be successful in performing code review or test driven design (TDD) without knowledge of coding. Why do agilests do BDD? Because through BDD we can realize (among others) the principle that states, “Business people and developers must work together daily throughout the project”. It is Agile software development practices which also help us to realize the underlying Agile philosophy.

While any system of classification subject to interpretation, I have found that speaking to the 3Ps of Agile Software Development has provided a simple and understandable way to introduce people to Agile. If you get a chance to present this, please let me know if it helps you as well.

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Android | RSS

18 January, 201618 January, 2016

You Have a Friend – Another Reason Scrum Works?

Scrum teams, when properly assembled and maintained, have been shown to increase developer productivity and satisfaction. Scrum teams that work are small, co-located, dedicated, stable and cross-functional. These elements are essential in working in the complex world of software development. Recently, I stumbled across another reason that may explain the gains found on proper scrum teams – friendships.

In his book, The Best Place to Work: The Art and Science of Creating an Extraordinary Workplace, Ron Friedman explains that there is a strong correlation between employee engagement and whether an employee has a best friend at work. It is important to note that employee engagement and employee happiness is directly tied to employee productivity. Additionally, engaged employees also exhibit increased focus, passion, loyalty, spend less time off the job being sick, suffer fewer job-related injuries and have less turnover. In other words, there is an excellent business case to be made for keeping employees engaged through facilitating friendships.

Of course, this begs the question of how companies can facilitate friendships. According to Friedman, there are three basic things that are necessary to foster friendships; physical proximity, familiarity and similarity. It is interesting that these are things that a properly assembled and maintained scrum team will nurture. Physical proximity is analogous to co-location. We find it difficult to bond with people who we are not physically close to. Familiarity can be gained with small teams that are kept together over time. Similarity is found in keeping the people dedicated to the effort over time. In fact, studies have shown that it takes about a year of occasionally working together to transition from acquaintance to friend, so I would recommend that it takes about four to six months of scrum team experience to achieve this friendship level.

There are two additional levels of friendship that have been studied, namely, the transition from friend to close friend and from close friend to best friend. According to Friedman, the cement that bonds friends even closer together is “a foundation of shared risk” and the ability to “reveal our vulnerabilities.”

And how is this related to Scrum? I think there are two things that could allow Scrum to facilitate these deeper bonds of friendship. The first is the retrospective. When this ceremony is done correctly, it challenges people to honestly confront issues that the team is having and the sessions can be intense, but the experience of frankly sharing can certainly increase the bonds between team members. The second thing I think could play an important role is the last aspect of a good scrum team, cross-functionality. While this may seem a stretch, my own experience with teams is that when individuals are encouraged to work in areas outside their primary focus, they increase their feeling of vulnerability. It also forges greater bonds because a person has more opportunities to support their friends and contribute to the team.

Scrum is a difficult challenge at many companies because they continue to have trouble creating scrum teams with characteristics shown to work optimally. These five characteristics are size (small), co-location, dedication, stability and cross-functionality. These are the things that are essential in combating complexity, but it appears they are also necessary to building lasting and close friendships. Perhaps one of the reasons that properly assembled scrum teams are so successful is that when you keep them together, close friendships are established and this has been shown to increase productivity and reduce turnover. I think that this needs to be taken into account when we assess our all too prevalent reliance on temporary workers and temporary project teams. Perhaps temporary teams do not function as well because we have not given people the time (and space) necessary to form friendships.

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Android | RSS