When Doing Your Best Is The Worst Option

There is a lot to be said about individual talent and probably even more about individual excellence. It is something we all strive for, we all work towards excellence in everything we do. Making the best out of our talents and doing our best on a day to day basis. Very rarely do we stop and think, is doing our best the best thing to do? What about personal, individual excellence? Where does that fall in the realm of team-based agile work cultures? For me, all of agile boils down to the following 4 points - Work in Small Batches Limit Work in Progress Get Feedback Do Not Sabotage Your Ability to Do the First Three Points The unfortunate part is that everything we are taught, everything that we have learned to do in the name of individual excellence runs counter to all of these. When it comes to working in an agile manner, doing your best(in the traditional sense of individual excellence) is the worst thing you can do. Work in Small Batches My education was that of an engineer. We were taught to solve problems, build things. The bigger the problem you solve, the better you are. The bigger the thing you can build, the more creative of an engineer you are. I believe that to be true of everyone’s education. We were all taught to, encouraged to do big things, to try to outshine others who are doing just routine, average things. IT continued when we joined the workforce. The ones rewarded were the ones that solved the nasty problems, that built the big things, that spent nights and weekends building the biggest, baddest, most magnificent projects. Individual excellence has almost always been revered and rewarded more than team excellence and the humility to make smaller things. It is little surprise that when we, as coaches and leaders encourage folks to work in small batches it feels entirely counter-intuitive for people who have are routinely rewarded for big batch delivery. Limit Work in Progress We have always valued people who can get a lot of things done. We have also valued people who seem to be very busy. In fact, we very often try to show that we can get a lot of things done and are very busy in order to seem valuable and/or important. Another hallmark of individual excellence is the people who can have multiple balls in the air, without letting any of them drop (until they do). The agile advice of limiting work in progress or in other words working on as few things as possible at any given time, this is pretty counter-intuitive to most folks striving to prove that they are doing their best. It is hard to convince folks who have regularly praised for handling multiple things at the same time and who take pride in being needed by multiple people and hence being busy to limit the number of things they are working on explicitly. There is another reason why the “Limit Work in Progress” advice has a hard time sticking. We are all people who love to please, especially, we like to please those that do our performance reviews. Hence, when someone, especially someone in management asks us to do something, very few of us say “No” or “Not Yet”. Most of us take that task to please and knowing that we, at our best, can handle this. Thus, inflating our personal work in progress. Get Feedback Delivering big items is not the only thing we are rewarded for, we are also rewarded for being right on the first try. The race to be the first one with the right answer has been inculcated in us from the first time a teacher asked a question in the kindergarten classroom. Being the first one with the right answer has gotten many a middle manager promoted. Being the first one to propose the winning solution is synonymous with individual excellence. Conversely, proposing the wrong solution or accepting that we do not know the ideal solution, is traditionally equated with mediocrity. Getting regular feedback from the customer means admitting two things — 1) You are unsure if the answer you came up with is the right one and 2) You will find out very soon if the solution you proposed is just wrong, forcing you to admit that in front of your bosses. It is again, no wonder, that the agile advice of getting regular customer feedback to know when you are going wrong does not sit well with most folks who are simply put — trying to do their best. Sabotage The combination of the above three issues plays havoc with the last point in what is my definition of agile. This point is probably best demonstrated by an example — Consider a system for a hospital used for scheduling appointments, shifts, holding patient information, etc. In other words, this system runs the day to day operations of the hospital. Of late the nurses have been complaining that when a patient is admitted to the hospital or schedules an appointment, it is very hard to get the information on all of the patient’s previous visits into the hands of the doctors. From the patient’s details screen, you have to individually click on every previous visit and print the details out one by one to put it in the doctor clipboard. It would be great if there were a more streamlined way of getting all the visit logs for the patient that was less time-consuming. The team responsible for the system has been asked to solve this problem. The team includes BAs, UX Designers, Developers and QAs. Let us take two cases - Case 1 — Everyone Doing Their Individual Best The BAs and UX Designers take on the task of making this feature the best it could be. They quickly figure out that what this needs is a modern reporting system, one that is responsive and easy to configure. We show some paper prototypes to a couple of users and figure out that they would love to be able to set date ranges, highlight specific visits and even change the font on medications that might interfere with current treatment. This is exciting. When we deliver this system, it will provide tremendous value. After we are satisfied with the research we have done, the information is presented to the developers and QAs for a combined design session. More design possibilities are sketched out and voted on. The team starts to coalesce around one solution. We will bring in a reporting engine that can be layered on top of our existing database and build some responsive components for our UI that can hook into the reporting system. Our senior devs know of at least three reporting systems that we can use. Let us spin up some “spikes” for us to research the implementation of these reporting systems. Also, since we have the company-wide DevOps initiative, we should research the appropriate cloud infrastructure for this feature. One of the QA folks in the session brings up the point that the new reporting system will need to comply with all the HIPPA and privacy laws that our base system meets. We can probably keep diving into the details of the 3–6-month (or longer) project and all the snags that it can hit. We have not even talked about other “high priority” projects that would come up throughout the development of this feature. Hopefully, you can see how the request of “I need to be able to print all visits for the patient” can turn into the implementation of a highly configurable reporting system. Case 2 — The Smallest Batch To Get Feedback We take the same problem to the team that approaches the problem slightly differently. There isn’t a lot of up-front design. One of the devs suggests we could build a page that has the details of all the past visits. One of the analysts reminds that there needs to be a print button since these need to be printed out to hand to doctors. The new page is built, with a print button up top. Tested and pushed to production in a matter of days. Based on feedback from users, date range or word highlighting can be added. The second solution, from my perspective, is much more agile and a better approach to solving the customer’s problem. It addresses the problem at hand and allows us to iterate towards the best feature set. It also allows us to pick up other problems to solve faster. It is not the solution that evolves when everyone is asked to do their individual best. Optimizing for individual excellence in a team setting can, and most often will, result in inefficient and overdesigned bulky feature sets. This essentially is the most significant advantage and flaw of agile at the same time. The advantage being the ability to identify the best solution for the customer. The flaw is that we are explicitly telling people that we don’t want you to do what you have traditionally considered your ‘best’. Instead, we are helping you reach the ‘best’ outcome for our customers.