What this concept does reinforce is the need for an individual to : be aware of and understand areas of operation outside his or her silo ; expand the project horizon ; be fully vested in and accountable for the end result ; and work to remove all artificial barriers to delivering value faster . These things in themselves create a significant value-add to any organization . If one full stack developer can provide so much value , what if we have 10 , 20 or 100 of them ? And what if we put them together into full stack teams ? But is that what a full stack team is , a team of full stack developers ? NO . A full stack team is NOT a team of full stack developers .
As much as we believe everything in our lives is moving toward software , there are more areas than that which need to be addressed for a product to be released . These include : business analysis , testing , product management , stakeholder management , communications and more . What a full stack team borrows from the full stack development approach is the idea that it is operating as a frictionless , self-sufficient , value-generating unit . Here are the five characteristics of a true full stack team
1 . Self-sufficient 2 . Empowered 3 . Agile
4 . Accountable 5 . Value generating
Self-Sufficient
1 2
Similar to the full stack developer , the full stack team should be able to address all aspects of the project or engagement . This will most likely cover everything from business analysis to architectural design to the hands-on implementation of the solution at all levels -- networking , database , software , testing , documentation , knowledge transfer , etc . You might even have one or more full stack developers on the full stack team . The key point is that the team needs to be autonomous and should have the right skills and the right tools to deliver the needed outcome .
Empowered
The full stack team must be empowered to make appropriate decisions , and the empowerment needs to come from the top . This is extremely important ! Decisions the team will make vary from feature implementation to architectural design to how the product is released . The team has to have the power to prioritize what to work on , when and how . If it has to constantly go ask for approvals elsewhere , it is not an empowered team and the process is full of unnecessary roadblocks . Plus , if the team cannot make its own decisions , it cannot be held accountable for decisions others made for it .
46 | THE DOPPLER | SUMMER 2018