Frustration was my path to adopting Agile.
Many years ago, I had a coworker that was, shall we say, extremely challenging. Let’s call him Mr. X for the purpose of this post. He was a very bright developer, with a large ego, poor communication skills, and no discipline to what was a priority. I was the technical project manager he was assigned to work with. He was far and away the most difficult co-worker I have ever encountered.

Our boss recognized that I was beyond frustrated and he instructed Mr. X to have a sit down, face-to-face meeting with me where he was to lead a discussion of how he would communicate better with me. He was tasked by our boss to come up with ways to achieve this goal.
It was during this meeting I realized Mr. X had a learning disability.
As Mr. X started describing, in a rather disjointed way, how his current means of working and communicating with me were “the best ever,” I began to see all the signs of a learning disability I had been trained to recognize in my first career. I couldn’t believe it had taken me so long. I had been a secondary teacher for over a decade and had been trained and worked first hand with many students who were identified with ADD and ADHD. Here I was, looking at the poster child for Attention Deficit Disorder.
As Mr. X outlined what he was already doing, I was no longer hearing him. My mind began putting together all the different attributes and examples that had led me to this ADD diagnosis. I had no intention of sharing this with Mr. X, as he likely already knew it, and would see it as me labeling him. That wasn’t the case. I’ve known many bright and very successful people who have ADD (or ADHD). Learning disabilities do not mean someone is neither smart nor unlikely to be successful. I did share my thinking with our boss, who agreed with me right away. I told him it would change how we approached our work with Mr. X.
Some of the symptoms I had witnessed included:
- A hyper focus on things that were of small importance. Mr X would spend huge blocks of time refactoring code that was already working . (I had joked that he was hoping to make Haikus with his code.)
- Extreme difficulty completing larger goals. The “shiny object” nature of completing smaller tasks were his justification for not getting to the larger, higher priority tasks. Mr X would say “I can focus on that big task once I get all these small things accomplished.” However, there was always another set of smaller tasks each day.
- Unable to focus on the important details of larger tasks. Mr. X would fail to follow a specification, providing instead what he thought was needed based on reading only the title of the request, not the use cases or requirements. I now saw he really was not capable of reading a detailed specification completely.
- Unable to manage his personal finances. Mr. X had several phone calls in our open-office environment to argue with various credit card companies about why specific auto-payments should not have been applied, or various other over-charges were not his fault. It happened often, and was painful to have to listen to. It is also one of the signs of adults with ADHD/ADD.
- Constantly looking for new ways to get organized, but never sticking to an established (and often working) system. Mr. X spent a great deal of work time creating custom email rules that would route and auto-respond to emails. These emails would in turn get lost or be filed in such a way that he never saw the priority of a specific thread.
For about a year prior, I had been using a whiteboard to list our current projects so that the marketing and sales teams we worked with could easily see what was our focus. I had a column for current projects, and another that was for pending projects. All active projects were listed in order of priority and had a status written after them. This is obviously not how one should do Agile, or Kanban, but I hadn’t yet learned about either of these strategies. The whiteboard was also intended to be a visual reminder for Mr. X about what he was supposed to be working on.

After my “diagnosis” of Mr. X’s ADD, I knew I had to try something different, and much more organized. What we were doing wasn’t enough to keep his focus, and clearly wasn’t working. I did some research and read my first article on Agile development. It described a simple Kanban board strategy for breaking down projects into smaller, manageable pieces. It seemed like a simple and quick thing to try that could really help our team.
I changed our whiteboard and project list into a simplified project backlog on one side. I bought a bunch of colored post it notes, thin tape, and pens and started listing the tasks for our active projects, posting them on a Kanban board I had made using the majority of the remaining whiteboard space. I’ll admit that my adoption and understand of Kanban processes was not complete, but with this new structure I was able to give more discrete and concrete tasks to Mr. X.
Additionally, we started having a daily scrum meeting. We worked in an open area — just four of us on the development team – and I posted a note above my desk that said –
What did you do yesterday?
What is today’s priority?
Are you blocked anywhere?
These three questions were to be answered at a high level every morning in what was supposed to be a quick meeting for all four of us to share.
Did these strategies work?
Agile strategies did not completely resolve my frustrations of working with Mr. X. He would choose to reorganize his email rules or focus on a task that was not even on our Kanban board. Still, his work was better than before. The Agile strategies did give him greater direction and focus. Our boss was not completely committed to our daily scrum meetings, making it difficult to get complete buy in from Mr. X, too. But where there was a true breakdown was when he would alter or ignore the user story written on the Kanban card. That wasn’t Agile’s fault. Our manager would need to address these greater issues.† We were making improvements though, and this was after more than a year of real frustration and many other efforts. I decided to go all in with Agile and started learning everything I could about it.
Where there was a bigger “win” with our Kanban board and scrum meeting adoption was in showing where (and when) we had blocks and problems. (Sadly, almost always the block or problem’s name was Mr. X.) There was no longer any argument about what the root cause was with regards to specific tasks and work not getting completed as desired. We had real accountability.
When priorities got changed, there was a visible shift on the Kanban board, too, and it was clear what tasks would be left waiting. This was good for the larger business unit to see. I was required to break work down more specifically and clearly, which was something I had failed to do well prior. Communication was greatly improved not just in our team, but to the greater business unit we worked within.
Using Agile strategies leads to much greater accountability.
With more frequent check-ins thanks to our daily scrums, and breaking down larger tasks into smaller units, providing a time “bucket” to be associated with each task, there was no longer any ambiguity about where work was getting off track. Our team still had struggles, but everyone now knew where the main blockers were.
We now had a roadmap for how to improve our workflow and I become a convert to using Agile strategies.
†My frustration would get much worse later. I eventually gave an ultimatum that our boss would need to fire Mr. X or see me leave the company within the month — Mr. X announced his leaving the company a few days later giving my boss an out and me a new lease on my job.
Photo by Chase Clark on Unsplash