Category Archives: Management

The Dangers of Tribal Knowledge

On her first day, Jayne spent a lot of time collecting data from teammates to become familiar with the company’s systems and procedures. Since she appreciated the hands-on approach being taken with getting her settled in, she made her own notes and never stopped to ask if there was a corporate wiki or central document system where this information was stored. Six months later, Jayne had become a valuable member of the team, had gained significant knowledge from her team, and was given a product enhancement project. While reviewing the code for the necessary changes, she noticed some oddly designed features. She asked her team lead, Tim, where the original specification of the app could be found so that she could understand why the application had been written that way. Tim gave her a confused look as said, “You’ll have to talk to Carrie. She’s the only one left from the team that wrote that. I think she’s in DevOps now.”

If you have run into a situation like this then you have already experienced the effects of Tribal Knowledge. This happens when enough people know how something works so it is believed that documenting it would be a waste of time. This common knowledge is ok for situations that everyone must deal with every day, however, relying on it for more obscure information can lead to lost data, increased project time, and decreased morale. Let’s check in with Jayne to see how this plays out.

After learning where Carrie now sits, Jayne heads over to ask about application.

“Carrie?”

“Yeah.”

“I’ve been assigned to enhance the shipment tracking system. I’m looking for the original specification, design plans, notes, whatever documentation there is on it and Tim told me to talk to you.”

“Good luck with that. I was only on the team for about two weeks before release and I never saw any documentation. We had meetings where we kicked some ideas around and then we went off and made it work. Josh and Kate were the ones that really knew that system. We’ve been hoping it didn’t break since they left.”

All too often (especially in IT), a source of knowledge will change jobs or companies and that resource will be lost. If the teams rely too heavily on tribal knowledge then it becomes likely that they will fall to the trap of reinventing the wheel or relearning lessons. This cycle results in inefficient use of both time and money. In a worst case scenario, it also depletes the moral of the team members assigned.

The easiest way to avoid the negative effects of tribal knowledge is through documentation. I expect that some people cringed after reading that and/or pictured writing tomes explaining every intricacy. Documentation doesn’t have to be tedious nor does it have to be extensive. Sufficient documentation to avoid a situation like Jayne’s could have been a short comment explaining the unusual approach in the code. Alternately, it could have been kept with the design records in an archive of stories or specifications. The key to good documentation is to eliminate the unnecessary and focus on what is important. Obvious functionality such as basic field validation (eg., number fields do not except letters) can be ignored while business logic should be called out in some way. If a developer needs to come up with a “clever” solution to an issue, there should be a comment in the code to explain why it was necessary and possibly how it works. Whether you write traditional specifications, Agile stories, or take notes in a team wiki, a few minutes of writing can save hours of review and frustration.

Advertisements

Are We Agile Yet?

Over the past few years, I have had the pleasure of working with multiple teams with each practicing their own flavor of Agile. This has given me the opportunity to see how processes grow and evolve based on the goals, strengths, and challenges faced by the teams. I have also been able to witness and gain insight into some of the confusion and mystery surrounding the Agile Methodology. For those who are just starting out on this path or those that are seeking a little more clarity, I offer you these three steps to help you on your way.

1. RTFM – Read The Famous Manifesto

Take the time to read The Agile Manifesto including the Twelve Principles of Agile Software. Despite how much has been written about Agile, the manifesto is quite short and easy to follow. By reading the words yourself, you will build your own understanding of them. It is that understanding that will help guide you to success as you discuss and evolve processes and methods with your team.

2. Confirm Team Alignment

Agile is not just for developers. It is for the whole team which includes developers, testers, product owners, facilitators, and stakeholders/customers. With that many roles involved, it should be obvious as to why you need to make sure everyone has clear expectations of their responsibilities and the ultimate goal of the team.

You may note that I said “roles” rather than “people” when describing the members of the team. That is because a single person may perform multiple roles on a team. For example a stakeholder may choose to also be the product owner or the lead developer may also be the facilitator for the team. No matter how many people the team has, alignment on duties and expectations is essential.

The Product Team:

  • Stakeholder: Provides input about the product. May also have financial responsibilities to the team and/or product.
  • Product Owner: Defines and prioritizes the project stories and tasks.
  • Facilitator: Runs meetings, removes obstacles, and shelters the team from interruptions.
  • Developer: Plans and writes code for a software project.
  • Tester: Confirms the application functions as expected.

As part of the team alignment, it should be agreed that no one member should act unilaterally because this hinders communication and will effect the project. While each member has ownership of an aspect of the project, they should make decisions based on information gathered from both their experience and that of their teammates. Product owners are responsible for what is being worked on but they should not dictate the completion dates. Developers control the frameworks, tools, and technologies used in the product but they should consider the advise from the testers to make it easier to catch bugs.

Communication and consideration are key to building team alignment.

3. Find What Works For Your Team

Agile is not a destination. Nor is it a single skill, practice, or process. No one can provide you with a checklist or script that will transform any team or product into an Agile one. The reason for this is every team and situation is unique and as such requires an equally unique solution.

This isn’t to say that there isn’t value reading about what other teams have done. Developing a unique solution doesn’t mean you have to build everything from scratch. In fact, it’s probably better for teams to adopt some practices they learn from articles, books, or an Agile Coach when they are starting out. This will provide the team with a chance to avoid some of the pitfalls and get a jump on their progress.

The key is to not get hung up on “the right way” or “requirements” of being Agile. If your team has found that part of the process isn’t helping to achieve the end goal, get rid of it. Teams should be allowed to determine the best way for them to function. So long as they continue to communicate with each other (including stakeholders, customers, etc), are able to adapt to change, and deliver working software on a regular basis then the team is successfully implementing Agile.

A Brief Review of “The Phoenix Project”

Over the past couple of weeks, I have been listening to The Phoenix Project during my commute to and from work. Having finished it today, I decided to jot down some of my thoughts and share them with you.

The first thing I will warn you about is that if you have already read The Goal and understand how it can be applied to IT then you are not going to find any new, eye-opening concepts in this book. The plot follows a middle manager that finds himself being promoted to the head of a struggling department. Through determination and coaching from a elusive and wise mentor, he learns to identify and control work along with how to align it with the companies needs to become successful and rise to the top of their market. For the record, that is the plot for both books. I identified the similarities between the books within the first couple of chapters, but was amused when the main character’s mentor began to quote and reference The Goal while explaining that work is work and IT is no different from a manufacturing plant.

With my main criticism out of the way, I found the story to be a fairly realistic look at IT functions within an company. Misunderstandings and unreasonable demands result in repeated disasters and a generally oppressed and depressed atmosphere. I dare say the stage was set so well that I could not only draw parallels from my experience but was starting to have actual sympathy for the characters because I could see what was coming.

Overall, I think this is a good book for IT staff, managers, and all executives to read and gain an understanding of the processes that help work flow. For the IT staff in the trenches, the purpose of reading this book should be gain an understanding of why processes may need to change and to help acknowledge that their managers need help not resistance. The executive’s take away should be to identify things that were done poorly by the executives and the board in the book so that they can recognize and correct similar issues within their organization. For the last group I recommend this book to, I suspect the take away would be a number of ideas regarding how to implement changes and structure work for their teams and that there is some hope if you can get those above you and below you to listen to reason.

I would recommend this book over The Goal for use in IT organizations simply because it makes it easier to see how the concepts apply to IT while making a point of addressing the common responses from IT personnel. I believe this was the motivation of the authors and, if I am correct, they succeeded.