How to Save Time by Automating your Development Process

In some of my other posts I have talked about ways to speed up the process of delivering software.  Below is a bullet point list of items I have been involved in over the past couple of years.  From start to finish these steps have  improved the quality of our development teams and our products. 

 

Source Control – Team Foundation Server  (TFS)

I hear a lot of people downing TFS. However I have had nothing but good experiences using it.  Setting it up proved a pain (at least 2008) but with 2010 it has become much easier.  It integrates well with Visual Studio 2010 which is my main IDE thus is the perfect choice. 

Continuous Integration (CI)

Continuous Integration is the process of automating the build process from your source repository.  There are a few good products on the market but my favorite is TeamCity by JetBrains.  It is written in Java and seems to be the most flexible across many different languages and platforms.  The best part is it is free for the Professional edition which for my personal development environment is great.  There are a number of different build configurations and agents that are available.  It is the “manager” of our whole build process. 

CI includes

• Building Source Code
• Running Unit Tests
• Running Integration Tests
• Building the MSI installers
• Starting the data generation processes
• Other miscellaneous tasks

Installations

There are many ways to package software for installation.  Some of the more common vendors such as InstallShield and Wise allow for automating the building of the installer packages (MSI’s) so this can be incorporated with the CI server above.  Plus with the MSI’s you can script the installations with simple windows batch files. 

Testing Environments (QA)

In one of my previous posts I wrote about automating VMware workstation.  I have been doing this for over two years now and it works flawlessly. 

http://tsells.wordpress.com/2009/09/20/how-to-save-time-automating-vmware-workstation/

As a developer – I still automate and install the build locally so I can be more effective when working with our Quality Assurance Team to assess any anomalies that may occur between a development and production (installed) environment. 

Test Data

Test data is critical for developers and testers to be able to confirm the product is working as expected.  There are many different ways of developing this.  I personally have done this with SQL Scripts, 3rd party utilities, and now I am using a tool I built custom that builds databases for all supported database platforms. 

Summary of Process

1. Developer checks in code throughout the day
2. Source Code is downloaded and rebuilt continuously
3. Unit / Integration Tests Executed
4. Daily Build Runs (full build to use for the steps below)
5. MSI installs build
6. MSI’s deployed to Server
7. Data is generated
8. QA Testing environments are reset

Once the developer checks the code in – there are NO man hours involved to setup the environments to be ready for testing.  When this was a manual process, it took at least 6 – 8 hours for the process to be completed by no less than 4 people. 

WPF Model-View-ViewModel (M-V-VM) Example

When starting out with WPF and the M-V-VM pattern I was looking for a simple example of this pattern.  Most of the things I found were full of items that complimented the pattern but didn’t show just the pattern itself.  I decided to walk through a simple example and will detail it below.

You can download the source code from here.

Basic M-V-VM OverView

Layer	Items
Model	Business Objects, Business Logic
View Model	UI Logic, Data / Services Interaction
View	UI elements (Styling, Data Binding, etc)

The Model

The model in the MVVM pattern will be the business object. For this example my model is a picture object.  This object contains some basic properties a picture would have such as:

• Name
• File Path
• Height
• Width

It also contains a validation method to validate the Picture object.  This was placed here for example only (notice there is no logic in the method).  Any business logic for the model should be contained within this class or a model helper class.

namespace MVVMDemoApplication.Models
{
    public class Picture : BaseModel
    {
        private string _pictureName;
        private string _picturePath;
        private int _height;
        private int _width;

        public Picture()
        {
            Width = 300;
            Height = 200;
        }
        /// <summary>
        /// Name of Picture
        /// </summary>
        public string PictureName
        {
            get { return _pictureName; }
            set
            {
                if (_pictureName != value)
                {
                    _pictureName = value;
                    NotifyPropertChanged("PictureName");
                }
            }
        }
        /// <summary>
        /// Picture path
        /// </summary>
        public string PicturePath
        {
            get { return _picturePath; }
            set
            {
                if (_picturePath != value)
                {
                    _picturePath = value;
                    NotifyPropertChanged("PicturePath");
                }
            }
        }
        /// <summary>
        /// Height of Picture
        /// </summary>
        public int Height
        {
            get { return _height; }
            set
            {
                if (_height != value)
                {
                    _height = value;
                    NotifyPropertChanged("Height");
                }
            }
        }
        /// <summary>
        /// Width of Picture
        /// </summary>
        public int Width
        {
            get { return _width; }
            set
            {
                if (_width != value)
                {
                    _width = value;
                    NotifyPropertChanged("Width");
                }
            }
        }
        /// <summary>
        /// Determine if Picture is Valid
        /// This is a model based logic validation and does not belong in the viewmodel
        /// </summary>
        /// <returns></returns>
        public bool IsPictureValid()
        {
            bool isValid = true;
            // Add Code here to validate picture - whatever you want
            return isValid;
        }
    }
}

Base Model Class

This class is used to provide functionality to each model class without the need to replicate code.  This works perfectly when implementing the INotifyPropertyChanged interface for Data Bound Properties in WPF and Silverlight.

namespace MVVMDemoApplication.Models
{
    public class BaseModel : INotifyPropertyChanged
    {
        public event PropertyChangedEventHandler PropertyChanged;

        /// <summary>
        /// Notify of Property Changed event
        /// </summary>
        /// <param name="propertyName"></param>
        public void NotifyPropertChanged(string propertyName)
        {
            if (PropertyChanged != null)
            {
                PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
            }
        }
    }
}

The View Model

The view model contains the UI logic for the view.  Any logic, method calls, parameters, etc should always be placed in the View Model.  This logic should not be placed in the view.

The view model contains a collection of picture objects.  These objects have to be populated from a data source.  After many hours of research I have to agree with some of the experts (a.k.a Josh Smith) and say that while the data operations belong in the View Model layer they should be extracted from the view model in a separate set of classes.  This will simplify the view models and allow the reuse of the data access logic across multiple view models.  This will be more apparent and useful when using Silverlight with WCF / RIA Services.

Properties

• Error Message – displayed when error occurs
• Pictures – observable collection of Picture Objects (Model).  It is better to use an observable collection when items maybe added / removed from the collection so the data binding recognizes the changes automatically.  This does not occur with list objects.

Methods

• MakePictureBigger – enlarge picture if valid (notice the call to the IsPictureValid object on the model itself)
• MakePictureSmaller – make picture smaller (notice the validation logic – since this is UI logic and not business logic it belongs in this class)
• CheckIfPictureSelected – ensure that an item is selected from the list box – if not modify the error message on the view model.
• LoadPictures – call to the services class to retrieve the data.  In this case it is a list of image files.  This can be anything from a WCF services call to a call out to a custom Data Access Layer (DAL).
• BuildPictureCollection – build the collection of picture objects – this is here versus the data services layer to reduce coupling.
• BuildPictureObject – load values on the object based on the file path given

namespace MVVMDemoApplication.ViewModels
{
    public class PictureListBoxViewModel : BaseViewModel
    {

        ObservableCollection<Picture> _pictures;
        PictureDataServices _services;
        string _pictureDirectory;
        string _errorMessage;

        /// <summary>
        /// Selected Picture in ListBox
        /// </summary>
        public Picture SelectedPicture { get; set; }

        /// <summary>
        /// Error Message
        /// </summary>
        public string ErrorMessage
        {
            get { return _errorMessage; }
            set
            {
                if (_errorMessage != value)
                {
                    _errorMessage = value;
                    NotifyPropertChanged("ErrorMessage");
                }
            }

        }

        /// <summary>
        /// Observable Collection of Pictures
        /// Uses INotifyPropertyChange when list changes
        /// </summary>
        public ObservableCollection<Picture> Pictures
        {
            get { return _pictures; }
            set
            {
                if (_pictures != value)
                {
                    _pictures = value;
                    NotifyPropertChanged("Pictures");
                }
            }

        }

        /// <summary>
        /// Constructor
        /// </summary>        
        public PictureListBoxViewModel()
        {
            // Initialize data services class for later use
            // It is best to keep this isolated from the view model
            _services = new PictureDataServices();
            // Set Picture Directory
            _pictureDirectory = Directory.GetCurrentDirectory() + "\\Images";
            // Initialize here so we don't forget to later and end up with a null reference exception
            Pictures = new ObservableCollection<Picture>();
            LoadPictures();
        }

        /// <summary>
        /// Overload to allow different images directory
        /// Maybe one view has an option to select a directory
        /// </summary>
        /// <param name="imagespath"></param>
        public PictureListBoxViewModel(string imagespath)
        {
            // Initialize data services class for later use
            // It is best to keep this isolated from the view model
            _services = new PictureDataServices();
            // Set Picture Directory
            _pictureDirectory = imagespath;
            // Initialize here so we don't forget to later and end up with a null reference exception
            Pictures = new ObservableCollection<Picture>();
            LoadPictures();
        }

        /// <summary>
        /// Make the selected picture bigger
        /// </summary>
        public void MakePictureBigger()
        {
            //Perform Error Check
            if (!CheckifPictureIsSelected())
                return;
            Picture picture = SelectedPicture;
            // Here is where we call business logic on the picture object itself
            // The validation method on the object determines if object is valid
            // This logic has nothing to do with the view or the view model so it
            // Is placed on the model
            if (picture.IsPictureValid())
            {
                picture.Height = picture.Height + 50;
                picture.Width = picture.Width + 50;
            }
        }

        /// <summary>
        /// Make the selected picture Smaller
        /// </summary>
        public void MakePictureSmaller()
        {
            //Perform Error Check
            if (!CheckifPictureIsSelected())
                return;
            Picture picture = SelectedPicture;
            // Verify we don't make the picture to small.  Since this is a UI
            // check we place in the View Model versus the model.  The model
            // does not care how big the picture is displayed
            if (picture.Height > 60)
            {
                picture.Height = picture.Height - 50;
                picture.Width = picture.Width - 50;
            }
        }

        /// <summary>
        /// Check if user selected item
        /// </summary>
        /// <returns></returns>
        private bool CheckifPictureIsSelected()
        {
            if (SelectedPicture == null)
            {
                ErrorMessage = "Please select a picture";
                return false;
            }
            else
            {
                ErrorMessage = string.Empty;
                return true;
            }
        }

        /// <summary>
        /// Load Pictures from FileSystem into Collection
        /// </summary>
        private void LoadPictures()
        {
            // Load picture collection from services (could be WCF or other Data Access Logic)
            List<string> pictureFilePaths = _services.GetPicturesFromDirectory(_pictureDirectory);
            // Build the Collection of Models here - not done in DataSevices to reduce coupling
            BuildPictureCollection(pictureFilePaths);
        }

        /// <summary>
        /// Build / Load Collection of Pictures
        /// </summary>
        /// <param name="pictureFilePaths"></param>
        private void BuildPictureCollection(List<string> pictureFilePaths)
        {
            foreach (string file in pictureFilePaths)
            {
                // Build Picture Object
                Picture pic = BuildPictureObject(file);
                // Add object to collection if not null
                if (pic != null)
                    Pictures.Add(pic);
            }
        }

        /// <summary>
        /// Load Picture object
        /// </summary>
        /// <param name="filepath"></param>
        /// <returns></returns>
        private Picture BuildPictureObject(string filepath)
        {
            Picture pic = new Picture();
            FileInfo fi = new FileInfo(filepath);
            pic.PictureName = fi.Name;
            pic.PicturePath = filepath;
            return pic;
        }
    }
}

Base View Model Class

This class is used to provide functionality to each view model class without the need to replicate code.  This works perfectly when implementing the INotifyPropertyChanged interface for Data Bound Properties in WPF and Silverlight.

namespace MVVMDemoApplication.ViewModels
{
    public class BaseViewModel : INotifyPropertyChanged
    {
        public event PropertyChangedEventHandler PropertyChanged;

        /// <summary>
        /// Notify of Property Changed event
        /// </summary>
        /// <param name="propertyName"></param>
        public void NotifyPropertChanged(string propertyName)
        {
            if (PropertyChanged != null)
            {
                PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
            }
        }
    }
}

The View

The view should contain the bindings to the view model only.  This may include some event handling.  In this example I used some event triggers for buttons to call methods on the view model directly.  Command binding reduces the need for this extra code.  For this example I did not want to introduce command binding as it does add an extra level of complexity that is best held for future example / post.

This solution has 2 views.  The first one shows the initialization of the View and View Model via XAML.  The second one performs the exact same functions in the code behind page.

View 1

namespace MVVMDemoApplication.Views
{
    /// <summary>
    /// Interaction logic for PictureView.xaml
    ///
    /// NO Business / Application logic should be in this class
    /// This class is for UI Logic ONLY!!!!
    ///
    /// Also note that the events you see in this class can be removed completely when using
    /// Command Binding.
    ///
    /// Added to interface to enable easy UI switching
    /// </summary>
    public partial class PictureView : Page, PictureViewInterface
    {
        // Reference for events. This can be elimnated when using command binding.  The
        // ViewModel in this case was created via XAML through the Data Context method
        PictureListBoxViewModel _plvm; 

        public PictureView()
        {
            InitializeComponent();
            _plvm = (PictureListBoxViewModel)this.gdRoot.DataContext;
        }
        private void btnMakeSmaller_Click(object sender, RoutedEventArgs e)
        {
            _plvm.MakePictureSmaller();
        }
        private void btnMakeBigger_Click(object sender, RoutedEventArgs e)
        {
            _plvm.MakePictureBigger();
        }
        private void btnClose_Click(object sender, RoutedEventArgs e)
        {
            // Grabbed parent window to call the close event on the parent window.  This
            // can be wired up different but was done this way for simplicity
            Window win = (Window)this.Parent;
            win.Close();
        }
        /// <summary>
        /// Added just to show the difference when using different views
        /// </summary>
        /// <param name="sender"></param>
        /// <param name="e"></param>
        private void btnSwitchViews_Click(object sender, RoutedEventArgs e)
        {
            Window1 win = (Window1)this.Parent;
            win.SwitchViews(this);
        }
    }
}

View 2 – Constructor only

    public partial class PictureView2 : Page
    {
        PictureListBoxViewModel _plvm; 

        public PictureView2()
        {
            InitializeComponent();
            // Initialize ViewModel in constructor
            _plvm = new PictureListBoxViewModel();
            // Set Data Context for Grid
            gdRoot.DataContext = _plvm;
        }

View 1 – XAML

Notice the data context and PictureViewModel initialization is done at the Grid.DataContext section instead of in the code behind page.

<Page x:Class="MVVMDemoApplication.Views.PictureView"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:ViewModels="clr-namespace:MVVMDemoApplication.ViewModels"
    Title="PictureView">
    <Grid x:Name="gdRoot">
        <Grid.RowDefinitions>
            <RowDefinition />
            <RowDefinition Height="40" />
        </Grid.RowDefinitions>
        <Grid.Resources>
            <Style TargetType="Button">
                <Setter Property="Margin" Value="5" />
            </Style>
        </Grid.Resources>
        <Grid.DataContext>
            <!--Set the Grid Data Context to the PictureListViewModel which initializes the class-->
            <ViewModels:PictureListBoxViewModel/>
        </Grid.DataContext>
        <ListBox x:Name="lbPictures"
                 ItemsSource="{Binding Path=Pictures}"
                 HorizontalAlignment="Left"
                 BorderBrush="AliceBlue"
                 BorderThickness="2"
                 Margin="10"
                 SelectedItem="{Binding Path=SelectedPicture}">
            <!--The list box template can be removed from this file and placed in a resource dictionary-->
            <ListBox.ItemTemplate>
                <DataTemplate>
                    <StackPanel Orientation="Horizontal">
                        <TextBlock
                            Margin="5"
                            HorizontalAlignment="Left"
                            VerticalAlignment="Center"
                            Text="{Binding Path=PictureName}"
                            />
                        <Image
                            Margin="5"
                            Height="{Binding Path=Height}"
                            Width="{Binding Path=Width}"
                            Source="{Binding Path=PicturePath}"
                            />
                    </StackPanel>
                </DataTemplate>
            </ListBox.ItemTemplate>
        </ListBox>
        <StackPanel Grid.Row="1" HorizontalAlignment="Center" Orientation="Horizontal">
            <Label>PictureView</Label>
            <Button Name="btnMakeSmaller" Click="btnMakeSmaller_Click"  ToolTip="Make selected item smaller" >Shrink</Button>
            <Button Name="btnMakeBigger"  Click="btnMakeBigger_Click"  ToolTip="Make selected item bigger" >Grow</Button>
            <Button Name="btnSwitchViews" Click="btnSwitchViews_Click" ToolTip="Click to switch to other PictureView">Switch Views</Button>
            <Button Name="btnClose" Click="btnClose_Click" ToolTip="Close the application" >Close</Button>
            <TextBlock Name="tbErrorMessage" Text="{Binding Path=ErrorMessage}" Foreground="Red" />
        </StackPanel>
    </Grid>
</Page>

Testing

Another major benefit of M-V-VM when implemented correctly is the ability to test the view model.  These can be in the form of Unit or Integration tests.  I added a test project to this solution utilizing NUnit (DLL provided in solution) so it will build.  You will need a test runner to be able to execute the tests.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using NUnit.Framework;
using MVVMDemoApplication.ViewModels;
using System.IO;

namespace MVVMTestProject
{
    [TestFixture]
    public class TestClass
    {
        [Test]
        public void Verify_PictureModel_HasPictures()
        {
            string imagesdirectory = Directory.GetCurrentDirectory() + "\\Images";
            PictureListBoxViewModel vm = new PictureListBoxViewModel(imagesdirectory);
            Assert.IsTrue(vm.Pictures.Count() > 0);
        }
    }
}

Summary

Using the M-V-VM pattern is a different mindset from traditional WinForms application development.  It is similar to the ASP.NET MVC / Rails patterns but for WPF and Silverlight.  This pattern makes it easy to test the application as the UI presentation layer has been extrapolated from the UI and business logic.  It also helps reduce coupling and make changing the UI layer (Views) much easier.

You can download the source code from here.

Agile Development – Is it for you?

A short answer to a very broad question – Yes.  For a more in depth answer keep reading.

Defining Agile

If you are in the software development world you have no doubt heard the term “agile” thrown around as much as any other word over the past few years.  But what exactly is agile? Does agile mean the same thing to you as it does to me or anyone else?  The chances are probably not.

I have been in a few different industries besides software development and can tell you that each one is different with it’s own set of rules and practices.  One thing that is common between all of them is how to get more value out of an existing set of resources.  So how is this done?  Other terms come to mind here such as Lean and Six Sigma.  Improving existing processes and re-engineering obsolete processes are a must to keep growing.  In software development this is no different and this is where the term “agile” comes in to play. 

Methodology Choices

Agile is a broad term that describes a movement.  Terms like Scrum and XP are specific implementations of this movement.  Each implementation has it’s own set of practices such as TDD, BDD, Stand Ups (scrums), sprints, etc. So the next question is which one do you follow? This is where the confusion comes into play. 

The purists / elitists would have you believe that if you don’t adopt every process / best practice of the methodology then you are doomed to fail.  This is naive and closed minded in my opinion.  If you follow every process to the letter and don’t attempt to improvise or improve the processes then how can we be expected to continue to improve as an industry?  At some point each group would plateau. 

Each process out there fits some teams better than others since each team is different.  Each team has it’s own dynamics that are unique.  So how can one be expected to apply the same business model to every team?  I would say it’s not possible.  What is possible however is to take the best practices from any implementation / methodology that suits your team best and apply it to your team’s processes. 

Test Driven Development

An example of a specific methodology would be Test Driven Development (TDD).  There are many people in the agile community that swear by this concept.  There are just as many that do not believe in it.  I am somewhere in the middle.  I believe testing your code at the unit level is imperative.  Having a high level of test coverage on your code is not a bad thing.  However – we do live in a world where in the end you have to deliver software.  There is a delicate balance between writing production code and test code.  Writing tests for the sake of writing tests however seems wasteful.    A good article on this concept can be found here. 

There are many that believe TDD is the Holy Grail when it comes to quality and software development.  Again I think this is naive.  TDD is a tool that can help you achieve a higher level of quality in the code you write.  However, the code will NEVER be better than the person who wrote it.  If the developer “didn’t consider that scenario” or “didn’t realize the implications” of a feature or technology then the code can be just as buggy or more so than someone who didn’t write it using TDD.  TDD should NOT be used as a crutch to say “hey look at my code – it’s great code because I wrote it TDD”. 

Summary

So based on the above how can we define agile?  A few key concepts come to mind:

• Ability to adapt to change (both at a team and organization level)
• Providing high quality / easily maintainable code at an acceptable pace
• Consistently improving existing processes

Each one of us can choose to become more agile in our daily processes through development practices.  But to do so at a team or organizational level you must be willing to adopt change.  See my post here about what prevents a team from adopting change. 

One other thing to keep in mind and this is where I differ from most of the elitists.  You do NOT have to adopt EVERY methodology to become a better organization.  You can choose what fits your team and apply it.  This does not mean you are doomed to fail.  It means that you are willing to accept that your team must change and you are starting the process to implement that change. 

Developer Testing

During my tenure in the software industry one of the biggest challenges that I have seen from a development team was when was it time to pass the story from the developer to the tester.  Having come up through the software industry via a background in hardware, support, testing, and now development this answer is obvious to me.  However, from experience, quite a few developers tend to release the feature(story for the agile folks) to QA prematurely. 

Depending on what type of system you are doing (Agile, Waterfall, etc) I think it’s important for any developer to thoroughly test the feature up to the point where it is not practical any longer.  I will use the example below to demonstrate my point.

 

Step 1 – Developer gets the specs / requirements (no laughs here) for the feature

Step 2 – Developer implements the code changes

Step 3 – Developer ensures code changes are functioning as expected

Step 4 – Tester tests the changes in a testing / staging environment and notifies developers of any bugs

Step 5 – After all bugs are fixed and tester passes the feature

Step 6 – Customer / Business accepts the changes (UAT)

There are many philosophies and ideas surrounding these steps (especially 2 and 3) on how this should be carried out.  There are many proponents (and opponents) to methodologies such as TDD, BDD, etc.  I feel that regardless of the methodology chosen that the following should be completed by the developer prior to moving to Step 4.

• Each main code path has a unit test to verify the functions are working as expected
• Main integration tests are carried out on the section
• The feature has been walked through / exercised by the developer through the UI *
• If there are multiple data storage options – each one is tested **

* Note that this is not always feasible and goes back to my point above about being practical or not.  This does not have to be done through an official installation – but should be done via the development environment.

** Sometimes the team assignments dictate this is the responsibility of someone other than the developer – in these instances the value of the developer performing the test should be measured on a case by case basis. 

Too many times have I seen developers rush through the coding process and not pay attention to Step 3.  The mentality is “Throw it over the wall and let QA (testers) find the bugs and I will fix them”.  I do not agree with this mentality.  Too many times this practice leads to extra effort being put in to the same process.  This reminds me of the old phrase – “If it’s worth doing – it’s worth doing right the first time”.  I know we are all under pressure and stress to get things accomplished – but sometimes when we pay closer attention to the details – the overall workflow process is improved and more work is accomplished.  The work in this case are features for the end user. 

How do you allocate resources in an agile development environment?

A concept I have been struggling with over the past few months is the allocation of resources in an agile development environment.  The problem I have is how do you effectively allocate resources and what ideas should you be focusing on.  I see there are two main strategies one could use.

1. Focus resources on specific product areas and leave them in that area

2. Do not focus on a specific product area where anyone can work on any product

I’ll start with the pro’s and cons of each

Focus resources on a specific area

Pros

• Resources grow with the product and usually have a higher level of business knowledge surrounding the product
• Developers tend to know the in’s and out’s of the code thus each task takes less investigative time to perform
• Bugs are easier to identify and fix in a more timely manner
• QA Resources tend to have a better understanding of the product and can perform more in depth testing scenarios

Cons

• Knowledge can become isolated and create product silos
• Losing a single team member may be more costly to the team
• When team members are out (vacation, sick, etc) certain areas may not be able to be worked on / or take longer to implement
• If product management team is weak product may trend in a direction different than other products

Do not focus on a specific product area where anyone can work on any product

Pros

• Losing a team member may be less costly to the product team as a whole
• Resources can be assigned more evenly
• Easier to cover team members being out

Cons

• Product domain knowledge is not built up as quickly by individuals so “experts” are few and far between
• With large products a thorough understanding of the entire product suite is almost impossible to achieve
• The likelihood of people making less than desirable changes to core components can lessen the overall quality of the product
• Developers will be less likely to innovate and improve specific code areas as the “ownership factor” is not present any longer as it would be with a single product or work area
• The “individual” is less likely to stand out
• QA resources are forced to work in too many product areas – thus reducing the effectiveness of strong QA personnel

In a simple world this would be an easy choice.  But as I see it we all work in the real world – or at least most of us do.  Keep in mind the above does not take into account what practices are implemented during the agile process (SCRUM, TDD, BDD, CI, etc).  In a system with more than a million lines of code and many different technologies – how would you expect to ask any developer to perform any function or task?  I know there are a lot of great developers who can code in many different languages – but usually people are better in some areas than others.  C++ would be an area like this.  Would you want a “younger” developer who has never coded C++ messing around with one of your core applications written in C++ or would you rather have an experienced developer who is focused on that area?  The same could be said for web development and CSS.  Wouldn’t you want to focus your best – most highly trained resources in the areas they excel the best in so you get the most out of your product?  How can this be achieved if Option 2 is chosen above?  Anybody?

As with any business practice or “religion” there are people who are “purists” for their methodologies.  Some of these have practical experience while others are only hypothetical (educational).  I will say that I do NOT believe that there is a one size fit’s all methodology for any business practice.  There are too many variables for this to be possible.  That being said I am open to suggestions above on how this can be achieved as currently I can’t justify option 2 over the loss of quality in a larger product.

What is Agile development and what does it mean to me?

While I admit I am new to the software industry (4 years) I am a big fan of learning and improving.  This is not limited to my job but a practice I use in my everyday life.  Over the past year I have heard the terms “Agile”, “Sprint”, “Iterations”, “Back log”, and my favorite “Defining done”.  This terms were introduced by a new member to our team (Cory Foy).  He was brought into our team with the goal of helping us move from a waterfall style of development to “Agile Development”.  After much research I have come to realize Agile is not a process, but a way of thinking.

Lets start with the definition of the word “agile”.  Merriam Webster defines agile as 1: marked by ready ability to move with quick easy grace and 2: having a quick resourceful and adaptable character.  If we apply this to processes in our every day life it maybe easier to understand.  Lets look at the examples below.

Example 1: Financial Agility

The ability to absorb and react to any potential cost or market condition with in reason.  This could mean a stock market crash or losing twenty bucks out of your pocket.

Example 2: Sports Agility

In football, a running back must be agile, or be able to avoid oncoming tacklers in any situation, to be effective.

Example 3: Marriage

We must all be agile in our marriages and relationships to withstand the test of time and hold true to our commitments.

Example 4:  Children

Those of us who are lucky enough to be blessed with children realize there is ALWAYS something new that we did not account for.  These could be good things (money for a field trip, college tuition, etc) or bad things (broken arm, lost text book, or “Dad come get me out of jail”).  If we are not agile , or able to react swiftly, then our kids suffer and we as good parents never want that for them.

These are all scenarios where we must be agile in our everyday lives to be successful.  So how do we apply this to Software Development?  Many people have defined agile, think they know what it means, and think their team is an agile team.  May be they are or may be they are not.  The only true test of how “agile” a team is comes when the team is faced with adversity.  This can be in the form of extra work, requirements changes, market conditions, loss of core team members, etc.  A good agile team can react to these and continue to function at a high level.  A team with low agility will suffer more with the same conditions.

So now we know what agile is and believe our team should be agile.  How do we do that?  Being agile should be common sense but as stated previously by someone “common sense isn’t so common”.  So that rules that theory out.  I guess we must teach ourselves to be agile.  So what is the best way to transition a team to be agile?

Agile Training

Ok now we need to train to be agile.  There must be a process called agile but after research I couldn’t find any set of steps called “Agile” that our team needs to do to become agile.  So now what?  That is where Cory Foy came in to play.  He introduced our team to many methodologies from the Scrum process. So now we have an idea of what we are supposed to be doing, a “coach”, and a whole lot of resistance.  As we moved through the process iteration after iteration our team developed some good practices. We implemented things such as iterations (sprints), daily stand-ups, continuous integration, stories, automated deployments, etc.  Our last release was the best release to date.  Our next release will be even better.  But as with any team we have more processes to add, change, remove, or refine.  This is where things get interesting.

Extreme Programming

As a budding developer many of the concepts introduced and / or explained over the past week were not that shocking as I haven’t been programming for years and years.  Terms like “Pair Programming” and “Test Driven Development” were not new to me but many of the tips and techniques were.  One technique I think will be most valuable is to break down stories (features / tasks) down to workable chunks all about the same size.  This makes estimation a lot easier and in the end management will be happier.  By the end of the training I think most people are on board to make an effort in testing out these practices.  I for one am all for it as I think our team will benefit from it (as would any team).

Summary

So now that we have talked about what agile is and we have trained on it we are an agile team right?  Not quite yet.  We still have a long process ahead of building our team’s core processes so we can be more agile in our main role – which is delivering a high quality software product.  This process will be refined and tweaked many times over on a continuous basis as our product grows.  I think being agile isn’t about getting to a certain point or level, but is constantly changing and adapting processes and practices to remain in a constant state of flexibility to any event that may occur.  This requires all team members to change and adapt along with the team.  Due to my inexperience with agile I cannot say that any one process or methodology is better than another while trying to be agile, but can say that each team should choose whatever practices are best for them and their unique set of team members and operating conditions.  In doing this the team should benefit from allowing the team members to drive the “change”.

To end I will say that I cannot see any drawbacks with attempting to become more agile in software development or in life.

What prevents a team from adopting change?

Over the past 18 months our development team has undergone major process changes.  This included Build Automation (CI), automated testing, and other process changes such as working in iterations (sprints).  When the initial changes were being implemented there were a few who were skeptical.  It took a while to get buy in from them but finally did part way into the process.  These changes improved the quality of our latest release exponentially.  This is one thing I think everyone can agree on.

Skipping forward to today we are looking at making additional process changes and refine others.  Again there is skepticism and doubt surrounding adopting the changes.  This doubt was seeded deeply well before the change process was brought to the team for discussion and further analysis.

So the question is why are technology specialists (Developers, QA Technicians, Business Analysts, Mgmt, etc) so reluctant to change when the industry for which we work in is built upon the foundation that change is a good thing and required to stay innovative?

I have narrowed this down to the following items

• Fear of the unknown
• Fear of inadequacy and /or not being able to adapt
• Fear of having skill sets (or lack of ) exposed through a process change

In each of these instances “Fear” is the key word.  We are taught from an early age that fear can be a good thing and it can also be a bad thing if we don’t control it.  Some people use faith to help battle fear while others use meditation, relaxation techniques, etc. These techniques are helpful for any type of fear one experiences, but……

In a business environment how can one adapt to handle the most common fear, Fear of Change?

I feel this can be addressed at many levels of the organization but must always start with oneself.  If you find yourself in a situation where you don’t want to try something or think something is “stupid” without going through the due diligence process then the chances are some type of fear is driving these decisions.  Once you realize what the actual root cause (fear) is then you can address it and move on to overcoming this fear.

There are always cases where the fears deserve merit from past organizational practices.  In these instances the team members must pull together with management to help determine why these fears exist in the team and what must be done to over come them.  Maybe the change proposed at the present time isn’t the best for the individual or the team.  Either way as an individual who is part of a team we all must be open to new ideas and be willing to grow as an individuals and as a team.

To be the best (individual or team) we all must be willing to grow our skill sets and channel the “fear” into positive areas.  Using this fear the team can be sure to implement any change in the best possible way for the team which benefits the team and the individual contributors.

So the only question left on the topic of change is are you a contributor or a detriment to your team?