The Importance of Talent in IT

February 14, 2011

For a little diversion from Cloud Computing, let’s talk about the importance of talent in IT organizations.  Several weeks ago, while talking with a collogue about the Super Bowl game between the Green Bay Packers and the Pittsburgh Steelers, our discussion turned to the value of talent.  Player talent is highly valued in sports, but not valued as highly in the world of IT.

In pro-sports, player talent is viewed as a fundamental key asset.  If a player has more talent and gets a few more tackles in a football game; hits more home runs in baseball, or scores more baskets in basketball, than that player’s value can on the field and salary off the field can be many times higher than less talented peers.

Yet in many organizations, the talent of IT software engineers, project managers and architects is commoditized.  A standard bill rate or cost per hour is defined for IT roles and “rate sheets” are developed with published rates for various roles.

The standard rate sheet model assumes that all individuals in a given role produce the same amount of work.  Unfortunately, IT is more of a craft than a factory assembly line and the standard rate models may not be the best model to use.

The same individual talent differences that we observe in sports occur in IT.  Barry Boehm, in his 1981 book “Software Engineering Economics”, (http://en.wikipedia.org/wiki/Barry_Boehm), found that higher performing software development teams were up to 25 times more productive than lower performing software development teams. This is an astounding difference and one that may play a big part in why so many IT projects fail.

Boehm’s results have been replicated time and time again. More talented software engineers, project managers and architects produce substantially better products, faster and at a much higher productivity level.

I am not sure of all of the reasons why IT talent is commoditized, but one reason may be that we don’t spend a lot of time focusing on IT talent.  Instead, we focus on the latest tool or methodology, versus the talent of the individual using the tool or methodology.

Most professional sports have a large infrastructure of scouts, talent evaluators and minor leagues that try to identify talented players.  Sports also measures performance with every game. Maybe if IT organizations focused on identifying talented software engineers, project managers and software architects, than we would have fewer failed projects, more project successes and individuals in IT who have more talent would be treated as the super stars that they are, just as super star players in sports are treated.

Advertisements

Agile vs. Traditional Project Manager Role

August 17, 2010

A number of Agile authors suggest that the role of the traditional project manager on Agile projects is dead and should be replaced by the Agile Project Manager.  Although I have disagreed with this idea, I had never examined it in detail.

At a recent Agile Project Management Meet-up, I had an opportunity to examine this idea.  We had a facilitated discussion on the role of the “Scrum Master / Agile Project Manager”.  The facilitator was objective, did not favor any particular view of Agile and did not compare the Agile role with the Traditional Project Manager role.

Note: For the remainder of this blog, I will use the term “Agile Project Manager” to refer to both “Scrum Master” and “Agile Project Manager”.

After the Meetup, I documented the Agile Project Management responsibilities discussed in the Meetup in the table below.  I added Ken Schwaber’s ideas about the role of the Scrum Master, (noted in italic with an asterisk) and listed PMI’s PMBOK 2008 responsibilities for the Traditional Project Manager.

After analyzing the table, there appears to me to be little difference between successful Agile Project Managers and Traditional Project Managers. They have similar responsibilities and successful ones practice participative management.

To me, the main difference between the roles is in the way they are portrayed.

Agile Project Manages are portrayed as favoring a participative management style guiding self-governing Agile Project Teams (more on this in another blog).

In contrast, Traditional Project Managers are portrayed as favoring an autocratic, command and control management style; make all project decisions themselves; develop detailed Waterfall Project Plans themselves; assign tasks to project team members without their input; and are constantly “cracking a whip” to make sure that all team members are working as hard as they can to complete the project.

These views do not fit with my experiences and do not they fit with what the PMBOK says.  The PMBOK discusses a variety of management styles, and then states that project team members are key to the success of any project and recommends a collaborative team building style as the best way to run projects.

The most successful Project Managers that I know (Agile or Traditional) practice participative management.  They include project team members in in project planning, in project decision making and in project execution.  They focus on training and mentoring their teams to help them achieve project objectives.

Table 1 – Agile versus Traditional Project Management Responsibilities

Scrum Master – Agile Project Manager

Roles from Agile Project Meetup

Traditional Project Manager

From PMBOK 2008

Facilitate Rituals:

  • Stand-ups / Scrums
  • Demos
  • Retrospectives
Facilitate Project Activities::

  • Project Planning Meetings
  • Execution of Project Tasks
  • Project Status Reporting
Coach Agile Team in Rituals and in agile task execution
  • Develop Team Members
  • Work collaboratively to resolve project issues
  • Work with Stakeholders to set and manage their expectations
Remove Obstacles (Impediments*) Resolve Project Issues often using an Issue List (Obstacles or Impediments)
Track Progress & suggest corrections if needed

  • Burn-Down Chart for Sprint
  • Burn-Up Chart for tracking multiple Sprints that were needed for a Production Release
Track Progress and manage changes

  • Time, Schedule, Cost and Scope through Project Change Control
  • Earned Value Effort and Schedule Charts
  • GANTT Charts
Manage Project Budget Manage Project Budget
Develop estimates using Planning Poker (a modified Delphi technique) Develop estimates using a variety of techniques including Delphi and modified Delphi techniques)
Communicate with Stakeholders:

  • Product Owner
  • Team
  • Sr. Management
Develop and manage Project Communications Plan for all key stakeholders
Work with Product Owner to:

  • Help prioritize
  • Manage Scope
  • Coach
Work with Stakeholders to develop:

  • Project Charter
  • Project Management Plan
  • Prioritize and balance project constraints of:
    • Scope
    • Time & Schedule
    • Cost & Budget
    • Resources
    • Risk
    • Quality
Helps form Teams*

  • Works with Customers and Management to identify and institute a Product Owner
  • Works with Management to form Scrum Teams
Develops Human Resource Plan

  • Identify key Stakeholders
  • Identify and document project roles, responsibilities, skills, reporting relationships
  • Acquire, Develop and Manage Project Team to fill Project Roles
Responsible for the success of Scrum*

  • Is the driving force behind all scrum activities and ensues that the values, practices and rules are enacted and enforced*
Responsible to organization to achieve Project Objectives (Success)

  • Is the application of knowledge, skills, tools, and techniques to project activities to meet project requirements?
Is a New Management Role* Traditional Project Management Role that has been around for numerous years.

Hybrid Software Engineering = Agile + Traditional

June 13, 2010

The time has come to stop the debate between Agile software developers and Traditional software developers.  Both Agile and Traditional have some excellent practices.  It is time to become “Software Engineers” and combine the “best” Agile software development practices with the “best” Traditional software development practices into what I call Hybrid Software Engineering.

The popularity of Agile software development has been increasing in the past few years.  Agile has introduced a number of excellent software development practices such as: Iterations, Planning Poker, Simple Design, Small Releases, Pair Development, Continuous Development, and On-site Customers.

There are also quite a few excellent Traditional software development practices such as:  Project Management Planning, Solution and Systems Architecture design, Configuration Management, Quality Assurance, Risk Planning and Inspections.

In this post and in future posts, I use the term Traditional software development practices to refer to “Waterfall” software development.  The reason for this is that “Waterfall” software development been given a “bad” name by many Agile software development practitioners who claim that the “Waterfall” process does not work and Agile software development is “much better and faster”.

However, most organizations that I consult with still use Traditional software development practices to develop most of their software.  Numerous software applications that we use everyday such as: Telephone Billing Systems, Insurance Company Claim Systems, Order Processing Systems, Banking Systems, Cellular Systems and Medical Device Systems to name a few, have all been developed and still being maintained by some form of Traditional software development process.

The Agile folks tend not to recognize the good Traditional software development practices and the Traditional folks tend not to recognize the good Agile software development practices.

The Need for Hybrid Software Engineering

The time has come to combine the “best” Agile software development practices with the “best” Traditional software development practices into Hybrid Software Engineering.

Hybrid Software Engineering would operate similar to the way a Hybrid automobile works.  A hybrid car uses the electric engine in city driving, where constant breaking recharges the battery and uses the gasoline engine in highway driving were the gasoline engine provides a greater range of operation and can be refilled more easily.  Hybrid Software Engineering would use Agile software development practices where they provide the most value and Traditional software development practices where they provide the most value.


What is Software Engineering?

May 21, 2010

This post is a follow-up to my earlier blog on Software Certification. Certification is a complex topic.  Before getting too far into a discussion on certification, let’s look at the work we call software development.

World wide there are millions of individuals who develop software for a living and they go by many names: programmer, software developer, software craftsman and software engineer.

From a work content point of view, the work of software development appears similar to the work that engineers perform and there is a recent trend to call individuals who develop software, Software Engineers.

For the past 20 years, I have been a consultant to dozens of companies assisting them improve their business processes and improve their ability to develop software. During this time, I have taught Software Engineering as an adjunct at DePaul University in Chicago.  This past Winter Quarter, I taught a Software Engineering Process class with a focus on Agile and Lean software engineering.  After this class I felt that my old definition of Software Engineering was inadequate and felt the necessity to develop the current definition as follows:

Larry’s Current Definition of Software Engineering

“Software Engineering is a profession that uses sound engineering principles, processes and practices and a body of knowledge to propose, design, develop, deploy, operate, maintain and retire computer software solutions over their useful life that people will buy and use to solve real world problems.”

Within this definition the Software Engineer becomes responsible for the overall software solution from the initial idea through design, development, deployment, operation to retirement.

This definition also accommodates the various sub-specialties of Software Engineering that we see in practice today such as: Business Analyst, Data Base Engineer, Infrastructure Engineer, Network Engineer, Software Developer and Systems Administrator.

Why develop my own definition of Software Engineering?

For the last 20 years I had been using a definition of Software Engineering by Fritz Bauer from 1968 (see below).  That definition was workable for a long time, but recently I felt that that it needed to be broadened to better encompass the full software development life cycle.

Before I wrote my own definition of software engineering, I researched several other definitions: one on Wikipedia and one defined in IEEE’s Software Engineering Body of Knowledge (see below). Neither of these definitions satisfied by current view of software engineering in terms of the breadth or depth required to “engineer” software in the real world situations that I saw every day in my consulting work.

Software development is a complex process.  The software development process begins with an idea, continues with the design and development of a solution followed by operating the solution in production for a period of time and eventually retiring the solution as described below:

  • Envision: The “engineering” of a software program begins when an individual, often called the “user” determines they have a need for something new or a “developer” envisions a new way to solve a problem.
  • Propose: The “engineering” continues with a proposal to obtain funding for a project to develop the solution.
  • Design: Once funding is obtained, “engineering” designs a solution to the problem.

  • Development: Next, “engineering” develops a working version of the solution.
  • Deploy: Once an initial version of the system has been developed, further “engineering” is usually needed to successfully deploy the solution into operation.
  • Operation and Maintenance: As the solution operates and its use grows, there is a need to “engineer” refinements into the solution for it to continue to grow and satisfy changing conditions.
  • Retirement: Eventually, the solution can not be cost effectively refined and it must be replaced by a “new” solution and the cycle continues.  Even in this stage, there is a need to “engineer” the graceful retirement of the “old” solution.

Although this may seem like a linear life cycle, there is usually considerable iteration between the various stages.  Throughout this life cycle, there is a need for a “software engineer” to formally or informally make use of a wide variety of principles, processes, and practices such as:  requirements definition (or product backlog development), coding and coding standards, configuration management, testing and a mechanism of handling changes (Change Control or Iterations) to name a few.

Other Definitions of Software Engineering

Fritz Bauer’s Early Definition of Software Engineering

“The establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines.”

Fritz Bauer, 1968

Wikipedia

Software engineering is a profession and field of study dedicated to designing, implementing, and modifying software so that it is of higher quality, more affordable, maintainable, and faster to build.

See http://en.wikipedia.org/wiki/Software_engineering for more details.

IEEE Computer Society

The IEEE Computer Society‘s Software Engineering Body of Knowledge defines “software engineering” as the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software.[6]

See http://www.computer.org/portal/web/swebok/html/ch1#Ref1 for more details.

Although the Wikipedia definition mentions design of software, it does not focus on the full life cycle and adds constraints such as “more affordable” that are extraneous.  The IEEE SWBOK definition includes operation in the life cycle, but does not mention design.  It also adds a statement around “quantifiable” which often can not be accomplished in the real world.

More posts on this topic in the future!


Software Certifications

April 29, 2010

At the APLN Chicago meeting on Thurs, April 21, 2010 we had a good discussion on Certification and Certificates. The discussion focused on the reasons for and against certification as follows:

Reasons for Certification:

1)      As guide to learn a domain

2)      To get past hiring filters

3)      To demonstration that the individual has learned a domain

4)      To socialize with peers w/similar knowledge, challenges and interests

Reasons against Certifications:

1)      Doesn’t show true capability – especially when Certification occurs after a 2 day class without a test (or even 1 week class with a test – I’m thinking of PMI here);

2)      Certification turns skills, knowledge, experience and knowledge work in general into a commodity

Some of my thoughts on the issue that were not discussed at the APLN meeting:

I believe that Certification has turned knowledge work into a commodity without adequate proof that it can be turned into a commodity.  The use of Certifications for positions like Project Manager, Tester, Business Analyst and Scrum Master has made the life of a hiring official easier, but I doubt that it has improved the quality of the workers hired.

Certification is not the way to solve the problem, especially when Certification means attending a 2-day class (or even attending a 1-week class and test).  Pretending that a Certification will fix the personnel selection problem is foolish and dangerous.

Where’s the Beef?

I would like to see a hiring official show me defensible personnel selection data that shows that Certifications has improved the quality of the work force hired.

In fact, I believe that Certification in the Computer Industry has led to the outsourcing of many US jobs to cheap foreign labor without adequate demonstration that the foreign labor can in fact deliver the same results.

Assessing Talent is difficult.  It is difficult in the software development area and it is difficult in sports teams as well, as most fans of Chicago area teams know.

Interview based personnel selection systems (which most organizations use) have low validity with correlation coefficients between 0.20 and 0.30. This means that the interview based selection systems account for between 4% and 9% of the variability between interview ratings and job success.  Not a number you would want to “bet the farm on”!

Improved interviewing skills, job simulations and greater focus on grooming internal employees will provide some improvement, but current personnel selection techniques are just not very effective.

It takes many years of continued demonstration of good skills, knowledge and experience in real life situations to become a licensed Medical Doctor.  If we want to formally assess talent, than we should State License Software Engineers in a way similar to the Medical Profession!


Software Engineering

April 25, 2010

I have been consulting in IT for over 30 years and have been teaching Software Engineering at the graduate level for most of the same time.

During that time I have noticed a disturbing trend among the individuals I meet within the IT Industry.  Many individuals only have a narrow knowledge of some specialty within IT.  They may know a specific software language such as:  C#, Pearl, PHP or Python; they may know a specific operating system such as: Linux or MS/Windows Vista; or a specific software development methodology such as:  Waterfall, RUP or Scrum, but do not have a broad range of skills.

This lack of overall knowledge of the entire software development, operation and maintenance process often leads to micro-optimization, inappropriate solutions and failed projects.

In other professions such as medicine, an doctor in training in addition to needing a college degree, and a medical degree needs to practice his trade as an itern to learn the general practice of medicine before they learn a specialty.   Learning a specialty takes years more of learning and practice.  Among the trades such as Electrician, Plumber or Carpenter, there is a requirement to learn the general trade over an extended period as a Journeyman before learning a specialty.

Not so in the IT profession.  Individuals in IT often learn a specialty, begin work  and never learn the general principles and practices of software development, operations and maintenance.

Computer software is becoming more complex and integrated with the business organization.  As a result, there is a need to identify individuals who have a broad range of expertise, look at the overall problem and develop a comprehensive solution to that problem.  These individuals should be called: Software Engineers. They should be taught the broad based of knowledge necessary to develop, operate and maintain software solutions.  Then they need to learn to practice software engineering over an extended period of time.  Once this is done, they can focus on a specialty and become certified in that specialty.

I try to correct this lack of general knowledge by teaching Software Engineering at the Graduate Level, but I can not reach every individual going into IT. We need focus on teaching Software Engineers if IT is every to become a true profession.