Retrospectives, 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.
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 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.
Source: Agile but Pragmatic.
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.