Essence and Problem Solving Blog

April 7, 2021

32 Questions and Answers from my recent ACM Tech Talk on Teaching our Next Generation of Software Practitioners in the Universities

Filed under: Essence and Problem Solving — pemcmahon @ 12:37 pm
Tags: ,

On March 25, 2021 I gave an ACM Tech Talk titled: An Industry Perspective on What We Should be Teaching our Next Generation of Software Practitioners in the Universities.

As of March 29, there were 1815 registrants for the talk, and 806 attendees, of which 570 attended live. More will be viewing the recording in the days ahead. If you haven’t registered and would like to view the recording, you can do so at the following URL:

https://on.acm.org/t/an-industry-perspective-on-what-we-should-be-teaching-our-next-generation-of-software-practitioners-in-the-universities/1992

At the conclusion of my presentation I answered a number of the participant questions, but we did not have time to answer all the questions so I agreed to answer more questions off-line.  Below you will find my answers to 32 of the questions received from participants. 

I have also conducted a Pareto analysis of the questions grouping them into the four categories to see where participant interest lies.   Refer to Figure 1.  

Figure 1: Pareto Analysis of Questions Received

The question numbers associated with each category follow:

Category 1: Essence and Practices

1, 3, 4, 23

Category 2: Value of Essence/Challenges to Essence

5, 8, 12, 13, 17, 18, 19, 21, 25, 26, 29, 30

Category 3: How to Teach Essence

2, 6, 7, 9, 10, 14, 20, 27, 31, 32

Category 4: General Essence Questions

11, 15, 16, 22, 24, 28

If you have further questions, or would like clarifications on any of my answers, please leave a comment and I will do my best to respond. 

Question 1: What is your position on Watts Humphrey’s Personal Software Process and Team Software Process as ways to developing a personal method?

Answer: I believe both PSP and TSP are very good processes, but keep in mind these are both processes, and Essence is not a process.  The five checklist items I referred to at the end of my presentation that are part of Essence are intended to help developers become better estimators and better at answering the question “when will you be done” which is a large part of what Watts was getting at in PSP with regard to learning to measure yourself in a disciplined way.  You can use the Essence checklists, if you use PSP or TSP, or any other process including Scrum, or a Waterfall variant. 

Question 2: What do you think universities should stop teaching to make time for teaching the material you suggested?

Answer: I answered this question at the end of my talk, but I will restate my answer here.  I don’t think we need to stop teaching anything to teach what I propose.  I am proposing the insertion of concrete examples/stories from real industry situations (I gave a number of these examples/stories in my talk) into each course in the University.  Then just change the way certain things are taught to make them a little more efficient, thus making time for the added stories/examples. 

Question 3: Agile methods have been a buzz for at least a decade. It seems that the buzz is fading and becoming “real”.  Critical views on agile i.e. Antipatterns and “survival guides” are popping up. Any comments on that shift?

Answer:  All methods (agile or traditional) have weaknesses.  It is to be expected with the popularity of agile methods that we would be seeing antipatterns and survival guides to try to address the common weaknesses people run into.  This is one motivator for Essence, which as I said in my presentation is NOT a method itself. It is a common ground of essentials that underlies all successful methods and, as such it can help us identify the weaknesses in any method including agile methods.  Many of the examples/stories are referred to in my talk are, in fact, anti-patterns that we often see in organizations regardless of the method they choose to use.

Question 4: Natural language may not be precise enough to express procedures; process logic.

Answer: What I am suggesting is not intended to replace teaching computer programming languages that do need to have precise syntax/logic.  What I am suggesting is adding stories that communicate the real kinds of situations that software developers are certain to face in industry, so they don’t get a big surprise when they leave the university.  These stories are best communicated with natural language.

Question 5: I don’t know about this. In many universities I have been in, the capstone project (senior design projects) has real stakeholders and mostly ambiguous requirements.

Answer: I know there are some universities where this is true, but, as I mentioned in my presentation, I have also heard university professors say their students don’t have real stakeholders and they don’t have ambiguous requirements.  It would be good to hear more of the stories and lessons from the universities that are already doing this and if they have received feedback that the students are better prepared because of these capstone projects. What I am suggesting is to supplement courses with these real stories which can support capstone projects if you have one, and at least give students who don’t have the benefit of participating in a capstone project some ideas of what they should expect when they leave the university.   

Question 6: What is the percentage of active practitioners teaching in universities in comparison to academics?

Answer:  This is a good question and I personally don’t know the answer. If anyone who reads this does have a reference to a good answer please provide feedback.  I do believe we should be encouraging more active practitioners to share their knowledge with students.  I address this further in a later question.

Question 7: Do you have any tips for balancing the limited time available in an academic term with the simulation of difficult stakeholders and late hardware?

Answer: This is exactly why I like telling students stories. I think they can understand the kinds of stories I shared in my presentation and it doesn’t take a lot of time to tell the story and then have a follow-on discussion related to the associated Essence Alpha and checklist (s).  Admittedly, this might not stick with the student to the same degree as actually having a real project with a real difficult stakeholder or some real ambiguous requirements they have to work through, but it is one way to deal with the time constraint of an academic term.

Question 8: How are NFRs such as performance and reliability captured in this framework? Students are seldom taught to be aware of these.

Answer: I answered this question at the end of my talk, but to reaffirm my answer.  Often students find non-functional requirements difficult to grasp.  This is a perfect example why we should use real stories from industry to explain what happens when non-functional requirements are not appropriately addressed.  There are many such well-known stories that could be shared especially in the area of performance, such as the Obamacare Website problems.  Telling stories is the best way I know to make the point stick short of actually having the time to conduct a real project.  Using the related Essence checklist can then serve as reinforcement and as a reminder once they leave the university and go into industry. 

Question 9: As an active undergraduate student, would Essence and root cause analysis be taught in conjuncture with something like operations and management course? Or would these concepts be taught in their own course?

Answer: It could be done either way, but what I am proposing is to spread this training across many courses with relevant examples to each course inserted.  Root cause analysis isn’t something that should be limited to just one course.  Students should learn this way to think and use it throughout their career wherever and whenever appropriate.

Question 10: Grand Canyon University hosts a tech advisory board session each semester – the topic of changing or unclear requirements has come up.  It is hard to teach to that scenario because education requires having clear expectations.  Do you think providing User Stories and Task lists meet the need for students?

Answer: I don’t believe User Stories and Task Lists are sufficient.  They provide one way, but the student should be taught that this is just one way and the company they end up working for may or may not use this approach.   I believe you can set clear expectations in the university by adding real world scenarios to class content with changing or unclear requirements, having classroom discussions on those scenarios, and then testing the students by asking them to describe the root cause of the problem discussed and possible solutions. 

Question 11: Is there a place we can find all of the checklists?

Answer: Yes. On the last slide of my presentation you will find how to access all the checklists from the SEMAT website.

Question 12: Do you think universities should teach students things that change every few years in the real world? (I’ll give you a hint. The answer is NO!)

Answer: I didn’t need the hint. –:😊) You are right. The answer is NO.  This is a major driver on why we developed Essence. That is to teach students what they can take with them and use for a lifetime in industry.  This is much more valuable content for the student.

Question 13: Why should universities teach things that change every few years?

Answer: See the answer to the previous question.

Question 14: When should we be introducing Essence into a curriculum? How do I teach this to my freshman students, many of whom have zero programming experience and may need very structured assignments?

Answer: As I said at the end of my presentation and as I said in my answer to question 2, I think Essence should be distributed throughout a Computer Science curriculum and taught in a “stealth” mode by actually using it through concrete examples where appropriate.  Thus, the freshman student might get a little introduction to it, and then learn more about it in other courses where other examples might be more appropriate.   If you have a course on software engineering methods that would be a good place to talk about Essence from a big picture perspective.  Also, if you have a course on software engineering management that would also be a good course to talk about the general idea of Essence from a perspective of assessing progress and locating trouble spots in your project.  If you have an ethics course this would be a good place to talk about the importance of getting all the team members and stakeholders in agreement with the ethical principles they will follow on the project… and so on…

Question 15: Is linking the architecture to the requirements part of the check list?

Answer: Essence doesn’t provide “ hard links” between architecture (or software system- the alpha that includes architecture checklists) and requirements (requirements alpha) although there is certainly a relationship. The essentials of architecture are addressed in the Software System Alpha, and we say that the Software System Alpha “fulfills” the intent of the Requirements Alpha.   We say it this way for the reason I explained in my talk related to the “Enough Addressed to be Acceptable”.  Sometimes you don’t need them all addressed to “fulfill” the intent, as I explained in the “Requirements are not always requirements” example. 

Question 16: Is linking requirements to business and engineering needs part of the checklist?

Answer:  As I mentioned in the previous answer, Essence doesn’t provide “hard links” between requirements and other areas, such as business and engineering needs.  The essentials underlying “needs” are addressed in the Opportunity Alpha and there certainly is a relationship between the “needs” and the Requirements.  We say the Opportunity helps to “focus” the Requirements.  The specifics of this relationship depend on the practice your organization decides to use for requirements gathering (e.g. user stories, use cases etc.).  The reason I am being careful with the word “link” is because Essence is independent of method or practice choice.  What we say in Essence needs to be true for any method or practice.  This is also why it is so useful to teach students.   

Question 17: Do you think this type of education will help minimize “imposter syndrome?”

Answer: I haven’t heard the phrase “imposter syndrome” before, but if it means one practice pretending to be new when it really is fundamentally the same as another known practice or method, the answer is Yes.  This was one of the goals underlying the development of Essence. That is, to provide a common ground from which to compare practices and identify real discriminators.  Therefore you can use Essence to determine if there are no real discriminators and a certain practice is thus effectively nothing new.

Question 18: Examples of things that change every few years are software development methodologies (SCRUM/Agile/Essence/XP).

Answer: I disagree with your putting Essence in this list. Essence is not a methodology.  The intent of Essence is not to be used as a method to develop software.  It is intended to be used together with whatever method your company has chosen and therefore it doesn’t change every few years even if the method your company is using changes or if technology or tools change. Again, this is a powerful motivator for learning and using Essence. It isn’t going to keep changing every few years.  There may be minor improvements over the years, but it will essentially remain pretty stable. 

Question 19: One issue I see in industrial software is office politics. For example, resistance to change. When bringing improvement to an existing process or a system, existing people who created the original system would perceive this as an implicit critique to them and would fiercely oppose any these changes or enhancements. How would this be taught to students?  Thanks.

Answer:  Good question. I answered this question at the end of my presentation.  But to emphasize the point I made – this is a primary reason why I use Essence in what I call “stealth mode” as I discussed in my presentation.  I don’t think we should start from the supposition that something needs to change in an organization because that is a setup for opposition, as you say.  The starting point should be observing whatever your organization is currently doing and understanding what is perceived by those in the organization as not working well.  Then we use Essence (in a stealth mode—just stimulating normal conversation) to help identify the root cause of the problem.  From there we can all discuss the possible solutions and reach agreement.  This approach I have found can help to diffuse any emotion around change by taking the time to look at and reach agreement on what needs to be done to help the organization be successful.

Question 20: Where do we get all the relevant stories? I have some industry experience from before joining my university, but my experience is not extensive enough to know many critical stories of how company’s decisions impacted the work with the clients.

Answer: This is a great question.  I have personally shared many stories from my own career (such as in this presentation) and stories that have been shared with me by my clients (also in books I have published—for example my “It’s All Upside Down…” book has many real stories as does my “Integrating CMMI and Agile…” book).  I often encourage those with industry experience to share their stories through publications and by giving talks.  One way is to invite industry personnel to come into your classroom and give talks on real experiences with a focus on the trouble spots or challenges faced.  You could then have your class discuss the stories shared afterwards and see if they can identify root causes of problems discussed and possible solutions using Essence Alphas and checklists to guide the discussion.

Question 21: Imposter syndrome is a feeling by entry-level programmers that they do not have the knowledge, skills, or experience to be successful.

Answer: Ok. I think I misinterpreted what this phrase means in a previous answer, but my answer is still Yes.  Telling stories can help minimize this syndrome among beginners because it will help them feel like they have been in these situations just by hearing the stories.

Question 22: I must admit, I do not fully understand the concept of requirements not being requirements yet. Any clarification would be helpful. Thank you.

Answer: I tried to explain this in the talk, but let me try again and see if I can simplify it. Often something is written as a requirement because the customer (or person writing the requirement) only knows one way to get their needs met. But what they are asking for isn’t really a requirement, but rather one way to achieve their real need which is something else more fundamental.  When they learn more about the capabilities of the system that has been developed they may find another way to meet their need and thus what they thought was a requirement doesn’t turn out to really be needed by the customer.   Hope this helps.  You can often find lots of examples of this when a system is given a new user interface with different ways to achieve a user goal. 

Question 23: Can you come back on the Scrum practices that are implemented, poorly and not at all? What are they in each category? Thanks

Answer: Thanks for asking this question.  It isn’t one set (or one category) that are always implemented poorly or not at all. It varies with each company. For example, some organizations who claim to be doing Scrum don’t actually do retrospectives at all, while, of course, many companies conduct very effective retrospectives.  Some organizations implement their daily standup poorly and so on… 

Question 24: So that means, checklists are not enough but we should also group them based on weight or priority? So that if the more weighted ones are not checked, you shall not pass.

Answer: This question is in relation to my story about the Senior experienced personnel and critical thinking.  The answer is Yes, but be careful how you implement this. Which checklists have more weight or more priority depends on the situation so please don’t think you can do this assessment of priority and weight just once for a given organization and say that is the way we use them in our company.  This is why you need to teach your developers how to think and make better decisions on a daily basis.  I have seen organizations who try to dictate these answers from the top and it does not work.  It actually will cause the use of Essence to fail.  It leads to just using the checklists in a “check-the-box” mentality which is not what we are looking for.  We want your people to learn to use the Essence checklists to help them make better decisions given their own context.  Essence can’t make the decision for them.  Essence doesn’t know your context and this is crucial for each decision.

Question 25: If we conclude, we can say that students can learn from these stories and instead of following the usual tradition of “learning by making mistakes”, they can learn from others’ mistakes.

Answer: Yes. That is what I am saying. I am not trying to say they won’t still make mistakes and learn. We all must be continual learners, but we can share what others have learned so our new developers don’t have to relearn what experience has already taught us.  That is a big advantage of using Essence.

Question 26: Thank you very much Mr McMahon, so so interesting, holistic thought useful in many knowledge areas to teach in the university.

Answer:  Thank you for the nice comment. Good to hear you find it useful.

Question 27: We have a whole mashup of degrees that could lead to programming careers: CS in Arts/Sciences College, CS in Engineering College, Computer Engineering, Software

Answer: Yes. And as I suggested, I believe using Essence together we concrete real stories could be integrated into all of these degrees to help the student have a better idea what they will face when they leave the university and go into industry.

Question 28: where are the cards downloaded from?

Answer: You can find the url on the last slide of my presentation.

Question 29: More than 99% of code in the world runs in embedded devices. I work in the specialised area of safety-critical embedded systems: railway signalling, medical devices, (semi-)autonomous cars, surgical robots, warehouse robots, etc.

A few years ago I gave a keynote talk at an IEEE conference (sorry, but I wasn’t invited to an ACM one) and found I had a room full largely of academics. I asked for a show of hands of how many worked in a department that taught the skills required for embedded programming. Very few hands went up — many of the people present thought that Java was a programming language! I then refined the request to those who taught the techniques of producing safety-critical embedded code. One hand remained up. The safety-critical area is growing very fast and we are desperate for new blood, yet we cannot get such people from the universities.

Answer:  The situation described is one of the motivators for Essence.  As I mentioned in my talk you won’t find specific principles and practices in Essence and this includes safety critical principles and practices.  This is because not all software development requires these specialized skills.  It is expected that organizations develop additional alphas and checklists extending the Essence kernel addressing the specific needs of their domain.  

Question 30: This is really important. There’s many “industry oriented universities” with short academic programs that are skipping essential engineering and mathematics courses in favor of only programming-oriented courses

Answer:  Yes.  This is a good point and again it is a motivator for Essence. Teach the core fundamentals that are relevant to all successful software development.  We are not saying, as mentioned in the previous answer related to safety-critical needs, that this is all that computer science students need to know.  But it does ensure they understand the essentials that should always exist for successful software development.

Question 31: Does Computing Ethics have a place in the Computer Science (and related) curricula? And if so, how big should that place be, i.e one off ethics course, integrated ethical/social considerations per each computing course, interdisciplinary collaborations (e.g. between Computer Science, Social Science, Law etc) for teaching ethics, etc ?

 Answer:  Absolutely yes.  I also mentioned this in my talk. Essence does not prescribe ethical principles, but it does remind teams that stakeholders and team members need to agree on the principles and practices they will follow and that includes ethical principles.  It is my view that one of the best ways to handle this is to integrate this discussion into appropriate courses with concrete stories/examples.  For example, a course on databases could have a discussion on privacy and the responsibilities of a database developer in regard to protection of personal information.  Similarly, a course in artificial intelligence could have examples/stories that discuss the potential consequences and responsibilities of the software developer related to controlling self-driving cars and so on..

Question 32: At Grand Canyon University, we look for ways to introduce experience in reading other people’s code and refactoring it without breaking previously working functionality. We know students usually build something from scratch and with their own bias on knowledge and skill. By expanding their code exposure, they are more successful when they enter the industry.

Answer:  This is a great way to help prepare students for what they will face in the University because more and more software developers are working on legacy code rather than developing new code.  I would also suggest this is another great application for Essence, as students can use Essence in assessing legacy software looking for root causes of potential problems and potential fixes to these problems.  The results of such an assessment could be class discussion item. 

February 28, 2021

Incremental Essentialization: A cost-effective and practical value of “Stealth Essence”

Filed under: Essence and Problem Solving — pemcmahon @ 9:09 pm
Tags: , ,

If you would like to read this blog, scroll down to where it says “Blog Text Starts Here.” If you would like to listen to the podcast version of this blog, click on the link and scroll down to where you can select the podcast.

Blog Text Starts Here

In my last blog/podcast I explained a simple way to apply just the right amount of structure to fix a problem with—or improve—a culture by using the Essence Pattern to capture essentials.  But how do you go about finding exactly which essentials rest at the heart of your current problem? 

I have in previous publications and blogs discussed [1,2,3] why I use a stealth approach when applying Essence with clients.  Simply put, proving the value of Essence by using it to help solve an actual problem is often the most practical way to get a client onboard.  But there is another good reason to take this approach, as well. 

Many senior organizational leaders are simply not convinced that investing in essentializing all their existing practices will be worth the investment.  This is where the stealth approach can help because it can be used to uncover small opportunities leading to an incremental essentialization approach.  Using this approach you can prove out the value of essentialization to your client (or your manager) in a low-cost way.  Let me give you an actual example from one of my client case studies. 

In one of my recent books [4] I tell the story of a client, I refer to as NORO, where we allowed the development team to effectively discover their own best practices while working on an actual customer project.  I make the point in this story that this approach seems totally “upside down” from what many of us have been taught with regard to proving out a well-defined repeatable process before using it on a real client engagement. 

But as we learned at NORO, by allowing the team to discover what worked best for them, we achieved rapid buy-in of key practices by the full team.  The reason this worked was because we were careful to make continual and small incremental improvements.  This substantially reduced the risk related to any single practice change.   

After we had proven out the new behaviors (many related to testing practices), I then was asked by my client to document the new/modified practices that the team had proven worked effectively.  When I captured these practices, I used an essentialization approach ensuring that the behaviors that were “essential” for success were clearly highlighted for other team members to learn and follow in the future.

This approach that includes waiting to formally describe your practices until after you have proven they work may sound upside down, but it worked effectively at NORO.  And, most important, NORO didn’t need to commit a large budget to essentialize all their practices at the same time.  Rather, at NORO, we essentialized the highest priority practices that we knew would give the organization payback because we had already proven it on a real project. 

If your organization isn’t ready to commit to essentializing all your practices, consider taking the “stealth approach” to identifying incremental improvement opportunities.  Once you have identified the essential improvements needed and proven they work, convincing your senior leaders to commit the budget to further practice essentialization will become a much easier road to navigate. 

Feedback is encouraged. 

[1] General information on Essence, https://essence-in-use.com/

[2] Essence-In-Use References https://essence-in-use.com/more-info-on-essence/

[3] Essence-In-Use Training Course, https://leanpub.com/c/essence

[4] It’s All Upside Down, Story Two, NORO Case Study, https://leanpub.com/itsallupsidedown

February 21, 2021

Essence Patterns: A simple way to apply just the right amount of structure to fix a problem with– or improve– a culture

Filed under: Essence and Problem Solving — pemcmahon @ 7:30 pm
Tags: , , ,

If you would like to read this blog, scroll down to where it says “Blog Text Starts Here.” If you would like to listen to the podcast version of this blog, click on the link and scroll down to where you can select the podcast.

Blog Text Starts Here

In my last blog I explained how you can fix a problem with—or improving – a culture and I gave a client case study that demonstrated how applying just the right amount of structure can improve a culture without adding unnecessary overhead.

In this blog I want to dive deeper into this subject showing you a simple way you can apply just the right amount of structure using an Essence pattern. So, let’s get into it…

People become engaged in their own improvement when they hear stories from peers. Over time I have noticed repeating patterns to the stories I hear and I often share these stories (without attribution) with clients facing similar challenges. I refer to these repeating patterns as “thinking patterns” because they can help teams effectively think-through their own challenges.

When the SEMAT [1] volunteers were developing the Essence checklists [2] I shared many of these stories and the other volunteers shared their own stories.  This was the genesis for many of the checklists that today are in the Essence standard [3].  

Today I use Essence checklists, along with Essence Patterns (discussed below) to communicate the “essence” of common stories relevant to a problem my client may be facing, along with proven solutions.  

In many cases the “essence” of both the problem and solution to these common situations is found to be rooted in culture.         

As an example, going back to Alistair Cockburn’s Spotify Case Study discussed in my previous blog [4], the solution Spotify came up with for managing dependencies was an optimal solution for their organization because it didn’t add the overhead of a Monday meeting and it utilized the existing Spotify culture to solve the problem.  

Similarly, the solution we came up with for my client with the Risk Management challenge (also discussed in the previous referred to blog) was optimal because we didn’t need to change what was already working well in the organization.  We just needed to rely on the existing culture and train more of the organization in the approach, which we referred to as “Doorway Risk Management.”

Nevertheless, all personnel in most organizations cannot be counted on to always provide what is needed to a teammate by a required date, as was the situation in the Spotify Case.  And in my own client case we could not count on everyone in the organization applying the “Doorway Risk Management” process just because that had become the culture for part of the organization. 

To fully implement this proven approach across my client’s organization we added a number of checklists to a one-page guidelines document and shared it broadly across the organization through focused coaching sessions. 

One way to capture this kind of solution to a problem and share it across an organization is through the Essence Pattern.  You can think of an Essence pattern as anything that can help teams conduct a practice more effectively, such as a collection of checklist items. 

You can also think of these checklist items as a set of  “essential reminders.”  As an example, refer to Figure 1 for the Scrum Values Pattern which reminds teams that the successful use of Scrum depends on people living the five Scrum values.

  Figure 1 Scrum Values Pattern

As another example, consider Cockburn’s Spotify Case Study.  In this case, we could have a Collaboration pattern that captures key checklist items, or “reminders” of things to think about to help manage dependencies.  Refer to Figure 2 for an example of an Essence pattern that could be used to capture key checklist reminders related to the Spotify Dependencies Case. 

                 Figure 2 Possible Spotify Collaboration Pattern to Manage Dependencies

It is also worth noting that there could be many more patterns collected under groups, including Collaboration, Deliver, Reflect and Improve as highlighted within the Heart of Agile initiative [5].  

In my own Essence training [6] I share a number of common patterns that I have observed, or my clients have shared with me, along with collections of related Essence checklist items to help teams think-through their own similar challenges leading to the best solution for their situation.

We now know the critical importance of culture to the success of any endeavor.  Many of the most common problems we see with software development teams (or any team for that matter) aren’t easily solved by simple structural fixes alone. 

Nevertheless, using Essence patterns can provide a simple and practical way to add just the right amount of structure to remind teams of essentials to fix a problem with—or improve—a culture. 

As always, comments are encouraged.

[1] SEMAT stands for Software Engineering Method and Theory. For more information refer to www.semat.org.

[2] For more information on the Essence checklists refer to https://essence-in-use.com/essence-in-use-forum/

[3] Essence checklists are part of the Object Management Group (OMG) Essence standard. For more information about Essence refer to https://essence-in-use.com/more-info-on-essence/

[4] https://paulemcmahon.wordpress.com/2021/02/11/how-do-you-fix-a-problem-with-or-improve-a-culture/

[5] https://heartofagile.com/

[6] Certified Essence-In-Use Practitioner Training, https://leanpub.com/c/essence

February 11, 2021

How do you fix a problem with–or improve– a culture?

Filed under: Essence and Problem Solving — pemcmahon @ 5:45 pm
Tags: ,

If you would like to read this blog, scroll down to where it says “Blog Text Starts Here.” If you would like to listen to the podcast version of this blog, click on the link and scroll down to where you can select the podcast.

Blog Text Starts Here

A colleague recommended I listen to a recent podcast with Alistair Cockburn [1]

where he says,

“The people who write about methodology don’t know how to talk about culture… so they describe the thing that’s easy to describe which is structure… With Heart of Agile I took away all the structural things.  I only talk about the cultural things; the behavioral things...” 

He goes on to talk about his Spotify Case Study where his client had a problem with dependencies.  Dependencies can be anything one developer needs from someone else to complete a task.  Cockburn gave them a “structural” solution which was to use a central person to manage a spreadsheet which identifies who needs what, from whom do they need it, and a “need by” date. Then they have a meeting every Monday and update the spreadsheet.  But soon after they started to use his solution, one of the Spotify people said:

“I don’t understand why I am sending this information to a central person.  How about if I need something from some person I just let him know what I need and then every Monday we don’t need to have a big meeting.”  

As it turns out the problem Spotify had soon was gone and Cockburn says, 

“My whole consulting went away because I was selling structure and they turned it into culture.”

Listening to this story cause me to wonder:

How do you fix a problem with—or improve– a culture?

Suppose there is something in your culture that is causing trouble in your organization.  How do you go about fixing it?

This reminded me of one of my own client cases which I will now share.

This particular case is a client I started working with many years ago (and still work with today) where we thought they had a problem related to risk management because they weren’t documenting their risks and holding periodic risk meetings to determine mitigation strategies.  Rather than just tell the organization that they needed to establish a more disciplined risk management approach, I asked a few people in the organization what they do when they have a risk.  The common answer was:

“As soon as I know I have a risk I am in the doorway of my manager’s office strategizing a mitigation approach.”

I have always said that a consultant needs to listen to the client first and take the time to observe what is going on because the best solution often depends on multiple factors and often those factors are related to the organization’s culture [2]. 

In this case, what I realized was that while this organization didn’t have a defined risk management process, they virtually lived and breathed risk management. It was engrained in the culture of the organization and it worked.   

So rather than recommend that they change their risk management approach, I recommended that they just recognize what was going on in the organization and train others in the approach.  We even referred to the expected practice in the training as “Doorway Risk Management.”  [3]

This is how we took an effective cultural practice and improved it by sharing it with others in the organization.  We did add a small degree of “structure” to the organization’s risk management culture.  But we were careful not to add any unnecessary, or non-value-added, activities.  

Another point I would like to make in regard to culture is that, while I agree a cultural solution is better than a forced “structural” solution, sometimes a small amount of structure can help fix a culture that has certain weaknesses. 

As an example, going back to Cockburn’s Spotify Case Study, in my experience while the solution Spotify came up with for managing dependencies was an optimal solution since they didn’t need to add the overhead of a Monday meeting, in many organizations that have similar dependency problems, all the personnel cannot be counted on to just provide what is needed to a teammate by a certain date.

Sometimes you need a degree of a “forcing function” (or structure) to ensure priorities are agreed to and accepted.  In these cases the Monday meeting may not be required for all dependencies, but you still may need a short meeting with a few key people for a period of time while the new desired behavior is still being learned.

Robert Martin, in his Foreword to our first “Essence of Software Engineering” book [4], says:

“Software is both a craft and a science, both a work of passion and a work of principle. Writing good software requires both wild flights of imagination and creativity, as well as the hard reality of engineering tradeoffs. Software, like any other worthwhile human endeavor, is a hybrid between the left and the right brain.”

I think there is something in these words that we can apply to the structure versus culture debate.  I believe quality software development requires both culture and structure.  They can and should work effectively together.  I have a practical idea on how to make this happen.  It requires us all to agree that just the right amount of structure at just the right time could be the most practical path to improve a culture– or resolve a known cultural weakness. 

I plan to continue this discussion in my next blog diving deeper into the challenge of applying just the right amount of structure to fix a problem with–or improve– a culture. 

As always, comments are encouraged. 

 [1] https://agilpodden.podbean.com/e/83-agile-manifesto-with-alistair-cockburn/

[2] Certified Essence-In-Use Practitioner Training, https://leanpub.com/c/essence

[3] Integrating CMMI and Agile Development: Case Studies and Proven Techniques for Faster Performance Improvement, (Chapter Four, Doorway Risk Management),  Addison-Wesley, 2011

[4] The Essence of Software Engineering: Applying the SEMAT Kernel, (Foreword, Robert Martin), Addison-Wesley, 2013

January 30, 2021

Teaching the software development life cycle to high school students: Don’t forget to include why they should care

Filed under: Essence and Problem Solving — pemcmahon @ 11:56 pm
Tags: ,

If you would like to read this blog, scroll down to where it says “Blog Text Starts Here.” If you would like to listen to the podcast version, click on the link and scroll down to where you can select the podcast.   

Blog Text Starts Here:

I recently received the following challenge from a high school teacher. He said,

“The goal is to code the Software Development Life Cycle (SDLC) using the Essence language. The result should be easy to understand for anyone, especially those NOT exposed to Essence. The general idea is to Essentialize something like Figure 1. My target is 16 year old students, or people who just started programming on their own.”   

                                                                                        Figure 1 SDLC

Let me start by saying that when I was in high school I wasn’t a great student. One reason was because I didn’t see what good much of what I was being taught was, so I wasn’t motivated to learn.  I almost failed ninth grade algebra.  I had no idea what the x’s and y’s had to do with the real world I lived in.  It would have been nice if this had been explained to me back then, but it wasn’t.  I start with this story because it affects the way I approach any challenge related to teaching students anything.  You have to first give them a reason to care.

Given this background, let me share how I would tackle this challenge today.

I would start by explaining to the students what the diagram in Figure 1 isn’t intended to tell them and then explain at least one practical use of the diagram they might care about.   I would focus first on what this diagram isn’t intended for because knowing what isn’t intended may help eliminate common mistakes. 

I would do this by saying something like:

“First, please don’t try to read too much into this diagram. I am stressing this point first because historically reading these kinds of diagrams too literally has led many software endeavors down troubled paths.   Specifically, the figure is not meant to imply a strict ordering of the software development activities identified on the diagram, nor is it intended to say anything about how to go about conducting the software development activities highlighted.” 

Next, I would explain what the diagram is trying to communicate and I would give a practical example that demonstrates why software developers should care.

I would do this by saying something like:

“The Software Development Life Cycle (SDLC), as depicted in Figure 1, is a simplified way to represent software activities conducted by a team. A team includes all the software developers involved in a software endeavor, as well as at least a few potential users of the software who can represent the views of the wider user community.  The value of an SDLC is that it helps anyone see the big picture, but what you don’t see on this diagram are essentials for software development success that underlie each of the activities identified and that is what you should care most about if you want to be a successful software developer.”

I would then give a few examples of those essentials by saying something like:

“Examples of essentials for success include principles, values, key practices and constraints. An example of a “principle” is Rapid feedback which could mean your team agrees to work in short cycles that include constant team and user communication. An example of a “value” is Courage, which could mean your team agrees to go as fast as they can, while also having the courage to slow down and share with their teammates anything that bothers them that they can’t solve on their own.  An example of a “ key practice” could be to develop tests before developing the code. An example of a “constraint” could be an agreement that there will be only three team members available to complete the entire software system.” 

I would then explain that principles, values, key practices and constraints must be agreed to by all software developers on the team, the software user representatives, and anyone else who your team depends on for help.   And here I would add, just for emphasis, when we look back at troubled software endeavors we often find that the root of the trouble can be traced back to a failure to reach agreement—or to take serious that agreement– on at least one of these essentials for success. 

I would also explain that principles, values, key practices and constraints can– and often do–  change on each software development endeavor.  In other words, you can’t learn just one way to develop good software and expect that the exact same way will work on all your future software endeavors.  

At this point I would slow down and tell them that in the future when they look at this diagram I suggest they try to recall what I am about to say about the essentials underlying each of the 6 activities highlighted on the diagram.  I would then explain the diagram to them in the following way:

Activity 1: Planning Essentials

On all software endeavors there is always work to be done by the team.  To be successful that work must be sufficiently broken down so the team can estimate their effort and commit to a credible (believable) plan.  

Activity 2: Analysis Essentials

When breaking the work down questions will arise that must be investigated and decisions made related to building new software, buying existing software, or reusing parts of existing software. 

Activity 3: Design Essentials

When breaking the work down decisions must to be made regarding hardware platforms (e.g. the computer or smartphone the software will run on), technologies used (e.g. programming languages), and interfacing mechanisms(e.g. how the software will communicateoutside its platform, such as cloud services). 

Activity 4: Implementation Essentials

The system must be tested and demonstrated, first in small pieces, based on the agreed to credible plan.

Activity 5: Testing and Integration Essentials

The small tested and demonstrated pieces must be integrated (combined) together, based on the agreed to credible plan to make sure the system as a whole is fit-for-purpose.

Activity 6: Maintenance Essentials

After the system has been accepted by the users as fit-for-purpose, acceptable defect levels must be maintained and agreed service levels supported.  This means that all defects don’t necessarily have to be fixed, but the critical ones– in the eyes of the users and the team– must be adequately addressed.

I would then point out to the students that the six essentials, as just described, usually occur iteratively (repetitively) within feedback cycles.  The details of these feedback cycles depend on the way of working that must be agreed to by the team as well as those who use or can affect the software system.

Now, let me say a little more about the approach I have just suggested in this blog to explain the SDLC  to high school students. 

First, I chose my words carefully.  The description provided above focusing on essentials underlying each of the six activities can be referred to as an “essentialized” description of the SDLC.  Essentialized means it uses the Essence language to communicate essentials.  

Specifically, information provided on principles, values, key practices and constraints can be found in the Essence Stakeholder, Team and Way of Working Alphas.  When you hear the word “alpha” just think of the important things we work with and want to keep healthy for software success.   Other italicized words in this blog can be found in Essence checklists.  Consistent with the Essence language, the term software system as used in the above description includes both the software and the hardware required to run the software.  This is because software without hardware provides no value.  And value is critical because Essence is a practical framework. It is based on what experienced practitioners have found is essential for success. 

The description of an SDLC provided in this blog is an example of using Essence in “stealth mode.”  For more information on Essence and the rationale for using Essence in “stealth mode” refer to [ 1, 2, 3, 4].

I would like to end this blog by providing a little rationale for the approach I have suggested to teaching the SDLC to high school students.

Using an “essentialized” description to teach high school students the Software Development Lifecycle can help our next generation of software developers avoid common mistakes of the past, and help them maintain awareness of the most important things to pay attention to for success when developing software.

As a final point, you might be wondering why it matters exactly what words, or phrases, we use when talking about software development.  The simple answer is because words matter.  Words are how we communicate, but they can easily be misunderstood.  The words, and phrases used in the Essence language were carefully chosen with the goal to minimize miscommunication and misunderstanding, while highlighting the essentials for success.

Feedback is encouraged.

[1] For more information on the background, rationale, and thinking behind Essence refer to https://leanpub.com/shyboys

[2] For more information on case studies and practical uses of the Essence framework refer to https://leanpub.com/itsallupsidedown

[3] For more information on Essence and Essence in Use refer to www.Essence-In-Use.com.

[4] For training in using Essence in stealth model and as a critical thinking tool refer to https://leanpub.com/c/essence

January 3, 2021

Build a Better Scrum using Essence and the Heart of Agile

Filed under: Essence and Problem Solving — pemcmahon @ 3:46 am
Tags: ,

If you would like to read this blog, scroll down to where it says “Blog Text Starts Here.” If you would like to listen to the podcast version, click on the link and scroll down to where you can select the podcast.

Blog Text Starts Here:

Today, thousands of companies are conducting agile transformations and according to Forbes 77% of those transformations are Scrum [1].  Yet, despite its popularity, according to Jeff Sutherland, co-founder of Scrum, 58% of all Scrum implementations are late, over budget and have unhappy customers [2]. Given these sobering statistics, a natural question we must ask is:

How can we build a better Scrum increasing our chances of success?

At least part of the answer, according to Sutherland, can be found in the Essence framework [3]. Sutherland tells us he has conducted an exercise with thousands of people in hundreds of companies where the participant teams build their own Scrum using Essence Cards [4] and then the teams presents their Scrum to the other teams as in a science fair.

Sutherland says:

“These Essence Cards flush out what is Scrum, what people are doing with it and how it is working…and we now have extensive data showing which parts of Scrum are implemented well,  which are implemented poorly,  and which are implemented not at all…  And on the average we find that about a third are implemented well, a third poorly, and a third are not implemented at all…. Essence immediately flushes out where the problems are, and then the next question is how can we use Essence to fix it?” [2]  

As a simple example of how Essence can be used to fix these problems Sutherland tell us one common problem you have in a vendor/customer relationship is who is responsible for what… By laying the cards out on the table and asking what the customer is responsible for, what the vendor is responsible for, and what do they jointly have to work on together, success rate is significantly increased.

Sutherland is not the only leader in the Agile movement looking at ways to fix common problems with Agile teams.  Alistair Cockburn, one of the authors of the Agile Manifesto has observed similar issues with Scrum, stating:

Scrum is pretty good.  It has very few rules, but it doesn’t tell you if anything goes wrong how to fix it.”  [5]

Cockburn, who believes that Agile has become overly decorated, has started a new initiative referred to as the “Heart of Agile” (HOA) in which he focuses on just four words—Collaborate, Deliver, Reflect and Improve [6]  The focus of HOA seems to be on the human or emotional side of software development.  Cockburn told me:

“If you see me emphasizing the human component more and more it’s because my experiences show it affects success more than other things.” [7]

The importance of the human dimension in software development success is supported by my own experience and the experiences of others working as SEMAT [8] volunteers on the development of Essence. In one of our Essence working group meetings we heard:

“The reason Scrum works so well is because we have come a long way on the technical side; how to develop requirements, how to design, how to test.  But it is the team side where we have been lacking and where Scrum fills a big hole.” [7]

While Scrum has helped many teams become more successful in areas such as collaboration through practices including Daily Standups and Sprint Reviews, the HOA initiative seems to be poking at a deeper underlying human issue.  One place you can learn more about it is in the first five minutes of a talk Cockburn gave in 2019 at a Lean Conference in France. [9]   

He starts this talk by saying he wants to make one small correction related to Agile, based on what he heard others saying at the conference the day before.  He then says:

“…Others put their energy into processes and tools and documents and plans, whereas the ‘magic’ is actually the way people interact with each other…. The magic comes from the movement of ideas between minds…”

 He goes on to say that the value that many people leave off when they summarize Agile is the very first value of the Manifesto and it is the one he is most proud of

“Individuals and interactions over processes and tools”  [10]

What struck me listening to this talk wasn’t so much what was being said, but rather the implications to successful software development. I was certainly aware of the Agile Manifesto Values, but I hadn’t previously given a lot of thought to the consequences of not emphasizing the values when people try to communicate what is essential to Agile.  

In the Essence language, the Pattern construct is used to reflect Values.  As an example, in Scrum Essentials, the Scrum Values are captured on an Essence Pattern Card. [4] Refer to Figure 1.

Figure 1 Scrum Values Pattern Card   

Those values, as depicted on the card, are:

  • Commitment
  • Courage
  • Focus
  • Openness 
  • Respect 

Note particularly the words on the card preceding the five values:

Successful use of Scrum depends on people living the five Scrum values.

These values are clearly an essential element to the successful use of Scrum, but in my own experience– and I would bet in the experience of many of those involved in the poor Scrum implementations referred to by Sutherland that– the essential values are too often not implemented well.

Reviewing the essential values of agile caused me to reflect on the fact that values must be lived, not just written down. It also caused me to reflect on just what the heart of agile is. 

From the Heart of Agile website [6] we learn that HOA is actually a “community of ideas” and that:

“The community forming around the Heart of Agile is what is interesting these days. People exploring better ways to collaborate, to communicate, to probe, to learn, to reflect, and to have more fun at the same time as having more impact.“

It occurred to me while reading these words that the degree to which teams truly “live” their values often has a significant impact on the success of a software development effort.  This also caused me to reflect on just how HOA might work effectively with Essence and Scrum.  To aid this reflection I recalled something Ivar Jacobson, the primary visionary behind Essence, once said to me, and that is the fact that practices are not just static descriptions. They are what we do! They are alive! 

More specifically, Jacobson recently said:

”…it is high time for a new paradigm. Where practices can be explored, experimented with, adopted and adapted interactively, in the same space where teams plan and execute their work, and continuously inspect and adapt their working practices.” [11]

The value of Essence is that it provides a reference framework that gives users the freedom to compare, and mix practices and patterns to form the best solution for their specific situation. Thinking of Essence this way brings me back to Jeff Sutherland’s exercise and something we all can do, particularly anyone reading this blog who believes they can implement a better Scrum. 

We can all conduct our own ”Build a Better Scrum” exercise similar to the exercise Jeff Sutherland referred to.  If you are one of those organizations that may be implementing Scrum poorly, or failing with Scrum, I suggest you download your own set of Scrum Essential cards [4] and conduct your own Build a Better Scrum exercise.  And when conducting this exercise be sure to pay close attention to the values your team holds giving particular attention to not only the Scrum Essential Values, but also HOA patterns, such as the one that captures the first value of the Agile Manifesto. 

You can use the Heart of Agile along with Essence to help your team build a better Scrum by bringing back the focus on the real essentials—including the values– to successful software development. 

Comments are encouraged. 

[1] https://www.scrumalliance.org/ScrumRedesignDEVSite/media/Forbes-Media/ScrumAlliance_REPORT_FINAL-WEB.pdf

[2] SIGSOFT Seminar, April, 2020, https://essence.ivarjacobson.com/videos/better-scrum-essence-jeff-sutherland-and-ivar-jacobson, Refer to 14, 26 and 28 minutes into presentation

[3] https://essence-in-use.com/

[4] https://pages.services/ss.ivarjacobson.com/essential-scrum

[5] https://www.youtube.com/watch?v=xDlz6mEm-7I, Refer to 38 minutes into presentation

[6]  https://heartofagile.com/

[7] https://leanpub.com/shyboys, Refer to Epilogue and Chapter Five.

[8] SEMAT stands for Software Engineering Method and Theory. Refer to  www.semat.org for more information.

[9] https://www.youtube.com/watch?v=sr5wfygbY7k

[10] https://agilemanifesto.org/

[11] https://www.linkedin.com/pulse/live-guidance-revolution-software-development-ivar-jacobson/

December 20, 2020

Using Essence to Teach Software Practitioners in Industry

Filed under: Essence and Problem Solving — pemcmahon @ 7:23 pm
Tags: ,

A few weeks after the keynote address I referenced in last week’s blog, I gave a talk at the 5th Essence Education Forum (EEF).  The title of my talk was: Using Essence to Teach Software Practitioners in Industry

In this talk I explain what is different about teaching software practitioners in industry from teaching university students.  I also motivate why university professors might want to consider the approach I use in industry to better prepare our university students for the challenges they are certain to meet.

You can listen to my roughly 27 minute talk using the link below.  As always, feedback is encouraged. 

December 10, 2020

An Industry Perspective on What We Should be Teaching Our Next Generation of Software Practitioners in the Universities

Filed under: Essence and Problem Solving — pemcmahon @ 8:56 pm
Tags: ,

Last month I gave a keynote address at the 1st International Workshop on Essence in Education and Training (WEE&T’20)  conducted as a part of the 32nd IEEE International Conference on Software Engineering Education and Training (#cseet2020).  This conference was conducted virtually from Munich Germany. 

To access a video of my 10 minute talk:

You can learn more about the conference and the workshop at:

August 19, 2020

The single most important software team success factor reinforced by two software engineering giants

The single most important software team success factor, and one I always share relevant stories about when coaching software teams, is the need to create an environment where all team members feel safe in raising any issue that bothers them—even small ones.  This essential for success is captured in two Essence thinking framework checklist items from the Team Alpha, Collaborating State:

  • Communication within the team is open and honest
  • The team is working as one cohesive unit

The importance of this factor was reinforced for me through recent interactions I had with two software engineering giants—Alistair Cockburn and Larry Constantine.  Let me share a little about these experiences.

After I completed the initial draft of my “Shy Boys” book [1] in July, 2019, I asked Alistair Cockburn if he would review the book and let me know if he was okay with what I said. He quickly got back to me letting me know he was fine with all the parts that mentioned him.  I share quite a bit about Alistair and his focus on the people side of software engineering in the book. Later that day while on a plane he read more of the draft book and sent me another email saying:

“It occurs to me that what drives me is this question: ‘What leads a team to a higher likelihood of success?’ If you see me emphasizing the human component more and more, it’s because my experiences show it affects success more than other things.”

Larry Constantine also got back to me after reading the book saying:

“I would like to set the record straight on a couple of matters.

 First, I did not say that Ed Yourdon and I ‘missed the people side’ when we were developing structured design (and later structured analysis). What I did say in Zurich (and on other occasions) was that Ed and I left out design of the human interface (along with database design). It had always been my intention to make the original book comprehensive, but we ran out of time, our hand being forced by the publication of the IBM Systems Journal article and the threat of being scooped by Glen Myers. Moreover, the concepts of interaction design and the user interface were hardly well developed at that point. We also concluded that others were doing a fine job on database theory and architecture, so we went with what we had. Of course, as you know, I did return to interaction design and the human interface later.

 The reality is that, from the beginning, everything I did in the computer field was about ‘the people side.’ My thesis at MIT was on the psychology of computer programming; the conceptual basis underlying coupling and cohesion is rooted in cognitive complexity theory; and the graphic models were obviously all devised for the people doing design and engineering of software, not for the computers. Ed and I had always been highly focused on the people side of software engineering and were instrumental in spreading such key ideas about project organization as Conway’s Law and Mealy’s Law.”

For those who may not be familiar, Conway’s Law states that:

“Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.”

What I find most interesting about this law/principle (and relevant to this blog post) is the fact that two distinct organizations with differing communication structures are likely to have conflicting preferred design approaches and collaboration difficulties.  I observed this phenomenon first-hand on multiple occasions with clients and I have written about it extensively in numerous publications. [2]

Recently, I got thinking again about the challenges of getting people to work well together as I listened to an interview Alistair Cockburn did with Richard Atherton in April, 2019. [3]

About 38 minutes into the referenced interview Alistair shares part of his theory of software engineering and how you can develop explanatory and predictive models using levers you can touch to influence project success.  In the middle of this discussion he hesitates and says:

“And what I love is that the lever you can’t touch is human personality.”

After explaining what he means by this with a few examples, he goes on to say:

“The question in my mind is how do you simplify so its actionable?… Scrum is pretty good.  It has very few rules, but it doesn’t tell you if anything goes wrong how to fix it. SAFe went the other way and added a bazillion rules that are very very hard to follow, but claims to be complete….

So, what I did is reduce all of this to just four words Collaborate, Deliver, Reflect and Improve… This is not going to surprise you…. As people collaborate better, things go better, as people collaborate worse, things go worse…  That’s not rocket science.  It’s astonishing how quickly we forget it.”

What I particularly like about this part of the interview is that Alistair goes on to explain why people quickly forget the importance of collaboration. He does this by connecting collaboration to things we don’t always think of as collaboration, like fear and trust.

Then he asks: “What are people afraid of?”

His answer is:  They’re afraid of looking bad, not getting a raise, getting fired, not getting their idea implemented and on and on…

And he goes on to explain further that the root of the problem often isn’t in process, but it’s in things like Executive bonuses and human resource appraisal systems which often fail to consider effective team collaboration.

This all made sense to me based on my own experiences, but it also caused me to reflect on my own approach to this challenge with my own clients which I will explain in a moment.

Alistair then tells a brief story about a client who said to him:

“Alistair, … Tell me what to tell the bosses to tell the troops.” 

Alistair replies:

“I am not going to tell you anything… I am going to dialogue with you about how to dialogue with your bosses about how to dialogue with the people… We are trying to create a culture of listening… The Execs should dialogue with the people to find out what they know…”

Alistair’s client replies:

“I’ve been trying that but the Execs tell me I’m not here to dialogue with you. I hired you to tell me. You are the expert. Tell me.”

Alistair then says,

“That’s fine. That’s not your client. You don’t have to have all the clients in the world.  If our tone is dialogue based, people will self-include and exclude… Today more and more people in the world are growing up in dialogue, rather than edict.”

This part of the interview particularly resonated with me, as it caused me to reflect on my own thinking when I started my consulting business in 1997.  At that time I wrote the following words that still remain true 23 years later and are still on my website:

“If when you think of a ‘consultant’ you think of someone with real project experience who can come into your organization, understand your key issues, and give you the kind of help that pays high dividends rapidly, then one could refer to our services using this term.  We often don’t use this term because too often it conveys a notion of examining a client’s problem from a distance –and then telling the client what they should do… We work directly with our client’s team first understanding their strengths…We share with our customers practical techniques that make sense in today’s challenging environment.” [4]

The key point here relevant to this blog post is to listen first.  Then I operate more in what I think of as a facilitator of dialogue (rather than a “consultant”) helping the client discover their own best solution.

The reason I take this approach is because when the client discovers their own solution they are far more likely to own it, and believe in it, and implement it leading to a lasting solution. I have also referred to this approach in other publications and training courses as using Essence in “Stealth Mode” [5, 6, 7]

One example of a practical technique I have shared with clients to improve collaboration is to enhance their appraisal system by using inputs from teammates and customers when appraising personnel. When team members know their appraisal and potential salary is tied to how team members view them, their attention to team collaboration often improves rapidly. Whatever is measured gets attention.

These recent reflections have led me to start thinking again about what we should be teaching our next generation of software professionals, in particular with respect to organizational cultures, collaboration and essential team skills.

It seems to me, at a minimum, we should be making them aware of the existence of varying organizational cultures—such as organizations with cultures of “just follow the rules” and those with cultures that encourage  “listening and dialogue.”

These differences, of course, aren’t new.  They existed 50 years ago and although more and more of the world seems to be moving toward the “listen and dialogue” approach as Alistair has observed, I suspect these differences will continue to exist for many years to come.

[1] https://leanpub.com/shyboys

[2] Numerous stories of conflicts arising when organizations with differing communication structures and cultures attempt to collaborate can be found in my Virtual Project Management book and related articles. Refer to http://pemsystems.com/distributedteams.html

[3] https://www.youtube.com/watch?v=xDlz6mEm-7I

[4] www.pemsystems.com

[5] For an example of  using Essence in stealth mode refer to https://paulemcmahon.wordpress.com/2019/05/16/using-essence-in-stealth-mode-to-help-solve-a-cybersecurity-challenge/

[6] For online training in using Essence as a thinking framework with numerous examples of using Essence in “stealth mode” refer to https://leanpub.com/c/essence

[7] For more general information on Essence refer to www.Essence-In-Use.com

July 3, 2020

How to get better at transforming a job you don’t like into your dream job

Next Page »

Blog at WordPress.com.