Scrum – An Insight

Scrum is an iterative and incremental agile software development framework for managing product development. Scrum adopts empirical approach i.e. problems cannot be fully understood or defined, focussing instead on maximising team’s ability to deliver quickly and respond to emerging requirements.

Three pillars uphold every implementation of empirical process control:

  1. Transparency: Significant aspects of process must be visible to those responsible for outcome.
  2. Inspection: Must inspect frequently progress towards sprint goal to detect undesirable variances.
  3. Adaptation: Must adapt when a process deviates from the acceptable limits.

Scrum is a simple framework for effective team collaboration on complex projects. Scrum provides a small set of rules that can create just enough structure for teams to be able to focus on their innovation on solving what might otherwise  be an insurmountable challenge.

Building complex products for customers is inherently difficult task.Scrum at its core is governed by three primary roles:

  1. Product Owners: Defines what needs to be built.
  2. Development Teams: Builds and Demonstrate to Product owner and based on this PO decides on next sprint.
  3. Scrum Masters:  Ensures the process happens as smooth as possible and continually help improve the process, the team and the product being created.

Scrum Events:  Following events are used to create regularity and to minimise the need of meeting not defined in scrum. All events are time boxed, once a sprint starts it cannot be shortened or lengthened. Each event in the scrum is formal opportunity to inspect and adapt.

    1. Sprint: The heart of scrum which is less than a month and during which a “Done”, usable potentially releasable increment is created. A new sprint starts immediately after the conclusion of previous sprint. Sprint contains of sprint planning, Daily Scrums, Development, Sprint Review and Sprint Retrospective. A Sprint can be cancelled before time box is over by only Product Owner.
    2.  Sprint Planning: Its a time-boxed activity where team collaboratively decides the amount of work to be performed.
    3. Sprint Goal: Its an objective set for the Sprint that can be met through implementation of product backlog. Selected product backlog items deliver coherent goal.
    4. Daily Scrum: Its a 15 minute time boxed event for development team to synchronize activities and create plan for next 24 hours. Daily scrum is held at same time and place every day to reduce complexity. During scrum team explains following questions:
      What Did I do yesterday?
      What I will do today?
      Do I have any impediment?
    5. Sprint Review: Its held at the end of sprint to inspect the increment and adapt the product backlog if needed. This is four hour time boxed meeting in a sprint of one month. The result of review meeting is revised product backlog that defines probable product backlog for next sprint.
    6. Sprint Retrospective: Its an opportunity for scrum team to inspect itself and create a plan of improvements to be enacted during the next sprint. It occurs after sprint review and next sprint planning. This is three hour time boxed meeting for one month sprint.

1000px-Scrum_process.svg

  • Product Backlog: Its a way to express ordered list of requirements for a product. It can be expressed as user stories, use cases, features, bugs etc. Product owner maximizes the value of the product and work done by development team.
  • Sprint Backlog:  Its the list of work development team must address in next sprint. Development team should keep in mind its past performance before taking up the new work. Product back log are broken down to tasks by the development team. Tasks are never assigned but picked up by the team members using self organisation. Scrum_task_board
  • Sprint Burndown Chart: Its publicly displayed chart showing remaining work in the sprint backlog. Its updated every day and gives simple view of sprint progress. SampleBurndownChart
  • Release Burn down Chart: Publicly displayed chart showing remaining work to complete target commitment for a product release. Its updated every sprint.
  • Definition of Done: Specified criteria by the team when to accept work as completed. It includes unit testing, reviews, functional testing, user acceptance testing etc.
  • Definition of Ready:  Specified criteria when a story can be picked up from backlog item. It includes backlog item written, user experience included, acceptable criteria defined, dependency defined etc.
  • Velocity: Its the total effort a team is capable in a sprint.
  • Spike: Time box period used to create simple prototype after research. Spikes are often introduced before large projects. Unlike sprints spike may not deliver tangible, shippable, valuable functionality.
  • Impediment: Anything that prevents team member to perform as efficiently as possible.
  • Tasks: Work items added into sprint backlog at the beginning of sprint and broken down in hours.
  • Tracer Bullet: Its a spike with current architecture, technology and results in production quality code. Often these implementations are quick shot through layers in tech stack.
  • Backlog refinement(grooming): Its a process to keep refining the backlog so that it gets properly prioritised and makes them clear for the team as they enter sprints.
  • Scrum of Scrums:  Its a technique to scale scrum to large development groups. Each scrum team designates ‘ambassador’ which has daily stand up with all ambassadors from other teams. Depending on the context ambassadors may be Scrum master or technical team member
  • ScrumBut: Customised scrum for the team.

 

 

Agile Software Development

Agile means quick and this new software development promotes agility by adaptive planning, evolutionary development-delivery and time boxed iterative approach. Agile Manifesto was introduced in 2001 and since then it has taken over software engineering and development.

Agile Manifesto is as follows: Uncover better ways of developing software by doing it and helping others to do it by using following values:

  1. Individuals and Interactions over Processes and Tools. – ( Co-Location & Pair Programming)
  2. Working Software over Comprehensive Documentation. -(
  3. Customer Collaboration over Contract Negotiation. -( Continuous customer involvement)
  4. Responding to change over Following a plan. (quick responses to change & continuous development)

Agile Manifesto is based on following principles:

  1. Customer satisfaction by rapid delivery of useful software.
  2. Welcome changing requirements, even late in development.
  3. Working software is developed frequently.
  4. Close, daily cooperation between business people and developer.
  5. Projects are built around motivated individuals.
  6. Face2Face conversation is the best form of communication.
  7. Working software is the principle measure of progress.
  8. Sustainable development, able to maintain constant pace.
  9. Continuous attention to technical excellence and good design.
  10. Simplicity – art of maximising the amount of work not done is essential.
  11. Self Organizing teams.
  12. Regular adaptations to changing circumstances.

There are various ways by which agile development has been propagated which includes Scrum, Kanban, Lean Software development etc. All agile ways follow certain agile practices like:

  1.  Backlogs – Ordered list of items maintained for a product.
  2. Cross-Functional Teams - self directed team with expertise from different departments.
  3. Information Radiators – Kanban Boards, Scrum Boards, Burndown charts, Task board are examples of information radiators.
  4. Pair Programming – Two programmers work together in a workstation.
  5. Planning Poker – Consensus based technique for estimating.
  6. Agile meetings – Sprint planning, Daily Standups, Review and retrospective meetings.
  7. Time Boxing – Allocates a fixed time.
  8. Velocity Tracking – Capacity planning tool, an act of measuring said  velocity of team.

Common agile pitfalls:

  1. Adding stories to  a sprint in progress: User story can be expanded but cannot be added, in worst scenario terminate the sprint.
  2. Lack of sponsor: Agile works from grassroots and without having sponsor its bound to fail.
  3. Insufficient training: Agile doesnt mean no rule but a proper training is must for prescribed methodology.
  4. Product owner not defined: With internal member taking product owner role will lead to finger pointing and breakdown of collaboration.
  5. Teams not focussed: Its expected resources to take up task potentially outside their service area.
  6. Excessive planning: Teams fall into trap of over understanding of all stories with detailed design.
  7. Problem solving in daily standup: daily standup is focussed meeting to disseminate information to all team members not to solve problems.
  8. Assigning task: If team members are assigned tasks than benefits of localised and timely decision making can be lost.
  9. Scrum-master as contributor: Not prohibited but multitasking may result in too many context switches to be productive.
  10.  No Test Automation: due to iterative nature of agile test automation is often a must.
  11. Letting Technical Debt to build up: Technical debt hinders planning as production defects distracts the team from further progress. As system evolves its important to refactor.
  12. Attempting to take too much: Team decides how much to work, pressurising will increase inefficiencies in delivery.

Software Design Patterns – An insight

Design Patterns are reusable solutions to the problems software architecture faces regularly.  Patterns must explain why the solution provided is the best amongst the equals.

Most popular 23 Gang of Four patterns are considered to be the base of all patterns.  These patterns are categorised in three groups:

1. Creational Patterns: These patterns help create object for you, hence giving flexibility in making decision for a given case.

a. Factory method: Creates an instance without specifying the exact class. It lets defer instantiation to subclasses.factory

 

b. Abstract Factory: It helps create several families of classes. Provide an interface for creating families of related classes without specifying there exact class.abstract

c. Builder : It help separate complex construction from representation and hence allowing same construction process to create multiple representation. builder

d. Prototype:  It helps create objects by cloning existing objects. prototype

e. Singleton : Restricts object creation to only one single object.singleton

f. Object Pool: Avoid expensive creation and deletion of resources by recycling objects that are no longer in use. Object_pool

g. : Multiton : Its an extension of singleton class objects by keeping key value pairs.cls-utl-multiton

2. Structural Patterns: These patterns help structure object composition using inheritance.  By achieving different object composition they attain new functionality.

a. Adapter: Matches interfaces of incompatible classes by wrapping up its own interface around. adapter

b. Bridge: It allows decoupling of interface with its implementation, so that two can vary independently. bridge

c. Composite: Composes one or more similar objects to represent part-whole hierarchies. It lets client treat individual objects of the whole composition uniformly. composite

d. Decorator: It dynamically adds features on an existing object. It provides a flexible alternative to sub-classing for extending functionality.

decorator

e. Facade: Provides a simple interface for a large subsystem. facade

f. Flyweight: It reduces the cost of creating and manipulating a large number of similar objects. flyweight

g. Proxy: Provides a surrogate for another object to control access, reduce cost, and reduce complexity.proxy

 

h. Front Controller : It provides centralized entry point for handling requests. Its mostly for Web Applications. FCMainClass

i. Module : Group of related classes, methods into single conceptual entity. Module-software-design-pattern

3. Behavioral Patterns: These patterns resolve communication issues with objects.

a. Chain of Responsibility: Delegates the command to chain of processing objects and hence avoid coupling the sender of request to receiver. chain

b. Command: Creates request that encapsulate actions and parameters hence let us do undo-able operations.command

c. Interpreter: It lets us define grammar of specialised language. interpreter

d. Iterator: Sequentially access elements of an object without exposing its internal representation. iterator
e. Mediator: Promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently. mediator

f. Memento : Allows undo operation by capturing and restoring its original state. memento

g. Observer: Publish/Subscribe pattern that allows various objects to see an event. observer

h. State : It allows changing of behaviour of an object when its internal state changes. state

i. Strategy: It allows one of the family of algorithm to be selected in the runtime. strategy

j. Template: Defines skeleton of the algorithm as base classes, letting subclass define its concrete behaviourtemplate

k. Visitor: It lets you define new operation without changing the classes of the elements. It separates an algorithm from its object structure by moving the hierarchy of methods into one object visitor

L. BlackBoard: Generalized observer, which allows various readers & writes, distributes information system wide. Blackboard

M. Null Object: Provides a surrogate for another object that shares the same interface but does nothing. nullobject

O. Servant : It separates out common functionality from a group of classes.  It implements some functionality which is common to group of classes and is not defined in them. servant

P. Specification Pattern: Outlines business rule that is combinable with other business rule. A unit of business logic inherits its functionality from abstract aggregate composite specification. Specification_UML_v2

 

 

Apocalypse of Technology