Understanding The Agile Manifesto: A Brief & Bold Guide to Agile – Podcast Now Available

Understanding The Agile Manifesto: A Brief & Bold Guide to Agile by [Apke, Larry]Those of you who may follow this blog may have noticed it has been some time since the last post. It was an eventful summer and it was good to spend some time to catch my breath. Now that the kids are heading back to school, it is time for me to renew my posting. In addition to posting the podcasts, please check back for new Agile posts.

I am pleased to announce that my first book, Understanding the Agile Manifesto: A Brief & Bold Guide to Agile is now available as a podcast. Over the next few days / weeks I will be releasing the book, chapter by chapter, on this website and through the iTunes store under my “Agile Doctor” podcast. Since the book was a series of blogs, the podcasts will also be made available under the original posts.

This project is very dear to my heart as the podcasts were recorded by my son, Vadim Kim, who assisted me over the summer as my intern. I think he did a fantastic job of recording my “little” Agile book and I am sure you will enjoy.

The most recent version of the book includes an Introduction which was never part of any individual post. I have included the podcast of the Introduction below.


Will Your Development Practices Shield You From Malpractice?


GavelThere 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.

Law BuildingIn 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.

Judge StatueMy 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.

Yahoo! – Some Thoughts on Regaining Former Glory

Yahoo Building Photo

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.

Yahoo Building PhotoCaveats 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”.

rocket photoThis 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.

collegeWhile 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.

moneyWhile 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.

stock marketI 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 stock marketeducation 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.

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.


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

einsteinAt 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.


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

martin luther king jr.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 3rd P) which came first. It is Agile Processes that help us to realize the philosophy of Agile.


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

lombardiSometimes 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.

Five Impactful Interview Questions for Prospective Scrum Masters


A friend of mine who happens to read my blogs contacted me the other day with a question – could you write a blog about “the five most important questions to ask a scrum master in an interview?” It seems that his company had interviewed a bunch of scrum masters and was not able to find a fit. In his words, “a lot of people think they want to be scrum masters but have only taken the one week training and don’t really get how to truly be successful in an enterprise workforce.” Having run into the same issue many times, I hope that I can provide some direction to help my friend and others faced with the same situation.

interviewIn the past, I have written about the problem of scrum certifications, specifically the Certified Scrum Master (CSM) certification. The issue is that people hiring scrum masters have mistakenly believed that a certification means more than it really does. Prior to interviewing a scrum master candidate it is essential to know that the CSM can be obtained by anyone who can sit still for two days and take an easy test. I am not sure how many people have failed the certification test but in over seven years of being intimately involved with Agile and Scrum I have never heard of a single one. If people cannot fail a test how good can the test be. Given this fact I am not even certain that a CSM should be part of the job description. A few months of “boots on the ground” scrum is better than the two-day training.

I have also written in the past about my favorite question to ask prospective scrum masters, namely,

“What book have you read recently that has changed the way you think about Agile and the way you go about your job as a scrum master (or coach) and why?”.

This question would certainly be on the list of five because it shows the desire of the candidates to better themselves outside of the normal workday. Agile and scrum are brief in words but very complex in practice. It is difficult to be a true “master” without looking past the Manifesto and two day training to what the experts are writing about. Bonus points to someone who replies with a book not written specifically about Agile or Scrum and having the ability to apply something from another discipline to their practice.

A big challenge in being a scrum master is understanding what makes for a good team. In my practice I have boiled it down to five aspects of a successful team. A good question would be to ask them

“what would you consider to be the five traits of a good Agile scrum team and why are these traits important?”

An experienced scrum master knows more than just theory. While a certification course can show us the happy path of scrum, the real world application is a lot messier. Like I don’t recall anyone ever failing the certification test, I don’t recall any seasoned scrum master not having to make adjustments or compromises when applying scrum. Of course these things are not optimal, but sometimes trade offs must be made in the short run in order to make things successful in the long run. The next question I would ask,

“Give me an example of when you have had to compromise or make a trade off in a Agile scrum implementation and why?”

A scrum master’s primary responsibility, in addition to the facilitation of scrum ceremonies, is to assist the team in removing impediments. A scrum master with experience should have multiple examples of how they were able to play the role of servant leader and remove impediments so my next question would be

“in your past please provide an example of a time when you successfully removed an impediment (or impediments) and what was the result?”

Most inexperienced scrum masters are able to speak to the scrum framework and the scrum ceremonies, but have not yet gained enough of an understanding of why Agile and scrum works. My last question (assuming I only have five) would be

“please explain why, when properly implemented, Agile and scrum are successful ways to create high quality software?”

I believe the questions above should aid anyone in assessing the true ability of a scrum master. I am also certain that there are many folks out there who might have similar or better questions that have been successful in the past. Please feel free to comment. In the spirit of open collaboration and helping others, like my friend, hire appropriately, what questions do you ask that have been effective

Technical Debt on the Balance Sheet

Mind the GAAP

My recent article on the high cost of “low cost” software seems to have struck a nerve with lots of views, comments, likes, shares, etc. A lot of software development professionals feel the weight daily of the tendency to chase the lowest price of software development and have added to the conversation I started last week. Below are some of the comments:

There is always a price for “free.”

In the end, it’s all about understanding the nature of software development in order to make wise decisions.

As the saying goes: “if you believe a senior developer is expensive, wait till you hire a Junior”.

Another aspect of poorly written code is the inefficient use of hardware which it runs on … leading to negative user experience .. Resulting in losing $$ in terms of user productivity .. Adding to the higher cost !!

My unscientific guess is corporate America is wasting billions each year on “low cost software “.

It’s funny how there never seems to be enough time to do it right, but always enough time to do it twice.

The technical debt gets worse when you add an army of developers to it.

The old saying “you get what you pay for” rings true.

Perhaps the most interesting comment came from Jason Ross who stated:

It’s often the case that people get “value” and “cost” confused. Technical debt is a very debt that must eventually get serviced. In the same manner that debt service kills cash flow and becomes a drag on the balance sheet, so does technical debt deprive an the ability to deliver new features and effectively update the code base as new technologies arrive that could be leveraged. In the long run, the maintenance and upkeep costs becomes the dominant factors in many things, and especially in software, they are often entirely neglected as factors.

Balance SheetWhen I read his comment and saw his mention of “a drag on the balance sheet” it reminded me of an article I had read a few years back from Israel Gat for his blog The Agile Executive titled Technical Debt on Your Balance Sheet

Israel’s assertion is now that there are ways to rather easily assess technical debt (like SonarQube with SQALE plugin), technical debt could (and should) be added to a company’s balance sheet. I applaud and support his efforts.

Unfortunately, it appears that any efforts to include technical debt on a company balance sheet might run into some accounting industry standards that would make this not currently possible. In his post, Clear Costs and Technical Debt, Trent opines

Accounting standards don’t allow provisions or liabilities to be shown for “not performing enough maintenance” or similar intangibles. There needs to be a present obligation before a liability is incurred and a present obligation is only usually formed through a contract.

In his scenario, financial wizards will chalk up the lower cost of software development as a savings.

The accountants will note a(n)… asset on the books, congratulate themselves for saving … capex and chalk up the increased opex of maintenance as the cost of doing business.

AccountingMy guess is this is precisely what happens now. If Trent is correct, then the issue facing companies developing software is that current accounting practices are inadequate and need to be modified. Technical Debt can be measured and tracked and is a very real liability.

The question remains: can there be a new GAAP around technical debt or can an existing GAAP be instructive? While I am not a CPA, I have done work in accounting in the past so I know “enough to be dangerous.” My line of thought is that technical debt probably resembles something that currently exists in GAAP. After doing some research I think that maybe GAAP around warranties may prove helpful. In reading about warranties in an article GAAP Accounting for Product Recalls. I noticed some similarities:

Product warranties present manufacturers with a bit of a conundrum. …The manufacturer is actually responsible for the product for the length of the warranty. In accrual accounting, the finality of the transaction does not occur until the period of responsibility ends. However, warranties … present a bit of an exception to the rule. (Emphasis mine)

Notice how, like technical debt and the Total Cost of Ownership (TOC) of software, the complete transaction is not final until the period of responsibility ends. I can see that the life cycle of software (and liability of technical debt – present or future) is like the life cycle of a product with a warranty attached. Even I can see how warranties could cause accounting headaches. However,

Rather than being on the hook for the cost of the product for the entire life of the product or throughout the product’s warranty period, manufacturers can instead follow the generally accepted accounting principles regarding products under warranty. … Under GAAP, product warranties and recalls can be reasonably accounted for with the initial sale of the product by estimating the potential warranty expense of a return or recall.

I can reasonable see how it might be possible to substitute an estimate of Technical Debt liability for the similar liability of estimated warranty expense. For example, with each release we classify software as a capital expense (CapEx). At this point we could also include on the balance sheet an estimation of technical debt as a long-term liability.

In the case of warranties, the actual accounting mechanism under GAAP is done by

 …making two separate entries, one a debit and the other a credit for the same amount. These are entered into the ledger as a warranty expense and a separate entry as an allowance for warranty costs.

What is to stop a company for entering two separate entries for technical debt – one a debit as technical debt expense and the other a credit under allowance for technical debt? I certainly see this as in the realm of possibility. This way GAAP can be followed AND technical debt can be raised to true financial visibility. It is this visibility that will allow companies to begin seeing the true total cost and guard against the high cost of “low cost” software development.