We need to be specific about our target audiences and promised outcomes. It comes down to setting expectations. You can deliver what you documented but the project can still fail simply because the business was expecting something else. Don’t let that happen.

Target Audience

Can you describe the target audience for your software? There are an immense number of possibilities and that’s why you need to narrow it down. Here are a few general categories:

• Business User
• Desktop
• Mobile
• Technical User
• Desktop application
• Server application
• Knowledge Level
• Novice
• Expert
• Income Level
• Poor
• Wealthy
• Physical Attributes
• Healthy, no significant medical issues
• Physically impaired (including advanced age)

There are lots of ways to slice and dice your user base. You might be inclined to say that anyone can use your software. It’s a platform open to everyone. That’s the wrong answer and here are two examples showing why.

Facebook and Twitter can claim to have universal appeal. Some people use them for business, others for pleasure. However, both services have a small percentage of hard-core users. Those are the people that spread the word, draw in others, and ultimately increase the popularity of both services. Without the hard-core users, neither service could flourish. Who are they?

Who are your hard-core users? Can you describe them in detail? If not, you’re likely trying to please everyone. You won’t.

Promised Outcomes

What promises are you making to your end users, paying customers, or corporate clients? Software offers many promises. Here are a few examples:

• Faster workflow
• Fewer mistakes
• Simpler work activities
• Automation of manual activities
• Integration with other corporate or cloud services
• Lower costs
• Improved reporting

The people using your software deserve to know precisely what to expect. Don’t simply offer them a smorgasbord of new features, enhancements and bug fixes. If you know your target audience, you know their needs. Tell them how the new software will satisfy those needs.

By doing so, you’ll get people to listen. They’ll want to know more. Excitement will build. They’ll be engaged in the effort.

What promises are you making? Can you articulate them in clear business terms?

Don’t let failure stalk your projects. In this case, the development approach doesn’t matter. Scrum, Kanban, Lean, XP and waterfall can suffer the same fate. If you can’t answer the questions above, find someone in the organization who can and enlist that person’s help today.

Some assumptions will be obvious and others will be obscure. If an assumption proves to be wrong, the team will be adversely impacted. (That would be a risk.) Here are a few examples of obscure or hidden assumptions:

• The team will remain intact for the duration of the project.
• Computer systems and data will be available to the team when needed.
• Development tools and technology infrastructure will be adequate to support the project.
• People outside the core team will be available when needed.
• Outside parties (e.g. vendors, suppliers, business partners, etc.) will deliver as promised.
• User stories have been properly scoped and estimated.
• Task lists are thorough.
• The definition-of-done covers the needs of every story.
• Any team member will be able to select any story and complete it.
• Team members have adequate knowledge and training to complete the project.

You get the idea. We all make a variety of assumptions when making plans and commitments. Usually, those assumptions prove to be correct but not always. And, the more assumptions the team makes, the greater the likelihood that something won’t go as planned. (A risk event will be realized.)

One reason why so many development projects take longer than planned is simply because one or more assumptions proves wrong and the team has to scramble to address an unplanned issue. For that reason, it’s a good idea to take a moment to think through the development team’s assumptions.

Ask yourself if the project goals and timeline seem reasonable? Is the team ready? Is the environment suitable? Are people outside the core development team engaged? What’s missing?

Projects tend to take more time than we expect simply because most of us are optimists — we want to believe. Don’t give up your optimism. Just take a little time to validate it.

You might be inclined to refer to the number of remaining known defects, the number of test cases, the improvements made in the code, the number of new features added, the feedback from the Product Owner, etc. Sadly, those are all the wrong metrics and don’t measure business outcomes.

What matters is end user perceptions and business value, not internal software metrics.

Real people, conducting real business with the software is the only true measure of outcomes. Here are a few real world examples where software teams thought they did a good job but the users disagreed. (I’ve avoided specifics to protect the guilty parties.)

• The software application functioned perfectly but was too slow to be useful by the large, target group. (Performance testing might have caught this.)
• The software worked properly but required too much manual data entry. (Useability testing might have caught this.)
• The software ran into a conflict with another desktop application meaning some people could not use it. (Additional analysis and testing of the target environments might have caught this.)
• The software worked fine but the new workflow actually took longer to get things done than did the old workflow. (Again, useability testing might have caught this.)

I’ve used the phrase “might have caught this” above because there is no guarantee that any laboratory testing will catch any particular complex failure scenario. Testing will catch the major problems and the expected ones. The subtle environmental issues are another matter.

This leads me to a more central question. If the ultimate measure of successful outcomes is the users’ perception, why aren’t teams doing more user testing? It’s not a simple thing to do. I get that. But, clearly we have to try harder. Here are a few suggestions.

• If you’re doing straight beginning to end waterfall, stop! You need to introduce interim deliverables. Break up the waterfall flow into a series of mini-waterfalls that each deliver useful functionality. Or, even better, dump waterfall entirely and switch to Scrum, Kanban, Lean or XP.
• If you’re already doing waterfall iterations, get the software into the hands of the end users sooner and more often. Draw them into the process. Engage them. Setup a small number of systems where users can stop by anytime and try out the latest build. Have lunch and learn sessions. Get creative. You need real feedback from real people.
• If you’re already using an agile development approach, focus more effort on the needs and concerns of the end users. It’s not about technology. It’s about them. Empathize more and they will respond in kind.

Recognize that software is a tool not an end game. Real people use software to accomplish something that adds value to their job functions or enhances their personal lives. Laboratory test environments can’t replicate every real work condition. There are too many variables.

The simplest way to do this is via an example.

Let’s say a Scrum team has an average velocity of 20 story points per sprint. Everyone considers that to be a pretty good number. But what does it really mean?

I’d start by asking how many sprints were completed to arrive at that number. In other words, how many sprints are we using to calculate the average? I’d also want to know the smallest velocity and the largest one to get a sense of how widely distributed the velocities are. (Excluding the first 2-3 sprints might be wise as Scrum teams often need a few sprints to sync and stabilize as a functional unit.)

These additional parameters are important. If a small number of sprints were used to calculate the average, the team may not have established a repeatable cadence as yet. If the range of velocities per sprint is very wide, I’d have to wonder if the team is operating well as a whole or simply consists of several developers working near each other.

Now it gets more complicated.

I’d also ask about story points being created during sprints. These new points could be defects or they might represent functionality that no one thought about in advance but is required before the final release. Either way, if the team completes 20 story points and creates 5, their effective velocity is somewhere between 15 and 20.

If the 5 new story points are bugs, should those points be subtracted from the sprint velocity so 20 points of calculated velocity becomes 15 points of effective velocity?

If some of the newly created points represent new functionality, it gets tricky. New functionality gets added to the product or release backlog depending on when the new functions are needed.

If a new function is critically required before the release is complete, the new points need to be added to the release backlog, thus delaying the final release date. If the new function is optional, the new points can be added to the product backlog and ignored for now. (BTW, a release consists of several sprints.)

Inevitable arguments will ensue over whether an issue is a defect or a new function. Let’s not go there.

There is also a more general argument to be made that knowingly adding to technical debt also reduces velocity. So if a developer takes a short cut in the code, he should estimate the story points needed to pay off the debt and that value should be subtracted from the team’s velocity for that sprint.

This involves a bit of a judgement call in that the team might decide not to pay off the debt anytime soon. Regardless, the technical debt exists and won’t simply go away.

Velocity is intended to be a simple metric and in principle it is. Unfortunately, nothing about software engineering for enterprise business users is truly simple. Should you track velocity? Yes. Should you reduce it as I’ve described above? Not for a new Scrum team but be aware of the issues and factor them into your retrospectives.

Oh, and please don’t try to simply compare velocities across multiple Scrum teams. That gets even more complicated!

I’ve seen it all and it can get ugly. As a general rule, planning and analysis should take no more than 20% of the time for the entire project. I’ve see that number go over 50% in some cases. For example, 6 weeks of planning and analysis for a 12-week project. That extra planning time delays the solution implementation and may prove to be very expensive.

I’ve even seen teams put together lengthy and detailed plans simply because they were required to do so. Once the projects got rolling, the plans were ignored and the teams operated day to day. (I don’t recommend that approach.)

The Law of Diminishing Returns

If something truly new and innovative is being done, additional planning time makes sense. Even if it’s not innovative but complex, more planning might help. But if the project is a variation of something that’s been done before, 20% is more than enough time to plan. So, why does all this extra planning occur?

Planning, like any other business effort, succumbs to the law of diminishing returns. All it means is that it’s relatively easy to throw together a high-level plan. Many of us have done it during a one-hour planning meeting. You may have 60-80% of the plan in place in a few hours or a few days at most. Now comes the hard part. The details of the plan. Ironing out the remaining 20-40% of the plan could take weeks. Is it worth it?

Plan less. Deliver more. Gather feedback and repeat. That’s how to be agile. Here are a few guidelines:

• Prioritize. What are the most important goals for the project? What are the high-risk areas? Those items may need more planning.
• Resist the urge to pile items onto the planning list. A long list of planning items doesn’t make a good plan.
• Remember that a complex plan will require more effort to track, maintain and adjust, increasing the project’s administrative overhead.
• Don’t get lost in the planning jungle. The goal is to deliver a business solution not to create a beautiful plan with lots of checkboxes, charts and graphs.
• Fewer people will likely deliver a better plan. Involve people who have unique knowledge or skills.
• If you’re unsure of something and cannot adequately plan ahead, allocate time during the project to adjust the plan.
• Add new requirements, stories, etc, to the backlog as you go. You don’t have to define everything up front.

Planning is a good thing. Just don’t get carried away. You’ll end up changing it anyway.

Communication

Communication is the most important aspect in any business. One can improve communication or be in touch with business clients, customers, employees by making use of the technology. Today, every person owns a Smartphone or mobile phone with camera facility. One can see and communicate face to face using video conferencing. You can view the other person, listen to and put your point forward to the target person, irrespective of their geographic location in the globe. Chatting via video conferencing gives more impact than a traditional phone call. One can explain about one’s new product and show its working and benefits to others. One can have business meetings via phone, instead of meeting in a particular place, thereby removing the barriers of boundary.

Accessibility

Many employees need to travel frequently as a part of their job. They need updated information to perform their job. Mobile phones and wireless technology have paved ways for this. One can access any information one needs and contribute to the productivity of the organization. Also, technology has developed so well that employees can be allotted seats only when they need to be physically present. Many employees can use the same seat on a gyratory basis. This greatly reduces the cost as the organization need not expand the workspace physically to accommodate the growing number of employees. Since the employees are in constant touch with their superiors, they can work effectively without any delay in acquiring official information.

Employee Monitoring

Many organizations provide mobile phones to their employees. The employers can install mobile spy on the mobile phones before giving it to their employees. This helps them to trace the activities of the employees. The organization can get access to the phone calls made and received, messages sent and received, websites visited, chat history, browsing history etc. It also helps to find the employees location at a specific time. Monitoring the activities drives the employees to consciously contribute to the productivity of the organization, also to know if any of the employees are involved in leaking company’s confidential data.

Customers

Technology has advanced so well that it helps to satisfy the customer needs. It helps to understand clearly what customers’ needs are and how they want them. For instance, when a customer calls the organization for any queries, technology can be used to set up a system which would give solutions to the queries of the customer by tracing the customer details that were previously recorded. The employee in turn can communicate to the customer appropriately and satisfy their queries and improve the relationship with the customer. This helps to boost sales and improve the business profit.

Apart from boosting sales, technology has gone a step ahead in building good customer relationship. The job of an organization never ends with making a sale to the customer, the business can benefit only if they have repeated sales. If a customer is satisfied with the product or service, they would keep coming again and again. This is possible only by maintaining a constant touch with the customers. Applications are available which help to monitor the sales, discover the customers’ tastes and practices and the reason why they like to come back. Thus, technology helps to take business to the next level.

Lucille J Cronk is a blogger who loves to blog on technology and mobile spy tool. You will get all the information related to mobile spy tools and its relevant benefits at her blog.

For this post, I’d like to focus on legacy software. Every established company has software systems that are used everyday and may have been in use for years. Regardless of how those systems were developed, any company that decides to take the plunge into agile software development hits an immediate impediment — all that legacy source code.

I’ve witnessed many situations where the business stakeholders get excited about doing something new and different yet they want all the old features, functions and data carried forward. What appeared to be a simple and fun software project turns into a tangled web.

What is legacy code?

There is no standard definition of legacy software because code bases vary widely in structure and quality. Here are a few situations where the phrase legacy code applies.

• Any code base that was not written by the current software team is legacy code.
• A code base that has been around for years and serviced by many engineers.
• Code that lacks documentation, test cases, or is otherwise difficult to decipher.

When trying to enhance legacy software, immediate questions surface. Where should software changes be applied? How do we know the changes will work as intended? How do we know there will not be unintended consequences?

Some teams try to avoid making software changes unless absolutely necessary. While wanting to avoid breaking anything is admirable, avoiding change is not how businesses prosper.

How do agile teams deal with legacy code? There are two high-level approaches to the problem and a seemingly infinite number of variations.

1) Start over. Forget the legacy code.

This approach won’t sit well with many organizations, but think about it. How has Apple been so successful with the iPhone and iPad? Because they started over. Compatibility with legacy software was not the goal. Look at the result!

Now consider Microsoft. What has held them back and prevented them from achieving their full potential in the mobile space? Backward compatibility. Microsoft has gone to great lengths to preserve their legacy. The approach has helped them in many ways but it has also hindered their ability to respond to leaner and more agile competitors.

The only way starting over can work is by setting priorities and maintaining a sharp focus on what really matters. Most companies don’t have the fortitude to pull this off so let’s look at the alternative.

2) Refactor the legacy code before making changes.

Adding features to fragile software will likely make matters worse. You have to understand and stabilize the legacy code base first. One of the best ways to do that is to start by writing tests. You know what the software does. Write automated tests to dive deep and find out how the software behaves. (Sounds like TDD because it is.)

Consider a complete re-write of all or portions of the system that prove to be incredibly fragile. Focus on interfaces. Write wrapper classes to encapsulate legacy components. Eliminate unused and rarely used features.

None of this will be easy or quick and the pressure to deliver new features will be intense. Find an executive-level sponsor and get adequate levels of funding and staffing.

Legacy code is not going away. Replace it or refactor it. The longer you wait, the more difficult it will be.

1) You’re working in a software-as-a-service environment like Salesforce.com or Microsoft Dynamics. The stakeholders want to know how long it will take to add a simple feature. You ask a few questions, indicate where the risks lie (if any), then offer an estimate (probably not more than a week or two).

Barring interruptions, the chances of delivering on time are high. Even if you don’t deliver exactly what the stakeholders envision, it will likely take only a day or two to fine tune the solution.

2) Now imagine your team needs to build a custom software application. You might use Java, C#, C++, Ruby, PHP, or Perl. There might be software components from prior projects that you can leverage but they’ll likely need some rework. You’re asked to estimate a delivery date.

You ask questions and identify risks but the real issue is the lack of business requirements, use cases, or epics. All you have is a description. You might even have a product vision statement, but that’s unlikely.

Now what?

The team will have to rely upon its experience. Familiarity with the software tool set and the type of application being requested will help in scoping the solution. Of course, the stakeholders need an immediate answer so they can establish a budget for the project. No time for detailed analysis. Now the fun begins.

Assume the team brainstorms for a day or two and estimates that 5 people can deliver the software in 6 months. Six months is about 130 business days. Multiply by 5 people to get 650 person-days or 5,200 person-hours.

Ideally, the team should offer an estimate range rather than a single number. 5,200 hours becomes an official estimate range of between 4,000 (80% of 5,200) and 6,500 (125% of 5,200) hours. (The 80% and 125% numbers are only examples. Smaller or larger values will apply in different situations.) The team also offers lists of assumptions and risks.

Do you see the problems here?

Scenarios like the above play out every day in companies around the world. The stakeholders offer an over-simplified description of what they want. Then they ask, “How soon can we have it?”

High-level, broad-based software estimates are almost worthless. For a large, complex system, an estimate of X hours may translate to a range of X/2 (50%) to 4X (300%). You read that correctly — from one half to four times the estimated effort. Where’s the value in such a wide ranging estimate?

Of course, there’s rarely sufficient time to produce an accurate estimate — a narrow range. Such an estimate may take anywhere from a couple of weeks to a few months depending upon the situation complexity. Everyone wants instant answers and rapid delivery. There’s no time to do it right.

What should you do? Go agile!

Tell the business stakeholders what they want to hear. You can deliver the software anytime they want — as long as they are willing to scale the feature set to align with the timeframe. Once the initial feature set is delivered (on time, by definition), features will continue to be added through a series of incremental releases. When money runs out, the project is over and there’s little or no waste.

Everybody wins. And luck isn’t a critical success factor.

Okay, okay. I know. Some additional communication overhead will be introduced by adding people to the team. Fine. I’m in a generous mood. I’ll give you 4 months. Now get to work.

Not so fast.

Simple math doesn’t always work, particularly when you apply it to complex situations. Also, keep in mind that project estimates are prone to variability and change. A 6-month estimate could represent from 3 to 12 months of work.

Let’s examine some of the factors that affect the productivity of a group of software engineers.

• Communication skills
• Software engineering experience level
• Experience with the toolset
• Work environment
• Ability to learn
• Structure of the system
• Availability of business stakeholders and end users
• Availability of support personnel to document, deploy, etc.
• Availability of target systems to develop, test, etc.

You get the idea. Adding software developers is just the tip of the iceberg. Are all the other pieces in place to make adding developers worthwhile? If so, what’s being done to help this larger team form, storm, norm and perform?

The bigger they are, the harder they fail.

Adding people to an established team at the outset of a project is a questionable idea. As time goes on, the issues listed above only loom larger making adding people well into the project a bad idea. Adding them nearer the end of the project in a mad rush to make up lost time is foolish.

I won’t say that you should never add people to a software development project but if you do, review the list above and take appropriate actions to support the team. Finally, be realistic. Adding a person may only provide half the benefit that the simple math suggests. Adding more than one could even have a negative impact.

That’s a scathing comment. It is often repeated and there are many examples of people who get promoted only to fail in their new jobs. How is it possible that someone who earned a promotion by doing a good job, turns out to be ineffective or incompetent in his new job? Here are a few possibilities.

1. An individual contributor is promoted to manager. It happens all the time. Many workers aspire to be managers. With proper training and coaching along with good people skills, anyone can be a manager. Unfortunately, the training and coaching part is often missing. Another critical success factor (CSF) for managers is the ability to multitask. Without it, the Peter Principle rules.
2. A subject matter expert (SME) is promoted and assumes responsibilities beyond her core area of expertise. Assuming the new area of responsibility is related to the SME’s existing knowledge base, taking on a bigger role can work. Of course, the SME will need help and guidance. A good mentor can be invaluable in making the transition. And she will need to master that multitasking CSF.
3. A great implementer is promoted into the role of designer. Design work is different from implementation work. The skills, tools and approaches are related but not identical. Training and mentoring are key ingredients. Oh, and designers tend to do much more multitasking (CSF).
4. A technical genius is promoted into a role that requires people skills (e.g. negotiation). Once someone masters the objective part of their job (technical details), that person often wants to try out the subjective (human interaction) part of the job. Fair enough, though the skill sets are usually vastly different. And, anything involving people will invariably require that CSF – multitasking.
5. Someone who is accustomed to focusing on a small number of tasks is promoted into job that demands multitasking across a broader array of work. There it is again.

Do you see a pattern here?

The lack of training, coaching and/or mentoring is a solvable problem. Why would any company invest time and money in an employee, promote the person, assign her new and more strategic responsibilities, and then drop the ball? It’s insane! Greatness doesn’t just happen. It requires constant vigilance.

As for the problem of multitasking, it’s not going away. When we multitask, we are less efficient. We make more mistakes, miss important details, and forget critical facts.

There’s a simple solution. It’s based on the fourth principle of the Agile Manifesto – “Business people and developers must work together daily throughout the project.” It’s called teamwork. The solution to the multitasking problem is teamwork. Share the workload. Divide and conquer. Many hands make light work. Many minds do great work.

The next time you get promoted do two things. 1) Get help. Insist on training and mentoring. 2) Don’t go it alone. Collaborate with your coworkers and team members.