Abstract
You have analyzed your urgency, developed your vision down to the details, and communicated it so vividly that even the cleaning staff knows exactly where the journey is headed. You have also empowered your employees on a broad basis and removed the biggest obstacles. Excellent! If you now believe, however, the work is done, and you could sit back, then you are mistaken. Even if you really have done everything that is needed for your long-term success, this is only true for the moment. To keep the motivation of your employees high for the long run—and your own, of course—you must also ensure short-term success (cf. Kotter 2012, p. 123). In this chapter, you will learn why this is so important and what you should heed.
This is a preview of subscription content, log in via an institution.
Buying options
Tax calculation will be finalised at checkout
Purchases are for personal use only
Learn about institutional subscriptionsNotes
- 1.
Your teams are distributed, if complete teams sit at different locations. For example, team red sits in the USA and team blue works in Germany. Your team is dispersed if the team members of one team are scattered around various locations. E.g. Peter in Bulgaria, Marc and Steffi in Germany, Uta in the USA, and so on.
- 2.
I use the term “complexity” in the context of “uncertainty”. The higher the complexity, the more uncertainty there is. As a consequence, the precision of planning decreases and risks increase. Since you already have enough process uncertainty when introducing Scrum, it is worthwhile to reduce other complexity factors.
- 3.
In my experience a Development Team with seven developers costs around €100,000 per month. Of course, this depends very much on whether you are working with internal staff or foreign workers. In addition, the hourly rates vary strongly. However, this amount has proven to be quite accurate as a rule of thumb.
- 4.
I personally used Skype/Lync, Teamviewer and Hangout so far. Other products will work as well of course. Important, however, is that the psychological barrier to actually use the software must be low. This is not the case if you need dial-in codes, register processes, or other wasteful steps.
- 5.
Trying out different Sprint lengths does not make sense in any case. Often, Scrum Masters or Scrum coaches have a fairly good impression of what would make sense for a new team. An inexperienced team might lack this foresight if they have never tried Scrum before. It is still important to involve the team, value their opinions, and facilitate its self-organization. This can mean that you have to work in a sub-optimal setting from time to time.
- 6.
The discussion most often heard is that “four weeks are far too short to deliver something of value”. This discussion usually vanishes quickly once the team actually starts working in Scrum. Do not fall for it.
- 7.
Compare with the chapter “Estimation” Meeting in the appendix.
- 8.
You can find more about the Definition of Done in the appendix.
- 9.
There may be very specific situations in which the Product Owner only needs a document. In research teams, this is more often the case. This is similar with source code and tests: There are exceptions, but usually it comes down to executable software.
- 10.
Also see chapter “events” in the appendix.
- 11.
This example was part of the February 2012 courseware of the Professional Scrum Master course by Scrum.org.
- 12.
For a few tips on how to do this, refer to the appendix.
- 13.
You do not believe this? Now consider how costly it is to fix a bug during development. Or during the test phase. Or once it has reached the customer. To do this, use the numbers of your own organization—this is better than any statistics.
- 14.
Wikipedia gives a good overview over this topic: http://en.wikipedia.org/wiki/Software_craftsmanship
- 15.
Caution: There are contexts in which this is very useful. For example it might be necessary in safety-critical contexts or for tests which the Development Team cannot do in one Sprint. Or would you send your developers to Scandinavia for vehicle testing every Sprint?
- 16.
You can find an explanation of “timebox” in the appendix.
- 17.
See the appendix for more about velocity.
References
Campbell, D. T. (1976). Assessing the impact of planned social change. Occasional paper series. Reprinted with permission of The Public Affairs Center, Dartmouth College. December 1976, Paper #8, pp. 1–70.
Kotter, J. (2012). Leading change (New ed.). Boston: Harvard Business Review.
Kraut, R. E., & Streeter, L. A. (1995, March). Coordination in software development. Communications of the ACM, 38(3), 69–81.
Sutherland, J. (2008). Agile contracts: Money for nothing and your change for free. 25.10.2008. jeffsutherland.com. 23.03.2014. http://scrum.jeffsutherland.com/2008/10/agile-contracts-money-for-nothing-and.html
Weinberg, G. M. (1991). Quality software management: Systems thinking. New York: Dorset House.
Author information
Authors and Affiliations
Rights and permissions
Copyright information
© 2018 Springer International Publishing AG, part of Springer Nature
About this chapter
Cite this chapter
Maximini, D. (2018). Generate Quick Wins. In: The Scrum Culture. Management for Professionals. Springer, Cham. https://doi.org/10.1007/978-3-319-73842-0_11
Download citation
DOI: https://doi.org/10.1007/978-3-319-73842-0_11
Published:
Publisher Name: Springer, Cham
Print ISBN: 978-3-319-73841-3
Online ISBN: 978-3-319-73842-0
eBook Packages: Business and ManagementBusiness and Management (R0)