“Innovation distinguishes leaders from followers.”
Steve Jobs
Chapter Purpose
As an AgileScrumCoach and Agile practitioner,
I will explain the Agile Methodology’s Life cycle,
So that people who want to understand the detail in the steps in the Agile Scrum at a deeper, richer level, can.
Introduction
First, a Ceremony in Agile Scrum is a meeting that is re-occurring, and has a specific purpose. Each ceremony will be discussed in detail in Chapter 3. One aspect of Agile Scrum I personally found confusing while learning Agile Scrum was that I began my journey with a misconception that every aspect of the Agile Scrum process was iterative. As I learned more, I began to realize that there are actually three parts that compose Agile Scrum. The first two below take place on demand, and the last, the “iteration,” is repetitive:
• Visioning
• Grooming
• Iteration
The above three items are discussed below.
Vision Ceremony
The Visioning Ceremony is where the ProductOwner works with the selected members of the Scrum team to capture and refine what is requested. Once the requirement is well understood, the ProductOwner, with the assistance of the team creates a User Story in the correct format (demonstrated at the top of this chapter). What the team needs from the Product Owner before this takes place is for the ProductOwner to explore the needs of all relevant stakeholders and then bring those “asks” forth to the Vision Ceremony.
Organizational Vision is important for the ProductOwner to understand. The purpose and soul of an organization is to strive to fulfill their Vision. The Vision identifies strategic, long-term direction. It defines what the organization should invest effort into, and, acts as a filter to sift out activities that are not within scope. If you look on the Internet, you will notice larger companies post these on their websites. Vision Statements are captured in writing after careful discussions between the leaders of the organization. The vision is important, as if an AgileScrumTeam aligns itself with the organization’s vision, it will necessarily choose to invest time and resources into the types of activities the organization has been carefully constructed to profit from. A short way to think of what a vision statement does is, it defines what is in and out of scope for the organization. The vision is not the only selection criteria to apply to prospective opportunities, but it should be the first filter. Below, please find a brief process map that covers the Visioning. Visioning is the process of creating requirements for the BuildTeam, where the build team is a sub-team of the AgileScrumTeam, and includes the developers and testers of the Agile Scrum team.
• Legal Mandates: Many governmental agencies have an interest in how organizations execute business practices on a day-to-day basis. Be it from not dumping toxic waste into fresh drinking water, not releasing GMOs into our fragile environment, or even following prudent financial measures as spelled out by Sarbanes-Oxley. Legal mandates can be extremely costly if not addressed.
• Executive Pet Projects: Executives have a high-level understanding of what needs to get done. This is because they have access to incredible amounts of well-organized material that their staff provides, and, input from the various nonwork-related organizations they belong to, and often lead. Occasionally, they will launch their own effort that sometimes looks rather bizarre. But, what I have found is that executives get those leadership roles by being smart, and I have also found that once time goes by, executive initiatives start to make sense.
• Innovations: An innovation that will soon play a big role in our lives is the 3D printer. I assume that since it can shoot out live cells, I want to eventually be able to tell a printer to make me a hamburger or pizza. Off the top of my head, the first project I would undertake if I were a factory owner is to identify all factory machine components that can be made on a 3D printer, and which ones would be the best to produce in-house. This would certainly be an example of an effort driven by technology improvements.
• Industry Trends: There is a trend in the airlines industry to rely on finding “black boxes” after a plane goes down. Eventually, the idea of information primarily being stored entirely on the “Black Box” will be eliminated, as the airlines will start storing detailed flight information on the cloud. This could also allow for a detailed analysis of all flights real time, so that even seemingly successful flights could be inspected before they land, or just plain fall out of the sky. Therefore, assuming this look into the future is correct, many airlines would implement this industry trend as it would fall into the notion of Industry Trends.
• Public Good: Some projects are done simply because it is the right thing to do. For example, a company might buy up a few hundred acres of tropical forest in South America to offset their carbon emissions. A project here could be to set up a post to monitor the forest to ensure that it remains healthy and alive.
• Competitive Pressure: Let us say Burger King’s nearest competitor starts selling gourmet coffee at rock-bottom prices. And further assume that Burger King’s experts indicate that it will take years to catch up and employ the competitor’s model. My knee-jerk reaction is to try to dwarf the competition by inviting Starbucks to have a space in key locations. This effort is to bring Starbucks in to select Burger King restaurants. This imagined scenario would be an excellent example of reacting to competitive pressure.
• Risk: This is when there is a possibility that the expected outcome will not match the actual result. Typically, when working on efforts, we focus on the impacts of adverse events. Please see the chapter on Risk for more information on dealing with adverse risk events. I feel obligated to tell you that if your entire AgileScrumTeam wins $600M in a lottery, this is an example of a positive risk event manifesting itself; at least “positive” from the team’s perspective. One needs to have an idea of how to be ready for unimaginable events like this because occasionally they do happen.
• Defects: Algorithms are sequences of meaningful statements, that when executed produce a desired outcome. Defects are statements, or sets of statements, that result in undesired results when algorithms are being executed. What I often see happening is defects getting fixed once discovered, and all other work is set aside. I suggest that if one has a defect in the Agile world, if it can wait, the action to fix it should be addressed through creating a User Story. That way, the defect is prioritized against all other work that needs to get done.
• New Technology: For this one, look at the cell phone industry. Assume there is a new technology that allows a new cell phone apps. to hold memories for humans. I feel a valid assumption that students who need to pass tests would buy into this new technology, and if the activity is within the scope of the vision, it could make for an interesting game changer.
Select Opportunities
Once the universe of opportunities has been inspected to determine activities that pair well with the vision, an initial list of opportunities is created. Then based on how well the vision of the organization is met, specific opportunities will be selected to potentially be worked on, based on priority.
Create User Stories
The Productowner will then format the main ideas of potential projects into “Epic Level User Stories.” Stories will be discussed in detail later, but for now, think of User Stories as a requirement that fits into a very simple, yet powerful template. The template has the items below to fill in:
1. “As a”
2. “I Want”
3. “So That”
Epic-level user stories are be Decomposed into much smaller User Stories that will be of more detail, but of a smaller estimated time commitment. The terminal event of decomposition is when User Stories are eventually broken up into “Tasks.”
Backlog Grooming
Backlog grooming is the process of converting User Stories into a format that the BuildTeam is willing to accept into one of their Agile Scrum iterations. Please find below a short process map that outlines the Backlog Grooming process:
The idea here is to transform the User Stories captured in the previous phase into User Stories that the BuildTeam can focus on. Here is another example of a User Story:
As a big car manufacturer’s president,
I will ask our engineers to create a tire that stinks as bad as a skunk,
So that if the young drivers ever go over 75 miles/hour, then the smell is let loose.
User Stories alone are not enough to get the job done. Metadata (information about other data), will eventually be added to User Stories to provide the needed detail.
Specifically with respect to the Grooming Ceremony, this is where the ProductOwner, ScrumMaster, and selected BuildTeam members review the User Story Backlog. Here is a list of activities during the Grooming Ceremony:
1. Confirm that new User Stories are formatted in User Story format, and also that they are written in a way that a typical reader can understand the intent of the person who originated the User Story.
2. Fill in the appropriate metadata for any new User Stories.
3. Apply “Story Point” estimates to each User Story (Story Points are similar to initial estimates in classic project management. Story Points will be further discussed in the next chapter).
4. Decompose into smaller User Stories any User Story that has too high an estimate. A “high estimate” is one that exceeds the maximum number of days that can reasonably be worked within an iteration. The number of days in this context, to a classical project manager, is called duration. Please see Chapter 3 where “Story Points,” which are an estimate of duration, are discussed.
The output of the User Story Backlog Grooming Ceremony is clean, and, tidy User Stories that fit the User Story format, that have Story Points applied to them.
Iterations
Of the three phases of the Agile Scrum Methodology, the Agile Scrum Cycle is truly where one begins to see the difference between just getting projects done, and, the Awesomeness of the Agile Scrum methodology. The following captures the main idea of the Agile Iteration Cycle:
1. Iteration Planning (Ceremony): This is where the team picks User Stories, from a prioritized list, to work on. Once selected, they are considered committed to the iteration. In the case of the above illustration, the task to work on the drywall is selected to be worked on.
2. Build: This is where the Detail Design, code, and similar elements get created. Estimated hours are calculated by developers at the start of working on a User Story. The estimates are then stored in “Tasks.” Tasks are like User Stories, but they are where work is done from, and they cannot be further decomposed. Before the Build phase is done, the developer is to unit test their work. For those of you with classical project management background, you mentally equate Tasks with “Work Packages” as found at the lowest level of the Work Breakdown Structure (WBS). Though not identical, work packages and Tasks are similar in that they represent the most decomposed effort and house metadata.
In this case, a member of the BuildTeam went to Home Depot and purchased some drywall and necessary tools and supplies. They then did the work to install the drywall.
Unit Test: Developers typically inspect their own code for defects through the use of previously created test cases embedded in User Stories. More advanced Agile Scrum teams will have software to determine if the code meets all known standards.
In this case, the drywall worker looks closely at all the seams to make sure that the seams will not show after paint is applied.
3. Environment Test: This is when testing takes place beyond one module of code. Some examples are system testing, iteration testing, one-up/one-down testing, regression testing, etc. The TestTeam will test multiple applications together to make sure that they “talk” to each other as expected. This is becoming increasingly more mechanized. The real work for the TestTeam at this time is creating effective and efficient test conditions and/or acceptance criteria. More advanced shops will rely on mechanical processes to execute these kinds of tests.
With respect to rebuilding the family room, the areas that the workers were in are inspected to make sure no tools are left behind, and that there is no mess.
4. Demo (Ceremony): The Demo (short for “Demonstration”) is the time that the AgileScrumTeam demonstrates its excellence to the ProductOwner, in a bundle, rather than in parts. To explain, when exercising “continuous delivery” the ProductOwner will only see a small chunk of the iteration’s work-product at a time. The Demo is when all deliverables for an iteration are put on display for the ProductOwner at the same time. In the human mind, if something is displayed in a different way (in this case, seeing the entire work-product for the iteration, rather than one component at a time), perceptual expectations can be deadened, and, the ProductOwner can occasionally look at the bundled work-product in a new light. This means, they will have fuel to create more ideas to convert into valuable UserStories.
For the example, the drywall is inspected by the mother of the house to make sure there are no holes, and that the drywall pieces are attached to each other in a way that they look seamless.
5. Done: This is when the TestTeam declares the code to be working to the specifications laid down by the Test Cases and/or acceptance criteria. “Done” is a term that each ScrumTeam should create a definition for as teams usually have their own definition of Done. This team-specific definition of done should be stored in the team’s Social Contract. To explain, a “Social Contract” is very similar to what Waterfall calls a Project Charter. It contains answers to how an AgileScrumTeam will manage itself.
Our definition of Done, in this case, is when the test cases are successfully addressed, and the mother of the home approves the deliverable.
6. Move to Production: Whenever it makes business sense, and it is safe to do so, code is to be moved into production when it is ready. In practice, it is often wise to target a certain date for releasing code so that everyone outside the AgileScrumTeam who will be impacted by new features and functionality can plan for the arrival of the newest version of the application.
When defects are found in production, under classical project management, there is often a “warrantee” period. When defects are found during this warrantee period, they get fixed with no-charge billed back to the paying customer. In Agile, we recognize that if you pull people off development to work defects, you will reduce the about of new functionality in the next release. So, in Agile, we may have a warrantee period, but it will be structured in a way that defects are to be converted to User Stories, and only worked when they have enough priority to get worked on (as assigned by the ProductOwner, with the assistance of the AgileScrumTeam).
An example of moving this idea to production is allowing limited use of the family room as it now has walls!
Comment: Defects found during an iteration are fixed as part of the normal Aglie Scrum process. If a defect is found after the iteration, it becomes a story and prioritized as part of the product backlog.
7. Retrospective: This is where the entire team meets and determines what went well and what areas need to be improved. As Agile supports a “Fail fast” mentality, people are not to be shy about making a mistake. Rather, they realize that most mistakes are a manifestation of poor process. So, mistakes are called out (but not by person). Once the list of improvements is created, the team examines the list to determine if the stuff that went right can be duplicated or expanded. They also look at what went wrong. The team then decides what is realistic to fix, and once determined, User Stories are added to the User Story Backlog.
This is a great time to buy some pizza and sit on the floor of the newly drywalled room. During the conversation, all people involved in the project identify what went right, and what can be improved the next time. In this case, all agree that the drywall went up fast and neat! Dust from sanding the drywall was noted in some areas. The team notes this in a log, and they decide to hire someone from Service Master (this company cleans up spaces) next time for cleanup as they get the point that drywall installers may not be the best choice for a great cleanup job.
8. Release Complete: If there is no reason to perform another iteration, or, funding runs out for the effort at hand, or all the work is complete, then the Done work is migrated into production. Once work is moved into production, it is called “Done–Done.”
There is one more critical ceremony yet to be discussed. It takes place each working day. It is called the Daily Standup: The daily standup takes place each day. Only people on the immediate Agile Scrum Team are allowed to speak. The agenda of this call is…
A. What is the Burn down Chart telling us? (covered in Chapter 3)
B. Status by Agile Team Member (Each person is given 2 minutes or less to speak)
1) What did I do yesterday?
2) What will I do today?
3) Do I have any impediments?
4) Have I updated my hours in the ALCM?
Comment: ALCM stands for Application Life Cycle Management. It is where all information regarding Agile Scrum projects is stored. It also provides transparency into the health of the AgileScrumTeam and its progress by any interested, authorized stakeholder.
In the case of this effort, the team meets daily for the life of the effort to bring the family room up to speed. While drywall is being installed, the person doing the drywall answers the four questions above.
Summary
In this chapter, we took a good look at the process side of the Agile Scrum Methodology. In the next paragraph, we will look at the various systems that keep this process moving and effective.
Knowledge Reinforcement
1. (Team Project) One night, a chimpanzee named Playful Imp escaped from Brookfield Zoo, in Illinois. Apparently he hid in the baggage compartment of a Mega Bus, and right by your house is where he finally figured out how to escape the luggage compartment under the bus. As it was a nice late spring day, and the temperatures were perfect, you left a few windows of your home open; much to Playful Imp’s delight. As if guided by radar, he quickly finds your hobby room, and utterly destroys all the gadgets, tools, instructions, supplies, etc. that you need to do your hobby. By the time the Playful Imp is brought back to the zoo, there is nothing of use or value in your hobby room any more. Please answer these questions:
a) Identify one of your personal hobbies. Assume it was your house that Playful Imp invaded. Please write the User Story to let all stakeholders know you are working on restoring all the materials in your hobby room. This is referred to as an “Epic” user story.
b) The master User Story is called an Epic. It defines the entire work effort as if written in a Project Charter in classical project management. Epics are decomposed just like organization charts are broken down into finer granularity. Please write two to four User Stories that would be a good decomposition of the Epic story. For those of you with a classic project management background, this is an identical thought process to decomposing the WBS. Please do not feel obligated to identify all the children; just enough to get started understanding the format of a User Story.
c) Identify the metadata for one of the child User Stories. A child User Story decomposes the User Story that it is subordinate to.
2. (Class Project) It has come to my friend’s 23-year-old daughter’s attention that there is snow and ice landing in Texas during the winter! Her idea is to buy a 4-wheel-drive truck and snow plow, and contract with the elite in Texas to keep their streets clear of snow and shovel their driveways. That will keep the snow and ice from bothering these busy, rich people.
a) Please create a vision statement for this business idea.
b) What would the Epic level User Story look like?
c) Create at least four User Stories under the Epic User Story that will help her understand the work that she is going to do.
3. (Team Experience) Identify a hobby that interests you and your team, specifically something that takes at least half-dozen specific tasks to create. Once your team identifies a hobby that is agreeable, please capture the following in a method that works for your learning environment (e.g., PowerPoint, Prezi, poster board, white board, etc.) where your in-class work-product can be shared. Please note, you will not actually do this hobby, rather we are going to work on establishing the infrastructure to work on this effort. Please capture the following:
a) In plain English, what is the hobby you are choosing to work on as a team?
b) In plain English, what are the inputs, processes, and outputs of the effort you will work on as a team for this exercise?
c) What is the Epic level story to capture the essence of the hobby activity your team is about to explore? As a reminder, the format of a User Story uses the template: “As a”….”I want”… “so that.” Also, and Epic level User Story is just like any other User Story except it is expected that the Epic Level User Story will be Decomposed, and it represents an entire effort, not a segment of an effort.
d) Decompose the Epic User Story into three User Stories. Please display your three User Stories that are components of the Epic that visually shows them as a part of the Epic. Ways to do this could look like an organization chart, a mind web, or even an outline format.
e) In order to get experience of a Grooming Ceremony a team, present your results to the entire class. Update your User Stories with their suggestions as appropriate.
4. In your company, do the requirements owners play an active role in the project’s progress after the initial requirements are approved? If not, how would you go about getting more of the attention of the ProductOwner?