Tag Archives: Waterfall model

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

Advertisements

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

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
//