Archives for

Agile Tool Eylean Introduces a Free Personal Edition

Agile Tool Eylean FreeIt is Cyber Monday and there are a lot of deals in the market. But we have something special for you. How about a 100% discount for unlimited time? Yes, you understood it correctly – starting from today Eylean is free for your personal use!

Since our start in 2010, hundreds of companies have chosen Eylean for their enterprise projects, including giants like British Petroleum, Hitachi, Velux and others. Using Eylean helps them implement Scrum, Kanban and Scrumban, and stay agile in the world of ever-changing requirements. We think it is time for everyone to have an opportunity to take advantage of Eylean and make their development process faster, easier, and more transparent. Therefore, we are making a personal edition of Eylean agile task board free of charge.

Personal edition of Eylean includes a fully fledged task board, reporting, and analytics. You will be able to download the software and manage your personal projects with a highly visual, Scrum– and Kanban-optimized task board. Personal edition also includes time-tracking functionality, as well as export to Excel and Outlook, so that you are able to use the agile tool in the most productive way and stay on top of your personal projects.

So get the new Eylean Personal Edition now – and get things done!

Read More

5 Reasons to Adopt Agile in Your Company

The concept of agile is not a new one. Its origins come from the 1990s, but some organizations still have not adopted agile despite its many inherent benefits. Agile believes in the faster adaptation and iterative life cycle, and brings the beauty of constant refinement of the goals, requirements and solutions during the development process.

However, if you are still undecided on whether to choose agile as your preferred method of software development, or if you need a few arguments to convince your colleagues, perhaps these five reasons will help you make a quicker decision:

Agile adapts well to changing priorities. Implementing agile ensures that your software development is up to date. Unlike the traditional software development methods, you do not need to spend a number of years in the development process only to realize that the world has actually moved past the original project requirements. With agile, your company will be better able adapt their portfolio to meet the ever changing business priorities. In agile, working software is delivered on a regular basis. The high value features are prioritized first against lower value features. With Agile you do not have to wait years to discover you have built an obsolete product.

Agile responds quickly to customer needs. Unlike in traditional software methodologies, the customer changing his priority midway does not affect the entire project drastically. Agile makes use of iterations so that the customer can access the progress of the project at any given time. Agile helps the project development team deliver products based on the feedback they receive from the customers.

There are fewer defects with agile. There far fewer defects associated with agile than with traditional methodologies. It is far preferable to test software in smaller installments as it is being developed than develop a whole project and test it at the last stage. Iterations make it possible for the defects and errors to be detected earlier and corrected. This makes it possible to have products with zero defects.

Marketing is faster with agile. It is possible for products made though agile to reach the market faster than those made through traditional methods. Research shows that there is a 37% chance of products developed using agile reaching the market faster than using traditional software development methods. In a competitive environment, it is essential to get the products to the market faster than the competition. Agile leads to better productivity as well as having the right scope delivered at the right time.

There is greater transparency with agile:  The use of agile inherently leads to great transparency between the team members. This is because of the improved communication between team members. Communication can take place daily in which each team members update on deliverables and make commitments to better quality products. Through communication, problems are discovered, discussed and resolved faster, hence bringing higher transparency to the company.

Do you know other ways how agile benefits organizations? Share them in the comments!

Read More

Introduction to Ruck (or Loose Scrum) Software Development

Ruck software development system – which is sometimes called Loose Scrum – is an emerging agile methodology that is based on Scrum, but has some features which sets it apart. Ruck methodology was coined by Microsoft’s ALM Rangers team and was called Ruck because in the world of rugby it means “Loose Scrum“. The key principles of Ruck are transparency, inspection, adaptation and collaboration.

Transparency: In Ruck, visibility is key. The methodology was developed by virtual teams that are working on the project only part-time and therefore addresses the challenges of operating in a virtual environment – including having colleagues from different time zones, who are working in a virtual or part-time fashion, and have diverse cultural backgrounds. Therefore, it is important for the project manager to have a well-defined idea of what “done” means so as to avoid any misrepresentations and confusions.

Inspection: With inspection it is easier for mistakes and patterns that will not favor the project to be spotted earlier on. This scenario makes it easy to curb a potential problem before it becomes full-blown.

Adaption: Ruck is a software development system that is still at its early stages. It is essential to be open to changes and adaptations when experimenting with variables and unknown quantities.

Collaboration: Members of the team should be able to collaborate openly irrespective of their time zone. Collaboration and open communication can take place at any time it is convenient for the entire team members.

Ruck is often used by teams operating from different time zones which cuts across different cultures. It is therefore a challenging task right from the planning stage, to the collaboration proper and down to the tracking. Ruck team has some feature areas with the Ruck Master being in charge. The role of feature area lead makes it possible to coordinate team members from different time zones and cultures. This type of team structure makes it easy for the Ruck master to delegate project management and tracking tasks to feature leads. The core team thus has time to focus on tweaking, grooming and refining the Ruck framework and other supporting infrastructure.

A feature lead is the person in charge of the feature area. This person is part of a core team comprising of other feature area leads, project managers, subject-matter experts and of course the Ruck Master. Iterations in Ruck often involve 4 weeks duration – as it might be difficult to have shorter iterations due to resource constraints that usually accompany part-time work.

Unlike Scrum, stand-up meetings may be capped at 30 minutes. This will allow time for more collaboration between team members. Again, stand-up meetings are more of ad-hoc in nature rather than regular.

Ruck development is a work in progress that is empirical at best. It is currently an evolving process that takes into consideration the virtual and part-time team members in a highly distributed environment. It is hoped that Ruck will be a framework that addresses the challenges of virtual teams – and will be reusable, transparent and predictable.

Read More

5 Myths About Agile Development

As Agile development becomes increasingly popular, there are also some myths that often surround Agile. Some of these myths arise from a misunderstanding of what Agile is and how it is practiced – and this post aims to address the most frequent ones.

1. Agile does not use documentation

This is perhaps one of the most famous myths about agile. The most common excuse given for the propagation of this fallacy is the line in the Agile manifesto that says “Working software over comprehensive documentation”. This is probably one of the most misunderstood sentences in the manifesto. The question of how an Agile framework like the Scrum can survive in highly regulated environments like the finance industry without documentation beats the imagination if this myth were to be true. The truth is that Agile processes uses documentation, but only the one which adds value and benefits the project, instead of documentation for the sake of documentation.

2. There is no control in Agile

One of the biggest fears people encounter while dealing with Agile is that of losing control of their teams. The misconception that often arises is that Agile is all about anarchy, because the team is self-organized. This is far from the truth. It is true that the role of the management does change in Agile but they still play a crucial role in within the company. It is the role of the manager to make sure that the goals, visions and constraints of a project are well-defined. When these roles are well-defined, it will be easy for the team to be self-organized.  So in reality, there is nothing to be afraid about in self-organization. In fact, it should often be encouraged as it makes the work of the manager easier and the process more effective.

3. Agile is faster

Naming an iteration a “sprint” does not mean it is faster than other processes. While it may be true that Agile as a whole makes development process faster, the initial process might be anything but fast. Quality takes time to accomplish and it needs time. Agile methodology ensures there are lesser bugs to fix and the software is sustainable. Agile also aims to minimize waste, which helps to make sure that the process is not stuck with the tasks that do not have a purpose.

4. Agile is a silver bullet

While many may wish this to be true, in reality there is no silver bullet in software development. Agile is about the people in a team; you need to have the right people in a team to create awesome products. Even the Agile manifesto said as much “Individuals and interactions over processes and tools”. Agile can make the right team more productive and the process more adaptive, but it will not fix all the problems of an organization.

5. Agile is easy

Finally, it is often said that agile is easy. When a team switches from traditional software development methods to agile, it is sometimes possible to deliver a quality shippable product in four weeks – that was previously done in one year. But it does not mean that software development has now become easy. Agile process eliminates some of the redundant work – but developing an awesome product can take a lot hard work in spite of whether Scrum, Kanban or another agile methodology was used.

Read More

Getting Started With Scrum Task Board

We recently covered how to get started with Kanban boards, and this post aims to help you if you decided to start using Scrum. The first step to getting started with Scrum is to do it with a pilot project. This pilot project will help you get the hang of how it is done and then roll it out to the wider organization. Before you rush out to start trying your hand on Scrum , it is good that you be aware of some organizational problems that may hold you back. Some of the most common issues with using Scrum include lack of training and infrastructure, adoption in silos, and overcomplicating the process. Once you have got these problems out of the way, you are good to start with the Scrum task board.

Below are three basic ideas to help you get your Scrum task board off the ground.

1. Choose the product owner 

Finding out if the product you intend working on has an owner is a great way to help you and your team get organized. Your team needs to determine at the earliest stage whose responsibility it is to make any form of changes to the product. It is also important to know who wrote the first business requirements and this will of course point you to the person who knows the product best and who is speaking from the customer point of view.

2. Get the product backlog organized

Now that the new product owner has been identified, it is time to get together with major business representatives. The purpose here is to plan a workshop that will educate and also help your team prioritize your product backlog. The project requirements should be rephrased into stories. If you are lucky, the product owner may already have the product backlog ready. In case your product owner does not have a story ready, start thinking of how to organize a second workshop to transfer their requirements into stories.  The stories should contain a detailed description of what your clients want and how it will benefit the product.

3. Get a task board

So far, you have succeeded in having your backlog ready and a motivated team to work with, the only thing left is a task board. You may consider a virtual task board, especially if some of your team is located offshore. Alternatively, you can use a magnetic whiteboard for this purpose, which allows most items to stick on it. Or, you can build your boards directly on the wall. To help you choose, we reviewed the pros and cons of virtual task boards previously on our blog.

Enter your vertical and horizontal lines with signs for name tags, columns, team pictures and status tags and you are set with your Scrum task board. Good luck!


Read More

5 Common Mistakes When Adopting Agile

Agile methodologies offer companies a lightweight framework to execute their software and other projects. It is therefore not a surprise that companies are increasingly looking to adopt agile as their preferred method of software development. Although the benefits to adopting agile are numerous, during the process some of the drawbacks emerge as well. In order to make sure that you do not make one of those mistakes when adopting agile, below is a quick rundown of some of the more common pitfalls that arise when adopting agile.

1. Lack of proper training and education

This is probably the most common mistake made by organizations hoping to adopt agile. The teams sometimes believe that they can cut corners by saddling the internal team with the responsibility of learning scrapes of agile and passing on the information to the members of the team. It is important to take into account that the team members are busy with their daily jobs, and might not have the time to ensure smooth adoption of agile. It depends on the situation, but it often makes sense to invest a bit of time into learning agile methodology of choice, or bring in experienced agile coaches and consultants.

2. The Silo syndrome

The Silo syndrome occurs when the evolvement of Agile is out of sync with what is practiced in the rest if the organization. The result is that different teams in the company are trying out and developing different methodologies and standards until there is outright confusion. While it is fine to start with a pilot team in an organization when adopting agile, the processes in the rest of the organization should not be ignored as well.

3. Abandoning other aspects of the business

This mistake in evident when the company ignores other areas of their business and focuses too much on their technology teams. While agile is often about software methodology, it is also about a shift in corporate culture as well as the building of infrastructure for the overall wellbeing of the company. Shift in corporate culture should not take place on Agile teams alone, it should also happen in other departments and offices in the company.

 4. Over-complicating the process

Agile adoption is a simple process that need not be complex. When there is an inclination to the introduction of new policies, additional process and extra layers of management, it can easily cause block adoption or at least decrease the adoption speed. When adopting agile, it makes sense to cut out the extra processes and policies, and make the process as simple as possible.

5. Failure to have proper infrastructure in place

Finally, when the company does not take into account the infrastructural changes needed to support scaling agile processes, it might be difficult to establish agile as the project management methodology for the organization. The infrastructure, including agile tools and the work processes, might have to be adjusted, especially as agile becomes the methodology of choice for the whole organization.

Therefore, if you are looking to adopt agile, make sure you do not make these mistakes – and good luck!


Read More

Setting Up a Kanban Board

So, you have decided to start using Kanban. Since there are often a lot of questions on how to get started, here we provide a simple set of tips for someone just starting out with Kanban:

1. Decide whether you want to use digital or physical board

First of all, decide if you are going to use a digital or physical board. Digital boards or software – such as Eylean – have a lot of advantages over physical ones, but you should decide which one is best for you. If you need additional help, we have covered the main aspects of choosing the right board in this blog post on electronic vs. physical task boards.

2. Prepare a simple board structure

Once you decided on the right board for you, prepare a simple task board which consists of three columns: “To Do”, “Work in progress” and “Done”. This is the basic structure of Kanban you will use to sort your tasks and items. If you have a multi-stage process – for instance development and testing – you might split these processes into separate columns later on, but for now just start with a simple board for one stage of your process.

3. Set a work in progress (WIP) limit

One of the key aspects of Kanban is that the number of items in progress is limited and therefore no other item can be started until the existing items are completed. Therefore, you need to decide whether you want to allow some multitasking or not. If you decide to go without multitasking, you should add the WIP limit that is equal to the number of people on your team. If you want to add a bit of flexibility (most teams do), you should add the WIP limit by several items higher than there are members of your team.

4. Embrace the pull principle

The next important concept to grasp is the Pull principle. The idea behind the Pull principle is to make sure that the team members can choose the items to work on. It works in the following way. You put the task cards on the board, but you do not assign them to anybody. The team members pull the tasks which they would like to work on and are capable of working on, and start working on it.

5. Set up prioritizing and planning processes

Finally, make sure that you develop a process for item selection and prioritization on demand. One of the approaches to that is doing small planning meetings, when the team discusses and decides which of the items are the most valuable and should be done next. The planning meetings can be done when the number of items in the backlog reaches a certain number – for example, less than three. This will make sure that you will not over-plan – but will also not run out of the items in your backlog.

You can always evolve and adapt your board when you master the basics – but this checklist should help you started with Kanban. Good luck!

Read More

Scrum vs. Kanban vs. Scrumban: Boards, Rules, and Who Should Use It

In the previous blog posts we discussed the team members, roles, work routines, planning, estimation, scope, and other aspects of Scrum, Kanban, and Scrumban.

There are a few other differences between the methodologies, which do not necessarily fall into one of the categories above. In this blog post we review the boards used in each case, prioritization, rules – and, most importantly – who should use which methodology.


The Scrum task board is defined and reset each sprint. As the backlog items move from backlog to completion during a sprint, and are planned separately for each sprint, the board is reset after the sprint is over.

Kanban and Scrumban boards remain persistent and are not reset, as there are no pre-set periods for backlog item completion.


Prioritization in Scrum is done through backlog. Therefore, the Scrum backlog is ordered and the most important items therefore end up being done first.

In Kanban, prioritization is optional. In Scrumban, prioritization is recommended during each planning.


Scrum is generally a constrained process, where the tasks are assigned to team members and bounded by deadlines. Therefore, Scrum is the most restrictive process of the three.

Kanban, on the other hand, has only a few constraints is a fairly flexible process.

Scrumban has a slightly constrained process and falls in between the two.

Who should use it?

While all three methodologies can be used in a variety of settings, there are a few aspects to take into account when considering whether to adopt different methodologies.

Scrum works well for large projects, and especially for projects with long-term maturity of more than a year. Therefore, Scrum is often chosen by enterprise teams seeking to make their process more effective.

Kanban has the unique ability to handle constant flow of incoming tasks, therefore it is often chosen by support and maintenance teams, or continuous product manufacturing – among other applications.

Finally, Scrumban is often used by fast-paced projects, as it combines the flexibility of Kanban with the basic features of Scrum. Therefore, it is often used in startups or, similarly to Kanban, where continuous product manufacturing is required.

It is however important to choose the process that works for you and customize it to fit your own requirements. Scrum, Kanban, and Scrumban are just tools to make you and your team more productive – and therefore use them the way it works for you and your team, not necessarily following every rule to the T. Good luck!


Read More

Scrum vs. Kanban vs. Scrumban: Team Members, Meetings, and Roles

We recently talked about the processes and the structure of agile methodologies, but at the center of the implementation of these methodologies is the team. Therefore, this time we review the differences of the three methodologies – Scrum, Kanban, and Scrumban – with respect to the team members, roles, and interactions.


In Scrum, there are several roles: Product Owner, Scrum Master, and the team itself.

Product owner is responsible for the product vision and priorities – and she is the person who decides which items or user stories are the most important to work on and complete in a sprint. The Scrum Master ensures that the Scrum process is going as agreed, removes any issues in the process and provides leadership with regards to the way it works. The team actually builds and implements the product.

Kanban and Scrumban do not have clearly defined roles for team members – so the roles may wary and it is up to the team whether any roles should be used at all.

Team members

Generally, Scrum is a methodology where the team members can be cross-functional. While there is no precise definition on what is cross-functional, the team as a whole should have the skills to complete the work within each iteration. As Scrum is time-limited methodology, it often happens that some team members need to work on several types of tasks in order to complete the work during the sprint – but as mentioned above, the methodology does not explicitly define what is cross-functional.

On the other hand, in Kanban the team members’ specialization or preference to tasks is preferred. Since the work is limited by work in progress, anyone with items in backlog can start working on another item as soon as they are finished with their own – which allows for specialization of the team members.

In Scrumban, the team can be either specialized or cross-functional.


The key difference in ownership is that while Scrum is a team-oriented methodology and is owned by a team, Kanban and Scrumban support multiple team ownership. So, for example in Kanban, different stages of the process can be owned by several teams – such as development team, quality assurance team, and others.


Several meetings are used in Scrum. They are sprint planning, daily scrum, and retrospective.

The sprint planning meeting involves pulling items from the backlog into the sprint and prioritizing the user stories that will be carried out during the sprint.

The daily scrum or stand-up meeting includes a short daily meeting where each member of the team briefly shares what they are working on. The daily scrum typically lasts no more than 15 minutes.

The retrospective reviews the teams progress after each sprint, and discusses ways to improve the process.

In Kanban and Scrumban, meetings are optional. They can be avoided entirely, or agreed upon on a regular or on demand basis.

Short Kaizen events can be done from time to time in order to focus. Kaizen events are defined as short, breakthrough events where employees from several departments or teams examine a problem, propose solutions and implement changes. These events can be used in Kanban and Scrumban from time to time, in order to solve issues or improve the process of work.

Continuous improvement

The approach to continuous improvement prescribes how the team makes changes and improves their work process based on the issues they encounter.

Scrum achieves continuous improvement by using a sprint retrospective meeting after the sprint, and discussing the outstanding issues as well as improvements to the way to work.

In Kanban and Scrumban, continuous improvement is optional. However, as mentioned above, short Kaizen events can be used for this purpose as well.

The next time we will be reviewing a few other differences between Scrum, Kanban, and Scrumban – including boards, rules, and who should use which methodology.

Read More

Scrum vs. Kanban vs. Scrumban: Planning, Estimation, and Performance Metrics

In the previous blog post we reviewed the basic differences of Scrum, Kanban and Scrumban. In this blog post we dwell deeper and look into how the tasks are planned in each of the methodologies, as well as how is the performance measured in Scrum, Kanban and Scrumban.

Planning routines 

Planning routines define how the work is planned during the process and when the planning sessions take place.

In Scrum, the product backlog items are pulled into to each sprint. Planning is regular and occurs in the beginning of each sprint.

Kanban, on the other hand, does not prescribe a precise planning routine. Therefore, the teams can choose to plan when they run out of backlog items (demand planning) or when the code or version is released (release / iteration planning). Scrumban, similarly to Kanban, uses planning when the backlog items are completed – and then plans for the new items.


Estimation is the process of determining the time required to finish each item.

In Scrum, the estimation of the time required for the items to be completed is typically done before the start of the sprint. Generally, the items have to be shorter than the time allocated for the time-boxed iteration. If they do not, they are usually split into smaller items.

In Kanban and Scrumban, estimation of the item duration is optional. After an item is complete, the team members simply pull the next item from the backlog and proceed with implementing it. Some teams still choose to carry out the estimation in order to have more predictability. Alternative approach to achieve predictability is to make sure that each of the items is of the same size, and therefore can be completed in the same amount of time.

New items in iteration

Agile methodologies also define how new items are added to the iteration.

In Scrum, it is forbidden to add new items during the sprint. Therefore, if there is a new item, it has to wait until the regular planning meeting in order to be included into the workflow. If the project requires dealing with incoming items (e.g. support), it is generally advised to use Kanban or waive this requirement in Scrum.

Kanban and Scrumban allow adding new items whenever there is enough capacity in the queue. Therefore, Kanban and Scrumban are very useful for functions with continuous flow of new items.

Performance metrics

The key performance metric in Scrum is the burndown chart. Burndown chart shows how much work within each iteration remains at each day or each hour of a sprint. A burndown chart example is provided below.

The blue line represents a typical burndown on an hourly basis, compared to the ideal burndown (the dotted line). The green line represents cumulative value that is added each hour. The key goal of the burndown diagram is to show whether the team is behind or ahead the schedule within each sprint.

In Kanban, the performance is measured via the cumulative flow diagrams and by estimating lead cycle time. Cumulative flow diagram shows the total items that are in progress, as well as the time it takes to complete them. Average lead cycle time estimation shows how much time, on average, does it take to complete one item. An example of the lead cycle time estimation is below. Similarly to Kanban, Scrumban also uses average lead time as its key metric.

It is important to note, however, that Scrum, Kanban, and Scrumban are just tools that are recommended and there is a variety of approaches of implementing the recommendations, depending on the team’s specifics. In the next blog post we will review the team requirements for Scrum, Kanban and Scrumban, including roles, meetings, ownership and continuous improvement.

Read More