There is no Success or Fail, only Learn

I have been in discussions both in-person and on twitter with colleagues on whether we should use the word “fail” or “learn”.  This was in context to projects (aka, releases, increments).  Did they failed or did we instead learn.  I also realized that the term “fail” is somewhat subjective (e.g., did the whole project fail or just parts of it?).  The overwhelming agreement was that “what did we learn” was a better way to discuss the findings or results. This lends itself to a shift in mindset, to a continuous learning environment that recognizes that there is value even in the negative feedback.   We can learn from that feedback and adapt for better results in the future. 

Then it occurred to me, the term “success” was also a bit subjective.  I recall reading a Standish Group Study where those projects that were “deemed” successful, 45% of the features were never used.  Another 19% was rarely used.  This meant that projects deemed successful built 64% never or rarely used features.  That seems to be a very loose definition of what “success” looks like.  In addition, how many projects are deemed successful because it met the scheduled deliver date yet few customers upgraded to it or bought it?  Is there a benefit to use the term “learn” in place of success?

While it may sound feel like the terms success or fail are the way to traditionally judge a project, release, product, or service, we lose sight of the most important result of the work, the feedback and what we learned from that feedback.   This learning helps us adapt to achieve better results.  If you are working in an Agile context where there are short increments of work, there is the benefit of continuous learning where you can continuously adapt for better business results.

I would suggest in the modern lexicon of work, when a project, release, or increment of work is done, it is much more important to ask what was learned instead of classifying it as a success or failure.  This strengthens the mindset within the organization that there is a value in feedback and the most important thing is what did we learn.  It also emphasizes a discovery mindset where what we think a customer wants is really a hypothesis that must be explored.  It is in the learning that can help us lead to better business results in the future.  So next time people talk about a project as a success or failure, instead turn the discussion around and ask “What did we learn”?  

What happens in the Retrospective stays in the Retrospective!

The Sprint Retrospective is the last event in Scrum occurring at the end of the sprint.  It is a private and safe session for Scrum team members only and facilitated by the Scrum Master. It is used to identify what went well, what did not go so well, and what can be improved.*  It is important to discuss what went well so that you can celebrate successes and when the team feels certain things are going well. 

A sprint retrospective promotes continuous team improvement.  The areas that did not go so well are rated by the team as to which were the most problematic.   The team takes the top 2 or 3 of these problematic areas and identifies the root cause.  Root cause analysis ensures that the real challenge is uncovered so the team crafts a solution that will resolve the problem.  An improvement action is established for each problematic area. Then the team commits to a couple of these improvement actions to be worked on in the next sprint. 

The retrospective is an opportunity for the Scrum Team to reflect on the past sprint’s activities including team dynamics, processes, tools, and culture.  It supports the Agile principle of self-organizing teams.  In order to really get to the nitty-gritty of the problem areas, sometimes “dirty laundry” needs to be discussed. This includes taking a hard look at the problems.  

In order for the team to feel comfortable in airing problems, the team needs to feel that they can trust each other.  Team members must believe they can discuss problems knowing that anything said will stay in the room.  If what is discussed in the retrospective gets communicated outside of the room, folks on the team will be less likely to raise and discuss problems.  And discussing and resolving problems is what the retrospective is all about.  This is why it is important to discourage outsiders, particularly any managers of the team members from attending these sessions.  When outsiders attend, you often see far fewer real problems get raised.  Outsiders may not understand the context of why a team made a decision or did something a certain way which can lead to inappropriate judgments.

The retrospective only has value when the team discusses problems in a sincere manner, has a safe environment to discuss problems, and provides a strong commitment to resolving the problems to the benefit of the whole team.  So keep all of this in mind when you hold a Sprint Retrospective and remember, what happens in a retrospective stays in a retrospective!

* An alternative approach is to discuss what we should stop doing, continue doing, and start doing.  

Scientists Find evidence against Big Bang and for Continuous Adaptation of the Universe

The earliest phases of the Big Bang are subject to much speculation.  In a new revelation by leading Quantum Scientists from CERN, they surmised that the universe had used more of an adaptive approach. In re-investigating Vesto Rugby's study that measured the first Doppler shift of a spiral nebula, they found evidence that an adaptive approach was used to in the expansion of the universe. 

Further investigation found the singularity known as Big Bang, was really a series of cosmic inflations that align with a plurality approach that caused the universe to iteratively unfold.  While initial observations best fit the theory of Big Bang, after the discovery of cosmic microwave radiation, this promoted a continuous epoch approach where spectral waves align much more clearly with an adaptation of wave expansion. 

This came to the attention of the Agile Alliance.  They are now backing the scientists and aligning with the newly termed Continuous Adaption theory of the universe.  They recently supported the Evolution of the Species Theory promoted by Darwin.   The Agile Alliance says continuous, adaptive, and iterative are all components of Agile and now believe that Agile is really the essence of the universe.  The Alliance is now in funding NASA and CERN research in their Agile endeavor.    

April Fools...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

CM Mindset

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

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

Agile Mindset

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

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

The “Continuous” Mindset Shift

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

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

Moving from Event-Driving to Continuous

In an Agile context, what we see in CM and the build space is a fundamental shift in the way we build software.  The build process moves from an event-based integration process to a continuous integration process. In other words, no one needs to hold onto large amounts of changes for a major integration effort or declare that builds will occur nightly, weekly, even hourly.  There is no ceremony needed.  We move away from the infrequent and often painful integrations (a.k.a., merges) and move to an integration and build process that becomes part of the team’s daily activities. 

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

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

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

References

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

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

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

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

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

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

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 an integration, full build, and smoke test of the product and reduces large integration efforts.

Continuous integration and build moves the build process 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 a continuous integration and build process that becomes part of the team’s daily activities. 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 elements of focus for CIB?  Learn about these elements in part 2 of the CIB series on Elements of Continuous Integration and Build.