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.

 

The Five Attributes of a Good Scrum Team

One of the best experiences I can have as an Agile Coach is presenting Agile and Scrum to people with little or no experience. It grounds me and after many years of living Agile, keeps me from falling into the Curse of Knowledge cognitive bias. Team01smallBetween these presentations and my daily coaching practice, I am reminded yet again at the importance of forming a good scrum team. This, along with proper backlog compilation and maintenance, can make the difference between success and endless frustration. In my experience, proper scrum team formation is the area where companies who are unsuccessful in Agile transformations fail most often.

Over the years, with the help of my teams and the many knowledgeable colleagues that I have worked with, I have distilled everything I have learned and come up with five attributes of a good scrum team. I use it much like a mantra. Those attributes are: Small, Co-Located, Dedicated, Stable and Cross-Functional. That is not to say that a good scrum team will not have other elements or that you can’t witness improvement without all five, but like the sculptor who is only done when there is nothing left to take away, these five represent an ideal essence of a good team. None of these five things can be removed without real consequences to the success of the team.

Small

I write about size at length (and mention the five attributes) in a previous post, When it Comes to Software Development – Size Matters, so I encourage you to read it for some eye-opening account of a major study that confirms this fact. Suffice it to say that Software Development is about communication and collaboration. It is complex knowledge work. In a physical, manufacturing model, adding a person to the effort would result in the expected proportional increase in productivity. In software development, however, adding an additional person merely exponentially increases the number of communication channels whereby any expected increase in productivity is quickly overtaken by the number of communication channels created. There is a reason Agilists recommend small teams. Basically, you can save money because your cost per unit of productive (and quality) work decreases.

Co-Located

Co-Location seems to be an issue with all of the companies that I consult for. We know that the best software developers can be 10 times or more productive than the least. We know that face-to-face communication is multiple times better than any of the substitutes we employ when that mode is not available. We all laugh at the Youco-location01smallTube video “A Conference Call in Real Life”. We know that the unacknowledged creation of technical debt will cause us financial havoc for years to come. Not convinced, I encourage you to check out my blog on the High Cost of Low Cost Software Development. And yet we still continue to source our software development to low bidders around the globe. Here’s the really interesting thing. For many years I have asked a simple question – does it work? I get two answers. The majority shake their head, laugh, and provide a solid “No”. The optimists of the group say that “We have found a way to make it work.” I also see a great deal of blogs that are titled “How We Found a Way to Make Offshore Work”, but it takes little research skills to uncover the author as someone employed by a company that works offshore. Never is there an enthusiastic “Yes.” Most would bring the work back if they could, but it appears that there is a mysterious formation in many software development organizations that continues to think they are doing the right thing by piece-mealing work to various locations. I can only guess it is accounting, but I have yet to meet anyone whom I respect who actually understands software development who would recommend it.

Dedicated

I often rail against the project-centric focus of many software development organizations. For more information, I encourage you to check out my blog “Why Project Focused Mentality is Killing Software Development”dedication. The problem is that in projects we build teams around projects so that one, especially a key employee, will be spread over multiple concurrent projects. There are a number of very serious negative effects to doing this. First, context shifting means that every time a developer must change their concentrated area of focus they will lose 15 minutes minimum. If I am working on two different projects concurrently, there is not a huge loss, assuming that I might work on one in the morning and one after lunch, but many developers are bounced from thing to thing like so many pinballs with context shifting throughout the day. Hours each day are wasted and no project gets the attention it deserves. A better way is to create a small, co-located scrum team around a product backlog and bring the work of these multiple projects to the team via their backlog. The ability for individuals on the team to not fall prey to context shifting will allow them to focus on their work, even at times leading to a state called Flow in which developers (and athletes, artists, etc) are at their peak performance. For those interested, I refer you to the work of Mihaly Csikszentmihalyi.

Stable

 Project-centric thinking also results in teams that are short-lived. We put the team together for a particular period (sometimes relatively short) of time. When the project is done, the team is disbanded. This causes a number of issues. First, every team goes through a period of “storming, norming, and performing.” This is easy to see visually when you plot the velocitiScaleStability01es of multiple teams on a timeline. You can visually see the storming period as teams learn to work together as a team instead of a collection of individuals, through very low (if non-existent) velocity. In my experience, I have come to the conclusion that I expect nearly nothing from a brand new team for the first couple of iterations. It is not until they reach iterations 3, 4 or even 5 that they will reach what is their performing velocity. Therefore, every time I break up a team, I have a very high overhead associated with the team’s “storming and norming.” Another benefit of keeping the same people on teams for a longer period of time is by simply learning how to better communicate with each other over time. Since software development is about communication and collaboration, the more time we spend together, the more effective we become in communicating. I remember reading about the notion of “hyper-productive” teams from Scott Downey and Jeff Sutherland.  The interesting thing is that their “hyper-performance” did not manifest until after the team had been together for some time.

Cross Functional

 In some respects, cross functionality of people is a by-product of the fact that team size should be kept small. If there are 15 things I need to do to get my code into production, I obviously will not be able to do so if there crossfunctional01needs to be an expert for each piece. The creation of “silos” is great if your goal is to create a MDD (mortgage driven development) environment. It is bad for the flow of the product. Silos create queues. Queues, if you want to deliver something quicker, are bad. I highly recommend the book Principles of Product Development Flow by Don Reinersten for a deeper understanding of queuing theory and the damage that out-of-control queues can have. This book talks about the concept of generalizing specialists. In my experience, developers are more motivated by status and mastery of new technology and ideas than any other group of people I have worked with. Creating an environment where developers are expected to know more than a single specialized domain is not only good for moving the software through the system quicker, but it also leads to greater developer engagement. A team should be responsible for all aspects of the software product and the development cycle. This cannot be accomplished without having team members who are cross functional.

Final Thoughts

 An old African proverb states, “If you want to go fast, go alone. If you want to go far, go together.” In order to be successful in software development we need to understand teams and team dynamics. My many years of experience working with what I would estimate around a hundred development teams has led me to conclude that there are five basic attributes for an optimal development team – small, co-located, dedicated, stable and cross functional. I hope that these five attributes help you as you continue your quest for agility.

 

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

einstein

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

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.

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

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.

Practices

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

Project Manager/Scrum Master: A Cry for Agile Help

call for help

Over my time as an Agile Coach I cannot even begin to count the number of times I have been approached by recruiters for a position as a Project Manager/Scrum Master. My coaching colleagues and myself often joke about this particular job title saying, “we like the title Project Manager/Scrum Master because it helps us know which jobs and companies to avoid.” Why would we avoid such positions? For better or worse, by using the title Project Manager/Scrum Master we are able to quickly infer a great deal about the company and their experience with Agile – most of it not positive.

call for helpThe first thing we notice about a company using this title is that they usually have little or no understanding of Agile and Scrum. The duties of a Project Manager and Scrum Master are quite different. Not only do the two roles perform different functions, but they represent a fundamental different in the way they view the world. Project managers in Waterfall try to control projects. Scrum Masters work with Agile Scrum teams to facilitate. In Waterfall, Project Managers have responsibility. Scrum Masters, on the other hand, do not have direct responsibility as the responsibility for success shifts to the development team and Product Owner. Since the Product Owner decides the sequence of the work, a Product Owner is the closest thing to a Project Manager in Scrum. A simple Google search of “project manager versus scrum master” can provide more information on this for those who are curious.

This particular problem manifests when a company desires the potential benefits of Scrum without really understanding Scrum. Without a good understanding, people attempt to map their existing roles with those of Scrum. Let me make one thing perfectly clear. The role of Scrum Master is unique to Scrum and any attempt to map it to existing roles will only result in confusion, frustration and less than optimal outcomes. As coaches, if given the choice of coaching a complete novice as scrum master or “retrofitting” a project manager as a scrum master, we chose the former. It is not that project managers cannot become good scrum masters because many have, but in order to properly train one as a scrum master there is a great deal of work in “unlearning” much of what has been previously trained. With novices the time spent “unlearning” is non-existent.

life perserverThis is why I believe that companies recruiting for Project Managers/Scrum Masters are actually making a very public plea for help. If a company truly wants the benefits of Agile, it is essential that they actually take the time to truly understand that becoming Agile through the use of the Scrum framework is a serious commitment. People must gain a better understanding of software development and how knowledge workers differ, change their fundamental thinking around projects and products, pursue organizational change and realign people around properly configured scrum teams, work with recruiters who understand the difference between project managers and scrum masters and work as partners to recommend better solutions to underlying organizational needs.

For those seeking Project Managers/Scrum Masters, I hear your cries for help. As an Agile Practice Director I would love to help you to better understand your real Agile needs, to help you reorganize your work and people to take advantage of Scrum (other Agile frameworks, methodologies and development techniques), to optimize your organization so that you can deliver high quality software in a shorter time. I am available anytime to provide the help you need. If not me, please reach out to another Agile professional so we can rid the world of Project Manager/Scrum Master for good.

The Most Important (and Least Understood) Software Development Fact

Facts and Fallacies of Software Development Book

Facts and Fallacies of Software Development BookI love the holidays – the family, friends, food, drink, and, of course, the gift cards. I love to read and time off plus Amazon Gift Cards means the opportunity to indulge my passion. As the New Year begins, I find myself knee deep in two wonderful books about software development and the workplace. One of these, Facts and Fallacies of Software Engineering by Robert L. Glass, I found fascinating even though it was published over ten years ago. While some of the material is dated, I found that most of the facts and fallacies are as valid today as they would have been decades ago. This alone is disconcerting. You would have expected that, by now, most of these facts and fallacies would be well understood and to some extent corrected. If anything, my experience is that there is less understanding of the true nature of software development now than ever. It should be required reading for anyone in the business of managing software development because it would certainly save many a great deal of frustration by learning vicariously from one of luminaries of software development.

It was just about midway into the 55 facts (Fact 21 in fact), that I stumbled onto what could easily be construed as the most important (and least understood) software development fact in Glass’ book. The fact is titled “Complexity” and states:

For every 25 percent increase in problem complexity, there is a 100 percent increase in complexity of the software solution. That’s not a condition to try to change (even though reducing complexity is always a desirable thing t0 do); that’s just the way it is.

Glass, Robert L.; Facts and Fallacies of Software Engineering

Glass goes on to state, “If you remember nothing else from reading this book, remember this.” He closes his statement of fact with “And remember, also, that there are no silver bullets for overcoming this problem. Software solutions are complex because that’s the nature of this particular beast.“

What struck me most about this particular fact and Glass’ treatment of it is how closely it aligns with my experience and things I have written and spoken about in the past. Software development is knowledge work and is generally complex, but a majority of people in software development are unaware of this fact and continue to treat software development as if it were physical (mechanistic) work and either simplistic or merely complicated.

It is by understanding this fact that software development will improve. Why? The things that we employ to combat the Complex are much different than the things that work against the Complicated. The Agile movement was a response against using complicated tactics in the complex world. The Agile philosophy engendered a whole host of frameworks, methodologies and development techniques all of which address the need to address complexity. constructionWhy do large teams not work so well in software development? Why does scrum talk about small teams? Because small teams are better at attacking complexity. Large teams are adequate for attacking the complicated. The same holds true about co-location, dedication, stability, and cross-functionality. These are all things that work well for complexity.

If we want to create better software we would be well to head Glass’ fact. We need to stop treating software development like we are building a house or assembling a car. Software is much too complex to be built using the tired old mechanistic means. Remember that as complexity of the problem increases, the complexity of the solution increases at a much higher rate, along with the risks attendant on increased complexity. If you want to mitigate your risk, it is essential that you learn how to properly deal with complexity. You might want to learn how to become Agile.