Agile Pratices

https://hackernoon.com/antifragile-product-development-39b8d5866b77

Kanban

Kanban is a system where your work moves through various phases, and the amount of work in progress for each phase is limited. Let’s say you have “In Design”, “In Development”, “In Quality Assurance” (QA), and “Done”; and you are capped at 3 tasks in each phase. If you then have 3 items in QA, you cannot move a task to it from Development until you’ve moved an item from QA to Done.

Kanban was developed as part of the Toyota way. If a worker encounters a problem along the assembly line, the car manufacturer allows them to stop the entire line. That way, when one part of the process breaks or bottlenecks, it gets the attention it needs to get fixed. Practices like this helped Toyota dominate the industry. Small errors lead to big improvements in process.

http://agilemanifesto.org/

Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding 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.

http://agilemanifesto.org/principles.html
We follow these principles:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

Business people and developers must work
together daily throughout the project.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

Continuous attention to technical excellence
and good design enhances agility.

Simplicity--the art of maximizing the amount
of work not done--is essential.

The best architectures, requirements, and designs
emerge from self-organizing teams.

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

https://crowdfavorite.com/agile-design-what-weve-learned/


Scrum meeting
https://www.scrumalliance.org/community/articles/2014/july/7-mistakes-during-the-daily-stand-up-meeting

Mistake#1: The stand-up meeting is not a status or recording meeting.

Mistake#7: The stand-up meeting must consist of the three questions.
One by one, each team member started speaking, and, to my surprise, each spoke only about two topics:

1. What they did yesterday. About 30-40% of the time was spent here.
2. What they are doing now (since the stand-up meeting began at 11:00 a.m. and many team members regularly came to the office by 8:00 a.m.). Only 20% of the time was spent here.

None of them spoke about any impediments, obstacles, or risks. No one asked for support from other team members, and no one offered any.

https://www.scrumalliance.org/community/articles/2009/november/daily-scrum-merely-a-status-report
1. What’s been accomplished since the last meeting?
2. What’s going to be done before the next meeting?
3. What obstacles are in the way? 
http://www.corejavainterviewquestions.com/agile-interview-questions/
Agile development acknowledges up front that requirements are malleable and that there will be unknowns. Being able to respond to change and produce a working, valuable system is our primary goal. 

• Iterative development: a minimum viable product is produced to get a system in the hands of the user.  New functionality is added and the system improved using the feedback of users.  This minimises the time between a user requesting a feature and being able to use it live.  In turn this helps to prioritise the features which will add the most value for development next.
• Stakeholder interaction: One of the central tenets of agile lies in the close interaction of development and business, working as partners on the solution. 

• Product Backlog/Planning: The work for the coming weeks or months is written as stories; these are chunks of work which can be usually completed within a single iteration (usually lasting 2 weeks).  Features can be prioritised by the business based on rough sizing (such as t-shirt sizing). Features with higher importance can then be broken down into detailed stories.  Only the work for the upcoming iterations should be well understood with detailed stories, as this reduces the chance of wasted planning because of a change in priorities. Agile embraces change.

• Velocity: By measuring the size of stories (either in time, story points or some other fashion) we can see how many of that unit we can complete each iteration.  A well performing team will “burn down” a similar amount each sprint, allowing for a team to be able to estimate upcoming deliveries with a reasonable degree of accuracy.

Lowercase agile is about actually being agile: flexible, nimble and open to change. This is a rare thing though, as most firms use the formal uppercase Agile.  It has garnered a worsening reputation in recent years.  A lot of people have used the banner of Agile as an excuse for poor development practices; skipping out on design, poor planning, completely abandoning documentation.