Agile Adoption Roadmap

Building Agile into your ALM Solution

2012-01-19T10:57:00.000-08:00

What is a good ALM solution? I define ALM to be a set of tools and practices that work together across the project lifecycle, from inception into production, to help you deliver an instance of a product (aka, a release). A reasonable ALM product will have a common user interface for utilizing the ALM functionality. It will also include a meta-model and process engine to parse and share information across and amongst the various functions within the ALM framework. IMHO, I believe ALM is still relatively immature and I don’t sense that there are strong business reasons for doing ALM and still lacks the true integration that is needed to make it seamless. So what would a business drive ALM framework look like? This is where Agile comes in.

I believe a key driver to ALM is focusing on customer value from inception to release. This is what an Agile mindset brings to the table. While many ALM frameworks start with planning or requirements, I suggest agile ALM begin as early as inception or during the creation of the business vision for the product or a specific release. This helps provide the context of the customer value that is being built during the project. Agile ALM also should include mechanisms that focus on customer validation along the way and effective product delivery.

What I am advocating is introducing the notion of the value chain. This concept has been around since at least 1980 when Michael Porter established his value chain framework and further explained in his 1985 book, Competitive Advantage: Creating and Sustaining Superior Performance but the concepts had been discussed in conferences and companies well before this time. I suggest taking the ALM framework, merging it with a customer value chain framework, all while applying the agile methodology of iterative and incremental approaches ©. This integrated framework emphasizes customer value and validation in an iterative and incremental approach. The primary value of my ideal Agile ALM framework is that it provides the mechanisms that enable continual focus on the value of what we are building for our customer throughout the lifecycle so that we ensure we are delivering of value.

To gain more detail about what I believe to be an ideal yet effective Agile ALM framework that is focused on delivering customer value, consider reading these articles:

• Agile ALM for Delivering Customer Value - Part 1 of 2 - published in the Configuration Management (CM) Journal - January 5, 2012

• Agile ALM for Delivering Customer Value – Part 2 of 2 - published in the Configuration Management (CM) Journal - January 11, 2012

Agile Definition of Done Starter Kit

2011-11-29T10:14:00.000-08:00

I often find it amusing when the definition of ‘done’ in Agile is sometimes called ‘done-done’. This is meant to imply that we are not just done with development (the 1st done), but we are done with testing (the 2nd done) as well. However, if you think about all of the activities that are needed to get stories in a sprint backlog into the shape to be potentially shippable, you should probably call it “done-done-done-done-done” and possibly more (LOL).

So what is the importance of done criteria? First as mentioned, it helps the team understand what is the expectation of getting a story (or the functionality therein) into shape to be potentially shippable. Second, it helps identify the activities and expectations that must occur to build a quality product. Third, all activities in the done criteria are considered when the team sizes the work during Sprint Planning and, therefore, has a direct impact on the sizing of stories. When the team sizes a story, they need to ensure it includes all of the work described in the team’s "done criteria".

As an Agile Coach, I usually bring a starter kit of typical tasks to get a story to "done". This helps initiate an active discussion prior to sprint 1 amongst the team so that each team member understands the various elements of the done criteria and what elements we are agreeing too as a team. Here is my done criteria (aka, definition of done) starter kit:

Incremental designing (and what type of design type(s) the team will use)
Incremental development (per the development programming techniques, and this includes developing documentation such as user guides and such)
Incremental building/evolving the unit tests
Consideration for incrementally building out automation for regression testing, etc
Applying appropriate source control, checkout/checkin, and branching/merging
Applying approach incremental local builds (in private workspace)
Applying code review (or pair programming if being applied) as appropriate
Incremental testing (per the testing types, e.g., functional, system, integration, etc., pending how much automation there is)
Meeting acceptance criteria shared by the Product Owner

At this point, the team discusses these elements and establishes a common definition of done for the stories and the sprint. Now keep in mind that this is the team’s common done criteria and it should be flexible depending on the type of work. Also, once the team agrees to done criteria, expect it to evolve over time and it may be a discussion in the Retrospective if it needs improvement. Some of the effort associated with your definition of done is dependent on what tools, infrastructure, and automation, that currently exists and where you want to go, so keep this in mind.

Finally, if your definition of done has nine key activities, then you can call it the “done-done-done-done-done-done-done-done-done” criteria (LOL). Maybe just one "Done" is enough. Once you establish the done criteria for the team, don’t forget to evolve it over time to get you to a quality and releasable product!

Agile and the Cloud – Match made in Heaven!

2011-10-30T09:54:00.000-07:00

Agile and the Cloud are both pervasive these days. Agile is a software development method based on an iterative and incremental approaches. As most software professionals are aware, the action of delivering the increment into the traditional on-premise software product environment is often laborious and time consuming. Software as a Service (SaaS) conveniently provides shared software products as services, and associated data via the Internet, a model that can be scaled and configured to a company’s or product team’s needs. SaaS changes the software paradigm by providing the software as a service “in the cloud” to companies that need that software product. Companies no longer need local administrators to handle the rigorous and time-consuming effort of establishing on-premise software product infrastructure and the installing the software.

When building products for the cloud, a production-ready environment is made available to many teams almost instantly. While most products require an on-premise installation, building cloud products reduces the need for the often rigorous and time-consuming effort of installing the new releases of the software product infrastructure. Because Agile utilizes an iterative and incremental approach, SaaS products can be incrementally upgraded when the end-of-sprint review (aka, demonstration) indicates that the product is ready. The effort on the SaaS provider side is reduced also, because a few installations by experts are much easier to develop and manage than the many installations by customers (and documentation, ramp-up, and problem resolution that are included).

On the Agile side, the challenge is to build an infrastructure that supports Agile and does not impede the progress of the Agile team that must continue to deliver value. A simultaneous goal is to avoid investment in infrastructure that may not be needed in later phases of the project. One suggestion is to utilize the infrastructure envisioning approach, which applies an incremental approach to the continuous establishment of an effective infrastructure. This is where Infrastructure as a Service (IaaS) and Platform as a Service (PaaS) can be useful to Agile teams. The cloud IaaS and PaaS approaches enable consumers to only use and pay for what they need. This is a distinct advantage for incremental development processes like Agile. This "use-what-infrastructure-you-need" approach minimizes technology debt and allows the team to adjust and scale its needs just-in-time.

As Agile methods continuously build SaaS product increments (i.e. functionality), the cloud deliver them as increasing business value to the customer with little effort from the customer. In addition, the cloud (by way of IaaS and PaaS) provides Agile projects with tools and infrastructure just-in time, so that the team always has the tools and infrastructure they need but never wastefully invests in unused equipment. Consequently, they are able to provide continuous value to the customer in the cloud. This mutually beneficial relationship is a “match made in heaven” for project teams utilizing Agile to build software in the cloud and using cloud infrastructure to support Agile projects. To learn more about on this consider reading the Winning Combination of Agile and the Clouds.

Have you benefited with the Agile and Cloud relationship? If so, in what ways?

Agile Culture - Are you Stepping Up?

2011-09-27T19:00:00.000-07:00

In the traditional and waterfall world, there tends to be a more directive approach to managing the projects. A hierarchy exists where decisions get made not necessarily based on full knowledge, experience, or information, but based on position. Often times, decisions are made by a few folks and then shared with the team. Ultimately this establishes a culture where folks on the project team become timid, lack enthusiasm, and do not feel vested in the work ahead. This is problematic because we are not getting the most brain power from the team members.

Then along comes Agile. When implemented correctly, the Agile culture places a strong emphasis on team empowerment and ownership. There is little to no command-and-control from management and teams are trusted to make the decisions since they are much closer to the working knowledge and have the experience in that specific area. Team members feel invested in the work ahead because they have a say in the direction of the product.

However, transitioning to an Agile culture does not immediately gain the advantages that you desire. There must be a recognition that managers and some overly directive people need to step back. However, when they do step back, the Agile team membes must step forward to fill the leadership gap. if you want to want to feel invested in your work, you must be willing to own the decisions and work ahead. Otherwise, those people that stepped back will have a tendency (per their natural inclination to be directive) to want to step forward again.

This is where being assertive and proactive becomes important. Some engineers may come from a culture where they are relegated to “getting instructions” and being told what to do. They are not expected to be a leader. With Agile, it is now their job to become self-empowered, become leaders, and take assertive steps forward.

What does this mean in the Agile context? First, as you become part of an Agile project, you must truly internalize that you are now equally part of the team and your thoughts, experience, and opinions matter. This does not happen overnight because the dynamics of getting to an Agile culture takes time. In some cases, there will be those working against you, to sabotage the change in order to maintain the status quo. But make no mistake, it is up to you to step up and assertively empower yourself. Ensure you are weaving your way onto the Scrum team as an effective team member

So next time you don’t think you are appropriately involved on the project or you think you need permission to speak up, stop for a moment. Change your mindset and be assertive, speak up, get involved, become a leader, and start owning the work. Agile provides that opportunity. It is your opportunity to step up.

Agile Animal Farm - Pigs, Chickens, and more

2011-08-26T06:41:00.000-07:00

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 (often management) 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.

I hope you enjoyed these animal 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

2011-08-10T13:14:00.000-07:00

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.

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

Tips for an effective Agile Customer Validation approach

2011-07-23T17:19:00.000-07:00

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 validation, 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 validation approach for the product, which I term the Agile Customer Validation Vision (ACVV), is missing from agile projects—and even missing within the bailiwick of agile practices. This vision is a strategy for identifying the right customers, establishing validation sessions throughout the project, and then motivating the customers to attend the validation 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.

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.

Consider Various Types of Customer Validation

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.

• End-of-Sprint Review/Demo—This is a type of validation 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 validation where customers will exercise the software in a hands-on manner in a simulated or pilot working environment.

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

Once you have established the Agile Customer Validation 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 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!

2011-06-29T15:42:00.000-07:00

To get to a fully robust Agile organization, it is important for everyone to play a role in Agile. I have found that managing a successful project from an Agile perspective requires three core roles and but must include the many adjunct roles to ensure success.

You start with the Agile Team. This is made up of around 7-12 cross-functional team 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), tech writers, and CM/build personnel. The key is to ensure you have all of the roles you need to build a product on your Agile Scrum team with sufficient skills to get the job done. If you need DB talent, UI talent, or other talent, ensure you include them on your team.

Equally important is the role of Product Owner (PO). 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.

The facilitator or servant leader for the team is the ScrumMaster. The ScrumMaster executes the Agile processes and practices, and ensures the team stays true to the Agile values and principles as articulated in the Agile Manifesto. The ScrumMaster helps the Agile Team and Product Owner remove roadblocks. This role also facilitates the Sprint Planning session, the Daily Stand-ups, Retrospectives, and the Agile Release Planning session.

If a project is made up of more than one Agile Team (e.g., for a project team of twenty you would want to break them into two Agile teams of approximately ten), then there is a need for an Agile Project Manager (APM) to manage the dependencies and risks across teams, remove roadblocks, and ensure they work in a concert. The APM also handles the interaction with the business governance of the organization.

In addition, it is important to have an Agile Coach who possesses deep Agile deployment knowledge to ensure the product teams are implementing Agile effectively. It has been established that training will only provide initial knowledge but team members can easily resort back to old traditional habits. The Agile Coach also 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.

Now we come 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 road-blocks, 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.

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).

Then we bring in other peripheral roles like Sales and Marketing, Finance, and HR. While these roles do not need to work in an Agile manner per se, they use the same concepts of 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. If performance objectives are part of the organizations 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.

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

2011-05-29T09:54:00.000-07:00

Sometimes Agile 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 no idea of what Agile really is. Some 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 black eye 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 approaches of Scrum, Kanban, eXtreme Programming (XP), Test Driven Development (TTD), and more, realize fairly quickly that Agile instills much more rigor and discipline than most cowboys can tolerate and more many some folks realize. Some who follow Scrum for instance, learn quickly that there is much more discipline than they originally thought.

One of the early introductions to Agile practices is Sprint (or iteration) Planning. Imagine every two, three, or four weeks you revisit the backlog of work with pre-work of reprioritizing the backlog, then scrubbing each story, sizing the work, and committing to the work. 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. Imagine every day that someone asks you 'what you did yesterday' and 'what you are doing today', and “what are your impediments”. Imagine, every day this is occurring! This starts to get you into a laser focus of the work because you don't want to go for too many days saying you accomplished nothing.

Finally imagine that at the end of each sprint, you have to actually have working software per the end of sprint review (aka, demo). This means that within the end of a two, three, or four week sprint (aka, iteration), you need to build a function into a meaningful and viewable piece of functionality for validation by customers (and you cannot show customers junk, can you?). And to add to this, during the sprint each story (aka, requirement) you work on has to meet the rigorous “done criteria”. Done criteria can imply (for example) that 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 because we are empowered as a team, the discipline ensures we all remain focused on the work. So next time someone says Agile is undisciplined and ad hoc, it is clear that they certainly have never actually done Agile, but more importantly, explain to them the real rigors of Agile and if you have Agile practices occurring, invite them to sit in or participate.

Knowing your Agile Personalities

2011-04-17T22:51:00.000-07:00

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

2011-03-16T09:55:00.000-07:00

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

o Holistic view of Continuous Integration & Build – Part 2 of 9

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

Agile Value Capture Metric - Are you spending your time Building Value?

2011-02-25T15:42:00.000-08:00

When applying an Agile mindset, you should consider the value of each task that you are asking the Agile team to complete. Agile often brings value concepts into play and determining the value of tasks is one way to achieve this. Is the task you are asking the team to do considered value-added or non value-added. Sometimes folks have a hard time wanting to separate tasks into value and non-value because it highlights the non-valued tasks folks are doing. However, if you really want to know, then you must do this (typically at the Product team level).

Keep in mind that in Agile, value-added tasks refer to only those tasks that are directly related to building the product and that your customer values. This would primarily include user stories and the attributes of this work related to the “done” criteria (e.g., incrementally designed, developed, built, tested, etc.) in order to complete the user story. On the other hand, non value-added tasks are those tasks that do not contribute directly to building the product. This may include administrative related tasks, training, all-hands and other status meetings, writing status reports, spending time on correcting defects, tasks related to correcting technical debt (like refactoring), and other tasks not directly related to building the product.

A good practice in Agile (e.g., value capture metric) is to capture all related work a team does in a sprint (as backlog items) to understand what are really value-added tasks vs the other tasks that we do. For each story or backlog item, assign it an attribute of either “value-added” or “non-value-added”. You can track this on a sprint basis (or release basis) or trend it over time (from sprint to sprint). Below are some examples:

Chart 1: Value of work per Sprint (can be rolled up to the release level)

Chart 2: Value of work per Sprint (at the detailed level)

Chart 3: Value of work from Sprint to Sprint (Trend line)

The big advantage of this type of metric is that it helps you 1) be aware of the value and non value related work that your team is doing and then 2) it allows you to make adjustments if you want to get to a more value-added stream of work. While this may force you to make some tough decisions (what is value-added and what is not), it will be worth it in the long run to get your team more productive and focused on the value-added work for your customers. This can help you on your Agile journey!

Configuration Management Crystal Ball - Is Agile in the Forecast?

2011-02-01T09:11:00.000-08:00

As we gaze into the horizon, what do we think will be hot in the CM landscape and where is the CM field headed? Let’s take a look into the crystal ball:

My forecast will focus on:

Agile in the forefront of CM
More CM books to help you Deploy
Extending the CM reach into ALM and beyond

Prediction #1: Agile in the forefront of CM
We will continue to see a strong focus on Agile in the way we approach and deploy CM. Organizations are seeing the benefits of Agile and there continues to be a significant increase in adopting Agile. There continues to be a heavy focus on continous integration and build where teams can take advantage of frequent merging and compiling to ensure their product is integrating, building, and testing correctly. Also, since so many teams are going Agile, CM professionals need to ensure they are in a position to provide a CM environment that maintains the integrity that CM provides but is adapted to the more frequent actions that Agile introduces (more frequent check-outs and check-ins, builds, etc.).

Prediction #2: More CM books to help you DeployConfiguration Management is a field that is pervasive in software engineering. With the shift to Agile comes the need to adapt and change and become lean. These are challenges in the CM community. The good news is that there are newer books on the market that help us address both the deployment of CM as well as the integration of Agile and CM. With that in mind, here are some new CM books as well as blogs that focus on CM and Agile:

“Configuration Management Best Practices: Practical Methods that Work in the Real World” by Bob Aiello and Leslie Sach. The materials in this book are practical, easy to understand, and fully reflects the day-to-day realities faced by practitioners. It addresses all six “pillars” of CM: source code management, build engineering, environment configuration, change control, release engineering, and deployment.
“Adapting Configuration Management for Agile Teams” by Mario E. Moreira. This book provides both a CM Primer and an Agile Primer for those wishing to learn more about each topic followed by a chapter on how they can work well together. It then focuses on infrastructure for Agile and how using the cloud can reduce technical debt. It follows this with a robust chapter on adapting the various CM practices for Agile. It ends with chapters on identifying good tools for Agile (including CM tools) and adapting to standards and frameworks in an Agile environment.

Prediction #3: Extending the CM reach into ALM and beyond
As we continue into the future, we see CM extending into the Application Lifecycle Management (ALM) space and then see ALM extended into a more unified approach. Integration across engineering areas helps teams streamline their processes and reduces the effort of implementation and maintenance of manual integrations. Two such examples of extending the reach include:

Rational Team Concert (RTC) provides a lean collaborative lifecycle management solution with agile and formal planning, project reporting, process workflow, work item management, source code management and build management, in a single integrated product supporting all popular platforms.
Look for innovative tool companies like AccuRev and AnthillPro establish Agile ALM solutions focusing on source code management and continuous integration and build as its core for organizations looking to improve and scale their Agile processes while still maintaining control.

Summary
As we look into 2011, what is the CM forecast and what is your forecast in CM? Agility will continue to show up in various forms in both the Configuration Management (CM) and Application Lifecycle Management (ALM) contexts. Also, books such as “Adapting Configuration Management for Agile Teams” will help CM and Agile teams understand and adapt to Agile methods and books like “Configuration Management Best Practices: Practical Methods that Work in the Real World” to help you deploy CM in a lean manner. What is your organization’s CM forecast? Whether your forecast is sunny or cloudy (or both), consider flexibility, adaptability, and agility in driving your business! Have a productive 2011!!!

Feel free to visit the full article at: http://www.cmcrossroads.com/implementation-excellence/13898-cm-forecast-for-2011. Enjoy!

Sunny with a Chance of Agility

2011-01-14T20:05:00.000-08:00

What is your Agile weather report? Some have sunny Agile efforts ahead. 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?

The theme of my Agile weather report for 2011 focuses on:

Job security with Agile credentials
More structure with Agile deployments
Agile Tooling goes ALM

Prediction #1: Job security with Agile credentials

I predict that we will see a significant growth in software engineering jobs that include an Agile element to them. In general, we are seeing a growth in the use of Agile methodologies and practices in the software industry. Many of the new positions are now mentioning Agile as one of the job requirements. The implication is that they are looking for people who have worked within an Agile context so that when they join the new company, they bring Agile experience.

Prediction #2: More structure with Agile deployments

As product teams become more mature so do their Agile practices. While Agile has been utilized in projects for several years now, it is still new to many. With that in mind, I expect to see more formality in deploying Agile. This is especially true since Agile is no longer a budding trend but maturing where patterns are emerging that lead to more successful Agile deployments. While some would like to say, “Let’s just get started doing Agile”, it may be better to consider a methodical or strategic approach to the deployment of Agile. With that in mind, here are some Agile adoption approaches that may be considered:

Agile Adoption Roadmap by Mario Moreira
Shock Therapy by Jeff Sutherland, et al.
Agile Scaling Model by Scott Ambler

Prediction #3: Agile Tooling goes ALM

As we look into 2011 and the future, we will see more focus on providing comprehensive Agile tooling capabilities within an Application Lifecycle Management (ALM) framework. The value of having an ALM framework is that it allows a product team to manage customer needs from business case development to delivery. When tools support this framework, it can help streamline and reduce the effort in supporting the process. Some examples of tooling that provides an Agile focus in an ALM context include:

Summary
As we look into 2011, conditions could be quite sunny for those companies looking for the Agile edge. What this may mean to those with Agile credentials is that you will gain job security. Since Agile is becoming more mature, continues to prove itself, and can scale to larger product teams and their projects, there will be a need to have more consistent approaches to deploying Agile. There are patterns for success deployments which new teams can take advantage of. And as Agile tooling makes its way into more of an Application Lifecycle Management (ALM) framework, it can provide a more end-to-end view of how business and user needs make their way to delivery. Whether your forecast is sunny or cloudy (or a little bit of both), consider agility in driving your business! Have a productive 2011!

Note: if you want to read the full article from the Agile Journal, go to: http://www.agilejournal.com/articles/columns/column-articles/3529-sunny-with-a-chance-of-agility-agile-predictions-for-2011

Is Agile Mainstream yet?

2011-01-04T13:41:00.000-08:00

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:

There is definitely broad awareness of Agile
There are many companies who are on the Agile bandwagon because it is seems like the right thing to do
There are many Agile “book-read” folks who have not really experienced an Agile implementation
There are some teams who are “cherry-picking” parts of Agile process for their own Agile implementation
There are fewer teams who are applying end-to-end Agile methods and practices across their lifecycle
The companies that have made the cultural shift to the Agile mindset are still a minority

The question becomes, does this really represent a pervasive enough understanding of Agile and a thorough enough adoption of Agile across the industry for it to be mainstream?

IMHO, the answer is not yet. The reasons are that I am not sure if companies have fully "realized" what Agile is and how to implement it. An indicator is whether enough people or teams who have implemented Agile can recognize common steps to a successful Agile implementation. Another indicator is whether those that have implemented Agile have actually made the cultural shift (aka, Agile mindset or self-empowered teams, servant-leader mentaility, etc. ) in order to gain the benefits of Agile and to make it mainstream?

So what do you think?

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

2010-05-31T09:15:00.000-07:00

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. Stay tuned for the next episode where we will focus on the Agile and CM Mindsets 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

Holistic view of Continuous Integration & Build – Part 1 of 9

2010-03-16T21:02:00.000-07:00

As you may know, the term CIB (or continuous integration and build) refers to the process of integrating code frequently (or on-demand) to reduce large integrations, complexity, and pain in the future and to make functional software readily available for testing and the customer. It provides development with immediate feedback on the success or failure of changes via a build and smoke test of the product and reduces large integration efforts.

Continuous integration and build moves the build process moves from an event-based integration process to a continuous integration process. This then moves us 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. And this also marks a significant increase in check-outs, merges, check-ins, and builds.

The benefits of CIB include:

Integration ensures the integrity of your code baseline.
Building frequently lets you and the customer know where things stand as a mark of value delivered.
Continuous integration raises merging issues to the forefront more quickly for more expedient resolution.
Frequent builds have fewer changed files which reduces the amount of time on debugging build issues and painful integrations.
Working functionality provides continuous feedback.
Can be applied to any project methodology (Agile, Waterfall, Hybrid, etc.)

The challenges of CIB include:

It is often easier said than done
It requires a focus on areas broader than most folks realize (beyond just merge and build)
May cause more churn than progress if not managed well
Requires a mindset change, thinking in smaller units, bite-size tasks and continuous change
Moves from event-driven model with ceremony to a continuous change model
Adds stress and load to CM and build tools

So what are some key areas of focus for CIB? Stay tuned for next week’s episode on Elements of Continuous Integration and Build.

2010-02-04T20:11:00.000-08:00

The Knight bringing Agile to the Day

Once upon a time, a Knight challenged the King saying that we should provide people with what they need and not what we want to provide them. Instead of asking people for all of their needs now and not deliver until a year later, we should deliver their more important needs in shorter time periods to ensure we provide them with their needs sooner and then allow them to adapt to their needs as life changes around them.

The Knight learned that the marketplace and the customers therein drove the real needs. This gets to the heart of providing business value, value that the customer perceives, value that can change in this ever-changing world.

As the Agile Manifesto (the Knight's creed) says, Agile values working software over comprehensive documentation. Working software is where the customer sees the value. The “right” amount of documentation, neither too comprehensive nor too little, can lead us to working software more quickly.

Individuals and interactions have more value than processes and tools. This does not mean that processes and tools are not important, it is just that defined processes and tools should not determine how the individuals should interact to get their work done.

Customer collaboration is valued over contract negotiations since Agile values the continuous interaction with customers to ensure we are constantly reducing the risk and increasing the certainty of delivering what the customer really needs.

And finally, responding to change over following a plan allows us to adapt to change with collaborative control that ensures the change is both welcome, understood, and continuously validated.

Agile embraces change and accepts the fact that life is uncertain. By providing methods and techniques to minimize risk and increase certainty, this ensures we close the gap between what the customer actually wants and what we end up delivering.

With that, the Knight brought Agile into the day and people into the light.

Cloudy with a chance of Agility - CM predictions for 2010

2010-01-21T19:15:00.000-08:00

As we gaze in the horizon, what do we think will be hot in the CM landscape and improve our working lives? What might be some of the latest trends in the industry? My prediction is the CM weather report will be “Cloudy with a chance of Agility”. My predictions will focus on:

Agile in the forefront of CM
Extending the CM reach into ALM and beyond
CM “in the Clouds”

Prediction #1: Agile in the forefront of CM

I predict that we will continue to see a stronger focus on agility in the way we approach and deploy CM. This is because Agile methods are continuing to increase in adoption. With the need to adapt and change, comes the need for CM that is both lean, yet well integrated to support the Agile processes. We'll see CM tools cater more to Agile. We'll see more publications focusing on CM and Agile.

Prediction #2: Extending the CM reach into ALM and beyond
As we continue into the future, we will see CM extending into the ALM space and then see ALM extended into a more unified approach. Integration across engineering areas helps teams streamline their processes and reduces the effort of implementation and maintenance of manual integrations. We'll see Agile ALM solutions with CM as its core for organizations looking to improve and scale their Agile processes while still maintaining control. And we may see more holistic unified change and release management solutions

Prediction #3: CM “in the Clouds”
As we looking into 2010 and the future, there may be two focus areas relating to the “Cloud”. The first is ensuring that there is configuration management of the Cloud infrastructure and the second is that there will be more of a focus on hosted CM services in the clouds. Companies are looking for software as a service (SAAS) solutions to limit their infrastructure debt, but these environments also require solid configuration management so the customers of the SAAS solutions can feel confident that changes within these environments will be effectively managed. The second is providing a CM service for software development in the clouds. This way development teams do not need to incur the cost and effort of setting up a CM environment and maintaining it, but instead use a CM environment in the clouds with built in version control, build management, and defect tracking tools that already exist.

Summary
As we look into 2010, conditions may get cloudy but not in the meteorological sense. Companies are looking for “software as a service” (SAAS) solutions to limit their technology debt, but will want to ensure the infrastructure is well managed. Agility will continue to show up in various forms in both the Configuration Management (CM) and Application Lifecycle Management (ALM) contexts. Also, books such as “Adapting Configuration Management for Agile Teams” and blogs will help CM and Agile teams understand and adapt to Agile methods. Whether your forecast is sunny or cloudy (or both), consider flexibility, adaptability, and agility in driving your business! Have a productive 2010!!!

To read the full article on this, feel free to visit: http://www.cmcrossroads.com/cm-journal-articles/13187-cloudy-with-a-chance-of-agility-cm-predictions-for-2010

What are your thoughts on where CM is moving to in 2010?

Book released in the US - Adapting Configuration Management for Agile Teams

2009-12-19T20:37:00.001-08:00

Exciting news! My new book “Adapting Configuration Management for Agile Teams” has recently been released in the US market. It is the first book of its kind that combines discussions on both CM and Agile. Agile is the facilitator of change while CM is the enabler of change. When done properly, CM provides the right level of control for Agile projects to maintain and increase its high level of velocity. CM for Agile can be a very powerful combination when done effectively.

How can it help you? Aimed at all levels of professionals in the Agile, Configuration Management (CM), Project Management, Product Management, and Development fields, this book provides very tangible support for Agile teams. It focuses on how CM with its practices and infrastructure can be adapted and managed in order to directly benefit Agile projects

What are some unique features of this book that can help you?

• Provides both an Agile Primer and a CM Primer. For those experienced with CM, it provides a solid overview on Agile(or visa-versa on CM) so you can come up to speed. It can be great for someone who wants to learn both. It’s almost like a two-for-the-price-of-one book!

• Provides insightful and concrete guidance on adapting CM for Agile methods while maintaining CM principles and allowing minimal structure needed for Agile projects to continue to run fast. Adapting CM for Agile doesn't mean throwing out the CM principles of identification, control, audit and report. Instead it means that CM should be adapted to allow the lean nature of Agile. The question is how do we do this? Inside, learn how to adapt:

o Continuous Integration and Build applying notions of bit-size tasks, right-sizing branches, minimizing merging, emphasizing continuous build, and testing with teeth.
o CM Planning moving away from big-effort-up-front (BEUF) to a more evolutionary approach, applying an iteration 0 to get started, adapting CM roles and responsibilities, and using wikis and other CM formats.
o CM to support more effective Refactoring, Pair Programming, and Test Driven Development (TDD), Traceability, Baselines, Problem Management, CM Audit, and CM Reporting and lean metrics.
o CM support for Distributed Development for Agile teams when co-location is not an option by performing a distributed analysis and considering code access solutions, and supporting a Cloud infrastructure option.
o CM infrastructure for Agile thru implementing CM Envisioning for a brand new product following Agile methods or thru CM Refactoring to adapt CM for an existing product line moving to Agile methods.

• Will help you understand how the more modern CM features help with implementing Agile in an effective manner and that CM tools are a strategic Agile partner.
• Will help you understand how to more effectively support Agile when your organization, product, or project must align with standards and frameworks.

Again the book is called “Adapting Configuration Management for Agile Teams” (ISBN-10: 0470746637). This book is available on both the Agile and Wiley websites. Also, if you want the original CM book which people love as a great CM reference book, feel free to consider, “Software Configuration Management Implementation Roadmap” (ISBN-10: 0470862645).

Have a great day!

How Valuable is Configuration Management to Agile Professionals?

2009-11-26T07:17:00.000-08:00

Being a strong proponent of both Agile and Configuration Management (CM), I was curious to learn if other Agile professionals perceived CM to be of value in an Agile setting. Having worked in both areas for some time, my initial hypothesis was "yes" Agile professionals do value CM. Having recently attended the "Give thanks for Scrum" event, both Ken Schwaber and Jeff Sutherland referenced the importance of builds and control to Agile (a CM component).

Having worked in Agile teams and hearing stories from Agile and CM professionals, I decided to exercise my hypothesis and find out if in fact Agile professionals do find CM tools and processes to be of value in their software development work and at what level. With that in mind, I conducted two studies to determine the importance of CM.

The first study was conducted in both the “Agile Journal” and on “Linkedin” that focused on the importance of CM tools (e.g., version control) for Agile projects. it is interesting to note that this appears to be the first study of its kind. I provided five categories as possible answers to the question: Extremely Important; Very Important; Somewhat Important; Not very Important; and Not Important at all.

The results from this study (based on 208 respondents) was very telling and indicate that CM tools (or at least the version control function) are indeed important for Agile teams working in software development. When combining the number of respondents who answered either “Extremely Important” or “Very Important”, the result was a dramatic 94%. This is quite an amazing number.

This means that 75% of the respondents answering “Extremely Important” and 19% answering “Very Important”.

I wonder if there are any other tools where 75% of Agile professionals would answer as being extremely important to their work. Respondents who answered “Not Very Important” or “Not Important at all” accounted for only 2%. While there were over 200 people who responded, I do not consider this conclusive data. However, it is certainly data to “chew on”.

The second study sought to drill down further as to which CM practices are perceived to be valuable by Agile professionals and which are more valuable than others. With this in mind, I conducted a second survey in the “Agile Journal” where I asked Agile professionals within a polling questionnaire to please place a value rating on each of the following CM functional areas:

• CM Planning (CM for the project including planning activities, roles, etc.)
• Version Control (tool with Check-out/check-in process)
• Build Management (tool with continuous build process)
• Branching and Merging (tool and continuous integration process)
• Change Control (process of managing changes)
• Problem Management (tool and process – a.k.a., defect tracking, issue mgt)
• Audit (process – baseline, etc.)
• Reporting/Status Accounting (process)
• Release Engineering (tool and process – a.k.a., migration and installation)

I provided 10 value choices (from 1 to 10) where 1 is the lowest value and 10 is the highest value. While not meant to be an exact survey, it provided some interesting data.

The results from this study (based on a modest 25 respondents) indicate a range of perceived values for the various CM functions. Build Management received the overall highest average value score with 9.21 (out of 10). This is not surprising since continuous integration and build is a highly valued practice for those who implement Agile. This was closely followed by Version Control which received an average value score of 9.13. This may be because of the recognized need of control due to the high volume of code changes. The high value of the version control function correlates well with the first study where a high percentage of Agile professionals indicated that CM tools (e.g., version control) were either extremely important or very important.

Branching and Merging is next with a score of 8.33. When considering that a big part of continuous integration assumes merging, then this high score is not surprising. Most interesting is Change Control with the fourth highest score of 7.92. In the survey, there was a short description included with Change Control that said “process of managing changes”. With this additional piece of information, it may be that Agile professionals align control of changes with iteration planning where change is periodically managed. While I do not consider this conclusive data, it is certainly data to “chew on”.

The conclusion is Configuration Management (CM) appears to be valued by Agile professionals after receiving a combined score of 94% who responded with either “Extremely Important” or “Very Important” from the first survey. Why this is may be because Agile is a facilitator of change that requires change mechanisms that can handle the high volume of change. CM provides those change mechanisms to ensure the integrity of change on a software project. Being a strong proponent of both Configuration Management and Agile, I am happy to see these results. For Agile professionals who have not yet considered CM as a valuable asset to their work, it may be time to do so now. It may be to your advantage. For Agile professionals who do understand this powerful combination, more power to you and it may be worth giving some of the CM functions a second look.

To see the full study on this topic, feel free to read the article the "Value of Configuration Management by Agile Professionals" found in the November 2009 edition of the Agile Journal found at: http://www.agilejournal.com/articles/columns/column-articles/2506-value-of-configuration-management-by-agile-professionals

The Chicken (CM) or the Egg (Agile)…

2009-10-20T13:10:00.000-07:00

What came first, Configuration Management (CM) or Agile? On the one hand, I've seen articles over the few couple of years that seem to indicate that trend toward Agile creates a new type of CM (e.g., Agile CM) although they seem to be subsiding. On the other hand, I’ve seen CM professionals (CM’ers) adapt their CM practices for an Agile methodology like Scrum.

I think CM'ers have been establishing CM systems that can handle any type of methodology (e.g., waterfall, hyrid waterfall, incremental, or iterative) needed for ages way before Agile became popular. Do you want builds to occur every day, every hour, continuously? It’s a simple cron job edit and now there are specific build tools to help. Do you want to have yearly, quarterly, monthly, or weekly releases? CM can handle that.

Agile certainly can provide a focus on the iterative and incremental nature of a development process by bringing something more tangible to look at sooner than later. This is very valuable. It gets you closer to what you want. Let’s hear from some other CM experts have said on this in the past:

Mark Bools said, “Configuration Management, when implemented correctly, defines interfaces that can be "plugged" into any development process.”

Brad Appleton said, “I agree that CM has always been able to deal with iterative development and frequent (e.g., daily) integration. And I think that when there is misalignment between the two, and development is "Agile", and CM is not on board with the corresponding value-system, then the CM implementation needs to be adjusted (but development needs to "give" some too - it can't be all one way). So, where shops were previously used to non-agile development and non-agile values, when they go to "Agile", the CM implementation will most likely need a big adjustment. it does create a new mind-set for implementing CM in such an enviornment (even if the tools & techniques already existed).”

Bob Aiello said, “CM has been around a long time. Process needs to be as thick (or as my Agile friends say - have enough ceremony) as necessary to get the job done and avoid mistakes. Your process needs to help us get the job done right each and every time without wasting our time on silly practices that happen to work well at the last show that we were in.”

Note: For more on Agile and CM, consider reading the book “Adapting Configuration Management for Agile Teams” found on both Amazon.com and Wiley.com.

What is a CM Tool?

2009-07-21T12:55:00.000-07:00

Does this title sound silly? I mean, doesn’t everyone know what a Configuration Management (CM) tool is? Isn’t a Configuration Management 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. Now the answer to “what is a CM tool” becomes complex.

Agreeing on exactly all of the CM capabilities is not the point. The point is to ensure you are clear on what possible CM (or CM-related) capabilities there are and then deciding which ones are important to you. By first identifying and understanding the capabilities, provides a good starting point to identifying your needs and then further drilling down to capture requirements for a CM tool evaluation. More details on this topic can be found at: http://www.cmcrossroads.com/content/view/12643/120/.

Thoughts? Feel free to share with others.

Infrastructure for Agile Teams - Who are some "in the Clouds" service providers?

2009-05-18T14:17:00.000-07:00

Unlike the past where organizations and product lines spent considerable time and large amounts of capital to establish local infrastructure, the future presents us with other options. They include (but not limited to) renting infrastructure "in the clouds" (e.g., in the internet), owning the server and renting space "in the clouds" (hosting service provider), and owning everything locally and on-premise (within your company). Focusing on "in the clouds", there are several types of "in the Clouds" service providers that allow teams to quickly get infrastructure set for Agile teams.

For those wanting to rent or lease a cloud infrastructure, this is a more recent concept and option that some organizations are utilizing where the infrastructure (servers, software, etc.) is effectively in the internet cloud. This service is sometimes known as cloud computing but have a variety of other names each with slightly different focuses and approaches including software as a service (SaaS) sometimes known as the application service provider (ASP) model, platform as a service (PaaS), application infrastructure provider (AIP). Some companies that provide cloud infrastructure include Force.com, Right Scale, Rackspace, GoGrid, and Caspio Bridge. Not all provide the exact same set of services, but they each provide aspects of cloud infrastructure services. Consider performing a search on “cloud infrastructure” for more service providers.

For those wanting to avoid the cost of having a secure datacenter on premises, then can rent a space in the clouds. Co-location as a service refers to renting space in the clouds by a service provider in order to physically host your server or servers. This is slightly different from cloud infrastructure where you rent a service that provides you access to infrastructure without necessarily knowing the details behind it. For co-location services include ColoSpace, I/O Data Centers, Colocation.com and Peer1 amongst others. They all provide either strictly collocation services or co-location as part of their set of services. Since co-location is most advantageous when the service is within your location, it is best to perform a search on “co-location” and possibly your city or state.

As you consider each of these approaches, take a good look at the amount of your budget, need for control, and even the development methodology you are considering. These factors can help you better evaluate the best infrastructure model that is best for your needs.