SCRUM, a subset of AGILE Software Development

SCRUM, a subset of AGILE Software Development

The Basic Life Cycle of any project generally follows the following steps: Requirements -> Analysis -> Design -> Code -> Test. This is the waterfall model which most companies are following without even knowing it is indeed a documented methodology.

Many software developers don’t even document their code, this is not an assumption on my part but rather an observation from working with several developers on separate projects though my career and also snorkeling though code examples online.

Generally if you ask a developer “What is software testing?” you will receive comments like “My code compiled… what more do you want from me?” or “Dude, I wrote some unit tests…” or even worse “I think we did some Agile”

Besides the last example, for general small projects this is normally enough, the requirements may have been scribbled on a piece of paper or white board and 5 minutes later the developer was frantically mashing his keyboard to meet a ridiculous deadline and building a solution he doesn’t really understand. For many of us this is the reality however you are not working smart, you will eventually burn out and your software will not be something you can be proud of.

If this sounds like your organization then you need to change. The first step is to take a step back and try understand what the software development life cycle is, how you are already managing it in your business and how you can improve things.

Oh boy

The seven most expensive words in business: are “We have always done it that way.”

The following is my understanding of SCRUM, a subset of AGILE software development methodologies to help promote a disciplined and collaborative working environment within a team.

Stake Holders

Stake holders in this context refers to anybody that the project or software touches. This includes Business owner(s), Project Manager(s), Development team even the end users.

Sprint Planning and Defining Acceptance Criteria

Few developers have the privilege to start a brand new project with a well-documented specification, for the bulk of us we will work on existing systems with a product backlog of features and known bugs. This is not a bad thing, detailed specification documents are not a requirement for quality software. Few companies can afford to document software as well as, for example the C# Language Specification.

At the sprint planning meeting items from the product backlog are prioritized and a select number of items are included in the sprint based on the size of the team. Your sprints should be two weeks long and each developer have at least 60 hours’ worth of work for that sprint. This is around 6 hours a day which takes into account interruptions and cognitive load, remember if you are working smart you don’t have to work that hard. Never over load your best staff with all the workload – its very bad management to punish a hard worker simply because they are good at their job. Rather share the load and try upskill the rest of the team. This way after a few sprints you will a team of skilled staff.

The hours per sprint have to be attainable, if developers have to work overtime to meet the sprint deadline you need to go back to the drawing board in your planning meeting and probably acceptance criteria. Rather let them deliver quality code than poorly planned and buggy software.

The software does not have to be release at the end of each sprint, several sprints can make up a single release.

Before you begin doing anything your tasks requirements or “Acceptance Criteria” needs to as clear as possible written in plain English using the Ubiquitous Language for references as defined by your business. This should preferably be done by the Project Manager with input from all stakeholders at the sprint planning meeting.

The sprint planning meeting can unfortunately take up an entire day but as your team matures this meeting will shorten and the rewards will be very clear.

Once the Acceptance Criteria is defined this is what will be built by the developer, tested by the Quality Assurance testers, Tested by Business at User Acceptance and released into live. It cannot change during the sprint as this will cause development creep which is not agile.

Story

A story is the feature or module that the developer is going to build. It would include the acceptance criteria along with a brief description of the feature or bug fix. It’s a good idea to include testing data for both the developers and Quality Assurance teams – remember they may not have domain knowledge of the business / underlying business data so try give them all the information up front.

Example: Testing data can include database id’s to query, names to lookup on, date ranges ect. It will be determined by the story.

Story Points

Story points is an interesting measurement as it is determined by the team at sprint planning and is based on their understanding of the story, the team being all stake holders. Everybody has their say and often your story points can change based on others input when they motivate their “choice”.

*Story point is an arbitrary measure used by Scrum teams. This is used to measure the effort required to implement a story. In simple terms its a number that tells the team how hard the story is. Hard could be related to complexity, Unknowns and effort.*

I have found that using the fibonacci sequence on que cards speeds up this process as it reduces guess work.

Printing que cards is rather silly as there are several apps for your smartphone that allow you to chooses these numbers. Example: Scrum Poker Cards (Agile) by artArmin

The format is very simple:

Round 1 – the team will be briefed on the story, everybody gets a vote using their que cards. The highest and lowest numbers need to then motivate their choice. For example a low point of 1 would then need to be motivated why they feel it’s a simple change or fix. Likewise a higher point of say 40 would need to motivate why the feel this is a difficult change or fix. This is extremely valuable as the team will learn from each other – business would understand the code domain better and developers will gain knowledge of the business domain.

Round 2 – repeat the votes based on what you have just heard. It’s important to take this seriously and not just vote random numbers. If you don’t have knowledge of the area rather abstain or better ask questions. Remember the only stupid question is the one you don’t ask.

The majority vote then carries and that is then used as the story point score for that story.

Stand-Up!

WHO: Scrum team

Every day, preferably in the mornings the team need to have a stand-up, they each need to answer and ask some simple questions:

  • What did you work on yesterday?
  • What are you working on today?
  • What obstacles are in your way?

This will help the team work together and also assure business that their needs are indeed being worked on. All stakeholders need to be present or at very least have a proxy present to voice their concerns / progress ect.

Release Notes

During development it is a good idea to produce release notes and send them out via email once a day, they don’t have to be overly complicated. A simple table showing the reference number linking back to your project tracking system, the story headline and its location or who its assigned to.

Release Notes

Velocity

This is helpful for managers to motivate for things like incentives, new team members or to simply justify a team’s size or even existence.

The metric is calculated by reviewing work the team successfully completed during previous sprints; for example, if the team completed 10 stories during a two-week *sprint and each story was worth 3 story points, then the team’s velocity is 30 story points per sprint.*

It also helps identify mental fatigue or when it’s time to move developers into another team or role.

Sprint Retrospective

WHO: Scrum team

This is such an important meeting as it is an open form for the stakeholders to express how they felt the past sprint went. Simple questions to ask include:

  • What worked in the sprint?
  • What did not work?
  • How can we improve for the next sprint?

The idea is never to ostracize a staff member, if somebody constantly is not pulling their weight it is for their managers to deal with. Never judge a peer when they drop the ball, judge them by how quickly they pick it up again and run with the task.

Sprint Review

WHO: Scrum team & Stakeholders

Opportunity for

  • Product Owner to showcase what the team has been working on, highlight risks, what we will look at next and time lines in this quarter and the next quarter. This sets expectations.
  • Designers to showcase their visions and alignment to company wide copy.
  • Developers to demo technical things or functional product slices.

Its common for large companys to combine these reviews by pods/squads that serve a common slice of the business.

Summary

Agile teams are constantly evolving, when something doesn’t work try change it for the better. This is a mind-set that needs to be achieved.

Research what other teams are doing but never try implement something for the sake of it – if your team is performing well even with antiquated techniques it’s not always a good idea to change things.

Never forget Product is a Team sport.

References