Mario Moreira

What is your Agile weather report for 2011? Some have sunny Agile efforts ahead. Some are looking across the Agile landscape and into the clouds, some are looking to get introduced to agility, and others are considering strategies for Agile deployments. As we gaze in the horizon, what do we think will be hot in the Agile landscape and improve our working lives? What might be some of the latest shifts in the Agile industry in the upcoming year?

There continues to be a lot of debate on whether Agile is mainstream. According to a Forrester report published in early 2010, while widespread “Agile” use of the iterative software development processes is found, " teams are not adopting scrum, extreme programming, or another specific Agile approach, but are embracing agile as an ethos or philosophy and cherry-picking the best bits from many different process models to develop a formula unique to their own situation." However, the largest category in the survey – and the one that is the most telling is that 30.6% of the respondents said they do not use a formal process methodology. Add to this my own experience implementing Agile, reading the latest Agile literature (e.g., articles, research, books, etc.), and discussing Agile (and Agile implementations) with people across numerous companies in North America, Europe, and Asia, and what this indicates to me is that:

Mario Moreira surveyed recently surveyed agile professionals to find out just how valuable CM processes and tools are to them. While there was a noticeable difference in opinion between different responder age groups, the overall response was overwhelmingly positive in CM's favor.

How do companies face the challenge of setting up their infrastructure when they've just started agile development? One option is to move your infrastructure to the cloud. In this article, we help you decide what's the best fit for your team and project by addressing this issue head on.

Configuration management (CM) provides organizations with a level of control over the changes that occur in the engineering space.  It can help protect the valuable code assets of the revenue generating products within the organization.  CM provides the capability for products to manage the pieces therein that change at different rates, exposes the changes that are occurring, and establishes knowledge of the baseline of the product which then improves integrity and minimizes product regression.  In addition, CM not only assesses the impact of change, but assists in problem resolution.   While the value of CM is typically understood within engineering organizations, it is important to apply CM investment wisely. 

I have seen many Agile projects, particularly those focused on brand-new product lines, struggle with getting their infrastructure up and running. Much of the reason is the time and effort that is needed to get infrastructure established far exceeds the time it takes to start development using an Agile method, effectively the first iteration. Typically the approach used to establish infrastructure is ad hoc and often not always aligned with the needs of the project. Therefore, a task must be identified to establish infrastructure. The question then is, how to best approach the establishment of infrastructure for a project using Agile methods? We do not want to build excessive infrastructure that may constrain us in the future yet we want to establish enough to keep us stable and productive.

The end of 2008 presents us with a very weak economy.  We hear the words economic crisis, gloomy outlook, recession, and economic decline in the news again and again.  We are also seeing small to massive layoffs in a number of sectors and IT is certainly not immune.  The question for those CM'ers in light of this economic downturn is how do I adjust my configuration management (CM) planning for the coming year when budgets are being slashed and projects are being cancelled?  

Does the title of this article sound silly?  I mean, doesn’t everyone know what a configuration management (CM) tool is?  Isn’t a CM tool something that provides version control functionality?  Well, the short answer is yes but only in its most simplistic form.  CM as a discipline goes well beyond simple version control.  It is important to look beyond what vendors define as classic CM tools and consider CM in terms of the full practice and processes they offer.  CM at its very essence covers identification, control, audit, and report.  Many would expand control to include version control, change control, build management, and release engineering. 

Early implementations of Agile focused on brand new or newer product-lines. More recently, Agile is gaining acceptance in the legacy product space where the project teams are moving away from their company's traditional (aka, waterfall) methodology and moving toward an Agile approach. In these cases, the project team that begins to use Agile methods are typically inheriting an existing infrastructure that was constructed for a phased (aka, waterfall) approach.

As many have learned, using Agile methods can provide solid business benefits including earlier return on investment, earlier detection of failed efforts, and more satisfied stakeholders. However, when applying Agile methods to product-lines (and projects therein), often there are dependencies on other products (and their projects), services, and organizations that may run in a more waterfall or hierarchical manner. If the Agile project and product therein are self-sustaining with no dependencies on outside factors, life can be quite good. But most of the Agile projects I have worked with or visited have varying degrees of dependencies on other products or services that run in a more waterfall or hierarchical manner.

For some organizations, IT governance is just another set of standards that is stated yet with few (or no) compliance expectations, little actual verification occurring, few or no metrics to indicate compliance, and even less use of the results by senior management to run their organization. Without support for standards, including practices, policy, verification, metrics and management’s commitment to use the results to manage the organization, IT governance, like any other standard, will only be perceived as yet another item that has little management support and is lacking value in the organization.

Is there a place for project management in the establishment of a configuration management (CM) infrastructure?  If so, then how much project management should be included?  A thin but strong layer of PM may be helpful to tie tasks together and keep
project team members in-sync with one another. 

Metrics provide data points that can both benefit and endanger and organization.   Metrics can be used positively to build a better organization and can be used negatively to punish organizations and people therein.  Many times, those that use the metrics negatively do it purposefully, but other times, they are not aware of the way they are using them.  This is why it is important to have a metrics culture that apply metrics in a positive manner, provides an understanding of the metric, and then actually utilize metrics to manage an organization. 

As we look to deploy or improve a requirements practice, the output should lead to a set of complete and quality requirements. A way to get there is to ensure that requirements have been captured in all pertinent categories and are testable. Often times, requirements focus on user needs and limited functional areas. But what may be overlooked are lesser requirements categories (e.g., security, usability, etc). It is therefore essential to capture requirements that ensure coverage in the requirements space.

There is always talk about improving application quality.  In many instances, a large quality program gets initiated that either takes a lot of resources and time or introduces change that is too challenging for the organization (or project team) to handle. It is usually better to start on a smaller scale. Focusing on improving application quality in the programming phase, a couple of suggests are: 1) initiate peer reviews (e.g., code reviews) and/or 2) initiate pair programming.  While peer review is more widely known and used in the software development industry, pair programming offers more problem solving possibilities. Both are known to reduce defects and improve quality. The key is to introduce a small initiative like peer review or pair programming ensuring you are building the practice for success.

Branching is both simple and complex.  For many, it is challenging to know where to begin.  This article hopes to provide a starting point, by highlighting branching concepts, providing reasons for branching, and suggesting an approach to establish a branching and merging strategy.

The activity of managing change is known as Change Management.  Managing change is typically very challenging and may occur at many levels within a workplace.  A key when implementing a change management process is truly understanding what should be managed and by whom.  For the sake of argument, I will refer to the group that manages the change as the Change Control Board (CCB).  However, there are other names used to represent this group (e.g., Configuration Control Board, Governance Board, etc.).  It is important to understand that while I use the phrase "manage or control the change", a CCB may not really control the change as much as acknowledge the change and apply impact analysis for the change in order to determine the best deployment guidance for the change.

Change control is a configuration management process used to manage changes to important baselines like requirements and production. Change control may be considered a critical practice in that it often can be used to manage critical items within a project lifecycle, an application lifecycle, or the organization. It can be challenging to implement change control effectively. Often the reason why is because there is an anti-pattern (poor unworkable solution) in place.

What title should we give a CM professional? Various ones are used, such as CM tool administrators, build engineers, release engineers, product installers, and more. It may appear that these roles are somewhat similar, but there are differences in the responsibilities and corresponding skills if you look at the context of the role.

The term “continuous integration” is getting a bit of attention these days. It refers to the process of integrating often (or immediately) to reduce integration effort, complexity, and pain.It allows for others make changes more readily. While the term “continuous” is catchy, it is not accurate in what the concept implies. In context to integration, it implies a process without interruption.

Many in the software engineering world consider build, package, and deploy the core areas of configuration management (CM). To highlight this, many CM jobs are titled “build engineer” or “release engineer” with responsibilities that focus on the tasks of building, packaging, and deploying releases.

In the past, I had a window view of the Boston Harbor from my office. I could see boats coming in an out, including numerous tour boats, whale watch boats, and sail boats. Occasionally, I got the chance to see the large ships including the tankers, battleships, tall ships (e.g., elegant large sailing ships), and the rare site of an aircraft carrier. The aircraft carrier is a floating runway for jets. Imagine the infrastructure needed to get those incredibly fast jets ready and flying.

In the ever-growing complexity of dependencies amongst products at the build and run time level, there is the challenge of managing increasingly separate items that must work together upon release. This is where the concepts, disciplines, roles, and responsibilities of release management help. Release management focuses on both the engineering disciplines that must bring a specific project release together along with the management of external dependencies across products that must accompany a release.

There was a time when mainframe development was the norm and teams were in close physical contact only having to walk down a few feet to interact with their colleagues. However, times have changed and access to code has to be considered in a much more serious manner. Some companies have had multiple sites participate in their development efforts for upwards of two decades, but a majority of them have only been at this for the last 5 years or just undertaking this venture. The crux of distributed development is the ability to share code for development across sites via the network or via tape or disk.

As more test items exist, there is a tendency for them to evolve due to the changes to requirements and code and, therefore, must be managed effectively. When there are an increasing number of test items, this increases the risk of failing to accurately track all test items, particularly when this is done manually. This is where configuration management (CM) can help.

Have you ever wondered what is the best approach to establish the relationship and the placement of the tasks of the various software disciplines?   Have the project managers, developers, and testers been confused because they generally know what CM is but are not clear where CM tasks should occur in a project release lifecycle and how they relate to other disciplines?  

There are times when Software Configuration Management (SCM) gets implemented and the results may not be as positive as one would hope. There can certainly be many reasons for this, but some times, it comes down to whether or not due diligence was performed during SCM planning,an important criteria for successfully implementing SCM. Other success criteria include: sponsorship (management commitment to the SCM effort); funding (money to purchase appropriate SCM tools and infrastructure); and personnel (persons trained, skilled, and experienced in the areas of SCM tools and process). However, effective SCM Planning should cover sponsor, funding, and personnel tasks if structured appropriately.