Sunday, April 17, 2011

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

Wednesday, March 16, 2011

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.    
· Also consider reading: Adapting Configuration Management for Agile Teams - book by Mario E. Moreira, Wiley Publishing, 2010

Friday, February 25, 2011

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

When applying an Agile mindset, a team should consider the value of each task that they are working on.  Agile often brings value concepts into play and determining the value of tasks is one way to achieve this.  Is the task 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).  Sometimes the answer surprises people.   
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.  Remember, value is from the customer's perspective.  

On the other hand, non value-added tasks do not contribute directly to building the product.  There are tasks that are out-right of no value including administrative related tasks, writing status reports, all-hands and other status meetings.  There are tasks with no direct customer value but have benefit to quality including spending time on correcting defects, tasks related to technical debt, performing refactoring. Please understand, there are levels of internal value in doing these things and the goal is to make the value levels of the work transparent. 

A good practice in Agile (e.g., value capture metric) is to capture all related work or activity a team does in a sprint (as backlog items) to understand what are 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).  This is a team-based metric so it is for the team's eyes only.  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.  Also, an important caveat: this metric is a team-based metric and not meant to be shown to management.  It is for the team to see where their work is being spent.   

Whether you call it value and non-value work, the key is that much like the prioritization of the backlog, that you become aware of the priority of the various types of work that is occurring on your team. This metric also brings transparency to the types of 'work' where the team members are spending their time.  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! 

Tuesday, February 1, 2011

Configuration Management Crystal Ball - Is Agile in the Forecast?

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!

Friday, January 14, 2011

Sunny with a Chance of Agility

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:
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!

Tuesday, January 4, 2011

Is Agile Mainstream yet?

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 mentality, etc. ) in order to gain the benefits of Agile and to make it mainstream?

So what do you think? 

Monday, May 31, 2010

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

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

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

The entrance criteria for an effective and lean continuous integration and build process include:
  • The ability to specify the right ‘bite-size’ level of story or requirements tasks that represent changes that allow for granular and frequent code changes. This implies that the Agile team can understand the stories well enough to divide them up in small and consumable tasks which allow the programmer to make changes frequently and incrementally.
The key components to initiate an effective continuous integration and build process include:
  • Right-size the branching strategy that reduces risk yet ensures code stability where people can work in a stable workspace without being impact by changes of others on a regular basis.
  • Shift in roles and responsibilities of who performs merging and building.
  • Minimize the merge process to reduce work for development
  • Emphasize building in general and understanding the build levels so it is clear who the target of the build is for. Builds can occur within a private workspace and within shared branches like the mainline or project branches.
  • Test with teeth by establishing and conducting unit testing at the individual programmer level and then smoke test after the integration build.
Underneath all of this, there is a need for infrastructure to support a continuous integration and build process. The two primary elements of this include:
  • CM version control system that has the capability of establishing the desired branching strategy, has an automated and intelligent merging capability, and can integrate with continuous integration and build tools.
  • Continuous integration and build tool that supports an automated build process. There are many continuous integration and build tools on the marketing ranging from vendor products to open source and freeware tools.
Let’s delve deeper into each area. Consider reading the next episode which focuses on the Agile and CM Mindsets (Part 3 of 9) and what this means in an Continuous Integration and Build process.

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