Sprint Results Are Not Releases

In agile software development, it’s widely believed that every Scrum sprint should result in software that is ready to ship. The theory is that the team will be able to stop or suspend development at the end of any sprint and ship the software to the end users. This means that the team is always delivering increasing value to the business.

Sounds good. Difficult to achieve.

Calling a set of stories “done” and ready to ship doesn’t always mean the business community can use the software effectively. Let’s take a simple example.

You’re building a financial application to manage customers that are late with their payments. You’ve completed a set of stories that provide the following functionality for customer agents:

• Search for a customer who is late.
• Display basic information about the customer.
• Review the customer’s payment history.

Obviously, those are essential features. However, before the user community can integrate the software into their business process, they will minimally need a few more features such as:

• Ability for a customer agent to log a contact attempt against the customer’s account.
• Ability to view recent history of contact attempts to avoid duplication of effort.
• Ability to mark a customer’s account as paid in full.
• Ability to block a customer from making any future purchases.

The absence of these features is fine during alpha and beta testing, even during initial pilot runs. But calling the software ready to ship is a stretch.

You could argue that the existing business process and the new software could co-exist for a period of time. While that may be true in principle, in practice, it places an added burden on the agents and added costs on the organization.

Sprints improve software. Releases deliver it.

Rather than think of each sprint as delivering software that is ready to ship, think in terms of a set of sprints comprising a release. Strive to make releases ready to ship.

In addition to easing the pressure of having to be ready to ship at the end of every sprint, the team has the added advantage of doing some additional release planning periodically — not just sprint planning. They can schedule an architecture and design sprint at the beginning of a release. Similarly, they can schedule an integration test sprint at the end of the release cycle.

Clearly, I don’t agree with the premise that each sprint results in a shippable product. But I do agree that the stories within a sprint should be fully baked and ready to be delivered. This is a subtle but significant distinction.

The needs of the technology team don’t always align with the needs of the business team. Find ways to make them align and everyone will be happier and less stressed — you’ll also be more agile.

Success or Failure – It’s About Expectations

How do you know if your project succeeds or fails? If you assembled your management team in a room and gave them some project statistics, would they rate the project a success or a failure?

Consider this. You’ve just completed a project that was planned for six months of work by a team of five. The budget was $400K including deployment hardware and software.

• The project finished in seven months, not six. All else being equal, was the project successful?
• The project finished in six months but required 6 people and thus ran over budget. Success or failure?
• The project finished on time with five people but the software ran much slower than expected so the deployment hardware had to be upgraded at an additional cost of $75K. Success or failure?
• The project finished on time and on budget but contained more significant defects than the business community expected resulting in added support costs. Success or failure?
• The project finished on time and on budget but several significant features were omitted resulting in lost end user productivity. Success or failure?

These are not simple questions and there are no easy answers. Yet, the questions need to be asked and answers must be offered so that the organization can learn and improve. Furthermore, if word spreads that finishing 15-20% over estimates is okay, teams will naturally gravitate toward that goal.

Always define success criteria.

Success criteria are easier to manage if you estimate in ranges. How broad the range should be depends on your organization’s risk tolerance.

Think about the minimum, realistically achievable goals for the project. Then consider the most likely, worst case outcomes. (Ignore outcomes like the project never finishes or is over budget by a factor of ten. Let’s assume you are better than that!)

Somewhere within those extremes are success criteria you can use to set expectations with the stakeholders. Don’t offer a six months estimate; offer 5.5 to 7 months. Don’t offer $400K; offer $360K to $475K.

Manage expectations better at the outset and you’ll be more successful at the end.

Don’t Skimp on Software QA; It’s Not Agile

There are two major schools of thought around quality assurance (QA) testing. The waterfall crowd appends QA to the development process while the agile crowd integrates QA into the process, sort of.

The waterfall approach has an obvious problem. If defining and writing the code takes longer than planned (very likely) and the schedule is inflexible (also likely), QA will have precious little time to test.

I’ve seen this play out time and time again. Some QA managers fight for the time allocated in the schedule even if it means late delivery. They often lose that battle. Most QA managers have learned that resistance is futile and they do the best they can in the limited time they are given. Poor quality software is the result.

The agile approach is better in that QA takes place during every sprint or iteration. Thus testing takes place throughout the development process not just at the end.

A similar problem manifests itself, however, in that testing is often done at the end of the sprint. Again, if the stories take longer to implement than planned, QA is left with little time to test. At least there is an opportunity to do more testing in the next sprint but that is not the best way to run agile projects.

Why Not Eliminate QA?

What if we eliminated QA as a separate effort? Toss it. What would happen?

The developers would no longer have QA to back them up. They wouldn’t be able to blame QA for missing a bug. They’d have to think more about testing and take more responsibility.

Problem solved? Not really. You see, it is difficult to test the code you designed and wrote. You are too invested in the solution, too familiar with the algorithms. This causes developers to miss defects simply because they ‘never thought of that’.

An independent viewpoint is needed

So what should you do? The answer is partially cultural. Does your company strive for high quality or is good enough sufficient? Does it focus on user needs or is it assumed that managers know best?

If you really care about quality and user needs, here are a few guidelines:

1. Agile QA must be as tightly integrated into the development process as possible.
2. Agile code creation and testing must be concurrent.
3. The smaller the code, the simpler and faster it is to test. Keep stories very small so that they can completed in one day or less. (There will be exceptions but keep them to a minimum.)
4. Build in time for regression testing and automate it (if you don’t, you’ll never keep up with the testing load on a large project).
5. As the software gets bigger, regression and integration testing may become huge efforts especially if there are multiple development teams. You may need to establish a parallel testing team to keep up. (They keyword is ‘parallel’ and they must be synchronized with the development team(s).)

Agile software development isn’t a shrink-wrapped process. You need to adapt it to your situation so that the rest of the company will adopt it.

Are you on a Team or in a Workgroup?

If you have four software developers, a Scrummaster and a product owner, do you have a team? Is that all it takes to assemble an agile team?

Forming an agile team is not easy. Most often, a group of people are assembled and given a common corporate goal. They create a plan and start working on it. They are a team, right?

It usually plays out such that each member of the ‘team’ is a silo. They each have knowledge in their area of expertise. This approach is efficient giving everyone the opportunity to develop expert skills in their chosen areas. Communication is minimal because everyone knows what they need to do.

For example, the four developers may breakdown into a database engineer, a web services expert, a JavaScript developer, and a user interface designer. While there is overlap in these areas, they are sufficiently different that it is difficult for anyone to pick up the slack for another.

The better each gets at what they do the more entrenched they become. Each member also gets faster and more productive making the ‘team’ more dependent on their skills. It all works great until something happens to disrupt the ‘team’.

Someone quits, transfers, gets sick, has an accident, etc. Suddenly the ‘team’ is stuck. No one can readily fill in for the missing member. They are operating more like a workgroup than a team.

In a workgroup, everyone has specialized skills. Each member of the workgroup does his or her part and collectively they accomplish something larger.

On an agile team, members also have specialized skills but the key differences are communication and collaboration. On a highly-skilled, agile team, the members know what other members are working on each day.

This doesn’t mean that every member can do every task assigned to the team. It means that team members can assist each other. In the event that a someone is unavailable for a period of time, a replacement can be brought in and gotten up to speed quickly.

If you want to extract maximum value from your teams, strive for open communications (mostly verbal) and plenty of collaboration. The team will be happier and more productive. The business will be stronger and more profitable.

LibreOffice Is an Important Open-Source Project

When Oracle bought Sun Microsystems they acquired the rights to OpenOffice, an open source equivalent to Microsoft Office. Sadly, Oracle is not known for its openness or contributions to open source projects. It began to look like OpenOffice would become OracleOffice.

Thankfully, some of the OpenOffice contributors decided to fork the code and create LibreOffice. The first stable version of LibreOffice is now available.

I’m sure there are many folks wondering why they should care. Sure, Microsoft Office is big and bulky but alternatives like Google Docs, ThinkFree and Zoho are readily available and quite good.

Open source lets people innovate

Open source projects create a breeding ground for new ideas and innovation. Just take a look at browsers. Where would browsers be today if the Mozilla Foundation hadn’t offered an alternative to Internet Explorer? I’d bet that most of the world would be running IE4!

Companies only innovate and advance when they face competition. One of the reasons Apple innovates so much is self-preservation. Until the iPhone appeared, Apple was always the ‘other company making personal computers’. Let’s hope they never lose that instinct.

Clearly office suites need a re-birth. Microsoft Office has been around for over 20 years. It is big, bulky and desktop centric. Copying that model and going head-to-head with a tough competitor like Microsoft makes little sense.

We need new ideas for what an office suite is and what it does. Companies like Google can help but they will only do things that serve their own interests. Open source projects like LibreOffice operate in the best interests of their communities. They innovate because they want to, because it’s fun, not because they have to.

LibreOffice can set a new direction

Office suites have been and will remain a very important software segment. They will morph into smartphone and tablet suites as we become a more mobile workplace. Having a strong and vibrant open source project in the segment is needed.

You may not want or need to install LibreOffice but keep it in mind. If is freely available for Windows, Mac and Linux systems.

No, it isn’t 100% compatible with Microsoft Office 2010 but nothing else is either. Does compatibility really matter? All the major office suites contain far more functionality than any person or workgroup will ever use. Focus on what you need to do. Chances are LibreOffice can do it.

Enthusiasm Delivers Results (if you’re agile)

One of the big challenges on any major software project is maintaining a high level of enthusiasm. When the team and the stakeholders are enthusiastic, ideas flow and things happen. Enthusiasm creates energy.

One of the reasons agile software development is successful is its ability to maintain a high level of enthusiasm within the team. How? By delivering incremental results early and often.

Let’s consider an example of developing an enterprise software application to assist customers having credit problems. Early intervention with these customers by staffers can reduce credit losses and improve profits.

First, consider the waterfall approach

1. Conduct business analysis and requirements gathering.
2. Get the business users excited about the project and the potential profit increase.
3. Engage the services of a project manager and a development team to write specs, review them, re-write them, write more, review more, etc.
4. The specs are finally done and the business users ask, “Great, how soon can we have the software?”.
5. 4 months later, the software is ready for QA.
6. Meanwhile, the business users have implemented a manual approach and they now realize that the software will need more features than they originally thought.
7. The development team needs to re-group.
8. The business users become exasperated. They lose interest and enthusiasm.

Now, consider an agile development approach

1. Assemble the complete team immediately including the business sponsor and product owner.
2. Create stories to describe what the business users do.
3. Select high-value stories and begin to build out the software using agile techniques.
4. Engage the business users early and often to try the software and offer feedback.
5. Incorporate new ideas into the agile development plan and keep delivering value.
6. Keep building on the excitement and keep everyone focused on the solution.
7. As soon as a core feature set is ready, have at least some members of the business community begin using the software to perform real work.
8. Keep improving and delivering updates until the team delivers the value that the business needs.

Enthusiasm. If your team has it, they will respond with impressive results. If they don’t have it, no process or methodology is going to help.

Want your team to be more enthusiastic? Be more agile.

Super Agile Teams Need Superstars

Every team needs good people. Great teams need superstars, that is, one or more top-notch contributors. Agile teams are no different.

A team composed of average contributors will produce average work. If you’re lucky and the team collaborates really well, you may get above average results — unlikely, but possible and worth striving for.

A team composed of average contributors with at least one superstar will produce above average results and possibly great results. The superstar(s) will challenge the team. The average members will strive to meet the challenge.

What about a team of all superstars? I don’t know that such a team has ever existed. If it did, the superstars would likely clash, disagree and dissolve into chaos. Be careful what you wish for.

Why are superstars so special?

Pay attention to the success stories you hear. Software development teams succeed in many ways and for many reasons. When a software team achieves a major advancement and a big success you will almost always find that there was strong leadership. It may have been a visionary, an idealist, or a perfectionist.

Regardless, someone took control and challenged the team to achieve more than seemed possible.

Organizations spend a lot of time on parity — getting everyone on the team to the same performance level. That approach makes sense on the whole but only if you also spend time on excellence.

Can you develop superstars internally?

Can you develop your own superstars or must you hire them from the outside? Developing them is hard to do but hiring them is not simple either. Regardless of your approach, answer the following questions:

• What is important to your business. What do you value most? How would define superstar within a particular group or team?
• If you have a star performer today, what characteristics does that person exhibit? What makes him a superstar?
• When someone exhibits superstar behavior, do you acknowledge and reward it? Do you let others know about the behavior?
• Do you provide the best tools and work environment that you can in order to extract maximum performance from your teams?
• Do team members have access to mentors, education and training to help them improve and become the best they can be?

Superstars don’t magically appear though they can disappear quickly if you don’t acknowledge and reward them. Want your agile team to do better? Nurture a superstar.

Agile and Big Companies Don’t Mix

The agile approach to software development has difficulty succeeding in big companies. This seems odd and almost counter intuitive but is simple to explain.

Big companies establish lots of policies and procedures. They are constantly in search of the cookie-cutter approach to solving problems and building things. Big companies are focused on performance and scalability. Just get it done — reliably and repeatably. Scale it up so lots of money pours in.

Ideally, they want to make the work output simple, routine and predictable. As they come closer to this ideal, they make fewer mistakes and keep customers happier. After all, everyone loves predictable and reliable!

Unfortunately, agile development is not simple, routine or predictable. This results in a fundamental inconsistency between what companies strive to be and what they need to do to be agile.

No one is doing anything wrong or trying to sabotage agility. They are doing what they have been trained to do and that training is killing teams trying to be agile.

The solution? We’re supposed to be agile, right? There is no procedure for solving this problem.

The approach and the ultimate solution are situational.

There needs to be compromise — give and take. The big company needs to offer some breathing room, some flexibility. Give a little and let the agile team show what it can do.

The agile team needs to accept a little more discipline and structure that it would like. Adapt a little and show the big company what you can deliver.

Be agile. Make it work. Got any ideas? Leave a comment.

There Must Be an Agile Way

How many times have you heard someone say, “There must be a better way.” I’ve heard it often enough but rarely does any real change follow.

There is surely resistance to change but the problem runs deeper. A “better way” is too general — too ambiguous. It is not actionable. What if the statement was re-phrased as “There has to be an agile way.”?

Agile principles are not just for software development. Any business process can be more agile. Adding the following concepts to any group effort will make it more agile:

• Cross-functional teams
• Empowered people
• Focus on value and excellence
• Risk reduction techniques
• Open communication and transparency

Ask a few key questions to draw out ideas and focus attention on the need for change. If people are serious about wanting a better way, the answers will lead them to it.

• If more people were available, could activities be overlapped (done in parallel)?
• Are there tools available that could automate the work or make it simpler or faster?
• Can the effort be deconstructed and reformed into an iterative set of activities?

The next time someone asks for a better way, ask a few questions and think of ways the team can be more agile.

Crisis Management Is Disruptive to Agile Teams

Crisis management is a tough job. The biggest problem isn’t solving the technical problem — given a little time, you surely can solve it.

The biggest problem is disrupting priorities. It plays out like this:

1. A crisis situation develops.
2. Priorities change to get people focused on the crisis.
3. Staff is moved around to get more people involved in solving the crisis.
4. The crisis is resolved and things return to normal — almost.
5. At least one of the projects that lost staff to the crisis is now in crisis — or will be soon.
6. The cycle repeats.

Once you get into crisis management mode, it can be difficult to get out.

There is no simple way to avoid this conundrum. When crisis happens, and inevitably it will, take a moment to evaluate scenarios and outcomes. Consider a few key questions:

• What if you ignore the crisis or take minimal action? What is the worst that could happen?
• If you drop everything and go into full-blown crisis mode, what benefits will accrue?
• If you delay other projects, what consequences will likely occur?

Your team will still have a crisis to manage but at least you’ll be making informed decisions and not just reactionary ones.