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


5 Comments

“Fed” Up With Bad Software? Learn from the Woes of Healthcare.gov

by Brenda Hall

Brenda_Hall_100_x_120All the noise and chatter over the ability to sign up for healthcare under the Healthcare.gov website is a clear indicator of one of the things that irks me the most — websites that don’t work. Online experiences such as shopping, planning for vacations, or any other effort requiring interaction with a computer or mobile device, that doesn’t deliver a successful experience is very annoying. It’s also detrimental to the lifespan of the product and ultimately the parent company responsible for its operation.

I see an elevating trend with people getting plain fed up, and in most cases the issue can be pointed directly to ‘buggy’ software. As in any effort to build a website, the need for an experienced team under the guidance of strong leadership is critical for success. The “team” is vast and varied… not everyone is there to write code. Business Analysts working with the user (in this case everyday Americans from many walks of life) should be making sure the requirements given to the technical team are clear and well documented. “Leadership” will include people who have built e-Commerce websites in the past. And project managers are there to assemble the project plans that deliver a successful result on time. The failure of this contractor to deliver a health care enrollment portal may involve many ‘gotchas’ along the way… but Quality was certainly the sacrificial cow on the altar.

Any experienced project manager will tell you projects are driven by three pillars: Cost, Schedule and Quality. If one of those elements goes awry, the project is at high risk for failure. And far too often, pressures on cost and schedule force quality to draw the short straw. No time to test? Really? So it’s okay to turn your customers on to something that isn’t working? Testing is a critical part of producing good software (and websites.) Testing is expensive. Testing takes time. Testing is hard. Testing takes experienced professionals to execute.

The experience so many people had with trying to sign up for healthcare is a modern-day example of what so many of us have come to tolerate, but not be happy about. “Why did I get all the way to the end and then get stuck? Why did I get bounced out just as I entered my credit card data? I haven’t changed my password….why isn’t it working now? Why is my data lost every time there’s an upgrade?” The complaints go on and on. I think people are fundamentally fed up with bad software in the market, and this most recent fiasco has voices in volume.

There really is no good excuse for Healthcare.gov to have gone ‘live’ in the condition it was in. We can ‘sidewalk supervise’ all day long, but the message is clear. Someone dropped the ball on Quality. It just wasn’t important enough and a lack of Testing is the reason this website failed to deliver. Costs have now skyrocketed with all the media attention and ‘24/7’ effort according to President Obama… far more than should have been spent if the job had simply been done right from the start.

However, Healthcare.gov was one enormous advantage over most projects — it’s being built by the government using federal tax dollars. As crippling as this failure has been, it will still move forward. A similar fiasco by a company in the private sector would undoubtedly result in such a reputational disaster that the software would be doomed to failure beyond repair.


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.


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.