Difference between revisions of "Agile"

From BC$ MobileTV Wiki
Jump to: navigation, search
Line 59: Line 59:
* [[wikipedia: Kanban]]
* [[wikipedia: Kanban]]
* [[wikipedia: Kanban board]]
* [[wikipedia: Kanban board]]
* Priming Kanban, 2011 (E-BOOK): http://www.infoq.com/minibooks/priming-kanban-jesper-boeg

Revision as of 15:45, 21 September 2015

Agile is a group of software development methods in which requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development, early delivery, continuous improvement, and encourages rapid and flexible response to change.


"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." [1]


List of Agile Methodologies (the most prominent of which in Software Development is currently Scrum).


Scrum is a new product development methodology whereby a team of talented cross-discipline individuals (almost always under 10, but ideally 3-5). Because of the constantly-changing nature of the Software industry, it is perhaps most commonly used there, but has become popular in all technology-related industries, and even in more traditional or non-technical industries with constantly changing requirements.

All features in Scrum are written from the perspective of the end-user (and thus called "User Stories"). Generate a list of all the required enhancements called the "Must Haves" to support current customers (users) or maintain profitability/operations, then list all necessary features to be added for growth as identified by the executives or business team and put in the "Nice To Haves" and relegate all non-essential functionality updates to a third "Wish List" category; this complete list is the Backlog which needs to be identified into a manageable number of releases over the course of a single year (i.e. release every quarter, release every month). Depending on the frequency of releases, the . The period of time in which an agreed upon amount of work must be completed and fully functional at end of such period is called a single Sprint; each Sprint should be arranged to take place over a consistent period of time, typically 2-weeks (10 business days, 14 days total) but could be anywhere from 2 to 30 days, depending on frequency of release cycle. Estimate the time it will take for each task (card). Estimates are best done in eight time-blocks (where total amount of time for a task must be less than two weeks, using a non-flexible scale where jobs take one of 1h, 2h, 4h, 8h, 2d, 4d, 6d, 8d (and jobs that take somewhere in between get slotted in the time-allocation above; i.e. a 3-hour job gets slotted as "4h" and a 3-day job gets slotted as "4d").

In summary:

  1. ROLES: Executives, Product Owner, Scrum Master (PM), Developers, Testers, Customer
  2. Daily short status/challenges (< 15 min) Scrum Meeting (standing/telephone/videoconf)
  3. Features + Requirements + Wish list = Backlog
  4. Feature & Requirement sub-set (to develop this release cycle) = Release Backlog
  5. Ranked, Sorted and Time/Difficulty-Estimated sub-set of Release Backlog = Sprint (usually 2-weeks)
  6. Each Sprint consists of Tasks (visually represented as Cards), and should be color-coded to denote aforementioned Time/Difficulty Estimate
  7. A graph/chart monitoring progress of Sprints = Burndown Chart (should trend towards 0 or else problems)
  8. Today's Date + Work Remaining(in days) / Rate(tasks completed per day) = Completion Date (of project)
  9. Have a 30-45 minute retrospective after each Sprint to discuss possible efficiencies, improvements or innovations to help work faster


Kanban is a methodology for managing knowledge work with an emphasis on just-in-time delivery while not overloading project team members. In this approach, the process, from definition of a task to its delivery to the customer, is displayed for participants to see. Team members pull work from a queue of items to be done. Kanban in the context of software development can mean a visual process-management system that tells what to produce, when to produce it, and how much to produce - inspired by the Toyota Production System and Lean manufacturing. The name 'Kanban' originates from Japanese[看板], and translates roughly as "signboard" or "billboard", representing the importance of visualization of "work-in-progress" and the workflow for completing individual work items. The primary goal of Kanban is to expose system operation (or process) problems and stimulate collaboration to continuously improve the system. Kanban is rooted in four basic principles:

  1. Start with existing process
  2. Agree to pursue incremental, evolutionary change
  3. Respect the current process, roles, responsibilities & titles
  4. Leadership at all levels

"Kanban Boards" and "Kanban Cards" are two of the more prominent tools which can be used to implement the Kanban method of management for a project. Whereas Kanban (signal) Cards represent demand or capacity, a Kanban Board utilizes magnets, plastic chips, colored washers or sticky notes to represent work items. Each of these objects represents an item in a production process as it moves around the board. Its movement corresponds with a manufacturing process. At its simplest, the board is usually divided into three sections: "awaiting production", "work in progress" and "completed work" (or correspondingly "To Do", "Doing" & "Done").

Lean Startup


The union of and full cooperation between Development (Dev) teams/departments and Operations (Ops) teams/departments, towards realization of a common set of corporate goals, over the entire service lifecycle [of systems], from design through the development process to production support.

[3] [4] [5] [6] [7] [8]




External Links


  1. Manifesto for Agile Software Development: http://agilemanifesto.org/ (by Kent Beck, Martin Fowler et al.)
  2. Towards Compliance as Code using the DevOps Audit Defense Toolkit: http://java.dzone.com/articles/towards-compliance-code
  3. The Essence of DevOps: http://dzone.com/articles/the-essence-of-devops
  4. 8 keys to DevOps success: http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=WH&infotype=SA&appname=SWGE_RA_VF_USEN&htmlfid=RAL14114USEN&attachment=RAL14114USEN.PDF
  5. Blue-green Deployments, A/B Testing, and Canary Releases: http://dzone.com/articles/blue-green-deployments-ab-testing-and-canary-relea-2
  6. Blue/Green Deployment: http://martinfowler.com/bliki/BlueGreenDeployment.html (the A/B Testing of server infrastructure, test your releases in PROD and quickly revert back)
  7. 7 warning signs you need DevOps: http://dzone.com/articles/infographic-7-warning-signs-you-need-devops?oid=devops
  8. 8 Ways to Track the Success of DevOps Teams: http://dzone.com/articles/8-ways-to-track-the-success-of-your-devops-team?oid=devops
  9. 10 Best Free Scrum Tools: http://knowscrum.com/10-best-free-scrum-tools/
  10. http://www.infoq.com/minibooks/kanban-scrum-minibook
  11. PERT Chart example: http://web2.concordia.ca/Quality/tools/20pertchart.pdf
  12. PERT overview: http://www.netmba.com/operations/project/pert/
  13. PERT for Project Planning and Scheduling: http://www.sce.carleton.ca/faculty/chinneck/po/Chapter11.pdf
  14. Critical Path Analysis and PERT Charts - Planning and Scheduling More Complex Projects: http://www.mindtools.com/critpath.html
  15. Minimum Viable Product (MVP) overview: http://practicetrumpstheory.com/minimum-viable-product/
  16. 15 ways to test your Minimum Viable Product (MVP): http://thenextweb.com/dd/2014/11/12/15-ways-test-minimum-viable-product/
  17. Choosing the MVP: http://www.startuplessonslearned.com/2009/08/minimum-viable-product-guide.html
  18. Estimation? It’s Complicated...: http://blog.lunarlogic.io/2015/project-management-estimation/

See Also