Month: January 2011

Sprint Results Are Not Releases

In agile software development, it’s widely believed that every Scrum sprint should result in software that is ready to ship. The theory is that the team will be able to stop or suspend development at the end of any sprint and ship the software to the end users. This means that the team is always […]

Don’t Skimp on Software QA; It’s Not Agile

There are two major schools of thought around quality assurance (QA) testing. The waterfall crowd appends QA to the development process while the agile crowd integrates QA into the process, sort of. The waterfall approach has an obvious problem. If defining and writing the code takes longer than planned (very likely) and the schedule is […]

Are you on a Team or in a Workgroup?

If you have four software developers, a Scrummaster and a product owner, do you have a team? Is that all it takes to assemble an agile team? Forming an agile team is not easy. Most often, a group of people are assembled and given a common corporate goal. They create a plan and start working […]

LibreOffice Is an Important Open-Source Project

When Oracle bought Sun Microsystems they acquired the rights to OpenOffice, an open source equivalent to Microsoft Office. Sadly, Oracle is not known for its openness or contributions to open source projects. It began to look like OpenOffice would become OracleOffice. Thankfully, some of the OpenOffice contributors decided to fork the code and create LibreOffice. […]

Enthusiasm Delivers Results (if you’re agile)

One of the big challenges on any major software project is maintaining a high level of enthusiasm. When the team and the stakeholders are enthusiastic, ideas flow and things happen. Enthusiasm creates energy. One of the reasons agile software development is successful is its ability to maintain a high level of enthusiasm within the team. […]

Super Agile Teams Need Superstars

Every team needs good people. Great teams need superstars, that is, one or more top-notch contributors. Agile teams are no different. A team composed of average contributors will produce average work. If you’re lucky and the team collaborates really well, you may get above average results — unlikely, but possible and worth striving for. A […]

Agile and Big Companies Don’t Mix

The agile approach to software development has difficulty succeeding in big companies. This seems odd and almost counter intuitive but is simple to explain. Big companies establish lots of policies and procedures. They are constantly in search of the cookie-cutter approach to solving problems and building things. Big companies are focused on performance and scalability. […]

There Must Be an Agile Way

How many times have you heard someone say, “There must be a better way.” I’ve heard it often enough but rarely does any real change follow. There is surely resistance to change but the problem runs deeper. A “better way” is too general — too ambiguous. It is not actionable. What if the statement was […]

Crisis Management Is Disruptive to Agile Teams

Crisis management is a tough job. The biggest problem isn’t solving the technical problem — given a little time, you surely can solve it. The biggest problem is disrupting priorities. It plays out like this: A crisis situation develops. Priorities change to get people focused on the crisis. Staff is moved around to get more […]

Scrum’s Popularity Has Its Price

Agile software development has massively increased in popularity over the last decade. Scrum, in particular, has attracted enormous attention. That’s the good news. The downside shows itself when teams adopt agile methods and cut corners. They skimp on training and coaching. They leave out techniques they don’t like. They add elements from waterfall that are […]

Plan Ahead and Be More Agile

Agile development teams often struggle with reaching the goal of having every sprint deliver a customer-ready build. Not every software feature fits into a short sprint. Should you abandon such a feature or revert to waterfall for implementing it? At times, unforeseen issues arise and a feature can’t be completed as planned within the sprint. […]

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 […]