10/11/2013
To every Myth there is always an equal destructive (Stupid) and opposite counter Myth:
Here are some Examples
Myth
You do not need to design up frontCounter Myth
Design is a one time effort which is best done before you startReality
You need to design some of your system up front and some of your system as you go. How much you need atg each stage depends upon your understanding of the problem, you technical skills & your system.
Myth
All user stories may be implemented independently from each otherCounter Myth
We must analyze all the dependencies between all features in order to lay out our critical pathReality
There will always be some dependencies between different user stories, however a lot of those can be eliminated with some effort invested during story slicing. Those which are left are usually obvious enough for a reasonable team to deal with.
Myth
you don't need architects.Counter Myth
A strong enough architect can design the system in such a way that anyone could implement it.or
The architect doesn’t need to codeReality
Every team needs to have strong design skills, when the projects becomes big enough a dedicated person (aka the architect) to help with the communication of the overall design and helping making sure everyone stays on the same picture is really important. However, the architect in order to be effective, needs to be involved in the day to day programming issues and challenges the team encounters. And at the end it will be the programmers that will do the implementation and they will adapt it according to their understanding so you better have a strong team as well.
Posted in: 
Posts
2 comments:
One word - THANKS
Design Myth:
The reality is that much of up-front design is based on the "known knowns" and assumptions made about the "known unknowns". Making wrong assumptions in design is something that is going to happen. In acknowledgement, people play the CYA game of documenting them as to shift blame to someone else. The bigger problem is when the "unknown unknowns" surface. This can result in huge refactoring or starting over with a new design which is wasted effort.
The issue with some "no up-front design" practices is that it is done without a clear understanding of the product vision and direction. That is called hacking. The development team needs to spent time with the product owner/manager to gain the initial understand of the product vision and direction. These initial conversations create the details of "known knowns." The elaboration process does not stop there. As the team begins to work on the "known unknowns," the dialog shifts to explore them and convert them to "known knowns" and the team enhances the design based on knowledge not assumptions. When "unknown unknowns" surface, the development team and product owner/manager have a shared language and common understand of the design to find a way to augment the design with the new information.
Story Independence Myth:
While I basically agree with the reality statement, it needs some additional elaboration starting with the "story slicing" comment. Vertical Slicing will produce stories that are independent of each other. However, if the stories are sliced based on architectural tiers, there will be dependence and greater exposure to the "unknowns" described above.
Another aspect of story independence is not setting priority based on end user experience. For example, user authentication and authorization is something that is important to any product. However, implement one of the many possible solutions available provides less business value than stories related to the core purpose of the product.
Architect Myth:
There are actually different versions of this myth based on expertise (e.g. database, UI, etc.). I am a firm believer of cross-functional teams. That does not mean that a project regardless of size should not have any specialists on the development team. If a team is only comprised of "jacks of all trades, master of none," the team will miss out on the opportunity to create a truly superior product. It is important that these specialists know that they are not gods. The other team members should be encouraged to question direction that the specialist is taking. It will be through the resulting conversations that everyone will learn and the superior product will emerge.
Post a Comment