Should You Complete the Agile Transition?

transitionWith Agile gaining bigger and bigger traction each day, there is no wonder why many companies are starting to adopt it and claim to be Agile. The change, however, is not overnight – it takes time and effort to implement. Due to this, many corporations choose to adopt Agile incrementally with a method that is now being called Water-scrum-fall. However, can it actually be better to use the transition method?


To answer this question, let us first explore what hides behind the term Water-scrum-fall. This definition appeared in Agile circles not too long ago striving to describe a process in which large companies choose to practice both Waterfall and Scrum methodologies at the same time. This is usually done to introduce a more efficient Agile process into some phases of the project, while leaving other phases untouched and managed in the traditional way.

Such a solution has become a great option for large companies in which some teams are pushing for change and a more flexible way to complete projects, while others are holding on to the established processes and refuse the necessity of change altogether. With Water-scrum-fall, the teams get to decide which of the two management methods is the most suitable for each situation and use it to gain the best results.

What we call Agile

After some time of such project management the mindset of the organizations usually changes. They get used to the idea of Agile, see the value of the process and Agile project management is chosen to govern more and more project phases. At this point, most of the teams start identifying themselves as Agile and slowly, but surely, the whole company is as well. However, the question of full Agile adoption still remains – how many teams have to be practicing the method, for the company to claim it’s Agile? Is it enough to implement the new method in the production phase or does it have to reach the whole company?

To put it simply, for a company to be fully Agile, all of the processes have to be. In other words, all of the phases of the traditional project management have to be done with the new method and all of the teams and management have to be practicing Agile to perform their tasks. There is really no black and white here and if the higher management is still using Waterfall methods to plan the overall vision for the company, then this company is not yet fully Agile.

In order to make the full transition from Waterfall, the company needs to gradually choose Agile for more and more parts of their project, until finally all of the steps are overturned. It is worth to mention, that making an Agile transition this way is a lot smoother and easier than trying to transition the whole process at once. In fact, if your end goal is a fully Agile process, but you have difficult processes in place, this is an option to consider. On the other hand, the full Agile transition is not what all companies are or should be seeking for and it is actually a lot more beneficial in some cases to stay within this mixed approach.

agile process

Staying within the transition

Let us imagine a traditional case of a company that has slowly come from the Waterfall management approach and has now been using Water-scrum-fall approach for some time. They have started adopting Agile methods in the project phases where it was the most needed. After the first few projects, they have witnessed positive changes and since have expanded Agile into other phases of the project, where they thought it was suitable. At the same time, they have kept the more traditional phases within Waterfall and achieved a good working model for themselves.

At this point, the company faces two options – moving forward with Agile transition or staying within this working model. For most of the Agile fans, the choice might seem clear, but in fact there are some things to consider before moving forward with the full transition:

  • It will be harder

At this point, it might seem like you have a hang of the method and some experience under your belt. The fact, however, is that the parts of your process that have been the most similar to Agile have been already transformed. Now you are left with the parts that are deeply traditional snf changing them will be much harder to achieve successfully.

  • It may not fit

Agile was built for execution – to optimize the production or development processes and to bring the best results forth. Since then, it has come a long way and has been successfully adopted in many fields, however it is still fundamentally different in some cases. When trying to transform your organization, you very well may find that some processes are just not compatible with what the method preaches.

  • It is not worth the effort

Based on the first two point, many companies soon find out that transitioning the rest of the organization into Agile may just actually cost you a lot more compared to the benefits it is going to bring. So before you make this leap forward, think whether the improved process will bring just as much as the efforts to change it will cost.

It turns out, that in some cases becoming fully Agile is not the best end goal and instead staying with this seemingly transitional model is a lot better choice. With Water-scrum-fall the organization gets a healthy boost of productivity from Agile without the added stress of having to implement the new method in all parts of the company. The slow process adoption, lets them to reap the most benefits and identify the project phases that are best kept in the traditional Waterfall approach. While this may not be what making an Agile transition ideally looks like, for some it is actually a lot smarter and a more calculated way to move forward with change.

Read More

Entering Life After Scrum

TeamAs recently discussed in the 2015 review, more and more Agile teams are starting to sway away from Scrum and lean towards a different methodology – Kanban. While this may be surprising at first, there actually is good reasoning behind this switch and possibility of this trend continuing into the 2016. Will you be switching as well? Let’s see.

The need for order

For most companies, Scrum has come at a time, when there was a need for a more flexible and at the same time a clearer approach to project management. This was especially true in the case of software development teams that lacked processes and often produced results, just not the ones management was looking for.

Read More

2015 in Review – Project Management Software

2015-review2Another year nears its end and before the holidays take over our mind completely, we thought it would be interesting to take some time and look back. Every year we analyze data from Eylean to see how our clients have used it and how can we improve in the next year. Most of this data is quite technical, but just like last year, we want to share some of the more interesting findings with you.


markets 2015

Country of origin. Over the years, we have been enjoying a steady growth of interest into project management software. Last year we were happy with an 81% growth of Eylean users and this year we are even more excited with a doubled 156% growth. Most of the new users came from our biggest market – the United States (31%), however, this year we also have new markets in our portfolio, such as China, France and others, proving that agile project management practices are becoming more popular all over the world. While there is some movement in the new markets, the top 5 have retained their strong positions with only some slight changes in the numbers.

Read More

Scrum – the silent facilitator of trust

Image Credit: ©

Trust is not only a great, but an essential asset to have within any team. It allows for ideas to flow freely, eliminates looking over each other’s shoulder and mergers different people into a unit. A team that trusts each other, brings forward better and faster results, makes the clients happier and in turn creates a prosperous environment for years to come. There is no doubt, trust is great, the question though is – how do we create it?

Building trust within a new team is often tedious and burdensome task that not all leaders are ready to cope with. There are essentially three points to ensure trust – we need to know that we are understood, that the deadlines will be followed and that promises are going to be kept. Besides all the small little details, following these three points will most likely guarantee that the team will be working within a trusting environment.

While it is easy to name these principles, following and putting them into practice is a whole another ball game that many struggle with. However, what if there actually was no need to cope with this task? What if appointing a specific project management method could do all of that for us? Well, then we would all be happy and we would all be using scrum to manage our projects.

Read More

Agile Startups – How Do Lithuanians Do It?

Both Agile and Startups are terms that have gained massive buzz in the business world over the last years. However, the idea of them mixing with each other has come up only recently. Startups that have been traditionally visualized as messy and uncoordinated have taken up a method that requires teamwork, planning efforts and timed delivery. Some are still struggling with this idea so we thought why not go ahead and ask startups themselves about their experiences?

Eight of Lithuanian startups have answered our call and shared their ups and downs using Agile methods. Here are their experiences and thoughts.

Mobile Worker logo



The team behind a field service management and time tracking software Mobile Worker has started using scrum in 2013. They have found the rules to be tough to follow and have decided not practice the routine of a daily standup due to team members being in different locations. However, they instead decided to focus on the benefits that scrum has brought them – they are now able to plan better, evaluate the final product immediately and quickly adjust the course of action depending on the necessary updates and improvements.

CGTrader logo

A 3D model marketplace founders at CGTrader have started using scrum in the summer of last year. They have done so looking to have clearer planning and allocation of tasks as well as overall control of productivity. While they have achieved their goals and find it that tasks get completed more quickly, they still struggle evaluating tasks accurately. The team members often overshoot estimating their ability and this results in project being behind the delivery date.

Read More

The 4 Scrum Cards To Consider

Since the very beginning of scrum practices, one of the most important tool to the teams have been the various task cards. They hold all of the important information and help keep the team on tracks at all times. It comes as no surprise, that there is great variety of such cards out there, so this time we are presenting our top 4 of physical scrum task cards.

The classic

cards 3

There is no denying that the task cards as we know it have started with sticky notes and in fact, many teams are still using them today. The one we liked the most, comes from Adam Rudd and is an improved version of the original with dedicated sections and places for specific information. It brings more clarity and order into the note taking, but lets you keep the format of a sticky note.

Read More

Sprint Retrospectives and The Wheel of Change

meetingmanagementRetrospectives, even though a valuable part of any sprint, are often disregarded and underestimated by scrum teams. Team members and the scrum masters feel that if there were no major issues during the sprint, there is really nothing to be discussed. This could not be further from the truth however and in fact goes against the constant innovation and improvement philosophy of agile. So what should you do in case your team is falling into the pattern? There are exactly three things propose to keep in mind.

  • Remind the team why it is important

First and foremost, the team needs to understand the importance and value that a retrospective adds. While it is all clear when the project begins, teams often tend to devaluate retrospectives towards the middle of the project. Even though the major kinks within the team are worked out by then, there are still improvements to be made and things to be discussed. Think about it – the type of work your team is doing at each stage of the project is likely not the same and therefore does require different approach to maximize results.

Thus make sure to remind your team that as their process is changing, their approach will likely change as well. Make them understand the retrospective as a great opportunity to voice their issues, hear out others and reach a mutual understanding for going further as a unit.

Read More

Top 5 Most Interesting Scrum Boards

Scrum board is one of the most essential tools to ensure a smooth project and while most choose the traditional scrum boards for their teams, there are a few that decide to innovate and improve the traditions to fit their needs. Therefore this week we gathered up the 5 most interesting (at least to us) boards and present them to you!

The wall

The first example comes from Agile but Pragmatic. Instead of dealing with a traditional scrum board, they suggest to expand it into a whole wall. This allows the team to put additional information such as results of retrospective – decisions and actions to take in the current sprint, parking for not active tasks, the sprint calendar and other things. By dedicating the whole wall to the scrum board, the team expands their ability to have all the information in one place.

Scrum board wall

Source: Agile but Pragmatic.

Read More

LeSS – scaled agile that keeps the small team vibe

As the summer is slowly but surely taking over our minds, the office life becomes slower and more relaxed. Most large projects are put off or have extended deadlines and most of our team is missing at some point or another. This is why summer is a great time to reflect on your teamwork, achievements and think of possible changes for the future. Who knows, what may come out as a result – a renewed conference room, new team structure or even a company wide reorganization. This is why this time we want to introduce and talk about LeSS – Large Scaled Scrum.

The interest and need to scale agile practices is not a new thing, it has first appeared shortly after agile gained success and proved its worth as a project management approach. The issue with it however, was the fact that it can only serve a small team effectively and is not created to be used as an organizational structure. Therefore several practices to scale agile have appeared on the horizon, amongst the more known ones we have the Scaled Agile Framework (SAFe), Disciplined Agile Development (DAD) and the Large Scaled Scrum (LeSS) which we want to talk about today.

LeSS was introduced to the Agile community by Craig Larman and Bas Vodde. Differently than other scaled Agile approaches, they put the focus on keeping the original agile values and the reasoning behind them when scaling up. They wanted to ensure that using scrum in a larger group of people would still be as beneficial as it was with a single team. As a result, when adopted, LeSS feels like a natural evolution from a small startup of a few people to a corporation of a thousand.

Read More

Scrum vs kanban – have a smooth transition

arrowsWith agile methodologies being as popular as ever, there is no surprise that people are picking their favorites. Some (well actually most) prefer scrum, while others choose kanban. However, what does happen when teams decide that their choice is no longer fitting and go for a switch? Most struggle. Instead of having a smooth transition they go down a rocky road for some time before finally reaching the light. The good news is – you don’t have to.

Switching from one methodology to another makes sense in a lot of cases – your requirements, team, circumstances and other things may change during time and working in the same way may no longer be fitting. To make sure the good intentions of bettering the teams process are well met, you should focus not only on choosing the best approach, but implementing it in the right way as well. And to do that, you simply have to follow these 3 rules:

1. Understand the differences.

When switching from one agile approach to the other, teams should think of it as adopting a completely new methodology altogether. Sure, they are both agile methodologies run in iterations and focused on value, however this does not bring them even close to being the same. Scrum is a very structured step by step approach, with clear roles and a set of rules, while kanban has a more at ease, let the team manage themselves attitude. So, when you decide to switch from one to the other, make sure to fully understand each and every difference. The way you plan, commit to and complete your work will change and you might feel that it is not as effective as it used to be if you are not prepared to embrace it.

Read More