Scrum and the Agile Philosophy

Developing our own Agile process is something that we should take pride in. We can take bits and pieces from frameworks and create something that works for our team. The point is not to go whole hog in to a single framework and force the team to work inside the constraints predefined for a different team.

The Origin of Agile

When most people hear the term Agile Development they instantly think of something specific. Unfortunately this is an issue of implicit vs explicit meaning. In it’s very nature Agile Development is nothing more than a way of thinking. The philosophy was originally developed in 2001 by a group of programmers who believed the current way of working (the traditional waterfall) was flawed and that there had to be a better solution. This group came together and wrote the Agile Manifesto.

The Principles of Agile

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.

The Definition of Scrum

Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

Scrum is:

Lightweight
Simple to understand
Difficult to master

Scrum is a process framework that has been used to manage complex product development since the early 1990s. Scrum is not a process or a technique for building products; rather, it is a framework within which you can employ various processes and techniques. Scrum makes clear the relative efficacy of your product management and development practices so that you can improve.

The Scrum framework consists of Scrum Teams and their associated roles, events, artifacts, and rules. Each component within the framework serves a specific purpose and is essential to Scrum’s success and usage.

The rules of Scrum bind together the events, roles, and artifacts, governing the relationships and interaction between them.

Creating our own Agile Process

Normally the first step I would suggest is to begin planning on a smaller scale; fortunately we already do this. The weekly “resourcing” that we do lends itself well to the Agile philosophy. In most cases a sprint is defined as a one to two week period of time that has been scoped out and a roadmap has been set for the team. This is where the wheels fall off of our wagon.

- Resourcing:

The current way we do resourcing is by assigning someone “x” hours for project “y”. In order for us to move forward as a team this has to change. All scoping and planning for sprints should be task based. Task “x, y and z” need to be completed for project “q” this week. This allows the team to focus on concrete goals for completion and gives a much needed sense of accomplishment to the developers. Resourcing and progress tracking based on tasks also allows for more accurate status updates. If someone is resourced 10 hours on a project and runs into a particularly stubborn issue they may take 20 hours for that project, but what actually got done? It’s much more clear is that person is resourced task “x, y and z”, that way if they complete task “x” and get stuck on task “y” we can see the progress that was made. If any tasks from the current sprint are not completed it is much easier to understand why; it also sets the groundwork for the next sprint, all unfinished tasks are rolled over and set as priority one for the next sprint.

- Progress Tracking:

Now that we’ve covered resourcing we can move on to the next step. This is also something that we have implemented to some degree. That is the standup; our version of the Daily Scrum.

The Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours. This is done by inspecting the work since the last Daily Scrum and forecasting the work that could be done before the next one. The Daily Scrum is held at the same time and place each day to reduce complexity. During the meeting, the Development Team members explain:

What did I do yesterday that helped the Development Team meet the Sprint Goal?
What will I do today to help the Development Team meet the Sprint Goal?
Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

With the implementation of proper sprints we will easily be able to talk about the progress towards the Spring Goal.

- Review and Retrospective:

Something that we do not really focus on as a team is a review of our progress. Much of this can be attributed to the fact that we don’t track our progress in a good way. By implementing the tools mentioned above we can improve upon this and it will enable us to review the progress we have made and talk about adapting the process in order to become more efficient.

- The Sprint Review:

A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value. This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.

- The Sprint Retrospective:

The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning. This is a three-hour time-boxed meeting for one-month Sprints. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendants understand its purpose. The Scrum Master teaches all to keep it within the time-box. The Scrum Master participates as a peer team member in the meeting from the accountability over the Scrum process.

The goal of the Reviews and Retrospectives is to:

Look back at the previous scrum and go over what has been completed. (Rev) Look back at the previous scrum and go over what has not been completed. (Rev) Discuss any issues that the team ran in to trying to reach the Sprint Goals. (Rev) Display the completed items from the previous sprint and answer any questions from the stakeholders. (Rev) Collaborate on what should be done in the next sprint, providing a baseline for the next sprint planing session. (Rev) Review the timeline, budget, and potential capabilities for the project. (Rev) Inspect how the last Sprint went with regards to people, relationships, process, and tools. (Retro) Identify and order the major items that went well and potential improvements. (Retro) Create a plan for implementing improvements to the way the Scrum Team does its work. (Retro)

Conclusion

I believe that by implementing, adapting and iterating on the processes listed above that our team will grow and become much more successful in the future. With a better process we will be able to develop our products more quickly and be able to take on larger projects. We will also be able to onboard new team members in a smoother fashion so that they can understand what we are doing and what is expected of them.

As always feedback is always appreciated and encouraged.