How can I overcome a badly structured software development model?

Question

I joined the company currently I am working on as a fresher. Due to the limited number of skilled people in GIS software development, and since I was among one of them I was directly recruited as a Project Manager.

I was quite conversant with Java and GIS, and I have done self motivated research on location based services, but not with project management and structured software development. It was one year after my graduation as a Geology special and during the previous year I was working as an academic in a University.

Thanks to the interest I was having at work, an opportunity shown up, and eventually I was made responsible for the Business Intelligence department of the company as well. The company believed in me. I myself studied data warehousing and BI concepts and was successful in combining GIS with BI as well.

Also I am currently working with two developers on our BI tool in C# WPF, where I also play the role of a developer at times (which I like).

I tried extremely hard to adopt good software development methodologies with agile project management, but it was not very successful. Also, though I believe in well designed code as far as a product is concerned, due to the lack of technical knowledge my CEO has (who is directly above me), I normally do not get the amount of time needed to do it. The time taken is greatly enhanced by the lack of expertise we have in the specific coding language as a whole too (for instance WPF opposed to Java). Also there is no version controlling system in place as well.

I am extremely fed up with the way things are going as it is not structured and I find most of my time thinking than working as to how to get things structured. I hope you guys with good professional experience will be able to help me overcome this situation.

Answer 1

We had a similar problem (without the technical details, of course) in the company I work about two years ago.

You just need to do it one step at a time. Don't try to adopt the agile software development in a rush. There's a lot of stuff to learn and apply. Don't let the lack of expertise to bring you down either.

Build slowly (but as fast as you can :P), steadily and surely.

I would recommend the next steps (to do this, you might switch from management to development for a while, but that should be fine)

1. Learn a good version control system, and learn it well. Personally I would recommend git or mercurial. There is a lot of documentation on both.
2. Build a solid core on practices and patterns. Read books, read blogs, watch screencasts with the team members. This will give a new air to the development.
3. Learn TDD/BDD and try to apply it in the new code, as well as in the old code that you might touch when doing a new feature.
4. Do pair programming. Two heads think better than one, and also 4 eyes are better than 2 :).
5. Find about the latest and most common used tools in the community of the language you are currently developing. Learn about them and try to include some of them in the project. See how these were built and learn.
6. Use scrum. Iterations, stories, story points, impediments are all concepts you should get familiar with. For me, scrum has proven to be the best workflow for software development and management. Apply it and learn from each day experience.
7. Teach by example. Most of beginner developers are eager to learn new stuff, but also some of them are very lazy. Anyways, show them the new stuff you've been learning and applying and hopefully that will tickle their brains.

Also, if possible, hire a consultant just so that he can check out the process and give better advice.

Don't get lazy or discouraged. Just learn from your mistakes and try different approaches. This is just the beginning!

Edit:

Here are some of the links and books that I've been reading/using lately...

Learning git: Pro Git

These are some of the blogs that I would recommend (most of them are .NET oriented):

• Java Blogs
• Karl Seguin's Blog and his Foundations of Programming series.
• CodeBetter.com
• Code Thinked
• Los Techies
• Clean Coder
• And also this link to a stack overflow question.

For books, you can see Buiding A Solid Programming Core list on amazon. I would also recommend these:

• Clean Code
• Agile Software Development, Principles, Patterns and Practices
• Almost any book from The Pragmatic Bookshelf

Answer 2

As the manager, it's your job to get the time required to complete a project properly. When approaching the CEO, make sure that you have all figures backing you up and reasons why estimates are as lengthy as they are. It is your responsibility as a manager to make the CEO understand why it takes n hours/days/weeks to complete a given task. This can sometimes be difficult, but I haven't met a CEO who wants his company to fail yet and I bet if you put it in those kind of terms (if all else fails), he may change his tune.

If the CEO is unwilling to grant you the time needed to complete tasks, then IMHO, be ready to either move on to another job or get prepared for continual death marches. As a last resort, explain to the CEO the burnout that will no doubt come from unrealistic expectations.

Having said that, you also need to make sure that your developers are providing you with accurate estimates (tremendously difficult, nearly impossible without proper technical designs done, which should also be in there somewhere).

Agile isn't good in all development domains. Works for some project types, fails miserably in others. You might have to try a few different methodologies before you find one that works well.

Get version control set up. Really, it takes 5-10 minutes to get Git set up, a few more minutes to get the basic operations down and a day or two of reading to get the more advanced concepts down.

Answer 3

Hmm, not sure if I met you at an Agile/XP event in Toronto - this sounds familiar

It sounds like you need a break. Take a long weekend, get drunk if you like, and forget about work for a few days.

Ease up on yourself. Self-teaching is good, and just because a methodology doesn't work with the personalities involved, doesn't mean you're doing it wrong, and it isn't a personal failure.

There is a (beta) pm.stackexchange.com site, targeted at Project Management, you may well get some useful advice/support there - but by all means, keep the question here too.

Moving on to the techie stuff:

there is no version controlling system in place

Put one in as your top priority. I prefer centralised systems like SVN (Subversion) over git/mercurial, because a stolen laptop won't have as much history locally. Especially important if anything super-secret (like passwords and ssh-keys) were checked in by mistake. But, it's a matter of taste. Nothing wastes more time than bugs from 'manual version control' - e.g. putting code back to what you think it was.

Good luck

Answer 4

It sounds like you have several problems: 1. Communicating with non-technical senior management so that they will support your improvement program; and 2. Driving the improvement program for success.

The hardest part of number 1 is simply remembering that senior management often won't be interested in the details of what you're working on. (If they were, they'd be doing it themselves rather than handing it to you!) It sounds like the big hurdle is 'why' and you may want to look at CMM 1.1 for a description of the business benefits of a process improvement program. Whether you use CMM or something else to actually improve your process won't matter to this discussion, only the data from the Carnegie-Mellon study which shows more mature organizations deliver projects faster with less variation in delivery time.

There are a lot of roads to success at process improvement, all of them tend to be very long. Experience with CMM shows it can take 8 to 10 years to move from level 1 to 5. Experience with 6 sigma shows that each iteration gives some improvement but it needs multiple iterations to remove most of the potential problems and, by the time you get to 6 sigmas of quality, work is being done completely differently without having to take the risk of trying to replace everything at once.

If there's a quality improvement approach commonly used in your industry, take the time to try to see how it applies to software and use it so that the rest of the company is hearing about something they are already familiar with and supportive about. We can talk for hours about specific software tools and practices but non-software CEOs will tune it out quickly. Talk about the standard practices of the industry and he'll perk up because you're talking his language. Talk about software in the common terms of the industry and he'll start asking relevant questions to better understand your challenges and your plans to make the companies' results better.

You won't win every ask for support this way, you'll probably get a lot fewer blank looks and more wins though!

Good luck sir!

Answer 5

All of your suggestions are indeed sensible and are the way to go in many companies. But they aren't universal, especially with teams which aren't that experienced. The reason they aren't is that they require some amount of work to setup and maintain - even version control - which many would assume is table stakes for any software project. Because they require some work, they need to provide some benefit too. And it might be the case that in your particular situation they don't! Or at least the people tasked with making the decisions don't see the benefit!

As others have pointed out you need to:

• Try adopting the practices in turn. Don't try all of them at once cause it will overwhelm people.
• You need to figure out a good order for this. I'd start with version control. Go then with easier ones too. Once people start trusting that you make good decisions and they see the benefits they will be more likely to adopt riskier changes.
• Build a solid case for why something needs to be implemented. With 2-3 devs who are constantly making progress visible to end users it's hard to justify adopting a more elaborate development methodology for example. You'll be seen as process focused rather than outcome focused.
• Have in mind who you need to convince. The devs? The CEO?