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.

Tuesday, August 4, 2015

When Software Development Goes Bad Part .9

(Title changed to fit in with the current series of posts on software development gone bad. Formerly titled: The Problem With Scrum: The Business Side)

Having spent the last 4 years of my career in an organization that wanted to practice Scrum, but behaved in a completely Waterfall way, I have some serious insight into why software development organizations fail at Agile development.

And it isn't the methodology's fault. It's the business' fault. (Note, this article uses business and product interchangeably.)

The business side of the company I just left so wanted to be agile. They spent time talking about Scrum. They wanted more releases, faster. But they couldn't behave in agile ways.

Here were the core issues:

  • No, "well-groomed" backlog
  • No prioritization ("it all has to get done")
  • No business involvement beyond a cursory "this is what we want" at the beginning
  • No test environment that mimicked production
  • No operations and infrastructure staff
  • Not enough resources to begin with
Let's dissect each of these and discuss why this was such a problem.

First, the backlog. Everyone agreed we needed a backlog. We, in fact, had a backlog. But it was holding tank for anything that didn't fit into the current "sprint". I quote sprint because even the idea of a sprint was destroyed by the business. 

Sprint is defined as: "a sprint is a set period of time during which specific work has to be completed and made ready for review."

However, the business didn't want a set period of time. One sprint we had ended up taking months because the Product Managers refused to close it until all of the features they wanted were delivered. (See, NOT Scrum.)

Without a "well-groomed" backlog there was no sprint planning meeting. The way it worked went something like this: PDMs and BAs picked a bunch of "items" (some defined, many not so much) and loaded them into the sprint. Negotiations began where the dev leads would review the items, and kick back any that were poorly defined (which was most). Then the PDMs badgered the BAs to provide better requirements, insisting that their loading of the sprint was doable in the sprint time-frame. This resulted in the first half to the sprint being consumed by providing proper requirements before dev could start. The PDMs then went away for the rest of the sprint and came back at the end to yell about what wasn't complete.

Seriously. The business would provide as little guidance as possible, and expected the end result they were anticipating. And anything not done, after verbally being dressed down, went to the top of the list for the next sprint. And so it went leading to.....

Lack of prioritization. When the dev group pushed back saying, "we can't deliver all of this, which of these are the highest priority?", the business came back with "all of it!" Not helpful. This usually meant that none of it got completed, at least to any real level. The biggest features languished for many sprints if the dev group insisted on sprint cadence. Or just long periods of time otherwise. 

One dev project, which was promised to be delivered in 2 months because the PDM, BAs, and devs were going to work closely together, was still not done 2 years later. Mainly, because the PDM and BAs got pulled away into other things. With no prioritization, dev was left to try and guess what was most important to get done. The success rate of that hovered around 10%. All of this was a direct result of......

The business not being fully engaged throughout development. Scrum CANNOT be successful, especially without a well-groomed backlog and prioritization, without PDM and BA engagement throughout the dev cycle. It's like throwing water against a wall to see what sticks. 

Much of this falls into a bigger category (and discussion) called Unrealistic Expectations. The business side loved the idea of Scrum regarding lighter requirement documentation, but they weren't willing to invest themselves into the rest of Scrum. Especially the part where they remained engaged throughout the dev cycle. One BA even was famous for insisting that dev only come to him once they had fully tested and certified that the solution was 100% bug free. -insert hysterical laughing here-

This thinking from the business side was pervasive, with the director of product once being quoted as saying: "when we make a software change we have to be 100% sure we don't break anything." You can't make this stuff up. And leads us into......

Test (dev and QA) environments not mimicking production. Now obviously this is impossible for every environment. But the point stands that there should be an environment for testing that is a replica of the production environment. Especially with decrees like "changes can't break anything." How does one certify that in environments that aren't like the environment that the user is going to be using? (It should be pointed out that this director was also the head of infrastructure, so you can see the hypocrisy in his decree.)

So as a dev group we not only had to guess what the business really wanted, but we had to deliver to their expectations, and be completely bug free, but had no test environment in which that could all be certified. I often said that when I perfected all of that I would make billions sharing the method with other software organizations.

Oh, and by the way, not only was this the expectation, but the devs weren't allowed to just be devs. Which takes us to....

The lack of operations and infrastructure staff. Of course, many people would say "in Scrum, you have DevOps, not mere devs!" However, anyone that says that doesn't understand DevOps. DevOps simply means that devs are capable of doing deployment and operations in the QA and dev environments. IT NEVER MEANS THAT DEVS SUPPORT THE PRODUCTION ENVIRONMENTS.

However, without operations and infrastructure resources, and without a true Operations Manager, then suddenly the devs were thrust into the roles of supporting the production operations and infrastructure. I frequently asked "why, as a dev, do I have access to the production environment?" The answer: "Because we need this done." 

Never mind the obvious security issues this raises, but remember the problem above? Too much to do and too little time (and resources). That was exasperated by the draw on the dev resources that this added responsibility caused. I was quoted multiple times, when myself and other devs were pulled into this support work, "to remember this at the end of the sprint when PDMS and Project Managers ask why more wasn't done." They didn't like to hear that.

I could go on but I think you are getting the point. It was no wonder that a project meant to be in market in 18 months was still not in market after 4 years. (See: Unrealistic Expectations) The compounding issues included:
  • Not enough resources across the organization (BAs, Devs, Ops and Infrastructure, Testers)
  • Poor processes that were exasperated by the lack of resources
  • Way too many hours logged by senior staff (I routinely worked 50-60 hours, over 80 during certain times. And that was short compared to our architect)
  • Lack of good leadership
The last item was really the main issue. All of this could have been fixed with strong leadership, reacting quickly to the issues. Not enough resources? Get more. Not the right resources? Get the right ones. Wrong processes in place? Mandate from above what the process was going to be. Rogue agents in the staff? Reign them in. Wrong attitude in the organization (like a director commenting that the prod environment, running a live customer's instance, was really an "experiment")? Reset the of organization to reality.

Unfortunately, no amount of hard work by very good staff could overcome these issues. The team assembled was topnotch. They were all hardworking individuals willing to do whatever it took to be successful. But their efforts were ultimately doomed because the business' behavior was not conducive to successful delivery. In the end the project was doomed to failure.

The last point is:the business, and product team, reacted to all of this by insisting everything go faster. Their failure to recognize their own poor behavior meant that the root cause of the issue was never going to be corrected. They didn't realize that going faster meant the path to final solution was actually slower. Sometimes the prudent approach is to slow down so that you can do things the right way.

All of this resulted in no chance of successful Agile software development.

(The author is currently in the process of writing a book on his experiences that should be out in the next few months. More details to come.)

Saturday, June 11, 2011

Chrome: Greatest Browser. Greatest OS?

A couple of years ago I began to use the Google Chrome web browser. I had been using Firefox up until then but I quickly liked the speed and the simplicity of Chrome.

I really didn't think much more about it. And even after Google announced that they were developing their own Chromium operating system I continued to use Chrome the browser.

A few months ago I upgraded my version of Chrome and discovered that there was now a Web Store where you could download extensions, plug-ins, and applications for Chrome. I soon discovered that you could sign up for the Chromebook pilot program. A Google initiative to give away several thousands Chrome-powered laptops.

I found the Chrome OS Forums where those that had received the Google Chromebooks, the CR-48, and those that hoped to, could commiserate. I even began playing around with various Chrome builds on thumbdrives to boot laptops into Chrome.

The results of those trials weren't great due to hardware incompatibilities. So I was excited to learn that Acer and Samsung will both be releasing Chromebooks this month. I believe that Chrome, and its cloud-based computing, is the future.

In the meantime I continue to use the Chrome browser. The extensions and applications make it an invaluable resource for using the web. In a later post I will detail some of those extensions and apps that are the most useful. Until then all I can tell you is to install and start using Chrome. The best web browser there is.

Friday, April 1, 2011

Amazon's Cloud Drive

I have become more and more of a fan of cloud computing as more devices and OS's and other technologies embrace it. One thing that the cloud computing crowd has been clamoring for is a way to not only store your MP3s in the cloud, but to stream them. Google and Apple have been working towards that very thing for a while now.

Early this week Amazon announced it's Cloud Drive. A cloud storage service that includes the ability to stream to any number of devices from Cloud Drive's cloud storage. Some features include:

  • Web player for streaming MP3s, and an Android player too
  • 5 GB of free storage
  • 20 GB of free storage for 1 year when you buy a MP3 album from Amazon
  • Amazon purchased MP3s do not count against your storage total
  • Graduated rates for additional storage, all fairly reasonable
One complaint I have is that uploading of MP3s isn't the easiest. You have to manually create an artist folder (say Aerosmith), and then a folder for each album under Aerosmith (Toys In The Attic for instance). They should allow you to select a folder and then create the folder structure for you. However, one cool feature is that Amazon uses album info, once it recognizes the album, to arrange the tracks in the album order.

It also will convert any WMAs to MP3s IF Amazon sells that album in MP3 format. If not then you are forced to upload in MP3 format since the player appears to be incompatible with WMAs.

Still in its infancy, I am sure everything will get better over time.

Wednesday, March 2, 2011

Welcome To My New Technology Blog

It dawned on me that my other 2 blogs were pretty specific. There is my main blog which is dedicated to politics and religion primarily, and then there is my Healthy Eating For Real People blog which I use to give health and dietary tips.

So this is the newest blog. That way when I want to wax philosophical on things technology related, I have a place to do that. Most of what will be posted here will be related to Google's Android (for smartphones and tablets) and ChromeOS (for net books). I will delve into other technology from time to time, but those two subjects will be the primary topics.

To begin, please visit my two favorite forums!
Enjoy!