Agile Project Management Works for Small Businesses

Guest Post

I’m pleased to share this post written by the folks at Agil8.

Project management systems are not methods that are just for big businesses and large-scale organisations alone. They are also suitable for smaller businesses that can benefit a great deal from these methods too.

The fundamental principles of project management can be successfully applied to all businesses regardless of their size. Agile Project Management methods are now being adopted by small businesses across a broad range of sectors, in order to carry out a variety of different types of projects successfully.

What Is A Project?

A project describes any type of activity that is carried out alongside, or in addition to the usual day-to-day running of the business that requires specific attention within an agreed and established timeframe.

What Is Project Management?

Project Management involves the planning and establishing of objectives, allocation of a budget and the distribution of responsibilities within a team in order to work towards a goal or objective. Traditionally this has meant a team working under a project manager who controls and is responsible for the project.

What Is Agile Project Management?

Agile Project Management uses modern methods which differ a great deal from the more traditional approach to project management. Agile Project Management methods embrace a highly versatile approach which allows a team to define a clear objective, then evaluate and adapt the path of the project together, in stages as it develops organically.

This flexibility has great advantages over the more traditional methods which plan the entire project in advance and work towards the objective following that plan, regardless of any changes that may occur along the way. This type of rigid planning is highly inflexible and makes no allowances for any potential obstacles, or changes.

So How Can Agile Project Management Help My Small Business?

A project can enable your small business to be innovative, in order to grow and expand. Perhaps your objective is to attract new clients in order to increase sales and boost revenue, or maybe you are keen to diversify in order to broaden your current business opportunities.

Whatever the objective, a project when it is planned effectively and well coordinated and evaluated at each and every stage, can help your small business to achieve its desired goal. With Agile Project Management, the whole team of employees within the business, pool their skills and resources and work together to achieve the objective of the project through careful planning, communication and teamwork. Tasks are shared and allocated to team members according to their particular skill or expertise.

Each project is approached in small iterations, or ‘mini-objectives’, based on short time scales. The team meets regularly to evaluate progress and plan and coordinate the next step. This highly flexible and interactive approach to managing a project allows the team to react to any internal or external changes as and when they arise, quickly and effectively. At times, certain changes will significantly alter the path of the project and this is where you can appreciate the real benefit of working with Agile Project Management which is designed to adapt and respond to change in a positive way.

This flexibility is a crucial, key element in any Agile Management Project; therefore any businesses that prefer to adhere to strict project processes would not find this particular way of approaching project management suitable for them.

Agile Project Management – What Are The Real Benefits?

Because Agile Project Management involves the whole team, who collectively share responsibility for a project, it tends to have a very positive impact on team morale and the whole working environment. Individuals feel far more focused and motivated and it is this boost to team morale that has a knock on effect on levels of productivity and performance, which will in turn increase revenue.

Go For It!

In reality, the need to manage budgets and deadlines and to satisfy your customers and clients with efficient delivery of your product or service, is identical and of equal importance to that of any other business, just on a slightly different scale. The fact that your business is small does not mean you should shy away from project management, or do not need it and should just stick to what you are doing already.

Agile Project Management can support your small business and make it more successful through effectively managing your projects in a flexible manner with the involvement of your whole team.

Guest Author: Agil8 offers the highest quality Agile consulting and training. The company was formed by David Hicks, a pioneer of Agile since the mid-1990s, an Agile Alliance Founder and one of the world’s most experienced and qualified Agile consultants and trainers. Agil8 draws on experience of working with organisations across all industry sectors over many years, and the management and delivery of some of the world’s largest and most complex Agile implementations.

Image Credits: shutterstock

10 Steps to Avoid Selecting the Wrong Business Software (Part 2)

This is the second part of this two-part blog entry discussing how to select commercial-off-the-shelf (COTS) software. It’s often better to buy than build – if you go about it the right way.

Part 1 of this article is available here.

6. Use spreadsheet comparisons wisely

Too many companies prepare elegant spreadsheets showing long lists of features and functions with checkmarks indicating which vendor meets the criteria. This is a worthwhile exercise though there has to be serious human interaction to qualify the gray areas that aren’t practical to model.

Scoring systems are also popular but they’re only useful if the system is two-dimensional. The second dimension is priority or value. You can assign a score based on how well you believe a package performs a function. Now multiply that score by the priority of the function. The result is the true value of the function. Software that does what you don’t need isn’t high in value to you, is it?

7. Map features to real business processes

Companies need software that’s connected to real business practices. Are you willing to change the way you conduct business in order to get maximum value out of the software investment? Or, do you expect the software to support the way you do things today?

Many companies buy good quality software that’s a poor match to how they run their businesses hoping that the purchase will drive change. This doesn’t work! Change has to be driven by the business with the support of the technology. Software enables change but can’t drive it.

8. Get a demo that’s pertinent to your situation

Face it; canned demos always make the product look good. Demonstrations are carefully crafted to show the best features of the software. Prepare your own demo. Develop a scenario and a set of activities that you want the software to perform. Send it to the sales person and request a demo that showcases your needs. To be fair, offer to help set up the demo with some sample data or other elements. This approach will create a level playing field, as every seller will be performing the same activities though in different ways and possibly in different sequences.

9. Find a good vendor match

Vendors will offer software to firms outside their typical target market. Identify the vendor’s sweet spot in terms of company size and industry segment. If you’re too small, you won’t get attention. If you’re too big, you’ll overwhelm them. If you’re outside their target industries, you’ll be blazing a new trail. There needs to be synergy between the two companies.

10. Take a broad view of costs

Consider all the costs of buying, installing, configuring and supporting a new application. Will the software run on the computers you have or will upgrades be needed? Can your network handle the additional load placed on it? How much and what type of training will be needed? Will any data conversion be required? How will your business be disrupted during the initial stages of implementation? What additional costs will be incurred due to the disruption?

Enterprise software is expensive. If it turns out not to be a good fit, the total outlay and lost business could be immeasurable. Given the investment, some extra time spent up front to truly understand what you need and what the sellers have to offer is well worth the effort.

10 Steps to Avoid Selecting the Wrong Business Software (Part 1)

This blog usually covers topics dealing with building enterprise software systems. I’m going to diverge a bit this time and discuss how to select commercial-off-the-shelf (COTS) software. Companies spend millions on COTS software and much of it is wasted. (I’ll post part 2 of this blog entry in a few days.)

Buying an enterprise-scale software package is an expensive proposition. The definition of enterprise scale for this post is any software package that requires a shared server computer and supports multiple users. The real cost of purchasing such a package includes the purchase price, maintenance fees, server cost, user training, support staff training and possible network infrastructure upgrades.

Selecting the wrong software presents more than cost issues, however. Employee morale and productivity can be severely impacted resulting in poor customer service, high error rates, and lost business. Don’t let this happen to you! Follow the steps outlined below and you’ll make the right choice.

1. Conduct a requirements and issues assessment

You can’t select complex business software when your organization is unclear about its objectives, priorities and constraints. A formal and lengthy analysis isn’t needed. Using a few structured joint requirements planning sessions with representatives from those groups most impacted by the software is usually sufficient.

Do this BEFORE you invite vendors to present their solutions. Take a hard look at the business processes that will leverage the software. Zero in on the activities you want to automate. Prioritize the capabilities you need using a simple three-level system.

• Essential – Failure to implement the capability means the system will not meet your needs.
• Important – Lacking the capability may affect customer or user satisfaction.
• Useful – No significant satisfaction or revenue impact is expected if the capability is missing.

2. Seek out objective advice

Many advisors earn commissions or advertising revenue from software vendors thus compromising their objectivity. Clearly, none of us are completely unbiased though anyone who makes money by swaying your decision simply cannot provide trustworthy guidance. Ask a potential advisor which companies and software packages he or she has recommended in the past, how often and why. Knowing a person’s bias can help you put their recommendations in context and challenge their ideas appropriately.

3. Gather all the relevant information

Meet with the sales people. They may work directly for the software company or for a reseller. Either is fine but for a major expenditure, you’re justified in asking to speak directly with experts at the software firm to get first hand answers to complex questions. Sales people are interested in account control and they should be. But you have a right to speak directly with knowledgeable individuals who can answer questions that the sales person cannot.

If the software package is built using critical components from another software company, you are entitled to speak with the third party company as well. Problems at either firm could jeopardize your purchase. When checking references, ask for names of firms like your own and speak with people whose jobs depend on the software. A refusal to support this kind of dialogue should be viewed with great skepticism.

4. Consider more than just features and functions

Features and functions are quantitative. Sellers like to produce long lists of all the things the software can do. Any software package will do some things well and other things poorly. The qualitative aspects of package selection are equally important. Focus on the capabilities you need. Ignore all the bells and whistles you’ll rarely use.

Take a look at the frequency of patches, maintenance updates, and major releases. Compare these statistics among the sellers. You’ll usually find a pattern as they strive to maintain parity with one another. If you find a seller issuing far more or less updates than the others, you should ask why. Too many updates may indicate problems that are being frantically addressed. Too few updates might suggest lack of new investment in the software.

5. Understand the technology foundation

The software package should be founded on widely used technologies and should supply published interfaces for interacting with other software. Meeting these criteria will make it easier for you to find people well versed in the software and able to help should problems arise. It will also be much simpler to integrate the new software with other systems in your firm.

Beware of proprietary technologies. Proprietary is okay when the vendor can offer something truly unique and innovative. This is rare and you should avoid it unless you have an unusual need. Also be on the lookout for outdated technologies. If a product has been available for a long time and hasn’t undergone a major overhaul, be suspicious. It may be on its way out. You don’t need to be on the leading edge but you need technology with staying power.

Part 2 of this post is available here.

photo credit: sgs_1019 via photopin cc

Chickens, Pigs, Commitment and Teamwork

I’m sure you’ve heard the fable of the chicken and the pig as it applies to Scrum. In case you haven’t, it goes something like this:

Chicken: Hey, Pig, let’s open a restaurant.

Pig: Okay. What would we call it?

Chicken: How about ‘Ham ‘n Eggs’?

Pig: No thanks. I’d be committed but you’d only be involved.

The essential concept focuses on the level of commitment to a goal. In this story, the pig would be fully engaged and completely committed to the restaurant. He’d be “all in” by any definition. The chicken would play an important role but would not be as committed. (In other words, the chicken can do other things but the pig cannot.) It’s a fun way of making a point about level of commitment.

On Scrum teams, software developers and testers tend to be viewed as pigs because they are usually “all in”. Stakeholders, managers, end users, etc. are chickens because they support the pigs but aren’t fully engaged with them. As for Scrum Masters and Product Owners, ideally they should be dedicated and focused making them pigs. But if they have responsibilities outside the team, they are chickens.

Funny and Divisive

Regrettably, this funny story divides software development teams creating a kind of inner circle (the pigs) surrounded by outsiders (the chickens). For example, the inner circle gets to speak at Scrum meetings, while the outsiders have to stand against a wall and be quiet. Does that sound like teamwork and collaboration to you?

Everyone has a job to do. If anyone, inner circle or outsider, doesn’t do their part, the entire effort is in jeopardy. The best way to get people to do their part is to actively engage them. Draw them in. Encourage their active participation. Recognize them for their contributions.

I really wish that old Scrum story would just go away. I don’t like being thought of as a chicken or a pig. The story has served its purpose and outlived its usefulness. I think we need to move on. How do you feel about it?

photo credit: drp via photopin cc

Arguments About the Value of IT Are All Wrong

There are endless arguments around whether IT is a support function or a strategic office. Neither side can win the arguments because they’re both wrong. IT occupies a middle ground that’s unique in the enterprise and can’t be classified like other departments.

What is Information Technology? What does an IT department do?

Would you believe that in an industry littered with standards for almost everything there’s no standard definition of IT?

Several years ago, the Information Technology Association of America published a 32-page document containing 25 unique definitions including its own. According to the ITAA, IT is “the study, design, development, implementation, support or management of computer-based information systems, particularly software applications and computer hardware.”

That either says it all or says nothing depending on your perspective. I find it rather meaningless so let me propose a completely new definition.

“Information Technology optimizes business processes by applying computer-based systems.”

Notice the focus on business process, not technology and not strategic company direction. IT has to carve out a middle ground where business meets technology.

Just as electricity enables our civilization to function, technology enables businesses to execute. Electricity and technology are meaningless in isolation. It’s how we use them that determines their value.

Extreme Positions

In my experience, IT organizations tend to fall into one of two extremes. They either focus on day-to-day operations or they focus on aligning themselves with the business. Both approaches are doomed to fail.

Running a business isn’t just about the daily activities that drive revenue. Everyone knows that – but it’s equally true that long-term business strategies don’t generate immediate cash flow.

CIOs tend to focus on one extreme or the other. Those with a technical background lean toward operations and infrastructure. Those with business acumen lean toward strategy and business alignment.

Think Convergence

Rarely do you find a CIO that understands how business and technology converge. Should IT focus on keeping the infrastructure running everyday or on adding measurable business value? I hope you realize that the answer is both.

If you focus only on daily operations, you’re simply a utility like the plumbing and electrical systems in your building. They are critically important to running the business but they add no value. In fact, they are expenses that every business tries to minimize.

Many companies have adopted operational standards like ITIL to improve daily operations. These management approaches can be helpful as long as you know what problems you’re trying to solve and what results you expect to get. Too often, ITIL is viewed as solution rather than a tool.

If your focus is strategic alignment and your infrastructure is inadequate for the company’s needs, you’ll never achieve alignment. It’s a hopeless endeavor.

Companies tend to be strategically driven either by marketing or product design. IT can help but face it, no company will enter a new market simply because IT can supply the needed technology. IT is an enabler not a strategy.

Technology Enables. People Solve.

While it should be obvious that daily operations and strategic direction are equally important, few IT organizations seem capable of doing both. This leads to unending arguments about the role and value of IT organizations and their leaders.

This poor understanding of the role of IT results in endless centralize vs. decentralize, outsource vs. insource, and too big vs. too small arguments. All of which contributes to hiring people with the wrong skill sets.

It takes many different kinds of people to operate an IT organization. The skill sets required are more diverse than in other departments. IT operations people have different skills than IT strategic planners. Many IT organizations are a hodge-podge of skill sets that overlap and conflict. The company needs them all, but they often don’t share common goals and objectives.

Technology can’t solve all problems or be all things to all people. At a tactical level, technology should make it easier and faster to conduct business. At a strategic level, it should enable new business opportunities by making information and knowledge available faster.

Focus on Business Process

Will the arguments about IT value ever end? Probably not, but give my definition a try. Focus on processes that run the business and drive key business decisions.

To optimize business processes, the underlying technology infrastructure has to be robust and reliable. In addition, strategic IT assets like software applications and databases must be highly tuned to the needs of the business.

Looked at this way, IT is neither tactical nor strategic. IT occupies a middle ground that helps the strategic business planners form a vision that’s executable.

photo credit: Chris Devers via photopin cc

Are You Accountable for Your Work? Let’s Hope So.

Are you accountable? Someone has to be. Work must get done. Software must be delivered. All the supporting artifacts that go into building great software must be created and maintained.

We all know that, right? But are you accountable? Is your work clearly defined? Do you know precisely what you have to do? Do you have a deadline to meet? Once you finish, do you know where to deliver the work output? Are you fully aware of the criteria for being “done”?

If you answered ‘no’ to any of those questions, your project is in trouble. In fact, your employment status may also be in trouble.

Accountability Matters

What’s the single most important trait in a good project manager? She holds people accountable. Say what you do and do what you say! It doesn’t have to be stressful. Deadlines don’t have to be tight. You simply need to know what needs to be done, when it needs to be completed, and deliver on time. A great project manager will hold you accountable.

Miss deadlines too often or repeatedly deliver incomplete artifacts and your time on her project will be limited.

Of course, Scrum teams don’t have project managers. They have Scrum Masters. Great Scrum teams self-organize with the guidance of a great Scrum Master. The entire team, including the Scrum Master, needs to be accountable. If anyone on the team drops the ball, misses deadlines or just gets sloppy, the Scrum Master has to focus attention on the problem and get the team to step it up.

Individuals are accountable for tasks and stories. Teams are accountable for sprints and releases. Scrum Masters are accountable for everything.

We should all welcome clearly defined activities. In fact, if someone is holding you accountable for something without specifying the delivery criteria, that person is doing a sloppy job. Hold him accountable! Make your manager, supervisor, project manager or Scrum Master clearly define what he wants and when he wants it. If he can’t do that, he cannot hold you accountable.

Don’t Go Too Far

By the way, none of this implies micromanagement. Establishing clear goals and deliverables is a good thing. Telling people how to do their jobs and looking over their shoulders is crossing the line. We want to be accountable, not leashed.

Accountability is not about identifying someone to blame or having one neck to strangle. It’s about delivering great software in a structured and reliable manner. Pick whatever approach to software development that works for your team and your company. Just remember that if I buy or use your software, I will hold you accountable.

photo credit: shareski via photopin cc

10 Common Mistakes Account for Many Project Failures

There are many more ways to fail than ways to succeed. (Anything that can go wrong, probably will, right?) Yet most software project failures are attributable to a small set of common mistakes. Avoid these and your chances of success increase dramatically.

Here’s a short list of common, but often overlooked, project mistakes. Review this list and take action to mitigate your risks. Your projects will be more successful, more often — and so will you.

1. Relying on individuals rather than teams: Many companies have one or more superstars. These employees get stuff done and make things happen. While it’s natural to rely on these superstars and give them even more responsibility, it’s counter-productive.

Cross-training is essential. People should work on a variety of projects and be exposed to varied situations. By encouraging collaboration and shared responsibilities, workforce morale improves and the business benefits.

2. Setting unrealistic project timelines: Deadlines that seem a long way off will morph into tight, aggressive commitments over time. As the details unfold, what appeared to be simple may turn out to be nearly impossible. Software projects are never fully understood at the outset.

Maintain some flexibility. Identify risks and possible mitigation steps before committing to a deadline. Keep everyone informed throughout and be prepared to negotiate the feature set.

3. Living on the edge: Technology suppliers are always looking for beta testers and trying to find buyers for the latest and greatest. There are times when it makes sense to be early adopter but beware of the risks. Using a measured approach involving pilot projects usually makes more sense.

Also, watch out for the opposite extreme. Keeping legacy systems around long past their prime can be costly and disrupting. Keep track of operating costs and downtime. Know when to move on.

4. Reinventing the wheel: Too many companies develop software in house that could readily be purchased. Why build a CRM application or a content management system when so many good packages already exist?

If you can’t resist the urge to create your own, start with an open-source package and customize it to your needs. Use scarce in-house resources are for projects that deliver uniqueness and offer a competitive advantage.

5. Failing to consider scalability: Systems that pass pilot implementation testing are not necessarily ready for enterprise deployment. Even when fully deployed, adoption may start off slowly and ramp up over time. Will your systems be able to handle it?

Watch for interdependencies. As systems grow in size and complexity, they develop many more interdependencies. Any weak link could drag down the entire operation.

6. Not addressing the needs of mobile and remote users: System and network management tools are designed to take care of PCs attached to the corporate network. What about employees who spend most of their time away from the office?

Be sure to offer anti-malware tools, backup options and email support that do not require a connection to the corporate LAN. Leaving these road warriors exposed to the wild will jeopardize the entire company.

7. Relying on a single vendor: Whether it is an operating system, an application suite, a service provider, or your network infrastructure, exclusivity is not good business. Picking one vendor and dealing exclusively with them makes life simple, right?.

There’s only one organization to blame when problems occur. However, vendor exclusivity limits your options and locks you in. Select a primary vendor and have a secondary one available for special needs or odd jobs. Keep your options open.

8. Never killing failed projects: Face it, some projects will fail. Some very big projects will fail catastrophically. Learn to let go.

When a project repeatedly misses major milestones and incurs cost overruns, it’s time to cut your losses. Always have an exit strategy or a fallback plan. Don’t assume that every project will succeed.

9. Mismanaging your data center: Keep your data center neat, orderly and controlled. Spaghetti cabling, unlabeled equipment and poor ventilation will cost time and money. Every time you need to add or change anything you’ll waste hours deciding what to do and how to do it.

Avoid having production servers scattered around the office. They will gather dust, overheat and cause endless problems. If you don’t have the space for a full-blown data center, at least find an isolated, controlled area big enough to house mission-critical servers.

10. Ignoring the human side of security: Elaborate security controls and enforcement are ultimately only as good as the people that use them. Social engineering tricks have proven successful in getting innocent people to divulge passwords. User training is essential to good security controls.

Don’t get carried away with overly zealous password policies. If your users have to employ overly complex passwords and change them often, they’ll write them down in plain sight. Keep policies clear and consistent to avoid undermining your goals.

photo credit: ktpupp via photopin cc

Estimates Don’t Matter But Story Sizes Do

I’ve read quite a few blog posts lately regarding software estimates. Should we estimate epics, stories and tasks or not? Are estimates useful to software development teams or are they a waste of time? Do estimates add value to the development process or are they inaccurate and misleading?

As is often the case, the answers depend on your context. For example, an experienced team working in a familiar environment will find it easy to accurately estimate new epics, stories and tasks. A less experienced team working in an unfamiliar environment will have a difficult time estimating anything reliably.

Are estimates worth the effort?

If a development team’s estimates are unreliable, is it worth the effort? Yes and no. It may be worthwhile as a learning experience if nothing else. The team needs to have some idea of how complex new stories are. However, it’s probably not worth it from a business planning perspective. Businesses need accurate information to operate successfully.

Let’s look at this from a different perspective. I think we can agree that small activities are easier to estimate than larger ones. For example, if I ask you how long it will take to add a confirmation dialog box to a web form, your answer will likely be very precise. If I ask you how long it will take to create a complex database query and display the results, your answer will likely be less precise.

Keep user stories small and simple.

So, perhaps the real issue isn’t whether to estimate or not. Perhaps we need to think about what’s being estimated and how the estimate is being delivered. If you want your estimates to be reliable, your best bet is to derive stories that are small. In fact, if the stories are small enough, why bother to estimate them at all?

I recommend getting your sprint backlog stories down to one or two days of work. If you have 10 stories, you’re in the range of 10-20 days with 15 being the most likely. Want to be more accurate? Ten stories that are each 4-8 hours of work amount to 5-10 days in total with 7.5 being most likely. Worst case? You’re a couple of days late rather than a week or more.

By keeping user stories small and simple, estimates add little value. Some will argue that estimates are needed to derive a final delivery date for the project. Not true! The business establishes the delivery date. The software development team does the best it can to complete as many stories as possible within the time allowed. That’s how agile software development is supposed to work.

photo credit: Pranav Prakash via photopin cc

Governance Can Suck the Life Out of Software Development Teams

Large enterprises like to centralize governance across all departments. Most large IT departments follow the leader and adopt centralized control mechanisms internally. They often establish governance entities such as program management offices, whose mission is to enforce conformance. There are good reasons for it.

By approaching major projects in a uniform fashion, everything from status reporting to personnel hiring gets simpler. Getting everyone to speak the same language and dance to the same tune makes life easier for senior executives. But, we’re not here to make life better for senior executives. We’re here to help customers, clients, patients and/or end-users.

Unfortunately, these central governing boards or offices often become dead weight. They tend to overstate the benefits of the services they provide and underestimate the associated costs. They also tend to become highly political as they seek to expand their influence. In their zeal for conformity, they do some of the following dumb things:

• Issue burdensome compliance requirements
• Implement excessive monitoring and control mechanisms
• Demand redundant reports and/or studies
• Create needless initiatives
• Call endless meetings

Governing bodies have to create more value than they destroy.

Centralization has a price. It often slows responsiveness as requests migrate up the chain for approval and back down again. Centralization incurs hidden costs in the form of bureaucracy that’s not directly tied to revenues. Perhaps worst of all, it can mask accountability as it offers a convenient excuse for missed deadlines.

To get passed these obstacles, centralized authorities need to go beyond simple command-and-control. They need to ask themselves how they can help project teams and how they can add value to the organization. These latter components are often missing as the authorities focus on metrics, reports, charts and meetings in a furious effort to enforce compliance.

Centralizing does not mean creating project police. Enforcement needs to be separate and distributed among the project teams. Central authorities need to focus on value creation. In order to add value, they must do the following:

• Allocate funding to projects based on corporate strengths and priorities. This requires an intimate knowledge of the business and a highly-disciplined approach. Avoid under-funding too many projects. Spreading a little money around to every project generates waste.
• Advocate for employees by encouraging training, knowledge-sharing and movement of personnel among project teams. Without this type of intervention, groups will attempt to hoard talent and form knowledge silos.
• Govern with a hands-off approach. That is, set reasonable, high-level goals and deadlines along with simple, clear policies that guide teams toward desired results. They should also shield project teams from short-term, disruptive behaviors that often plague bureaucratic environments.
• Invest in the future. Great central authorities behave like venture capitalists. They nurture and invest in projects and people that have great potential. Not every investment will pay off, but those that do can deliver value at least ten times greater than the initial investment.

How does your project management office or other governance board stack up? Does it help you do your job or get in the way? Does it add value to your team or suck the life out of it? Let me know.

photo credit: Michigan Municipal League (MML) via photopin cc

Software Bugs Won’t Just Go Away. We Need to Fix Them!

Software bugs, all of us despise them. You might prefer to call them by their politically correct name — defects. I still despise them. Yet many companies seem to ignore them. Are they hoping no one will notice? Do they expect bugs to scamper away on their own? Maybe they believe customers will be able to squash the bugs themselves!

Here are a couple of personal anecdotes. These companies are well-known and their software systems are widely used but they are not unique.

Yahoo! Mail

I used Yahoo! Mail for a few years. I liked the user interface and I still do. I think Yahoo! Mail is better than Google’s Gmail from a strictly user experience point of view. The UI is cleaner and more intuitive in my opinion. Yet I switched to Gmail.

Why? Yahoo! Mail had bugs that never got fixed. I reported them. I explained why I felt the bugs were a major problem. I even explained what the proper behavior should be. I got nothing.

Weeks and months went by and nothing. Sure, I received acknowledgements regarding my submissions but nothing changed. And to be clear, I was a paying customer, not a freeloader. I felt neglected.

Salesforce.com

My current company pays lots of money to use the Salesforce.com software-as-a-service. I’ve reported several bugs to Salesforce. The usual response is “that’s a feature”. Thanks, but bugs are never features. Never.

On occasion, their response is “submit a request to the IdeaExchange”. For those unfamiliar with Salesforce, the IdeaExchange is a customer forum where feature requests are submitted and voted on. It’s really a terrific concept. But, it’s not where bugs belong.

On a couple of rare occasions when I’ve actually gotten Salesforce to acknowledge a defect and forward it to their developers, they immediately close my defect report and I never hear another word about the issue. I also have never witnessed one of my reported defects get fixed — never.

Defect Repairs Are Critical

The lack of response by these companies is far from unique. It’s natural for all of us to focus on new features. We always want the software to do more. We always want the software that we use to have all the features that the competition does. New features are a driving force for gaining new customers and increasing market share. I get that.

Shipping lots of new features with an ever-growing list of open defects is a disaster-in-progress. If a vendor can’t make what I have work reliably, why should I trust them to make new features work well? Past behavior is the best predictor of future behavior.

Fix the bugs in your software. There are many arguments around how to track bugs. Should you add them to the backlog and treat them like stories? Should you track them outside the backlog? Should they be prioritized like stories or treated differently?

As a customer, I don’t care. Just fix them!

photo credit: Sarabbit via photopin cc