Software Development and Dieting Have Something in Common

Any change to the way we do things is disruptive. Any deviation from our normal routine is unsettling. Forget about the holy wars around what constitutes the “best” software development approach or whose diet plan produces the “best” results. The challenges of creating software and dieting are the same.

Why would a company change the way it builds software systems? Companies change their approach to software development once they conclude that what they’re doing is too big, too slow, or too costly. They want better, faster, cheaper results.

Why would a person decide to go on a diet? People decide to lose weight when they believe they are too big, too slow, or too costly (as in having to buy a new wardrobe). We’d all like to be healthier, fitter, and more appealing, right?

Consider the Challenges

Whether it’s a company writing software or a person losing weight, the challenges are similar. Many companies struggle with software projects that are usually late, over budget or unreliable. Making major improvements is difficult. Flawed processes don’t just heal themselves. It takes a lot of work.

As for the challenge of losing weight, it’s hard to do. It may be a few pounds or a hundred pounds. Regardless of the amount, you have to make some some basic lifestyle changes. Excess weight doesn’t just magically melt away as some marketing campaigns would like us to believe.

The basic steps to solving either problem are the same. The steps might look like the following (along with some examples):

• Establish goals
  • Company: reduce time to market by 20% or lower customer support costs by 30%
  • Person: lose 50 pounds, run a marathon, or fit into an existing wardrobe
• Evaluate approaches
  • Company: iterative waterfall, Scrum or XP
  • Person: Weight Watchers, Jenny Craig or South Beach Diet
• Prepare to follow the approach
  • Company: identify training materials and train employees
  • Person: study the diet and chat with others that have followed it
• Purchase necessary items
  • Company: buy equipment and software; setup office space
  • Person: buy cooking tools and food items
• Start the effort and track progress
  • Company: use charts and graphs to show progress
  • Person: track weight and strength/endurance

I could go on but you get the idea. The similarities are striking.

If you don’t have clear goals, you’ll either fail from lack of direction or you’ll accept whatever outcome you get and call it a day. Proper preparation is also critically important, as is tracking progress. It all has to come together to achieve a successful outcome.

Oh, I almost forgot! The most important aspect of any change endeavor is commitment. Some things will go wrong along the way. Mistakes will happen. The journey certainly won’t be smooth sailing. Those that succeed in any endeavor are those that defined clear goals at the outset and were committed to success from the beginning.

That’s hard to do as an individual and it’s even tougher as an enterprise organization.

photo credit: Rance Costa via photopin cc

Even When You Build the Right Software, You Can Still Get It Wrong

Is it more important to build the right software or more important to build the software right? The lazy answer is something like “…they’re equally important…”. Let’s not be lazy. Let’s think about this.

Build the Right Software

You can build the world’s best software system but if it doesn’t do what the customer needs, you’ve wasted time and money. For example, if you’ve built a system to generate comprehensive enterprise reports but the customer needs a system to do big-data analytics, you’ve failed. The reports may be easy to create and a pleasure to read but without the big-data analytics piece, they’re lipstick on a pig.

It’s astounding to me that this happens as often as it does. Everyone seems to think they understand what the “right software” is and what it needs to do. Yet when the system is ultimately delivered, key stakeholders conclude that critical features are missing. Then the blame game begins.

Build the Software Right

The other perspective is building the software right. Software that does exactly what the customer needs but is unreliable, fails. If the system was built is such a way that it’s slow and crashes frequently, no one will be happy. It’s great that it solves the specified business problem but if no one can effectively use it, what’s the point?

This too happens far more often than it should. There’s a joke among software developers who say “It works on my machine.” Just because the software works well in controlled environments like development and QA doesn’t mean it will work in real world environments.

There’s No Simple Answer

So which is more important? Would you rather have good, reliable software even it’s missing critical features and functions or poor, unreliable software that includes all the things you need it to do?

It’s clearly a rhetorical question. You’d need a lot more information to answer it. What features are missing? How often does it crash? Can the missing features be added quickly? Can the software defects be fixed readily? Of course, most delivered software systems fall between these two extremes — some features are missing and some aspects of the software are unreliable but, in general, things usually work fairly well.

Here’s the problem. When features and functions are left out — completely left out as in no one considered them — adding them to the system after delivery may be an incredible amount of work. The software may need to be deconstructed and rebuilt to include the missing pieces. Imagine building a house and failing to include a bathroom at the far end of the structure. Carving out the space and running the piping could be an enormous job. It would have been simple when the house was merely a shell, but not now.

Reliability problems discovered late in the effort are not so easily corrected either. I’ve seen software systems taken apart and reconstructed to resolve performance problems. I’ve seen defects that appeared to be minor result in major changes to the code. Imagine that bathroom again. If the plumbing and electrical services are inadequate to meet the needs of the bathroom fixtures, major rework will be needed to upgrade those systems. It will be highly disruptive.

You Can Have It All

It appears that the lazy answer — “…they’re equally important…” — may be the best answer. We need to define the software right and we need to build it right. Ultimately, it takes both to deliver great software.Why settle for good or adequate when you can deliver great?

How do you do that? Follow basic agile development principles.

• Be sure that the business and technical teams collaborate early and often.
• Deliver working software regularly and schedule formal review meetings to get feedback.
• Expect changes and be open to new ideas.
• Study software frameworks and good design practices. Use them!

photo credit: marsmet471 via photopin cc

Without Trust, No Enterprise Software Development Approach Can Work

I’ll bet you’ve seen this happen. It may even have happened to you. The business folks are using software they built to track and report something important. The software is a bit crude, maybe even primitive, but it works. It’s simple. (Often, Microsoft Excel and/or Microsoft Access are the preferred tools.)

Everyone loves the insights they get from the software. Now they want more — a lot more. The business wants to be able to mix, match, sort, filter, add, remove and combine just about every data element there is. And, oh by the way, they want the new software to be just as simple and intuitive as the current software.

The project is complex enough that they ask the IT department for help. IT decides that a new enterprise application is required and it will take several months to develop. The business people gasp — “SEVERAL MONTHS!”.

I’ve seen this scenario unfold many times over the years. It happens for three reasons. First, there’s a lack of trust. Neither side trusts the other to be open, honest and direct. Second, successful businesses become more complex over time. That complexity brings new challenges making it harder to get things done. Third, people get carried away. They wish for everything they can think of rather than focusing on what they really need.

Have you been there? What was the result? If you find yourself in this situation, consider the following advice.

Build Trust

1. Be transparent.

2. Be honest.

3. Commit to a long-term relationship.

Understand the current situation

4. Assess the data that’s being gathered and reported.

5. Be sure you fully understand what’s being analyzed today.

6. Evaluate how the data is processed.

7. Isolate the limitations of the current approach.

Define the desired situation

8. Gather stories that describe what people want to do — everything they want to do.

9. Find example user interface techniques from existing software that people like.

10. Determine if the current software can be changed/enhanced to meet the needs.

Build the new/enhanced system

11. Weed out the stories to get to what really matters.

12. Prioritize the remaining stories.

13. Build the new system in short iterations (2-4 weeks each).

Follow Through

14. Be responsive after each deployment.

15. Fix bugs — even those you don’t agree with.

Keep referring back to items 1, 2 and 3. It will take a lot of effort to build trust. It will take a lot of time to win people over. Like it or not, you have to do it. Without trust, none of the other steps will matter.

photo credit: SalFalko via photopin cc

Software Quality and Time-To-Market Should Never Conflict

Here’s a question that I believe generates some of the controversy around agile software development techniques versus waterfall techniques. If your team delivers fewer software features and functions but the software is higher in quality, are your user base and your company better off?

Agile teams often claim to deliver better quality software. I agree with that sentiment as long as the team follows core agile principles, in particular, “Customer collaboration over contract negotiation”. My experience with both agile and waterfall teams supports the quality claim. All software development teams have a strong tendency to over-commit. Agile teams figure this out fairly early in the development cycle and make adjustments. Waterfall teams figure it out much later and tend to sacrifice quality to stay on track.

Despite these tendencies, don’t rush to judgment in answering the question. Every major software company has rushed products to market knowing that the products weren’t ready. Here are a few examples:

• Apple: MobileMe and iOS Maps
• Google (and its hardware partners): Releasing “Beta” products and leaving them in beta status indefinitely
• Microsoft: Windows Vista
• RIMM: Blackberry Storm and PlayBook

Despite the problems faced by these and many other rushed products, there are good reasons for getting to market fast.

• Obtain first mover advantage
• Generate cash to continue product development efforts
• Respond to customer demand for new capabilities
• Respond to competitive threats
• Establish a position in a new market

The original question generates follow-up questions such as “How do you define quality?” and “What do I have to give up to get better quality?”. The questions are simple but the answers never are.

Agile teams are not immune.

Agile development teams also get sucked into rush-to-market tempests. The pressure to deliver something — anything — can reach stratospheric levels. When it does, quality often gets sacrificed. Unfortunately, customers, investors and the trade press share some of the responsibility for pressuring companies to release products too soon. You can have it fast but something else has to be compromised. That something is often quality.

For me, quality trumps features. I’d rather have a small and reliable feature set than a large and flaky feature set. The project team will eventually run out of time. The software will have to ship — ready or not. That’s why it’s so critically important to prioritize features and deliver quality results in each iteration.

Do you agree?

photo credit: Jmos® via photopin cc

Chickens, Pigs, Commitment and Teamwork

I’m sure you’ve heard the fable of the chicken and the pig as it applies to Scrum. In case you haven’t, it goes something like this:

Chicken: Hey, Pig, let’s open a restaurant.

Pig: Okay. What would we call it?

Chicken: How about ‘Ham ‘n Eggs’?

Pig: No thanks. I’d be committed but you’d only be involved.

The essential concept focuses on the level of commitment to a goal. In this story, the pig would be fully engaged and completely committed to the restaurant. He’d be “all in” by any definition. The chicken would play an important role but would not be as committed. (In other words, the chicken can do other things but the pig cannot.) It’s a fun way of making a point about level of commitment.

On Scrum teams, software developers and testers tend to be viewed as pigs because they are usually “all in”. Stakeholders, managers, end users, etc. are chickens because they support the pigs but aren’t fully engaged with them. As for Scrum Masters and Product Owners, ideally they should be dedicated and focused making them pigs. But if they have responsibilities outside the team, they are chickens.

Funny and Divisive

Regrettably, this funny story divides software development teams creating a kind of inner circle (the pigs) surrounded by outsiders (the chickens). For example, the inner circle gets to speak at Scrum meetings, while the outsiders have to stand against a wall and be quiet. Does that sound like teamwork and collaboration to you?

Everyone has a job to do. If anyone, inner circle or outsider, doesn’t do their part, the entire effort is in jeopardy. The best way to get people to do their part is to actively engage them. Draw them in. Encourage their active participation. Recognize them for their contributions.

I really wish that old Scrum story would just go away. I don’t like being thought of as a chicken or a pig. The story has served its purpose and outlived its usefulness. I think we need to move on. How do you feel about it?

photo credit: drp via photopin cc

Are You Accountable for Your Work? Let’s Hope So.

Are you accountable? Someone has to be. Work must get done. Software must be delivered. All the supporting artifacts that go into building great software must be created and maintained.

We all know that, right? But are you accountable? Is your work clearly defined? Do you know precisely what you have to do? Do you have a deadline to meet? Once you finish, do you know where to deliver the work output? Are you fully aware of the criteria for being “done”?

If you answered ‘no’ to any of those questions, your project is in trouble. In fact, your employment status may also be in trouble.

Accountability Matters

What’s the single most important trait in a good project manager? She holds people accountable. Say what you do and do what you say! It doesn’t have to be stressful. Deadlines don’t have to be tight. You simply need to know what needs to be done, when it needs to be completed, and deliver on time. A great project manager will hold you accountable.

Miss deadlines too often or repeatedly deliver incomplete artifacts and your time on her project will be limited.

Of course, Scrum teams don’t have project managers. They have Scrum Masters. Great Scrum teams self-organize with the guidance of a great Scrum Master. The entire team, including the Scrum Master, needs to be accountable. If anyone on the team drops the ball, misses deadlines or just gets sloppy, the Scrum Master has to focus attention on the problem and get the team to step it up.

Individuals are accountable for tasks and stories. Teams are accountable for sprints and releases. Scrum Masters are accountable for everything.

We should all welcome clearly defined activities. In fact, if someone is holding you accountable for something without specifying the delivery criteria, that person is doing a sloppy job. Hold him accountable! Make your manager, supervisor, project manager or Scrum Master clearly define what he wants and when he wants it. If he can’t do that, he cannot hold you accountable.

Don’t Go Too Far

By the way, none of this implies micromanagement. Establishing clear goals and deliverables is a good thing. Telling people how to do their jobs and looking over their shoulders is crossing the line. We want to be accountable, not leashed.

Accountability is not about identifying someone to blame or having one neck to strangle. It’s about delivering great software in a structured and reliable manner. Pick whatever approach to software development that works for your team and your company. Just remember that if I buy or use your software, I will hold you accountable.

photo credit: shareski via photopin cc

The Dark Side of Metrics: Be Careful What You Wish For

Many managers are fond of using metrics as a way to evaluate the performance of software developers. This can be done both at the team and individual levels. However, most metrics can be “gamed”, that is, manipulated to show the desired result.

Some readers are likely thinking that their teams would never “game the system”. It’s true that most teams would never openly conspire to change a metric result. However, in the end, people will do whatever is needed to protect themselves, their teammates, and their families. If management places the team under severe and unreasonable pressure to improve a metric, each member of the team will seek out ways to improve.

Here are a few examples of metrics that are fairly easy to improve:

•  To increase team velocity, increase the size of user story estimates.
•  To improve the pass/fail test-case ratio, avoid testing boundary conditions.
•  To reduce the size of the backlog, put fewer stories in it.
•  To produce more lines of code, write sloppy code.
•  To complete more tasks, divide the work effort into smaller tasks.
•  To reduce time-to-market, write less software and/or reduce testing.
•  To reduce your development costs, take on more technical debt.

These tactics may appear dishonest but it’s a matter of perspective. If I make a demand that most people view as unreasonable, I should expect that those people will satisfy the demand using equally unreasonable tactics. Fair is fair, right?

Focus on the right things.

One way around gaming is to track multiple opposing metrics. For example, you could track velocity and average story size over time. If velocity improves while story size increases, something is out of balance. But what problem have you solved? How has the company benefited?

In the end, metrics are internal measures of the past. They tell us how we did recently versus how we’ve done historically. The problem is that our customers don’t care. They want software delivered as promised; software that does what they need; software that works well; software that’s a delight to use.

The only valuable metric is your customer’s opinion of the software. That’s why the principles of agile software development make so much sense. Focus on customer collaboration and working software. Focus on the future. Use metrics sparingly to help identify and correct team weaknesses.

Metrics have their place but not as the team’s focal point. They are tools not outcomes.

photo credit: jcoterhals via photopin cc

Great Agile Teams are Adaptive and Resilient

This is the sixth and final post in a series about building great software using agile techniques. The series began here.

Many people, managers and developers alike, view agile development approaches like Scrum and Kanban as just another way to write software. Once they decide to try an agile approach, they quickly realize how wrong they are. Agile development isn’t about writing software. We assume you already know how to do that. Agile development is about delivering software.

I’d like to expand upon and summarize my original premises as follows:

1. Enterprise software development is complex and requires many skills. [Note: This series is not about small utilities or mobile apps. It's about software systems built and used by large groups.]
2. The agile manifesto is the definitive list of guiding principles and beliefs for agile development. [As such, it is a starting point, not an end game. We need more ideas.]
3. Agile development encompasses several approaches including Scrum, Kanban, Lean, XP, DSDM, FDD, BDD and others. [All are valid and applicable in appropriate situations.]
4. Applying agile development principles on an enterprise scale is much tougher than it looks. [Note: The Scrum of Scrums idea is merely a bandage.]
5. The hallmarks of truly agile teams are simple — they are adaptive and resilient.

What does it mean to be adaptive and resilient?

One of the key differentiators for agile developers is change. I’m not referring to accommodating user requests for changes to the software. That’s easy. I’m referring to changing the way the developers work. Changing the development process. Changing the very rules followed by the team.

Such changes need to be discussed, arbitrated and applied frequently — such as at the end of every sprint or cycle. If you’re looking for the ultimate, tried-and-true way to build software, look somewhere else. Agile development is about adapting to the current business situation.

If you develop software in a business that is changing rapidly or in an industry that is highly competitive, change will come at you fast. Your team must be able to learn and adapt continually. “Evolve or perish” is a good motto to adopt.

If your team is adaptive, there’s a good chance you can also be resilient. The terms are related though resiliency goes deeper. Resilient teams bounce back. They recover from adversity and find a way to succeed.

If you’ve worked on enterprise-scale software systems, you know that things will go wrong along the way — some things will go very wrong and cause near panic on the team. Resilient teams will swarm. They’ll apply their collective skills. They’ll change the rules. They’ll find a way to move forward.

The Attributes

To become adaptive and resilient, several attributes are essential:

• The team must be highly cohesive, loosely coupled and decentralized. [See this post.]
• They must implement constant feedback cycles and continuous improvement. [See this post.]
• They must exhibit rapid responsiveness and swarming behavior. [See this post.]
• They must have diverse skill sets and share a common vision. [See this post.]

Does your software development team have these attributes?

Would you describe your team as adaptive and resilient?

If not, what’s missing and what are you going to do about it?

I hope you found this series of posts interesting and thought-provoking. Whether you agree or not, I encourage you to leave a comment and expand the conversation.

photo credit: Seiya235 via photopin cc

Diverse Skills Need To Be Combined With a Common Vision

Great agile teams have diverse skill sets and share a common vision.

This is the fifth in a series of posts about building great software using agile techniques. The series started here.

If you read any books on agile software development, you’ll see references to multidisciplinary teams. That means the development team is largely self-contained. The developers have the ability to get the job done without excessive reliance on outsiders. Why is that important?

Enterprise organizations like specialization. They create many workgroups that focus on narrow areas of expertise. If anyone wants to do something covered by one of those specialized areas, they are required to issue a request to the appropriate workgroup.

For example, enterprise IT departments have database administration (DBA) groups. They include people who have the knowledge and authority to create and modify database structures. If anyone wants to create a new database or make changes to the structure of an existing one, they must request assistance from the DBAs.

There’s a good reason for that. If the enterprise has multiple systems relying on a database, changes have to be reviewed and coordinated. Making a change for one team could cause another team’s software to crash. Centralized control makes sense, right?

Until, the concept is taken too far. What’s too far?

• Applying the rule to every database even if it’s used exclusively by one software system.
• Applying the rule to development and QA environments, even if those environments are isolated (e.g. sandboxed).
• Applying the rule to every database change, no matter how small.

[I don't mean to single out DBAs for criticism. I'm merely using them as an example to make a point.]

Now imagine that there are several such specialized groups that every software development team must use. Each time they need assistance, they have to issue a request, enter a queue, and wait for availability. Does that seem agile to you?

Being Multidisciplinary Demands Vision

Agile software development teams have to be multidisciplinary by definition. They need team members who have multiple skills so that delays and wait times can be reduced or eliminated. They need an enterprise organization that gives them the independence to do whatever the team needs during the course of the project. Only then can real agility be achieved.

Having independence and using it wisely require that teams have a common vision. The team members have to work together with a shared purpose and a unified commitment. In this way, they’ll develop trust that, in turn, fosters collaboration. So through a common vision, the team will develop the strength to be independent and work as a unit.

Swarming won’t work without a common vision (see my last post). Even simple tactics like pair programming, will devolve into pair arguing without the joint commitment and shared ownership that derive from a common vision,

I’ve never said that enterprise software development is simple. While it’s fairly easy to be good, it’s difficult to be great and impossible to be perfect.

Is your team multidisciplinary?

Does your team share a common vision?

How would you characterize your team — good or great?

I’ll wrap up this series of posts on what it takes to be a great software development team in my next blog entry.

[The next post in this series is here.]

photo credit: chrismar via photopin cc

Agile Teams Swarm to Greatness

They are known for rapid responsiveness and swarming behavior.

This is the fourth in a series of posts about building great software using agile techniques. The series started here.

I’ve said before, “Plan less, deliver more.”

Others have said, “Stop starting and start finishing.”

Sounds crazy, right? How can your team deliver more software by doing less planning? How can they finish without starting? People who champion agile software development must be nuts!

Okay, these claims use exaggeration to make a point. Agile developers don’t sacrifice planning as a way to write more software. Nor do they skip project initiation activities and simply throw software over the wall into production. Let’s get serious.

The key point is a simple one. Agile teams respond rapidly. They quickly go from planning to designing to coding to testing to finishing. Then, they do it again — and they keep doing it until the software meets the goals defined by the stakeholders.

Don’t lose the excitement.

I’ve witnessed several cases where business stakeholders were excited by the prospect of a new software application. They cooperated in a lengthy discovery phase where requirements were gathered and documented. They grudgingly reviewed and approved hundreds of pages of documentation. Finally, they were told that the software would be delivered in six, nine or twelve months.

In every case, the stakeholders were disappointed and lost interest. In some cases, they sought out alternatives because the delay was simply too long. Business can’t wait.

Agile teams know that delivering something of value, early and often, is a critical success factor. They are fully aware of the need to respond rapidly both to the initial request and to the ongoing feedback after each delivery. Stakeholders need to experience the software not simply read about it. Incomplete software is okay. Nonexistent software is not.

Great teams swarm.

One technique agile teams use to respond rapidly is swarming. This is simply the act of coming together to solve a problem or get something done quickly. Great teams don’t point fingers at others or engage in blamestorming. They pull together and do whatever it takes to finish the current activities.

Swarming focuses energy at a critical area or key activity so it gets done. Most often, teams swarm when there is a mission-critical problem such as system or customer down. That’s fine though great teams use swarming as a planned activity. They recognize that difficult issues will be encountered during sprints and everyone will have to jump in and assist.

When you reduce the time spent on initial planning and designing, you have to anticipate that unforeseen issues and impediments will surface during the project. You could simply toss them into the backlog and worry about them later but your backlog could grow endlessly. Instead, great teams swarm. They try to resolve the issue or remove the impediment now. If they can’t, fine, move it to the backlog but only as a last resort.

Does your team respond rapidly?

Do you see swarming behavior in your organization?

If you answered no, greatness will elude you. Your team may be good, but it will never be great.

Swarming is a natural, instinctive behavior. It’s been observed in single-cell organisms, insects, wild animals and humans. Take advantage of it.

[The next post in this series is here.]

photo credit: gydnew via photopin cc