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.
With 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.
The recently released annual state of agile survey is great and informative. In fact, we loved it so much, we decided to analyze it‘s results and draw some predictions for 2015.
Click on the picture below to get the full infographic and our insights.
Let us know what you think in the comments.
The goal of every marketer out there is to create a campaign that is so genius and grand, that the whole perspective of their brand changes. Whether directly expressed, or not, this idea consumes most of the marketing departments making them forget, that the times where you could take months to prepare the perfect interaction with the consumer are long gone. Today consumers have means, they have opinions and most importantly – they know they have the power to communicate back. Therefore the new mantra is react or react quicker!
It is only natural, that with the new technologies available to the mass market, the way marketing teams work had to be adapted. In the last couple of decades it changed from working on the one sided communication of presenting a message, into a conversation where the consumers have very clear opinions about everything that a brand does. By now, there is no question, that the marketing teams need to communicate effectively or they will lose in the big race.
As with any changes, the main question is – how do I do it better than my competition and surpass them? While the changes to be made are clear, the best way to organize the teams work is still foggy. The team needs to be more flexible for the short-term changes and still focused on the long term campaigns. The best way to do it is still to be determined, but some are suggesting that agile might be the way to go. And we think, they have a good reason for saying that.
The financial sector is associated with big numbers, meticulous work and mistakes that could cost millions. It comes as no surprise that the procedures are very precise and require a lot of effort to ensure there are no slip ups. Therefore in this sector, IT solutions are irreplaceable in helping to manage large corporations, navigate international laws and keep track of what is happening locally.
It comes as no surprise that the IT spending in the financial sector has been growing over the last years. Which is caused not only by the initial demand, but also by the fact that the last time this sector heavily invested in IT was in the 90’s. By now most of the systems need to be patched up, reworked or completely switched out.
Even though it has been thrown around the project management world for a while now, Scrum-ban is still a foggy concept to most of us. Some see it as improved scrum, others as improved kanban and while this train of thought is on the right path, it is not quite correct. Let us try and explain the hype of scrum-ban.
By definition scrum-ban is a mix of scrum and kanban. However, instead of being an improvement of either, it is a brand new approach especially dedicated to the teams working in fast-paced and fast-changing environments that require flexibility. This event driven approach is designed to push practices only when they are needed and no sooner. Compared to the traditional agile approaches, it offers wiggle room for teams that have to change their priorities often.
When implementing scrum for the first time, you read all about the roles, meetings, user stories and more. However, when it comes to planning the first sprint, most of us feel lost and unsure in what exactly needs to be done.
The basic steps of a sprint are pretty straightforward – plan, execute and finish, with the help of various meetings in between. However, after starting to implement, a lot of questions and uncertainties seem to appear and at this point most of the teams tend to start looking for the best practices. Unfortunately there is no such thing, and it is each team’s specificity that determines how the sprint needs to be organized. In other words, the best practices can only be created by the team itself.
While the best practices do not exist, there are some guidelines that you can follow to make the process smoother. Here is our take on the most important ones.
The duration of the sprint. Deciding what the duration of the sprint is going to be is completely up to you. However, remember two things – at the end of the sprint you have to provide an incremental value to the end customer and the sprint should be a relatively short iteration when compared to the whole project (most of the sprints run between 7 and 30 days).
At the moment, more and more companies are turning away from the old project management practices and searching for the new trends like agile and one of its methodologies – scrum. While most are successful in adopting the new practices, some however are struggling. While the reasons vary from the incompatibility with the process to the feeling that the methodology is too strict, the end result is the same – a team that is not getting a 100% result. However there seems to be a solution on the horizon – scrumban.
To put it simply scrumban is a mix of scrum and kanban. It takes certain components of both practices and mixes them together in order to create a new and enhanced one. In this post, however, we will not focus on the complete methodology, but instead we will take a look at how scrumban can improve the process of an unsuccessful scrum team. There are various reasons why teams find the scrum methodology unfitting – strictness, time constraints, continuous planning and others. For these teams scrumban is a great solution because it still has the main scrum principles and at the same time offers more flexibility and freedom to move forward.
When talking about reports, the image that comes to most of our heads is hundreds and hundreds of pages filled with words, numbers and charts. In fact, most of us do not like to either prepare or to read reports unless they contain the exact information we are looking for. However, this image of reporting is a little outdated as with the new technology available, they have changed and are able to bring a lot more to the table.
Since the computerization of the office, the changes in reports can be summarized in three words – automatic, on time and insightful. Nowadays, the reports are mostly automatic as various project management software does exist for the sole purpose of generating them for the team. Because of that, reports are also usually live, meaning that the needed report can be accessed at any time and it will provide up to date information. The insight that reports can create for the team is also greater, as a computer can quickly analyze and cross-analyze the important data to provide information that may not be visible at first.
Team Foundation Server (TFS) is a tool widely used by companies all over the world. It offers a great variety of features and covers all of the development phases and aspects. However, when covering every aspect of a large process it is hard to be perfect and companies using TFS are still seeking additional features to get the perfect user experience.
Eylean Board aims to do exactly that – enhance TFS project management experience by providing additional features. In order to do that, Eylean works as a two-way integration into TFS. It takes all the information related to work items from TFS and represents it in visual task boards. The information in Eylean is updated regularly and any changes are immediately transferred back to TFS. This ensures that the users always have the most recent information and can use the two tools interchangeably. Let us look into what sought after additions does Eylean bring into the TFS experience.