Building Agile into your ALM Solution

What is a good application lifecycle management (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

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” 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".
 
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 among 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 non-functional requirements associated with the story)
• 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!

Agile and the Cloud are both pervasive these days.  Agile is a software development method based on an iterative and incremental approaches. Applying an Agile method and mindset can, on the one side, can incrementally build Software as a Services (SaaS) based products and, on the other side, utilize IaaS (Infrastructure as a Service) and PaaS (Platform as a Service) to build the SaaS products and services.

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. 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 people and companies that need that product or service. Companies no longer need local administrators to handle the rigorous and time-consuming effort of establishing on-premise product infrastructure and the installing the software.

When building products for the cloud, a production-ready environment is made available to 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 prior to the installation. Because Agile utilizes an iterative and incremental approach, SaaS products can be incrementally upgraded when the 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 delivers 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. 

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

Agile Culture - Are you Stepping Up?

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 members 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

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

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

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

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

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

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

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

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

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

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

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

Here are few more links to other Agile animal references:

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

Enjoy!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Establish Customer Profiles

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

Identify Personas

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

Motivate Customers to Attend

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

Capture Customer Feedback

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

Consider Various Types of Customer Feedback Loops

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

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

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

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

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

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

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