Agile methods have been around for a long time. It was pointed out that projects using "iterative and incremental development" have been undertaken from 1957, and was common in the 1970s (Abbas et al., 2008, p. 94). It just got a snappy name and a some snazzy consultancy bundling in the late 90s. Re-badging, anyone?
Agile - collectively - has been defined as techniques which are "adaptive, iterative and incremental, and people oriented" (Abbas et al., 2008, p. 94), and can be either a philosophy, a set of practices, or a way to keep things moving QUICKLY (Schwaber, 2004). A way of looking at this might be to consider if "there were an incremental, iterative approach for constructi[ng a house, and] houses were built room by room. The plumbing, electrical, and infrastructure would be built in the first room and then extended to each room as it was constructed. Buyers could move in as soon as they had decided that enough rooms had been completed. Then additional rooms could be constructed depending on the needs of the buyer" (Schwaber, 2004, p. xviii).
The idea is that there is a very rough plan, which swings straight into design, then developm then test, then deploy. There is a minimal review, followed by as many reiterations of design-develop-test-deploy-review as needed until full launch.
The scrum and sprint elements are related to how rugby is played, written up in 1986 by Takeuchi and Nonaka and published in the HBR, who said this 'rugby' "approach [was] 'where a team tries to go the whole distance as a unit, passing the ball back and forth'" (Rigby et al., 2016, p. 1). The idea is that development is kept moving and no breathers are taken (Sutherland, 2005). New product development just keeps pushing on until the 'game' is won; so to speak.
However, we need to keep front of mind that agile and scrum arose largely as tools for software development. These were a "response to change, customer involvement, and working software over documentation" (Abbas et al., 2008, p. 94). The "infrastructure is deployed, pieces of functionality are delivered to [the] organization[ so they] can start using [...] system [elements] early in the development cycle" (Schwaber, 2004, p. xviii). We do as much as we need to do to keep the client moving towards their intended outcomes, and this system allows us to adapt when the client realises that there are "missing and changing requirements" (Abbas et al., 2008, p. 97) because the client brief was inadequate. We don't know what we don't know. Agile allows us to - depending on what the client's next outcomes are - consider tweaking a system while the client is using it (Abbas et al., 2008; Schwaber, 2004).
Development is effectively prototyping. Agile systems are not intended to replace planning, budgeting, control of a process, or documentation.
And it doesn't really suit government departments. Government systems are usually too ponderous, and the decision-making process too slow and requiring too much documentation for Agile systems to work well.
Sam
References:
Abbas, N., Gravell, A. M., & Wills, G. B. (2008). Chapter 10 Historical roots of agile methods: Where did “Agile thinking” come from?. In P. Abrahamsson, R. Baskerville, K. Conboy, B. Fitzgerald, L. Morgan, X. Wang (Eds.), Agile Processes in Software Engineering and Extreme Programming Proceedings (Vol. 9, pp. 94-103).Springer Science & Business Media
Rigby, D. K., Sutherland, J., & Takeuchi, H. (2016, April). The Secret History of Agile Innovation. Harvard Business Review Blog. https://hbr.org/2016/04/the-secret-history-of-agile-innovation
Schwaber, K. (2004). Agile Project Management with Scrum. Microsoft Press.
Sutherland, J. (2005, July). Future of scrum: Parallel pipelining of sprints in complex projects [paper]. Agile Development Conference, IEEE, 24-29 July 2005, Denver USA. http://jeffsutherland.com/scrum/SutherlandFutureOfScrumAgile2005.pdf
No comments :
Post a Comment
Thanks for your feedback. The elves will post it shortly.