Categories
Business

Scrum Methodology

What does it mean to be agile?

Being agile means we know how to react to the market and customers, and we react by responding quickly to their needs and requests. Agile methodologies try to minimize the risk of creating products that do not meet – or no longer meet – the needs of the market nor the customers.
Scrum is one of the most popular agile methodologies that is nowadays used to develop complex products and systems.

Agile scrum methodology is a Sprint-based project management system with the aim of providing the greatest value to stakeholders. It encourages teams to learn from experience, to self organize while working on a problem, and to reflect on their wins and losses in order to continuously improve.

It consists of 3 steps: 
1. getting work done
2. checking it
3. adjusting it

 

We ourselves use Scrum methodology for the management of our own projects, and tools such as Jira, Azure or Trello help us with the project and task organization. They are easy to use, and also let us keep track of the progress, so both we and our clients are always up to date when it comes to work that is currently being done and how its progress is coming along, so that if needed we can adapt to it in the future.

In this post, we will go through some Scrum events and Scrum participants, and what they look like for us.

Sprint

A Sprint is a time-bound period of 2 ,up to 4, weeks during which specific work must be completed and ready to be delivered to the stakeholders. This way, feedback is obtained regularly and plans for further implementation or potential changes can be made.

The duration of the Sprint depends on the size and the complexity of the project itself. Within our projects, it usually lasts for 2 weeks.

Sprint starts with Sprint Planning and ends with Sprint Review and Sprint Retrospective. These phases are repeated throughout the project’s life cycle until the entire project is delivered before the stakeholders.

Product backlog and Refinement

The Product Backlog contains all the work related to product development and its improvement. Product Backlog is a list of work tasks (Task, Story) that need to be done in order to develop the product. This list is open to change and is continuously updated as the work on the product progresses.

Refinement is a meeting in which both the Product Owner and the development team participate. They analyze, discuss, assess the complexity and time needed to complete the tasks. This is also the way of keeping Product Backlog well maintained. Work assignments must be understood by everyone involved (shared understanding), have an estimate on complexity and how much effort (time) will the implementation take.

Refinement and Sprint Planning help us prepare and plan both work tasks and Sprints better.

Sprint Planning

Sprint Planning is the event in Scrum that starts the Sprint. The purpose of Sprint Planning is to define what can be delivered within the Sprint and how will that be done. Sprint planning is done by the Product Owner in cooperation with the entire Dev team.

The estimated duration of Sprint Planning is 2 hours for each week of the Sprint. This means that if the Sprint lasts 2 weeks, this meeting should last 4 hours. But if the team prepares well and estimates the tasks they plan to include in the Sprint, planning can take less time.

Our practice is that Sprint Planning does not last longer than an hour, and we achieve this by carefully preparing and estimating each work task during the Refinement meetings.

Daily meetings

During a Sprint, the team holds daily standup meetings in order to discuss progress and find solutions for challenges we are facing. Both the Development team and Product Owner attend this meeting, although the PO is not required.

During this meeting, all team members should give answers to the following 3 questions:
1. What did you do yesterday?
2. What are you going to do today?
3. Is there something blocking you?

Daily meetings should last from 5, up to 15 minutes.
We hold them every morning, at the beginning of the work day.

Sprint Review

The Sprint Review is an informal meeting during which the team demonstrates what has been achieved, while stakeholders provide feedback. The Development team, Product Owner and Stakeholders are attending this meeting.
The main purpose of the Sprint Review is to examine the outcome of the Sprint, gather feedback from all stakeholders, create a plan and reorganize the Product Backlog.

The Sprint Review is held at the end of the Sprint. The duration of this type of meeting is estimated at 1 hour per Sprint week. This means that if the Sprint lasts 2 weeks, this meeting should last 2 hours.

We like to keep our Sprint Review flexible, therefore our Sprint Review lasts up to an hour.

Sprint Retrospective

At the Retrospective we discuss what went well during the previous Sprint and what can be improved for the next one. We can think of it as a meeting where we discuss the good and bad things that happened in the previous Sprint and the things that we should start, stop and continue doing. This is the moment when the previous Sprint is used for learning.
The meeting is attended by the Development team, Product Owner and Scrum master.

A Sprint Retrospective is held at the end of each Sprint. The estimated duration of the Retrospective is 45 minutes per Sprint week. This means that if the Sprint lasts 2 weeks, the Retrospective should last 1 hour and 30 minutes.

We believe that the time allotted for the Sprint Retrospective should be flexible. When we judge that the Sprint was easy and that we did not have any problems, we reduce the duration of the meeting.

Dev Team

Group of 3 to 9 people that are working together on development of a product, and have all the skills and abilities needed to get the development done.

In our case, a Dev team consists of 1 or more Android developers, 1 or more iOS developers, 2 backend developers (mostly), a designer and a tester.

Conclusion

We have seen what Scrum should look like theoretically, as described in the scrum guide. We also saw how we could apply the Scrum methodology and adapt it to our projects. The Scrum guide should only be a guideline on how to proceed, but the point of agile methodologies is flexibility and learning from previous experiences. That’s why if you, like us, feel that you can’t apply or do some things as described, you have the freedom to adapt them as you see fit for your own team and projects. This will bring out the best in team, as they feel free to express their opinion, approval or disapproval – and in the end, that’s how success is achieved!

Categories
Android

How to update fragments in the ViewPager?

Five indubitably easy steps

The problem described in the title below is found to be a very common problem Android developers face. As being so, I decided that is the problem I want to dedicate my first blog post to. In this quick read, I will show and explain to you a very simple solution.

When I was first encountered with this implementation, I failed to find much regarding it while searching the internet. What was offered in response either sounded like a very poor implementation or was quite complicated to deal with.

At that time I was on a project where I had to use EventBus library, and it proved to be a very good solution, with not so demanding implementation. That is why I decided to approach the solution in this way.

A sample project for this tutorial can be found on Github repository: https://github.com/Crystal-Pigeon/photo-manipulation.

To start the implementation, we need to add the following line of code to the build.gradle file:
<code class="language-kotlin">
implementation 'org.greenrobot:eventbus:3.2.0'
</code>

We start from the fact that we have one activity, in my case that was MainActivity. It contains a ViewPager with 3 tabs, which means that we have 3 fragments and a field for entering a query, which is going to be used for the search of the data from the aforementioned fragments. To display the data each of the fragments contains a RecyclerView.

Then we need to create an event that will be observed. We create a SearchEvent class that includes the following:
<code class="language-kotlin">
class SearchEvent(var query: String, var pageTitle: CharSequence?)
</code>
The next step is to create a Publisher that will broadcast the event itself.

In this case, the event is broadcasted every time something is entered in the search field. First, we create an object of class SearchEvent and broadcast the event to which we forward the created object.

<code class="language-kotlin">
et_search.doAfterTextChanged {
      val searchEvent = SearchEvent(
            et_search.text.toString(),
            searchViewPagerAdapter.getPageTitle(vp_search.currentItem)
      )
      EventBus.getDefault().post(searchEvent) //publish the event
}
</code>
Moving forward, it is necessary to register the Bus in fragments.

We will do this by overriding the onStart and onStop methods as follows:

<code class="language-kotlin">
override fun onStart() {
    super.onStart()
    if(!EventBus.getDefault().isRegistered(this)) {
        EventBus.getDefault().register(this)
    }
}

override fun onStop() {
    super.onStop()
    EventBus.getDefault().unregister(this)
}
</code>
In addition to this, it is necessary to create a Subscriber.

Specifically, we have to create a method that needs to be annotated with Subscribe, which, as a parameter takes in an object of the SearchEvent class, that we previously created. This method is executed after the broadcast of each event.

<code class="language-kotlin">
@Subscribe(threadMode = ThreadMode.MAIN)
fun onSearchEvent(searchEvent: SearchEvent) {
    // add here what needs to happen, for example display data on the screen
}
</code>

I hope you found this solution-based summary useful, and good luck with the forthcoming work.