Agile Software Development Will Never Go Mainstream

The headline of this post pains me but it’s true. Real agile approaches to software development will never replace the old and outmoded command-and-control approaches based on waterfall. Scrum, Kanban, XP, Lean, etc. will augment and improve waterfall approaches but never replace them. Here are two reasons for my pessimism.

The Safe Choice

Have you ever heard the old saying, “No one ever got fired for buying IBM”? It comes from a time when IBM was the king of the enterprise computing industry (some will argue that they still are). If an IT manager purchased equipment from IBM, he was making a safe decision. Even if the equipment didn’t solve the target problem, it would be assumed by many that no vendor could have provided a solution. After all, the manager bought from the best, right?

Today, companies don’t tend to dominate markets the way IBM did largely due to anti-trust laws. However, the same logic is true when it comes to any market leading vendor such as Apple, Cisco, Google, Microsoft, Symantec, etc. When you buy from the (perceived) best, you get a layer of protection from criticism.

Waterfall approaches to software development are the market leaders. They are widely used and accepted. Managers won’t be criticized for following them. Agile approaches carry more unknowns and more risks. Why would any conservative manager even consider an agile approach?

Protected By Procedure

My second rationale is more complex. It has to do with our penchant for following the rules. Most companies place plenty of rules around their software development efforts. They implement phases, gates, approvals, documents, hierarchies, reviews, standards, etc. to control every aspect of software development. Those controls aren’t inherently bad but become evil when carried to extremes.

The problem is that many people like extremes. Many managers like to tightly control how things get done. Many subordinates are eager to follow the rules. After all, you can’t be fired for following the rules, right?

Lots of rules and procedures provide a safety net. Everyone knows what they are supposed to do and how to do it. If anyone encounters a situation that’s not covered by the rules, they seek assistance so that the management team can make a decision. It’s safe and conservative. Agile approaches have few rules or procedures and relatively flat hierarchies exposing everyone to new risks. Why would any software developer even consider an agile approach?

Culture Trumps Process

These are high hurdles stemming from corporate cultures that demand conformance. If you follow the rules and make conservative decisions, you’re granted a layer of protection. If you bend the rules or make independent decisions, you could be reprimanded — even if you made the right decision.

In some organizations, the pain of the status quo will overpower the need to conform. When the software is consistently late, over-budget and crappy, management will sometimes be willing to adopt a completely new approach. That gives agile development a foot in the door.

Unfortunately, I’ve found that many organizations are willing to put up with a lot of pain to protect the status quo — self-preservation is more important than delivering good software. When the software development process battles with the corporate culture, the culture wins — every time.

Can agile software development ever replace waterfall development as the primary approach for software projects? I’m skeptical. Perhaps we’ve gone as far as we can go and it’s time for the agile community to move in a new direction. Any ideas? Your opinion is as good as mine so please leave a comment.

photo credit: shareski via photopin cc

7 Steps for Energizing Your Software Development Team in 2013

As we say goodbye to 2012 and prepare to greet 2013, we need to think about what we want to accomplish in 2013. Specific goals and objectives will vary widely among companies, workgroups and individuals. I can’t help you with those.

What I hope to help you with is how you achieve those goals and objectives. If you’re still operating the same way you did in the 1990′s or even the 2000′s, you’re living in the past. It’s time to move on.

The world around us and more specifically, the markets we compete within, are changing faster than ever. Consider the following as food for thought.

[BTW: These ideas work best when implemented from the top of the management chain down to the lowest levels. Any other approach will not achieve optimal results.]

1. Define your vision, communicate it clearly and instill a sense of urgency for getting things done.

Every company must have a corporate vision. From it, each division, department, workgroup and individual must derive a progressively narrower and more focused vision. Honestly, I’ve rarely seen companies manage their vision like this, which is one reason we’re drowning in crapware.

2. Focus on your customer (or stakeholder).

Everything matters — revenue, profits, products, features, appearance, etc. — but nothing matters more than the customer (or stakeholder) you need to satisfy. Put your ego aside and focus on your target audience. You’ll be more successful and less stressed.

3. Develop an agile mindset — not simply an agile approach.

Scrum, Kanban, XP, Lean, etc. won’t solve anything by themselves. Move beyond being flexible. Flexibility is reactive. Agility is proactive. Embrace change. Seek it out and make it happen. If you’re not changing, you’re dying.

4. Share everything. (Yes, really.)

Honesty and transparency build trusting relationships. There are too many corporate secrets. Most of it is legal gibberish. Stop labeling everything proprietary or confidential. It’s not.

5. Build relationships among business partners, workgroups and individuals.

Your success depends upon the people around you being successful. If they fail, you fail. Why is that simple concept missed much of the time? Success is 80% relationships and the other 20% doesn’t matter.

6. Empower everyone in every way.

Encourage everyone to make decisions, raise issues, offer ideas and just plain speak up. You may believe someone is shy or reserved when, in fact, you haven’t empowered that person to actively participate.

7. Establish accountability.

There’s only so much one person or team can do. We are dependent upon others to meet their commitments too. Everyone should have the tools they need to get their jobs done and the power to push ahead. Assuming they do, hold them accountable for delivering what they promise.

There you have it. Seven simple ideas that could transform you and your team.

Oh, and one more thing. Don’t pick and choose from the list. It’s all or nothing. You want to change, right?

photo credit: mdezemery via photopin cc

Plans Change. So Why Bother to Plan?

It’s true. Plans change. They change often. In fact, elaborate, detailed plans will change almost continually. Is it worth the effort to plan?

At times, agile software development is criticized because it’s perceived to lack planning. The perception is that developers simply jump in and start writing code. The process of writing code and delivering the executables to the users determines the end result. Plans, managers and metrics are cast aside as unimportant.

While there are some developers guilty of supporting such ideas, most don’t. Plans have value — when done appropriately.

Consider a simple example. Let’s say you intend to embark on a hiking trip tomorrow. You’ll be hiking in an area that you’ve never been through before. You know it’s wooded and hilly but you don’t know much else about it. You don’t even know how far you’ll hike. It will depend on how you feel during the trek and what the weather is like.

If you didn’t do any planning at all, tomorrow you’ll simply head out as is — wearing whatever you happen to have on, carrying whatever happens to be handy. You might end up hiking in casual shoes and slacks with no supplies or necessities. Crazy, right?

Plan. Don’t Agonize.

Clearly, you’d do some minimal planning. You’d assemble proper hiking clothing and set aside a few necessities such as a water bottle, a few munchies, jacket, hat, etc. You wouldn’t have a detailed route nor even know exactly what to expect but you’d be ready for the most common situations encountered by hikers.

A plan for dealing with emergencies would be an extra measure of safety. What will do if you fall and suffer a serious cut or a broken bone? Could you get lost and unable to find your way back? If the area is heavily traveled, these may be minor concerns but if the area is remote, a little planning could save your life.

As your hike progresses, you’ll make detailed decisions such as which paths to follow, what pictures to take, and when to stop and rest. These are decisions that would be difficult, if not impossible, to make in advance.

Agile Development Needs Agile Planning

A similar concept applies to agile software development. We don’t lay out elaborate, detailed plans. Such planning takes a lot of time and effort at the outset and also takes an ongoing commitment to keeping the plans current.

What makes more sense to us is defining a high-level plan, and making detailed decisions that align with the plan along the way. The plan keeps us headed in the right direction at the appropriate speed. The plan does not determine precisely what will be done or when. It guides us to the destination without dictating how we’ll get there.

How much planning should you do at the outset? Enough to give you confidence that the major project goals can be achieved. You have defined the major goals, right?

photo credit: DanieVDM via photopin cc

Enough Already! Why Are We So Obsessed With Bigness?

It happens all the time. As companies grow, they take on bigger and bigger software projects. Why is that?

Small companies work on small projects. Why? Simply because they can only handle small ones. They don’t have the staffing, equipment, office space or budget to handle big, long-term projects. Makes sense, right?

Big companies have many more resources at their disposal including partners, vendors and major customers. They have the apparent capacity to take on much bigger projects. So they do. If a small company can deliver something small, a big company can deliver something big. Makes sense, right?

Appearances Can Be Deceiving

This simplistic comparison of a small company to a big one contains a fatal implied assumption. The assumption is that complexity is linear. That is, as the company and more specifically its projects grow, complexity grows at about the same rate. That’s wrong! Complexity grows faster — much faster.

Think about this simple example. Imagine having a conversation with one other person about JSON data format (you don’t need to know what JSON is for this example). You might be an expert or a novice. Either way, the conversation would be informative.

Now imagine adding two more people to the discussion. It gets more complex. More questions. More details. More variations. More tangents. We’ve doubled the number of people and more than doubled the complexity.

Now add four more people. It’s no longer a single conversation. It’s multiple conversations and a whole lot more complexity.

The same type of thing happens with software projects. Going from a 10-person project to a 20-person project doesn’t double the complexity. It quadruples the complexity — at least. (I’ll spare you the math behind this conclusion. Take my word for it.)

I don’t mean to imply that complexity is bad. It’s not. As long as you recognize it and control it, you’re chances of success are as good as any software project. However, when you don’t acknowledge complexity and take appropriate steps to handle it, your project is DOA (dead-on-arrival). You may as well not even bother.

Then It Gets Worse

Complexity is not the only problem. Big projects develop personas. They take on institutional characteristics. They want to be preserved and protected. They even form antibodies to change making them highly resistant to efforts that might alter their courses or planned outcomes.

Many corporate executives have started colossal projects only to lose control of them. As more people are added to the projects, more and more ideas are generated. More ideas means more things to do — more artifacts to be delivered. Before long, the executive’s original vision is lost in the chaos and the project finds its own direction from within. No one knows where it will go. No one has control.

Enough already! Big software projects are bad. Smaller is better. Massive change efforts carry huge risks. Incremental changes are safer. Makes good sense, right?

photo credit: dgray_xplane via photopin cc

Don’t Try This On Your Next Project

You hear the words greatness, excellence and leadership quite often in the worlds of business operations and software development. Every person, team, organization and company should strive to be the best — but don’t go too far.

What’s too far? Perfection. You don’t need to be perfect — not even close. The results you produce need to be better than they were last time; better than the competition; better than whatever you’re replacing; better than your stakeholders expect … but not perfect.

Pursuing perfection paralyzes performance.

It goes back to a variation of the over-used 80-20 rule. In this case, you can achieve 80% of perfection in about 20% of the time it would take you to reach true perfection (assuming you could get there at all).

For example, let’s say it takes us 3 months to get to 80% of the ideal goal — perfection. It would take 15 months, five times longer, to reach the ideal. If we’re building a revenue-generating product, we’d have to sacrifice an entire year of revenue to get to 100%. If the software will be used internally to improve the organization’s results, we’d have to sacrifice an entire year of improvement.

Is that a tradeoff worth making?

I know some readers will shrug this off thinking that neither they nor their teams seek perfection. But, perfection can gnaw at us in subtle ways. Consider these:

• Fear of making mistakes
• Unwillingness to take prudent risks
• Refusal to incur any technical debt
• Obsession with grammar and formatting
• Inability to make critical decisions
• Hesitating to try anything new and different

You get the idea. Perfection isn’t only about the whole project. It’s also about the artifacts and components that make up the project — the little things. Spending an inordinate amount of time on any single issue or item can derail the entire project. Before long, a year has gone by and the business is still waiting.

photo credit: becca.peterson26 via photopin cc

Whiners and Complainers Can Be Sources of Inspiration

Would you like your team to do a better job? Do you want to change your approach? Try talking to the team members who are discontented — the disgruntled ones. Why are they unhappy? What would they change?

This can be a difficult conversation to have. Some people are just plain grumpy. They are the ones that always complain no matter what the situation is. I often say that some people aren’t happy unless they have something to complain about.

You really need to focus on those who can offer constructive criticism. It’s easy to complain and criticize. Anyone can do it. It’s much tougher to follow complaints with constructive suggestions — new ideas that improve the situation.

People who whine and complain constructively can be a source of inspiration. Here’s how to tap into it.

Define the Problem

The first step is to clearly define the problem. For example, if someone says that a process is too cumbersome, it’s largely meaningless. What precisely is cumbersome about the process and in what way? You need specifics. Here are some questions you can ask to get started.

• What’s going on?
• Why does this bother you?
• Is there something brewing within the group?
• What prompted you to speak with me?
• Does this happen often or occasionally?
• What are your expectations?

Explore Solutions

It’s important that the team member offer ideas for solving the problem. It’s not the job of a team leader or manager to solve every problem. If no ideas are presented, challenge the team member to find a solution and suspend the conversation. If an idea is offered, explore it and add one of your own.

• Can you move beyond pointing out the problem and help solve it?
• How can we solve this together?
• What changes do you recommend?
• Who else needs to be involved?
• How will these changes affect other teams?
• How quickly can this get done?

Agree on Next Steps

• Would you be willing to do X?
• If you’ll do X, I’ll do Y. Agreed?
• Let’s meet again tomorrow.

If you encounter someone who wants to change the world or proposes a big, expensive solution, bring the person down to earth. Explain the realities of budgets and potential impacts on other teams. I like to tell people to start small and lead by example. If you implement a positive and constructive change, others will gravitate toward it and more changes will follow. We all want to succeed, right?

Process Misalignment Is a Leading Cause of Agile Failure

Transitions from traditional software development approaches to agile ones fail occasionally. None of us who try to faithfully practice agile development like to admit it, but it’s true. I’d like to explore one of the key contributors to those failures — process misalignment.

Here’s an example of how this happens.

Let’s say the business stakeholders have a process they follow faithfully. For example, they meet every Monday morning to go over important open items and take corrective actions as needed. They either make decisions during the meeting or assign someone to resolve the issues offline.

This scenario is quite common across corporate America and it generally works well. The software development teams escalate issues to the business and they receive responses the following Monday. With waterfall development, waiting a few days on average for a response is normal and not disruptive. Project managers simply build these lead times into their schedules. (There is usually a procedure for handling urgent requests but it’s often cumbersome and its use is discouraged.)

Now the company decides to switch from waterfall to Scrum as the software development approach. Everyone agrees that going agile is a good idea. The new Scrum process is implemented but the existing business process isn’t changed. Those weekly meetings remain the venue where tactical decisions are made.

We have a process misalignment.

Agile developers generally need answers to their questions on the same day. They can’t wait until a Monday business meeting takes place. The business process and the development process are misaligned.

In this example, the root issue is that the software development team may be empowered and self-organized but the business team is not. In particular, the Product Owner doesn’t have the authority to make decisions. He is merely a pipeline connecting the Monday business meeting to the development team.

The point is that if you want your software team to be agile — I mean truly responsive and energized — the business stakeholders must be equally agile. Processes, attitudes and rules have to be aligned. It seems obvious but it’s often ignored.

photo credit: ant.photos via photopin cc