“If you carry this way of working on for months or years, you get a lot of technical debt …” states the blogpost we have been covering recently. Unfortunately, it is only a declaration, lacking any kind of explanation. Therefore it is impossible to argue with. Instead, we will talk about what we have seen as the causes of this situation and what can be done to avoid it.
We continue analyzing the blogpost that we have been covering in the previous posts by taking a look at the next phrase: “Scrum practice of ignoring peoples’ career goals and their individual talents”.
There is a blogpost on quora.com dealing with the topic of why some developers in prominent companies think of agile methodology as nonsense. The post concludes that the agile model is only usable for time-critical, short term projects lasting a maximum of six weeks. It is no doubt cohesive and its conclusions are a logical deduction of the occurences stated therein. However, the problem with the essay is that it reiterates a handful of misconceptions regarding agility. We aim to address these misconceptions one by one in a series of blogposts regarding this topic.
Opening a business is tough, even if we have a great product idea.
How do we become successful on the market? How will our product create revenue? What expenses are to be expected?
In today’s post we take a deeper look at a statement from the essay we have already been covering in a series of Hungarian blogposts. The passage we would like to analyse states: “Product development and architecture aren’t the programmer’s job, because they take longer than two weeks. Rather, the programmer works on atomized feature-level ‘user stories’.”
This practice comes in handy when the Product Owner cannot decide on the importance of several items with, seemingly equal importance.
The terms “team” and “group” are quite often mixed up. It is not uncommon for a bunch of individuals to be huddled together (they might even be moved to sit next to each other in the same area) and be told that now they are a team so from this point on management expects miraculous results from them. But those miracles never come. Because there is more to forming a team from a group of people than just that.
Have you heard the phrase “Everything is important!” or “Everything is top priority”? Such statements can result in effects that ripple through product development. No matter what, delivery teams will have the same work capacity and they won’t be able to deliver more. Forcing the situation only leads to endless arguments, dissatisfaction and demotivation, resulting in higher fluctuation, unstable teams, loss of domain knowledge, and even in project failure.
In this article we would like to share a practice that can help Product Owners and business stakeholders to make the first step towards prioritization.
In today’s “big data world”, companies have the opportunity to access all the information they need to strive for creating great products and services, yet they often fail to deliver the right ones to customers. Research shows that customers don’t really care about seven out of every ten products. How is that possible? And more importantly, how can it be avoided?
There are two team definitions in Scrum which can sometimes be confusing.
The Scrum team by definition is a self-organizing cross-functional team that regularly delivers potentially shippable product increments.