Tag Archives: Change

IFPUG (News) Beyond MetricViews – FP for Agile / Iterative S/W Dev


With the support of QSM, Inc., I wrote and published this article on a new area of the International Function Point Users Group (IFPUG) website called “Beyond MetricViews.”

While the IFPUG already had published guidelines in this area, the key points to this article include:

  • If you want to measure productivity (or anything else) consistently across two or more software development projects – where each was developed using a different approach (i.e., waterfall vs. agile) – one must be consistent in the definition and application of the measures (and metrics);
  • Function points are defined in terms of elementary processes and agile methodologies deliver such functions iteratively (not complete in one iteration) – posing challenges to the uninitiated;
  • Regardless of whether you measure productivity, defect density (quality), costs or other aspect of software delivery – it is critical to do an “apples to apples” comparison.

Here’s the article (click on the image) for your interest.  (You can also visit the blog at www.qsm.com for details.)

ifpug

Comments and feedback is appreciated!

Advertisements

No free lunch in Software Estimation and Benchmarking


I’d love to have comments on my latest QSM blog post of the same name… read more

22 no free lunch

Whats behind Project Success: Process or People?


Depending on who or what you read, most software and systems projects (over 50%) end up as unsuccessful/failures:  over budget, late, and/or fail to meet the user needs.  As a worldwide phenomenon, studies continue to expound on why projects fail (poor requirements, underfunding, overoptimistic estimates, unreasonable schedules, lack of management commitment, etc.) but few studies focus on what it takes for projects to succeed.

What do you think makes a project (of any kind) successful?  What is more important to project success:

1. The processes involved (e.g., formal project management, standards, shortened development life cycles, agility…); or

2. The people involved (e.g., the right team makeup, a good mix of skills, a motivated workforce, engaged users); or

3. Trust (e.g., collaboration rather than negotiation between customers and suppliers, reliance, cooperative teamwork; communication); or

4. Something else (e.g., other factors such as CMMI, tool sets, unlimited budgets, Steve Jobs on the team, …); or

5. Some “magical” combination of the above; or

6. None of these?

Across industries and across the world, is there a difference in what makes a project successful?  Are there certain factors that predispose a project for success (or failure?)

What do YOU think?  Inquiring minds are interested in hearing from you… (please post a comment or send me a private email to dekkers (at) qualityplustech (dot) com).

Thank you!
Carol

Common-sense Leadership: Respond not react…


A big benefit to teaching leadership and communication workshops to adult professionals is continuous learning: every time I teach a class, new revelations come into focus.

One such “aha” moment (where one realizes something that may not have been obvious before) is that Leadership is really about learning to Respond to a situation or stimulus instead of automatically Reacting.  Why is this important?  Responding is the thought intensive process of actively listening, pausing, and then gathering ones “thoughts” before speaking.  Gathering of one’s thoughts involves the neocortex (center) of the brain whereby we override the reptilian (instinctual) brain and the limbic (emotion-induced) brain, and hopefully create a response less prone to immediate and autonomous reactions (based on instinct or emotion).

Considering how eastern cultures (such as Japan) seem to habitually pause before asking questions at a conference or before coming to an agreement gave me “pause” to reflect on how this practice conveys power and respect – and is one often used by practised politicians at press conferences.  This results in less “eating one’s premature words” and less damage control as opposed to when one speaks too hastily or without due thought.

This is a common-sense tip on how to practice better leadership in your own workplace no matter your position:  remember and practice active listening (if you are thinking of what you are going to say – you are not listening!), pausing, gathering your thoughts (and perhaps even saying “please give me 15 seconds to gather my thoughts”) and then thoughtfully responding.

Food for thought – what do you think?  Could this be helpful in your workplace?

Carol

Whose job is IT anyways?


The title was a purposeful play on the acronym “IT” (information technology) because there is often no one person who takes responsibility for failed IT projects. In addition, it is not as if there are not project failures everywhere.

Notwithstanding one of my least favorite (but often quoted) research studies, the Chaos Report cites that about one-third of projects are successful when it comes to IT.  What gets in the way of project success?  Lots of circumstances and lots of people!

When a software intensive project fails, there is no lack of finger-pointing and blame sharing – yet seldom do teams stand up and confess that the failure (over budget and behind schedule and failing to meet user needs) was due to a combination of over and under factors, along with fears:

  • overzealous and premature announcements (giving a date and budget before the project is defined);
  • over optimistic estimates of how quickly the software could be built;
  • under estimation of the subject complexity;
  • assumptions that the requirements were as solid as the customer professed;
  • under estimation of the overall scope;
  • under estimation of how much testing will be needed;
  • under estimation of how much time it takes to do a good job;
  • under estimation of the learning curve;
  • under estimation of the complexity of the solution;
  • under estimation of the impact of interruptions and delays;
  • over anticipation of user participation;
  • over optimism about the availability of needed resources;
  • over optimism about hardware and software working together;
  • over optimism about how many things one can do at once;
  • risk ignorance (“let’s not talk about risk on this project, it could kill it”);
  • over optimism of teamwork (double the team size doesn’t half the duration);
  • fear of speaking up;
  • fear of canceling a project (even if it is the right thing to do);
  • fear of pointing out errors;
  • fear of being seen as making mistakes;
  • fear of not being a “team player”;
  • fear of not knowing (what you think you should);
  • fear of not delivering fast enough;
  • fear of being labeled unproductive;
  • fear of being caught for being over or under optimistic.

Therefore, I ask you, on a software intensive IT project, whose job is it to point out when there are requirements errors, or something is taking longer than it should, or it is costing more than anticipated. In traditional waterfall development because there’s so much work put into the planning and documenting of requirements, pointing out errors are  either no one’s job or the team’s (collective) job which really relates to no one’s job.

Often it is easier (and results in less conflict) to not say anything when the scope or schedule or budge go awry on a software project. Yet it is this very behavior that results in so much rework and so many failed projects.

Agile and Kanban projects are different

Several of the advantages to using Kanban and Lean and Agile approaches to software and systems development is that the methods address the very items outlined above.  Building better software iteratively becomes every developer’s job rather than no one’s:

  • Fear of pointing out errors is removed because the time that goes into a scrum is days and weeks not months (so participants don’t get defensive about change);
  • Over and under optimism remains but is concentrated on smaller and less costly components of work (i.e. days instead of months or years);
  • Risk is not avoided or ignored because we are no longer dealing with elongated and protracted development cycles (spanning seasons);
  • Assumptions come out with better and more frequent discussions;
  • Over optimism about how many things one can do at once is removed because Kanban limits the amount of work-in-progress;
  • Under estimation of the impact of interruptions and delays is minimized because such factors are addressed in Kanban;
  • Over anticipation of user participation is managed through direct user involvement.

What do you think?  Join us at the Lean Software and Systems Consortium conference LSSC11 from May 3-6, 2011 as participants and speakers address the best ways of advancing software and systems methods including Lean, Kanban, Agile and other exciting new ways to deliver high quality software more efficiently and effectively.

These newer approaches make it easier for everyone in IT to make it their job to build better software.

Wishing you a productive week!

Carol
@caroldekkers (twitter)

Share

The importance of Being There (at work)!


Did you know?

Only 26 percent of IT employees in North America are fully engaged at work, while 22 percent are actually disengaged, according to a global study by consulting firm BlessingWhite.

Being there…

At a time when unemployment is at an all-time high, only one-quarter of IT workers are fully engaged or Wowed by their work, while the remaining 75% just go through the paces or don’t care at all.  When you consider specific industries fraught with frustrations of rework (exceeding 40% in some areas) and impossible deadlines such as in waterfall development, I would bet the excitement factor of going to work is even less.

#Kanban, #Lean, and #Agile communities are exceptions

The Agile Manifesto recently celebrated its 10th anniversary last month, and Kanban, Six Sigma, Lean, and Agile methods now share space with waterfall as leading methods in the software and systems development space.  Agile (in my humble opinion) was one of the first to restore a sense of sanity in software development.  In earlier times, a group of  business customers with rapid fire changing requirements would challenge software developers (tired of the constant change and “jello” like demands) for amorphous software products.  The result too often – failure.

It makes sense, in this type of environment, to do iterative development.  It was illogical to do the opposite: long development cycles to produce products already obsolete before they hit desktop computers.

Approaches like Kanban, Lean, Agile, Personal Kanban and others continue to transform our industry and inspire software developers to become “fully engaged” in the work.

Less head banging… but you have to engage

Certainly there is head banging and more job satisfaction in this new world (if “tweet volume” is any indication, the Kanban/ Lean/ Agile communities are a happier lot!) but it takes commitment to show up and be part of the action.

I believe that the Kanban and Lean and Agile communities know the importance of really being present and engaging at work.  We also know it is critical to create a community of like-minded people who meet in-person – at conferences, local meetings, at social events.

LSSC11 is coming soon!

The landmark Lean Software and Systems conference is only 10 weeks away in Long Beach, CA on May 3-6, 2011.  Make your choice of conference to attend in 2011 the LSSC11 (especially if you can only attend one!)  See my related post Top 10 Reasons to attend LSSC11.

Join the movement of people who know the Importance of Being There in software and systems development: The Lean and Kanban and Agile communities.  I hope I will meet you at LSSC11!

Have a Wow! and engaging week at work,

Carol

Share

Pre-flight email checklist: THINK before you click…


I AM OVERWHELMED BY EMAIL!

There I said it, I am overwhelmed with email and I can’t stand it!

I thought I was the only one until I read Tim Tyrell-Smith’s post today: How to reduce the Quantity of Incoming Email and realized that there should be a pre-flight email checklist to save our sanity… and to encourage Thinking before Clicking!

Since joining the world of social media I realize my “connectivity” has grown exponentially, but not all in a good way. Even with my SPAM filters set to high, I get so much email that it is overwhelming!

I feel like I must have ADD (attention deficit disorder) because my day is interruption after interruption (sorry TweetDeck!) and I need help (and I know I am not the only one!)

Pre-flight email checklist (THINK before you click):

  1. If it takes longer to write an email (to one person) than it does to walk across the hall / call the person, don’t write an email. Pick up the phone or get up from your desk.
  2. If multiple people are involved and you need responses, consider whether a one hour meeting would work better than filling up in baskets with back and forth threads for the next 2 weeks.  If so, schedule a tight meeting and solve the issue in one fell swoop.  (Just because it doesn’t take paper doesn’t mean email is green — it can litter cyberspace!)
  3. If 1 and 2 are not possible, consider other options: Twitter or a blog post or an update at a staff meeting might be better than email.
  4. You’ve thought through 1,2 and 3 and decide your message needs an email.  Never negligently click “Reply all!”  unless you’ve gone through these same steps:Make sure you set aside a dedicated time (10 minutes minimum) to THINK before you click:
  • Consider your recipient: Walk for a moment in their shoes and think: what would be your response to this email? Make sure to emphasize the key points (i.e., make the reason for the email crystal clear). Do not “assume” that everyone shares your knowledge so give necessary background.  In the words of Peter Drucker:  It is important to state the obvious otherwise it may be overlooked.
  • If you expect/need a response, be clear about it. Tell recipients what you need from them (each), by when, and how (call, email, comment, decide…).
  • If it is an information only email, say so. No one has time to read your mind.
  • Consider using the subject line as a filing cabinet: Use tags to identify topics and intent. E.g., ABC Department meeting notice, Feb 17, prep material attached; or Dekkers: Blog Marketing draft – comments needed by Feb 20, 2011.  In this way, recipients can quickly find YOUR email from a pile in their in basket.
  • Consolidate information! If the email is about a meeting: include dial-in information (top and center for easy access!), meeting date and time, and  attach all preparatory material all together in a single email. There is nothing worse than having to pull up 3 emails to get ready for a single meeting!
  • Preview before sending: Spellcheck, attach files, check all recipients are included.
  • If there is emotion involved save the draft email and wait a full day (or at least an hour) before doing the doublecheck and send step below.
  • If it’s a regular email (non-emotional), take a one minute break – stand up, look out the window, anything to clear your head. Then go back and re-read your email, double-check attachments, recipients, bcc’s etc.
  • When you are sure it looks right consciously hit “send”. NEVER hit send when you are multi-tasking (i.e., on the phone). Once an email has been sent it is in cyberspace FOREVER (regardless of rescinds!)

I plan to follow this checklist starting today! What do YOU think? Do you have any additions?

p.s., DON’T forget to sign up for my Feb 17, 2011 (11am – 12:30 pm EST)  FREE Webinar:  Navigating the Minefield – Estimating before Requirements.

Register here: http://tinyurl.com/6flgjwr

To your increased productivity!
Carol

Share

Superheroes in IT, come down to earth…


Are you a technology superhero?  Then you might want to read this (and even comment!)

Information technology is a widely misunderstood part of business:  executives view us as a necessary evil, yet do not understand  IT is an investment.  As technology professionals, we lament our treatment as suppliers (or even servants) instead of business partners, and spin our wheels trying to prove that we add value to the business. What we fail to see is that we unwittingly contribute to the dysfunction with a superiority complex that we project on the business.

We view ourselves as technology superheroes, while the rest of the world sees us as overpaid intellectuals lacking in social skills.  There is no right or wrong here, just misunderstanding on both sides of the relationship.

The Superhero World

As software engineers, it is hard to imagine that the world thinks any differently than we do.  We take for granted how we learn, digest and embrace new concepts, so much so that we assume it is universal.  Certainly, we recognize genetic individuality, but we assume thought patterns are common. When we assimilate new ideas easily, we assume that others can too. We reinforce our beliefs by seeing co-workers behaving the same as we do.

This is a major issue in IT and engineering (and other professions as well) where success hinges on clear communication and a shared understanding of business needs. As software engineers and product developers, we live in an insulated world – one laden with technical terms and concepts, and life as we know it can be exciting!  We are the superheroes in IT – we use Kanban, Lean, and Agile to get close to our customers and we develop advanced software solutions that make the world better in a single bound.  Or so we think…

The world would be perfect if we could concentrate on doing what we do best – building great software solutions – without interference from the outside world. The problem is that we have to deal with “mere mortals” in business, and for some reason we are simply not on the same page. Herein lies the problem:  our assumption that the world thinks the same way that we do.

As superheroes in the IT world, we ARE different, but we need to function in the real world.  We are addicted to technology but others are not… so who has the problem and what can we do about it?

First steps…

The first step in solving any problem is to admit that it exists and take responsibility for our part.  This means taking a hard look at our role and what we can do to change the dynamics of the business / IT relationship.

Here are a few ways that we can take responsibility for improving the relationship:

  • Realize that the way we look at the world is not universal. As software engineers our passion for technology is hardwired, just as others are hardwired with passion about banking or marketing. My professors (and maybe yours) taught that everyone aspires to engineering and computer science, but few can make it, and this created an elitist view of the world.  I now know how this attitude projected a sense of superiority and entitlement to special respect that is simply, undeserved. Recognizing these differences is the first step to humility and true communication.
  • It might sound impossible but… technology IS intimidating.  Moreover, the subject can be boring to others. The world does not share our zest for IT English – we may be superheroes when it comes to creating technology solutions, but that does not make it interesting to others. While it might seem like “dumbing down” when we translate IT English into business English, there is no other way.  If we continue to talk our talk without consideration of others – well, we sound unintelligible.  (Just watch an episode of the TV show “Big Bang Theory” for a glimpse of how techies seem to the world).
  • There is no base level of idiocy. Many technical professionals believe that there is a base level of knowledge idiocy.  In IT, we dismiss anyone as an idiot whose technical knowledge is below this “line” and then treat him/her as a lesser being. While we do not necessarily do this consciously, it comes across in the way we talk down to non-technical people.  Sure, doctors do this, lawyers do this, and software engineers do this, but it does not promote good relationships on projects. The sooner you realize that your basic level of knowledge (such as knowing about the software development life cycle or communication protocols) is above the general population, the better off you will be.  While you and I might be aghast to realize how little most people know about software concepts, they do lead successful and productive lives without this knowledge.  We are the idiots if we cannot translate IT English so our customers can understand, not the other way around.
  • Read outside your world. If we want to understand how our customers think, we need to explore outside the world of technology. Find out what journals your customers read, and pick up a copy. When you start to understand what your customer’s world is all about, you can start to solve their problems.
  • Accept the world that is. Engineers are known the world over as being great at technology and poor at communication.  Instead of denying this fact and defending ourselves, we ought to accept it, improve it, and move forward.  Communication and soft skills can be learned, but we first have to admit that we need help.  I know many software engineers who behave as ostriches by burying their heads in their work and avoiding customer contact.  Why not accept the world as it is and improve on it through education?  Ignorance is bliss except when it comes to communication – and the good news is that communication can be learned.

If we want to garner respect for the IT superheroes among us, we need to come down to earth and live among the “mere mortals” (non-IT).  Only then can IT save the world.

What do you think?  Agree or disagree? Comments?

Carol

Share
//


Separated by a common language… IT English is different


I am not a stupid person, but I simply cannot keep up with all the new information technology (IT) terminology!

I know that every industry has acronyms and terms, but it seems that IT artifactis unique: every time a new methodology comes in, English words are redefined.  Today, IT English is expanding.

For example IT English uses Scrum (but not for rugby), Ruby (not for birthstones), Java (without caffeine), and Artifacts (but not from Egypt).  Certainly, English English is different from American English and Australian English, but IT English is a dialect unto itself.

If I, as an engineer with experience in IT, am daunted by the ever-changing IT English, how much worse is it for laypersons who work on software projects?  It can be intimidating.

I read an “introductory article” written by an IT colleague today and had to read and re-read it several times before I gave up. Despite visual aids and process flows, I felt I needed a geek-to-English dictionary to make sense of it.  (Yes, it was written in English.)

Most of us are not bilingual, so it should be no surprise that many technology professionals only know IT English. In fact, some do not even realize that there are other English dialects. When engineers find a new way to do things, you can expect a flurry of new acronyms and variations on IT English.

This happened with “waterfall”, client/server, web development, agile, lean, and Kanban. Once you understand that old words get new meanings, it all makes sense, but it is a learning curve every time.

Do you know that everyone (outside of IT) asks

Why can’t IT just speak English?

Outside IT, it’s no mystery why software projects fail (to meet user needs).  Just when users and the business learn enough IT English (technology) words to converse, a new method comes in and the dialect changes.

In my post earlier this week (IT’s all about the people, stupid), I touched on the need for “soft skills” in technology, and mentioned the communication factor.  Soft skills or EQ (emotional intelligence quotient) covers more than communication (such as empathy, consideration, mutual respect, cultural sensitivity, communication, and a host of other people skills), but communication is the linchpin.

My first IT English “encounter”

I’ll never forget my first engineering job in Alberta, Canada working for a pipeline engineering company. During the first week, a colleague suggested that I should “sign on” to the mainframe.  I gave him that “are you nuts – why would I want to do that and have to call IT?” look and walked away shaking my head. No one in his/her right mind would purposely “interface” with IT unnecessarily.

monitorAs luck would have it, I found myself working in IT a year later. On my first day, I had to sign on and predictably, the system crashed within an hour.  I became the network operations’ comic relief when they asked me my terminal address and I responded that I was on the eighth floor. Over muffled laughter, they told me they needed the 16-digit number on the side of my terminal (monitor)… and added that they were also on the 8th floor.

I had no idea that my English fluency would be so tested in IT.  While I knew that English is the language that separates so many across countries, I didn’t know it also was true with IT.

What is the solution for IT English?

misunderstandIf we truly want to make progress with technology, we need to recognize the walls that IT English puts up around us.  It’s not enough to know that there are walls and to converse with each other – we need to care about the misunderstanding that arises whenever we redefine English words and expect the world to understand.

IT needs to stop talking in acronyms and start translating our IT  English into English English or American English (a dictionary or savvy translator can help) so that when we talk technology, others will listen.

That is, if we truly want to communicate with the business.  It reminds menapoleon of the English Channel Tunnel (Chunnel) project:  did you know that it was originally started by Napoleon over a hundred years earlier?  The project stopped when Napoleon realized that the tunnel would not be a one-way deal…

What do you think? Am I being too cynical about IT?  Is there hope for IT English to become mainstream or vice versa?

(Fade to black with the strains of Dr. Doolittle’s “I want to talk to the animals…” )

Have a productive week!

Carol

P.s. Don’t forget to register for the #LSSC11 FREE Webinar series – Feb. 2, 2011 (noon-1pm PST — 3 -4pm EST!)  Session #1: INTRODUCTION TO KANBAN with Janice Linden-Reed. Register here: http://tinyurl.com/69ae36w

Share

IT’s all about the People, Stupid…


(Note to self: Remember Mark Twain’s quote – If I had more time, I’d have written less…)

It seems apropos to use this headline to illustrate soft skills’ importance in software development (the 1992 Clinton presidential campaign coined the originalIt’s the economy, stupid).

What do you think?  Do technology skills trump people skills in IT (this was the traditional engineering approach)?  I believe that people skills are at least as important – if not more important – than the hard methodology or coding skills.

I believe that the lack of people skills are at the root of several issues in IT today, unless you work on projects for unknown customers, such as the story this week in the NY Times: Can Apple Find More Hits without its Tastemaker:

Steve JobsShortly before the iPad tablet went on sale last year, Steven P. Jobs showed off Apple’s latest creation to a small group of journalists. One asked what consumer and market research Apple had done to guide the development of the new product.

None,” Mr. Jobs replied. “It isn’t the consumers’ job to know what they want.”

“IT would be easier without the people”

One of my first MIS projects as a programmer was memorable for two reasons:

  1. It was the first time I heard the phrase above; and
  2. My boss made a deal to get sponsor sign-off on requirements by promising that he (the sponsor) could change anything down the road that he didn’t understand.

It was a project from hell (change running rampant) and it was the first time I truly realized that we go into computer science and engineering because we are good at technical subjects, not communication.  Back then, waterfall development was essentially done “over the fence” with the business throwing the requirements over to us, we doing the design and build, and then us throwing the finished software back to the business for testing. More often than not, our “perfect” software missed the mark in terms of functionality, and was typically late and over budget.

Certainly much has changed with the new approaches – can you imagine software development without regular end-user contact?

How much rework is people-based?

CalendarDoes it surprise you to learn that software development is fraught with rework – in traditional settings it is close to 40%?  This means – literally – that we do great work every Monday, Tuesday and Wednesday, and then get to redo it all every Thursday and Friday.

Thanks to Kanban, Agile, Lean, Scrum and other customer-focused methods, our industry is getting a lot better at reducing rework, and at identifying non-productive wait times/delays from customers and others. We are also better at knowing how to deliver incrementally to customer needs. Augmenting the new approaches are job roles specifically tasked with customer facing such as business analysts, project managers and user advocates or scope managers. Some might argue that these roles are inconsistent (or even counterproductive) with Lean or Agile approaches, but that is the topic of a future post.

Regardless of approach, however, engineers and computer scientists are no fundamentally different today than they were in the days when I attended college.  We choose these professions because we love math, science and technology, have a reasonably high-IQ, and want to make a difference in the future of the world (at least that is my excuse!)  People do not go into engineering or computer science for the people skills.

Sure, there is a growing recognition that both engineers and computer scientists must have good people skills when they enter the workforce, however, soft skills training is still secondary.  Soft skills remain some of the most elusive and necessary skills in software and systems development.

(Side note: at an SEPG conference several years ago, research showed a high concentration of early onset autism/Asberger’s syndrome among Silicon Valley’s professionals.  For SEPG, this was a very controversial session that led t interesting results: 1. developers who already felt socially inept wondered just how inept they might be; and 2. others took careful notes so that they could report people they didn’t get along with to HR with the suspicion that they might be autistic. Presenters were careful to say that this research was inconclusive and PRELIMINARY.)

In my experience software engineers score high marks in technical areas but fall short in communication skills because:

  • they do not realize that they are poor communicators (their co-workers and friends understand them);
  • they see themselves as superior in intelligence to non-IT’ers, which can lead to condescending behavior (“what do you mean that you don’t know what these acronyms mean?”
  • they do not realize that both the sender and receiver are part of the communication loop (as in “I understand perfectly, it’s the business who has a problem”);
  • they value technical proficiency over soft skills proficiency (if something is not complex and technical, where is the value?); and
  • they have not taken soft skills training aside from a presentation skills course in college.

What did I miss on this list?

What are soft skills?

While I hate to quote Wikipedia, it has a good definition for soft skills (better than dictionary.com):

Soft skills is a sociological term relating to a person’s “EQ” (Emotional Intelligence Quotient), the cluster of personality traits, social graces, communication, language, personal habits, friendliness, and optimism that characterize relationships with other people. Soft skills complement hard skills (part of a person’s IQ), which are the occupational requirements of a job and many other activities.

Soft Skills are behavioral competencies. Also known as Interpersonal Skills, or people skills, they include proficiencies such as communication skills, conflict resolution and negotiation, personal effectiveness, creative problem solving, strategic thinking, team building, influencing skills and selling skills, to name a few.

How many of these skills are explicitly taught as part of Scrum, Kanban, Lean or Agile training?  (In fairness, they were never taught in waterfall or structured analysis classes.) I know that there is at least recognition of soft skills importance with newer customer-centric methods, and I believe there is still a gap.

Are you better at presenting and communicating with users doing  Kanban or Scrum than you would be if you were involved in waterfall development?

As our industry has learned better ways of developing software-intensivScalee systems, neither our business partners nor we are well skilled in soft skills.  Accountants, marketing majors, doctors, actuaries, and human resources can also suffer from too much IQ and not enough EQ.  So, who is responsible for making sure that business outcomes, funding levels, and trust are present in the IT/Business partnership?  Both sides are definitely responsible for their own part to make things better.

On the development side, we need to recognize that prowess in terms of effective communication, knowledge transfer, people networking, facilitation, cultural awareness, etc. do not come by osmosis – we need soft skills practice and training.  When we are experts at both the hard and soft skills, our entire industry will gain – and so will our business partners.

How are your soft skills?  Here is a quick quiz: http://www.bettersoftskills.com/quiz/

Soft skills workshops?

It is easy to blame misunderstanding, lack of technical prowess, and poor communication on users, but IT has yet to recognize that IT’s not about the business; IT is all about the people.

Are you interested in attending a dedicated session on soft skills for technical professionals?  Drop me an email for information on my upcoming one-day IT’s all about the People workshop.

Have a productive week!

Carol


Share
//