Agile Animal Farm - Pigs, Chickens, and more

Once upon a time there was a chicken and pig walking down the country road. The chicken turns to the pig and says, “I have a great idea! Let’s start a breakfast restaurant called Ham-n-Eggs”. The pig thinks for a moment, and then says, “No thank you. You would just contribute (your eggs) and could leave when you wanted to, while my bacon would be on the line”.

This humorous yet telling analogy from the Agile world helps us distinguish those that are just involved from those that are truly committed on an Agile team. However, in the real world, pigs do have to work with chickens and even other animals around the farm. Let’s take a look at each animal more closely. I have seen or heard about the Pig, Chicken, Fox, and Seagull before and I will also introduce a few more new animals (e.g., Rat, Cat, and Bull) to this interesting analogy. How many of these have you seen in your Agile workplace?

Pig - They are fully dedicated to the project. This would include the Agile team (aka, Scrum Team), ScrumMaster, and Product Owner. They are committed to the work. They work in a pig-pen with other pigs who love their work and environment and love to pitch-in. If Agile is being implemented correctly, they are more than willing to put their bacon-on-the-line every day because they feel ownership of the work. They are assertive and accountable for the success of the project and have a majority (if not all) of their performance goals linked directly to the success of the project and their specific Agile team.

Chickens – They come and go on the project. While chickens are mostly helpful, because they are contributing their eggs, they don’t always understand the full context because they are not a dedicated team member. So occasionally they may accidently contribute a rotten egg. They are not accountable for the success of the project, although they may have a small portion of their performance goals linked to the success of the project.

Fox – They like to stealthily move into and through the team seeing who has certain skills and ideas. Then they like to steal not only resources (Agile team members) for their own teams, but they also steal ideas. They are not necessarily negative, because they are often so quiet in their manipulative work. They are dedicated to their own success.

Seagulls - They like to fly around the project and not really contribute in any manner. They enjoy “talking” (mostly hearing themselves speak) and pretend they are adding value, but they are only annoying the pigs (Agile team members). Often, they like to swoop in so it can look like they are involved (and they’ll tell others this). They are often quite negative, squawk a lot in a “know it all” manner, and often poop on people and their ideas.

Rat –They are deceiver types who will use the trust of the team to gain insight into topics so they can then “rat” on what is going on to others. Often on Agile teams, they are really deceivers because they are really anti-Agile or just plain negative people. They often know the decisions that are made based on certain contexts that the team is in, but will twist the truth in order to bring the project down. It is important to identify these deceivers as quickly as possible and get them off the team.

Cat – They are a lazy type on an Agile team that really do not pitch in but instead like to sleep instead. They are almost purposefully not assertive, have been used to just “getting by” on projects for years, and are not really interested in feeling ownership of the work. They typically neither positive nor negative and simply like to be left alone. The other team members will begin to notice this behavior and realize they are not really interested in becoming part of the team.

Bull – They are command-and-control types who think they can continue to tell their folks what to do even though they are dedicated to their Agile teams. Sometimes referred to as bullies, they charge right into the team and attempt to direct them to their own work and often deviate the team from building product functionality. Typically, they are not interested in the Agile mindset because they see it as a challenge to their authority (technical or managerial) or don’t really understand or care about the business benefits of Agile, but instead want to maintain their own status.

And finally no farm is complete without the Farmer.  However, on an Agile farm, it cannot be just any Farmer but instead a benevolent Farmer who is good to his animals and ensure the animals have what they need to grow and prosper.  The Agile Animal Farmer encourages, inspires, and allows for team autonomy and self organization.     

I hope you enjoyed these animal farm analogies. Did you recognize any of them? What Agile animals are on your Agile farm?

Here are few more links to other Agile animal references:

• Chickens, Pigs, & Seagulls - http://www.scrumology.net/2009/06/10/chickens-pigs-seagulls/
• The Chicken and the Pig - http://en.wikipedia.org/wiki/The_Chicken_and_the_Pig
• The Classical story of the Chicken and the Pig (cartoon) - http://www.implementingscrum.com/2006/09/11/the-classic-story-of-the-pig-and-chicken/

Enjoy!

Holistic view of Continuous Integration & Build (Bite-size Stories) – Part 4 of 9

In the last episode (e.g., Part 3 of 9) of this series, I introduced the importance of the Agile and CM mindset.  One of the key elements in CIB involves an Agile and CM mindset change to think more continuously.  For Continuous Integration and Build to work effectively it is also important to ensure we are breaking down the work into bite-size stories and/or tasks to ensure we can have a potentially shippable increment.  Let’s examine this in more detail. 

In order to do continuous integration, you need to have the work broken-down into a size of work where you can integrate and build frequently.  The ability to specify the right ‘‘bite-size’’ level of story represents change that allow for granular and frequent code changes. This implies that the Agile team has the skills to understand the stories well enough in order to effectively break them down into small and consumable chunks.  This allows the team to make codes changes frequently and incrementally. 

But what are some techniques that help you break down work into bite-size stories? Here are a few ideas:

• Phrase your stories following the Canonical form.  A canonical form for a story is expressed as "As a I want to a so that ". This allows work to be segmented into actor, action, and benefit which helps in breaking down the work.

• Utilize the INVEST approach which stands for making a story Independent, Negotiable, Valuable, Estimable, Small, and Testable (established by Bill Wake). This approach helps us split larger stories or work into smaller bite-sized stories. Here are more details:

• I - Independent can stand on its own and could be demo’able
• N - Negotiable indicates that stories are negotiable and can be adjusted
• V- Valuable to the users and customer
• E- Estimable so that the stories can be sized
• S – Small enough to be bite-sized
• T – Testable so they can be verified and validated to work as written.

• Utilize the Use Case method that helps you break down work into functional steps. Each step should produce a piece of functionality. By using this approach, it provides you a basis for reviewing and determining the value of the functionality from each use case step in the flow. This then allows you to establish a more bite-sized approach to the work using a value and/or priority approach.

As you move to Continuous Integration and Build, your team must have the skills to chunk out the work into bite-sized pieces, in this case into stories that can be done within half the size of a sprint.  This makes continuous integration and build meaningful and allows for more frequent merging and building of the work.  Stay tuned for the next episode where we will focus on the Right-sizing your Branching and what this means in a Continuous Integration and Build process.

Note: If you started with this entry (Part 4), consider reading the first 3 earlier blog entries in this series.

• Holistic view of Continuous Integration & Build – Part 1 of 9
• Holistic view of Continuous Integration & Build (Elements of CIB) – Part 2 of 9
• Holistic view of Continuous Integration & Build (Agile and CM Mindset) – Part 3 of 9

Note: consider reading Adapting Configuration Management for Agile Teams, consider by Mario E. Moreira Wiley Publishing, 2010 for more information on this topic.   

How an Agile Customer Feedback Vision can lead to Product Success!

Gaining periodic customer feedback of working software is an important aspect of agile development, because it ensures that you are constructing a valuable solution for the customer. Without customer feedback, you are not really applying agile; you are just doing a form of iterative development without aligning your work with the customer’s need. While the engineering practices applied within an agile project focus on building the product right, the validation practices focus on building the right product.

The notion of thinking through and establishing a serious feedback approach for the product, which I term the Agile Customer Feedback Vision, is missing from many agile projects—and even missing within the bailiwick of agile practices. This vision is a strategy for identifying the right customers,  applying personas, establishing feedback sessions throughout the project, and then motivating the customers to attend the feedback sessions.

Establish Customer Profiles

Customer profiles are important to a successful implementation of customer validation. A customer profile identifies common traits in your target customers, including demographics, buying patterns, and areas of interest. The goal is to identify and select customers who meet the profile you are looking for and who are willing to provide feedback.

Identify Personas

Personas represent the users of the product that is being developed.  There are often several personas that use a product for various reasons.  An example of 3 personas that may use an on-premise application are: "Regular User", "Power User", and "Administrator".  They all use the product a bit differently and features are built for their needs.  The importance of identifying the personas in regards to customer feedback is that you should invite the customers that represent that persona when those features are being demonstrated.  For example, when you are demonstrating a feature that focuses on administration tasks, then the best feedback comes from having someone from the customer who represents the administrator.

Motivate Customers to Attend

Start by inviting customers to just one end-of-sprint review or demo session and getting their input. Customers who have not experienced something like this before typically are impressed to see working software so early in a release lifecycle. If they like the first validation session, then invite them to the next end-of-sprint review and excite them by highlighting where you’ve incorporated their input. At this point, ask the customers if they want to participate periodically at a per-sprint cadence.

Capture Customer Feedback

Capturing customer feedback is important to ensuring we are "building the right thing".  I have seen feedback languish which defeats the point of gaining the feedback.  It is critical that the feedback gets incorporated into the next Sprint Review.  The feedback that you gain should be linked to the User Story and should also capture the customer by way of Customer Profile that gave the feedback.

Consider Various Types of Customer Feedback Loops

While there is significant benefit to the end-of-sprint review or demo, the customer is, in most cases, only viewing the working software at that point. Let us review the potential types of customer validation sessions and their attributes in more detail.

• Sprint Review/Demo—This is a type of feedback that demonstrates the working software completed during the sprint, shown to customers in order to both highlight progress and gain the all-important customer feedback.

• Hands-on Experience—This is a type of feedback where customers will exercise the software in a hands-on manner in a simulated or pilot working environment.  This could be in the form of alphas or betas.

• On-premise Installation Feedback—this is a type of validation where customers physically install the working software into their environment.

Once you have established the Agile Customer Feedback Vision, it is important to share it with the team so that everyone is aware of the vision and the importance of the validation activities.

To learn more about Personas, go to: http://cmforagile.blogspot.com/2013/12/personas-do-you-really-know-your-users.html.

To read the full article, go to: http://www.agilejournal.com/articles/columns/column-articles/6310-agile-customer-validation-vision.

Robust Agile Organization - Core Roles and Beyond!

To establish to a fully robust Agile enterprise, it is important for everyone to play a role in Agile. I have found that being successful from an Agile perspective requires "core" roles and but must include the "across the enterprise" roles to ensure success.  Let's focus on each of these areas.

Core   

The core roles provide the nucleus for building customer value.  This starts with the Development Team. I prefer to use the term Agile Team (or something similar) since I want to ensure folks understand that it is not just development-centric but includes other key cross-functional roles and disciplines.  This cross-functional team is made up of around 7-9 members who can architect, design, develop, build, technically write, and test. This is commonly made up of developers (who can architect, design, and code, but preferably some who can do all three), QA/testers (who can build and execute tests), UX, DB, tech writers, and CM/build talent. The key is to ensure you have all of the roles you need to build an idea with sufficient skills to get the job done. You may also need a Product Architect which is a role that may not be considered full-time because they can support more than one team related to an idea.  However, it should be committed to the team(s).  This person ensures that the architectural related decisions are established and discussed with the team.

The servant leader for the team is the Scrum Master. The Scrum Master educates the team on Agile processes and practices, and helps them apply those practices. The Scrum Master takes the responsibility of a team coach ensuring the team stays true to the Agile values and principles as articulated in the Agile Manifesto including applying self-organization around the work. The Scrum Master helps the Agile Team and Product Owner remove roadblocks. This role also facilitates the Sprint Planning session, Daily Stand-ups, Retrospectives, and the Agile Release Planning session. Learn more about the Scrum Master in the Who makes the Best Scrum Master article.

Equally important is the role of Product Owner (PO), the driver of customer value. This Agile role should be played by someone within each product team that is customer facing to ensure everyone understands customer needs. This is often played by the Product Manager, Business Analyst, or someone who provides the business perspective and engages with customers to ensure the Agile Team is building something that is of value to the customer. Identifying the right customers for validation is the job of the Product Owner. To scale this PO role, the lead PO may introduce Product Owner Proxies (POP) who may be architectures, lead developers, or functional managers (the latter role may now have much less to do). The POP takes direction from the lead PO via the Product Owner Scrum of Scrum sessions to ensure all POs and POPs are on the same page. Then it is important to bring the customer into the picture to validate that what the team is building is something that the customer actually wants.  Learn more about the PO in the Who makes the Best PO article.

The final core role that is often forgotten in many Agile environments is the Customer.  The customer is core to determining what is value.  With the customer, you are not really enacting Agile. The customer is where many of the ideas of value come from.  The customer provides the valuable feedback along the way that validates (or adapts) what is considered value.  The customer may be in the form of multiple personas depending on their motivations and pain points. 

Across the Enterprise (aka, Beyond) 

If this is your first foray into the Agile space or you want advance in your state of Agile, it is important to have an Agile Coach who possesses deep Agile deployment knowledge to ensure teams are implementing Agile effectively. It has been established that training will only provide initial knowledge but team members can easily revert back to old traditional habits. The Agile Coach understands both the short-term and long-term pitfalls of adopting Agile, that Agile is a culture shift and will take time, and can help the team move to Agile is a more effective and efficient manner.

We then turn to management. Middle Management must play their role where they gently back away from command-and-control and act more as servant-leaders where they trust their teams, help them remove roadblocks, and support the Agile practices. They must realize that their direct reports are now on Agile Teams so they cannot be assigned any additional work. They may attend the End-of-Sprint Review (aka, demo) to gain a more genuine sense of progress (seeing actual working functionality) vs. getting a status report. Often times middle management have less to do in an Agile world and may consider changing their roles to either more of a Resource Management or Product Owner Proxy.  Learn more about Agile and middle management by visiting the Agile and Middle Management article.

Executives/Senior Management needs to play a leadership role as Agile champion. They must support Agile and understand that its primary intent is to build customer value which can ultimately mean more revenue for the company. They must also understand that they must get the Agile teams to feel ownership of their work and this requires leadership and not command-and-control style managers. They may need to adjust their staff if it already laden with too much command-and-control. They may also attend the End-of-Sprint Review (aka, demo) to gain a more genuine sense of progress (seeing actual working functionality).  Learn more about Agile and the Executive role by visiting the Agile Executives Playbook article.

Then we bring in roles like Sales and Marketing, Finance, and HR. These roles should adapt toward the same concepts of agile leadership, self-organizing teams, collaboration, streamlining and eliminating waste. Sales and Marketing are involved with bringing a product to market. They need to help the Product Owner with requirements input and clarification to ensure we are building something the customer needs. They need to understand that the Product Backlog and Release Goals are owned by the Product Owner, they must funnel requirements to the Product Owner, and avoid making commitments without the Product Owner in agreement.

Finance needs to be flexible in understanding that they can still manage to cost because it is the scope that is the important variable.  Finance and Portfolio should adapt to a continuous budgeting approach where ideas are continuously added to an enterprise kanban prioritized by value instead of fixing the work at the beginning of an annual budgeting process. You can learn more in the book Beyond Budgeting. 

If performance objectives are part of the organizational processes, then it is important for HR to establish a performance process that allows for team goals. This is because as part of the Agile mindset, it is important to establish that it is the team’s responsibility to ensure the release is a success and not specific to individuals.  HR can also help the enterprise move from an annual performance review to continuous review and feedback. Learn more about this in the Agile is creating a new horizon for HR article. 

If an idea or product is made up of more than one Agile Team (e.g., for a team of twenty you would want to break them into three teams of around 7), then there may be a need for an Agile Project Manager (APM) to help manage the dependencies and risks across teams, remove roadblocks, and ensure they work in a concert.  They may support a Scrum of Scrums (SoS) or similar.  The APM also handles the interaction with the business governance of the organization.  If your organization is large, you will need an Agile Portfolio Management Leader or team.  This leader focuses on providing visibility to the highest value work so that the organization (and teams therein) are building the highest value work to the customer.

Ultimately everyone within the organization should be focused on understanding and delivering customer value every step of the way. Getting to that value oriented mindset is critical to the success of Agile. It takes teamwork to get there and that team is the entire organization.

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

You can see a presentation that covers many of these roles at: http://www.boston-spin.org/slides/boston_spin_slides_2010_09.pdf

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. 

Knowing your Agile Personalities

When viewing the Agile world, it is beneficial to recognize the different types of folks on your team and in your organization. This can help you understand their perspective on Agile, if they are positive or negative on the topic, and what level of experience they have. Knowing these personality types can be very helpful if you are a professional looking to deploy Agile into an organization or product team. It is important to distinguish between personality types so you understand the people you are dealing with.

What I believe I may have recognized are seven personality types of people who are in the Agile space: the Innovator, Champion, Workhorse, Bandwagon, Cowboy, Deceiver, and Denier. Knowing these personality types can be very helpful if you are an Agile professional looking to deploy Agile into an organization or product team.  Here are details, highlighting the various Agile personality types including their experience levels in Agile, their positive or negative attitude toward Agile, the common roles that fit into a type, and their common attributes. While some folks fit squarely into one personality type, others may have attributes of two (or more) personality type.

Innovator

Agile Innovators make up a small population of folks in the Agile arena who are very experienced in this field and very positive about Agile. Agile Innovator is typically designated as an Agile industry leader and is motivated to improve and extend Agile methods, practices, and techniques. They can provide Agile leadership in an organization’s Agile adoption efforts. Many Agile Innovators have extensive Agile Coaching experience and have the ability to adapt Agile practices and methods to fit the context within an organization. They are motivated to educate others on Agile and understand how to get cultures (e.g., a cultural change agent) to accept Agile. Many Agile Innovators are consultants who move from company to company helping them adopt Agile. Those companies lucky enough to have hired an Agile Innovator as a full-time employee will have the benefit of having this expert to guide the organization through all aspects of an Agile adoption effort.

Champion

Agile Champions tend to know Agile well and are willing to advocate it in a very positive way across an organization. Some common roles in this space are Agile coaches, consultants, product managers, heads of engineering, development, and QA, and project managers. They make up a small, yet core, leadership in the Agile community and communicate the real meaning of what Agile is and what it means to have it applied. Folks in this role, play an important part of getting Agile adopted within an organization’s culture. They can help make it very clear in what conditions Agile will work. They can help communicate where there are challenges and help share new ideas in the Agile space. Agile Champions help generate Agile buy-in with Senior Management, many of which are part of bandwagon crowd (to be discussed momentarily), to initiate a new Agile culture (in pockets or throughout the company.

Work Horse

The Work Horse has learned about Agile by trying to implement it on their own or as part of an Agile team with some help from others. They are mostly positive about Agile but will be fairly honest on what works and what does not. The common role in this space are the members of an Agile team that have implemented Agile methods and practices. They bring a pragmatic approach to Agile, understanding the structure that Agile needs to thrive, by either being bitten once already or by understanding the environment needed for Agile. The work horse has worked in the trenches and really understands the challenges of implementing Agile because of their experience and they know that project success is tied to implementing Agile in an effective and pragmatic way. A lot can be learned from this group.

Bandwagon

The Bandwagon crowd sees benefits in jumping on the Agile bandwagon. Fads and trends rule the day in many organizations so if Agile is perceived to be "hot", then there will be folks who will jump on that bandwagon. Those in the bandwagon crowd tends to be inexperienced with Agile but are generally positive especially when they think it can help their own image or further their career. Some bandwagon folks are engineers who think they should align with the latest enterprise trend so they are perceived as team-players so appear positive since it places them in the right crowd. Some bandwagon folks are middle and senior management who are good at reading the winds of change within an organization and who believe they can get ahead by aligning with the hot new trend even though they may not have much interest in actually learning about that trend (in this case, Agile). They are very willing to "throw around" Agile terminology to give the appearance of knowing more about the field than they actually do.

Cowboy

The Cowboy sees Agile as an opportunity to abandon processes and documentation so that they can enjoy the wild west life. Cowboys are the type of folks who are not necessarily negative about Agile because, in many cases, they know that they get away with pretending to be Agile since many folks, particularly the bandwagon crowd who are their up-line management, really have no idea what Agile is. It is the cowboy that has propagated the myth that Agile is an undisciplined approach for wild-west coders. Ultimately, these pretenders can give Agile a black eye in the organization since others will believe from the cowboy’s actions that Agile means no process. Agile methods instill much more rigor and discipline than most cowboys can tolerate and much more than many folks realize. You will find cowboys out there who know a bit about Agile, and just enough to know how to circumvent it.

Deceiver

The deceiver will provide surface agreement to using Agile but will silently attempt to ignore or even sabotage the project in order to put the blame on Agile. A deceiver is negative about Agile but is usually so because they have thrived using traditional or no method and see this as an impact to their working culture. Some deceivers may have been forced into a role on a team using Agile but do not want to lose any credibility by openly bad-mouthing the new direction. Some deceivers may have enjoyed their singular role within traditional methods and find the team approach within Agile not to their liking and will begin to subtly rebel in a passive-aggressive manner. Some will believe it will impact their career advancements or their compensation. Deceivers are the most dangerous because they may undermine and obstruct the potential success that Agile may bring to an organization and will attempt to hide any evidence of doing so, while a cowboy will try their best to simply avoid Agile.

Denier

The Denier will outright deny any benefit to Agile or their interest in moving to it. They are typically set against Agile from the beginning because they see that it will interfere with what they perceived to be their currently successful role within the company. Some deniers have thrived on playing a very specific role on a project and have been rewarded accordingly. Deniers typically do not have much Agile experience. It is actually better to have deniers than deceivers because with Agile deniers you know where they stand. The input from the deniers can help you understand their specific reasons for objecting to Agile (e.g., rewards, roles, loss of control, etc.). In some cases, by providing the deniers Agile knowledge, may lead them to be more positive impression about Agile, and in-turn some may become Agile work horses or champions. Also, by knowing who the Agile deniers are, they can be moved to other projects that are not going to Agile and where they may can continue to provide value to the company.


Consider reading more on this topic in full article: Agile Personality Types

Holistic view of Continuous Integration & Build (Agile and CM Mindset) – Part 3 of 9

In the last episode (e.g., Part 2 of 9) of this series, I introduced the elements of Continuous Integration and Build (CIB).  One of the key elements in CIB involves a mindset change to think more continuously.  For Continuous Integration and Build to work effectively it is important for the Agile mindset to merge with the CM mindset.  Let’s examine this in more detail. 

CM Mindset

The CM mindset focuses on the CM values.  CM thinking focuses on modularity and in small building blocks.  This makes it easier to group configurations when the building blocks (e.g., configuration items) are uniquely defined.  Thinking in a modular manner also makes it easier to construct and deconstruct a process, particularly when CM professionals are often asked to automate processes so they understand the checkpoints along the way as they script and code.

CM professionals also think in terms of integrity.  This includes both personal integrity in the manner in which CM professionals work and integrity in the product development they are supporting.  Personal integrity implies that CM professionals believe strongly in doing the work the right way and feel accountable to ensure correctness and completion of the task.   Integrity in the product implies that CM professionals feel strongly in working processes that have the ability to track changes to the product and have the ability to verify the baseline of code in which they are working.  

Agile Mindset

Agile thinkers bring a different frame of mind to their work.  In traditional methodologies, the world appears well planned with very specific milestones and changes are constrained after a certain point.  In Agile methodologies, the world is much more fluid, changes are dynamic, and changes are welcome.   Traditional methodologies use a phased or a more serial approach while Agile uses a continually evolving and iterative approach.  In effective, traditional methodologies look for a fairly fixed and pre-defined path while in Agile the path is more collaborative, allowing for learning and gaining an understanding of value to the customer. 

Agile thinking focuses on short iterations and small increments.  In Agile, you time-box activities and breakdown work into small chunks.  This is not dissimilar to CM in thinking modular. This incremental building of functionality allows the customer to provide feedback which in-turn ensures we are building something the customer actually wants.  This allows you to continually see progress. 

The “Continuous” Mindset Shift

A very interesting shift occurs when the concept of “continuous” is ingrained in the culture.  Agile embraces continuous change and those practices that support this.  In more traditional cultures, processes tend to be set up to maintain the status quo and constrain change.  This is why Agile professionals often have challenges getting Agile adopted in more traditional companies.  This is not really a clash of processes, but instead a clash of cultures.  The process used reflects the way the culture works.  Some cultures are heavy in ceremony, governance, and multi-level approval.  Agile will have challenges with this type of corporate culture.

The continuous actions of check-ins and builds introduce a new challenge to CM.  A continuous integration and build practice places considerably more stress and load on the CM version control and build systems.  Having modern, faster, and automated CM tools with underlying infrastructure that can support these continuous actions is important to the success of this practice.

Moving from Event-Driving to Continuous

In an Agile context, what we see in CM and the build space is a fundamental shift in the way we build software.  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.  There is no ceremony needed.  We move away from the infrequent and often painful integrations (a.k.a., merges) and move to an integration and build process that becomes part of the team’s daily activities. 

When you integrate and build all the time, integrations and builds become non-events.  As an example, when code gets continually promoted based on successful private builds and unit tests, an integration and build at the project (or next) level becomes automatic and trivial (e.g., minimal merge and build problems).  Then the results of a successful build routinely become candidates for test and release if they pass the defined tests (e.g., integration, system, performance, etc.) and meet the customer need in the end-of-iteration reviews. 

The primary benefit of continuous integration and build is that the changed code provides immediate feedback whether it runs correctly with the rest of the code in the integration branch (e.g., project release branch or main branch).  When code sits in a programmer’s private workspace, no one else can see it, nor can it be accessed by other programmers. Much like the concept in Agile where value is only realized by working functionality, the same is true with continuous integration.  Progress is only realized when the code has been integrated into the active project code-line where others realize that it exists and it can be built as in an integrated manner with the rest of the code. 

As you move to Continuous Integration and Build, your team must also evolve to a mindset change that involves thinking more continuously.  For Continuous Integration and Build to work effectively it is important for the merging of the Agile mindset and CM mindset in both thought and in action.  Stay tuned for the next episode where we will focus on the Getting to Bit-size work and what this means in a Continuous Integration and Build process. 

References

· If you started with this entry (Part 3), consider reading the first two parts.    

  o   Holistic view of Continuous Integration & Build – Part 1 of 9 (Introduction)

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

· Also consider reading: Adapting Configuration Management for Agile Teams - book by Mario E. Moreira, Wiley Publishing, 2010