Agility and Project Leadership

For Agile software development, I'm a big advocate of XP's practice of continuous integration. This is the practice where a developer checks in code which triggers an automated system to compile and build the code into the system.  One of my early projects was to implement an automated build system for a .Net/C# platform using open source software such as Cruise Control, that worked in conjunction with a custom make file that got triggered during check in to compile and build the code.  There were three development systems these builds got deployed to: development, staging and production environments.

For Agile software development, I'm a big advocate of XP's practice of continuous integration.  This is the practice where a developer checks in code which triggers an automated system to compile and build the code into the system.  One of my early projects was to implement an automated build system for a .Net/C# platform using open source software such as Cruise Control, that worked in conjunction with a custom make file that got triggered during check in to compile and build the code.  There were there development systems these builds got deployed to: development, staging and production environments.

 

If a build got broken due to a complier error or integrations tests did not pass (unit tests were done at the function level), the developer would receive a warning by email that she/he had to fix the error.  This would only effect the development environment.  It wasn’t till we reached the end of our iteration after all the code was checked in and integrations tests passed, that it would be deployed to the staging environment where system and UAT testing got done.  Once this was all complete, it would go to the “production” environment.  I have production in quotations as this was really a pre-production or “prototyping” environment.

 

So it was with interest that I read this post from the Plastic SCM website about the difference between a “continuous” and “controlled” integration:

 

In a regular continuous integration scenario, all developers perform integrations and solve merge conflicts in code, which is perfectly acceptable on small, well-trained teams. Even agile teams can be affected by personnel rotation, though, or just new members joining, and it’s usually not a good idea to have a brand new developer mixing code he doesn’t yet understand.

 

In controlled integration a new role shows up: the integrator. The integrator is usually a seasoned team member who is familiar with the bulk of the code, the version control system, and the build and release process. The most important feature of the integrator is not that she knows all the code, which is not even necessary, but that she takes responsibility for the integration process. The integrator’s primary goal is creating a new stable baseline to serve as the base for development during the next iteration.

 

I have to agree with this and think it is an important distinction to make.  For the automated test system I was in charge of, I played that role of Integrator that was tasked with setting the baseline for the development of the next iteration.

 

The illustration above shows an example of a mixture of a continuous and controlled process.  For anyone tasked with deploying an Agile software development project and are utilizing continuous integration, I recommend looking at this model and ensuring you and your team recognize the difference and where to adopt one process or the other.For Agile software development, I'm a big advocate of XP's practice of continuous integration. This is the practice where a developer checks in code which triggers an automated system to compile and build the code into the system.  One of my early projects was to implement an automated build system for a .Net/C# platform using open source software such as Cruise Control, that worked in conjunction with a custom make file that got triggered during check in to compile and build the code.  There were three development systems these builds got deployed to: development, staging and production environments.

If a build got broken due to a complier error or integrations tests did not pass (unit tests were done at the function level), the developer would receive a warning by email that she/he had to fix the error.  This would only effect the development environment.  It wasn’t till we reached the end of our iteration after all the code was checked in and integrations tests passed, that it would be deployed to the staging environment where system and UAT testing got done.  Once this was all complete, it would go to the “production” environment.  I have production in quotations as this was really a pre-production or “prototyping” environment.

 

So it was with interest that I read this post from the Plastic SCM website about the difference between a “continuous” and “controlled” integration:

 

In a regular continuous integration scenario, all developers perform integrations and solve merge conflicts in code, which is perfectly acceptable on small, well-trained teams. Even agile teams can be affected by personnel rotation, though, or just new members joining, and it’s usually not a good idea to have a brand new developer mixing code he doesn’t yet understand.

 

In controlled integration a new role shows up: the integrator. The integrator is usually a seasoned team member who is familiar with the bulk of the code, the version control system, and the build and release process. The most important feature of the integrator is not that she knows all the code, which is not even necessary, but that she takes responsibility for the integration process. The integrator’s primary goal is creating a new stable baseline to serve as the base for development during the next iteration.

 

I have to agree with this and think it is an important distinction to make.  For the automated test system I was in charge of, I played that role of Integrator that was tasked with setting the baseline for the development of the next iteration.

 

 

The illustration above shows an example of a mixture of a continuous and controlled process.  For anyone tasked with deploying an Agile software development project and are utilizing continuous integration, I recommend looking at this model and ensuring you and your team recognize the difference and where to adopt one process or the other.

For Agile software development, I'm a big advocate of XP's practice of continuous integration.  This is the practice where a developer checks in code which triggers an automated system to compile and build the code into the system.  One of my early projects was to implement an automated build system for a .Net/C# platform using open source software such as Cruise Control, that worked in conjunction with a custom make file that got triggered during check in to compile and build the code.  There were there development systems these builds got deployed to: development, staging and production environments.

 

If a build got broken due to a complier error or integrations tests did not pass (unit tests were done at the function level), the developer would receive a warning by email that she/he had to fix the error.  This would only effect the development environment.  It wasn’t till we reached the end of our iteration after all the code was checked in and integrations tests passed, that it would be deployed to the staging environment where system and UAT testing got done.  Once this was all complete, it would go to the “production” environment.  I have production in quotations as this was really a pre-production or “prototyping” environment.

 

So it was with interest that I read this post from the Plastic SCM website about the difference between a “continuous” and “controlled” integration:

 

In a regular continuous integration scenario, all developers perform integrations and solve merge conflicts in code, which is perfectly acceptable on small, well-trained teams. Even agile teams can be affected by personnel rotation, though, or just new members joining, and it’s usually not a good idea to have a brand new developer mixing code he doesn’t yet understand.

 

In controlled integration a new role shows up: the integrator. The integrator is usually a seasoned team member who is familiar with the bulk of the code, the version control system, and the build and release process. The most important feature of the integrator is not that she knows all the code, which is not even necessary, but that she takes responsibility for the integration process. The integrator’s primary goal is creating a new stable baseline to serve as the base for development during the next iteration.

 

I have to agree with this and think it is an important distinction to make.  For the automated test system I was in charge of, I played that role of Integrator that was tasked with setting the baseline for the development of the next iteration.

 

The illustration above shows an example of a mixture of a continuous and controlled process.  For anyone tasked with deploying an Agile software development project and are utilizing continuous integration, I recommend looking at this model and ensuring you and your team recognize the difference and where to adopt one process or the other.

For Agile software development, I'm a big advocate of XP's practice of continuous integration. This is the practice where a developer checks in code which triggers an automated system to compile and build the code into the system.  One of my early projects was to implement an automated build system for a .Net/C# platform using open source software such as Cruise Control, that worked in conjunction with a custom make file that got triggered during check in to compile and build the code.  There were three development systems these builds got deployed to: development, staging and production environments.

 

If a build got broken due to a complier error or integrations tests did not pass (unit tests were done at the function level), the developer would receive a warning by email that she/he had to fix the error.  This would only effect the development environment.  It wasn’t till we reached the end of our iteration after all the code was checked in and integrations tests passed, that it would be deployed to the staging environment where system and UAT testing got done.  Once this was all complete, it would go to the “production” environment.  I have production in quotations as this was really a pre-production or “prototyping” environment.

 

So it was with interest that I read this post from the Plastic SCM website about the difference between a “continuous” and “controlled” integration:

 

In a regular continuous integration scenario, all developers perform integrations and solve merge conflicts in code, which is perfectly acceptable on small, well-trained teams. Even agile teams can be affected by personnel rotation, though, or just new members joining, and it’s usually not a good idea to have a brand new developer mixing code he doesn’t yet understand.

 

In controlled integration a new role shows up: the integrator. The integrator is usually a seasoned team member who is familiar with the bulk of the code, the version control system, and the build and release process. The most important feature of the integrator is not that she knows all the code, which is not even necessary, but that she takes responsibility for the integration process. The integrator’s primary goal is creating a new stable baseline to serve as the base for development during the next iteration.

 

I have to agree with this and think it is an important distinction to make.  For the automated test system I was in charge of, I played that role of Integrator that was tasked with setting the baseline for the development of the next iteration.

 

 

The illustration above shows an example of a mixture of a continuous and controlled process.  For anyone tasked with deploying an Agile software development project and are utilizing continuous integration, I recommend looking at this model and ensuring you and your team recognize the difference and where to adopt one process or the other.

You knew it would happen and so it has, with the growing popularity of Kanban in recent years by the Agile community someone was going to merge Scrum with Kanban and call it something cute: Scrumban! (Scrum + Kanban).  Before you roll your eyes and shrug your shoulder at "yet another Agile method", it may be something worth looking at.

Here's a slide from Yuval Yeret who was apparently one of the first few people to formally propose this:

So in a nutshell here's the rationale for combining the two:

• Since there seems to be many synergies between Scrum and Kanban techniques, why not combine the best elements of both into one
• Kanban already has a well know lean way of visually presenting the flow of work, so use it to visualize backlog items and user stories
• Itegrate daily stand up meetings with Kanban review boards to move the flow of the project more effectively
• Use visual WIPs to help prioritize backlog items and user stories to efficiently achieve incremental progress

Some challenges you will face and need to address before moving forward:

• Unless you and your teams familiarize yourself well with both techniques, you may waste more time context switching between which Scrum or Kanban method to follow.  Worse, you will confuse the team and Product Owner with inappropriate use of terminology creating self-induced impediments
• Kanban places a limit on WIPs, which in Scrum means placing a ceiling on the number of backlog items to be checked off at any given time causing the flow to slow and/or stop.
  • Not too big of a deal, but goes back to the previous challenge just mentioned in that a Scrum centered team will get slowed down by wondering what to do when the limit is reached

Anyway, this is yet another inevitable evolutionary iteration of Agile methods and techniques that you may want to familiarize yourself with and try out if it suits your project's goal and requirements.

Yet another adoption of Agile outside of software development presents itself again with this article on how a retail outlet called "Oddyssea" based in Half Moon Bay, CA, used Agile development principles to deploy their retail operations:

On July 14, 2012, Oddyssea, a first-of-its-kind retailer, opened in Half Moon Bay, Calif. Equal parts science, nature, games, magic and furnishings, with a generous dash of whimsy, Oddyssea thematically is dedicated to exploring, creating and discovering. What’s most interesting about the Oddyssea retail experience is it was conceptualized, designed, implemented and continues to operate using Agile. The Agile software engineering model.  But Agile is unrelated to the store’s point of sale, inventory management or financial systems. Rather, it’s completely focused on defining the retail experience... to build a retail operation that was flexible and open to customers, collaborative with his target market and, most importantly, change ready.

Leveraging the principles of Agile from software development, they customized the methods for:

• Quicker conceptualization of new retailing ideas
• Design implementation based on those ideas
• Development of a working prototype
• Testing and tweaking of the prototype based on customer feedback 
• Creating a culture of continuous improvements by making each iteration better than the last and delighting their customers

I recommend reading the article if you are interested in seeing how Agile is crossing over the boundaries of software development to the development now of retail outlets!

1. Rapid deployment of new workloads
2. Try before you buy
3. Buy only what you need, only for as long as you need it
4. Get out of the business of running infrastructure and instead deliver higher level strategic value
5. Greater flexibility in technology adoption strategies
6. Lower costs (maybe)
7. Greener (maybe)

1. Rapid deployment of new iterations (or Sprints for Scrum’ers)
2. A “potentially shippable product” at the end of iterations that business could try before they buy
3. A “money for nothing, changes for free” Agile procurement model (could definitely be used if you are doing internal charge backs to business for IT services)
4. Focus on business value and collaboration rather than standards and processes
5. Embrace and create a culture of responding and adapting to change rather than resisting it
6. Lower costs by delivering products faster and with higher quality
7. Be an advocate for sustainability by incorporating Agile, Lean and Green