Your team needs a coach

shutterstock_133999970We talk about teams a lot in software development. That’s understandable, since most projects need more than one person to work together to accomplish everything that needs to be done in the project. That team needs to be composed of people with different strengths, but they all need to have a clear understanding of the business goals. The team also needs to understand the strategy and tactics that they’ll employ to achieve those goals. This is no different than a sports team. But in software development, we hardly ever talk about coaches. You may think that a manager is the same thing as a coach, and there is a definite overlap between those skill sets. However, many organizations fail to cultivate the specific characteristics required for managers to be effective coaches.

First and foremost, coaches have to have credibility. The team must believe that the coach’s advice is worthwhile. In software, this frequently comes from the manager having “been there and done that” as a developer or test engineer.  Having a first-hand understanding of the challenges facing technical teams, and being able to provide specific technical guidance, gives the team faith that the coach knows what he or she is talking about. The coach doesn’t have to be the smartest person in the room, or know the latest and greatest technology. But the coach absolutely must have the standing with the team to get them to change.

A good coach also has insight into the reasons why a team succeeds or fails. Most managers can correctly observe successes and failures, but a good coach will understand why things are going well, or not. Discovering those insights, and encouraging the team members to reflect and come up with their own, is a necessary activity for continuous improvement. This can be one of the most difficult things for a team to achieve, since the team must admit their mistakes and discuss why they happened. But when a team can honestly discuss their flaws, they can also find ways to address them.

Of course, insight and credibility are only useful if the coach knows how to communicate with the team. Change can happen only when the team can identify alternatives, discuss the benefits and drawbacks of each, and come to consensus on the way forward. The coach needs to be able to articulate his or her own ideas to the team, but also needs to be able to listen to the team members and help them structure their own thoughts. Creating that environment where team members are free to express their observations about how the work is done, and what could be done better, is one of the most powerful things a coach can do to support organizational change.

While there’s no bright line between the definitions of managercoach, or leader, I think it’s critically important for software development managers to think of themselves as coaches. It’s not enough to observe how the team functions. The manager must also analyze the team’s performance, determine what changes to make and motivate the team to make those changes. The best coaches will involve their team members in that conversation, turning each one of them into a source of great ideas for improvement. Not every team will be able to function at that level, but without a good coach, none of them will.


Lessons from a struggling software project – Step 2: Assess the indicators

Struggling ProjectsIn our Fractional CTO™ practice we often help distressed software development teams in the middle of a struggling project, or right after one has failed. Regardless of the size of the organization or project, the failures are usually caused by tensions between the definition of the end result and the process by which the team attempts to accomplish it.

In this series we are exploring our approach to identifying and addressing project failures in the hopes of enabling you to capitalize on our lessons learned. We break the process into four steps; identify the failure scenario, assess the indicators of project risk, identify the root causes, and then formulate a remedy.

The first step in the process helped us come to agreement with the team on what results from their project experience they are dissatisfied with. In the second step we identify the problem indicators. If you have a failure on your hands, identifying the symptoms is validation that you are dealing with the problems you perceived and may help in addressing them for future projects. Early identification of these problem indicators can save a project and the team a lot of aggravation. Resolving these issues early will help forge a stronger and more collaborative team, capable of accomplishing great things. While there are a many indicators, there are a few that come up frequently in our analysis. These are red flags that every team should learn to identify, discuss, and address immediately.

When will we be done?

Teams that cannot effectively estimate their work set themselves up for failure. Management, investors and sometimes customers need to know when the milestones will be achieved and the overall task or project will be completed. A team’s ability to address this “need to know” will build goodwill and credibility.  Since there are many dependencies within a business it is critical to have sound estimation processes to ensure product readiness and project completion so the rest of the business can plan around it.

Estimation is an art as much as a science and the best we can do is balance setting realistic expectations with meeting our commitments.  Communication and transparency are important but in the end a team that can’t tell when they will be done may never get the chance to find out. After all who wants to invest in “I don’t know when we will have a product”?

What granularity of certainty you can provide is dependent on several factors including clarity of requirements, experience of the team, etc. Often it is more important how you frame the answer. That is because on projects it is quite common to deal with “unknowns”. As software developers, we know it is hard or impossible to estimate the unknown which is why effective teams strive to reduce the unknowns to a minimum.  So while all projects have risk, your team should work hard to identify, isolate and minimize estimation risk.

Team stability impacts risk

Whenever a team adopts a new tool, framework, method, or works on a problem they have never encountered before they are introducing estimation risk. Additionally, changing the makeup of the team can have significant impact on short-term estimation. A stable project team tends to improve the predictability of the work product. As you change the makeup of your team you may improve the future results but you make estimation more difficult in the short run.  This is necessary sometimes but should not be discounted as a factor when planning work or setting release date expectations. A team member that is new or one that leaves will affect the overall team dynamics. While this change may be positive overall, it still means planning impact for a few development cycles while the team re-forms itself.

Most people realize if you lose your best programmer it will have an impact on your ability to get work done or estimate work, but do you also realize adding a great programmer can slow you down too? You add a capable person to the team and all of a sudden everyone needs to reconfigure what they do.

Steve used to handle the database but should the new guy do it? Well, Steve is also good at UI but Sandy was doing that… In addition, turns out the new guy isn’t a great communicator so we have to learn how to talk and build trust all over again…

So teams matter whether you are adding or removing people, you are introducing estimation risk in the short-term and need to expect your release to be impacted somewhat. There are many approaches to minimizing this reality but it’s beyond the scope of this post.

Quality impacts risk

In addition, the product quality can significantly affect the estimation as well.  The more robust your quality process, the less you need to factor in the unknown risk related to bugs, testing, etc. This is one reason that the industry is trending towards implementing Test Driven Development  and other related strategies for identifying failures early and often.

Process impacts risk

Another cause for poor estimation can be undisciplined process. If you don’t follow a predictable process it is hard to predict results. This is why baseball pitchers have a routine before they throw. These habits allow us to predict the outcome more effectively. It doesn’t guarantee success but it does increase the likelihood when everyone is following a consistent process. All processes and situations are not created equal so it is  important to periodically re-evaluate your process and improve it.

When we think of process in this context we mean a framework for how work gets done. The framework should provide transparency and allow for change. It should support and encourage best practices in all aspects of software development.

Grumbling undertones

The human dimension to software projects is fascinating. There are so many variables in our relationships and interactions. One indication of a problem that can not be overlooked is interpersonal hostility. If dissent is identified on the team it must be dealt with. It’s not that we must like everyone else on the team (although it is great when it happens) but there must be mutual respect. If there is a lack of respect, then it is time to change the team dynamic as it will impact the team’s ability to communicate. An open and collaborative environment is what every software team should strive for. There are variations on this issue that we deal with but regardless, personal conflicts cannot be ignored. It would be like drinking a little poison every day. It may not kill you today but it will eventually.

Excessive refactoring

Refactoring, or improving your code as you work on new tasks is a good idea. However excessive refactoring may be a red flag of some underlying problem with the software design, or a conflict where developers feel the need to “fix” each others code due to preferences in style. It may also be a symptom of a weak developer that needs more training.  If it’s just a preference issue then perhaps a coding style guide is needed to define the expected style. If the issue is a more severe design problem it should be addressed immediately. Peer review of code is one strategy to address this.  Static analysis tools can also be helpful identifying issues such as complexity, security, and consistency.

The hero

When you find your project being bottlenecked because only one person knows how to do something you have the Hero problem. Regardless of team size it is a significant risk to have dependency on one individual. Having a strong developer is great, but it is important to educate and balance the entire team through a variety of strategies such as code reviews, peer programming and other techniques. Without addressing this, projects will struggle to be predictable if/when something happens to your hero. In larger organizations the hero can be an entire team or department. Silo’d intelligence and expertise leads to a brittle organization. Specialization is useful but agile teams need to have individuals that are fairly interchangeable for when the need arises. Otherwise no one can go on vacation, get sick, leave. So whether you are a large organization with multiple development practices or you are a start up with two technical founders it is important to share knowledge. Of course if you only have one programmer you can’t do much about this, but everyone else should fix this.

Developers hitching a ride

Sensing that certain team members are just along for the ride indicates a problem. When a developer frequently asks “what to do you want me to do?” rather than telling you “here is what I think I should do” they are likely indicating they have become a “project hitchhiker,” someone that doesn’t feel empowered or engaged and is “just doing their job” – just along for the ride. These resources are generally not emotionally invested and do not care if the team succeeds and they may not feel responsible when they miss their commitments. Another sign of this is when the team member stops asking why the business wants some feature. When they don’t care about “why” they are doing something they will eventually stop caring about “what” they are doing and this can lead to them not caring about “when” it is done. This results in commitment failure,  which is devastating to an agile team.

This problem can manifest itself in the team’s inability to hit dates and increased defect rates; bug counts climb when there is apathy towards quality.  We often engage in correcting this problem but each situation is unique in this regard and requires different approaches to address it. Often times the problem is not with the developer, rather it is with the management or the culture. So in those cases the “fix” is not simple but it is achievable and necessary.

Avoiding commitment

There are many reasons why a team or a team member may not commit or deliver successfully. They may be apathetic as described above but they also may be passionate about the product or the company and are struggling with management not providing adequate guidance, process, tools, etc. So when you find your team is either not actively committing or they are failing to deliver on their commitments, certainly scrutinize that behavior but also be willing to look in the mirror.

Bugs everywhere

Problems with your software are never good but they should be expected, especially early on in the development process. Learning from these early mistakes to improve the development process is key; using tools to track defects and resolution rates as well as openly discussing strategies within your team will increase quality.  Increasing bug rates over time should trigger a review of the quality processes so the team can collaborate on ways to improve. When defect rates get too high it is hard to deliver software on a predictable schedule or with any predictable quality, so keep a watchful eye on the defect trends and be determined to understand the underlying issues.

Head in the sand

So you have a good process in place, your team is collaborating well and is stable. The development process seems effective and the team is routinely working together on identifying process issues to address. So now what’s the problem? You may be surprised at the number of times organizations identify risks but never prioritize or strategize on how to deal with them or take action. You need to insist on solutions and action plans whenever you find a flaw in your process. It’s not sufficient to identify a problem, or even a solution. Specific actions must be taken. Don’t reward complaining, reward solutions and action. Here are two common examples of areas where people see the problem and inexplicably take no action until it is too late:

Technical Debt -  Code that is inefficient or complicated or broken is referred to as “Technical Debt”. It’s a debt you will pay down the road. It might show itself as an unexpected bug, a feature that is much harder and more expensive to implement than anticipated, or difficulty training new developers due to overly complex or convoluted code and process. Some amount of technical debt is expected but managing this down needs to be part of your process because if it gets out of control it can cripple your product development.

Disaster Recovery / Business Continuity - Companies recognize they have single points of failure in their infrastructure or their people but they choose to justify ignoring the problem because of competing priorities, or lack of resources, or lack of understanding of how to address the issue. This type of risk can grow and become much harder to fix later. That is, if you are fortunate enough to make it to a fix before a disaster strikes.

Project Management

There are of course many indicators that a project is in trouble. If you learn to watch for them early on you can avoid the project disasters altogether and have a much more rewarding experience. Most of these typical indicators that a project is at risk have specific root causes within the organization and they are usually not technical issues at their core. In the next installment we’ll look at some of the more common root causes for projects getting into trouble to help you recognize them in your own organization and avoid these project issues altogether.

If you have any war stories and observations on this topic we would love to hear from you. By sharing our experience we can all improve our process and deliver high-quality solutions.

Working on policies that affect innovators


ACT Fly-in group at Capitol Hill. Picture courtesy of Ann Caldwell Adair


Last Sunday, I traveled to Washington, D.C. to meet and educate elected officials and regulators on the status of the tech industry. At NeuEon I specialize in helping small to mid-size companies implement best practices in software development. I am also a founding member of MomsWithApps which is dedicated to helping family-friendly app developers succeed. For the past four years I have made this trip to DC with the goal of representing the interests of our clients and the developer community.


Me and Parick Larsson of HappiPapi ( heading into talk with Rep. Kennedy’s staff.

As part of ACT | The App Association’s annual fly-in, I joined executives of 50 tech companies from across the country to advocate for an environment that encourages innovation and inspires growth. During my time there, I met with the staff of Representative Joe Kennedy and Senator Ed Markey as well as several members of the Federal Trade Commission (FTC), including the staffs of Commissioners Terrell McSweeney and Maureen Ohlhausen and personally with Commission Julie Brill. I found the staff  of Representative Kennedy and Senator Markey to be knowledgeable, inquisitive and supportive of Massachusetts tech companies. While we didn’t agree on all issues, it is clear that they were interested in our concerns and wanted to engage. My message was simple. Companies that NeuEon works with and the thousands of small developers I represent in our development community are creating solutions that are improving lives, creating jobs, and invigorating our economy. However, we want policymakers in Washington to understand and address issues threatening small tech companies in order to ensure growth continues.

The concerns I raised included data privacy and security, Internet governance, intellectual property and patent reform, education regulation, and regulatory obstacles to growth. These are important issues for which the federal government is considering taking action.


Betsy Furler of Showing Commissioner Brill how apps are helping children with disabilities function successfully> Her presentation is great and brought some officials to tears.

With the FTC I have been having these conversations for several years so those meetings were more of a check up. We discussed the progress the FTC has made with  the COPPA rule refinements. Improved definitions in the FAQ have helped companies adhere to the rules. However we pointed out that there still isn’t a low-cost, viable, popular  parental consent mechanism that meets their criteria. We also pointed out that we need the FTC to take action against bad actors so that the rest of us that are going through hurdles to comply feel there is an incentive for doing this additional work to protect our children’s privacy. Most of us want to protect children but the cost of complying with COPPA is significant. We also discussed the confusion between  FERPA and COPPA and we heard that there is some movement towards reconciling these and some talk of consolidation which I think would be good for the industry. For instance, right now under COPPA if I have an app that analyzes writing difficulties of a child and I send my analysis to some other vendor’s app that provides specific remediation this would be considered a violation of COPPA without parental consent. However use the same two independent apps in a school and this would be ok under FERPA since you are allowed to share data in a school setting for the purpose of education. So companies need to know how their app is going to be used to be in compliance? This doesn’t make sense. I’m sure I’m misunderstanding the law somehow but the commissioners were scratching their head in the meeting too.

We were able to cover many issues and here are some highlights of the key issues we covered:

Digital privacy reform through the LEADS Act

An important issue I highlighted was the need for digital privacy reform. Currently, the U.S. Department of Justice claims that it possesses the authority to access data stored abroad by a foreign citizen anywhere in the world. When DOJ exercises this authority, it forces U.S. companies to violate the laws of countries in which they operate.

U.S. software companies and cloud service providers have data storage locations around the world to meet the demands of global commerce. Companies both big and small are able to attract customers abroad through the efficiencies provided by the cloud. Unfortunately, the Justice Department’s actions threaten our access to these markets.

Any company I represent that has servers in foreign countries are at risk of losing customers that don’t want to be subject to US law in their own country.   Furthermore, my clients are at risk of being forced to break laws of the countries they are working in if they are compelled by the US government to turn over data stored in those countries.

This problem can’t be fixed without action from Congress. The LEADS Act provides the appropriate balance between the needs of law enforcement to conduct criminal investigations and the demand for privacy by our trading partners overseas.

Specifically, the LEADS Act clarifies that U.S. warrants must comply with the law of the country where the data resides, or requests must be made through existing treaties for bilateral cooperation. To assist law enforcement, the LEADS Act also provides technical updates that will greatly improve the speed and efficiency of information exchange between countries cooperating in criminal investigations.

Passage of the LEADS Act is critical to the future of companies I represent, and I’ve encouraged Representative Kennedy and Senator Markey to cosponsor this important piece of legislation.

Patent reform through the Innovation Act

Another issue that I raised was the need for patent reform. Patents are important for innovation in mobile technology, but flaws in the patent system have allowed for the rise of patent trolls. These bad actors intimidate startups and small companies by making confusing and vague claims of patent infringement, essentially blackmailing companies to pay them for licenses. Reform is needed to ensure the patent system is a boon, not a bane, for companies like mine.

I encouraged the offices I met with to cosponsor a piece of legislation called the Innovation Act. The bill works to protect companies by requiring transparency in patent ownership, transparency in what the patent owner claims as infringement, and ensures that the patent abusers cover the costs and attorney’s fees of small companies that are wrongfully sued. Innovators like us need a healthy, quality patent system and the Innovation Act will help protect the interests of of developers.

I’m always impressed with the passion of the people that come to this event and really appreciate the strong showing from the MomsWithApps group.  Over there years, we have made a significant impact and we will continue to push for a better climate for business and innovation while looking out for the privacy rights of our citizens. If you want to get involved let me know. We always can use more voices because we know you can help us make a difference too.

Entrepreneurial Thinking

I recently gave a talk to the Cape Cod Young Professionals’ (CCYP) Mentor Exchange on Entrepreneurial Thinking and Thinking Like an Owner. I use the phrase “thinking like an owner” when referring to employees who have a strong work ethic and go the extra mile. There are a number of characteristics I outlined with the group of mentors/mentees who have been participating in the program. The first was debunking the myth that being a business owner is not really working for yourself per se. When you are an employee you have a pretty clear idea of who you work for. When you’re a business owner, you work for everyone; customers, employees, shareholders, board of directors, investors, etc. The other characteristic of thinking like an owner is doing tasks that technically don’t appear within your job description. It could be as simple as taking out theshutterstock_144471493 trash, answering the phone, or greeting a customer. It could also be taking on a special project, staying a little later/coming in a bit earlier, and showing the owner you care about their business to do what it takes. These little things go a long way toward ingratiating yourself with a business owner and nothing drives them crazier than when an employee claims “that’s not my job” if asked to do an extra task.

During the next part of the talk, I focused on concepts and characteristics which drive the entrepreneurial mindset. Four I can especially relate to and defend.
1. Know your customer: This is the most important part of being an entrepreneur. Knowing what your customer looks like, thinks about, and wants. Specifically, what problems you can solve for them, what pains they have, and what gains or benefits they are looking for when you perform a job for them.
2. Attitude is everything: I explained how a positive, welcoming, and optimistic attitude will help you succeed as an entrepreneur. It is amazing how well your customers, employees, and vendors respond when you treat them with a positive attitude.
3. Don’t fall in love with your concept: This seems like a simple statement, but entrepreneurs often become myopic and defensive about their concepts. When you get out of the building and actually talk to real customers, you may discover they may not want what you have to offer. Based on what you hear from your customers, you may need to kill it, adapt it, or pivot away from your original concept.
4. Failure is an option: True entrepreneurs embrace the concept of failing fast, knowing how to do it gracefully, and learning from the experience.

I have learned and adapted many of these four concepts from the great work done by Eric Reiss (Lean Startup), Steve Blank (Startup Owner’s Manual), and Alex Osterwaller (Business Model Generation and Value Proposition Design).

How will you differentiate yourself ? – Getting ahead of the competition in the life insurance industry


At NeuEon, our success has been built on our deep domain expertise and our ability to become trusted advisors for our clients. One industry we have the pleasure of working in, is Life Insurance.  Some of the brightest minds in this business ask us,  “What are my competitors doing to stay ahead of everyone else in the market place?”. Most firms want to focus on accelerating the introduction of new products, riders, and features to increase market share and new premium revenue.

Our clients often lament on their inability to introduce innovative products and offerings to the market in a timely fashion.  The cause for delays are always related to market focus, product launch, project implementations, and resource issues. In general, we find that client resources are continually being dragged down in the day-to-day tactical fire fighting which does not allow them to look strategically across the enterprise to increase efficiencies.

Over the next few weeks we will discuss the benefits of stepping back and assessing the overall health of your business technology vision, including:

  • Market segmentation – The traditional demographic of your client base will be changing as younger generations entering the market with different needs and priorities.
  • Process Standardization - Effective project and cost management can be achieved by utilizing “playbooks” and standards for repeated periodic events such as changes to investment options, forms, and new rider launches.
  • Straight Through Processing - Service is a significant differentiator, it must be easy to do business with a firm from a distribution, policy issuance, and in-force processing perspective.
  • Data Management – Effective data management will enable leadership to make smart business decisions based on consistent data.  It also provides consistency to the end client.
  • Platform Rationalization – Companies have created more and more complexity in their technology stack through M&A activity, as well as, a lack of sun-setting legacy platforms as new technologies are introduced.

These are complex topics spanning the front, middle, and back offices of an insurance company. This series will provide an appreciation for the technical and business strategies we have helped our clients with in order to optimize their organizations for the future.

Are you managing your technical debt?

shutterstock_147127772All software organizations accrue technical debt. Some, our actions add to our debt. Every time we copy and paste a block of code and make one little change, or use a library for something other than its intended purpose, we ring up another small amount of technical debt. Other times, the debt accrues through inaction. Ignoring compiler warnings, failing to document code, or sticking with a technology platform longer than we should have can all make a codebase more difficult to live with. In all these cases, we end up with something that isn’t as good as we know it could be.

We usually create technical debt for the best of reasons. Most often, we’re in a rush to make a deadline. It’s easy to tell ourselves: We got it working, even if it is a little ugly. We need to move on to the next item. We’ll come back and clean that up later. In many organizations, “later” never comes. Once the code is in production and working, it’s more difficult to justify expending effort to change it. If you have poor regression test coverage, you might even be scared to change it. Over time, your state-of-the art code turns into a confusing jumble of workarounds. Your team velocity declines, and morale goes with it. Your developers know they could make things better, if they only had the time…

The best way of dealing with that situation is to avoid it in the first place. There are three main things you should do, as a software development manager and leader, to keep your technical debt under control:

1. Set standards that reduce opportunities for technical debt. Having a strong set of standards for code formatting, use of frameworks and third-party libraries, and unit test coverage will help the team maintain consistency and good structure in the code. All team members should be empowered to hold each other accountable to these standards, but as the manager, you will need to know what “good” looks like and take the lead in establishing the standards if they’re not in place. Some team members may grumble, but eventually most will see the utility of adhering to these standards.

2. Describe your technical debt. At some point, the team will decide that the best course of action is to accrue a debt in order to reach a goal. When that happens, you should add a corrective action to your backlog. The only way the team will remember to go back and address these things is to write them down. Having technical debt backlog items also allows you to estimate the amount of time and effort it will take your team to address the debt. You may want to create a backlog item type specifically for technical debt, to distinguish it from the typical user stories and bugs.

3. Prioritize technical debt items along with other backlog items. Once you’ve described your debts, you’ll only pay them off if you give the team time to work on them. The best way to do that is to include technical debt items with your other backlog items, and prioritize them together. If you’re following a Scrum process, your team may need to educate the product owner on the need for these items. Your developers must be prepared to advocate for their items in terms of the business value they will deliver. If there’s no business impact (perhaps increased quality or development efficiency), why is the item in the backlog?

Doing these three things will put you in control of your technical debt. You should not attempt to eliminate all debts, but you should make sure you don’t acquire more debt than your team can handle over the long term. What if you’re inherited a legacy code base that seems to be nothing but unaddressed technical debt? That’s a difficult situation, but one that most of us have seen before. We’ll tackle that in a future post.

‘FREAK’ flaw undermines security for Apple and Google users, researchers discover – The Washington Post

Technology companies are scrambling to fix a major security flaw that for more than a decade left users of Apple and Google devices vulnerable to hacking when they visited millions of supposedly secure Web sites, including, and

This appears to be a flaw you should know about.  It affects Apple and Android devices as well as Web browsers but a fix is in the works. For more information see:

‘FREAK’ flaw undermines security for Apple and Google users, researchers discover – The Washington Post.

Lessons from a struggling software project – Step 1: Identify the failure scenario

Struggling ProjectsIn our Fractional CTO™ practice we often help distressed software development teams in the middle of a struggling project, or right after one has failed. Regardless of the size of the organization or project, the failures are usually caused by tensions between the definition of the end result and the process by which the team attempts to accomplish it.

In this series we will explore our approach to identifying and addressing project failures in the hopes of enabling you to capitalize on our lessons learned. We break the process into four steps; identify the failure scenario, assess the indicators of project risk, identify the root causes, and then formulate a remedy.

Step 1: Identify the failure scenario

Every new situation requires us to first identify the type of project “failure” the client perceives they are dealing with. We want to identify themes in order to build team consensus and understanding of the issues from a strategic point of view. Later we will create an action plan to resolve the issues. Typically, project challenges fall into any of the four categories described below. If you have ever struggled with a software project these categories may sound familiar.

Financial disaster

There are many reasons why a project may feel like it is sucking money. So when it becomes clear management views the project as an endless stream of unplanned costs we focus on that. This could be a lack of cost controls, poor project management or software quality and practices, or a variety of other challenges in the SDLC that we will try to identify in a later stage of investigation. Usually this can lead to other serious problems and significantly erode trust and communication and force bad choices. For instance, you don’t want to throw good money after bad but replacing the team or changing the project goals may make things worse. It’s important to get to the root of the problem quickly before this high burn rate leaves you with no good options. When this happens project termination, or abandonment is often the result.

Unending scope creep

The project requirements continually change resulting in a seemingly never-ending project with more and more features but no sense of completion. In some cases there may be no releases, just a steady stream of new requirements. A variation on this is a sense that the software isn’t “perfect” so it is either never released or the release is never considered worthy due to constant tweaking. This could be due to poor quality in any stage of the Software Development Life Cycle (SDLC) combined with unrealistic expectations. There is simply no clear strategy for calling the project “done”.

Over the course of these projects Management will often ask “Why can’t we ever ship anything?” or “This seems simple, why can’t we finish it?” It is common to hear the development team in these situations complain that, “Every time we show Management/The Customer our progress they change what they want.”

The result will often be that Management becomes frustrated with the lack of a released product and out of control costs. Meanwhile this endless drip of requirements can lead to low development team morale since they want to feel accomplished. What’s worse, this deterioration of morale can lead to a lack of project commitment since the team will feel like they can’t finish anything and that feeling slowly becomes the accepted cultural norm.

Bitter endings

The team finally hits their milestones but the project is not viewed as worthwhile upon completion. The perception may be the overall costs were too high, “nobody” is finding the new features helpful, it’s possible the original intent and need has been forgotten. Even worse, the resources, who are now burned out, could have been better utilized. As technical leaders ourselves it hurts to recognize the tremendous amount of energy and creativity that went into a project which when finally completed no longer represents core business value. We find this more often in non-agile projects, however even projects utilizing tight iterations can suffer from this disconnect when there is a lack of real product ownership and an uncommitted team that doesn’t challenge weak requirements or focus on consistently delivering value.


When a project fails it may end up getting turned off, resources reallocated or let go. For a small company this could be the end. For a larger company it could be the end of a strategic vision or it could be wasted money followed by a reboot with a different team or approach. Abandonment is the result of not identifying the signs of a project at risk and taking action soon enough. The mistake many companies make with this type of result is they don’t learn enough from it. Taking the time to really do a detailed and constructive analysis of what happened can be invaluable, in fact, in the long run it could be more valuable than the promise of the original project. If an organization learns sufficient lessons from their mistakes they can become a stronger and more effective organization. So while this may be the worst of all outcomes for a project it doesn’t have to be a complete waste for the company.

Project ManagementThere are of course many types of failures but these four general scenarios cover the majority of situations we help to unwind and improve. They are also in the back of our mind whenever we are helping to launch new project initiatives as serious risks to avoid. Understanding where the project stands and having the team come to consensus is the first step in fixing the problem or avoiding it in the future. In the next installment we will examine some of the underlying indicators that help us clue in where the issues are percolating so we can later hone in and address them. These key issues are also important areas for new teams to learn to avoid and address quickly so their project doesn’t end up in one of the failure scenarios.

If you have any war stories and observations on this topic we would love to hear from you. By sharing our experience we can all improve our process and deliver high-quality solutions.


Commitment to Process – Key Quality of Successful Development Teams

CommitmentOne of the benefits of the work we do at NeuEon is that we have the opportunity to work alongside some very talented developers.  Yet, more often than not, we find that one of the reasons most products fail and why most development teams are not successful in meeting their objectives has nothing to do with their ability to write code. One of the reasons most teams fail is because they do not follow a disciplined process for building production quality software. The actual process a team subscribes to is less important than the fact that they have one. You could argue that one methodology is more effective than another.  We happen to like Scrum, but there are others that are just as good.

Once the team determines the methodology will follow, it is imperative that they commit to it and hold each other accountable to it.  Let’s use the Scrum process as an example.  The knock on Scrum is that it is too rigid.  The reality is that Scrum has very few rules, however the few that do exist must be followed with the utmost discipline or else the process and the team will likely fail.  Scrum calls for a select number of meetings that happen in regular intervals.  These events include:

  • Sprint Planning Session – occurs at the start of each development sprint to allow the Product Owner to communicate the priority of the stories that the development team need to complete during the sprint.
  • Daily Standup – occurs every day for upto 15 minutes in which all members of the development team answer three very specific questions – 1.) What did I complete yesterday; 2.) What do I plan on working on today; 3.) What roadblocks do I have that I need help removing
  • Sprint Review – occurs at the end of the development sprint.  The development team demonstrates the work that was completed in order to give the Product Owner and stakeholders the opportunity to sign off that work was completed as specified.
  • Sprint Retrospective – occurs immediately following the Sprint Review to allow the development team to discuss how the team can improve.  During the retrospective teams ask 1.) What did we do well – what should we do more of?;  2.) What didn’t we do well – what should we do less of?

There are obviously many other principals of the Scrum development methodology such as story estimation, acceptance criteria, backlog grooming, etc., however for the purposes of this article we are going to focus on the four mentioned above.

The interval in which these meetings occur may vary from project to project depending on the length of your sprint.  What should not change is when they take place.  The Sprint Planning Session takes place on the first day of the sprint, and the Sprint Review and Retrospective occur on the last day of the sprint.  These meetings must be scheduled as recurring events on the team’s calendars.  Successful teams hold each other accountable for attending every meeting and coming prepared.

During the course of every development sprint emergencies occur, and priorities are challenged constantly.  What must stay constant however is the commitment to the process.  Early in the process it may feel as if the “overhead” of the process is getting in the way of completing tasks, but the time spent is essential for long-term efficiencies.  A common statement we hear is, “I can’t make it to the planning session because I have to finish a deliverable for this afternoon.”  This is unacceptable.  Good teams create a culture of that puts the process as a top priority.  It is the responsibility of each individual to plan their availability and forecast deliverables around the commitments of the process.

When you join a Scrum team you commit to the team and the process.  The meetings are critical to the success of the project and in start-ups, the business.  Early in our involvement with new teams, we ask them to look around the room and count up the hourly rate of each team member to put a dollar amount to the meeting.  This inevitably gets the attention of  the business owner when they view it from a financial perspective.  In many cases these meetings cost the company thousands of dollars.  When individuals and the team do not approach these meetings with the necessary commitment and diligence, it has a negative impact on the business not only on productivity, but financially as well.

On Being Remote and Not

We subscribe to many of the points outlined in “Remote: Office Not Required” by Jason Fried and David Heinemeier Hansson.  Especially the concept of getting together in person from time to time.

Remote: Office Not Required

Remote: Office Not Required

In January we had the chance to meet for our annual company meeting. It was a chance to have team members that have only met via Google Hangouts and GotoMeeting to meet in person. Our annual gatherings tend to be set up similar to a scrum planning day. There’s a bit of retrospective about the year that just passed, analyze what works and doesn’t work and review the results that we have achieved. The other half of the meeting is dedicated to planning for the upcoming year in which we look at goals and objectives and agree on what we’re committing to as a team. We also review any changes in our services as well as internal operational items like employee benefits. This is a great time to get to know each other and share a meal or two, and this year was no exception. These annual events have been so successful that we are exploring other ways to get together more frequently throughout the year.

In addition to our company-wide gathering, our leadership team took the opportunity to do our quarterly off-site planning session this past weekend. This time we were fortunate to be in Lake Placid where the weather was conducive to both outdoor activities and getting some work done. We set a theme or topic for the weekend that we want to tackle and discuss in detail – this weekend was all about marketing. This served as the topic of conversation throughout the weekend – as well as in the car and even on the ski lift.

In the past few weeks, it has become even more compelling to be a 100% remote-only company. Those of us in the Northeast of the United States and more specifically in Eastern Massachusetts have been subject to a crippling amount of snowfall. This extreme weather has made virtual meeting technologies a critical investment for us and reinforced our belief in our “Remote: Office Not Required” philosophy.