Should engineering companies developing high technology products with very small teams - of perhaps 3 or 4 engineers, use Agile Development ?
I'm sure we all have an opinion on this, but whether you adopt Agile, Waterfall or a hybrid approach will append on many factors which define your own particular situation. What is your company culture and in which method are your team most experienced ? is your product aimed at a highly regulatory market, is this a project based on novel technology, or an evolution of an existing product ?
"...we have come to value :
- Individuals and interactions over processes and tools.
- Working software over comprehensive documentation.
- Customer collaboration over contract negotiation.
- Responding to change over following a plan.
That is, whilst there is value in the items on the right, we value the items on the right more."
Individuals and interactions
For that small team, unless the processes have already been established, to be successful the project needs individuals who are experienced, competent and motivated, and who openly and freely communicate with each other.
If the team size increases in future, more formal processes will become necessary, to support the new engineers, particularly for more junior engineers and those not familiar with the project domain.
Working software
Comprehensive documentation is great, but it takes time and effort to create, increasing the time to market, and when the company will a return on the investment. It also needs to be maintained, to be relevant and a trustworthy reference as the software evolves. Working software can be sold, and with a small experienced team the codebase can be used as the document - use of commenting and a tool such as doxygen (2020) to automate creating documentation can help here.
Since most software spends the majority of its time in maintenance, the lack of documentation can become an issue. As software evolves, it becomes more complex. Whilst this can be managed to some extent through refactoring, if the time to do this is available, the complexity will increase as new features are added. Also, the project team might change, and even those team members who remain will find that once they haven't worked in an area of the code for a while they will forget how it was designed. Finally, the importance of good design documentation will increase if the project becomes long-term, perhaps as it develops into a software product line, and the team size increases. It is very difficult for a new engineer to understand a large code base when presented only with the code, some simple high level UML diagrams would certainly make life easier.
Customer collaboration
Customer collaboration is essential if you are to develop the product that they want, as opposed to the product you think they want (validation of the product requirements.) Again, this becomes harder as the project and team size increases - who is going to manage that customer contact, and how are they going to communicate those requirements back to the project team ?
Responding to change
A company must respond to change if it is to be successful. With a small team this should be easy to manage, through conversation - evaluation of the issue, the possible solutions and then agreement of the direction to take. Everyone can discuss the impact the possible solutions will have on their area of the product development, and mutually the team decide the best way forward.
This again becomes more difficult as the team size increases, or is not co-located. Perhaps it is not possible, or efficient to bring everyone together to discuss individual issues encountered. A more formal process is required, which defines how the issues are escalated, who is involved in finding the solution, and how the changes are managed.
Conclusions
I believe the Agile methodology does effectively support product development within small engineering teams. However, as Boehm (2002 ) stated all those years ago, it should be approached with caution, and as the company and project team size grow, it should be re-assessed and more formal processes introduced as necessary to manage the larger team and their more complex interactions.
References
Agile Alliance (2001) The Agile Manifesto [Online]. Available at https://www.agilealliance.org/agile101/the-agile-manifesto/ (Accessed 7 June 2020)
Boehm, B.W. (2002) Get Ready for Agile Methods, with Care. IEEE Computer 35 (2002): 64-69.
Boehm, B. (2002) ‘Get ready for agile methods, with care’, Computer. LOS ALAMITOS: IEEE, 35(1), pp. 64–69. [Online]. DOI: 10.1109/2.976920. (Accessed 7 June 2020)
doxygen (2020) Generate documentation from source code [Online]. Available at https://sourceforge.net/projects/doxygen/ and https://www.doxygen.nl/index.html (Accessed 7 June 2020)
No comments:
Post a Comment