Moving to an agile environment (part II) — Scrum by the book

Dear reader, I came across with this article to tell you about an experience that I’ve been living since a few months now — the experience of moving from a waterfall to an agile environment. I’m not an Agile nor a Scrum guru, but I’ll be giving you what I have been learning both from my experience and what I’ve been retrieving from some books and articles. This is part 2 of 3.

In this article I’ll be giving you a brief overview over agile and scrum framework and then, in part III, I’ll be addressing some minor topics that are important to make all this work.

Agile

Agile is a methodology that describes a set of values and principles for software development, that aim to guide software development teams to seek for the evolution of requirements and solutions along with an adaptive planning, fast deliveries, short development periods and continuous improvement. It embraces change instead of fearing it.

However, it doesn’t give you any receipt to accomplish any of its values and principles, that’s agile frameworks’ responsibility and in this article I’ll be giving you a brief overview over Scrum.

The agile manifesto

The agile manifesto is the key behind any agile environment and describes a set of values and principles that you must address. But if you work in a waterfall model like I used to, you’ll need to change most of your day-to-day work in order to achieve these.

That’s where frameworks like Scrum come into play, defining roles, artifacts and cerimonies.

Scrum framework

I would like to focus just on a brief overview around the framework but I believe there are some core concepts that you’ll need to read about to understand the bigger picture. Let’s commit ourselves to this little task:

We cover the overview now but if at any point you don’t know what is a “Product owner”, “a Scrum Master”, a “daily meeting”, etc. You jump to the “Appendixes” at the end of this article to find more about it.

Let’s do this!

So, this image above represents all you need to implement Scrum. Putting all these in practice doesn’t necessarily means that you work in an agile environment but… baby steps (quick read about this).

Like I’ve said before, our goal is to split our project in several stages so we can deliver more often and get feedback sooner. This image represents each of these cycles and they are known as Sprints.

Sprints must last between 1 to 4 weeks and always start with a sprint planning and finish with a sprint review/retrospective (Appendix C). In the middle is where our product gets implemented and at the end of each sprint we must always have a new working version of our product, a Potentially Shippable Product (we’ll see right next why this fancy name).

Let’s see all the stages of a user story from the paper to production!

From the idea to production

All ideas can be turned into user stories, spikes, tech stories, etc. And all these can become product backlog items (Appendix B) or simply trash. All the scrum team members can have a word about each new idea but the Product Owner (Appendix A) is the one responsible for deciding if it turns in a PBL item or if it’s discarded.

When the PO has enough PBL items (5, 8, 10…) without any measure, he gets the Scrum team together, explains each one of these so everyone gets the same understanding, and then each member of the Dev team (Appendix A) gives his estimation using story points — this is called Grooming (Appendix C).

So now our new idea is a product backlog item and has its estimation, it’s time to define its priority. At the product backlog, items are ordered from high to low priority from the top to the bottom and the PO is the one responsible for managing this order.

When our initial PBL item gets at the top it’s time to get it into the next Sprint!

Like I’ve said, every Sprint starts with the Sprint planning. At Sprint planning the scrum team gets together and decide which items go into the Sprint backlog (Appendix B). But how much items can we place at the Sprint backlog? That’s something I’ll address in part III but for now I can say that it’s related to story points and team velocity.

Once our Sprint target (Appendix B) is defined the Dev team can start implementing each one of the items and see its progress at the Scrum board. The Scrum board is composed by the several stages, for example: WIP, Code review, UX Review and Done. And an item must be marked as done only when:

1. Meets all its acceptance criteria
2. Accomplishes the Definition of done
3. Passes through the different stages in the Scrum board

During the sprint, the Dev team and the Scrum master make daily meetings (Appendix C) where each team member answers essentially to this three questions:

1. What did you do yesterday?
2. What will you do today?
3. Are there any impediments in your way?

The goal here is not to punish someone by his performance, but to understand the sprint progress and check if someone is stuck with something. This way we can all be aware of the state of our initial idea and how much is it close from getting done.

Then, at the last day of sprint we have our sprint review and retrospective (Appendix C). These two can occur in any order.

The Sprint review is also known as the demo meeting, because is a meeting where the Scrum team must demonstrate the new version of the product to the stakeholders.

This is our Potentially Shippable Product. A new working version of our work that can be shipped to production!

The Product Owner is the one responsible for deciding whether this new version goes live or not. (Our idea is finally this close of seeing the day light! yay!!)

“Oh nooooo. How can I ship something I’ve just implemented???”

Remember that DoD and acceptance criteria and all that? Quality assurance, unit tests, integration tests, end-to-end… it all must be part of it. It’s the only way you can achieve continuous delivery effectively.

And now the question…

“Ok. I have all my stories implemented and tested but I have the “users module” that only has the list of users. It doesn’t make sense to put it into production yet.”

Well… In this case I can tell you about two approaches.

1. The Potentially Shippable product isn’t shipped, as simple as that. It is a potential ship so… If the PO doesn’t find that new version valuable enough to be deployed so don’t.
2. Use feature toggles. Remember those videos from spotify that I shared with you previously? They do exactly that. You don’t compromise your delivery by unfinished developments. Simply use a parameterization system and enable/disable features. This can also be useful for A/B testing for instance.

And finally, when the PO founds a new version of the product valuable enough to be available to our users, our idea comes a feature in production!

I’ve just gave you a quick walkthrough about Scrum but guess what? There’s much more to learn about it. In part III I’ll be covering some additional topics.

If you have any question, please reach me in the comments. I‘ll try my best to help you.

Appendixes

Appendix A — Roles

Scrum master

The Scrum master is the one responsible for establishing a balance in the Dev team giving them some alignment along with some autonomy.

His responsibility is to resolve any blocking issues, to introduce any new techniques that may help the team to develop better and faster, to defend the team vision and to build trust not only in the team but also with the stakeholders. His main goal is increase the team velocity as hard as he can.

Product owner

The product owner is who holds the product vision and direction. He is the bridge between the Scrum team and the customers and other stakeholders.

His main goal is to the deliver the product that better suits the client needs and for that he has to continuously collect feedback from them and evaluate which changes must be applied to improve the product.

PO holds the product value and SM holds the dev team vision.

Development team

Dev team are the doers, who make it happen! Their responsibility is to execute the PO vision with the help of the Scrum Master.

The team is comprised of the people needed to deliver the work — developers, testers, architects, designers… anyone who is needed. And its size must be ideally around 7, plus or minus 2 people.

Scrum says that in a dev team titles and roles must be removed so we can achieve cross-functionality . Where the mindset is “I’m a team member who is responsible for delivering this work and I cannot do it alone”.

Appendix B— Artifacts

Product backlog

The product backlog is a list of items prioritized by business value and risk, describing features and functionality needed to implement the vision. Anyone can contribute with new items to this list, but it is product owner’s responsibility to maintain it, keeping it up to date, prioritized or ordered, and clear.

This is a living document that never ends and items can be added and removed at any time. There are several types of product backlog items like user stories, epics, ideas, spikes… The important thing is that, those who are at the top (biggest priority) are clear and well detailed and those who are at the bottom can be more vague since are not the focus for now.

Sprint backlog

The sprint backlog is simply a subset of product backlog items with the highest priority. When a new sprint beggins, some of the items are moved from the top of the product backlog and putted into the sprint backlog. This builds the sprint target.

During the sprint, items move from the sprint backlog to different stages in the Scrum board and an item is identified as done only when it meets all its acceptance criteria and the Definition of Done.

“When a backlog item is described as ‘Done’, everyone must understand what ‘Done’ means.”

Appendix C — Cerimonies / Mettings

Grooming

The gromming happens when the PO has enough new Product Backlog items that need discussion with the team (i.e. at any time during the sprint). In this meeting PO explains each one of the items so everyone can understand it in the same way and then each element from the Dev team gives his estimation using story points.

From this meeting, new items can be added, other may be removed, some may be changed and the list’s order may change too.

Sprint planing

The sprint planning can be split in two parts. The first is where the PO says what he want to be done during the sprint (the sprint target/goal), the second is where the team defines how it will be done. The PO doesn’t have to be present in this second part since he doesn’t participate in technical discussions.

Daily meetings

The daily meeting is the opportunity for the team to sync. This meeting is led by the SM and every team member answers the following standard questions:

• What have you accomplished since the last meeting?
• What will you accomplish today?
• What impediments or obstacles are in your way.

Sprint review

On the last day of the sprint the team holds the sprint review. It is also known as the “Demo meeting”, where customers have the opportunity to review the progress made on the project to date. This is where the team can collect valuable feedback from the customer.

In this meeting the team must ask for acceptance from the customer. Sometimes customers say that some functionality was not delivered or was not delivered as expected. In those cases, work might be putted back on the product backlog.

Restrospective

The sprint retrospective also happens on the last day of sprint. It provides the team an opportunity to identify ways in which it can improve its work process and execution. It is important to the SM and every element of the dev team to be present, the PO is not required to this meeting.

(These improvements are known as Kaizen.)