Agile Development: One Approach of Many
A lot of the times I come across the question “What process of development should we use for our project”, and I generally respond with “Agile” followed by blank stares and question marks. After repeatedly explaining the process, I thought why not just write out what Agile is for others to read. And thus I am writing this blog entry.
What is Agile
Agile is a highly adaptive development process that enables decision makers( ex: managers, stakeholders, owners, ceo), developers, and other expertise( ex: marketing, financing) to work together on creating a product. The process consists of stories, iterations and velocity but those are all terms we will go over shortly.
Agile is often a touchy subject among developers because there is the belief that there is a right way of doing it. I’ve worked using Agile on development teams from Fortune 100 companies to small start-ups and there is no set in stone right way but the process varies depending on the team. When I say team, I mean everyone involved in the process from the ceo to the marketing, not just the developers. The belief that there is a right way of doing Agile completely misses the point of Agile.
Agile Terms
Before we go into how to execute Agile, we should start by going over some terms used in the development process.
Stories: When you think of stories, you should immediately think of tasks. Stories are short task written by the decisions makers on what needs to be done. A story should only be about 3-4 sentences max. An example of a story would be:
“A user enters their email address and password on the login screen. If successful they are redirected to the dashboard. If unsuccessful, they are redirected to a forgot password page”.
The stories are generally derived from the business plan or the vision of the product that is being made.
Points: Points are a numerical value assigned to a story. The points represent how long it should take to a complete a story. The meaning of a point is determined by the organization. I like assigning my points like this:
2 hours of work is equal too 1 point
2 points is 4 hours of work,
8 hour work day is 4 points
6 points is a day an a half of work,
8 points is 2 days.
The basic idea is harder stories are assigned more points. Remember to come up with your own point scale based on the team.
Iteration: An iteration, also known as a sprint, is a set time period in the development life cycle. The development cycle should cover planning, coding, design, testing and approval. Normally I have weekly iterations, but it depends on the team how long your iterations are. At the end of the iteration, there is an iteration meeting where the team reviews the past progress and plans for future tasks.
Velocity: Velocity is a numerical value, based on the points, to how many tasks should be completed in that iteration. The velocity is calculated using the average points of stories completed from previous iterations. If the majority of stories in an iteration are assigned a lot of points, this means that they are hard task to complete and not many stories will be completed. But if the stories are assigned a low number of points, then a lot of stories should be completed because they were easy tasks. Either way, the velocity should be the same if the points are assigned correctly to the stories.
Scrums: Scrums are meetings that are held. Normally there should be a daily scrum amongst the developers called a stand up. This is where developers talk about their accomplishments and problems they are having. There should also be a scrum when the whole team comes together too meet. This should happen at the end of an iteration and is called the iteration meeting. Other scrums can be added as needed.
Rules of Agile
Now that we have the basic terminology of Agile, we can go over the rules. Yes there are rules to Agile or it the process will just fall apart. These are my rules, you can come up with your own that best facilitates your team.
No Adding Onto To A Story: The story is the defined task at hand. Once a story has been finalized, no adding on extra elements to that story. An example of adding onto a story is this:
Finalized story:
“A user enters their email address and password on the login screen. If successful they are redirected to the dashboard. If unsuccessful, they are redirected to a forgot password page”.
Story Additions
The developer completes the story and then the decision makers decide to say “Also add in a register button, login button, and also only go to the login page after they failed 3 times.
This is wrong. These new requirements should become a new story. The reason why is because adding new task to a story:
ruins the velocity
makes it seem like things are not getting done on time and make it hard to track progress
frustrates the developer
Nothing Is Set In Stone: One of the key points of Agile is the ability to easily change the requirements that are best for the product. When a decision maker writes a story, the developer should ask questions. The developer and the decision maker should come to an agreement on the story, no one person is right.
2 Story Limit: Developers should only work on two stories at max. This is to keep the developer focus and allow management to know what is being worked on and by whom.
2 Day Limit: under normal circumstances, a developer should work a story on for a max of 48 hour time period. This is done because other stories may require the completion of the story being worked on. If it cannot be done in a reasonable time period, put the story back in and either come back to it later or have another developer look at it.
Agile Process
We have the terms and we have the rules. Now we can go through the process of using Agile. Remember, this is the way I find it best to execute Agile, but it’s not the right way. The right way is the way the best suites your organization.
Decision Maker Writes A Story: The decision makers(stakeholders, managers, business owner, etc) write stories that are based on the business plan, an iteration meeting, or the vision of the product. Remember the stories should be short. Write many of them to give the developers enough to do.
Developer Examination: A developer looks at a story and asks questions about the story to clarify what needs to happen. The developer and decision maker have a discussion on what is the best way to go about executing the story and if the story is even right. When a consensus has been reached, the story is locked and no more requirements can be added. At this point the developer assigns point to the story for how long they expect to complete it.
Selecting and Submitting: A developer chooses a story that has been assigned points and works to complete the story. During this process, test case should be written. Once completed, the story is submitted for a code review.
Code Review: Another developer code reviews a submitted story. They check to make sure the code completes the requirements of the story and that the implementation of the code is suitable for production. If there are problems, the story is given back to the developer with things to fix. Otherwise the story is submitted to the decision makers for a final review.
Final Review: The decision makers review the functionality to make sure it completes the requirements specified. Remember, no adding additional requirements to a story, make a new story. Afterwards the story is deemed done. Otherwise it is sent back to the developer with the needed changes.
Meetings: Remember to have a set structure of when to have scrums. Typically there should be a meeting everyday amongst the developers and a meeting at the end of every iteration. The iteration meeting should influence the direction of future stories: go back to step one and repeat.
That’s all the Agile Process is. When the team involved agile understands the process, it will move fairly quickly which should cause the velocity to go up. While the Agile process described above is focused towards developers, Agile can be used with other expertise. An example can be your marketing team follows the same steps except they won’t be doing a code review. They would perform a peer review of the marketing material created and an approval by the decision makers. Remember that Agile is about the team, meaning in an iteration meeting, the marketing them can have input that affects the developers and vice versa.
Most importantly, I’ve stated it several times but I want to make sure this is clear: Above is the rules and procedure I have found that works with Agile. This is not the correct way, the correct way is the way that works best with your team.
Follow Me:
GooglePlus
Tumblr