Mobile Technology

This blog is generally about mobile technology, concentrated on the Android/Chrome OS arena. However, there will be other topics delved into from time to time.

Thursday, February 25, 2016

When Software Development Goes Bad Part I

I've decided, after reading many articles on the subject, to talk about software development and how sometimes it can go really wrong. I recently left a company where the project I was working on had turned into a cargo cult. IE pseudo-agile. (Look up the meaning of cargo cult!) Everyone wanted to do Agile development, but no one could set aside their waterfall mentality to actually execute in an Agile way.

The first part in this series will concentrate on that very phenomenon. So many software development organizations (many I've worked for!) talk a big Agile game, but continue to execute in a traditional waterfall way. The term Water-Scrum-Fall has materialized in the industry because of that very phenomenon.

The problem is mostly at the management level. Management likes the sound of Agile. "I can change requirements on the fly!" "I will get buildable, potentially deliverable units of work on a regular basis!" "I will get less run up time to actually coding a solution!" These Agile platitudes at the management level are many and varied. However, the fault here of management is that they think there is nothing they have to change to support Agile.

For instance, management will push for, and hold to, clearly defined budget and timing milestones. Not something that is very Agile like. Take the platitude "I can change the requirements on the fly!" Whether you are using an Agile SDM or not, that will in itself make you reevaluate your budget and timing for the current deliverable. But management doesn't like that change (budget and timing changes that is) much.

Another way that management falls down in this regard is in understanding that in Agile people must have clearly defined roles. In other words, developers are developers. Developers cannot be infrastructure, operations, technical support, and/or sales support, etc, etc, etc. That will jeopardize the project because developers will get pulled away from their main role; coding. Management has to recognize the need to right-size the team. That means that a fully staffed infrastructure, support, sales support, operations, and even desktop support staff. Otherwise, your devs will get pulled for these roles and software development will grind to a halt.

Developers and other technical resources have their own platitudes (and even untrue statements) in support of Agile. "Agile means I don't have to document anything!" "Agile means that I don't have to meet with product resources." "Agile means I don't have to meet deadlines." These go on and on and on. Most of these are based in the fact that developer don't really understand what Agile is.

Developers have to understand that Agile means 1) clearly understanding the use case and/or requirements before starting to code. 2) properly documenting where appropriate 3) working with product resources directly on 1 and 2. 3) keeping management abreast of daily (maybe hourly) progress and/or slips related to timelines.

Agile will always fail for the lazy developer. Lazy devs are those that want to do their own thing, not be hassled, not talk to anyone else, not have to go to meetings, work odd hours, etc. The reason for this is that Agile, at all levels MUST have good, clear communication. They must be willing to connect directly with the necessary resources to get something completed, especially things that are critical and/or complicated.

Some of the best successes I've had with Agile projects was when I as the dev, or as the development manater getting the assigned dev, to work directly with a business analyst or product manager. One hour, half day, full day, or multiple day sessions with a common goal: to get a set of functionality completed. In a previous organization these were called coding slams, and they were highly effective as long as the objective was clear.

The issue for most organizations is that the problems highlighted above, at both the management and development levels, are all too common. If some, many, or all are present then in most cases the software development organizations that attempt Agile will fail. No one should kid themselves that he above problems can be ignored and a successful project can result. It just will not happen.

The foundation of this problem is the lack of understanding about the methodology itself. Think of a football team where the 11 players on offense aren't sure what play has been called. 99.95% of the time that situation will lead to utter and total failure on the offense's part. Not gaining yardage is the minimum, while turning the ball over completely is more likely.

So as this series of posts continues, we will explore different situations that I have personally witnessed that has led to the failure of a software development endeavor. Hopefully through my mistakes, and those I've witnessed by others, it will help you in your struggle to adopt, and correctly apply, Agile software development methodologies.