The Agile Choice Can Be Your First Choice

Let’s say your company has a great software application. It could be a revenue-generating product or an internal workgroup solution. Either way, the business is asking for an enhancement — not just any enhancement. They want to implement a completely new feature set.

You ask lots of questions to determine basic information like:

• Target users
• Information sources
• Analysis algorithms
• Data volumes
• Reporting needs

In the end, it becomes clear that the business doesn’t have all the answers. They know they need to do something to remain competitive, keep customers, and reduce costs but the details are murky. What should you do?

1. Keep asking questions. Cast a wider net and involve more people. More business analysis should deliver a better definition. Makes sense but could eat up lots of time. Time you probably don’t have. [This is not very agile.]
2. Conduct competitive analysis coupled with focus groups. It might work as focus groups are frequently used to help determine software characteristics. Unfortunately, they won’t help if the users don’t know what they don’t know. [This is not agile either.]
3. Take your best shot. Write an elaborate requirements document; develop detailed use cases; get the business to sign-off; build it; ship it; done. While this approach is quite common, there is a high risk of delivering what the business requested but not what the business needs. [This is anti-agile.]
4. Employ a minimalist approach. Zero in on the highest-priority and best-defined needs. Deliver the essential feature set and call it “beta”. Gather test feedback and refine the solution. This will work if you can get real people to run the beta software in real situations. [This is not exactly agile, but getting closer.]
5. Go with #4 but skip the “beta” label. Get the essential feature set out fast. Listen intently to the user feedback and keep delivering refinements every few weeks. [This is the most agile approach.]

Is #5 the right choice for every situation? No, but it can be your first choice in every situation. Get the business to rationalize why the most agile approach won’t work.

Does Your Boss Have What It Takes to Be Agile?

Agile development may be a hot trend but it’s hard to get right.

• Are you afraid to take risks?
• Are you afraid of losing your job if you mess up?
• Does your boss operate on the “failure is not an option” principle?
• Do you feel the need to be right all the time?
• Is “playing it safe” the approach your boss prefers?
• Is perfection the goal your boss seeks?

If you answer “yes” to any of these questions, you’ll find it tough to follow agile principles in software development.

• Being agile means taking risks.
• Being agile means accepting small failures.
• Being agile means perfection is a journey not a goal.

If your management team catches agile fever and orders your software development team to be agile, ask them the questions above. While you’re at it, ask the the following questions too.

• Why?
• What problem needs to be solved?
• What is the goal of changing the development approach?
• Will the rest of the company also commit to being agile?
• What is the budget for training, coaching, tools, etc?

Enterprise transitions from any command-and-control development approach to any agile approach (e.g. Kanban, Lean, Scrum, XP) won’t be easy, fast, or cheap. Get everyone to accept that — up front.

Don’t Let an Emergency Throw Your Project Into Chaos

A minor disaster in my home town (water contamination) makes me think about the impact of disaster situations on software project teams. It’s frustrating to have a project derailed by events beyond your control.

Disasters happen to the best projects. It’s how the project team prepares and responds that matters. Unexpected emergencies sabotage teams and chew up precious time. Avoid them and you’ll sleep better at night.

There are several high-risk areas where a little planning can minimize the disruption caused by typical emergencies. You can’t prevent all failure scenarios but by being prepared, you can minimize the damage and speed up recovery efforts.

Hardware Failures

Even the best equipment fails from time to time. These failures often result from the two worst enemies of electronics, dirt and heat. Keep your electronic systems clean and cool.

Be ready to deal with the breakdowns by evaluating major systems and identifying those that are mission critical. Keep redundant equipment or spare parts on hand. If this isn’t practical, find a technical support service that can guarantee 2-4 hour response.

Be sure all systems are backed up regularly and test the restore process periodically.

Disgruntled or Mischievous Employees

We’d like to believe that all network intrusions and unauthorized information retrievals originate externally. Unfortunately, it’s been shown that many such activities originate on the inside. Angry or unhappy employees can cause serious problems by virtue of the inherent trust placed in them.

Reasonable precautions can stop or at least minimize errant behavior. Have clearly documented policies and procedures for using team resources and accessing information. Use security techniques such as passwords, encryption and internal firewalls to separate and protect sensitive information. Make sure doors to sensitive areas are locked at all times.

Software Vulnerabilities

Every software package is vulnerable, particularly if it accesses information over a network. While vendors may leave the door open, ultimately the burden of protecting your network lies with you.

It’s imperative to keep systems up to date with the latest vendor patches. Implement a policy for testing and deploying patches on a monthly basis. Many companies that suffer serious consequences from an attack simply failed to keep their systems updated. Don’t let this happen to you.

Natural and Artificial Disasters

If equipment is damaged by flood, fire, wind, temperature extremes, or any other cause that results in damage to the building, quickly restoring the hardware won’t be enough. In these cases, operations may have to be moved to another location. Employees may have to work from home.

This is where a business continuity plan comes in. This type of plan is essential to maintaining critical services after a catastrophic disaster. It also helps to have an IT asset database to make insurance filing and equipment replacement easier.

Be prepared

We hear about all the events discussed above on a daily basis. None can be completed avoided but the impact on your project teams can be minimized. Take some simple precautions.

No one likes to have their normal routine thrown into chaos and their project ruined.

How to Be Agile in a High-Turnover Environment

The best agile software development teams are those that have stayed together through multiple projects. Those teams have time to grow, evolve and adapt. It takes time. Greatness doesn’t just happen; it takes practice.

Unfortunately, software development teams tend to experience significant turnover among their members. There are many reasons for it, but in the end we need to face the new reality that company loyalty is in decline and there are far more career opportunities available than ever before.

It’s not uncommon for a software development team of 5-9 members to lose 2-3 of them each year. That means the team is constantly training new people while trying to meet commitments and stay on plan.

Obviously, reducing turnover should be a priority but I’ll leave that topic for another time. The point of this post is delivering within a high turnover environment.

How can your team stay agile?

There are steps you can take to make it easier for the team to operate in a high turnover environment.

1. Document your process

Yes, being agile means reducing documentation. However, when a new team member arrives, she will need to understand how things work and what policies exist. At the very least, have a quick-start guide that defines how the team operates and what the rules are (e.g. the definition of done).

It’s also a good idea to have a list of the team members and key stakeholders along with their contact information and pictures. You’ll save yourself a lot of time and repetition.

Any such documentation will need to be kept updated as the team’s process evolves. Make those updates part of the retrospective meetings.

2. Reward longevity

Identify at least one person (and preferably two) who has been with the team a comparatively long time and is likely to stay. The Scrum Master would be ideal though not required. This individual will serve as the point person when it comes to questions about how the team operates.

The point person either knows the answers or knows how and where to find them. This person needs to be a mentor for the team. Your responsibility is to keep him around.

3. Keep user stories short

Short stories are easier to understand and implement. They are particularly good for newcomers because of their narrow scope. They also help in enabling someone new to demonstrate their implementation abilities quickly.

A short story is one that can be completed (“done”) in less than 16 hours. This isn’t a hard and fast agile rule but a general guideline that you should consider. Not every story has to be short but many of them should be.

4. Use short sprint durations

Many agile teams make sprints about 4-weeks long. I don’t know why that’s the case but I suspect it feels more comfortable to those having been trained in the waterfall approach to software development. It’s too long!

Keep your sprints to 2 weeks or less. Short sprints force you to keep stories shorter. They provide frequent checkpoints and opportunities to self-correct. They also make it easier to handle the usual two-week notice when someone decides to leave.

5. Standardize the tool set

In some development shops, there is a vast array of software development tools in use. Everyone uses their favorite text editor, compiler, make utility, unit test tool, etc. In a high turnover environment, this is a key failure point.

Have a standard set of software tools. If you are comfortable with giving team members some flexibility in tool selection, that’s fine, but you still need a standard set. A new person will need to know what is expected and the tool set is a key part of it.

High turnover is a big problem but one that agile techniques can help you manage.

The Best Agile Development Teams Are Competitive

Competition — it’s what makes everything better.

The most successful athletes and sports teams are highly competitive. The most successful people are driven to compete. The most successful companies challenge themselves to be better than the competition.

Does your software development team compete with anyone?

It should. Competition will up the energy level and drive everyone on the team to do better. Improved individual performance will quickly result in better team performance. Here are some possible competitors.

• Compete with insiders. If your company is large enough to have multiple software teams, they could compete with each other. This scenario presents some difficult challenges, however. Teams working on different systems and technologies are hard to compare. If the differences are small, comparisons may be valid, but will remain somewhat subjective.

• Compete with outsiders. If you’re selling a product, you must have competitors. Buy their products and conduct comparisons. Work with your marketing department to have independent experts compare products. Set goals. Can your product cost less? Use less memory or storage? Be faster? Simpler? Challenge the team to do better than the competition.

• Compete with users. (Well, almost; user expectations.) If you’re delivering software to an internal workgroup, impress them. Deliver on time and on budget. Deliver free of defects. Deliver software that just works. Ask them to grade the software on a scale of one to ten. Next time, do better.

• Compete with itself. One of the basic tenets of any agile development approach is continuous improvement. Whatever the team does, it can do better. Higher velocity. Fewer defects. Accurate estimates. Greater capacity. Better budgeting. Track a few metrics and challenge the team to do better and be more agile.

And one more thing. Competition creates winners. Winners get rewarded. Don’t forget that.

How Accurate Are Your Project Estimates?

There is no substitute for experience.

Here are the approaches most commonly used to estimate the time and cost of software projects.

Story Points – An approach favored by agile software teams. The simplest unit of work is one point. As units of work are evaluated, they are compared to the simplest and to each other on a relative scale. While some of the estimates will be too short or too long, hopefully, they will balance out and produce a good overall duration.

Function Points – A rigorous approach based on system inputs, outputs, interfaces, tables, etc. Some teams find this metric too complex and time consuming. Significant design work is required to derive an accurate estimate. If you have the time and patience, this is a robust technique.

Lines of Code – Simple right? How many lines of software source code will it take to implement the system? Unfortunately, lines of code vary widely across systems and teams. An accurate estimate is much harder than it looks. Your team will need substantial experience to produce accurate estimates.

Use Case Points – A technique for converting use cases into a point metric. This technique has never achieved much traction in the industry. Use cases, which include multiple scenarios, can be complex making them difficult to estimate.

Hours (or Days) – This is the ultimate measure because the conversion to dollars is simple. In the end, all of the above measures will be converted to hours or days so that a cost estimate can be derived. The problem is that teams need some baseline to estimate time. How much work can be done in four hours or two days?

Wild-A$$ Guess – Someone with lots of experience decides how long the project should take. This technique is commonly used and the cause of many project time and cost overruns. If you must do this, provide a range not a single value. For example, rather than say the project will take six months, say the project will take between five and eight months.

Scientific Wild-A$$ Guess – Someone calculates how long a portion of the project will take — usually either the requirements gathering or code implementation part. They apply standard metrics to the rest of the project to calculate a total duration. Again, if you must do this, offer a range.

The bottom line is simple. Software construction estimates are notoriously unreliable. The only good estimates are produced by teams that follow a repeatable process and maintain good records. There is no substitute for experience when it comes to estimating.

8 Lessons in Being Agile from the Open-Source Community

The open-source community can teach us a few things about being agile whether you follow Scrum, Kanban or any other agile approach.

1. Open-source teams tend to be decentralized with a minimal hierarchy. This enables fast decision-making. Multiple levels of approval aren’t needed to get things done.

This level of autonomy can be difficult to accept but the productivity gains make it worthwhile. Let your teams define their own structure and reward system. Define clear guidelines and success parameters then let them go.

2. Open-source teams value intellectual contributions. The people that make the most valued contributions are the ones with the most influence and control. No one just goes along for the ride.

This approach follows the agile principle that results matter more than anything else. People who complain and criticize carry no weight with the team unless they can offer a better idea and help others implement it. Forget rank and job title. Only results matter.

3. Open-source teams collaborate. They use forums, email, instant messaging, and other tools to stay in contact and share information. They don’t write lengthy documents as a means of sharing information.

Resist the corporate call to generate extensive paperwork. Offer the minimal level of documentation that corporate watchdogs require. If they want more, offer them software artifacts instead such as source code, use cases, architecture drawings, etc. Avoid creating new documents just for outside review.

4. Transparency matters to open-source developers. Source code and documentation are readily available for anyone to review. Ideas aren’t hidden or protected. They’re shared.

Provide access to all project documents including source code to any employee that wants it. Don’t hold back. Withholding any information will only invite closer scrutiny and criticism.

5. Open-source teams actively involve end users throughout the development cycle. Early and frequent feedback provides a self-correcting mechanism for the team. Many small corrections are easier to manage and integrate than a few major ones near the end of the project.

Work directly with the user community. Don’t rely on marketing or some other group to act as a liaison. First hand feedback is always the best.

6. Peer review is one of the stalwarts of open-source development. Team members look forward to having their work reviewed by their peers. This is one of the key ways that they learn from each other and develop their skills.

Peer review must be an assessment by other developers not professional reviewers who no longer write software. The team must respect the reviewer for this to work.

7. The open-source focus is on continuous improvement by incremental, not monumental, change. Small, frequent changes allow for rapid development and feedback cycles. Both quality and productivity improve.

Keep project timelines short. If many new features are being demanded, group them into a series of short projects or iterations. Insist on user feedback after each iteration.

8. Time is not rigidly controlled on open-source projects. Quality and stability are valued more than getting the next major release done by a predefined date.

This works because there are multiple mini-releases of the software along the way. The major defects are corrected and many people install the application before the final release is delivered.

Energize your teams by challenging them to produce results not documents. Give your teams the tools they need to be successful. And most importantly, get out of their way and let them succeed.

Best Practices Are Guidelines Not Absolutes

We hear a lot about “best practices”. They apply to every endeavor from home repairs to business strategies. The phrase is also often used when examining agile software development approaches such as Kanban, Lean, Scrum and XP.

What are best practices? They’re really just methods, processes, rules or techniques that have been successful in certain situations. Once a practice delivers a successful outcome, it’s immediately a candidate for “best practice” status. Multiple successful outcomes make it appear to be a sure-fire approach.

Do best practices represent the best we can do?

Of course not. A best practice, even if it’s optimal, is merely a snapshot in time. It’s the best we can do today, given the present situation. It says nothing about tomorrow.

There is another downside to the idea of best practices. They often serve as a crutch; a kind of safe haven. Because a practice is generally accepted as a best practice, it must be the right thing to do — a no-brainer. Thusly, there is no need to analyze and assess the present situation. All you need to do is adopt best practices.

Take daily standup meetings, for example. These represent the most widely accepted element in any form of agile software development. But, are they an essential characteristic of being agile — a best practice?

Consider these two divergent situations.

Team One consists of senior developers and testers. They have been through many agile projects together and work well as a unit. Do they need to meet everyday? It won’t hurt but it’s likely to be unnecessary. The team should decide what works best for them. Perhaps meeting 2-3 times a week will suffice. Or, they might decide to meet weekly for longer than the prescribed 15 minutes.

Team Two consists of a senior-level contributor along with a staff of mostly junior members. This is the first agile project for most of them. Do they need to meet everyday? Yes! In this situation, the best practice recommendation of daily meetings should be followed. A junior team needs additional oversight and more opportunities to self-correct.

Any particular best practice may not be suitable to your situation. If you conclude that a best practice cannot work or will be too difficult to implement, ask yourself how the practice can be adjusted to make it work for your team.

Managing Expectations Leads to Successful Outcomes

I’ve written about context (Without Context, You Can’t Make an Informed Decision) and how important it is when making a point. For example, if your work involves IT consulting to the U.S. Government, your context is completely different from someone working in a software start-up targeting consumers. The ground rules are totally different.

In a similar vein, setting expectations is critically important. Few of us manage them well. Set them too high and you’ll likely disappoint your customers, even if you deliver as specified.

Software development teams, regardless of approach (Kanban, Lean, Scrum, Waterfall, etc.), spend lots of time on business requirements, stories, minimum viable products, and other ways of defining what the business needs. While these are good concepts, they often mean almost nothing to our stakeholders and end users.

Expectations mean much more.

Consider that expectations go far deeper than requirements. Expectations have an emotional component. They represent a kind of vision or mental image of a future state. When system changes are introduced, they will be mentally compared to expectations. If the changes align to expectations, you have satisfied customers. If not, you don’t (even if you delivered on the requirements as specified).

Most people don’t know what to expect from a new or revised software system. We need to educate them in terms they can relate to. For example, telling a group that the software will run inside Safari on the Apple iPad will set high expectations with some people and mean nothing to others. Keep it simple and use examples wherever possible.

Expectations are usually set by a combination of factors. The requirements, stories, etc. play a role, but often a secondary role. Why? Simply because they tend to be too long and complex for most people to grasp.

That presentation given to the business stakeholders may have had the biggest impact on expectations. The words used and the enthusiasm in the presenter’s voice may have set expectations higher than intended.

Listen and learn.

To gauge expectations, it’s important to listen carefully to what the stakeholders and customers say. Their comments help us understand the level of excitement they have. Is it too much? Their questions can help us direct their expectations appropriately by offering appropriate answers.

People are more likely to let us manage their expectations once they get to know and trust us. Would you put your faith in a complete stranger? Get to know your key stakeholders and power users. Be open and build credibility.

Remember that setting expectations is not a one time exercise. We need to monitor and redirect them during the course of every project as new information arrives. Try spending a little more time managing expectations. You might have more successful outcomes.

Adding Managers to a Late Project Only Makes It Later

I’ll bet it’s happened to you. You’re working on a software development project that runs into trouble. The project could be on a long, slow decline or some unexpected event may have blindsided the team. Either way, the project is late and your team is in trouble. Now it gets worse.

The news spreads up the management chain like an explosion at the bottom of an elevator shaft. Middle, senior and even executive managers are eager to solve the problem. Have you ever heard the phrase, “I’m from corporate and I’m here to help.”? Just what you need.

I’m not suggesting that management intervention is always bad. In fact, I’ve witnessed many good managers help teams by clearing technical roadblocks and administrative obstacles. These actions enable the team to focus on solving the problem(s) and not get slowed down by ancillary tasks.

Unfortunately, I’ve also witnessed many poor managers. They schedule weekly or daily status meetings that only take up valuable time. Or, they do nothing more than demand weekly or daily status reports. Not only does the team need to solve the problem(s), they also need to allocate time for preparing status updates. These steps simply apply pressure, create more work, and cause anxiety.

When this happens to one of your projects (and, eventually, it surely will), here are a few agile ideas to help you get through it:

1. Establish control. Your management team is not going away. If they sense that the project or the problem is out of control, they will establish a command-and-control structure along with rules and procedures you’ll have to follow. Don’t let that happen.

It’s important for you and the team to define the steps toward a solution such as:

• Understand the problem and assess the situation.
• Explore courses of action and decide on an approach.
• Implement a sequence of actions to solve the problem.

You get the idea. The details will vary with the situation but the general technique is the same.

2. Ask for help. Your management team wants to help but they may not know what to do. Be clear about what the team needs and what your management team can do to assist.

• Do you have the right tools and equipment? If not, ask for them.
• Do you have the right people? If not, clearly state what skills are needed.
• Are there normal business processes that you’d like to circumvent temporarily? If so, lay it out.

If the problem is relatively small and localized, you may not need anything and even if you do, you may not get it. If the problem is large and widespread, be assertive. Get what you need.

3. Assign a team representative. Have one person report status for the team. Make it clear that the rest of the team will be focused on solving the problem and cannot be disturbed.

• The spokesperson should be a senior member of the team or the team’s manager.
• Daily (internal) team meetings (like Scrum standups) are likely to be a good idea.
• A team status board (like a Scrum board) showing tasks, assignments and current state may also help.

Be sure that the spokesperson communicates openly and honestly. There is a tendency to sugar-coat management reports. Don’t. Tell it like it is and maintain control.

There is no better time to be agile than during a time of crisis. Do you have any ideas to add?