What does the 4th Agile Principle (Business and Development Work Together) look like in Action?

Many want to go Agile or claim to be Agile. The question is, are you and will you align with the Agile values and principles? In this article, I expand on the fourth principle to better understand what it means and attempt to identify what evidence looks like to determine if a culture change may be occurring. What is this principle?  

Business people and developers must work together daily throughout the project. Agile attempts to bring an understanding of business value to the development team and the technical choices and challenges to the business side. To do this, it attempts to integrate business and development as one team. In traditional approaches, there is often little interaction between the business (e.g., product management, sales, and marketing) and development (aka, cross-functional technical team). On the business side, this may be the Product Manager or Business Owner. Scrum introduces the Product Owner (PO) role and XP introduces the Customer role as the bridge between the customer and the development team. These roles allow for a closer embodiment of the business and development team spirit and avoid fiefdoms and throwing work “over the wall” from one group to another with little interaction. 

The intent is to make a sincere effort to build a collaborative and amicable yet productive relationship between business and development. Development benefits from a better understanding of what the customer finds valuable. The business side benefits because development will ask for details that the business may not have thought about. In both cases, the result is a product that more closely aligns with what the customer finds valuable. What actions and evidence exhibit business people and developers working together?

• An established and productive relationship between business/customers and development
• A dedicated business owner who works continuously with the development team. 
• Development comprises a cross-functional team with developers, testers, technical writers, designers, and so on. 
• The business owner with the development team work together during iterative planning to build a mutual understanding of the requirements of what to build. 
• The development team demos the working product to the business owner and customers to gain feedback to better align with customer value. 
• The development team can reach out to the business owner whenever needed throughout the project lifecycle.   

It is up to you to determine what supporting evidence will highlight that continuous integration, build, test, and frequent delivery is occurring. It is worth experimenting with this as it will help you better understand and embrace the Agile principles. The ultimate question is, do you believe that business and development should work continuously together as a team?

-------------------------------------------------------------------------------------------------

To learn more about what the Agile Principles look like in Action, consider reading:

• 1st Agile Principle (Satisfying Customer with Valuable Software) at: https://cmforagile.blogspot.com/2023/09/many-want-to-go-agile-or-claim-to-be.html
• 2nd Agile Principle (Welcome Change to Requirements) at: https://cmforagile.blogspot.com/2024/01/do-you-have-evidence-to-support-2nd.html
• 3rd Agile Principle (Frequent Delivery) at: https://cmforagile.blogspot.com/2024/02/what-does-3rd-agile-principle-frequent.html

Exploring Five Pair Programming Techniques

A collaboration by Antonio González Sanchis and Mario Moreira

Extreme Programming (XP) introduced a programming technique that’s been famous since its early days: pair programming. It sounds simple, two people working together with the same computer. However, what people don’t know is that there are many ways in which you can approach this technique. Let’s explore a few:

Driver-navigator: This is the best known style of pairing. It consists of one person ‘driving’, taking the keyboard and coding or doing the work, while the other one is ‘navigating’. The Navigator’s job is to pay attention to the work being done by the driver while keeping the big picture in mind.  They should guide the driver in the right direction. It is very important that driver explains every decision they make, otherwise the navigator might lose interest and may stop paying attention. It’s healthy to switch roles every now and then.

Ping-Pong: For this approach you might need two keyboards connected to the same computer. In contrast to the driver-navigator mode, in ping-pong both people can be driving at any point in time. A good strategy for this approach is to have one person writing the tests while the other one tries to pass them. As in the previous approach, you should be switching roles often.

Backseat navigator: A typical approach when there’s a new team member in the group or a junior colleague. The navigator (usually the more senior team member) tells the driver, who has the keyboard, what to do to solve a problem with every little detail. The navigator should provide insights on how to solve the problem but also on why that’s the best solution in mind. It’s a good way to ramp up new members in your team as they build relationships with other people in the team while learning about the working style.

Tour: If there is an even number of team members or someone who you used to pair with went on holidays, you are not going to stop working. However, when those people return or you start pairing with someone, you don’t want them to start right away. Therefore, a good way to start would be to do a ‘tour’ through the code or work you did in their absence. The person who doesn’t know the most about the work takes the keyboard and the mouse and starts driving through the code while the ‘expert’ acts as a navigator and explains every detail.

Distributed pairing: Often people tend to think pairing is for collocated teams but that’s not entirely true. While pairing face-to-face is definitely much more effective than remotely, there are many tools and ways colleagues can pair. A good suggestion would be to use a videoconference messaging tool with a screen sharing app that allows the navigator to see in real time what the driver is doing.

These are not the only pairing styles that you might encounter but they are the best known.  They are also the easier techniques to try when you want to start pair programming. Also, examples seem to focus on software development but pairing is applicable to almost every field.  For example if you are in marketing and are launching an email campaign, you can pair with someone to navigate through the email while you write it, etc.

There might be anti-patterns when pairing. For example, you might find cases when the navigator is ‘sleeping’. This means the navigator can be checking emails, texting or even coding in parallel without paying much attention to the driver. Try to identify the root causes of this behaviour before you jump in into action. Usually it might be because the driver is not explaining properly the reasons why he is doing a specific task in a particular way.

Lastly, keep in mind that while pair programming may work in every role or department, it might not be suitable for every work. There will be times when you just want to discuss the approach with the team and go do it by yourself. That’s also a way of getting feedback, which in the end is the main purpose of pair programming: getting feedback early.  

If you are interested in trying pair programming, the first thing to do is review the list of possible techniques (above) and select one that you will experiment with.  Then identify your pair.  Brainstorm on how you might approach pair programming, specify how long you will try your experiment, and begin.  

------------

Learn more about Antonio González Sanchis at https://www.linkedin.com/in/antoniogonzalezsanchis/

Read more of Mario's article at: http://cmforagile.blogspot.com 

Agile Education Engine - Bringing Power to your Agile Transformation

When I look across the numerous Agile deployment efforts, I see a lower rate of success in achieving the business benefits than I would expect.  May I suggest that in order to improve the odds of achieving Agile success and gaining the business results it can bring, there are three success factors. The first is that the Agile change must be thought of an organizational level change.  The second is that the Agile change must focus on getting the mind Agile-ready.  This is emphasized in the article Are you Ready for you Agile Journey.  And the third is that in order to bridge the gap between the Agile values and principles to Agile methods and practices, people need to be well educated in ways to build more customer value, optimize the flow of work, and increase quality with feedback loops.    

The current level of Agile education tends to be limited to 2-days of training and a variety of books.  I think most people will acknowledge that 2 days of Agile training does not provide enough learning.  On the other hand, reading lots of books takes a lot of time and are often not aligned with each other.  The other challenge with some of the Agile education is that it is often focused only on implementing the mechanics.

What is missing from many Agile transformations is an Agile Education Engine that helps you truly understand and embrace Agile and helps bridge the gap between Agile Values and Principles and the Agile methods and practices.  This will help folks better understand how to understand, embrace, and implement Agile and move beyond simply following the Agile mechanics of the methods and practices.  The Agile Education Engine can help ready the mind for an effective transformation.  

One of the best Agile education engines that I have seen is the material found in the Value Flow Quality (VFQ) work-based education system.  VFQ provides a set of well-researched topics that are easily digested in the form of readings, case studies, activities, and experiments.  It provides students with the ability to study a little, then experiment a little within their own context (aka, project or team).  The benefit of the VFQ work-based learning system is that it helps people apply their newly learned skills on the job when they need them.  This bodes very well for the learners because, they can learn at their own pace and as they are trying to implement the Agile values, principles, and practices. 

Some topics that VFQ offers are: Why Change, Optimizing Flow, Feedback, Requirements, Prioritization, Trade-offs, Understanding your Customer, Delivering Early and Often, Teams, Motivation, Attacking your Queues, Work in Progress, Trade-offs, and more.  Each topic includes a number of techniques that will help you achieve the business outcomes you are looking for.  The VFQ materials will provide you with knowledge on Value Stream Mapping, Story Mapping, Cost of Delay, 6 Prisms and much more.   

In addition, VFQ really helps you get to the state of “being Agile”.  It moves you away from thinking about the mechanics.  Instead, it provides you a layer of knowledge in a critical thinking manner to ensure you apply the principles and behaviors to the practices to gain the outcomes that you want.  Finally, applying the VFQ education is also an excellent way to kick-start an Agile transformation.  This way, the Agile champions for the transformation and teams are armed with a variety of different ways to bring Agile to the organization. 

If you find yourself struggling with getting a good baseline of Agile education, then consider the Value Flow Quality (VFQ) work-based learning system.  It will help you bridge the gap between the Agile values and principles and Agile methods so that you bring the Agile mindset to bear as you start or continue your Agile journey. 

A great Agile book - Being Agile: Your Roadmap to a Successful Adoption of Agile

Being Agile is your roadmap to successfully transforming to an Agile culture. In this unique book, veteran Agile Coach Mario Moreira advises new and current adopters how to implement a robust Agile framework that emphasizes Agile values and principles over the mechanical elements. This book focuses on the business benefit of implementing Agile which focuses on delivering customer value and having a positive impact on revenue. 

This book begins by explaining that in order to truly cross the Agile chasm, there must be a transformation to the Agile culture that focuses on delivering customer value.  Mario shows maturing early adopters how to bridge the chasm between going through the motions of “doing Agile” and genuinely “being Agile.” 

It then delves into the business benefits of Agile and the often missing discussion that Agile supplements your strategy to help your business succeed.  The book highlights the important objectives of customer and employees matter, another area that often is underserved.  It briefly discussions some of the methodologies (including Scrum, Kanban, DSDM, Lean, VFQ, and XP), and the roles a team and organization can play within an Agile context. 

After a high-level synopsis of Agile, Mario reminds us that Agile is nothing more and nothing less than a set of values and principles.  This book delves deeply into a focus on the Agile values and principles.  This book dissects each value and principle that conveys whether they are really exhibited within a culture.  These values and principles must be observed, believed, and translated into actions as an important to precipitate a cultural shift. The book emphasizes the importance of keeping the values and principles always in mind.

The author then plunges into the nitty-gritty of the deploying Agile in a manner that will better achieve an Agile transformation.  He does this by introducing the reader to the Ready, Implement, Coach, and Hone (RICH) Deployment model.  The rubric of readiness engages and begins conditioning the mind toward the Agile mindset as well as focusing on the areas that need to be considered as you are embarking on your Agile journey.  He asks you to consider such factors as:

·         Evaluating team candidates for skills, behavior, and willingness 

·         Assessing Stakeholder buy-in and engagement

·         Determining Suitability for applying Agile

·         Identifying measures to see if you are Agile and if you are deriving the business benefits

·         Establishing a customer validation vision to engage in the critical customer feedback

·         Implementing Agile roles and identifying those best for these roles

·         Establishing an adaptable and scalable Agile framework

·         Determining your User story writing and grooming approach

·         Understanding story points for sizing and establishing a relative sizing framework

·         Establishing Educational needs and building an Agile community

·         Constructing Done criteria and how it helps with quality

Implement focuses on the timely application of agile elements within a team or organization while still maintaining emphasis on the Agile values and principles. Coach focuses on on-boarding teams, coaching teams and management through initial implementation, grooming in-house talent, ensuring Agile values and principles are a focus, while acting as a navigator on the path to Agility. Hone emphasizes the inspect-and-adapt model where periodically the current state is reflected upon and opportunities for improvement identified and acted upon.

This book is geared toward Agile Coaches, Scrum Masters, Product Owners, Team members, product managers, project managers, middle, senior, and executive management in software engineering and development divisions and enterprises.  Learning opportunities include:

·         Comprehending Agile values and principles with an in-depth discussion on each principle and how they may be exemplified within an Agile culture.

·         Advocating a framework in which values, customer engagement, employee engagement, and an Agile framework can lead to an increase in sales and productivity, incorporated in the Agile Value to Incentive Differentiator (AVID) framework.

·         Presenting a methodical yet adaptable approach toward Agile transformation, encapsulated in a Ready–Implement–Coach–Hone (RICH) deployment model that can help establish an adaptable roadmap toward your Agile destination.   

·         Introducing the importance of an Agile Customer Validation Vision that emphasizes a disciplined approach to engaging customers and gaining their valuable customer feedback

·         Providing a mechanism for evaluating your level of alignment to the Agile values and principles, encapsulated in the Agile Mindset Values and Principles (Agile MVP) Advisor.

·         Promoting a special focus on value-added work (VAW) that features customer work as valuable and an accompanying value capture metric.

·         Introducing Gamification concepts to engage and motivate employees toward Agile behaviors with the goal of achieving an Agile transformation

·         Advocating a change in your IT governance toward collaborative governance and performance review process places a focus on team rewards. 

This book ends with three case studies—stories of a smaller colocated project, a medium distributed project, and a large distributed team—to help you understand how the readiness activities, deployment approach, and commitment to Agile lead to different results. This book can help you focus on truly “being Agile” and gain the business benefits of doing so.  What will your case study look like?  Let this material in Being Agile help you achieve a successful one.

Do you bring the “Semper Fi” mindset to your Agile Teamwork?

When I think of a strong example of an Agile team, I recall teams that would help each other out, would watch each other’s back, and would focus on the project at hand, working strongly in a collaborative manner to achieve the common goal. 

Interestingly enough, this is what it takes to achieve the ideal Marine mindset.  Semper Fidelis is Latin for “always faithful” and has been the Marine motto since 1883.  This motto guides the Marine to remain focused on the mission at hand and stay focused on each other as part of the unit, as part of the team.  The intent is that once you commit and become a Marine, you transform to something new, something better, where you don’t worry about yourself.  Instead, you worry about the guy next to you and to the success of the mission.  You live a life with personal integrity, courage, determination, and commitment.  These are the same attributes that make a member of an Agile team successful. 

   

Another mindset within the Marine leadership is “to lead by example”.  In Agile, we don’t need people telling us what to do.  We need people who lead by example and who live the Agile mindset.  This is the best way for the team to absorb what is expected by the Agile values and principles and is another way to grow.  

If you want to learn about the importance of teamwork, spend a moment learning about the mindset of a Marine.  As I would illuminate the attendees of my numerous Agile workshops, one strong attribute of teamwork is “no one succeeds unless everyone succeeds.”  Agile team member should bring encouragement to each other, integrity to do what is right, courage to challenge the bad habits, and commitment to see the work through.  This is teamwork and beyond.    

The Importance of Language in a move to an Agile Culture (with Polling Results)

In my experience in helping teams transform toward an Agile culture, moving away from the traditional terminology and adapting Agile terminology is very beneficial.  At the same time, I have sensed reluctance in organizations in removing from their traditional language.  I believe the language you use matters a great deal if you are attempting to achieve a certain culture.  A prime example is moving from the language of certainty in a more big-upfront Waterfall culture to discovery and hypothesis driven language in an incremental Agile culture.

If you are trying to change culture, the change in language highlights that something has changed and provides folks with a learning opportunity assuming that there is true meaning behind the language and a commitment to change. It makes everyone pay more attention. If you think about it, when you travel from one culture to another, the language does indeed change.  Using the proper language helps you inform and communicate needs more effectively while a common language provides a bond within our community.

Maybe the key is to use language that is most efficient and effective for the culture you want to get to. If you want to change your culture, you need to ensure that the language is not tripping you up and dragging along its baggage of prior meaning.  When you move from a big-upfront Waterfall to an incremental Agile culture, using the same waterfall language will trip you up.

Why? Because people in the organization still think the definition of the term is stemming from the 'old' culture. Attempting to change culture is hard enough and when you have language from the old culture still around, you can be sure that those people within the org are still interpreting the language using the old world context. This can impact your success to advance your new culture. 

With all of that being said, this is the opinion of one person.  So what of the opinions’ of others?  With that in mind, I embarked on a poll via LinkedIn to gauge other’s thoughts on how important is it to use Agile terminology to get to an Agile culture.  I present you with the following results:

Within a period of a month, there were 83 votes cast along with 26 comments.  The poll results revealed that 65% percent (or close to two-thirds) of the participants felt the use of Agile terminology was either ‘Very Important’ or ‘Important’ for an Agile culture.  Another 12% felt it were neutral.  The remaining 23% felt that the use of Agile terminology was of ‘Little Importance’ or ‘Not important at all’.

In order to more fully understand other opinions, I have included a paraphrasing of some of the comments.  They include: there is a need for specialized vocabulary; there are fundamental differences amongst various practices and methods so terminology should be considered; the terminology contributes to language precision; and the words used should work for the culture.  You can see one of the threads within the “Agile” Linkedin group for specific comments from others.

Some took my examples literally.  I didn’t really mean to imply that the term ‘sprint’ and ‘phase’ are the same, but I have seen teams use those terms interchangeably.  So I do agree that one term is not necessarily better than another but that you should ensure the language you use does not get in the way of learning and advancing within your culture.   Also, I’m not clear that there needs to be a standard “Agile” terminology across the industry.  However, with that said, if you are applying Scrum, you should use Scrum terminology (and the same for XP, Kanban, etc). There is a value of having a common Agile terminology within an organization so that there can be a more effective platform for Agile related discussion across teams.  

Also a few people mentioned that the meaning is more important than terminology.  I do favor this line of thinking because there should be an effective meaning behind all terminology used.  Terminology without meaning is babble.  So yes, it is important, dare I say critical to have a well understood and clear meaning behind all the terminology used in order to gain an effective Agile culture. 

Ultimately if you are truly trying to initiate a culture change, then the language should reflect the change you are looking to make.   In this case, if want to establish an Agile culture, utilize the terminology that provides an appropriate and clear meaning which drags little or no baggage.  This will help you get to the Agile culture you may be seeking.  Cheers!

Note: another article that discusses Agile terminology focusing on the terms 'size' vs 'estimate' may be found at: http://cmforagile.blogspot.com/2012/10/size-matters-using-size-instead-of.html

Agile Problem Finder

I occasionally hear that Agile is the silver bullet and will solve all engineering problems. In some cases, someone in management heard about Agile and figured it could be a quick fix to solve the challenges within their organization. Unfortunately this is far from the truth. While Agile mindset and methods can help you adapt to customer needs and deliver more effective customer value, one key benefit that I find is that Agile shines a bright spotlight on existing problems within an organization or team.

This is where Agile methods such as Scrum, eXtreme Programming (XP), Kanban, Test Driven Development (TDD), and others can be very effective problem-finding tools. While this is not what most people think about when adopting Agile, it is a side benefit. It is important to understand that Agile methods won’t necessarily help you solve the problems that are being uncovered but they really need to be removed to achieve the value delivery and speed you are looking for. 

More often these challenges have been around for quite some time, well before Agile was introduced. In fact, management and team members have known about these issues, risks, and dependencies, but they conveniently get buried under the organizational carpet. In the Agile world, every impediment can impact the value and velocity of Agile.  Once Agile comes along, the spotlight focuses brightly on anything that gets in the way of efficient and effective delivery of customer value. What are some of areas where Agile shines the halogens onto existing problems? In my experience, I have encountered numerous challenges during the deployment Agile. Here are some examples:

• When moving to a 2 week cadence of delivery, the team bumped into organizational processes like approvals and alignment of priorities that slowed the team's ability to delivery on a faster cadence. We talked with these approval groups, shared what is agile and asked if they could work with us on a more regular basis (e.g., bring approval groups in earlier and add a Scrum of Scrums to gain alignment with dependent groups).  
• In setting up Scrum teams, it became clear that there is a lack of QA resources on the project (7 developers to 1 QA engineer). We assessed that our development to QA ratio really needs to be 5 to 3, then replaced some developers with QA engineers. Until we could hire the level of QA engineers needed, we had a few of the developers play the QA role.
• We learned that teams often don't stay together long enough to perform effectively.  Project-based company didn't allow bonding time. When the project ended, the employees are reconstituted to other project teams. We worked to have a long lived team allowing them to go through the stages of forming, storming, norming, and then performing and then stay together. 
• The team lacked trust and psychological safety. There is often a culture where trust is damaged by management actions as teams are not trusted enough to make decisions. Teams don't feel safe enough to bring up vulnerable points to more easily get over team hurdles. We implemented bounded authority so teams own their own decision-making.  
• In running incremental QA processes, it becomes clear that there is a lack of automation and, in fact, very few unit tests were ever written. We then spent some time building unit tests to provide at least 80% test coverage (we built this into our Definition of Done), then began automating the tests.
• In running continuous integration, there was a lack of understanding the branching and merging process. Developers were unaware of the importance of refreshing the private workspace with latest successfully built and approved code and also continued to retain local objects and executables in their private workspaces. An effective Checkout/Checkin process (with refresh and build and promote) was established and workspace education was conducted by the Configuration Management (CM) engineers for the team.
• In working with a legacy team, it became clear upon sizing and building functionality on existing code, that we were continually breaking other parts of the code since there was tremendous technical debt within the code base. It was learned that there was no coding standards since the beginning. We initiated a refactoring strategy with coding standards to help us reduce some of the more problematic code modules.
• In working with Product Owners (aka, Product Managers), it became clear that requirements were poorly written which led to a lot of churn between the Product Owner and the developers/QA engineers. The existing requirements list had requirements at multiple levels and it was hard to discern who the requirement was meant for. I educated the Product Owners and Scrum team members on how to write requirements in a canonical form (persona + action + business value) and the POs rewrote the requirements over time in a priority order.

For some teams that move to Agile, they can get overwhelmed by the problems that are identified by the Agile spotlight. In some cases, prior to deploying Agile, it is worth identifying the existing challenges so folks realize they are not caused by Agile. One way to do this is to understand your full end-to-end "idea to release" process. The key is to add the challenges to your issues list, prioritize them, then address them in priority order. Remember, the Agile spotlight can help you identify some of your problematic areas on the product or in the organization. Take advantage of this but be prepared to address the challenges.  What existing problematic areas have you identified when you were implementing Agile?

Agile – Its more Disciplined than you Think

Agile is known to be an adaptive mindset and approach to conduct work to better align with customer needs.  A side affect and often a myth to this is that some think Agile allows ad-hoc changes and it gets branded as being the cowboy methodology. Some folks who say they are Agile, use it as an opportunity to abandon processes and documentation so that they can enjoy the wild west life. These cowboys know that they get away with pretending to be Agile since many folks, particularly their up-line management have little idea of what Agile really is. Other folks like to term whatever they are doing as Agile in order to be on the Agile bandwagon.

However, it is the cowboy and those that want to pretend they are doing Agile that propagated the myth that Agile is an undisciplined approach. Ultimately, these pretenders can give Agile a bad name in the organization and industry since others will believe that Agile means no process, implies an ad hoc approach, and is undisciplined.

For those that have followed the formal Agile approaches of Scrum, Kanban, eXtreme Programming (XP), Test Driven Development (TTD), and more, when done right realize fairly quickly that Agile instills much more rigor and discipline than some folks realize. Some who follow Scrum properly for instance, learn quickly that there is much more discipline than they originally thought.

One of the early introductions to Scrum is Sprint (or iteration) Planning.  Imagine every two weeks you revisit the backlog to reprioritize it, then scrub and design each story, size the work, and commit to the work for the next sprint. This is meant to be a rigorous day of really understanding the work for the sprint where typically your brain will hurt upon conclusion of this day-long session!

Now let’s visit the Daily Stand-up sometimes known as the Daily Scrum. First, imagine that you MUST show up on time. This shows your commitment to schedule and respect for others' time. Then imagine you must share 'what you did yesterday' and 'what you are doing today', and “what are your impediments” and not just to the Scrum Master but to each other. Imagine, every day this is occurring! This starts to get you into a laser focus of the work and gets you motivated to get work accomplished.  

Finally imagine that at the end of each sprint, you must have working software per the end of sprint review (aka, demo). This means that within the end of a two-week sprint, you need to build the user story (aka, requirement) into a meaningful and viewable piece of functionality for validation by customers (and you cannot show customers junk, can you?). Remember that Agile takes an empirical approach where progress is based on actual observations and data to understand progress. 

To add to this, during the sprint each story you work on has to meet the rigorous “done criteria”. Done criteria is a commitment that (for example) each story that is worked on, must be checked out, incrementally designed, coded (following appropriate coding standards), possibly code-reviewed, built, unit tested, checked-in/promoted, merged, integration built, smoke tested, and system tested. Whew, is that enough discipline for you yet? All of this within a sprint so that you can have some tangible to show the customer so that they can validate if you are meeting customer needs.

Or course there are many more rigorous Agile practices. The discipline helps with the productivity and accountability to really become an empowered team. The discipline also ensures you remain hyper focused on the work. So next time someone says Agile is undisciplined and ad hoc, it is clear that they haven't done Agile as it was meant to be, and more importantly, explain to them the real rigors of Agile when you want to have observable progress. 

Holistic view of Continuous Integration & Build (elements of CIB) – Part 2 of 9

In the last episode (e.g., 1 of 9) of this series, I introduced the topic of Continuous Integration and Build (CIB). In this episode, I will introduce the elements of CIB. The key elements involve four areas: a mindset change to thinking more continuously; the entrance criteria that makes the CIB process perform; the components to initiate an effective CIB process; and finally key infrastructure to enable the CIB process. Let us walk through these areas at a high-level.

An Agile mindset merges with the CM mindset. 

• A very interesting cultural shift occurs when the concept of “continuous” is ingrained in the culture and method. Agile embraces a mindset of continuous change where the build process moves from an event-based integration process to a continuous integration process. In other words, no one needs to hold onto large amounts of changes for a major integration effort or declare that builds will occur nightly, weekly, even hourly.

The entrance criteria for an effective and lean continuous integration and build process include:

• The ability to specify the right ‘bite-size’ level of story or requirements tasks that represent changes that allow for granular and frequent code changes. This implies that the Agile team can understand the stories well enough to divide them up in small and consumable tasks which allow the programmer to make changes frequently and incrementally.

The key components to initiate an effective continuous integration and build process include:

• Right-size the branching strategy that reduces risk yet ensures code stability where people can work in a stable workspace without being impact by changes of others on a regular basis.
• Shift in roles and responsibilities of who performs merging and building.
• Minimize the merge process to reduce work for development
• Emphasize building in general and understanding the build levels so it is clear who the target of the build is for. Builds can occur within a private workspace and within shared branches like the mainline or project branches.
• Test with teeth by establishing and conducting unit testing at the individual programmer level and then smoke test after the integration build.

Underneath all of this, there is a need for infrastructure to support a continuous integration and build process. The two primary elements of this include:

• CM version control system that has the capability of establishing the desired branching strategy, has an automated and intelligent merging capability, and can integrate with continuous integration and build tools.
• Continuous integration and build tool that supports an automated build process. There are many continuous integration and build tools on the marketing ranging from vendor products to open source and freeware tools.

Let’s delve deeper into each area. Consider reading the next episode which focuses on the Agile and CM Mindsets (Part 3 of 9) and what this means in an Continuous Integration and Build process.

Note: If you started with this entry (Part 2), consider reading part 1, Holistic view of Continuous Integration & Build – Part 1 of 9