Archive of Software development Articles

What can you learn about your agile project from this Gannt chart? The one above looks out two years. It shows task dependencies and concurrencies. If you’re iteratively developing software, do you really expect to know what you’ll be doing two years from now, to know if you truly have a dependency? You may understand the dependencies with a two-month time horizon. But how much effort are you investing in creating a detailed, two-month Gannt chart? And how much value are you getting from it?

Why don’t more companies and teams use agile development techniques? We know some teams just aren’t aware of them - although that list is getting shorter every year. The benefits of iterative development over waterfall development are pretty well established. I don’t believe I’ve seen a study that shows that waterfall is more effective. Do people refuse to believe in the data? Or maybe they are unable to believe.

Your project is almost finished. Last week, it was almost finished. And you suspect that next week, it will still be almost finished. Why does this happen, and what can you do about it? In some ways, we’ve known about this problem for almost 2500 years But the solutions are still far from widespread.

Measuring the return on investments in design may be the hardest ROI calculation you can do. It certainly is one of the rarest. To measure ROI, you have to be able to determine what would happen without the investment, and what happens with the investment. The difference between them is what happened because of the investment.

Visualizing complex data can be very difficult. There are almost as many ways to visualize data as there are data to visualize. The Ralph Lengler and Martin J. Eppler at the Visual Literacy Organization collect many of them for us in a periodic table.

Almost a month ago, we published an article titled Broken Requirements Ecosystem. That article built on a discussion thread at Seilevel. Since that time, the original thread has grown, and a new one has been spawned at the Catalyze site.

In short, the question was asked on the Seilevel forum- why are specs sometimes ignored by developers, and four possible reasons were suggested.  We followed up with our view, and the discussion picked up again, this time at Catalyze.

1. Original discussion thread on Seilevel’s forum: Reasons Reqs Go Unread (Discussion from 19 Jun to 26 Jun )
2. Article at Tyner Blain: Broken Requirements Ecosystem (Written on 21 Jun, Discussion to 26 Jun)
3. Thread spawned on the Catalyze forum: Broken Requirements Ecosystem (Discussion from 23 Jun to 15 Jul)
Note - the dates above for each article/forum-post are as of right now. People have submitted 23 comments across the articles, showing a lot of good insight from many different perspectives. Developers, product managers, project managers, stakeholders - lots of great comments!

Even if you read our article before, go back and follow the discussions again - starting with Seilevel’s article, and progressing to ours, following up with the conversation at Catalyze.

Change is a reality of our businesses and our customer’s businesses. Without change, there would be no need to purchase new software. Yet many teams seem to both resist and embrace change at the same time. They embrace change because change leads to demand for new software products. And they resist change because it makes it harder to create new software products.

There are at least 7 ideals to keep in mind when designing a user interface. Shmula tells us about them.

You expect analysis to happen before design, and both to happen before implementation and testing. But how much should these activities be staggered? When a project is being run with monthly releases, it might seem logical to have each group working on a different release. For example, the test team working on the current release (3), the developers on the next release (4), and architects and analysts working on releases 5 and 6 respectively.

If your team is this staggered, you have a problem. It takes four months for a requirement to be released from the time the analyst has documented it.

When you plan a release, agile user stories, or classic use cases are the best sized pieces to use in the planning - from the perspective of your customers. Each user story can be further decomposed into a set of specifications, and those into development tasks. Development tasks are the right sized unit to manage your work breakdown structure - communicating the release schedule internally with your development team.