Gary Han - A Nerd Who Tries To Be Cool And Failed Thus Far

    So we all heard of the art of agile software development.

    But everyone has their own said about these processes, and most of us use a mixture of these defined methodologies in our projects.

    Here, I will write down my own thoughts and ways of using these processes.

    There are 2 types of methodologies I realistically involved in: Scrum and XP,

    I will keep it short and summarize each process:

Scrum  

Scrum Team: Consist of Scrum Master(Team lead programmer), the project manager, and the programmers.

Summary:

        Idea of Scrum is to produce shippable software each iteration.

        Project starts, Clients talks to project manager to confirm project.

        Once confirmed, clients talk to the scrum team to summarize and have everyone get a feel of the project at hand.

        Client and project manager create individual functionalities in backlogs, (With the help of Scrum master or sometimes the whole team) the backlogs are front-end specs that describe the application from the user's perspective.

        Client and project manager discuss and prioritize the backlog items.  Then decide sets of functionalities needed delivered for upcoming iteration.

        The team reviews backlog for the upcoming iteration, modifying items according to time frame and work load.

        Once backlog confirmed, developers review and take on tasks from the list, and the Sprint of the iteration begins. (Rapid development begins)

        During the sprint, developers keep each other updated with daily Scrum meetings.

        During my experience of Scrum, the proposed functionalities were always delivered. (Because we did not take on something that we could not handle)

        After the sprint, the team would give review and retrospective meetings to conclude the iteration.

        Then client is involved again to showcase the deliverables as well as to discuss the deliverables for the upcoming iteration.

        And the process repeats itself.

XP(Xtreme Programming)  

XP Team: project manager, business analyst (BA), team lead, story leads, developers

Summary:

        Project Manager, team lead and BA discuss project requirements with client.

        XP team meet with client to discuss and create user stories for the project. (Sometimes only the team lead and other senior members of the team will meet with client in a large team)

        User stories are front-end specs stating the requirements. Not necessarily shippable software pieces. (i.e. a story can be to setup backup and build method for project)

        Story leads are assigned to each story. (Usually voluntary, this is a way to enhance the leadership skills of each developer in the team) Development team meet and discuss technical aspects of each story; Breaking each story into technical tasks. (i.e. create database objects and accessor methods)

        Give work estimations for each task, then conclude work required for each story using these task estimates.

        BA and client prioritize these stories taking the work load on each story into consideration. They determine the immediate deliverables required for the upcoming iteration.

        Once confirmed, developers pair up and take on the tasks. Test first development is encouraged. (Because making test first development a requirement is not realistic)

        Tasks are checked off as they are completed. And deliverable adjustments are made as iteration progresses.

        After each iteration, the staging environment is updated with the new version of the program for client to review.

        Then more stories are made as requirement changes, and priority list gets updated. Then the process repeats itself.

    Many companies adapted to agile development process tend to evolve themselves into a process which is a mix of many methodologies. There is nothing wrong with such action, as long as it works for the team. We have to always remember, the methodologies are not alive, we are. All of them are there for reference, not to follow exactly down to the bits.

    Some key points to remember when adapting to agile:

        1. take changes of requirements as a possible property during the course of our projects. Think Changes are fun.

        2. try to retain to small iterations, even if there are a lot to be done, and often the case is true, break things up. (Many teams adapting agile fail to break things up, and dragged iterations on and on.)

        3. avoid heavy documentations and write self documenting code. Like descriptive variable names, intuitive method names, well organized packages, etc.

        4. do not hesitate to refactor code, and doing code reviews.

    Simple enough, by keeping in mind these key points, we are already boosting our success rate of a project to the feasible region. Feasible region because software development is never easy. It needs hard work and dedication of everyone in the team.

    As "Good To Great" by Jim Collins states, let the employees empower themselves. Same holds true for developers, let the programmers empower themselves. And agile programming is the key to promote that idea.