Agile Scrum Fundamentals
Top Fortune 500 companies that uses agile
Some of the most well-known companies in the world use an Agile approach to improve their processes. To name a few, Amazon, Spotify, IBM, Cisco, Microsoft, AT&T, Tesla, NASA, Google, Apple, Facebook, Yahoo!
Why Agile?
The Agile methodology is one of the fastest-growing approaches that software development companies have been adopting lately. The Agile method has been proven to be of immense help in assisting companies to create successful products. This is mainly because of how focused Agile is on teamwork and how much importance it gives to customer satisfaction.
Creating project roadmaps and continuously evolving it with the changing needs of the consumer is another reason why Agile projects are so successful.
Who are the creators of Agile Scrum?
Both creators of Scrum, Jeff Sutherland and Ken Schwaber, fought in the Vietnam war between the years 1967 and 1975. Necessary everyday risk assessment already influenced their way of thinking and naturally affected their later work. Next, they followed similar career paths and stayed in touch.
January 1994: first Scrum team is scrumming
In 1993 Jeff Sutherland was hired into Easel Corporation as Chief Engineer for developing a new product. At the time, they didn’t know what exactly they wanted, but they knew it had to be something faster and better than what is already on the market. Knowing this was a huge challenge, he and the team first reviewed the literature to see what was already done and what could be taken beyond.
Jeff Sutherland invented Scrum in 1993 and worked with Ken Schwaber to formalize Scrum at OOPSLA’95. Together, they extended and enhanced Scrum at many software companies and helped write the Agile Manifesto.
They found, according to Sutherland, the best paper in Harvard Business Review, The new new product development game (not a typo, authors chose to emphasize the word new) by Hirotaka Takeuchi and Ikujiro Nonaka. A paper showing a new, holistic approach to product development. Authors of this paper compared the new approach to a rugby game — team moving down the field in a scrum formation as a unit. This paper provided Sutherland with a formal model and the name for a new framework created for the IT industry: Scrum.
Agile development is a term that was derived from the Agile Manifesto.
The manifesto details four core values for enabling high-performing teams.
Agile Values
- Individuals and their interactions
- Delivering working software
- Customer collaboration
- Responding to change
Individuals and Interactions
Individuals and interactions are essential to high-performing teams. Studies of “communication saturation” during one project showed that, when no communication problems exist, teams can perform 50 times better than the industry average. To facilitate communication, agile methodologies rely on frequent inspect-and-adapt cycles. These cycles can range from every few minutes with pair programming, to every few hours with continuous integration, to every day with a daily standup meeting, to every iteration with a review and retrospective.
Just increasing the frequency of feedback and communication, however, is not enough to eliminate communication problems. These inspect-and-adapt cycles work well only when team members exhibit several key behaviors:
- respect for the worth of every person
- truth in every communication
- transparency of all data, actions, and decisions
- trust that each person will support the team
- commitment to the team and to the team’s goals
Working Software over Comprehensive Documentation
A software development team’s focus should be on producing working products. The second Agile core value emphasizes working software over comprehensive documentation.
On projects using agile management tools, the only way to measure whether you are truly done with a product requirement is to produce the working product feature associated with that requirement. For software products, working software means the software meets what’s called the definition of done: at the very least, developed, tested, integrated, and documented. After all, the working product is the reason for the project.
On a traditional project, if you’re 75 percent done, you don’t have any working software to give the customer — “75 percent done” traditionally means you’re 75 percent in progress and 0 percent done. On an agile project, however, if you’re 75 percent done, you have working product features for 75 percent of your project requirements — the highest-priority 75 percent of requirements.
All projects require some documentation. On agile projects, however, documents are useful only if they’re barely sufficient to serve the design, delivery, and deployment of a working product in the most direct, unceremonious way. When you work on an agile project, however, you concentrate on the documents necessary to support product development. Agile approaches dramatically simplify the administrative paperwork relating to time, cost control, scope control, or reporting.
Customer Collaboration over Contract Negotiation
The third value of the agile manifesto is Customer collaboration over contract negotiation. This value stresses the importance of encouraging your customers and development team to collaborate to chart the best way forward together, rather than to view each other as adversaries.
Customers are important, but what about contracts? They are important as well. But the issue comes when instead of collaborating with our customers we end up spending most of the time negotiating contracts.
Responding to Change over Following a Plan
For teams to create products that will please customers and provide business value, teams must respond to change. Industry data shows that over 60 percent of product or project requirements change during the development of software. Even when traditional projects finish on time, on budget, with all features in the plan, customers are often unhappy because what they find is not exactly what they wanted. “Humphrey’s Law” says that customers never know what they want until they see working software. If customers do not see working software until the end of a project, it is too late to incorporate their feedback. Agile methodologies seek customer feedback throughout the project so that teams can incorporate feedback and new information as the product is being developed.
Agile Methodology: Incremental and Iterative way of development
Incremental software development entails delivering finished components of the whole in parts. It allows you to stagger the release of features which are of utmost value to customers.
Iterative software development allows for instant feedback at multiple levels of the product development process. For example, for developing a food delivery app the customer was first presented with a wireframe version of the app and feedback was taken. The subsequent steps followed the same pattern where feedback was taken and incorporated.
The Agile methodology incorporates both incremental and iterative product development processes.
Agile Vs Scrum?
If your refrigerator were to break, you would go to an appliance store and be shown various refrigerators.
You might see refrigerators from Maytag, General Electric, Viking, Whirlpool, Frigidaire, SubZero, Bosch and so on. You would leave the store, let’s say with a Maytag, because its unique features best fit your needs. In the same way that Maytag is a brand of refrigerator, Scrum is a brand of agile.
User Stories: Making the Vertical Slice
One of the challenges we continually observe is that Scrum teams struggle with in their Agile adoption is the concept of vertical story slicing.
As described by Wikipedia a vertical slice “refers to a cross-sectional slice through the layers that form the structure of the software code base.” For example, a simple vertical slice would encompass the data access layer, the business logic layer (a.k.a. middleware layer) and the user interface layer. A vertically sliced story should also encompass the testing that corresponds to the functionality being delivered.
Vertical slicing is intimidating to teams when they first experiment with it. Even teams that understand it conceptually often struggle with decomposing their stories small enough while still achieving a vertical slice. Consequently, teams revert back to their old habits of creating user stories that are horizontally sliced.
For example, they’ll define one story to create a web service, another story to create a database table, and yet another story for testing. These so-called stories, are actually tasks. Horizontal stories typically do not meet a well-formed story structure of “As a <role>, I want <functionality>, so that I can achieve <value/outcome>” and they don’t meet the INVEST criteria (Independent, Negotiable, Valuable, Estimable, Small, Testable).
For example, I want to build a site that sells shoes.
My features might be:
Display informative Home screen
User Registration
User Login
Display Products
Display Shopping Cart
Add products to Shopping Cart
And then, User stories would be developed off those:
Display informative Home screen
- As a User, I want to access the Home scree, so that I can enter the website
- As a user, I want to be able to see specials, so that I can see the current deals
User Registration
- As a user, I need to be able to register as a new user, so that I can have more access to the site
- As a user, I want to be able to register with my Google account
User Login
- As a user, I need to be able to login with my username/password, to gain access to the site
- As a user, I want to be able to login with my Google account, to gain access to the site
Display Products
-
Display Shopping Cart
-
Add products to Shopping Cart
-
etc etc.