Mastering Agile: Achieve complete agility with Eijel

Mastering Agile Achieve complete agility with Eijel

Dondon Vizcayno Founder of Eijel

Copyright © 2014 by Dondon Vizcayno

All rights reserved. No part of this book may be reproduced in any form or by any electronic or mechanical means, including information storage

and retrieval systems, without permission in writing from Dondon Vizcayno, except by a reviewer who may quote brief passages in a review.

First Edition

Contents 5 Introduction 6 What You Will Get 7 The Incompleteness Chasm 8 The Ladder 9 Achieve Complete Agility

10 A Sample Project 11 Client Needs A Website 12 And Also Mobile Apps 13 Meet the Project Plan 14 Embracing Agile Development

15 Eijel 16 An Anchor to Reality 17 Creating Your Account 18 Creating Your Projects

20 Project 21 A Context for Everything 22 When a Project is Deleted

23 Sprints 24 Managing all the Sprints 26 Updating and Deleting Sprints

27 Scrum Team 28 Building Your Team 30 When Members and Roles Change

31 Product Backlog 32 What Needs to Be Delivered 34 Reorganizing the Priority 35 Assigning Points and Playing Poker 39 Viewing the Burndown Chart

40 Wiki 41 Maintaining Living Documents 43 Uploading Images

44 Sprint 45 How Much Work Can Be Done? 48 Doing the Actual Work 52 Progressing the Tasks 54 Closing a Sprint 56 Viewing the Burndown Chart

57 Bug Tracker 58 Managing Project Defects

61 Software Engineering 62 Serve the Developers 63 The Value of Quality Code

64 Conclusion 65 A Promise Kept 66 Succeeding in Your Projects

Introduction

What You Will Get

The Incompleteness Chasm

The Ladder

Achieve Complete Agility

What You Will Get

I promise you three things

In reading this book I promise you will get three things:

1. You will know how to do agile.

2. You will know how to achieve complete agility.

3. You will know how to master agile.

And if you give effort in doing item 1 above, I will give you a fourth promise:

4. You will succeed in doing all items above. You will achieve mastery.

The Incompleteness Chasm

Why companies fail at agile

The incompleteness chasm is the main reason why many companies fail at agile.

It is the gap that separates companies successfully doing agile from those trying

and yet failing to get into it. It is something that must be crossed, or the company

will fall short in its transformation and will revert back to its old ways.

You will need a ladder to cross this chasm. The ladder represents a solution to an

incompetency:

1. Companies don’t know how to do agile. They have an idea, but it is flawed.

2. Even when trained, they can’t relate what they have learned to what they

are currently doing.

3. The training will fade like a dream. It is over and trainees will go back to

their jobs bringing a story of an ideal world called “agile”. It won’t change

anything after wards though.

4. And if and when the company finally gets what agile is, it overwhelms

them. They can’t transform. The current is always easier.

5. Companies rarely hire agile coaches. But trainings don’t help them either.

Companies don’t know what to do, and if they know, they don’t know how to do

it.

The Ladder

A ladder to cross the incompleteness chasm

A company successfully doing agile is separated by a mindset and a collection of

practices from another company that fails at it.

This is the chasm that the failing company must cross. How can it get the mindset

and the set of practices present in the other company?

What is the ladder it can use to cross the incompleteness chasm?

Should it hire an agile coach, send the team into more training?

My answer is simple.

I introduce to you Eijel. Eijel is a tool that will empower you to have the mindset

and the practices to emulate the companies successful at agile.

Eijel is a ladder that will help you cross the incompleteness chasm.

Why?

Because it will help you achieve complete agility.

Achieve Complete Agility

A complete solution for doing agile

When a company crosses the chasm and becomes good at agile, it achieves

complete agility. It achieves the minimum to be really good at something. It has

completed the requirements. And with time and practice, becomes master at it.

The requirements for a company to achieve complete agility are:

1. It knows the principles and values behind agile. This is the why of agile.

2. It knows the practices of agile and knows how to do them in real life. This

is the how of agile.

3. It has the will of really following the principles and really doing the

practices.

4. It is doing its best to implement this will, no matter how imperfect.

5. It aims to excel and master the execution of the will.

The will of agile can have a physical manifestation. A concrete embodiment that

represents the abstract concept.

The will of agile is the ladder that helped the company cross the chasm.

The will of agile, in this book, is represented by Eijel.

The next chapter will introduce the context in which you will learn complete

agility.

A Sample Project

Client Needs A Website

And Also Mobile Apps

Meet the Project Plan

Embracing Agile Development

Client Needs A Website

Learning with a goal

It is best to learn new things by solving a problem using the lessons as a solution.

I will give you a client with a project that needs to be delivered using agile.

The client, Urela, is a start-‐up that collects promotions of different shops and

provides them to users through its mobile apps and website. The users will be

categorized as publishers, consumers, and admins.

The publishers will use the website for posting their promos. They can select the

specific shops that provide the promotion and set the start date and end date

when the promotion is valid. They can also set the title, the details, and the image

for the promo.

The client demands that the website be operational after 3 months.

And Also Mobile Apps

Adding complexity to the goal

The client also wants mobile applications for Android and iOS to display the

content posted by the publishers. The user should be able to browse promos that

are nearest to his current location. He should be able to subscribe to shops and

browse promos of shops.

In both the website and the mobile apps, a user should be able to create an

account and must be required to authenticate before he can use the services.

The mobile apps should be delivered within 3 months.

Meet the Project Plan

The old way of doing things

In a traditional waterfall project, the plan to complete Urela will look like this:

Phase Duration January February March

Planning 1 week Analysis 4 weeks Design 2 weeks Development 2 weeks Testing 2 weeks Release 1 week

Most software development projects, if not all, have the goal of producing

working software at the end of the project.

However, you can see from the plan how much is allocated to the part where the

real action is, development.

The first three phases will be filled with the preparation and creation of

documents, which will be later on signed-‐off, as contracts to which software will

be developed and be tested against later on.

This approach has the following characteristics:

1. There is no room for mistake. Signed off.

2. There is no room for unknown, ambiguous, or changing requirements.

3. There is no room for unpredictable events that can affect the plan.

4. There is no room for feedback or client verification. Surprise at the end.

5. The chance of burning developers is very high. Because they are the one

really accountable for the working software. Meet the deadline.

6. The chance of slippage is very high. It was intended to be deterministic.

7. Poor model for long and on-‐going projects. Not sustainable.

Embracing Agile Development

A better approach to software development

Agile development aims to provide the solution to the weaknesses of the

waterfall model. It excels in doing this, and more.

The only problem is that many companies still do waterfall primarily because of

ignorance and because of resistance to change. And those that attempt to move

into agile fall victim to the incompleteness chasm, making them go back to what

worked before, the waterfall.

Here is where Eijel helps you.

We will use Eijel in developing and delivering the product for Urela. You will

learn the principles and actually do the practices of agile by using Eijel.

I am not going to bombard you with facts and info about agile. You will learn a

principle or a practice, only in the right context, and when it is needed in creating

the product for Urela.

We are now about to create our first project.

Eijel

An Anchor to Reality

Creating Your Account

Creating Your Projects

An Anchor to Reality

Eijel is an anchor to reality

Before we start using Eijel in creating the solution for Urela, I would like to

explain why I choose the approach of using a tool in teaching agile development.

The answer is simple.

Eijel is an anchor to reality.

A trainer might use index cards in explaining the concept of the product backlog

in an agile project. For him, the index card is an anchor to reality. The collection

of index cards represents a list, which is a physical manifestation of the product

backlog.

Eijel achieves this, and more.

It does not only represent a manifestation of an abstract concept, but as I have

shared earlier in the topic of the incompleteness chasm, it represents the will of

agile – the principles and practices of complete agility.

When you think of agile, you can treat Eijel as the anchor to reality, the physical

manifestation of the idea.

Creating Your Account

Create your login account

To create you account, go to http://eijel.com/signup. Eijel accounts are free.

Fill up the form and then submit.

Eijel will send you an email to confirm your registration. After this, you can login

to your account.

Creating Your Projects

Manage multiple projects

After you login in Eijel, you will see the Project Dashboard. But as you don’t have

yet any projects, it will show a message that you need to set an active project.

If you will try to explore the different pages in the site, they will give you the

same message. All the features are based in the context of an active project.

You can create multiple projects in Eijel. To create a project, go to

http://eijel.com/projects. It will initially show an empty list.

Click on Add Project and a form will show up. Name your first project as Urela –

Mobile Apps and Website, and then submit.

After saving, the newly created project will show up in your list of projects.

Note that the project automatically made you the Scrum Master. You will learn

later what it means to become a Scrum Master. You will be able to update a

project by clicking the small icon after its name.

In the next chapter, we will study more the details of a project.

Project

A Context for Everything

When a Project is Deleted

A Context for Everything

All features belong to a project

In the previous chapter we created our first project. If you now explore the other

pages in the tool, you will see that they all belong to a project.

The active project is the context of all the other pages. So if you change the active

project, the information in these pages will also change.

If you edit a project, it will show you the following form:

Here you can set the project length and the sprint length. Both of these are in

terms of number of weeks.

• Project Length – the total number of weeks allocated for the project. This

is from the start of the project to the production release.

• Sprint Length – the number of weeks per sprint. You will know later

what a sprint is.

Even though there might be some concepts that are not clear to you, like the

meaning of a sprint, you have achieved something of great importance. You have

created your first project, which is the basis of everything in Eijel.

When a Project is Deleted

Deletion of projects is allowed

You can create, edit, and delete projects in Eijel. But you have to understand

what it means when a project is deleted. As the project is the basis of all

information contained in Eijel, when you delete it, all the other information

belonging to it will be deleted as well.

Sprints

Managing all the Sprints

Updating and Deleting Sprints

Managing all the Sprints

You can create all of the sprints in advance

We have come to the part where you will be introduced to the first agile concept

you will use in delivering the product for Urela – the concept of a sprint.

A sprint is one cycle of work in agile.

The whole span of agile development consists of multiple sprints. In each sprint,

a small but complete part of the whole product is being delivered.

Think in terms of the toy Lego. It is like delivering multiple blocks of Lego at a

time, until all the blocks were delivered.

In waterfall, you deliver the complete Lego structure at the end of the project.

In agile, you deliver a few blocks in every sprint, until all blocks are delivered at

the end of the project.

The typical lengths of sprints are 1, 2, 3, or 4 weeks. You will learn more about

the details of a sprint later on. For now, you will use a 2-‐week sprint for the

product of Urela.

Edit the project and set the project length and sprint length.

You can now create all the sprints for the project. When you go to the Sprints tab,

the list will be initially empty.

Click on Add Sprint and a form will show up. Enter the sprint name, start date,

and end date.

Your list will be similar to below once you have created all your sprints.

There are six sprints in total because the project length is 3 months (equal to 12

weeks) and the sprint length is 2 weeks (12/2 = 6).

Updating and Deleting Sprints

Update and deletion of sprints are allowed

You can update and delete sprints in the list.

To update a sprint, click on the small icon after its name. This will show a form

where you can update the details of the sprint.

Similarly, you can delete a sprint. However, you can only delete sprints that have

not yet started. Once a sprint is already in progress or if it has already been

completed, it is no longer deletable.

Scrum Team

Building Your Team

When Members and Roles Change

Building Your Team

There are only three roles in a Scrum team

We have now reached the part where you will be introduced to the next

important concept in agile development, the Scrum team.

The Scrum team is a group of people accountable for delivering the product.

There are three specific roles in the team:

1. Product Owner – responsible for the product features

a. Continually re-‐prioritizes and refines the list of features

b. Actively and regularly interacts with the team

c. Reviews the result of each sprint

2. Scrum Master – responsible for applying Scrum in the team

a. Educates, coaches, and guides the team

b. Serves the team and removes impediments

c. Supports and empowers the team as it becomes self-‐managing

3. Development Team – responsible for developing the product

a. Is self-‐managing – with high degree of autonomy and

accountability

b. Is cross-‐functional – it includes all the skills necessary to deliver

the work in each sprint

c. Is multi-‐learning – each member continues to learn other

specialties

To add members to your Scrum team, go to the tab Scrum Team. Initially it will

only contain you as the Scrum Master.

Click on Add Member. This will open a form.

Enter the details of the member and click on Send Invitation. The member will

receive an email and he will be able to accept the invitation on his own Project

list.

Once he has accepted, he will show up as a member in the team.

After inviting all the members, your team will look like this:

When Members and Roles Change

You can change roles and members

There are some rules that you need to know in managing your Scrum team:

1. There can only be one Scrum Master – this is mandatory and it defaults to

the creator of the project.

2. There can only be one Product Owner – you will not be able to add more

than one product owner.

3. The development team – all developers will be under this role regardless

of skill set.

Here are the rules for changing the role of a member:

1. The Product Owner cannot be changed to other roles.

2. The Scrum Master cannot be changed to other roles.

3. A Developer can be changed to a Product Owner or a Scrum Master.

4. When the role of a Product Owner or Scrum Master has been taken away,

he will have a role of a Guest.

5. A Guest role is a read-‐only role in the project

Here are the rules for removing a member in a team:

1. The Product Owner cannot be deleted.

2. The Scrum Master cannot be deleted.

3. When a developer is deleted, Eijel smartly manages all relevant data

assigned to him.

4. A Guest can be deleted.

With the rules stated above, you can easily manage the team especially when

new members join or old members leave the team.

Product Backlog

What Needs to Be Delivered

Reorganizing the Priority

Assigning Points and Playing Poker

Viewing the Burndown Chart

What Needs to Be Delivered

A prioritized list of features

I will now introduce one of the most important concepts in agile development,

the product backlog.

If you remember, in a traditional waterfall project, most of the project time is

spent in creating documents that will serve as a contract to which a product will

be developed and tested. Participants in a waterfall project try to freeze this

document as much as possible. It was aimed to be unchanging for the rest of the

project timeline.

There is no such frozen document in agile development. Instead, we collect all

the features for the product and put them in a simple list. This list is ever

changing and very dynamic. It is always prioritized – with the most important

items on top and less important near the bottom.

This list is called the product backlog.

It contains everything that the business thinks it needs for the product. By design

it supports a sustainable and continuous development – as you can always add

and remove and shuffle items in the list. It is in stark contrast to the frozen

document of waterfall.

You will appreciate and understand it more, when you see it in action.

We will now create the product backlog for Urela.

Adding user stories

For a new project, your product backlog will be initially empty. The whole Scrum

team has capability of adding user stories in the list.

You can access it at the Product Backlog tab.

To add a story, click on Add Story and a form will show up.

Enter the title and category for the user story. Categories that you add will be

available next time you add new stories.

After adding several use stories, your Product Backlog will look like this:

Reorganizing the Priority

You can easily reorder the product backlog

One of the important characteristics of the product backlog is that it is always

prioritized. The most important features are always on top and the less

important are near the bottom.

To achieve this, the list should be easy to re-‐arrange.

With Eijel, you can easily reorder the stories in the Product backlog by drag-‐

and-‐drop. This feature is a delightful way of organizing the stories.

Here is how the drag-‐and-‐drop action looks like:

The list automatically saves itself after the reorder is done.

Assigning Points and Playing Poker

Points represent level of complexity

To update a user story or to set its points, click on the icon after the story’s title.

A form will show up after clicking the icon.

Points represent the level of complexity of a user story. By assigning points to all

of your user stories, you can have a measure of the total points for the whole

project. This will help your team later on when predicting how much you can

complete in each sprint, using your previous achieved points.

Here is a suggested approach for assigning points to each of your story:

1. Go through all of your user stories and try to find the simplest as well as

the most complex story.

2. Assign 1 point to the simplest and 5 points to the most complex.

3. Using the two user stories above, assign points to all the other user

stories.

4. If you find a user story as vague, unclear, or extremely complex, assign the

points 100 to it.

5. Repeat the re-‐assignment of points until all are within the 1 to 5 ranges.

Clarify later all those that have a 100 points by checking with the Product

Owner or Scrum Owner.

You are now familiar on how to create and update user stories for your product

backlog.

Assigning points by playing poker

Assigning points is a team activity. Try to include everyone present in the

development team when doing the assignment.

One tool used for this collaborative work is playing poker.

Here is how it works:

1. Give each member of the team five cards containing the following

numbers: 1, 2, 3, 5, and 100. 100 represents complex, unknown, or

ambiguous user stories.

2. The Scrum master will read each of the user stories, give them description

and details so they are clear to all developers participating in the playing

poker.

3. Each developer will assign a number to the user story and will place the

card for that positioned upside down.

4. The Scrum master will ask everyone to reveal their number once all have

placed their cards.

5. If all cards have the same value, that will be the number for the user story.

If there is a large deviation, the Scrum master can ask for an explanation

why a developer thinks differently from others. The developers will

repeat again the process until a consensus is reached.

6. This way, all the user stories will have points.

One common question is – how do you perform playing poker in a distributed

team?

Eijel has a solution for this. You can do playing poker online using Eijel.

Go to the Playing Poker link in Eijel and you will see a screen containing all of the

developers.

The X in the screen means that the developer has not yet assigned a number to

the user story.

There are four buttons in the screen. They represent the following:

• Estimate – click this if you want to assign a number to the user story

• Refresh – this will refresh the page to show the latest state of the cards

• Reset – this will reset your current assigned number to the user story

• Reveal cards – this will reveal the values of all the cards. A reveal will only

happen if all the cards have a check mark, meaning, all have assigned their

numbers

When you click the Estimate button, a form will show up where you can assign

and submit the number.

The numbers above are the complete standard numbers used for playing poker.

Click Submit Estimate when you have chosen a number.

After every estimation the Scrum master updates the story with the points for it.


How much work is left for the project?

You will now be introduced to one of the most important charts in agile, the

burndown chart.

It typically shows the ideal as well as the actual completion of items. For a

product burndown chart, it represents the completion of points.

It is a tool for knowing how the team performs – whether they are delayed, on

track, or ahead of work.

Here is a sample burndown chart for Eijel:

Wiki

Maintaining Living Documents

Uploading Images

Maintaining Living Documents

Documentation exists

Documentation is important, regardless of the chosen methodology. But there is

a big difference between agile and waterfall documentation – documents in agile

are living and dynamic instead of dead and static.

In waterfall, changes to the documentation, once signed-‐off, and once

development has started, is not acceptable. This is in stark contrast with agile

where changes are welcomed especially if they bring business value.

To document in agile, you will not use the tool well known in waterfall, Word.

You are also not going to document everything, only the essentials.

You will use a tool called a wiki.

This format of documentation has the following benefits:

• Anyone in the team can update the document

• The document is available online and can be accessed anywhere, anytime

• It is a living document and can always be corrected and enhanced

Eijel has a built-‐in wiki to make your documentation simple and easy. We value

documentation a lot such that we made all user stories in the product backlog

automatically have a corresponding wiki for it.

Each of these wiki pages also has acceptance criteria. By automatically

documenting each – there is no way ambiguity can stay on a user story. If a story

has a complex business rule, all you have to do is put the information in its wiki

page.

Developers will benefit from such wiki page. They can use the acceptance criteria

in creating the automated tests in their code.

Here is how a sample wiki page with acceptance criteria looks like in Eijel:

If your documentation does not map to any specific user stories, you can make a

wiki for it. We call this kind of wiki an article.

Go to the Wiki of Eijel and you will see the second tab for articles:

Uploading Images

You can add images to your wikis

Most of the time you will need to use images in your documentation. To make

things simple and easy for you, Eijel included a tool for uploading images that

you can use in your documentation.

Go to the third tab of the wiki tool and you will see the place for uploading

images.

Initially your list will be empty:

Click on New Photo Upload and a form will show up. You can now upload a

photo.

Your uploaded photo will show up afterwards in your list.

Sprint

How Much Work Can Be Done?

Doing the Actual Work

Progressing the Tasks

Closing a Sprint


How Much Work Can Be Done?

The challenge of estimation

One of the difficult tasks in waterfall is estimation. Sometimes you would have to

prepare estimates for work that spans several months. Depending on the project

complexity, these estimates could be wrong by days or weeks.

Estimations are also needed for agile development. But you will rarely estimate

time allocation for work that spans 4 weeks. The shorter the span of time, the

more accurate the estimates are.

One of the questions you will face in every sprint is how much work can be

done? Since the sprint consist only of a few weeks, this is not very difficult.

Eijel has a built-‐in tool that can make this even easier. It’s called Capacity

Calculation and it will help you produce highly accurate estimates.

It is accurate because it tries to be empirical as much as possible.

With Capacity Calculation, you will be able to get accurate answers to the

following questions:

1. How much development hours will the team produce in the next sprint?

2. How much hours will the team spend on meetings?

3. How much hours will the team spend on bug fixing?

4. How much hours will the team be off?

You get the answers above by following these steps:

1. Go to Capacity Calculation in Eijel

2. The tool will show each of the developers in the team

3. You will ask each developer the following questions

a. Do you have any planned leaves in the next sprint?

b. How much development time will you allocate next sprint?

c. How much bug fixing time will you allocate next sprint?

d. How much meeting time will you allocate next sprint?

4. Check the calendar for any holidays in the coming sprint. Add the hours

to the Hours Off for each developer.

5. Enter the values for each developer

6. Once all the values are entered into the tool, you will see the total

development time for the team.

You know now that your team can allocate 315 hours to development in the next

sprint.

You will now determine the actual work that can be done for the 315 hours.

Doing the Actual Work

What actual work can be done?

In the previous lesson we were able to determine that we have 315 hours

allocated for development in the next sprint.

We will now determine what we can we can achieve with that 315 hours.

It is time also to introduce an important concept in agile development, sprint

planning.

Sprint planning consists of two parts:

1. Part One – the goal is to determine what will be included in the sprint.

This is done by the Product Owner, with the help of the rest of the team.

2. Part Two – the goal is to determine the number of stories the

development team can deliver and how they will deliver them. The

development team does this.

The output of the sprint planning is called the sprint backlog. It is the list of

stories, and their tasks, that must be completed in the sprint.

Sprint planning is seamless and very easy in Eijel.

For the first part of sprint planning, the Product Owner adds stories to the

sprint by following these steps:

1. Go to the product backlog

2. Add a user story to the sprint by clicking its Start link

3. Once the story has been started, its status will change into In Progress

4. Start all the other stores needed for the sprint

5. Verify that the current sprint has started in the Sprints tab

6. You can now view your sprint backlog in the Sprint Backlog page

For the second part of sprint planning, the development team determines the

actual number of stories they can deliver by following these steps:

1. Notice that each story takes 0 hours to complete. This is because they do

not have any tasks

2. To add tasks to a user story, click on Add Task. A form will show up where

you can enter the title of the Task and its estimate in hours.

3. Once you have completed adding tasks to all of your user stories, your

Sprint Backlog will look like this:

4. You can easily see the total number of hours your team will need to

complete the sprint. The total hours for done and in-‐progress tasks are

also shown. The sprint backlog shows that the team can achieve this

amount of work for the sprint.

At this point, the development team can inform the Product Owner that it can

add more stories into the sprint. They will do this until they have reach a

number where it matches the allocated development time.

Progressing the Tasks

Easy drag-‐and-‐drop

In the previous lesson we have determined the contents of the sprint backlog.

We will now look into the actual progressing of the tasks.

If you have observed, we initially did not assign tasks to developers. These tasks

will be assigned in real-‐time. When they are about to be done. This is a pull

model as compared to the push model of waterfall. The developers assign the

tasks to themselves. This shows the spirit of collective ownership in an agile

team.

Assigning a Task

To assign or edit a task, click the icon after the title. This will show a form.

Every tasks has a status:

1. Todo – the task has not yet been started and has not yet been assigned

2. In Progress – the task is being worked by a developer

3. Done – the task has been completed by a developer

To move a task from one status to another, just drag and drop the item.

Once your team has started working on the tasks, the sprint backlog will be

similar to this:

You can easily see the number of hours for Todo, In Progress, and Done.

Closing a Sprint

Closed sprints can be viewed

Your development team will give its best in completing all user stories in the

sprint. Regardless if all stories were completed, at the last day of the sprint, you

would have to close the sprint. This follows the time-‐boxed nature of activities in

agile development.

When your team has completed all the tasks for the user stories, the stories will

show up as Done in the Product Backlog.

You can end your Sprint by clicking End at the Sprints tab.

After clicking End, the Sprint will be marked as Done.

You will still be able to view previous Sprints by clicking View. This way you can

know what tasks were included and who worked on the tasks of previous

sprints.


How much work left for the sprint

At any time during the sprint, you will be able to view the burndown chart for

the sprint. This chart represents the remaining hours left to be completed for the

sprint. It can also show you how your team is performing against the ideal

burndown.

Bug Tracker

Managing Project Defects

Managing Project Defects

Defects are normal

Defects can occur in any project, regardless of the methodology followed during the development. We consider them as normal and accept them as part of life.

For this reason, we gave our best in creating what we believe is the currently best defect tracking tool in existence. And this tool comes as part of Eijel.

Introducing the Eijel Bug Tracker.

At one glance, you can easily know the state of your project with regards to defects. You know right away the following important statistics:

• Count of Open defects • Count of Show Stopper open defects • Count of High priority open defects • Count of Medium priority open defects • Count of Low priority open defects • Count of Unassigned defects • Count of Fixed defects • Count of Ready for Retest defects • Total number of defects for the project

The Eijel Bug Tracker is a grand example of opinionated software. It will not allow you to sort the columns, as it sorts itself on its own.

It follows the following rules

1. The list is first sorted based on importance – with the highest severity on top. It follows the following order: Show Stopper, High, Medium, and Low.

2. The list is sorted afterwards based on progress – with the newest on top. It follows the following order: New, Assigned, In Progress, Fixed, Ready for Retest.

3. Closed issues are always at the bottom.

Once you have experienced this smart auto sorting, you will never come back to other defect tracking tools.

The bug tracker has also one of the best search functionality among tools – as most of the time – developers are searching for specific issues and do not want to see the whole list. Often they just want to see the issues that are assigned to them or the issues they have worked on.

By clicking on the Search Icon, the search functionality will show up:

With this feature, you will be able to filter on any of the columns in the bug list.

The best features of the Bug Tracker are not limited only on the list and on the search – when you click the title of the defect, it will bring you to a wiki page exclusive for that defect.

In our experience, the true value of a defect tracker comes from user interactions that happen within the defect. This means communication and clarification by means of comments and attachments, all fully supported within the tool.

When you click on one of the issues, you will see its wiki.

The developers involved in testing and fixing can easily attach files and create threaded conversations in this wiki page.

Software Engineering

Serve the Developers

The Value of Quality Code

Serve the Developers

A servant leader is not a boss

In agile development, much emphasis is placed on empowering the development

team. Because at the end, they are the one really creating the product.

The product will be a creation of the development team.

They deserve this credit.

The Scrum Master helps the team achieve their best by removing any

impediments that can block them.

Eijel helps in this goal by providing within the tool a means for managing

impediments.

You will be able to add, edit, and set the status of each impediment. Anyone in

the Scrum team can add impediments.

Notice that they are not assigned to a name, as it is implied that the Scrum

Master will handle the impediments, with help from within and outside the team.

The Value of Quality Code

Reduce undone work

Depending on the maturity and skills of the developers, they would have some

undone work.

Remember that the goal of every sprint is to product a complete set of features.

These features should be potentially shippable to production.

However, there are times when developers can’t follow all the requirements to

produce the level of quality set by the team. These things are called undone

work.

Eijel has the feature for managing undone work.

Notice that the items are not assigned to any specific developer. This is because it

is implied that it is everybody’s business to make sure his or her quality of work

does not include any undone work. This is in the spirit of continuous

improvement.

Conclusion

A Promise Kept

Succeeding in Your Projects

A Promise Kept

You can only master the things you actually do

I have given you four promises at the start of the book.

I promised you that:

1. You will know how to do agile.

2. You will know how to achieve complete agility.

3. You will know how to master agile.

4. You will succeed in all of the above if you give the effort in actually doing

At this part of the book, you know how to do agile.

You know how to actually do it using Eijel.

You have a mental context, an anchor to reality when you think of the following

words:

• Product Backlog

• Sprint

• Scrum Team

• Sprint Planning

• Sprint Backlog

• Impediments

• Undone Work

• Burndown Chart

• And other agile concepts

You can only master the things that you actually do.

By giving effort in the part of actually doing, you will gain mastery.

Succeeding in Your Projects

Create your free Eijel account

I created Eijel with the goal of creating the simplest tool that manages agile projects from vision to product release.

I now invite you to give Eijel a try in actually doing your agile projects.

Eijel is free.

By using the principles and practices you learned in this book, and by actually doing agile with the help of Eijel, you will succeed in your software development projects.

Thank you for taking this learning journey with me.

If you would like to learn more, you can visit my blog at:

http://completeagility.com

You can see my contact info at:

http://eijel.com/contact

Feel free to add me in LinkedIn at:

http://sg.linkedin.com/in/dondonvizcayno

Mastering Agile: Achieve complete agility with Eijel

Software

Transcript of Mastering Agile: Achieve complete agility with Eijel