• Prev
  • Next

Avoid the Expert Effect When Consulting

The “expert effect,” roughly, is the inability of someone who has achieved mastery of a subject to relate that concept to a non-expert. This is especially important to be aware of with consulting. As a Certified Function Point Specialist (CFPS), I spend a great deal of time working with Subject Matter Experts (SME) discussing function point counts for various software projects.

A lot of these discussions focus on the SME explaining how a particular piece of software functions. Of course, he or she knows everything about the software – I don’t, but I need to be as informed as possible in order to appropriately size it. Essentially there is a gap in my knowledge and I am dependent on the SME to fill it – which is not always easy (“Why can’t you understand what I’m talking about?!” is a commonly unexpressed, but felt, sentiment).

Keeping the expert effect in mind, there are a few things you can do to make it easier to collaborate with an a SME.

In discussions with a SME, always be mindful of the effort it took to become an expert. Every word of what seems like a “simple” explanation or question is back-loaded with hours, days, years of contextualized study and experience. Keep that in mind and be patient when relating concepts. Do not expect the SME to “get it” in the ‘”right” context (i.e. your context) immediately when sharing a concept or asking them a question. Losing patience is disrespectful to not only the SME, but also to your own efforts in becoming an expert!

Be aware that a SME can also have the tendency to be overconfident in the simplicity of an explanation. This is the other side of that coin. Sometimes when the consultant (me!) searches for clarity on a concept or asks for more detail, the SME will get annoyed because they feel it has already been explained simply. Find a polite way to point out that the reason for more questions is that there is still a knowledge gap to bridge for your own unique perspective. Of course, if it were so simple to know their system, they would not be the expert!

Working with an expert is obviously valuable – he or she knows the topic at hand to the fullest extent. But, distilling that knowledge into digestible pieces can be an exasperating challenge. Understanding that challenge is the first step to opening the door to communication – and a more efficient engagement.


Karl Jentzsch
Senior Analyst

 

Written by Karl Jentzsch at 05:00

Better Agile / Better Software Conference East

IMG_1068Last week I attended the Better Agile & Software Development Conference East, and I really enjoyed the experience. The conference presented a good opportunity for organizations to come and learn about some of the common struggles facing software development from a process and strategy context.

Because of the broad topic area, the conference included a good mix of organizations in terms of size and industry. For example, there was one organization there that has a single development team, and it sent most of the development team to the conference for Agile certifications and learning opportunities. There were other organizations who hand-picked members from among hundreds of teams, with the intent of discovering fresh ideas to bring back to present to managers in the hopes of starting a conversation about ways to improve or move forward. The vast array of lines of business in attendance was impressive – software development vendors, government agencies, blood banks, medical clinics, financial firms, department store chains, process consultants and everything in between.

The conference itself seemed to focus on two common themes. The first was trouble with testing inside of the Agile framework. Testing is no less important to the development process than actually developing the code or requirements, but often testing is crammed into the end of a sprint cycle, which leads to late discovery of defects and contributes to difficulty in estimating projects.

This difficulty speaks directly to the second common theme – trouble with estimation in Agile. A large number of organizations are having trouble shifting their estimation models to fall in line with the Agile approach because of the change in philosophy and an inability to establish a recognizable cadence to their releases. This also makes it difficult to provide reliable estimates, which snowballs with the testing issues mentioned above.

Some of the tutorials I attended at the conference provided good insight into ways to deal with the problems of estimation within the Agile framework. The best example of this was taken from a tutorial about the role of a business analyst in an Agile environment when the instructor mentioned an idea that resonated immediately with everyone in the room and provided words to a concept we had all felt before – the need for a “definition of ready.”

 In Agile we are familiar with the idea of a “definition of done” – aka the criteria we have to consider for a backlog item to be considered complete and moved into the “done” pile. The definition of ready is the other side of this – aka the criteria that must be met in order to consider an item ready to go into the backlog. If this criteria is not established, the backlog gets cluttered quickly and the implications are not understood to the greatest degree possible. This then makes it difficult to estimate the task appropriately and also leads to more difficulty in establishing the testing goals in advance.

I certainly came away from that tutorial and the others with some good tips for how to approach these (and other) trouble areas. Of course, it was also nice to be just a block away from Downtown Disney for some evening entertainment!

I look forward to delving further into the concept of estimation in the Agile environment (something we can help with here at DCG) and the “definition of ready,” with the team here at DCG. If you attended the conference and have any thoughts about these concepts or about the conference itself, please leave a comment! Otherwise, I hope to see you there next year!

 

Karl Jentzsch
CFPS

Written by Karl Jentzsch at 05:00
Categories :

"It's frustrating that there are so many failed software projects when I know from personal experience that it's possible to do so much better - and we can help." 
- Mike Harris, DCG President

Subscribe to Our Newsletter
Join over 30,000 other subscribers. Subscribe to our newsletter today!