Tag Archives: continuous integration

Debunking Testing Myths

Joel Tosi of VersionOne wrote a good article on testing myths.

He raises a good example for the age old excuse that “I don’t have time to write unit tests”.   The example provided was some code that processed a data feed/push with transformation.  In this type of scenario, it can take a substantial amount of time to complete a full test run.  If the job takes an hour or so to run, that time can add up as bugs are found and the code is troubleshooted and retested.  It would be far preferable to invest much of this time up front in creating and running automated unit tests which can simulate troublesome data issues and problems in a matter of seconds or minutes, in a more controlled and granular manner (than processing a full data feed, or even smaller simulated data feeds).

The fact that these unit tests can be fully automated in a Continuous Integration build as either unit tests or more robust integration tests, is even better.  This way, the unit test is generated once, and will be run every time a build is done (probably at least once a day, if not multiple times per day).

If developers are not spending time writing automated unit tests, it very well may cost more time through the course of the project.

Agile and Scrum from the Trenches – Part 2 – Selling Agile

I will be one of the first people to admit that I have a limited exposure to agile methodologies, including Scrum, as I feel I have so much more to learn and experience.  Since we started implementing Scrum a few years ago, and some other agile practices such as Continuous Integration and Test Driven Development, I have become more and more passionate around “agile”.  It just seems to make sense. Trust me, I am nowhere near the agile implementation mastery that I would like to be.  There is still much to be learned…

Team First

It can be disheartening when I see posts online from Scrum teams that absolutely hated the experience and want to go back to Waterfall.  How can that be?  Agreed, Scrum can be a difficult pill to swallow at first when one is very used to the ebb and flow of the waterfall, but I feel the core principles of the Agile Manifesto and the core principles of Scrum should make sense and eventually impassion the team. So why does this not happen?

I believe one of the main reasons this might be happening is because some of us are not doing a good job as Scrum Masters.  We need to do a better job selling agile to the teams (and implementing, but that is for another post).  Selling does not mean shoving down their throats, blinding following the Scrum rules.  It means put yourself in their shoes and see the change from their eyes.  More meetings?  Possibly.  More transparency?  Of course.  More productivity?  Let’s hope so.  Less risk? Definitely.  These are not bad things for the team, but they may not see it that way initially.  It could take months, or longer, for them to “get it”.  Unfortunately, some of them may never “get it”, or may never want to.

Once we understand the changes that are occurring, not just in process, but also in culture, we can do a better job communicating to the team.  Each team member may see things differently, and we should acknowledge that fact and see if we can find a common avenue to help address issues or concerns across the team.

These types of discussions and transition plans could be well beyond the skill level and experience of a new Scrum Master, so in that case a professional agile or Scrum coach may be necessary.

We must not forget that a large part of Scrum and agile is team empowerment, and valuing people over process.  If the team is resisting, then the process probably isn’t working, and may need adjustment.  Use common sense.  I strongly feel that if the Scrum Master protects and empowers the team to the best of their ability, success in a better process in the end should be inevitable.  It may not be Scrum by-the-book, but I think that is perfectly fine.

Selling Leadership

If you are doing Scrum, or another agile process/methodology, hopefully leadership has bought in and is fully committed to going agile.  Perhaps they have not.  Even if they have stated that they are committed, they may not fully understand what it means to go agile.  Helping to form cross-functional empowered teams, providing dedicated Product Owners, and embracing and leading the agile cultural change, are all things that leadership should be doing.

If leadership does not appear to be fully on board, perhaps the benefits of agile are not clear?  Perhaps we need to do a better job selling agile to leadership.  Agile best practices are in their best interest as well.  Motivated, well-equipped, cross-functional teams working on the highest value items to the business at all times?  Reduce waste in process; increase productivity; increase transparency and thus reduce delivery risk.  Who would not want that?  Continuous Integration is an easy sale, in my opinion.  There are no real negatives that could possibly come close to outweighing the automation and reduced waste and risk that would ensue.  Test Driven Development is possibly more difficult to sell, but I am convinced it can be done with supporting arguments and information.

Everything can, and should, be started in moderation.  That also helps reduce the risk of spending time on processes or procedures that may ultimately fail.  It also reduces the risk that team members will be caught up focusing on areas that are not providing the highest value to the business.

With leadership support, agile teams can do so much more.  It is our job to help leadership see the benefits of going agile, and to try to obtain that support.

Selling the Client

I think much of the same arguments above apply to communicating the benefits of agile to clients or our users.  Shorter feedback loops, more transparency, adaptation to change; I see all of these as positives from a client perspective.  There is definitely a lot of adjustment that will probably have to be made (doing small iterations means delivering smaller chucks of features to the client at a time, which is possibly quite different than what they are used to), but there is a reason for this (see adaption to change and shorter feedback loops).

So if a Scrum or agile transition is not going as well as planned, or preparations are being made for a future transition, keep in mind that we must all be good stewards of agile.  We must be able to sell agile, to a certain extent.

After that, it should continue to sell itself.

The Importance of Continuous Integration for Software Development

In my opinion, any organization that produces software, regardless if the software is to be sold or used internally, should be using Continuous Integration (CI) as a best practice to help improve the quality of their software, increase productivity and reduce risk.

This post does not aim to re-define CI, as there are plenty of other sources online that can give you the run-down, but it does aim to share my thoughts as to why it is so important.  Let me summarize CI at a high-level, and then break down the positive impact as I see it.

What Is Continuous Integration?

Good question, and an excellent place to start.  Continuous Integration, or “CI” for short, in the simplest form is a process which fully automates the compilation of your projects latest source code from source control.  There are some very important points in that sentence, so let me highlight them:

  • fully automated
  • compilation of latest source code
  • from source control

These points are very important, but often seem to be missed at some point or another.  If developers are running build scripts manually (either from their machines, or on a server somewhere), that doesn’t qualify as CI.  If they are still doing builds manually (not even running scripts, ouch) from their machines, then keep reading…. Read more »

%d bloggers like this: