Agile Software Development with Scrum

I’ve started reading Agile Software Development with Scrum. This is just the first few sections of the book, but I’ve tried to pull out key thoughts and instructions that can be skimmed over and later used as a benchmark.

Take a look at the other posts:

I’ve seen a good deal of gains whilst working in a Scrum environment at the digital, creative agency I work at. Much of them are talked about below but to highlight what has got me excited about Scrum…when we get this RIGHT projects are so much more productive, less stressful and issues are cleared quicker.

I’m enjoying this discovery process and I’d thouroughly recommend anyone to give it a go.

Agile Software Development with Scrum

Systems development has so much complexity and unpredictability that it has to be managed by an “empirical” process control model.

Values integral to scrum are empiricism, self-organisation and action.

The Scrum Master

  • Is responsible for the success of scrum
  • ensures that Scrum values, practices, and rules are enacted and enforced.
  • compares what progress has been made to what progress was expected

The Scrum Master has certain personality traits.

He or she is usually focused and determined to do whatever is necessary for their scrum teams. They are comfortable being visible and taking a lot of initiative. Removing impediments requires determination and stubborness.

The Product Backlog

This is an evolving, prioritized queue of business and technical functionality that needs to be developed into a system.

The Product Owner

  • The product owner solely controls the product backlog.
  • The product owner is one person, not a commitee. Commitees may exist that advise or influence this person, but they must convince the owner to have any priorities changed.
  • For the product owner to succeed, everone in the organisation has to respect his/her decisions.

Estimating Backlog Effort

The Product Owner works with developers, technical writers, quality control staff and other people who understand the product and technology to estimate how long each item in the backlog will take to develop.

  • The estimate will only be as accurate as the team are at estimating.
  • Estimating is an iterative process.
  • The Product Backlog estimate is not binding.

Scrum Teams

A team commits to achieving a Sprint goal. The team is accorded full authority to do whatever it decides is necessary to achieve the goal.

The team size should be seven people, plus or minus two. Teams as small as three can benefit but the small size limits the amount of interaction that can occur and reduces productivity gains. Teams larger than eight generate too much complexity.

A Scrum team self organises. When a team member commits to work on a sprint, he or she commits based on what work can be done within the hours they have. There are no titles on teams, it is ego-less development.

Team members are in charge of their working hours although need to work when the rest of the team is present and must not disrupt the organisational environment.

So a reminder of what makes Scrum different.

It’s an empirical process, it promotes self-organisation and encourages action through personal ownership of what is being produced.

Work with me

Dave is a cohesive team member, widely popular with his colleagues and always inspiring quality, exploration and innovation. One of the true ‘greats’ we’ve had the pleasure to work with

I believe in community, in inspiration and creativity. I believe it's an inspired team and a laser focus on the user's experiece that will produce the best results. I want to help frontend teams live inspired, be productive and scale better.