If you have ever worked with Scrum, it is highly likely that you have run into problems more than once trying to define a Sprint Goal.
You may have wondered if the highest element in the Product Backlog is theoretically the most valuable. Should it be the basis for defining the Sprint Goal? Or what do we do when we have several items at the top but they are uncorrelated? Do we craft a Sprint Goal with ‘A’, ‘B’ and ‘C’? Can there be more than one Goal per Sprint?
In the previous post The power of the Goal Sprint, we saw the importance of working with Sprint Goals in Scrum. In this post we will see when they should be created and the main techniques we can use to define them, and we will explain some types of Sprint Goals.
“Perhaps we no longer have to think about servers”. This is what Werner Vogels, AWS’ CTO, said on 7 July 2016 to sum up the value of Serverless computing during his speech at the London Summit.
He saw it as the next big revolution after containers and mentioned that some companies were already starting to remove the big parts from their apps and replacing their servers, virtual machines and containers just with a code.
Lately I have been noticing some trends within the agile world that I don’t like at all. The first one is the market which the world of certifications has become, which has led some companies to make the mistake of assessing their level of agility ‘by weight’ according to the number of PSMs, PSPOs, PSDs, SPSs, PSKs, PALs, and so on.
The second trend – the one that I am more worried about – is the high degree of inbreeding in the industry and, hand in hand with this lack of openness, an excessive devotion to the Scrum Guide – with quasi-religious fervour.
I think the sector should already be mature enough to accept that methods are tools and not liturgy. But, most of all, to accept that there are other parallel worlds which are way ahead of agilism in some areas.
One of the big problems when carrying out Machine Learning and Artificial Intelligence projects in companies is having the right professionals. There are still few people in Spain with the necessary training in this area of specialization. However, the demand is increasing.
BI teams and departments don’t have the capacity to implement Machine Learning in most cases and, conversely, there are not many service companies with the experience and profiles necessary to address these projects.
In this post we are going to explore some of the career paths we can follow to train ourselves, deepen and keep our knowledge of this discipline up to date.
Around 100 years ago the most popular debate regarding saving was whether you should buy a car or keep your horse.
There were articles and newspaper ads, such as the one below, which argued in favor of not discarding your horse thinking “what it costs you to feed it in a year” versus “expenses on gasoline, repairs and storage.”
A similar logic is used today when evaluating the cost of cloud thinking about the cost of what we are used to instead of thinking about betting on the future.
It is curious that this type of evaluations are only common in Cloud projects. There is no such tendency to try to justify the viability of a project, for example, when we compare whether it is developed in Java versus Python or if a MySQL or a PostgreSQL database is used.
Next, we will see how the cost of running your projects in Cloud compared to on-premise compares, the possibilities that the new billing models bring to the financial departments and all the facilities with respect to the price offered by the cloud.
It’s clear that everything agile is trendy. If we put some post-its by the office, we do some cool dynamics with legos and copy something from the Spotify model, customers will fall at our feet and we will also have free ways to develop comfortably, without dates or a closed scope.
Well, this does not work like that. In most cases, both customers and developers are not clear on what it really means to follow the principles of agile development.
If you’ve been a bit absent-minded this year with our posts… it is about time to catch up! And if you have remained faithful to us every week, you’ll probably like to review our best content this summer.
We’ve compiled the most successful posts on our blog so far this year, have you missed any of them?
“Is it a Fortissio Lungo? Because it smells great”, asked Gonzalo, Product Owner of the Telcom Team, just before starting Sprint Review #4. I had joined the team a couple of days earlier as a Scrum Master and in the midst of the calm and with the smell of coffee, I could not have foreseen the storm that was brewing.
Less than 20 minutes had passed when Alonso de Benavides, the main stakeholder and sponsor of the project, launched the question that rumbled like thunder in the room: “So, can someone tell me what the hell was done in this Sprint?”.
To which Gonzalo responded in a tremulous voice: “The team has finished the TL-34 and TL-35 tours related to the user area, and also the TL-40 to TL-44, which have improved the loading time of the product catalog pages”.
Alonso’s face turned blue at times. In the room everyone looked at him, while they held their breath, without understanding why he reacted like that.
Alonso, having been subjected to great pressure for months, stood up, as if to reinforce his message, and added: “I told you it was vital for the company to be able to sell the new TV-Streaming product at the end of this Sprint, since our competition is crushing us as theirs was released to the market two months ago”.
Gonzalo, who vaguely recalled mentioning this to the team during the Sprint Planning, replied, almost with a broken voice: “I’m afraid that the team did not have time to finish up the Jiras for that functionality, they got stuck and decided to continue with other things to complete more items of the Backlog without bringing the speed down”.
After hearing his reply, Alonso smiled slightly, one of those smiles in which the mouth makes a stiff grimace and the rest of the face remains motionless.
After a few seconds of utter silence, he said while he was leaving the room: “I’m afraid you haven’t understood anything and it’s very disappointing. You have not understood the priorities of the business, what adds value and makes us support this company. You cannot distinguish the important from what is unnecessary. It is a very worrying situation that I hope you will solve in the next Sprint or I will have to take measures”.
I could not help thinking that none of this would have happened if the Scrum team had learned the power of the Sprint Goal. The good news is we got something positive out of the situation as we had an opportunity to perform Inspect-us and Adapt-us in the next Retrospective.
In the 90s, three-level architectures were booming. During the transition from a client-server model to distributed architectures, industry leaders defended a pattern where the interface, business logic and databases had to be structured in different layers.
This is the three-tier architecture that we have been so familiar with in the J2EE world. Now, at the height of Cloud Computing, we are used to very similar architectures where data is transferred to a centralized location to be processed and then sent back to the requester.
However, there are situations in which this model does not work. For example, what happens if the generated data to be transferred is very large? It is clear that it will increase the time to process and the latency to store or retrieve said data from the cloud.
This, in many cases, can penalize the performance of the applications, negatively impacting business.
To solve these problems, new cloud computing paradigms emerge, such as Edge Computing.
Have you ever noticed that when we are involved in a project we talk about a viable minimum PRODUCT? Why do we talk about a PRODUCT owner in Scrum projects? Shouldn’t it be Project Owner?
The word “project” has been overused, it is a concept that has been established with strength in our day to day. We cannot say “I belong to this team”, we usually say “I am in this project”.
This is because we have always been taught that we work on projects and that in the IT sector everyone belongs to one. On the other hand, when we do an “internal project” we usually call it a product.
Is the difference between a project and a product important? Why do projects managed with Scrum also fail?