What good practice strategies and technologies can my company adopt that would save them potentially hundreds of thousands of dollars?

Question

Basically we have rows upon rows of programmers that do mundane tasks every day. This would involve writing code that is not very effective, is not unit tested, and often integrates poorly with the application. Not to mention that there is no accountability in terms of hours spent versus hours worked. I am not trying to get people fired or make life miserable for anyone. All I want is a stream line agile (word is banned in our company) process.Would this involve setting up something like a Hudson integration server? Version control that is tied to project management software?

Answer 1

• Add testing
• Build a high-quality culture
• Encourage experimentation to build quality
• Encourage exploring other languages
• Focus on teamwork and leading the programmers to betterness.

Answer 2

I would start building teams, introducing continuous integration servers and distributed version control.

Your company management apparently does not believe in agile, chances are the believe in control(tm) (or at least the illusion of control). Chances are your management likes hierarchy, because nothing gives better illusion of control than hierarchies.

In the teams a lead developer takes the role of Integration Manager, this has a nice ring to it. You can also use 'Integration Coordinator' if you have insecure management. His job is actually just developping, yelling when the CI-server is blinking red and (this is important) send a weekly printout of the sonar report from the CI-server and some plan vs actuals to management. They'll feel in control and spend a full week trying to get through all the numbers.

Another task is to meet with the other Integration Coordinators to discuss integration of the different teams work. Here is where the distributed VCS comes in because it allows flexible, process driven change flows.

(make sure your management does not read the rest)

Your management now see a classical hierarchy, are informed and hopefully see enough progress to leave devs alone.

The devs have now an environment where agile practices can be deployed. You already have a prototype scrum-of-scrums structure to start from.

It is important to build confidence with your management. It will not last without management support in the long run. If your management does not want to take a leap of faith you can convince them by giving them what they want, but on your terms. It is relatively easy to influence management by being proactive and 1 step in front. If demonstrable results can be shown, most managers will find something better to do than meddle with development.

Now there are managers which are so insecure they need to micromanage everything and make sure everyone is even more insecure.

Answer 3

Some ideas:

• Yes, Hudson and co are good. Continuous builds run together with tests are very, very helpful for a variety of reasons.
• Git or other distributed tools are good (after you learn them). It allows people and groups to be far more independent in experimentation while they develop something.
• Clean-cut building tools are good. Maven, sbt, buildr, cmake - anything. You should be able to send the projects around to other people and they can immediately build & execute it with one command or two.
• Sane documentation practices: Use lax internal documentation standards (customers of course still need the full course, but internally you don't). However, you need some "most encouraged" place / utility to share documentation in case your teams need it. Jira(and co.), a wiki, trac... whatever you like. There just needs to be one or two places where people can go and look for documentation on things - if its not there, its probably nowhere. Fast failover.
• Maybe look into functional programming or adapt the "as functional as possible" paradigm. If everything is small, manageable, and predictable, you'll have a real reduction in complexity that leads to error and poor code reuse.

By the way, "tool-assisted" accountability "in the workflow" is a bad, bad idea. It stifles innovation and leads to them wasting much (and I mean much) time on producing signs that they worked. Bloated documentation, inflated commit logs, ... those kind of things. Minimal and not really electronically rigidly enforced accountability is much better. Your workers already know what they're hired to do, and you can for the most part limit yourself to controlling the quality of intermediate and end results of their work.

If you want to do something about overly lax work practices, sometimes walk to people's offices with an appointment and maybe rarely without appointment to discuss their problems and current work and ideas. Maybe bring some food and other treats occasionally... Anything that credibly shows "you" or any of the managers or staff actually care about work and staff will make the remainder of the team care more as well - and that's what helps the most when dealing with skilled workers.

Answer 4

This is the perfect question for a plug of the Seven Principles of Lean Software Development:

1. Eliminate Waste
   
   • Provide market and technical leadership - your company can be successful by producing innovative and technologically advanced products but you must understand what your customers value and you know what technology you're using can deliver
   • Create nothing but value - you have to be careful with all the processes you follow i.e. be sure that all of them are required and they are focused on creating value
   • Write less code - the more code you have the more tests you need thus it requires more work and if you're writing tests for features that are not needed you are simply wasting time
2. Create Knowledge
   • Create design-build teams - leader of the development team has to listen to his/her members and ask smart questions encouraging them to look for the answers and to get back with encountered problems or invented solutions as soon as possible
   • Maintain a culture of constant improvement - create environment in which people will be constantly improving what they are working on - they should know that they are not and should not be perfect - they always have a field to improve and they should do it
   • Teach problem-solving methods - development team should behave like small research institute, they should establish hypotheses and conduct many rapid experiments in order to verify them
3. Build Quality In
   • Synchronize - in order to achieve high quality in your software you should start worrying about it before you write single line of working code - don't wait with synchronization because it will hurt
   • Automate - automate testing, building, installations, anything that is routine, but do it smartly, do it in a way people can improve the process and change anything they want without worrying that after the change is done the software will stop working
   • Refactor - eliminate code duplication to ZERO - every time it shows up refactor the code, the tests, and the documentation to minimize the complexity
4. Defer Commitment
   • Schedule Irreversible Decisions at the Last Responsible Moment - you should know where you want to go but you don't know the road very well, you will be discovering it day after day - the most important thing is to keep the right direction
   • Break Dependencies - components should be coupled as loosely as possible to enable implementation in any order
   • Maintain Options - develop multiple solutions for all critical decisions and see which one works best
5. Optimize the Whole
   • Focus on the Entire Value Stream - focus on winning the whole race which is the software - don't optimize local inefficiencies, see the whole and optimize the whole organization
   • Deliver a Complete Product - teams need to have great leaders as well as great engineers, sales, marketing specialists, secretaries, etc. - they together can deliver great final products to their customers
6. Deliver Fast
   • Work in small batches - reduce projects size, shorten release cycles, stabilize work environment (listen to what your velocity tells you), repeat what's good and eradicate practices that creates obstacles
   • Limit work to capacity - limit tasks queue to minimum (one or two iterations ahead is enough), don't be afraid of removing items from the queue - reject any work until you have an empty slot in your queue
   • Focus on cycle time, not utilization - put in your queue small tasks that cannot clog the process for a long time - reduce cycle time and have fewer things to process in your queue
7. Respect People
   • Train team leaders/supervisors - give team leaders the training, the guidance and some free space to implement lean thinking in their environment
   • Move responsibility and decision making to the lowest possible level - let your people think and decide on their own - they know better how to implement difficult algorithms and apply state-of-the-art software frameworks
   • Foster pride in workmanship - encourage passionate involvement of your team members to what and how they do

My point is that you can certainly adopt engineering practices like automated testing, refactoring, coding standards, pair programming, code reviews, continuous integration, etc. They will definitely not hurt. But they should be part of a bigger plan that involves organizational practices and, ultimately, the way your company drives the business. Agile is actually a business oriented thing, engineering practices and tools are just a small part of the story and won't be enough by themselves to save hundreds of thousands of dollars.

In short, whatever you'll use, if your current (probably sequential and defined) process produces poor results, not changing the process won't drastically change the results.

I thus believe that enabling "inspect and adapt" cycles and feedback loops would be the most important thing to do.

But change usually involves the management.

See also

• Lean Software Development
• Scrum (a simple inspect and adapt framework)
• Extreme Programming

Answer 5

In my experience, it is difficult to be the single driver of change. And it is much worse if you do not have the support of management. If you don't have management support, you need a dual pronged attack: a) to recruit developers to strive to be better, and b) to demonstrate to management how your improvements are affecting the bottom line. If you feel that you do have management support (or can get it), then you still need the support of the people on your team(s).

You should introduce tools (as others have suggested), such as Hudson and unit testing frameworks that make it easier to do the right thing. But introducing tools that only you use gets frustrating after a while. You also need to introduce the ideas to the other developers in the organization and hope that they have the desire to learn something new and apply to make their (work) life better.

• Start a weekly brown bag to review tools, new languages, problem solving approaches, and review papers. Basically anything to introduce new ideas and get people thinking beyond the scope of their next bug fix. (This will also tell you who is going to be receptive to better practices.)

• Show off your workflow. Pair programming probably has a bad name in your organization, but getting someone to occasionally "help me with this" (even if you don't really need the help) gives you an opportunity to show them something new. This can happen the other way around too. When you see someone struggling with some manual task that could be automated, offer to teach them a new trick. (Anecdotally, I think it's more likely to be have an impact when they are the ones asking, "Nice. How did you do that so easily?")

• Demonstrate pride in your own work and try to encourage the same from your team. Keep asking your team and peers questions like "how would you want this to work if you were using it?" and "how can we make this more maintainable / easier to extend?"

• Hire good developers. Get involved in the hiring process and make sure new hires demonstrate their ability to code and a willingness to learn.

Finally, it may seem rudimentary compared to the Agile practices (which I do not hesitate to recommend), but I think the Joel Test is still relevant (do I get bonus points for the mention?). I don't know how highly your organization ranks, but there are a number of good suggestions about things that you can do whether you're a single developer or part of management.