A Fast Look at an Agile Scrum Project
Success “come(s) only from continuous effort … “
Napoleon Hill
Chapter Purpose
As an Agile Coach, Agile practitioner, and Agile evangelist
I want to provide a high-level explanation of Agile Scrum methodology
So that readers have a basic understanding of this methodology, and this can lay a foundation for the rest of this book.
Comment: The above is in the format of a User Story. User Stories are very similar to a sentence in a requirements document. They will be discussed in detail later in this book.
Why Agile Scrum is Valuable
Agile Scrum is a process that is used by many companies you would have heard of to guide the creation and delivery of working software to the client community. It is also utilized in many other areas; for example, in creating online training. To me, the top reasons as to why Agile Scrum is well-liked by end users, clients, customers, and organizational leadership are:
• That every 2 to 4 weeks a Retrospective takes place, so the team can continually improve on its ability to perform.
• Requirements (called User Stories) are prioritized, so important features can be delivered to production; fast and first.
• In Agile, a midstream project change request is no harder to process than an initial requirement. This is a key reason why the DevelopmentTeam and TestTeam have no issues with midstream alterations in scope.
• Learning and growth are expected, meaning people have no fear of trying out new or different methods and potentially failing. In fact, agile teams prefer to “fail fast” so that they get to know what they need to confront as soon in the project’s life as possible.
• Agile teams work closely with the ProductOwner as requirements are created. Then, ProductOwner inspects the work-product regularly to confirm what they really want.
• Agile has become the methodology of choice for getting work completed in a number of large, well-respected companies.
• It is my experience that ScrumMasters, at this moment in time, are more marketable than those with only classical project management skillsets detailed on their resumes.
As for the reason why Agile is valuable to me, once I learned enough about Agile Scrum to realize that it was a superior method of having project outputs better match customer expectations, I was hooked.
Formulating an Example Agile Scrum Project
On November 18, 2014, just before Thanksgiving, a fire started in my family’s laundry room. The laundry room was destroyed by the fire, and the rest of the house and its contents were ruined by smoke damage. Below, please find a picture of the fire damage to this room:
As we had practiced fire drills for years when the kids were young, the entire family was outside within moments of my wife, luckily, noticing the fire. The most stressful call I have ever made in my life was the first of dozens of calls to our insurance company. This first call was simply: are we insured? You see, insurance is easy to overlook, until a risk manifests itself as an event. They responded, “Yes, you are insured.” A sense of relief overtook me.
The insurance adjuster arrived at our home the next day, and she confirmed again that we were covered; however, it would be close as to what was insured versus what we would have to pay. She then asked her best cleanup crew and contractor for fixed bids.
The house was vacant for a few weeks while the fixed bids were created. When the estimates came in, the bottom line was that everything was covered except for the family room.
As I have had many years of experience in project management, including a real-estate build-out project (I usually lead IT projects, but, the skills of doing projects is portable between industries), and have a lifetime of experience doing DIY (do it yourself) projects in my home, I took on the role of General Contractor. Now the real story begins; how the project would run in an Agile Scrum environment.
IT Industry Background
About 15 years ago, Waterfall was the mainstay development methodology that companies used for many years to manage projects. That is, when a project was first started, the team would know (in their unique way) when the entire effort was due and almost exactly what they were creating; from the beginning. If a change was needed after a project team was launched, any change required a miniature project to run concurrent with the main effort called a change request. When I worked during this period, all team members had to reapprove everything! That took forever! Then fortunately, many well-known people in the IT industry met face-to-face in 2002 and created the AgileManifesto.org. They created a blending of the best of breed techniques from various methodologies known at the turn of the century. However, the idea of bringing all this great stuff under one umbrella is huge. And when you consider that key members in the IT space actually agreed on anything, this is truly amazing.
To see the stunningly excellent and simple foundation of Agile, just look below:
Manifesto for Agile Software Development
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools.
Working software over comprehensive documentation.
Customer collaboration over contract negotiation.
Responding to change over following a plan.
That is, while there is value in the items on the right, we value the items on the left more.
Kent Beck |
James Grenning |
Robert C. Martin |
Mike Beedle |
Jim Highsmith |
Steve Mellor |
Arie van Bennekum |
Andrew Hunt |
Ken Schwaber |
Alistair Cockburn |
Ron Jeffries |
Jeff Sutherland |
Ward Cunningham |
Jon Kern |
Dave Thomas |
Martin Fowler |
Brian Marick |
|
© 2001, the above authors this declaration may be freely copied in any form, but only in its entirety through this notice |
||
|
||
(The Agile Alliance, 2001)
Example of Using Agile Scrum
So, let us begin with the working example of me redoing a family room which was ruined by the smoke from the fire, and the necessary efforts of the firefighters (800 gallons of water plus one entire wall destroyed!). The hands-on part AgileScrumTeam, that turns User Stories into physical elements of my home, is called the BuildTeam. The BuildTeam is composed of the DevelopmentTeam (they actually create the physical elements) and the TestTeam (they do the testing and quality inspections).
The entire area had to have its drywall ripped out, exposing the 2” × 4” wall studs and concrete floors, and 2” × 10” ceiling joists. Here are some assumptions:
• My wife, our ProductOwner, wants to have the living room restored to the “original” condition and has all the money needed.
• All supplies will be purchased at Home Depot.
• The team will be contractors working using fixed bid contracts. There will be one contract issued for each major User Story.
• A document called a Project Charter has been created for me by my wife as she wants us to not forget anything, and has documented her expectations (like having Pella windows) therein. It is a green-light-letter to get my project started and keep it going with the funds she has set aside for this restoral effort.
As for the roles: I am the ScrumMaster and my wife is the Product Owner. The DevelopmentTeam and the TestTeam will be the hired contractors.
Here is a picture of my family room, taken by my son on the day of the fire. Fortunately, our insurance covered the cleanup, and no one was hurt:
The desk on the left was my desk. Please notice the wall on the right. This wall was destroyed in moments by the firemen so that they could get access to the fire inside the walls. All the furniture was tossed about like it was weightless by the best fire-fighters from about five surrounding counties. By the way, there were 800 gallons of water used to put out the fire, meaning all the electronics (except my backup hard-drive) were trashed. I had no idea these firemen knew how to toss a house about; a huge thanks again to each of them!
I will use the diagram immediately below as our map to using the Agile Scrum method in this chapter. Here is a roadmap of Agile Scrum:
Now, let us start explaining the key points on the example above. Please note that the explanation in this chapter of the Agile Scrum process is at a high level only. A more detailed discussion is held in the later chapters.
A
ProductOwners write the requirements for the project in User Story format. This format is shown at the top of this chapter. Specifically, the underscored and bold’ed part is the template. When they are actually ready to write the User Stories out, this takes place with the help of the ScrumMaster and BuildTeam during a Vision Ceremony.
The team also needs metadata to be attached to the User Story for it to be useful. If you look at User Story CH1 #2, you will find some example metadata attached to that User Story:
• Estimated duration in Story Point format (we will get into Story Points later).
• The key to the User Story it decomposes and keys to any user stories that decompose it.
• A list of any assumptions or risks.
• Etc.
Please find below a handful of example User Stories for the project at hand:
1.
Epic User Story
As a mother, home owner, ProductOwner, and as supreme ruler of the house,
I want my family room restored to its original prefire state
So that I can enjoy the room’s facilities again, as we did before the fire.
Example uses of User Story Examples:
1.1.
User Story ID: CH1 #1
As the ProductOwner,
I want to contract out the hard wood flooring,
So that that we have a human friendly surface to walk on.
1.2.
User Story ID: CH1 #2
As the ProductOwner,
I want to contract out all aspects of the windows, including treatments,
So that the windows look nice and the rays of the sun can be reduced or virtually eliminated.
1.2.1 Metadata for Use Story Ch1 #2: Assumptions and Details
1.2.1.1 We assume the windows are replaced before we start our project
1.2.1.2 We will have thermal pane windows with UV protection
1.2.1.3 We will use Pella brand windows.
1.2.2 Story Point Value: 13 (Story Points are a high-level estimate of duration, assigned by the BuildTeam; this is covered in detail in Chapter 4)
1.2.3 Priority: 1 (Priority is set by the ProductOwner, who understands the business’ prioritization schema.)
…
User Story ID: CH1 #7
As the ProductOwner,
I want safety items added like smoke detectors and fire extinguishers,
So that that we have a safer home.
Please note that metadata was added to CH1 #2 (only) during a Grooming Ceremony. In Chapter 3, metadata will be discussed in full. Also, this Agile Ceremony is very similar to the Initiating process group at the Project Level (PMBOK, p. 69).
B
“B” is the Iteration Planning Ceremony. At this time, the Backlog is populated with prioritized User Stories; the User Stories are sorted based on Priority. The idea is that the BuildTeam takes ownership of User Stories from the backlog. They take the one with the highest priority first.
In the case of our example, the User Story with a priority of 1 is the one that will be worked first; installation of windows. Since this will keep the weather out, it appears this one makes for a great first one to work on.
Also at this time, once a User Story is selected to be worked on, Tasks are created. These Tasks are to hold the information that is needed to create the work-product the task is referring to.
C
In this section of the process, we create detail-designs and code. Once coding is done, user testing is then undertaken. These aforementioned items are the work of the DevelopmentTeam.
While this is going on, the TestTeam creates test conditions and stores them in a Task.
So, to continue the project, this is where windows and window treatments are installed. Also, we will look for the contractor to build a checklist of tests, and will provide proof that the tests were done, and the tests passed.
D
If the TestTeam will execute any Test Plans that are scheduled with respect to any work outside the immediate area that is being worked on. This includes testing like if the windows match the windows upstairs.
E
This is where the Demonstration to the ProductOwner occurs. If there are any User Stories in the iteration that were not previously approved, this is the last chance to have them approved for the current iteration. Approved User Stories in this book are called “Done.”
In this case, my wife the ProductOwner checks out the contractor’s work. And she said all was good.
IF
There are no more User Stories for this project, or the funds run out, or some other reason to stop working on the project….we exit
ELSE
do another iteration.
F
This is where the code for the project is considered “Done.” Once it is ready for end users to use in their day-to-day business processes, it is considered “Done–Done.”
In the case of our project, the move to production blends nicely with the move-back-in date.
Summary
In this chapter, we took a fast, high-level look at Agile Scrum. This was done to lay a foundation for the remaining chapters.
Knowledge Reinforcement
1. 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?
2. The (controversial) Hawthorne Effect indicates that the more the attention given to employees, the harder they will work. During which ceremonies are individuals most likely to show off their work and get attention? And if so, can just scheduling a ceremony increase the likelihood of tasks completing on time as promised?
3. (In Class Activity) The ScrumMaster is like a parent to the team. What characteristic would you look for in a ScrumMaster? Would you expect them to solve every issue and/or problem?
4. (In Class Activity) Assume that you are a general contractor asked to re-do a kitchen. Please create at least five User Stories to support this effort. Please add some metadata to one of your new User Stories.
Reference
The Agile Alliance (2001). “Manifesto for Agile Software Development”, AgileManifesto.org.