Scrum

Building Your Next Sprint With Eylean Board

1. Visual board1

Building a sprint is not only a difficult but also a very important task. You need to identify the priorities and set realistic goals for the whole team at the same time providing a meaningful result in the end. So there is no surprise many struggle in the beginning and even the most experienced Scrum Masters sometimes run into trouble.

While there are no definite guarantees against anything in this world it is always better to face uncertainty prepared and sure in your processes. This is exactly what Eylean Board goal is and here are 5 ways planning your next sprint with our tool will make you not only more sure of your process, but also happier.

Easy start

They say, having a successful start is half the job and in fact whatever it is we do, starting it is often the most difficult. Therefore with Eylean we made the start as easy as possible – all you need to start planning your next sprint is dragging and dropping your chosen user stories. You can even play around by moving them back and forth! Once you are set on the sprint backlog, double click the desired story, add detailed information, due dates, attachments and divide it into as many tasks as needed. You can even add su-btasks to the tasks and sub-sub-tasks to the sub-tasks. Forget the messy cards, lost information or unclear DODs, with Eylean everything is in one place and accessible to the whole team at any given time.

Scrum User Story Details2

Comparable estimations

Once you are done with choosing the user stories, it is time to involve your team. Here is where it is sometimes hard to decide which task will take what time and comparing them to each to each other may become simply uneasy with a new team. While we cannot do all of the work for you, Eylean Board neatly displays all of the estimations on the top right corner of each task as soon as you enter it. Thus making it easy to visualize, compare and discuss the estimates while looking for the best mutual decision.

Scrum Story Point

Intuitive team management

Keeping track of what is happening with every single team member in the team can become a hassle. You don’t want to be the annoying boss and the team will not likely report every single action they take even though you need to know it. Just to make sure the important stuff is getting done. Eylean doe not only show which team member is responsible for which tasks, what is their progress and if there are any issues, it also provides you with a quick information resume in the form of a dashboard. You can check how many tasks where completed that day, how many hours worked and the assignments left for each team member to do.

Scrum Dashboard

Automated reporting

Just like keeping your eye on the team, tracking your progress is no less important than planning the work. When it comes to a cumulative workflow, it is imperative to keep a steady pace, but generating such graph can be burdensome. With Eylean you can forget the trouble – automatically generated cumulative workflow, burndown chart and many other reports are always live and ready for your keen eye. cummulative Task moving between sprints

Lastly, no matter how good your planning is, there might be some hurdles on your way and the team will have to move some of the tasks to the next sprint. You may start to worry about moving all of the information, not missing anything important, but when you have Eylean Board, simply remember the fun drag&drop feature. Click that unfinished story and move it right into the next sprint, with all of the information in tact and ready to be worked on.

What gets you the most when running sprints? Share with us in the comments!

Read More

Agile vs. Hybrid Approaches – Which Will Stay On Top

Agile-vs-hybridLast week I introduced you to the hybrid WaterScrumFall model that merges the Waterfall and Scrum practices in order to create a happy medium of both worlds. While it is not the likeliest of merges, many companies out there find it to be a viable option for their situation and happily use it. However, there are also those that claim this model is ineffective and faulty therefore this week I want to dive into their side of the story.

According to a recent study by TechBeacon, Agile projects are more successful than hybrid ones. This is a bold statement to be made, especially when keeping in mind that most companies deal with different processes, situations and in general are very diverse. However, the study focused on development and IT professionals show substantial results in favor of Agile.

Amongst the interviewed companies, both Agile and hybrid approaches are widely used as project management practices. The difference between their numbers is not really significant Agile taking the first and Hybrid approaches the second place. Where a difference does come in though is the satisfaction level. Agile users are generally happy with the project outcomes all around, while the hybrid users seem to have issues with six important metrics – Quality and performance, Time to market, Speed of delivery, Scope, Security & Cost and use of resources.

All of these metrics show over 50% or 60% success rate with Agile practices and only around 30% success rate with hybrid methods. So while WaterScrumFall seems to be great on paper, does it fail in reality?

Where the hybrid fails

We can easily find the answer to this question, by actually looking at the metrics themselves.

  • Quality and performance talks about product that fits the client requirements and is produced effectively. Agile practices with their iterative approach and work organized around the product are built for this. The hybrid method on the other hand keeps the design first, build later attitude and can fail to reach that changing expectations of the client.
  • Time to market is also much shorter with Agile not only due to design on the go, but also because the practice focuses on the minimum viable product and can release it much sooner.
  • Speed of delivery is much simpler to achieve with Agile. While both methods hold review meetings with clients, hybrid teams’ product is not yet tested and not ready to be used contrary to Agile teams’.
  • Scope. By keeping with the waterfall planning approach, hybrid methods lose the ability to plan on the go and thus may miss some of the client requirements that may have been miscommunicated at the beginning or only arose during the course of the project.
  • While Security satisfaction rate reaches 45% with hybrid and just under 60% with Agile users, this is still a significant difference. Which could be explained by the more control Agile projects have during the course of the product creation compared to the hybrid approach.
  • Lastly, the Cost and use of resources is undoubtedly lower when everything is planned on the go, according to the projects needs instead of preplanning and blindly following the course.

 

Which to choose?

So while WaterScrumFall aims to merge the best of both worlds it still falls short in comparison to pure Agile methods. In the midst of two different approaches merging and mixing, it is hard to keep track of all the processes and ensure that the most effective path prevails. Nonetheless, for cases where pure Agile adoption is not a viable solution, it may be a better choice to choose a hybrid instead of not innovating at all.

 

Read More

WaterScrumFall – What Lies Beneath A Complicated Name

waterThere is no question that Agile is one of the top project management approaches these days and even littler question of it going away anytime soon. However, as more and more people start adopting the iterative practices, more innovations and modifications of them start to appear. Agile methods are being mixed together, redefined, scaled and in this particular case joined together with a completely different school of thought.

WaterScrumFall aims to breach the gap between two worlds, but does it succeed?

To put it simply, the hybrid approach joins together the linear Waterfall and the circular Agile methods to find a happy medium and the best of both approaches called the WaterScrumFall. The name looks a little heavy at the first glance, but it absolutely makes sense with the way the method is set up. Waterfall approach is used at the beginning and ending stages of the project, while the Agile (usually Scrum) approach is sprang into action right in the middle. Therefore we have it Water – Scrum – Fall, depicting the way hybrid projects are run.

The division

This structure makes sense when you think about most of the corporations and the way they react to change. Most of the companies are reluctant to switch up processes at large, however they can be easily changed in small teams, especially in the operational level. WaterScrumFall takes advantage of that – the activities that require more budgeting, planning and are related to higher management positions remain with the waterfall approach, while the execution is switched to Agile.

Let’s say an average project is composed out of 5 stages – Study/Requirements, Design/Planning, Implementation, Verification/Testing and Release/Maintenance. The first two stages require quite a bit of knowledge and analysis to make sure the project runs smoothly and thus are completed by the upper and higher management. This makes a shift to Agile difficult and the stages remain in the Waterfall methodology. Next comes the build stage that requires teams to create the products based on the laid out plan. On this operational level, making changes is much easier, thus Scrum practices are introduced.  Lastly, the resulting products have to be tested and maintained, which requires developed processes and a good overall understanding. This once more makes Agile adoption a little more tricky and the waterfall practices are used instead.

waterscrumfall

This way WaterScrumFall uses both approaches in places where they are the most comfortable for the company. Starting with Scrum on the operational level allows teams to evaluate its value and scale it at the pace they feel comfortable with. Thus avoiding rejection and misconceptions within the organization.

Two opinions

There are two schools of thought when it comes as to why the hybrid approach is necessary, but both deal with the same issue – implementing Agile practices in large organizations. The first opinion group claims that WaterScrumFall should be used as a stepping stone for companies reluctant to adopt Agile organization wide right off the bat. It sees it as a good way to start implementing Agile on a small scale and then increase gradually. Others claim that while Agile is very beneficial in the production stages, large companies simply will not benefit from a full Agile transition. Thus the hybrid approach is a great way to get the best of both worlds and keep both methods at their most suitable stages.

Whichever opinion you support, WaterScrumFall is a great way to test out Agile practices in any Waterfall company and see whether it has any potential to increase the business results in a positive way. At the same time it does not completely disregards the positives of waterfall and allows you to enjoy both methods.

Similar school of thought has been used in mixing Agile with PRINCE2, which proved to be a great solution for some.  Therefore, as I always say – don’t be scared to break the rules of Agile it may bring you the best results.

 

Read More

What Makes A Scrum Master

trainerComing into the Agile world, we not only encounter new rules and practices, but also gain new roles to enforce them. Some of them are quite clear, like being a team member and completing tasks to add incremental value to the process. Others are a little less self-explanatory and require a deeper understanding and training in Agile. One of the most misunderstood roles is the one of a Scrum Master. While this is one of the most important ones for the Scrum team, it often gets neglected or reduced due to the lack of knowledge and experience. So what should a Scrum master be? Let’s see.

Scrum Master is defined as a person who is accountable for removing impediments to the ability of the team to deliver the product goals and deliverables. In other words, it is not about being a traditional team leader, but more about being a guide for the team to navigate difficulties and achieve success. It is in fact because the Scrum Masters role is hardly found within any other project management approaches rather than Agile, that it makes it difficult to understand and easy to misinterpret by those new to the approach.

A good Scrum Master is a listener and a facilitator first, a coach and a leader second. They should be able to not simply lead, but to create self-organizing teams that make their companies successful. They should also be the most knowledgeable and the most enthusiastic about Agile, thus relaying their passion onto the team. However, as you can guess, working on this team level is temporary only the first step in the Scrum Masters process.

All in all this role is composed out of three gradual steps – the team, the intercompany relationships and the entire system.

  • The first step is the Scrum Masters team. From the very start the person in this role is responsible for making sure the team functions well. For that they have to explain how the Agile process works, facilitate meetings, help remove any issues and coach the team so that eventually they become self-sufficient and only need assistance in extraordinary situations.  So the first step is all about assisting and guiding the team.
  • The second step speaks about relationships. Once the team processes are all figured out and running smoothly, the Scrum Master should shift their focus outward. The relationships between the team and other entities should become the focal point as well as facilitating them and aiding the product owner in building a greater overall vision. Contrary to the first step, this one is continuous and never stops.
  • The third and the last step of a Scrum Masters responsibilities is overseeing the entire system. Here they have to distance themselves even further and take a look at the whole company. See what should be fixed at the organizational level, help growing leaders and coach the whole organization to be agile.

Contrary to the popular first impression, Scrum Master is not only responsible for coaching the team, but should also be able to see the greater vision and aid the whole organization in their efforts to be Agile. Coaching the team and enabling them to work efficiently is only the first step and part of the job and focusing solely on it hurts not only the image of some Scrum Masters, but also the organization that misses out on great advice and the possibility to be steered in the right direction.

A scrum master should be a great guide and facilitator, someone passionate and positive about Agile and someone that has the ability to see not only their team, but the whole company steering them into the right direction. A positive attitude never hurts as well!

 

Read More

Tips & Tricks On Using Agile

tips-tricksTaking on Agile can be a tough challenge, especially if you have no previous experience with it and have no one to coach you. The good news, however, are that all it takes is time and determination to take over and understand. To make that process more smooth for both you and your team, we came up 17 tips and tricks. Use them to reach your goals sooner and more easily.

Read More

Choose The Right Agile Method

Choose-Agile-method for posting

The next big question after deciding to go Agile is deciding which of the methods is right for you- will you go with Scrum, SoS or SAFe? While this decision is not an easy one and will take careful considerations, there are some aspects to each of the method that can help you along the way. Below you will find our easy 3 step process that will guarantee you consider the right options from the start.

 

Choose-Agile-method

For more helpful Agile cheats and tips see The Ultimate Agile Guide.

 

Read More

Transitioning to Agile: Running Effective Meetings

Startup Stock Photos

Ah, meetings.. The thing we all hate, yet cannot live without. No matter what project management method your team is using, meetings are always a part of it one way or another. And while most of us associate these gatherings with long and strenuous activities that often yield little to no actual results, when transitioning to Agile you should keep an open mind.

The whole idea of Agile is being effective and eliminating practices that create waste. So when talking about meetings there is no surprise, the same rules apply. No matter the chosen method, all meetings have to have a clear purpose, duration and must yield a result. So to get the Agile meetings right from the start, you should understand that contrary to other practices every single meeting has a very specific value to add to the table.

  • Understand the reason of the meeting

Depending on your chosen Agile method, the number, complexity and scheduling of these meetings will differ. Scrum meetings are planned based on the length of iterations, while Kanban meetings are held once the team feels the need for them. However, no matter which method you have chosen, the first thing you will have to do is to understand the purpose behind each of the accompanying meetings.

More often than not, the meetings will be very distinctive and specific – sprint planning is only held for planning tasks of that one sprint. Daily standup only discusses the results and plans and so on. While at first, it may seem hard to keep track of all the different rituals, it is understanding the reason behind them that will help pull you out of the dark. Ultimately this will not only help you, but will also make your teams transition a lot smoother.

  • Go by the rules

Another thing that might be difficult to do at first and will possibly slip your mind later, is that the meeting rules and rituals are there for a good reason. It might seem silly to be standing during daily Scrum for the first few times, but this will help to keep the meeting short and on point. And while planning the work for only a two week iteration could seem very irresponsible and short sighted, you will later realize this way of working cuts a lot of planning time in the long run.

Therefore make sure to stay along the lines of the meeting rituals, especially in the beginning. They will create right practices and rituals within your organization and that will help you avoid overcrowded, extended and useless gatherings. And if you still feel that some rituals don’t work for you after you’ve completed a good number of iterations, you can change them. Only then you will have experience and will actually understand what will work for you.

  • Have a clear goal to be achieved

Lastly, before going into any meeting, make sure to have a very clear goal and a plan to achieve it. It may be to show your client the results of a sprint and to get an informative feedback in a review meeting or it might be as simple as catching up with the team and logging the progress in the daily Scrum. No matter the type of meeting, without understanding what you are trying to get out of it, you chances of success are slim.

In order to avoid the possibility of making your meetings redundant and fruitless, take some time beforehand and draw a mini plan to understand what you are trying to achieve, who should be involved and how long it might take. By doing that you will save your team a great deal of time and frustration as well as will achieve your goals faster.

Agile meetings and meetings from any other project management practice are not much different – they are all set up to improve project success. However, as with anything else, Agile tries to eliminate as much waste as possible. So to make you do just that, take note of why those meetings were set up and fulfill their requirements as best as you can.

Happy meeting!

Read More

Scrum vs. Kanban vs. Scrumban – What’s the difference?

Scrum-Kanban-Scrumban for postingUnderstanding how do Agile methodologies differ can be a daunting task. Some get confused with the overwhelming amount of information, others are disappointed with the lack of clarity.

Ideal way is to have everything at single glance and compare pros and cons in each framework. To make sure it is easy enough, we present a short and clear table listing the main differences and similarities between Scrum, Kanban and Scrumban.

 

Scrum-Kanban-Scrumban

 

For more helpful Agile cheats and tips see The Ultimate Agile Guide.

 

Read More

Transitioning to Agile: Understanding the Methods

agile processAgile is not a new concept in the business world by any means – it is being adopted to more and more various fields, innovated and even discarded by some teams that feel they have had enough and are ready to move on. However, as the Agile reign continues, we find some of the practitioners are still trying to figure out how exactly to be Agile. For this, we are launching a series of blog posts explaining and answering some of the questions most new Agile users have.

To practice any methodology, first you have to know what it actually is and we find that there is still a lot of confusion out there about what exactly can be called Agile. So is Agile equivalent to Scrum as many out there believe? Or is Agile an ancestor of Extreme Programming? Let us try and explain everything.

Agile is a term that describes an effective way of working. It was introduced to the mass public by the release of the Agile Manifesto in 2001 and while it does specifically outline 4 values and 11 principles to be followed by the Agile teams, it does not include any particular methodology or recommendations of a methodology to be followed. So in itself, Agile is simply a framework to be followed.

Naturally, after the creation of the Manifesto, the practitioners felt a need of a clear method to be followed and thus the search has begun. Some looked into existing project management tools and though how they could be made to fit the Agile framework, others created whole new concepts and methods completely from scratch. Thus today we have a wide variety of Agile methods to choose from and new ones coming up every single day. Check out our Agile method genealogy tree.

So to answer the questions we have posed in the beginning, Agile is not Scrum, not XP and not any other method in particular, but all of the methods that comply with the Agile Manifesto are Agile. And as long as you are practicing one of them, your team is Agile too.

 

Read More

Agile Hierarchy – How Are The Methods Related?

Have your ever got lost between all of the Agile practices and frameworks? With the methods evolving, changing and appearing constantly, it can get difficult to understand, how they evolved and turned into the form of today. Therefore we decided to make this quick cheat sheet for anyone wondering if SoSKanban and XP have anything in common.

Agile-Hierarchy

For more helpful Agile cheats and tips see The Ultimate Agile Guide.

Read More