Agile Manifesto
In 2001, a group of 17 programmers who work in IT Programming and interested in Iterative and agile methods met in Snowbird, UT to develop common framework for what is meant by Agile methods. This group has created the Agile Manifesto.
Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. 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.
Items on left are considered value drivers while the items on right are generally management controls for software development. Many members consider that Agile is a project management approach rooted in programming parlance while traditional waterfall approaches (PMP) are rooted in management parlance.
Agile Principles
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity–the art of maximizing the amount of work not done–is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Agile Team Roles
1. Programmers, designers, architects: How to design and program the software
2. Product managers: Why the software is important
3. Domain experts (SME): The rules to be followed by software. Must follow industry standards like regulatory etc.
4. Interaction designers: How the software should behave (Understand users, needs, how they interact with software etc)
5. Graphic designers: How should user interface look like
6. Tester: Where are defects likely to be found
7. Project manager: How to interact with rest of the company (read Politics)
In many ways, the traditional project roles still exist in an Agile project, but in a modified manner for a modified purpose.
Agile Artifacts
An artifact is a document or a chart to manage an Agile project 1. Sprint burn down chart: The sprint burn down chart is a publicly displayed chart showing remaining work in the sprint backlog as the spring progresses. 2. Product backlog: The product backlog is a high-level list that is maintained throughout the entire project. It aggregates backlog items: broad descriptions of all potential features, prioritized as an absolute ordering by business value based on various metrics to be determined by the project team (For example provided by www.unleashpm.com). It is therefore the “What” that will be built, sorted by importance. It is open and editable by anyone and contains rough estimates of both business value and development effort. Those estimates help the Product Owner to gauge the timelines and, to a limited extent prioritize. The Product Backlog, and business value of each listed item is the property of the product owner. The associated development effort is however set by the Team. 3. Sprint backlog: The sprint backlog is the list of work the team must address during the next sprint. Features are broken down into tasks, which, as a best practice, must be 4-8 in any given sprint. With this level of detail the whole team understands exactly what to do, and potentially, anyone can pick a task from the list. Tasks on the sprint backlog are never assigned; rather, tasks are signed up for by the team members as needed, according to the set priority and the team member skills. This promotes self-organization of the team, and developer buy-in. The sprint backlog is the property of the team, and all included estimates are provided by the Team. Often an accompanying task board (For example provided by www.unleashpm.com) is used to see and change the state of the tasks of the current sprint, like “to do”, “in progress” and “done”.
Daily Agile Meeting or Stand up Meeting
On each day of a sprint, the team holds daily meetings in a stand up position for about 10 minutes (“the daily Agile meeting or a stand up meeting”). Meetings are typically held in the same location and at the same time each day. Ideally the daily Agile meetings are held in the morning as they help set the context for the day’s work. All team members are required to attend the daily scrum but will not be postponed if someone is not in a position to attend. Since both the Project Manager and Product
Owner are committed team members, they are expected to attend and participate. Anyone else (for example, Head of the department, a salesperson, or a developer from another project) is allowed to attend but are there only to listen. This makes the daily Agile an excellent way for an Agile team to disseminate status information–if you’re interested in hearing where things are at, attend that day’s meeting. The daily stand up meeting is not used as a problem-solving or issue resolution meeting. Issues that are raised are taken offline and usually dealt with by the relevant sub-group immediately after the meeting. During the stand up each team member provides answers to the following three questions: 1. What did you do yesterday? 2. What will you do today? 3. Are there any impediments in your way? By focusing on what each person accomplished yesterday and will accomplish today the team gains an excellent understanding of what work has been done and what work remains. The stand up meeting is not a status update meeting in which a boss is collecting information about who is behind schedule. Rather, it is a meeting in which team members make commitments to each other. If a programmer stands up and says “Today I will finish the user information generation template” everyone knows that in tomorrow’s meeting he will say whether or not he did finish. This has the wonderful effect of helping a team realize the significance of these commitments and that their commitments are to each other, not to some distant customer.
Any impediments that are raised become the Project Manager’s responsibility to resolve as quickly as possible.
Typical impediments are:
• I still haven’t got the upgrade I ordered a month ago. • I need help debugging a problem with ______.
• I’m struggling to learn ______ and would like to pair with someone on it.
• The department Head has asked me to work on something else “for two days”.
In cases where the project manager cannot remove these impediments directly himself (e.g., usually the more technical issues) he still takes responsibility for making sure someone on the team does quickly resolve the issue.
Technical Debt
It is the total amount of “less than perfect” design and implementation decisions in the project. Quick and dirty hacks made to make something work right now. This usually increases the maintenance cost and cost of adding new features. Refactoring is done to reduce technical debt so that code can be reused. Technical debt is something which prevents team from being Agile and has to be constantly addressed as the project progresses.
Time boxing
Work invariably stretches to use the existing time (Student syndrome). Time boxing prevents this by ensuring a work stops when it is time up. It will prevent “ Analysis paralysis”.
Last responsible moment
Making decisions during the moment at which failing to make a decision eliminates an important alternative. If you delay beyond this time decisions are made by default which is NOT good. By delaying the decision till this point you improve accuracy of decisions, decrease your workload and decrease impact of changes. All this because you will have higher information at the time of decision making.
Use Stories
They Represent a self contained, individual elements of work. They correspond to individual features and represent one or two days of work.
E.g. A Job application portal: “Ability to search for a job” is a story.
Iterations or Sprints
Iteration or a Sprint is the full cycle of design-code-verify-release of an Agile team. Each iteration will involve customer deciding what stories to implement in the iteration and results in an software which the customer can use. Beginning of an iteration i where the customer can make changes to the direction of software development. Although planning is frequent, it is small and proportion to the size of iterations.
Velocity
A measure to be able to determine the amount of work which can be done in an iteration. Most common ways to express velocity are user story points or man days.
Theory of constraints
Every system has a single constraint that determines the overall throughput of the system. One must find the constraints in the system (developers, programmers, testers) and eliminate the constraint.
Mindfulness
The ability to respond effectively to changes requires that everyone pay attention to the process and practices of development and this is called “mindfulness”. Sometimes there are subtle pending changes, you may realize technical debt to be growing or the tone of customer feedback to be changing, or team behavior changing etc.
Pair programming
Two members share the same keyboard. One member does the coding (and the tactical issues concerned) and the other members think about the big picture (Driver and a navigator). The partners can switch when frustrated or stuck. This usually gets people tired more than solo programming as the energy involved is higher. A good rule of thumb is to pair up anything which needs maintenance. Large monitors and good leg
room is essential. Create chances for both the members to be learning to enhance the utility of pair programming.
Energized work
When you are energized you work better. One of the best ways to feel energized is to take care of yourself. Go home on time every day, spend time with family & friends and do engage in activities that take your mind off of work. At work, give full attention to work. Turn off interruptions like e-mail, instant messages, phones and shield from unnecessary meetings. If you make more mistakes than progress, then it is time to take a break.
Informative work space
An informative work space brings information into the team. It allows the team to sense the state of project when they take breaks. An informative work space also provides for people to communicate easily.
Big visible charts and hand drawn charts are preferred.
Root cause analysis
Everybody makes mistakes- Aggressively laying blame does not solve this problem and only causes people to hide the mistakes.
Instead of thinking of this as a people issue, think of it as a process issue- This is called as root cause analysis.
5 Why technique is a good tool for root cause analysis.
Fixing root causes needs the cooperation of other people and this can be done by during retrospectives.
1. Example: Why is our largest customer unhappy? Because our deliveries of bicycles have been late for the last month.
2. Why have our bicycle deliveries been late for the last month? Because production has been behind schedule.
3. Why has production been behind schedule? Because there is a shortage of wheels.
4. Why are we having a shortage of wheels? Because incoming inspection has rejected a large number of wheels for not being round.
5. Why are we rejecting so many parts? Because purchasing switched to a cheaper wheel supplier that has inconsistent quality.
Retrospectives
Retrospectives (Introspective lessons learned meetings) are a great way to continually improve a process. Iteration retrospective happens at the end of each retrospective. Following are a few tools to keep in mind in a retrospective.
• Prime directive: No blame game.
• Brainstorming (Enjoyable, frustrating, puzzling, same, more ,less): Use of index cards
• Mute mapping (Variant of Affinity mapping)
• Pick the one with highest number of cards and focus on it (discard others for this retrospective). Can use root cause analysis.
Trust
Trust is essential for a team to improve productivity. Some strategies to create trust:
• Customer programmer empathy: Sitting together and understanding different point of view.
• Programmer-tester empathy
• Eat together
• Team continuity
• Impressions (Organizational antibodies)
Ubiquitous Language
Will help reduce mistakes and greatly increase communication. It is suggested that programmers should speak the language of domain experts and not other way around. The code can use functions, classes etc based on the domain experts language.
Coding standards
Creating of coding standards will help increase communication and collaborative work.
Not just formatting, but naming the variables, handling exceptions, when and where to log events etc are all part of standardization.
Iteration Demo
It’s a concrete way to show your progress and keep stakeholders happy. It helps the team to be honest about their progress and helps solicit feedback from the customers and change direction if needed. Any one can do this, but is best done by the product manager.
Two key questions to ask at end of iteration demo are:
1. Is the work satisfactory till date
2. Can the work be continued
Agile Reporting
Only product reports that are strictly necessary (as reports take up time). There are progress reports and management reports.
Some practices for progress reports are:
• Weekly demo
• Release and iteration plans
• Burn up chart
• Status e-mails
Some practices for management reports are:
• Productivity (The actual metrics are difficult and needs stakeholder involvement)
• Throughput (Number of features developed)
• Defects (Decide who will arbiter defect vs intentional behavior)
• Time usage (Developing, planning, improving skills, out of office, un accounted)
Version control
Will help team to co-ordinate source code, testing and other artifacts. It provides a central repository for the code.
Repository: Storage place for all the files.
Sandbox: It is a working copy of files on local system
Check out: To create a sandbox check out a copy of repository (also called as update and lock)
Update: Update sandbox to get latest changes from the repository
Lock: Prevents anyone from making changes except you
Check in or commit: Check in the files from sandbox to save them into repository
Revert: Throw away changes and return to point of last update
Tip or head: Contains the latest changes made to the code that has been checked in
Tag or label: A mark allowing easy access
Roll back: A check in to remove from tip of the repository
Branch: Create distinct “Alternate histories”
Merge: Merge multiple files and resolve conflicts
Concurrent Editing: Where multiple users can edit at same time and if two users edit same line of code then the lines are prompted to be merged manually.
Collective code ownership is encouraged for Agile software development approach.
Continuous Integration
Get members to agree to build frequently and never break the build. Agreement is the key as forcing is not likely to work. The general rule to keep the build to under less than 10 minutes. If the build is reasonably fast, the it is a good idea to do synchronous integration (Confirm that the build and test succeeded before you go to next step). If the build takes longer, then it is tantalizing to do asynchronous integration. The biggest problem is that it tends to result in broken builds and you have to interrupt your work later when the build breaks. If anyone has checked out the code in the mean time their build will not work either (If they have gone out for lunch then someone else has to fix the mess).
Osmotic Communication
Communication that is picked up or absorbed by another person. Osmotic communication means that information flows into the background hearing of members of the team, so that they pick up relevant information as though by osmosis. This is normally accomplished by seating them in the same room. Then, when one person asks a question, others in the room can either tune in or tune out, contributing to the discussion or continuing with their work. When osmotic communication is in place, questions and answers flow naturally and with surprisingly little disturbance among the team. Osmotic communication is the more
powerful version that small projects can attain of close communication, a property core to the entire Crystal family. Osmotic communication makes the cost of communications low and the feedback rate high, so that errors are corrected extremely quickly and knowledge is disseminated quickly.
People learn the project priorities and who holds what information. They pick up new programming, design, testing, and tool handling tricks. They catch and correct small errors before they grow into larger ones.
Although osmotic communication is valuable for larger projects, it is, of course, increasingly difficult to attain as the team size grows. Hence it is suggested in Agile methods that if the need for growing the size of team is felt, better thing to do is to recruit the team with higher experience. It is hard to simulate osmotic communication without having the people in the same room; however, adjacent rooms with two or three people in each confers many of the benefits.
Communication Factors
There are several factors that effect communication, including:
1. Physical proximity. The closer people are to one another the greater the opportunities for communication.
2. Temporal proximity. Whether or not two people are working at the same time affects communication.
3. Amicability. Amicability, the willingness of someone to hear the thoughts of another person with good will and to speak without malice, is an important success factor. The greater the amicability a greater amount and quality of information will be communicated and less will be concealed. Amicability is closely followed by the trust that people have for one another and the sense of community that they share. Sometimes amicability can run too high, people can be so worried about offending their colleagues that they are afraid to disagree with them or be afraid to take the initiative for fear of being perceived as glory seekers.
Kanban Board
A Kanban System visualizes some unit of value. This unit of value could be a User Story, Minimal Marketable Feature, Plain Old Requirement or something else. This is different from a task-board, which generally focuses on visualizing the current tasks.
A Kanban System manages the flow of these units of value, through the use of “Work In Process limits”. This is different from a task-board, which generally has no WIP limits, but aims to have all tasks complete by the end of a time-box. A Kanban System deals with these units of value through the whole system, from when they enter a teams control, until when they leave it. This is different from a task-board, which generally only deals with the work in the build/test stage, but shows no information about what work is being prepared, or what work is ready for release.
By putting these 3 properties of a Kanban System together, we can describe a Kanban System for Software Development as one which allows value to flow through the whole system using WIP limits to create a sustainable pipeline of work. Further, the WIP Limits provide a mechanism for the Kanban System to demonstrate when there is capacity for new work to be added, thereby creating a Pull System. Finally, the WIP Limits can be adjusted and their effect measured as the Kanban System is continuously improved.
A task-board simply shows what development tasks have been predicted to be done in the current time-box, with their status.
Agile Iteration Planning
After the iteration demo and retrospective are complete, iteration planning begins. Start by measuring the velocity of the previous iteration. Take all of the stories that are “done done” and add up their original estimates. This number is the amount of story points you can reasonably expect to complete in the upcoming iteration.
Be sure to use estimated time, not actual time, when calculating velocity. This allows the velocity to account for interruptions and other overhead. With your velocity in hand, you can select the stories to work on this iteration. Ask your customers to select the most important stories from the release plan. Select stories that exactly add up to the team’s velocity. You may need to split stories or include one or two less important stories to make the estimates add up perfectly.
Because the iteration planning meeting takes stories from the front of the release plan, you should have already estimated and prioritized those stories. As a result, selecting stories for the iteration plan should only take a few minutes, with perhaps ten or 15 minutes more to explain.
Size Estimation: Story Points
Points is a relative measure that can be used for agile estimation of size. The team decides how big a point is, and based on that size, determines how many points each work item is. To make estimation go fast, use only full points, 1, 2, 3, 5, 8, and so on. To get started, look at 10 or so representative work items, give the smallest the size of one point, and then go through all other work items and give them a relative point estimate based on that point. Note that points are used for high-level estimates, so do not spend too much time on any one item. This is especially true for work items of lower priority, to avoid wasting effort on things that are unlikely to be addressed within the current iteration.
Use non linear number sequence (Like Fibonacci numbers) to determine size as humans can differentiate non-linear numbers better than linear number sequences.
A key benefit of points is that they are neutral and relative. There may be disagreement about the actual effort required to do it, but we do not care at this point in time, we only want the team to agree on the
relative size. We will later use Velocity to determine how much ‘size’, or how many points, the team can take on within an iteration.
Spike Solution
It is a technical investigation or experiment to research the answer to a problem (For example, you want to know if C# throws an exception on floating point overflow, you can do a quick spike to find the answer)
The biggest problem with Spike solution is that it takes time to experiment which is going to be wasted after the solution is found. A Spike Solution:
1) Is an experimental solution that cuts through all the “layers.“
2) Is necessarily time-boxed.
3) Is always intended to be thrown away.
Spike – a spike is a quick and dirty implementation to show that the suggested solution would work. It does not follow the laid down architecture and might be done in a different language all together. For example a spike could be done in RoR and then later implemented in Java. These are more like prototypes and are thrown away.
Size Estimation: Ideal days
Ideal days are the imaginable amount of time that would be spent on the project if there were no interruptions (including email checking), everybody was working full time at full speed without any vacations and everything needed was present from the day one.
Pros:
• The concept of ideal time is relatively simple to explain both to developers and their bosses.
Cons:
• Since both elapsed and ideal times are measured in the same units, they tend to mix
• Not everybody is eager to accept that in a real world week there can be only two-three full ideal work days
• Since team skills and the understanding of the subject area raise over time, ideal day estimations tend to decay and have to be readjusted often
• Ideal days can be difficult to sum. My ideal days are not equal to yours
Agile Exploratory Testing
Exploratory testing is a style of testing in which one learns about the software while simultaneously designing and executing tests, using feedback from the previous tests to inform the next. This helps discover emergent behavior, unexpected side effects etc. Four tools are helpful for exploratory testing. They are:
1. Charter: A small document providing information about what to explore and what of things to look for in the system.
2. Observation: Based on observations of code.
3. Note taking: To prevent where you have been and where you are going, can take the aid of a notepad. Take notes of what might need further exploration.
4. Heuristics: A guide which helps in explorations (Like boundary testing)
Iteration Velocity
Velocity is the number of story points completed in an iteration. Ways to increase velocity:
1. Pay down technical debt
2. Improve customer involvement
3. Support energized work
4. Offload programmer other admin duties
5. Provide necessary resources
Agile Personas
A persona, first introduced by Alan Cooper, defines an archetypical user of a system, an example of the kind of person who would interact with it. The idea is that if you want to design effective software, then it needs to be designed for a specific person. For the bank, potential personas could be named Frances Miller and Ross Williams. In other words, personas represent fictitious people which are based on your knowledge of real users.
You’re likely familiar with actors. Unlike actors, personas are not roles which people play. In use case modeling actors represent the roles that users, and even other systems, can take with respect to your system. For example, in a banking application we would have actors such as Customer and Credit Card Processor. Actors are often documented by a sentence or two describing the role. For example the description for Customer might read “A person or organization which does business with the bank.”
Personas are different because they describe an archetypical instance of an actor. In a use case model we would have a Customer actor, yet with personas we would instead describe several different types of customers to help bring the idea to life.
Test Drive Development (TDD)
Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes a failing automated test case that defines a desired improvement or new function, then produces code to pass that test and finally refactors the new code to acceptable standards. A 2005 study found that using TDD meant writing more tests and, in turn, programmers that wrote more tests tended to be more productive.
Programmers using pure TDD on new (“greenfield”) projects report they only rarely feel the need to invoke a debugger. Used in conjunction with a version control system, when tests fail unexpectedly, reverting the code to the last version that passed all tests may often be more productive than debugging.
Test-driven development offers more than just simple validation of correctness, but can also drive the design of a program. By focusing on the test cases first, one must imagine how the functionality will be used by clients (in the first case, the test cases). So, the programmer is concerned with the interface before the implementation. This benefit is complementary to Design by Contract as it approaches code through test cases rather than through mathematical assertions or preconceptions.
Test-driven development offers the ability to take small steps when required. It allows a programmer to focus on the task at hand as the first goal is to make the test pass. Exceptional cases and error handling are not considered initially, and tests to create these extraneous circumstances are implemented separately. Test-driven development ensures in this way that all written code is covered by at least one test. This gives the programming team, and subsequent users, a greater level of confidence in the code.
Test-driven development is difficult to use in situations where full functional tests are required to determine success or failure. Examples of these are user interfaces, programs that work with databases, and some that depend on specific network configurations. TDD encourages developers to put the minimum amount of code into such modules and to maximize the logic that is in testable library code, using fakes and mocks to represent the outside world.
Management support is essential. Without the entire organization believing that test-driven development is going to improve the product, management may feel that time spent writing tests is wasted.
Tracer Bullet
Pragmatic Programmers usually prefer a “Tracer Bullet” which:
1) Is an experimental solution that cuts through all the “layers” of the architecture.
2) Is not necessarily time-boxed.
3) Is not intended to be thrown away.
It is of production quality and rest of the iterations can build on this code.
