Leave a comment

Wasting Your Money in Software Development

By Chris Durand CTO, Bridge360

ChrisDurand-B360Want a guaranteed way to reduce your spend on software development? Do less. Really. Testing too expensive? Test less! Development too expensive? Develop less! Does this sound too good to be true? The good news is that most teams can benefit tremendously from this approach. The trick is to identify what to do less of.

Continue reading


Leave a comment

Increasing Velocity of Agile Teams

by Benjamin Frech, Senior Software Engineer

Ben-FrechIncreasing a team’s productivity is a ubiquitous goal. But, how do you achieve that goal?

To many, it may be tempting to use velocity as a measure of productivity, but the value of a story point can vary significantly over time. Once you get past counterproductive answers like, “let’s inflate all our story points by 50%,” you’re left with options that can actually increase your team’s productivity or, at least, facilitate collaboration between team members.

In my experience, the top two methods of truly increasing productivity involve creating a comfortable work environment, and addressing technical debt and developer concerns. Continue reading


Leave a comment

How to Quickly Solve Technical Problems With “Straw Man” Technique

by Chris Durand, CTO

ChrisDurand-B360Are you looking for new way to solve pressing technical problems? Well, I’ve found one, and I recommend it for anyone looking for a fast way to start a problem-solving process. I call it the “straw man” technique, and it’s pretty straightforward:

  • Think of the simplest possible solution or partial solution for a problem. This is the “straw man.”
  • Discuss with your team reasons why you think the solution will work or not. My favorite question to ask is, “Why won’t this work?”
  • Modify the straw man accordingly and repeat until you have a useful solution.

That’s it! I find myself using the straw man technique often; you can, too. Imagine you and your team are looking for answers on how to solve a challenging problem or implement what appears to be a complex feature. Think of a super simple solution that addresses at least 50-60% of the problem and ask the team why it won’t work. Then iterate from there until you reveal an acceptable solution. Continue reading


Leave a comment

Best Practices: How to Gain Adoption and Ensure Software Quality

by Diane Kenyon, VP of Engineering and Operations

Diane picBenjamin Franklin famously stated that, “an ounce of prevention is worth a pound of cure.” In the world of quality software, that analogy may be underestimated. Errors in software development discovered at the release stage are greatly more expensive and difficult to repair than when discovered during the testing and development stages.

While there are no guarantees of perfect success, establishing best practices for development and properly educating your team of those guidelines will significantly reduce the likelihood of errors and diminish their impact. The key lies in making sure everyone knows the rules to the point of being able to quote them, and that each person understands his/her responsibilities within the project. Culture, compliance needs, expectations and risks all go into establishing a framework for success.

Following this structured process for defining and hardening your best practices improves consistent adoption across all team members: 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.


Leave a comment

Invisible Pillars of Development: Motivation, Morale, Skill, Diversity, and Chemistry

by Phil Smith, Vice President of Operations and Services

Phil Smith Bridge360A few months back I wrote a blog for this site that talked about 3 pillars of development that are visible: cost, schedule, and quality. Like arithmetic, these items are fact-based with little room for interpretation. Dollars, time, and adherence to requirements are all measurable and tangible. Multiply this, divide by that, and you can measure earned value and know if your project is ahead, behind, or progressing as expected.

Yet the most important dynamics of the workplace are not always measureable. For instance, how is team morale? Does the organization have enough diversity? Is the team chemistry contributing to overall performance, or hurting it? This time around I’ve elected to write about things that are more subjective, including the less visible “pillars” of development and the unspoken roles of team leadership.

Let’s look at that first.

A project manager works within the realm of cost, schedule, and quality. It is possible to affect one or two of these elements by making adjustments to the other(s). For example, we can reduce cost and advance the schedule if we are willing to sacrifice quality.

A project leader creates an environment where motivation, morale, skills, diversity, and chemistry all contribute to improved cost, schedule, and quality. It is important for us to think at a higher level specifically about these items that I’ve listed, because improving these areas is the best way to affect cost, schedule, and quality without having to make sacrifices.

Now I’ve stepped into a leadership dialog that may require multiple books to explain. Given that this is a blog and that my goal is to invoke thought, I’ll stick with the high level and will let the people who write books do their writing. In fact, I’ve included some books at the end of this blog that I believe cover these topics quite extensively.

I do want to share some of my own thoughts and I invite you to comment on the blog with your own ideas in return. In the title of the article I refer to the following concepts as development pillars as well, because they are essential to success. Continue reading


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

Leading, Managing, Doing

By:  Philip Smith

Phil Smith Bridge360I recently traveled to Europe on a business trip and was sitting up late in the hotel catching up on things that had happened at the home office while I was in flight.  I had the TV on in the background with a World War II documentary to keep me company. Fortunately the documentary ended and I was able to get back to the business at hand, but not before I picked up on a recurring point the documentary was making, which was Rommel’s impressive ability to lead his armies both strategically and tactically.  General Erwin Johannes Eugen Rommel (15 November 1891 – 14 October 1944), popularly known as The Desert Fox, continuously sought out ways to be unpredictable and grabbed geographic advantages even when it did not look possible. Fortunately for the Allied forces, Rommel usually over-achieved his goals, unintentionally overextending his ability to hold a region, or leaving a critical supply line vulnerable.

I actually committed to this blog title a while back, as I was planning to write about the difference between leading, managing, and doing.  I was going to differentiate leaders as people who motivate, encourage, strategize, manage risk, and build balance within the business domain (people, business, and customer). I was going to describe the doers as the people who have the skills, training, capability, and motivation to show up for work every day and get the job done, whatever that job might be.  These doers have respect for their profession and manage their career to the best of their ability. The managers in the middle bring it all together. They are the team builders, the front lines to the client, the make-sure-it-gets-done-no-matter-what people, and the example to the rest of the team. I was going to dig into these concepts and attempt to surface some original wisdom.

However, that documentary took me briefly away from my workplace and put me on a different thought plane about leadership. The wisdom here is that success can result from surprising the competition. Internally, a leader must be consistent and predictable, such that the established vision can actually be achieved. Externally, it is best to leave competitors wondering what you, the market leader might be reinventing.

Managers are the people who enable leaders to lead. Their ability to comprehend the challenges their teams face while also working in support the larger objectives requires them to be creative on a daily basis. The team members who work in support of the managers also bring creativity to their work. At Bridge360, our people invent and reinvent on a daily basis, regardless of role. Sure, we’re not lighting homes on fire to conceal our forces (that would be ridiculous in peace time), but we are finding better ways to implement complex business rules in a legacy payment system. We are helping a client use new technology to improve their collection of marketing information, which will help with market penetration. We are implementing a website with reusable design elements and code snippets to allow a client to accelerate a massive technology refresh. And in the business that we were founded on, testing, we are deploying key people with key skill sets to make sure that our client’s new projects are brought to market in a reliable fashion. These projects require clearly defined roles, as well as the flexibility to be nimble and shape-shift (or even fully integrate ourselves into our client’s team structure) based on what the project may require.

Leading, managing, and doing… we are accomplishing it in surprising ways at all levels in the organization, and more importantly we are doing it for and with our clients.


1 Comment

Should “Good Technical People” Manage Projects?

by Phillip Smith, Vice President Operations and Services

Phil Smith Bridge360I’ve seen many people in the IT industry think about shifting from a “software engineering” job over to project management.  When I come across these folks in discussions, I stay on topic with the person long enough to discover their real motivation for change.  I ask them to think about how they want to spend their workday, because it really is important to maintain alignment between the way people are wired and the type of work they are asked to perform.

So let’s talk about the general differences between the two “types” of people we typically see in technical roles vs. project management roles.

People who excel with technical work are a strong blend of “idea” and “action” in terms of the way they are wired.  They love submersing themselves with great technical ideas and they are motivated to make use of all of the available tools and tricks.  They often use their free time keeping up with new technology, simply because they have a passion about it and have an appetite to keep learning.  They may stay up late at night reading manuals, or publications, or tinkering with things on their home network.  I don’t want to discount the teamwork aspects of working with technology, because they are critical to success.  However, working with technology does require a person to be comfortable with working many of their hours independently and somewhat isolated, because they are typically assigned tasks that require research and original thought that is performed at the individual level.

In contrast, project management work is very “people” and “process” centric.  Most of a project managers’ time is spent building relationship and influencing people.  They spend time facilitating meetings, gathering information, and communicating status or resolving issues.  A project manager who is savvy enough to manage their schedule, cost, and risk through constant communication will be even more successful if they also love taking advantage of formal processes.  When I refer to formal process, I’m referring to defined work patterns, tools, templates, and mechanisms for reporting and tracking.  A project manager will go to sleep very quickly if you put him or her in front of a technical manual, but that same person will become energized if you strike up a conversation about earned value or resource leveling.

Again, my point comes back to the question of how a person likes to spend their day.  If they are passionate about technology they are likely to be miserable if their job requires them to navigate organizational politics and never gives them time to work through the riddles of writing efficient code.  To this I say, let them be architects and engineers—why ask them to be project managers?

I will concede that there are a few people around who are oriented strongly as a mix of people, process, idea, and action.  These people are sometimes confused by the distinctions I’ve presented here because they are just as happy to be accomplishing something on their own in isolation as they are accomplishing things in a group setting where a lot of people interaction is required.  These folks can leap from a PM role to a technology role quite comfortably.  You’ll often find them excelling in various parts of the software development cycle as product managers, business analysts, technical leaders, or as quality assurance specialists.  These roles require a mix of technical understanding and desire to work with people and process.  So next time one of your technical people talks to you about doing project management work, ask them:  “How do you like to spend your day?”


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.