Retrospectives Make Agile Teams Better

Good agile teams rely on retrospectives to maintain their edge. Not-so-good agile teams often ignore retrospectives. (Come to think of it, the same is true of traditional software process teams.) I don’t know about you, but I find that intriguing. Retrospectives attempt to answer a few simple questions and use the answers to improve the […]

Is Quick and Dirty Such a Bad Thing?

I sat in a meeting today discussing a complex customer problem with the team. We brainstormed and quickly determined that a good, clean solution to the problem would take more time than the customer was willing to give. I suggested that we try to find a partially manual work-around to buy us time to implement […]

Gantt Charts Offer the Illusion of Control

Agile software development is often criticized for lack of detailed plans and associated control points. Many managers would like to see gantt charts for agile projects containing carefully laid out tasks and deliverables. Yes, the gantt chart is the ultimate project planning tool. Why? Because it offers the illusion of control. Have you ever taken […]

Multitasking Is a Myth; Focus Is the Solution

One simple reason why many agile (and traditional) projects fail is the multitasking myth — the team members are working on more than one project. They are allocating time as needed across multiple unrelated activities. There’s a commonly held belief that humans are capable of multitasking. The theory is that we can juggle many balls; […]

Agile Success Demands 12 Agile Principles

Every software development process is subject to plenty of criticism. Agile methods are no exception. Regrettably, in most situations where a methodology “failed”, the people following it cut corners. They adopted some but not all of the core ideas. Failure risk always increases when you do that. At times, people take things too literally. Or […]

Accurate Software Estimates — Impossible?

Estimating is hard. Hours, days, dollars, story points, function points, use case points, lines of codes … whatever — they are all tough. The only reliable estimates are based on prior experience. If you have never performed a task before there is simply no way to estimate how long it will take YOU. 3 people […]

Project Requests Can Be Tough to Turn Down

At times, being agile simply means having the ability to speak freely. For example, a senior executive may make what appears to her to be a simple request, for example, a software application to track customer purchases. You have all the data, how tough can it be? Enterprise-scale software is always tough. You need a […]

Google Search Is Broken … Still

I use Google search heavily. Every day. I also use Gmail, Google Docs, Google Calendar, Google Maps and YouTube. There are alternatives for all of them but Google does a nice job and the integration across applications is a big plus. Google clearly dominates Internet search and wants to dominate cloud-based services in general. All […]

Design Is Important, But How?

One of the biggest criticisms of agile development is the lack of big design up front (BDUF). This leads to inefficient implementations, poor performance, and ever-changing internal structures — or so the arguments go. Agilists opposed to BDUF argue that spending too much time designing early in the development cycle is largely a waste of […]

A Team in Conflict Can’t Be Agile

It’s tough to be agile when team members collide. Heck, it’s tough to just get anything done when you have members on the team that don’t get along. It’s unfortunate but it happens — often. Why can’t we all just get along? Hostilities develop for many reasons. At times, it seems that there is no […]

Be Agile to Innovate

Innovation is not a technical problem. Anyone can innovate. It’s a cultural problem. Big organizations block innovation by pulling every idea into the corporate mainstream. It works something like this… Employee: “I have great idea. There is an untapped market for X and we are in a unique position to capture it.” Manager: “Yes, you’re […]

Ready, Set, Stop. Energize!

The week between Christmas and New Year is historically focused on family, not business. Plenty of business gets done, but staffing and intensity levels are reduced. We all need time to unwind, decompress, chill out or simply relax. It seems that many of us make ourselves available 7 days a week, 16-24 hours a day. […]

Sports Lessons Learned for Agile Development Teams

There are some interesting similarities between professional sports teams and agile development teams. Think about it. Whether it’s baseball, basketball, hockey, (American) football or soccer, teams spend a lot of time training and conditioning. They prepare a game plan and create player match-ups. As the game unfolds, they make adjustments. No game ever goes exactly […]

Distributed Agile Works Better

Let’s be honest — managing geographically distributed teams is tough. Here’s a simple breakdown of how teams might be distributed from least distributed to most: Shared space: This is the simplest. Everyone is in close proximity in a shared office area. Separated shared space: Everyone is in the same building but in different areas/floors. Different […]

Agile Development Is Not All Or Nothing

The transition from chaotic software development to agile has got to be easier than the transition from waterfall to agile. If a team is not following any process — just winging it — adopting a structure, any structure, can only help. In my experience, people don’t like chaos — complete lack of any process — […]

Business and Technology Worlds Collide

Dealing with the business users of a software application can be a real challenge. It’s rare that you find a user group that embraces agile software development and wants to actively participate in the process. There are two predominant types of business groups that you’ll encounter in agile development. The first is a business group […]

Be Agile: Build a House Iteratively

People often struggle with how to apply agile techniques, particularly iterations or sprints, to their situation. They are so entrenched in the ways of waterfall that they cannot envision another way. Let’s consider a simple example — building a house. The traditional approach looks something like this (simplified): Design the house. Dig a big hole. […]