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

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

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

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

Great Technology Isn’t Enough For Being Agile

We have a disconnect in the agile community. Agile approaches to software development are not about technology departments like Information Technology, Engineering or Research and Development. Agile development approaches are about customers, knowledge workers, and successful outcomes.

This fundamental concept seems to be difficult for many companies to grasp. Or, maybe many managers and developers prefer to ignore the broad-based, core aspects of being agile and prefer to focus on the easy stuff. It’s much easier to focus on your job and your team’s activities rather than the broader corporate goals.

Whether your team applies the principles of Scrum, Kanban, Lean, XP or some combination of all of them, you’ll need many skills to be successful. In addition to the obvious technical skills, successful teams need active participation from marketing, product management, finance, customer support and security administration teams — at least.

The major concepts behind agile software development aren’t technically oriented. They are people and process oriented. Consider this list of agile principles:

• Value creation
• Shared knowledge and pairing
• Multidisciplinary teams
• Continuous improvement
• Quality results
• Collaboration
• Customer satisfaction
• Change acceptance
• Simple techniques
• Trust and respect
• Self-organizing teams
• Short cycles
• Backlog management
• Daily 15-minute standups
• Minimal work-in-progress
• Definition of done
• …I’m sure you can add others.

The point is that by focusing exclusively on the technical contributors and their skills we also focus on the technical aspects of the solution. Yet customers don’t care how the software was built or what tools and technologies were used. They care about quality results delivered in a timely manner.

Great software delivered late is a poor outcome. Great software delivered far above the expected cost is a poor outcome. Crapware delivered on time and on budget is a poor outcome. Software that meets all the technical and internal goals but doesn’t satisfy customers’ needs is a poor outcome.

Are you following this? Delivering software that everyone (software developers, business community, and customers) believes is great is hard to do. Agile techniques are no guarantee but they’ll improve your odds — if you adopt a comprehensive view of your approach.

photo credit: lumaxart via photopin cc

The Simplest Way To Get More Done Is To Do Less

Software developers, testers, analysts and managers are known to be detail oriented. We need to know exactly what needs to be done so we can devise and implement software algorithms. We need answers to detailed questions so we can make the right implementation decisions.

Meanwhile, business people don’t always have all the answers. This is particularly true for new business initiatives. These are often experimental. They represent learning opportunities. If the business teams had all the answers, would they need high-caliber (that is, expensive) software people?

Business Really Matters

I work with multiple business groups. They often ask for new data elements or new software algorithms. Sometimes they know exactly what they want and what they’ll do with the information. Other times, they only have a rough idea. The actions they’ll take after seeing the results depend on the results they see. The analysis will, in turn, generate new requests for the software team.

These situations are more common than not. Running a business is not an exact science. It demands flexibility and rapid responsiveness. Whenever I direct questions to the business stakeholders and receive answers that are vague or general, I work with the development team to assure that the software can flex with the business.

For example, if someone tells me that are interested in data elements within a broad range of values, I’ll make sure the range can be changed by simply editing configuration parameters. If someone gives me a list of data elements, I’ll make sure the list can be changed by updating a configuration table.

Does your team seek out ways to do less?

Part of being agile is designing software for change. These types of configuration changes should be normal operating procedure. They aren’t technical changes and don’t require change management or backlog grooming.

Take a look at your backlog. Look for ways to combine stories or eliminate the need for some of them entirely. Doing less is a perfectly valid way to deliver more. The alternative is to slow down the business and that’s a dreadful outcome.

photo credit: Brett Jordan via photopin cc

At Yahoo!, Working From Home Is Not The Real Issue

I feel compelled to weigh in regarding the recent decision by Marissa Mayer, CEO of Yahoo!, dropping the company’s work-from-home option beginning in June. Yahoo will require that employees work in an office location (unless they have a need to work from home such as a visit by the “cable guy”).

Firstly, I have to say that I’ve never worked at Yahoo nor do I know anyone who does. Also, I’m sure that most Yahoo employees work hard and earn their pay. That said, Yahoo has problems — lots of them. The company is in serious trouble. It’s relationship with Microsoft has not gone as well as hoped. The company lacks a clear identity. What is Yahoo’s strength? What is it good at? Why would you use Yahoo rather than another website? I don’t know the answers to those questions and that’s a problem.

According to Business Insider, Mayer made the decision after reviewing VPN (Virtual Private Network) logs. Simply put, many more people claimed to be working from home than were logging into the corporate network via VPN. I have to agree that if you’re working from home, you should be signed into Yahoo servers and collaborating with colleagues. If management oversight was lax, abuses were likely and something needed to be done.

The core issue is poor management.

This is clearly a management problem. Think about it. Employees are “working from home“. Some are not logging in. Work is not getting done. How would you fix that?

I’d hold people accountable. Managers should assign specific tasks or employees might grab them from a task board or a list. Either way, tasks should have due dates and the person working on a task must be held accountable. If impediments arise — and they often do — the employee is responsible for raising awareness of the impediment and seeking assistance. In other words, impediments are not an excuse for failing to deliver by the due date.

Management 101

If this sounds like “management 101“, it is. Will dragging everyone into the office help? Not likely. Poor management will still be the root problem. It will be exacerbated by having disgruntled employees. Things are going to get much worse at Yahoo before they get better.

It’s sad. Yahoo is one of the original and premier Internet companies. I’m sure Mayer is frustrated and stymied. She had to do something significant to get everyone’s attention and force the organization to change. This is a quick and dirty approach — clear and simple.

I wish she had opted for a more complex change such as laying out a company-wide product roadmap and holding everyone accountable for achieving it. It’s not too late. Hopefully this new work-at-the-office policy is merely a stopgap measure.

(BTW: This issue goes far beyond agile software development and collocated teams. Yahoo’s problems run much deeper. This is an attempt to change a stagnant and dying corporate culture.)

photo credit: Britt Selvitelle via photopin cc

Change Is Good, Upheaval Is Not

You want your software development team to switch from using a waterfall approach to using an agile approach like Scrum, Kanban, Lean or XP. Should you do it gradually or go cold turkey (all at once)?

Before you answer that question there are a few things to consider. Let’s walk through an example. This will be a rather extreme case to get you to think about how complex this transition can be.

For this example, we have a strong software development team. They have a good track record. There are no pressing problems to solve. The motivation for changing the development approach is to try something new and see what effect it has.

Management identifies a new product. It’s not a desktop application that has been the company’s strength. It’s a web-based application taking the company in a new direction. This is a great time to try a new development approach, right?

Here is a list of the major things that will need to change in adopting the new approach and building the new application. Let’s assume they’ve decided to adopt Scrum.

• Approach – From Waterfall to Scrum
• Language – From C to PHP and Javascript
• Tools – From desktop software build tools to browser- and server-based tools
• Office Layout – From distributed cubes to cohabited open space
• Work Style – From individual efforts to team efforts
• Control Style – From tasks assigned by a manager to self-organizing workflow
• Alignment – From isolated work efforts to collaboration with business people
• Documentation – From formal, lengthy specifications to informal, brief stories
• Meetings – From formal status and review meetings to informal daily standups
• Deployments – From two (QA and production) to many (after each sprint)

I could go on but you get the idea. A lot is changing — in fact, everything is changing. Will this team be successful?

Maybe but not likely — too much is changing too fast. For this team to succeed, here’s what needs to happen.

1. Training – The team won’t know where to begin. Scrum training and web-based application development training are essential.
2. Coaching – Even with training, they will make rookie mistakes. Direct assistance from someone who has experience with Scrum and web-based software development is needed (not necessarily one person).
3. Time to fail – The team cannot estimate tasks with any precision. There are too many unknowns. They need time to experiment and mature.

If the management team is willing to put money and time into this effort, the team will succeed. Unfortunately, senior managers tend to be impatient and cheap. They want instant results. Problems can always be fixed later — if there is a “later“.

If you decide to make such drastic changes, tread carefully. If money and time are not on your side, consider changing one or two things such as the language and the tools. Once the team is comfortable, change one or two more and keep at it.

Lastly, have good reasons for changing. Simply wanting to “try something new” is not a good reason.

photo credit: HikingArtist.com via photopin cc