1 Comment

The Exciting Potential Of Agile Software Development

by Morgan McCollough, Senior Software Engineer

Morgan McCollough Bridge360In the first week of June, I made the trek to Caesar’s Palace in Las Vegas to attend the Agile Development and Better Software Conference. The conference itself was only two days, but I attended a three-day Agile scrum master training class beforehand. It rounded out a full week immersed in all things Agile.

I’ve worked with a number of clients who claimed to have adopted Agile in one form or another. I’ve also read quite a bit about it, but prior to my week in Las Vegas, I had never received any formal training. The trip was eye opening, and it was a great opportunity to talk with people from across the industry.

What really became obvious was just how many companies are successfully implementing Agile processes at both the software development and program management levels. Some are achieving pretty dramatic results, with up to 30% shorter schedules and 75% fewer defects on average! However, learning the formal practice of Agile also made it clear how much dysfunction still exists, even in companies claiming the Agile moniker. Continue reading


Leave a comment

Continued Education: Whose Responsibility Is it – Employer or Employee?

by Phil Smith, Vice President Client Services

PhilThere is a large volume of material circulating on the Internet, providing philosophical approaches to lifelong learning for individuals. The concept of “continuous learning”, as it applies to the workplace, tends to revolve around these two generally accepted definitions:

  1. “Ongoing learning process that seeks to incorporate the lessons learnt (from the results of already implemented changes) into a continuous improvement program” (http://www.businessdictionary.com/definition/continuous-learning-activity.html), and…
  2. “Total quality philosophy in which every process and system in a firm is subject to constant scrutiny to (1) eliminate waste, (2) reduce response time, and (3) simplify process or product design” (http://www.businessdictionary.com/definition/continuous-improvement-program.html).

These links will take you back to the core concept that organizations must base their manufacturing and/or services on processes, and that once established, processes must always be under formal measurement, scrutiny, and improvement. If you are in a knowledge-based industry, such as software engineering and quality, then you have to extend the concept into your training program. Training must be viewed as a process and must always be improving. This applies to your own skill set as well—it’s not just about process capability, but also about people capability.

There is some overlap with workplace continuous learning (employer sponsored improvement) and self-improvement (individual sponsored improvement) in a few articles that I recently stumbled onto where the authors were clearly unhappy with current or past employers’ training programs. I’m not providing links because in many cases it was obvious which employer had caused enough emotion to ignite a blog. However, these articles do raise interesting points, specifically, who is responsible for an employee remaining current with their technical skills:  the employee, or the employer?

I’m referring to widely accepted workplace concepts related to improvement; not just improvement of the product or service, but also improvement of the human capital used to deliver. I’ll state my opinion clearly right here: the employer is responsible. Organizations that rely on people’s knowledge, skills, and efficiencies have a significant responsibility and market incentive to keep their workforce as far ahead of the competition’s workforce as possible.  These organizations have a social and economic responsibility to provide formal plans for training and they need to execute those plans with relevant material. The results and methods the training uses must be measured and improved over time.

I use the term “economic responsibility” because training is actually a pursuit of efficiency and improvement. Without these investments, companies lose ground to competition and ownership value erodes. Additionally, leaving training solely in the hands of employees will result in poor alignment with company objectives and unpredictable results.

I use the term “social responsibility” because the software industry typically keeps people so busy working billable hours that we don’t make time for training programs. We create them; we just don’t execute them. Cost pressure from offshore providers has left US-based resources in a predicament, because training costs are no longer easily hidden inside billing rates. Therefore training programs get sorted to the bottom of the priority list and do not receive attention. In some cases, recent graduates end up more qualified in relevant technologies than long-term industry experts. Technologists who do not take it upon themselves to learn relevant technologies may end up on the wrong side of the cost benefit curve, which certainly feels unfair to the many who work long billable hours to make their company successful.

Other industries such as health and legal, which are knowledge based, require that people be licensed, and that licenses be maintained over time on the basis of formal, ongoing education. We’ve missed this concept in the software industry, which has been convenient in that it allows us to be informal with our staffing decisions and enables us to exchange hours that should be dedicated to training and certification for more billable hours.

On the flip side, you can’t argue with free market economics. Graduating students will always have some advantages that may or may not outweigh their lack of experience, and offshore resources will always have some cost advantage that may or may not outweigh distance and other factors. Employers will always have challenges with cost and commitments, resulting in pressure for more billable hours. In the end, the only person that can be held responsible for a person’s career plan, training, and marketability is the person. Life just works that way.  Making sure you are marketable is basically the same as being a gazelle out on the plains. Fast and capable is essential. With that in mind, if I could personally meet the people whose blogs read like, “it’s not my fault,” I think I’d have difficulty finding sympathy.

So, is the employer responsible for training, or is it the employee? Yes.


3 Comments

3 Visible Pillars – Cost, Quality, Schedule

by Phil Smith, Vice President of Operations and Services

Phil Smith Bridge360Searching the Internet for “information technology project failure rates” will provide a wealth of data and information. Data is readily available in depressingly large volumes from studies that indicate that investing in IT projects is high-risk and unwise. There is useful text accompanying the statistics that explains root cause and even classes of failures. I like these sites because the content is well organized and they include recommendations for how to avoid failure.

The sites are:  Why Projects Fail, McKinsey Report Highlights Failure of Large Projects, and Gartner Survey Shows Why Projects Fail.

The Project Management Institute (PMI) was launched in 1984. The PMI material, certifications, frameworks (and everything else offered) are invaluable to any organization that runs an IT project. I applaud the PMI for giving the world of project management context and rigor to not only talk about improvement, but also a way to build methodologies to achieve the improvements.

Yet the statistics available from current studies, over 25 years after the PMI started helping us, are disastrous. According to the Calleam site listed above, a McKinsey & Company survey from 2012 showed that 17% of large scale IT projects fail so badly they threaten the existence of the company.

Again, there is no lack of material or training, even beyond what the PMI makes available, to help our IT industry improve. I often think of the maturity of the IT industry in comparison to the maturity of other industries like medicine, manufacturing, engineering, and construction. History indicates that assuming that customers will continue to invest due to lack of an alternative has turned industries and companies inside out once a suitable alternative becomes available. It is in our best interest to be in control of the revolution.

I know I’ve stepped into a complex dialog here, specifically with the subject of how to get the entire industry to move toward one common set of methods, practices, and cost structures. I argue the absence of common structure creates a gap that is filled by the client’s choice to bring unique and unrealistic expectations for cost, timing, and quality. Most consumers of IT services are well educated and know that writing a line of code only costs as much as the pay rate multiplied by the actual effort, which is not much.  Yes, that is the wrong way to measure cost but it is the way that most consumers elect to measure it in a negotiation, because we as an industry lack structure.  To compare, my recent trip to the doctor cost my insurers over $200, and I only saw the doctor for about 5 minutes.  I’m sure that along with the 5 minutes I was also paying for a lot of staff, infrastructure, insurance, training, equipment, and capability that all came together to make the 5 minutes possible.  And the doctor does not invoice the insurance company for the 5 minutes he spent, instead he associates it to a billable service with a preset fee.  That approach allows him to be there for me when I need him.

In our IT world, individual projects are bound by unrealistic expectations from clients. Referring back to all the sound advice and training available from the above referenced sites, and from PMI, we know that project plans, which incorporate the boundaries of cost, quality, and schedule, must consider everything that is required to deliver an entire solution, not just the individual point in time that an engineer is writing a specific line of code. For example, that line of code, in order to be correct, must be written with an appropriate technology, within an architected solution that is secure, accessible, reliable, tested, and maintainable. Those adjectives are not free.  They are in place because of hard work, training, and process.

The pillars of cost, quality, and schedule are non-negotiable once established. If a project fails, it failed because one or more of these three pillars cracked, or crumbled. Establishing them correctly up front will significantly reduce the opportunity for them to bear pressure during a project. Establishing them correctly requires that we manage expectations that include the teachings from PMI and from the lessons learned in the industry.

In summary, we need to plan for things like validation of requirements with stakeholders. We need to plan for things like training, performance testing, failover, risk management, system documentation, traceability… I could go on. My larger picture argument is that I hope that someday we’ll take this approach as an industry rather than as individual service providers.  We should be differentiated by our ability to deliver rather than win business based on our ability to negotiate ourselves into low cost and inadequate delivery.

Set the pillars in place, build the plan based on the pillars, and deliver to the plan.

Please, share your thoughts and opinions on this topic and let’s see where the dialogue takes us.


Leave a comment

The Tale of the Process Challenged Pig

by Phillip Smith, Vice President of Operations and Services

Phil Smith Bridge360Once upon a time there was a wolf and three pigs.  One pig acted in a cost conscious manner.  One acted with urgency.  The other one… well, he stayed in business long enough to tell the story.  In IT, we need all three attributes:  cost consciousness, motivation, and quality focus.  Yes, the quality conscious pig who built with reliable design and materials is going to be the first one that I’ll select to be on my project team.  This individual not only cared about the end result, but he (not being gender biased here; I looked it up and the three pigs were males, sorry ladies) cared about the process.  He thought about how to measure success (security was considered in the requirements) and about sustainability (I understand a wood stove and a chimney were included).  The windows had curtains and shutters which increased usability, and the foundation was solid with an open floor plan in case of further expansion.

The third pig used a process to get to his end result.  He did not react; he planned.  He followed what he had learned in the past and put his best skills and resources to work.

In real life, I don’t get to pre-wire all of the members of a project team, and most of them, myself included, are not wired like that last pig.  In fact, most of us are wired with action (get it done, move on to the next task) and with a tendency to think about getting there with low cost, which is always noble and usually rewarded.  In fact, most of us have to stop and remind ourselves of the things we were taught that may not be inherent in our genes—namely, to plan and deliberately execute, rather than to simply execute.

Therefore, project teams, by nature, are made up of people with a mixture of tendencies, and many of them will not be process oriented.  It is important that teams be intentionally staffed and supported by people who value process and are capable of influencing their other team members.

When we drive our cars, we all follow a basic set of rules based on lanes, signals, and safety.  We all understand and accept these rules, and follow along with them without much discussion.  Yes, similar rules exist in the world of software development.

Such as:

  • Requirements should be documented and validated
  • Testing should be planned
  • Work products should be reviewed
  • Team members should be trained

I could go on for a while with this list.  And, very few in the software industry would argue with these basic rules.  Yet some of the most talented engineers are comfortable moving straight from a conversation with the client to writing code.

I want these talented engineers on the team.  I also want to balance their action oriented initiative with some process so that the end result is similar to the brick house.  If the three pigs had pooled their talents, they would have all been better off.

One parting shot… don’t load your whole team with process people unless you are creating a PMO.  They are certainly invaluable, but if you put them all together they will build a better process, not a brick house.


1 Comment

Why You Should Think of People as Raw Materials

by Phillip Smith

Those of us in the service industry do not always have something tangible to show as a result of our work. Compare us to people who build things (like roads, or boats, or furniture) or to people who refine, grow, weave, or clean (to provide fuels, clothing, or foods) and we’re quickly at a loss to point to anything physical that is the result of our efforts. Extend the comparison a bit further to folks who perform, write, invent, or design, and we still fall short in terms of having a tangible product. However, that does not mean that we, specifically those of us who sell or provide a service, are not building something.

Consider the absolute best outcome of a good day’s work in the service industry: the result is a new or improved “relationship.” Yes, people who work in sales and service are building; they are building relationships.

To the casual observer, it may appear that they are explaining the features of a product, or in the case of something closer to my daily work, deploying high quality software into your business environment. And that is the day-to-day picture of what we do. However, the observer who is looking a bit deeper sees us doing more than filling a role in order to put food on the table. We are building expectations, trust, and ethical standards that result in long lasting high value relationships. In these cases “tangible” falls short of being a good measurement of value because the end result is anything but an end. Solid relationships, new processes, better standards—these have a ripple effect in the way people do business, and even if the work didn’t result in the next greatest invention, it’s still the kind of stuff that changes the world.

I’ve not presented anything revolutionary in this article. I’m hoping however, that I caught your eye with the title and that you’ll be willing to think about your hiring, training, and culture in a slightly different way. You would not assemble furniture using an unreliable design or with poor quality components. You should think of the people in your service company the same way that you think of the materials that you might use to make a salable product, with the exception that you are using these people to build relationships that make your business successful.

Are they the best people you can find? Have you trained them well and set them up for success? Are they true critical thinkers, not satisfied until they’ve found the best way of doing something? Have you set the right example with the relationships that you maintain with your clients and with your employees?

Have you communicated the right message to your employees, so they understand how to win repeat business? A smile and a willingness to view the service from the client’s point of view is a key ingredient to repeat business, and it’s not always something you can teach. The people that do your smiling are doing what they love, caring about the results and invested in the outcome—and they are the equivalent of the grapes that go into a fine wine.


4 Comments

Ailing Projects: Should PM’s Treat the Symptoms, or the Root Cause?

by Phillip Smith

In my previous article I wrote about IT projects experiencing trouble, and separated the symptoms from the root causes. Doctors sometimes treat symptoms, and sometime they treat root causes.  Other times they treat both or do nothing at all. In this case, the project is the ailing patient, and the specific medicines that a project manager chooses to administer—and when—is largely a matter of style.

Some project managers are comfortable allowing a certain amount of churn to take place before they step in, while others work in a more hands-on mode. If the project team is seasoned and is using a mature development process, the PM can afford to allow that team space and time to work through problems without having to personally drive a resolution for each problem.  There is a balance between empowering the team and being so distant that you appear to be “checked out”.  Find that balance (it will vary by project and by team) and use it to your advantage.  Teams that work independently within a process set tend to accomplish a lot –  and they tend to have great morale when they are productive and know they have a PM who will drive resolution for issues when they need that kind of help.

While I’m willing to admit that the PM has a right to bring a certain amount of style to their approach, I’m also willing to make a strong argument that various situations call for certain “medicines”.  In the last article I listed classic symptoms of a project being in trouble. One of these was “high defect rate.”  We can use that as an example of a situation that calls for specific action. Continue reading


1 Comment

Project Management Survival Guide Part II: Three Ways to Stay Clean While Doing the “Dirty Job” of IT Project Management

by Phillip Smith

Last week we talked about the dirty job of project management, and how the complexities involved in leading teams and implementing IT projects often make the PM’s job even messier than Mike Rowe on a sweeps week episode of Dirty Jobs.

Luckily for us, there are three tried and true guidelines for cleaning up even the messiest project—or even better, keeping it in check before things get out of hand. Here they are:

  1. Stabilize requirements and schedules
  2. Set up repeatable processes and tasks
  3. Allow team members to develop specialized skills that can be called on as needed.

1. Stabilize requirements and schedules

Stabilizing the requirements and the schedule is about managing the stakeholders.  It’s an art form that requires patience and understanding, and the good sense for compromise and protection of the project team.  If you lose too many battles here, the project may be successful, but you won’t have a team left to execute the next project.

2. Set up repeatable processes and tasks

Setting up repeatable processes and tasks is all about maturing the project team.  While every project is unique, the execution is not.  For example, there is always a design document.  Use the same template every time.  Use a reliable review process with team members who have the right knowledge.  Hold the design to a high quality standard, schedule enough time into the plan to do it right, and execute this way on every project so that all team members understand the expectation. Continue reading