Agile Scrum Methodology

 Agenda:

• Introduction
• What is Agile methogology
• What is Scrum?
• Histroy of Scrum
• Functionality of Scrum
• Components of Scrum
• Scrum Roles
• The Process
• Scrum Artifacts
• Scaling Scrums

 Introduction:

• Classical methods of software development have many disadvantages
• huge effort during the planning phase
• poor requirements conversion in a rapid changing environment

What is Agile:

• Agile methods are considered
• Lightweight
• people based rather than plan-based
• Agile methods
• Scrum
• Extreme Programming
• Adaptive Software Development (ASD)
• Dynamic System Development Method(DSDM)
• Agile Alliance(http://www.agilealliance.org/)
• A non-profit organization promotes agile development

Scrum:

• Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
• It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
• The business sets the priorities.  Our teams self-manage to determine the best way to deliver the highest priority features
• Every two weeks to a month any one can see real working software and decide to release it as is or continue to enhance for another iteration

History of Scrum:

• 1995
• Analysis of common software development processes
• Not suitable for unpredictable and non-repeatable processes
• Design of new method: Scrum by Jeff Sutherland & Ken Schwaber
• Enhancement of Scrum by Mike Beedle & combination of Scrum with Extreme Programming
• 1996
• Introduction of Scrum at OOPSLA conference
• 2001
• Publication "Agile Software Development with Scrum" by Ken Schwaber & Mike Beedle
• Successful application of Scrum in over 50 companies
• Founders are members in the Agile Appliance

Characteristics:

• Self-organizing teams
• product progresses in a series of month-long "sprints"
• Requirements are captured as list of items in the list of "product backlog"
• No specific engineering practices prescribed
• Uses generative rules to create an agile environment for delivering projects
• One of the "agile processes"

How Scrum works:

 Waterfall Vs. Scrum:

Scrum Framework:

• Roles
• Product Owner
• Scrum Master
• Cross functional Team
• Ceremonies
• Sprint planning
• Daily Scrum meeting
• Scrum-of-Scrums
• Sprint Review
• Sprint Retrospection
• Artifacts
• Product Backlog
• Sprint Backlog
• Sprint Burndown chart

Product Owner:

• Defines the features of the product
• Decide on release date and content
• Be responsible for the profitability of the product (ROI)
• Prioritize features according to market value
• Adjust features and priority every iteration, as needed
• Accept or reject work results

Scrum Master:

• Represents management to the project
• Responsible for enacting Scrum values and practices
• Removes impediments
• Ensure that the team is fully functional and productive
• Enable close co-operation across roles and functions
• Shield the team from external interferences

Picking Scrum Master:

• Traits of an effective Scrum Master
• Highly committed to the success of the team
• Good people skills
• Good communication skills
• Observant, Good listener
• Courageous mindset
• Proactive, helpful personality
• Technical expertise helpful but not mandatory
• Best results will come from a full-time Scrum Master
• If dedicated person is not available, a team-member will have to play the role, and take a much lighter load of tasks
• Avoid having the team's manager be Scrum Master

Scrum Team:

• Typically 5-10 people
• Cross-functional
• QA, Programmers, UI Designers etc.,
• Members should be full-time
• May be expectations (e.g., System Admin etc.,)
• Teams are self-organizing
• Membership can change only between sprints

Ceremonies:

• Sprint planning meeting
• Sprint
• Daily Scrum
• Sprint Review meeting

Sprint planning meeting:

 


Parts of Sprint planning Meeting:

• 1st Part: (Grooming)
• Creating Product Backlog
• Determine the Sprint Goal
• Participants : Product Owner, Scrum Master, Scrum Team
• 2nd Part:
• Participants : Product Owner, Scrum Master, Scrum Team
• Creating Sprint Backlog

Product Backlog:

• A list of desired work on the project
• List is prioritized by Product Owner
• Typically a Product Manager, Marketing Internal Customer, etc.,
• Requirements for a system, expressed as a prioritized list of Backlog items
• Is managed and owned by Product Owner
• Usually created during the Sprint Planning Meeting
• Can be changed and re-prioritized

Product Backlog Estimation with Planning Poker:

• Estimation of each user story in product catalog can be done as
• size = Effort x Complexity x Uncertainty
• Team make use of poker cards to estimate the user story
• Poker cards can have a
• Fibonacci order (0,1/2,1,2,3,5,8,13,20,40,80,100,∞,?)

Sprint Backlog:

• A subset of Product Backlog items, which defines the work for a Sprint
• Is created by Team members
• Each team has it's own status
• Should be updated everyday
• No more than 300 tasks in the list
• If a task requires more than 16 hours, it should be broken down
• Team can add or subtract items from the list

Sprints:

• Scrum projects make progress in a series of "Sprints"
• Target duration in one month
• +/- a week or two
• But, a constant duration leads to a better rhythm
• Each Sprint begins with the Daily Scrum Meeting
• Product is designed, coded, and tested during the sprint
• NO outside influence can interfere with the Scrum team during Sprint

No Changes during the Sprint:

•  Plan sprint durations around how long you can commit to keeping change out of the Sprint

Daily Scrum:

• Parameters
• Daily
• 15 minutes
• Stand-up
• Not for problem solving
• Three questions
• What did you do yesterday
• What will you do today
• What obstacles are in your way?
• Chickens and Pigs are invited
• Help avoid other unnecessary meetings
• Only Pigs can talk

Sprint Burndown Chart:

• Depicts the total Sprint Backlog hours remaining per day
• Show the estimated amount of time to release
• Ideally should burndown to zero to the end of the Sprint
• Actually is not straight line
• Can bump up

Sprint Dashboard:

Sprint Burndown Chart:

Sprint Review Meeting:

• Team presents what is accomplished during the sprint
• Typically takes the form of a demo of new features or underlying architecture
• Participants
• Customers
• Management
• Product Owner
• Other engineers

Sprint Retrospective Meeting:

• Scrum Team only
• Feedback meeting
• Usually lasts 1-2 hours
• Make 4 lists
• what went well (During the sprint)
• What could have been better (During the sprint)
• Things to try (To do better in the next sprint)
• Issues to escalate (To Upper Management)

Scalability of Scrum:

• A typical Scrum team is 6-10 people
• Jeff Sutherland - up to over 800 people
• "Scrum of Scrums" or what called "Meta-Scrum"
• Frequency of meetings is based on the degree of coupling between packets

Spring framework Instrumentation

Instrumentation is the ability to monitor the level of product's performance, to diagnose errors and to write trace information.

Instrumentation is one of the key features from Spring framework to review application performance.

Spring supports instrumentation through AOP and Logging.

Types of Instrumentation

Code tracing - Tracing the information messages about the execution of an application at run time including:

• Business state changes
• Beginning and end of major business transactions
• Resource creation and deletion
• Events related to performance and reliability
• Logging events
• Monitoring database activities

Instrumenting applications by placing trace statement at relevant locations in code is particularly useful for distributed applications, as diagnosing is an issue that crosses process and machine boundaries is easier when all of the logging information can be collected into a centralized location and stored into a cohesive transcript of single business process.

Spring uses AOP framework to provide tracing and debugging logic to the application.

Performance monitoring - Three forms of performance monitors used in spring framework

• Out of box statistical monitors (CPU, Memory, Network, Storage usage etc.,)
• Custom specific statistical monitors (average time for specific method)
• Custom counters for events of interest (exceptions, cache etc.,)

The out of box statistical monitors are part of open source infrastructure.  These are the primary methods used to monitor system performance of any environment.  We can develop custom performance counters that will provide similar aggregate counters for our application code.  The primary use of these counters is for counting and timing key methods within the application.

Java instrumentation does the following process to count the timings of key methods:

• Takes the current time of the invocation request on the inbound
• Retakes the current time on outbound response
• Calculate the elapsed time as a delta of the two measurements
• Submits the elapsed time of the invocation to the Application Performance Management (APM) system

INSTRUMENTATION APIs

Logging API

Logging API abstracts logging functions from the implementation

Logging API will work as common logging utility for the the application,if we want we can  change the logging implementation at the utility framework to meet with application requirements.

Logging levels 





Where logging is implemented through IoC interceptors such as a Trace logging, an administrator API will be provided to change the interceptor configuration at run time.  This will allow an administrator to enable to disable trace logging at a granular level in the application without restarting the server.

Logging in Clustered environment

In clustered environment log information will be collected and stored in a centralized log server.  With this approach all log information from many servers is brought together into a single location.  Decoupling logging in this manner reduces contention for the single data store and improves logging performance.

Logging in a multi-server distributed architecture can generate a huge amount of logging content from many severs and layers where many disparate items of trace and logging information are created.  The logging solution will collect and store all of this information in one common repository.

Logging in cloud environment

Logging in cloud environment can be exactly the same as local environment except for the publishing mechanism.  The services running in the cloud will use a message queue appender into a local message queue.  The custom publising solution will collect and write diagnostics from the cloud services to the on premises store.

Logging interceptors

AOP enables developers to write code for a cross cutting functionality and then apply it decoratively to existing code.  The IoC framework will resolve services which are wrapped in an interceptor which has the same interface as the service.  The consuming component thinks it's calling the service, but is actually calling the logging interceptor, which then calls the service.

Configuring a logging interceptor

 Logging interceptor class implementation

Logging interceptor class implements three interfaces of Spring AOP framework

MethodBeforeAdvice

AfterRunningAdvice

ThrowsAdvice

Performance API  

Spring AOP provides custom counters for a specific statistical monitoring such as calculating average time taken by a method to complete the transaction.  These statistical monitors will be used for real-time monitoring, alerting, fault diagnosis and informing scaling planning.

Out of box statistical monitors

Java's JConsole can be used for out-of-box statistical monitoring in development and test environment.  It supports CPU, memory, network, and storage usage.

Custom specific statistical monitors ( average time for a specific operation)

Spring AOP provides configuration for performance monitoring, which does not require any changes to existing code.

Spring framework provides a class called "JamonPerformanceMonitorInterceptor" for performance monitoring.

JamonPerformanceMonitorInterceptor is an AOP interceptor that hooks into the framework.

JamonPerformanceMonitorInterceptor configuration

  

autoProxy creator will be created and hooked in the interceptor, which includes the beans for which performance monitoring is required.

Spring HandlerMapping Types

HandlerMapping is responsible for translating a URL pattern to a controller. There are several URL mappers:

• BeanNameUrlHandlerMapping: Maps a URL to a bean based on the name of the controller's bean, as defined in the bean's XML definition.
• SimpleUrlHandlerMapping: Maps a URL to a bean based on a list of properties. (In Listing 2, the SimpleUrlHandlerMapping class is used to map /home.htm to the bean with the ID of homePageController.)
• ControllerClassNameHandlerMapping: Maps a URL to a bean based on the bean's class name. For example, HomePageController would be mapped to /homePage*, such as /home.htm.
• ControllerBeanNameHandlerMapping: Similar to the BeanNameUrlHandlerMapping mapper, but does not expect bean names to follow the URL convention. Also supports Controller annotations.
• CommonsPathMapHandlerMapping: Maps URLs to a controller based on Jakarta Commons Attributes metadata.
• DefaultAnnotationHandlerMapping: Maps URLs to a controller for methods that implement the RequestMapping annotation.