The Preservation Trap Steals Productivity and Depletes Morale

Have you ever noticed that start-up companies have a sense of urgency while established companies have a sense of preservation?

It makes sense when you think about it. Start-ups have nothing to lose. They have little or nothing to preserve. They need to build something and get it out into their target markets. Only then can they accumulate knowledge, processes, documents, inventory, skills, etc. that are worth preserving.

On the other hand, established companies have much to lose. They need to protect what they’ve accumulated and not disrupt their normal operations. Urgency often takes a back seat to preservation.

Software development teams fall into the preservation trap too. Established teams have a lot to preserve and protect. Here are a few examples:

• Software architecture
• Development process
• Existing documents
• Team member roles and titles
• Work habits

There’s nothing wrong with a strong sense of preservation — protecting your team. Problems arise when the sense of preservation becomes more important than building great software systems, rapidly. This will eventually have an adverse impact on team morale and productivity.

The best way to overcome the sense of preservation is to create a sense of urgency. Get the team excited about delivering something new and different. Challenge them to reach further and hit stretch goals.

Make sure you can justify the urgency. The team will see right through any artificial or contrived “urgent” needs. You don’t want to instill fear or panic. You want to motivate, energize and create excitement. How? Consider these example goals:

• Beat a competitive product — be specific about which product and what needs to be better
• Outperform a competitive service — again which service and what aspects of it
• Increase profits — by how much?
• Reduce expenses — which expenses and by how much?
• Improve the revenue stream — increase existing revenue or add new revenue?
• Enter a new market — be specific about the target
• Land a major new customer — who and why?
• Win a new contract — which one and why?

You’ll note that I made no mention of adding software features, improving quality, or reducing time to market. None of those represent an ultimate goal. The goal needs to focus on the business and financial outcomes. This will energize everyone in the company, not just the software developers.

Do you arrive at work on most days with a sense of urgency or preservation? Let me know.

photo credit: Mait Jüriado via photo pin cc

Car Racing and Software Development Have Something in Common

Enterprise-scale software development is bit like car racing. I’m not thinking about speed or agility. I’m thinking about complexity. Hear me out.

Let’s take NASCAR racing as an example. It looks simple. Drivers go round and round on a track as fast as they can. Fastest car wins, right? Not at all!

Racing crews win races not just individual drivers. A crew consists of the crew chief, tire changers, fueler, jack man, etc. In addition, there are racing teams. A team might have three or four drivers and crews in a race. Those drivers will help each other during the race using techniques like drafting and blocking.

Tires always have a major impact on race results. Crews make real-time decisions on when to change tires and whether to change all four or only two. Fresh tires are always better but changing four tires means spending more time in the pits.

Pit stops are a major factor in every race. No one ever runs a complete race without making pit stops. Crews employ varying strategies to maximize distance between pit stops and achieve the perfect balance between lap times and distance traveled. Many a race is won or lost in the pits.

The more people learn about NASCAR racing, the more they enjoy watching it.

What does this have to do with software development?

Like car racing, software development looks simple. Software team members write code, pool their efforts, iterate a few times, and deliver a final system. Simple, right?

Like car racing, there are other considerations — team dynamics, change requests, error handling, standards compliance, security controls, audit trails, report generation, data validation, response times, memory usage — to name a few.

Many aspects of enterprise software development are simply not apparent to observers outside our profession — just like the strategies used in car racing. Most of these aspects fall into the category of non-functional requirements. They are items and issues that are important to the proper operation of a software system and to the company’s ability to support the system. Yet, it’s hard to measure the business value they offer.

Educate and Engage

Those of us who build software systems need to do a better job educating business people about all the considerations around building high-quality enterprise software. At times, it seems that we want to know everything about how businesses operate, yet we closely guard our secrets for building software.

The more business people learn about the process of developing software, the more they will engage with us and become part of our development teams. Only then can we achieve real agility.

photo credit: Darryl W. Moran Photography via photo pin cc

Stop Managing. Start Leading. Be Agile.

Managers: Want your company to be more agile? Learn to let go!

Managers are trained to maintain control. Their annual reviews reinforce the need to make good decisions and stay in control. And then along comes agile software development.

There’s an immediate and harsh conflict. Agile teams need to take control. They can’t be agile if they’re simply following orders. That’s much too restrictive.

When I refer to an “agile team”, I’m talking about all the people needed to make the product or software system successful. So it’s not just about software engineers. We need to include real end users, business stakeholders, marketers, UX designers, testers, data center operators, etc. Only multidisciplined teams can be truly agile.

Of course, with so many diverse groups represented on the team, we’ll have many managers involved. There will be one or more managers associated with each specialty group — for example, a group manager, department manager and director. Every group manager will want to control his or her team members. That spells c-o-n-f-l-i-c-t!

Those team members will be torn between allegiance to their team and allegiance to their managers. It’s not right to place them in that position. Let go!

It’s the difference between managing and leading.

Managers seek to control. They establish procedures and protocols. They define rules and systems to maintain order. They are primarily responsible for running the business.

Leaders seek to energize. They create goals and motivate people to reach them. They establish direction, communicate it clearly, and help clear obstacles. They are primarily responsible for aligning people with the needs of the business.

Of course, few, if any, companies refer to their managers as leaders. It’s probably just as well. Titles are rather meaningless, anyway. The bottom line is managers need to stop telling their people what to do and how to do it. Instead, they should ask questions. Listen to the answers. Guide. Motivate. Prioritize.

It’s fine to express concern and even to pitch an idea to the team. But, ultimately the team members need to make decisions guided most directly by the Product Owner and/or key business stakeholders. (Hopefully, those folks are being driven by the end users and strategic business goals!)

Are You a Software Development Extremist?

Some of us tend toward extremism. It manifests itself in many ways in both our personal and professional lives. It could appear in the clothes we buy, the cars we drive, the way we work, or the way we look. In many situations, we’re not even aware that we’re extremists.

In software development, there are (at least) two extremes you should avoid.

One extreme is being rigid and inflexible regarding requirements, work plans, schedules, documentation, etc. Everything must be predefined and locked down. A change management (a.k.a. change prevention) process is used to see to it that nothing changes unless several managers agree to the change in writing.

The opposite extreme is letting every aspect of the project float. Nothing is locked down. Anything can change anytime. No single individual is ultimately in charge or accountable. The team wants to be left alone and succeeds or fails as a unit.

Do either of these extremes seem reasonable to you? If so, I’d love to hear from you so that I might better understand why you feel that way. I believe that the vast majority of us prefer to stay away from the extremes and seek out a balanced approach instead.

Because the focus of this blog is agile software development, I’ll direct my thoughts there. I see many definitions of agile development (in the form of Scrum, Kanban, Lean and XP) across the Internet.

Here are a few extreme misconceptions.

1. Agile development lacks controls and commitments — it’s chaotic. No it’s not. It’s fluid. Agile teams commit to deadlines, budgets and quality levels. Software features are allowed to float.
2. Being agile means eliminating project managers, business analysts, and system architects. No it doesn’t. Big projects still need senior people to guide the teams.
3. Agile teams don’t write specifications or documentation. Not true. They don’t waste time writing needless or redundant documents. They write documentation that matters.
4. You need an omnipotent Product Owner to be agile. No, Product Owners don’t need the ability to walk on water. They need to be skilled in solving a mix of technical and business problems.
5. The team has to be co-located to be agile. Just not true. With the right tools and the right management support, distributed teams can be just as agile as any other.
6. The project status board has to be a dedicated whiteboard with sticky notes. Actually, electronic status boards are fine. You simply need to invest in the right equipment and software.
7. Agile development does not work in regulated industries. Wrong. It takes discipline and structure to do agile development well. Those are also the qualities needed by regulated industries.
8. Agile developers are cowboys (or cowgirls). They just want to crank out code all day on their own terms. Nope. Anyone wanting to be a lone ranger should start their own company. Agile developers need to be multidisciplined and team oriented.
9. Agile development can’t be scaled. It’s for small teams. Agile development can be scaled though it’s hard to do well. The key is to start small and scale up using retrospectives as the continuous improvement tool.
10. Software architecture and user experience design are ignored by agile development teams. Ridiculous. Software architecture and UX can be improved through agile techniques. Start simple and add complexity as the software evolves.

Oh, and here’s a bonus extreme misconception for you to ponder.

• You can make your prescriptive (a.k.a. waterfall) approach to software development just like agile development by including a few agile best practices. NOT!

The Advantages of Distributed Software Development Are Enticing

Distributed software development teams are becoming more common. There are some good reasons for it. Here are a few:

• Access to potentially lower cost talent
• Ability to attract highly-specialized and hard-to-find talent
• Outreach to a larger and more diverse labor pool
• Advantages of an extended work day via time differences

The potential benefits are enticing though they come with unique challenges. Software development is hard enough when the entire team is together in one place. Adding the complexity of having team members scattered around the country or around the world only makes it harder.

The traditional approach to this added complexity is to document, approve and control every aspect of the development process. Fight complexity with complexity! This is an administrative and legal solution to a problem that’s founded in people and technical issues. It doesn’t work.

If you have an interest in distributed software development, I invite you to read a guest post I wrote for Colabpro. Agile development techniques reduce risk and simplify the management of distributed software teams. The post is called “How Agile Principles Make Distributed Software Development Better”.

Please take a look and let me know what you think by leaving a comment at Colabpro or here.

In Agile Software Development, Context Really Matters

Mark Mansour over at Agile Bench published a blog post titled “10 Agile Bloggers You Should Know About, But Don’t”. It’s worth reading. (Please note: In the interest of full disclosure, this BrainsLink blog appears in the post.)

A phrase in Mark’s post got my thinking. There are several lists of top agile bloggers around, “many of whom are book authors”. You’d expect book authors to be good writers and thus you’d expect their blogs to be well-written and insightful. Fair enough. But are their agile practices useful in environments like yours? Will their theories prove themselves in your situation? More to the point, will the author’s approach work for you?

You’ll need to answer those questions for yourself. (I won’t openly criticize another blogger unless the other person has specifically agreed to an open debate. CEOs of major corporations are exempted because they expect to be criticized and they have staffs to help them handle it.)

Anyway, I strongly recommend that you learn about agile software development from multiple sources. The approach you select must ultimately work in your situation. Just because an agile approach worked for a particular author, doesn’t mean it will work for you in your current environment.

Context really matters.

I’m a big fan of Scrum and Kanban (especially when combined) though I’d implement them very differently in a small start-up versus a major corporation. Start-ups are easy to change because they aren’t overly invested in anything. Major corporations are hard to change because they have institutionalized much of what they do.

So my thanks go out to Mark for taking the time to read my blog and others like it. I’ve also added Agile Bench to my Tools List. Please check it out. I believe it is the most comprehensive list of agile software development tools anywhere on the Web.

Software Teams Have to Manage Scarcity to Be Successful

Scarcity is fact of life. There’s never enough time or money to complete a software project — and that’s only the beginning. Every project runs out of something it critically needs. Here are a few things you might not have enough of:

• Time
• Money
• People
• Computers
• Storage Space
• Network Bandwidth
• Software Licenses
• Office Space
• Chairs
• Patience
• White Board Space (write smaller!)
• Sticky Notes (well, only if you run out of money)

You get the idea. Every project invariably runs out of something during its existence. How the team reacts to the situation may well determine the outcome of the project. If the team manages scarcity well, its chances of success improve. If the team whines and complains, failure becomes more likely.

This is another reason why software development teams need to adopt an agile approach like Scrum, Kanban, Lean or XP. Agile teams can rapidly adjust to scarcity and move on. Teams using more prescriptive approaches like waterfall, are forced to re-plan and re-group. Valuable time is lost. Money is wasted. The situation usually gets worse.

Don’t let scarcity derail your project. Good planning should help you anticipate areas where scarcity may become a problem. Address the scarcity if you can. If there’s nothing you can do to increase the supply, find a way to compensate. Do the best you can with what you have.

Many great companies run lean. They’ve learned to live on the edge of scarcity. You can too.

An Agile Dilemma – Stop Talking. Start Delivering.

A challenge awaits any IT group switching from a waterfall process to agile software development. It is often overlooked. It has to do with the mindset of the company’s business community and how they perceive IT.

The business stakeholders and end users have historically complained about issues like the following:

• It’s difficult to get IT to focus attention on their problems.
• Once they have IT’s attention, it takes a long time to get new or updated software delivered.
• IT won’t deliver everything they request, so they have to request everything they can think of.
• Once IT delivers (if they deliver), it will be a long time before they see any updates.

Ouch! How stinging is that! (Yes, these are real complaints I’ve heard over the years at multiple companies.) Does it describe your IT shop?

These complaints are a direct result of the waterfall process coupled with change control (better described as change avoidance). Waterfall approaches don’t always take longer than agile ones but it feels that way. There’s long lead time between user requests and tangible software. It feels like an eternity.

An Agile Dilemma

Now, let’s say IT decides to switch to some variation of Scrum. They seek collaboration with the business community. What would you expect them to encounter? Skepticism, right?

Scrum offers solutions to the above complaints in the form of:

• A dedicated software development team
• Frequent software deliveries
• Incremental improvements until all requests are filled
• Change acceptance

If you were on the receiving end of these promises, what would you think? How would you react? (I know I’d be extremely skeptical.)

Here’s my suggestion. Actions speak louder. You already have a backlog of user requests, right? There must be plenty of requirements that didn’t make the final list or were dropped during the project. There must also be defects that didn’t get fixed or weren’t fixed to the satisfaction of the users. Start with all these backlog items and software defects.

Get to work. Fix something. Add something. Re-work something. Just do something. Deliver it. Now repeat!

Engage the business stakeholders and end users in productive conversations about each delivery. Explain to them that this is how agile development works. It’s a whole new approach. You’re showing them, not just telling them. They’ll get the idea and become engaged in the new process almost immediately.

Stop talking. Start delivering.

This Test Will Help You Determine How Agile You Really Are

We sometimes talk (or write) as if agile software development and waterfall software development are two completely separate and different ways of building software. Yet, in reality they have much in common and it can be hard to slap a label on the process followed by any particular team.

With that in mind, here are seven key criteria that are often different among software development teams. Score your team in these areas and see where you end up. It will help determine if the process you’re using is more agile-like or waterfall-like.

The score for each criteria runs from one to ten where one is waterfall and ten is agile. Most answers will be likely be in-between the end points. That’s okay. No team is likely to be a perfect 7 or a perfect 70. Be honest.

At the end you’ll find a range of scores to help you determine how your team stacks up.

1. Requirements and Scope Definition

1 – Requirements and scope are well-defined and stable. Stakeholders and end users communicate them clearly and in writing.

10 – Requirements are poorly defined, uncertain and/or subject to change at any time.

2. Stakeholder and End User Involvement

 1 – Stakeholder and end user involvement are intermittent.

10 – Stakeholders and end users are available when needed.

3. Team and Process Experience

 1 – Team, technology and business process are mature. Project methodology is established and documented.

10 – Team likes new challenges and embraces change. The technology or business process is new and unproven.

4. Team Communication

 1 – Information exchange is formal and in writing.

10 – Information exchange is informal, open, and usually face-to-face.

5. Team Structure

 1 – Departmental hierarchies are important and management is top-down.

10 – Teams are cross-functional and self-organizing.

6. Planning Approach

 1 – Project planning is front-end loaded and detailed.

10 – Project planning is spread throughout the project and adjusted as needed.

7. Process Governance

 1 – Development process is structured, complex and audited.

10 – Development process is fluid, analytical and adaptive.

Scoring Summary

• 56-70: It’s an Agile approach.
• 42-55: It’s an Agile approach that needs work.
• 28-41: It’s mostly a Waterfall approach with some improvements.
•  7-27: It’s a Waterfall approach.

Remember, this is a single data sample and a simple one at that. I’m sure some will disagree with one or more of the criteria I’ve chosen or wonder why I left something out. These are the criteria that I view as most important. If you’d like to offer an additional item or change something above, your constructive comments are welcome.

Failure to Collaborate Threatens All Large Software Projects

There’s a famous quotation from the classic movie Cool Hand Luke that applies to many business situations; “What we’ve got here, is failure to communicate.” In many post-mortem evaluations of failed projects, inadequate communication is cited as a primary reason for team turmoil.

Companies have responded by making it easier to communicate. Many of us carry smartphones enabling us to receive and reply to e-mail messages anytime, anywhere — even on vacation. We also have instant messaging and text messaging that allow informal conversations with anyone regardless of location.

Now that we’ve solved the communication problem, many people argue that over-communication has become a major burden. In particular, managers are overwhelmed by the non-stop blizzard of messages that rage 24 hours a day, seven days a week. There simply isn’t enough time to think through and understand every message.

The real problem is no longer failure to communicate. It’s failure to collaborate.

Teams and workgroups need more than the ability to send and receive messages. Exchanging messages certainly qualifies as communicating but it’s not exactly collaborative. High-performance teams must be able to share knowledge while using it to generate new ideas.

I’m a big fan of software tools. Technology has created the information overload problem and technology can solve it.

There’s an abundance of software tools available that enable collaboration. They fall under the three broad categories of document, content and knowledge management tools. The terms are often used interchangeably however there are differences among the three.

Types of collaboration tools

Document management is a structured means of storing, locating, and tracking business documents. The files can be word processing documents, spreadsheets, images, audio or video recordings, or any other file type. Multiple revisions of the files can be saved showing how the information evolved. In addition, security controls define who has read or write access to the documents.

Content management is focused on creating documents and controlling changes to their contents. This solution is used when two or more people are creating or modifying a single file such as a word processing document. Additions and changes are controlled by the software to avoid conflicts.

Knowledge management is about capturing worker experiences and making the information available to others. Most companies do this by creating word processing files or spreadsheets. While effective in capturing information, this approach leaves much to be desired in sharing it. A knowledge management system stores information in a database making it much easier and faster to search and retrieve.

Collaboration tools solve two large and growing problems. The first problem is information overload. Most of us are nearly drowning in a vast sea of computer data. If it’s not managed, it’s useless.

The second problem is information sharing. It’s great if one of your employees seems to have all the answers but what about everyone else? What happens if that gifted employee leaves the company?

Communicating has gotten much easier making failure to communicate less of an issue. Of course, progress brings new problems. Now we have to deal with failure to collaborate.

Don’t let it happen to your team!

While there are a variety of commercial vendors offering software products, check out OpenSourceCMS.com for information about open-source content management systems.