“Good, fast, cheap: pick any two” is an often heard project management statement. It is a trilemma from the classic management triangle. The joke is often used to subtly figuring out the budget, deadlines and the requirements.
A Venn diagram does perfectly visualise project limitations and makes it very understandable and logical.
Although this conceptual model helps us think about the project constraints, logically it is not very solid.
There are lots of ways to develop software. From the "cowboy coding" that involves no design, no documentation, and no testing to strict and rigorous processes. Almost all software development standards describe how to perform and improve specifications, designs, coding, and testing.
The end goal of all software development processes are: creating software that works as intended, is on time, within budget and can be maintained. But which development approach is the best?
Is this context-dependent or are there any generic aspects so that an overarching software development "framework" can be labeled as "best practice" for the status quo?
At the beginning of a new to start project, I get the question how to set up the project organization. I try always to answer it shortly:
The project organization must consist of as few people as possible and only dedicated people that will really contribute to the project and has interests that the project will succeed.
It is a loaded answer with a lot of criteria and questions in it. It can be helpfull to explain the underlying reasoning.
I work now for 1 month on an assignment for Minoto Video. It is a SaaS platform for video that can be used for easily placing video's on a website or to integrate it within an application by using the API. The goal is to be something like Heroku for video implementations.
In the short period I am working here, I have learned some things that I am going to sum up so I can reflect later on.
There are many reasons for fallacies, many arise from oversimplification and others from urban myths. I have listed the most common and harmful ones.
The key to success is the ability to adapt to the changes that the new media brings. There is not much to gain by either resisting or denying it.
Internet has its own rules and influence. As a result, more and more people are forced to make sense of it. But it doesn't work the other way around.
If you want to order a pizza and don’t want just one of the regular pizza’s on the menu, you can of course build your own pizza. At that moment, things will get really complicated. If you just choose a couple of toppings, it is likely that your pizza is not special at all: It’s just a variation on one of the pizzas on the menu. Then you get aware that actually someone profoundly thought about the pizza’s on the menu and configured the pizza’s really in a smart and logical way already.
Pizza syndrome is a metaphor that I use to describe the phenomenon when you want to “order” an extraordinary web product.
But if you insist to not order a regular pizza, one thing you can do is add a lot of toppings on your pizza. It is a sure way that your pizza is really unique and one-off. At the other hand, you are also sure that it is uneatable. It is not tasteful to add anchovies, salmon and shrimps combined with brie, bacon, chicken and spinach.
Agilists are not to be divided into divisions or sections but rather be united under one manifesto. Common purpose is off course the same: uncovering better ways of developing. However, since the publication of the agile manifesto, there have arisen distinctions into schools of thought, methods, traditions, and related practices. Furthermore, the same organic and natural emergence of fragmentation happens also with Scrum.
Since the publication of the agile manifesto, there have arisen distinctions into schools of thought, methods, traditions, and related practices.
While implementing Scrum in an organisation, there is always a discussion about the implementation of rules and the level of flexibility. Some practitioners argue that all best practices must be followed as literally as possible and that it is otherwise not Scrum. Other practitioners argue that the essence is important and that the practices are all up to individuals to follow, change or set aside. While the description of a practice can be very clear, the implementation in practice may still differ from team to team. Like a religion we can say that there are interpretation and perception differences caused by the context.
It strikes me that web development projects often do not learn enough from the past experiences in other fields. One of these problems lies in the area of (new) product development. Most web development projects have not enough emphasis on product management. While agile development practices heavily encourage to "take action", they are off course not against substantial thinking about the product. To stress the importance of a well thought out product road map, Scrum tries to constrain it by saying "A sprint should only begin if the product backlog is prioritized and ready".
Web development projects have not enough emphasis on product management.
But Scrum doesn't give you product management tools because Scrum is not a silver bullet. It is just a framework for completing complex projects. Scrum is not a market research method or a tool for generating new business ideas. It is said so many times but maybe not often enough, because I hear still people talking about Scrum if it is a silver bullet. Scrum is neither a substitute for skilled and experienced developers who write good code or solid engineering practices.
It is not my goal to discuss if it is possible to apply agile principles to fixed scope and/or fixed budget projects. That has already been discussed enough and the conclusion is simply: “a lot of people think it is possible, and a lot of people think that’s not agile anymore.”
My goal is to clarify the advantages of working without a fixed scope and budget, for the customer of a web development project.
But what is actually a fixed scope and budget project in simple words? Simply put, it means that a customer asks: “Can you tell me in advance how much it approximatively will cost with these features in your mind?” Translated to the Scrum terminology: “How many sprints do we need to realize this product backlog?” It is an innocent and well-meant question. But if it is not adequately dealt with, it can have far reaching effects.
The origin of Scrum lies in software engineering where visual appeal didn't really matter. When we mention software design, most people will think about the technical design and not the visual look of the software. On the other hand, website development is a lot about visual communication. Therefor when we mention website design, most people will in contrast think about the visual aspects.
When we mention website design, most people will in contrast think about the visual aspects.
Here lies the challenge when Scrum is applied at website development. A product backlog is not seen sufficient when the product owners wants to describe the visual communication requirements. As a solution, they want graphic designers to design the website upfront. But this complicate things even more, because a graphic design implicitly requires functional solutions. They fall unconsciously in to the trap of "Big Design Up Front".