A Couple of Extra Sprints Go a Long Way

If you begin your project with a sprint zero (or iteration zero), does that make you less agile and more like waterfall?

A zeroth sprint is generally used to perform some upfront analysis or design work that serves as a foundation for the sprints to follow. It may involve a spike whereby there is a deep dive into the system to answer a few critical questions around what can be achieved and the level of complexity involved.

This effort differs from the typical sprint in that delivering a useful feature, that is, a completed story, is not required. The team is laying groundwork for the software and/or experimenting with system capabilities.

While some will disagree, I believe that starting off with a sprint zero can make your team more agile. It eliminates some degree of risk and helps you plan better.

Along these lines, ending the project with a sprint n+1 can help you tie up loose ends and apply a few finishing touches. Such a sprint is typically focused on fixing defects that could not be addressed earlier and/or performing final cleanup on the GUI and the documentation.

It can be argued that if you do things right you won’t need these pre- and post-sprints. Yes — and in a perfect world you will meet all the project goals and objectives with ease. Life’s not perfect. It needs your help!

Show Up and Be Agile!

Have you heard the semi-famous quote widely attributed to Woody Allen? “80% of success is showing up.” It’s good advice for everyone on your project team.

Let’s first define “showing up”. A physical appearance at the office is not enough. In fact in today’s virtual world, a physical appearance may not matter at all. What really matters is having your head in the game.

You need to be committed to the effort both mentally and emotionally. In other words, you must be fully engaged. If you can do that — every day — you are 80% of the way to a successful outcome.

Being engaged means being immersed in the process and tools used by the team. Making an appearance at the office and spending the day chatting with friends and shopping online is not engaged or committed.

So, how do you determine if each member of the team is showing up? Ask a few critical questions.

• Does each team member understand the key goals of the project?
• Does each person understand what he needs to do and why?
• Is each member committed to meeting personal and team goals and objectives?

Getting yourself and everyone else on the team to show up each day is not easy. There are far too many distractions making it easy to lose focus. It takes constant vigilance to keep a team showing up day after day until the project is done.

Want to be more agile? Show up!

Some Projects Deserve to Die

A software project will occasionally get off to a bad start. Maybe it was ill conceived. Maybe the concept was good but the approach is wrong. Maybe the concept and the approach are correct but the team consists of the wrong people.

Or, forget all that — maybe the project got off to a good start but something changed along the way. The original premise may no longer be valid; the chosen technology solution isn’t working; the team has lost a critical member.

Need more? Maybe the company direction has changed or a competitor has announced something completely unforeseen. The game has changed and so must the project.

It is truly frustrating to work on a project that seems headed for failure regardless of the reason(s) why. If you find yourself on a project that you believe is doomed, speak up. Don’t whine and complain. Instead, ask questions. Make everyone involved think about what they are doing and why they are doing it.

• Does the project have clearly defined goals and are they still valid?
• Does it appear that the goals can be met given the current constraints?
• Is the chosen technology up to the task? Is the team up to it?
• Are there other projects overlapping with this one? If so, why?
• Is the business ready to accept and use the resulting software?

Enterprise software development is never easy — agile or not.

For more insight on this topic, take a look at this posting called “Product Management Tip: If Your Product’s a Turkey, Kill It!” at voximate.com.

It’s Hard to Follow Agile Rules Exactly

Anytime a team embraces a new agile process a critical question comes up — must they rigidly adhere to the process guidelines or can they make adjustments to fit their needs? Even Scrum, with its simple rule set, falls into this unending debate.

You won’t find a strong consensus answer. The compulsive agile practitioners will claim that you must abide by the published rules. In the case of Scrum, they will tell you that if you don’t implement the standard Scrum rules as defined, you are not using Scrum and you can’t call your process Scrum.

The less compulsive (but no less agile) among us will tell you that it’s okay to adopt and adapt. The agile process you adopt must work for you; it must feel right and that usually requires that you adapt it to your situation.

Too much advice? What should you do? Consider this:

• It is usually best to start out following the agile process guidelines exactly. If you adopt Scrum, stick to it. Try to make it work. If you strongly believe that an aspect of Scrum is not suitable to your team situation, why not? What is the smallest change you can make that will adapt Scrum to your needs?
• If the agile process you select doesn’t seem to be working, why not? What is it  — exactly — that is not working? Is it really a process issue or is it a people issue? What is the simplest way to address the issue?
• Who is most resistant to the new process? There is always someone who wants to see the new agile process fail. The resistance may be obvious but it could also be subtle. Appeal for cooperation. If that fails, get the resister off the project. I know that sounds harsh but the alternative is team failure.

Many agile process failures are a direct result of failing to implement the process as defined. Your best chance at success is to play by the rules. Adapt it if you must, but recognize that changing the rules often makes the job harder.

What Makes Waterfall So Popular?

Big companies love the waterfall approach to software development. Why? It’s simple really. Most big companies thrive on the command and control approach to management. (Yes, it’s rooted in military history.) It works something like this:

• Define the goal.
• Prepare a plan to achieve the goal.
• Assemble the troops.
• Yell “charge” and schedule weekly status meetings.

To people conditioned to operate this way, agile approaches are terrifying. Why?

• The goal is flexible not fixed.
• The plan is loosely defined not cast in stone.
• The ‘troops’ cross organizational boundaries making command and control complex.
• The team is in charge and status meetings are replaced by team meetings.

So how do you get such an organization to try agile? Start by asking a few critical questions?

• How successful has the organization been in meeting project goals? Be sure they can offer hard data and not just general perceptions.
• How detailed are the plans they create? If the plans are high level only, they may actually be using an aspect of agile whereby they refine the plan as they go.
• How do they deal with cross-organizational issues now? It’s likely to be a thorny problem already. Agile techniques may make the management problem simpler by creating greater accountability.
• How do project teams make decisions? It is likely that the teams already make many of their own decisions. Agile techniques will help expose those decisions sooner and more often.

Identify the real issues and tackle them one by one. You don’t have to implement agile software development in one iteration or even during one project. You just need to get started.

Software Development Is a Faulty Process

Every software development methodology is flawed. Waterfall, Unified Process, Scrum, eXtreme Programming, Kanban, et al — they are all flawed.

Each has a place but it’s tough to know which one fits a particular situation best. There are many aspects to consider — company culture, team size and experience, problem complexity and scope, solution type, corporate policies, developer personalities — you get the idea. There is simply no way for one approach to work for everyone.

There are many examples of people who have successfully used a particular approach at a company. Yet, they moved to a different environment and the approach failed.

It may seem paradoxical but it’s not. Individual, team, and corporate differences require that the chosen approach be customized. You have to fine tune your techniques to align with the entrenched behaviors — at least at the start.

So, when you decide to apply agile principles in a non-agile environment, take some time to understand the culture, the people and the policies. Fine tune your preferred methodology to make it blend with the situation.

This will likely mean using techniques that make you less agile. This may seem counter productive but it improves your chances of winning people over and being successful. Once you’ve demonstrated some success, you’ll be able to make more changes and be more agile.

Agile: To Automate or Not, Does it Matter?

There are raging debates over using pen, paper and whiteboards to track agile projects versus a software tool. The agile purists eschew automation and rely on simple, manual implements.

I admit to being a computer advocate. If it was up to me, pens and paper would be banned.

But it’s not about what I like. It’s about what the agile team likes and what works for them. There is one important point about any software tool — it must be unobtrusive. Computers should make things simpler and faster. If the software gets in the way and forces you do to things in a manner you don’t like, it’s the wrong tool!

If you’re starting out using agile techniques, try the old-fashioned approach first. Good old pens, paper and whiteboards work just fine in many cases.

If you insist on capturing information electronically, spreadsheets work well to capture and track activities. They are good enough to get you started.

Once you feel more comfortable with the agile process, scope out available software tools and try a few. If you find one that works for you, use it.

You can go manual or automated. Either approach can work as long as it works for you.

Agile Is Better, But Not Faster

Companies often turn to agile software development in an effort to reduce time to market. Short iterations, frequent deliveries, integrated testing — sounds nimble and fast — right?

Not quite. Agile development,when done properly, has a relentless focus on the customer, teamwork, quality and continuous improvement. There is no goal to deliver a final product in less time than with other approaches. That said, agile holds the promise of delivering software better, cheaper, and yes, faster … over time.

Agile teams improve with each iteration and release. They learn from their mistakes, take corrective actions, and get better. It takes time.

So, if you decide to try agile development, be prepared to give it time. Your first major release will likely take just as long, or longer, than it would using any other approach. Be patient.

Too often, a company will give agile a try only to abandon it after one project because they did not see an obvious improvement. Any new process takes time for people to adjust and feel comfortable. Agile is no different.

If you’re looking for instant improvement, forget developing custom software and go with a commercial off the shelf package. It may not do exactly what you want, but it can be delivered and installed next week.

It’s Not What You Did, It’s What You Finished

One of the hallmarks of Scrum is having each team member answer three questions:

• What did you do yesterday?
• What will you do today?
• What issues do you face?

It seems like a good idea but fall the first two questions fall short. Let’s say that a software developer says she worked on the sort function yesterday and will work on it today. What does that tell the team? Nothing.

What really matters to the team is what was finished yesterday and what will be finished today. When something is finished, it is handed off to another team member for testing, documentation, deployment, etc. Merely doing something is a static activity that is extremely hard to measure.

To make this approach work effectively, you’ll need a clear definition of done. If someone is writing a software module, what constitutes “done”? If someone tests that module, when is the testing “done”?

It is also important to keep stories and associated tasks small. Everything should be measurable in one-day increments. Thus, each day team members can report that they finished something or have encountered an unexpected problem.

Once you know what done means and have short-duration activities, you can re-phrase the standard Scrum questions to make them measurable:

• What did you finish yesterday?
• What will you finish today?
• What issues do you face?

Good Process Is Not Good Enough

There is much discussion about how to build software right. Agile techniques help in getting the software right. But are a good process and a good result good enough? Are you building the right software?

I’m a big fan of risk management and prioritized feature lists but they are not enough. You need to understand how the solution fits into the corporate strategy and how it adds value to the company. Simple, right?

Of course not. All that rhetoric about aligning the business and IT is nonsense but there are few things to consider. You don’t want to end up with a great software implementation that misses the mark in term of what the business needs. Here are a few questions to ponder:

• What business problems is the software expected to solve?
• Are there related problems that will be solved by other approaches?
• Will there be lingering problems that the software is not expected to address?

This is all part of scoping out the entire problem space and envisioning how your software fits in. You can’t solve all the company’s problems but you can understand how your software fits in.

This blog entry at NetObjectives got me to thinking about this topic. Take a look!