RESEARCH SYNTHESIS

Lean_Mobile_App_Development_----_Chapter_4_An_Agile_Workflow_in_a_Nutshell.pdf

Home >Business & Finance homework help >Operations Management homework help >RESEARCH SYNTHESIS

4 An Agile Workflow in a Nutshell

In this chapter, we will discuss Agile to find out what it is and how we can benefit from it.

Many companies have moved away from the waterfall methodology when developing software. They have switched to a more adaptive methodology such as agile, and for a reason. The waterfall methodology just follows the original plan and requirements and there is little to no room for change. It is obvious that such an approach is not going to work for your app. Unless you have a crystal ball, and you are right from the beginning, this approach most likely is going to lead to a lot of waste.

An agile workflow accommodates change through adaptive planning, promotes faster software development and delivery, and is rooted in a continuous improvement methodology. That is exactly what you need to validate your assumptions, and it is what you need to pivot when necessary.

There are a lot of implementations of agile software methodology. They all focus on the ability to adapt and to deliver releasable software as quickly as possible. Some of them focus on managing the workflow in particular. One of the most common is Agile Scrum. We will have a closer look in this methodology to see how well it works with Lean software development.

Specifically, in this chapter, we will learn more about the following topics:

An Agile workflow Lean software development, Kanban, and Scrum Epic, stories, and tasks The Scrum team and the daily standup Backlog refinement and the definition of Ready The sprint planning The definition of Done

Drongelen, Mike van, et al. Lean Mobile App Development, Packt Publishing, Limited, 2017. ProQuest Ebook Central, http://ebookcentral.proquest.com/lib/harrisburg-ebooks/detail.action?docID=5165112. Created from harrisburg-ebooks on 2020-12-01 07:18:52.

C op

yr ig

ht ©

2 01

7. P

ac kt

P ub

lis hi

ng , L

im ite

d. A

ll rig

ht s

re se

rv ed

An Agile Workflow in a Nutshell Chapter 4

[ 39 ]

The sprint review, planning, and retrospective Tools that you can use, such as Trello and Jira

An Agile workflow Using an Agile workflow helps your team to be flexible and able to quickly respond to changes. It also means that your team is self-organizing, and that members of the team are able to deliver early and often.

Good communication is fundamental to Agile and the members of your team have to collaborate well with the product owner, stakeholders, and each other. The users of your app need to also be involved, right from the beginning. Their feedback is vital, and is critical for you to make the right decisions for your app development. Finally, at any time, you should be able to deliver a working version of the software. A good git workflow and being able to continuously deliver are key elements here. You will read more about this in Chapter 19, Building an Unfair Advantage.

What all agile methods have in common is that they promote the ability to change, continually learn as you go, and to delivery software as quickly as possible.

Some agile software development methodologies are as follows:

Lean software development Kanban Scrum

There are many more approaches, but these are the most interesting ones. Of course, Lean software development has the focus of this book. The key elements for this methodology are:

Delivering as early as possible Making decisions as late as possible Gathering early feedback through Continuous Delivery

We will learn more about all these elements in the next chapters. Unlike the other methodologies, Lean is more focused on avoiding waste.

But, let's start with the basics first. Lean software development, Kanban, and Scrum have a lot in common. In this chapter, we will have a closer look at Kanban and Scrum, and discuss Lean in the rest of the book.

C op

yr ig

ht ©

2 01

7. P

ac kt

P ub

lis hi

ng , L

im ite

d. A

ll rig

ht s

re se

rv ed

An Agile Workflow in a Nutshell Chapter 4

[ 40 ]

Kanban Kanban is a way to visualize the flow and the current state of each action. Every participant can see the progress from start to finish. Team members start working as capacity permits. Unlike Scrum, there is no need for forecasting as it is a continuous process.

Kanban is a methodology that uses visualization with a Kanban board. The method originates from Lean manufacturing (inspired by Toyota), but it is often used for software development as well. In its most basic shape, it contains three columns, reflecting the state of each item—To do, Doing, and Done. Note that it is important to keep the amount of items in the Doing lane to a minimum. People are, in fact, not really good in multitasking, although they think they are. Switching from contexts will increase waste and should be avoided.

All you need to create a Kanban board is an empty wall and a number of post-its, but you can also use a software service such as Trello. If you sign up at www.trello.com, you can set up your own project for free and define a number of lanes. In this example, set up with Trello, it is clear to everyone which state each item is in. You can define additional lanes where needed:

In Kanban, the flow of work is continuous, but in Scrum, work is divided into events that last for a specific amount of time. Scrum uses Kanban boards, but adds a forecasting element to it.

Scrum Scrum is a way of software development management that is designed for small teams. The members of the team complete a number of actions during cycles of a fixed duration called sprints. The sprint is restricted to a specific duration. The duration is normally between one week and one month, with two weeks being the most common. The fixed length of a sprint is important because it allows the team to determine their velocity, or rate of speed at which they get work done, after a couple of sprints.

C op

yr ig

ht ©

2 01

7. P

ac kt

P ub

lis hi

ng , L

im ite

d. A

ll rig

ht s

re se

rv ed

https://trello.com/

An Agile Workflow in a Nutshell Chapter 4

[ 41 ]

At the beginning of a sprint, the team decides which tasks can be accomplished in the given timeframe. After a number of sprints, it is easier to make appropriate estimations, since the team will have a better feel for the work they do. Knowing the velocity of a team will make it easier for the team to make estimations on the stories, and to make sure the team can truly commit to all stories defined for a given sprint (that it is doable).

The methodology places emphasis on a workable and potentially shippable product at the end of the sprint. This means that the software has not only been developed, but also that it has been tested and integrated. It should be possible to demonstrate the app, to perform an ad hoc distribution to beta testers, and even to publish the app or the update in the Play Store or App Store.

Epic, Stories, and Tasks An epic is a large amount of work that is almost always delivered over a number of sprints. An epic often is a high-level description of functionality. It contains no specific details. Through customer feedback, the team can learn what is needed to complete the epic. An example of an epic may be: As a user of the app, I want to be able to set up and to review a Business Model Canvas in an app.

An epic is a high-level description of the feature or features. Since specific details are missing, the team needs to learn more about the epic, and often this will generate multiple stories. solve the problem that the epic defines, can become a story.

A user story should be as small as possible while it is still delivering business value. User stories are often written from the perspective of the users of the app, and they are described in a natural language. They describe a particular feature in only few sentences that outline the desired outcome. This can help the team to understand the objectives and the context of a specific desired feature.

A story may have one or more tasks. These tasks can describe in a very specific way which actions need to be taken in order to complete a story. An example of a task could be to develop an edit box where the user can edit text or add a Save button and persist the edited text. It is also important to specify the acceptance criteria. If you have clearly defined what the result of the implementation of a story or task should be, it will become easier for your testers to accept (or to decline) the new feature.

C op

yr ig

ht ©

2 01

7. P

ac kt

P ub

lis hi

ng , L

im ite

d. A

ll rig

ht s

re se

rv ed

An Agile Workflow in a Nutshell Chapter 4

[ 42 ]

Scrum team For the Scrum approach, you will typically find three main roles, although some organizations do define others in addition to the ones listed here:

Scrum master Product owner Development team (and that includes the testers)

Scrum teams have one product owner. He or she is responsible to ensure that the team delivers business value that is required. To do so, the product owner is the connection between the stakeholders and the (technical) team. The product owner is primarily focused on the business side (problem definition). The product owner defines the user stories and adds them to the backlog.

The user stories describe the features that need to be implemented. You can think of a backlog as a to-do list. The team has to commit to these items, and each item needs some refinement to make clear what exactly is needed to implement a specific feature. It is the team, focused on finding a solution, that will give the feedback for this. The backlog also needs prioritization. This prioritization is often based on how important specific features are for the end user (the value).

The product owner demonstrates the app to stakeholders, and defines the milestones and releases of the app. He or she also informs stakeholders about the development of the app, and plays an important role at negotiation of funding, scope, and priorities. The product owner needs to be able to communicate effectively. He/she needs to find a balance between the stakeholders' (and end users') interests, and the collaboration with the members of the team to make sure they develop the right solution for the problems that stakeholders find or define:

This results in information on two totally different levels. Stakeholders are often only interested in obtaining a solution for the problem. However, the development team prefers to hear feedback with as much detail as possible, so they will know how a feature should be implemented.

The developers, testers, and others are all members of a self-organizing team. They will care for all tasks related to delivering or updating the app. Tasks that you can think of are:

Design UX Analysis Technical research and development

C op

yr ig

ht ©

2 01

7. P

ac kt

P ub

lis hi

ng , L

im ite

d. A

ll rig

ht s

re se

rv ed

An Agile Workflow in a Nutshell Chapter 4

[ 43 ]

Code review Testing Documentation

The team commits to a sprint, and is responsible for delivering an updated and working app at the end of each sprint. It does not make a difference whether the update is a external or an internal one. It should always be possible to demonstrate the new features to the stakeholders.

Another role is that of the Scrum master. The Scrum master makes sure that the Scrum framework is followed. He coaches the team to make sure that the team delivers all the features for a sprint. He educates the team and the stakeholders about the Scrum principles. The scrum master helps the team to remove (or to avoid) internal or external impediments that might impede a sprint's success.

The Scrum master also maintains the backlog, and ensures the stories are clear and that they are defined in a nonambiguous way. It is important that the team understands the objectives of a story so it can actually make progress. Other important responsibilities of the Scrum master are helping the team to come up with the definition of Ready (when the development team can begin work on a story), and to come up with the definition of done (when can a new feature be rolled out). We will have a closer look at these definitions later.

The daily stand-up The team holds a stand-up (also known as Daily Scrum) on each day of a sprint. It is a short meeting that is often limited to 15 minutes (timeboxed). It happens at the same time and place every day, even when some team members are missing. Anyone is welcome to join, although only team members should contribute.

During the stand-up, each member provides an answer to these three questions related to the context of the sprint:

What did I do the last work day? What do I plan to complete today? What impediments do I see that prevent me or the team from meeting our sprint goal?

Since the meeting is timeboxed, it is important that each member focuses on these three questions alone and there should be no detailed discussions. The Scrum master will be notified about any impediment mentioned during the meeting.

C op

yr ig

ht ©

2 01

7. P

ac kt

P ub

lis hi

ng , L

im ite

d. A

ll rig

ht s

re se

rv ed

An Agile Workflow in a Nutshell Chapter 4

[ 44 ]

Impediments are blockers, risks, dependencies on other teams or partner companies, and possible or expected delays. The Scrum master is responsible for removing impediments, or finding someone who is willing or able to find a resolution. A Scrum board displaying the actual impediments can be useful to note this, as finding a solution is something that needs to happen outside the stand-up.

Backlog refinement Before a sprint can start, the sprint backlog needs to be defined. What stories need to go into the sprint? To provide an answer to that, the team needs to review the product backlog. The product backlog contains all actions (stories) that need to be taken to complete the product (the app). First, they need to be refined before the team can commit to them.

Each story needs an estimation of the amount of work involved. This estimation is usually expressed in story points, not hours. The story points relate to the expected complexity and amount of work. Typically, a specific and clear action such as Edit a text on a button will be defined as one story point. This creates an anchor for defining other more complex stories. All estimated stories will be derived from it.

To be able to assign story points, the story needs to be clear and well understood by the team. Planning poker is often used to let the team members make estimates. You can use cards for the estimates, or use one of the many apps that are available.

Here is an example of such an app, called Scrum Time. You can find it on the Play Store or App Store.

C op

yr ig

ht ©

2 01

7. P

ac kt

P ub

lis hi

ng , L

im ite

d. A

ll rig

ht s

re se

rv ed

An Agile Workflow in a Nutshell Chapter 4

[ 45 ]

As a user of the app, you can pick a card with a number that you will show to the rest of the team. If the estimated points differ too much between the team members, then they need to discuss why they think the implementation and testing of a story will take more (or less) time. Perhaps a member of the team has knowledge that the rest do not have, or maybe he is looking at the story in a different way. New insights can contribute to a better estimation.

The numbers to pick from are typically derived from the Fibonacci sequence. In mathematics, the Fibonacci sequence is characterized by the fact that every number after the first two is the sum of the two preceding ones. The reason why these numbers are used here is that the larger a story becomes (having more story points), the more difficult it will be to make an exact estimation. If you have no clue, you can always play the question mark card, or if the action related to the story is infinite (think of delivering support), then there are cards for that as well. And yes, if you are thirsty, there is always the coffee/pause card that you can play.

The 1,2,3,5, and 8 cards are the ones that are played most often. Stories with more points very likely need to be split up into multiple smaller stories to reduce risk.

Definition of Ready It is the responsibility of the product owner to add stories to the backlog. During the backlog refinement, the team has to provide feedback to get each story into an actionable condition. The stories at the top of the backlog, and that are candidates for the upcoming sprint, must be ready. Having a clear Definition of Ready (DoR) is important if you want to raise the productivity of your team.

The stories need to be immediately actionable. If they are not, how could one implement or test a feature? It must be clear what the objectives are, what needs to be done to make it happen, and what amount of work it takes. For example, the backlog may be filled with user feedback such as, "We want to able to create new invoices quicker." This statement clearly defines a problem, but if we want to work on it, we need more specific information. The team must be able to determine what needs to be done. If we could state that adding a button for creating new invoices to the main screen is the solution, then we can make an estimation for it and start working on it. A story that is ready is clear, concise, and actionable.

C op

yr ig

ht ©

2 01

7. P

ac kt

P ub

lis hi

ng , L

im ite

d. A

ll rig

ht s

re se

rv ed

An Agile Workflow in a Nutshell Chapter 4

[ 46 ]

Sprint planning The team selects the items that have the highest priority and that are ready for work to start. The team can only commit to stories that have clear objectives, and that are not blocked by anything else. Also, the team can commit only to a limited number of stories during a sprint. That means that the team needs to know how much work will be involved with these stories, and how much work can be done during a sprint.

To determine how much work can go into a sprint, we need to know the team's velocity, which is a number that expresses the total effort a team is capable of in a sprint. That number comes from evaluating and determining the average amount of work done (sum of story points) in previous sprints. Of course, seasonal influences (holidays) and other things that could determine the team's capacity need to be taken into account. No extra work should be added to a sprint once the team has committed to start.

Definition of Done The Scrum framework determines that each story should be done at the end of every sprint. In an ideal world, the Definition of Done (DoD) means that each story has been developed, tested, and approved, and that your app's current state is in a potentially shippable state. We still need to define exactly what that means. The DoD may vary from one Scrum team to another, but must be consistent within one team. The DoD can help to ensure that features are implemented and tested and that their addition will truly contribute to a shippable app.

The definition could also contain a list of other actions, such as code reviews, running unit tests and UI tests, writing documentation, and ad hoc or public distribution. Each action should add a verifiable value to the product. This helps the team to focus on which features matter while avoiding activities that are wasteful.

Sprint review, planning, and retrospective There are a couple of events at the end of each sprint: the sprint review and the sprint retrospective. There is also the sprint planning for the next sprint.

At the review, the team reviews all the completed work and demonstrates it to the stakeholders. They also review the work that has not been completed yet.

C op

yr ig

ht ©

2 01

7. P

ac kt

P ub

lis hi

ng , L

im ite

d. A

ll rig

ht s

re se

rv ed

An Agile Workflow in a Nutshell Chapter 4

[ 47 ]

For the upcoming sprint, there is the sprint planning event. During this event, the team and stakeholders work together to determine which features can be delivered in the sprint, and how it can be achieved.

The retrospective is used to reflect on the past sprint so that a team can learn and improve over time. In general, the two main questions asked of each member are:

What went well during the sprint? What needs to be improved in the next sprint?

The Scrum master facilitates the event and helps the team to determine what actions are needed in order to improve things. For the retrospective, you can use a tool such as Jira, but often using post-its works much better.

Anything that needs improvement will be prioritized, and actions will be defined for the top three issues.

By now, you have a basic understanding on what the Agile workflow and Scrum is about. To learn more about Scrum, you can visit https://www.scrum.org.

Tools that you can use You can use a number of tools to support, automate, and visualize the process. Jira and Agilefant are well-known web-based solutions that can help you define epics, stories, estimates, and sprints. Most tools also have an option to add (sub) tasks to stories. Although a story should be the smallest amount of work possible, it can still be useful to divide them into multiple subtasks.

You can find more information about Jira at https://www.atlassian.com/software/jira. Agilefant can be found at https:/ / www. agilefant. com.

The following is an example of Jira displaying a Kanban Board. Jira comes with good support for Agile and Scrum in particular, while Agilefant is more method agnostic:

C op

yr ig

ht ©

2 01

7. P

ac kt

P ub

lis hi

ng , L

im ite

d. A

ll rig

ht s

re se

rv ed

https://www.scrum.org

https://www.atlassian.com/software/jira

https://www.agilefant.com

An Agile Workflow in a Nutshell Chapter 4

[ 48 ]

If you just got started, you might not need all these tools yet. In that case, a whiteboard and a number of post-its are sufficient to create your first Kanban board. This board comes in handy when all members of your team work in the same space. When you have a distributed team, Trello is a good choice. It is not as advanced as Jira, as it does not have support for Scrum, but it is a great way to get started in an organized way.

To start with Trello, sign up at https:/ /trello. com/ , create a new team and project, and you are ready to start. Just as is the case with Jira, you can create multiple lanes in Trello, each reflecting the actual state of a card/item. As said before, you can start with a To do, Doing, and a Done lane. However, you soon will find out that these states alone are not going to be sufficient.

If you configure the following lanes, you will have a decent start for an agile workflow in Trello:

Backlog Ready (the story is clear, well understood, and has no impediments) In development (developing and testing) Test Done (it has been tested and approved)

C op

yr ig

ht ©

2 01

7. P

ac kt

P ub

lis hi

ng , L

im ite

d. A

ll rig

ht s

re se

rv ed

https://trello.com/

An Agile Workflow in a Nutshell Chapter 4

[ 49 ]

It may look like the following example. You can also add more lanes to it, such as code review, or whatever suits your organization best:

All stories start as a card in the Backlog lane. Once you have clearly defined what the objectives are, the story is ready for development. You can then move the card to the Ready lane. When a developer picks up the story, he will move the card to the Development lane. At the moment, the implementation has been completed and the unit test(s) for the story succeed the card will be moved again, for example, to the Test lane or, optionally, to the Code review lane first:

If a manual or automated UI test for the implemented feature succeeds, then the story can be considered as done, which correspond to the final lane.

This is, of course, just a simplified process, and tools such as Jira offer much better support for Agile and Scrum workflows, including epics and estimations. Nevertheless, Trello is still a good start for newbies. Trello comes with options to add labels and to define an expiration date and time. You can use it for multiple purposes, even to set epics and estimations, as shown in the preceding screenshot. The epics appear as green labels and the estimated story points appear in blue.

In the later chapters, you will read about other tools that can help you to organize an agile workflow. Think of Confluence. Just like Jira, it is a Jetbrains web-based solution that allows you to organize all of your documentation and discussions.

C op

yr ig

ht ©

2 01

7. P

ac kt

P ub

lis hi

ng , L

im ite

d. A

ll rig

ht s

re se

rv ed

An Agile Workflow in a Nutshell Chapter 4

[ 50 ]

Summary In this chapter, we saw a brief introduction to Agile and Scrum workflow and how you can benefit from them. We now know how you can use Kanban to visualize the state of each item of work, and what some possible implementations of the agile workflow are. In particular, we had a look at Scrum, the different roles that exist, and what planning and estimation a Scrum environment requires.

You might think that all of this makes sense, but it will be difficult to implement if you have limited resources and time. What can we do to keep waste to a minimum, but still act in a very pragmatic way? You will read all about that in the next chapter.

C op

yr ig

ht ©

2 01

7. P

ac kt

P ub

lis hi

ng , L

im ite

d. A

ll rig

ht s

re se

rv ed