I started this post a while back, meaning a couple weeks ago. I started it for the reasons I start any blog post, because I had both a flicker of inspiration and a few minutes to begin writing something. I realized after a while that I was sort of rambling, another good attribute of my blog posts. So instead of going on rambling I thought maybe I should begin breaking this into little doses, so that it is apparent that I'm just rambling. And now I'm rambling, so without further ado, part one on my thoughts bout applying Ssrum outside of the domain of software development:
So I'm already about halfway through my friend Jared's book dealing with sports psychology. I had said to him that I was looking to mine it for ideas for helping me as a ScrumMaster considering that a ScrumMaster is a sort of coach. We certainly coach teams, especially new team members in the Scrum process. We deal with monitoring the team performance and trying to find ways to improve. ScrumMasters help motivate and focus the development team. Finally, we shield them from negative outside influences that would detract from the team performance. So, there are ways where being a ScrumMaster is very much like being the coach of an athletic team, though I said previously that it may be a little more like coaching a golf team than a football team. (Of course, as I'll point out, a Scrum team is like a rugby team in more ways than one.)
Well, Jared turned the question back on me, saying he'd like to learn more about Scrum to see how it might apply to what he does in regards to sports psychology. I thought about that. How would I describe Scrum to someone completely outside the domain of where we use it? That idea certainly isn't foreign to anyone who has practiced Scrum for any length time: You need to get business managers and executives to buy into Scrum or Agile practices at least, you need to sometimes guide product owners in why it works, and there are sometimes when you need to explain it to the customer directly. Still, while they are all stakeholders in the process, besides the product owner they really only need as much understanding as needed to let the dev. team do its thing. Customers, upper management, they aren't really "practicing Scrum" (unless you are lucky). So where does one start to get relatively good understanding from someone outside the domain of software programming?
First off, I'll say as an aside, that if you are a business person interested in how Scrum can affect business practices, you are really better off looking into Lean practices. The Lean software development practice was adopted from the Lean manufacturing process which was built from the Toyota Production System. Frankly, I don't know Lean near as well as I know Scrum. Maybe someday I'll learn enough to feel comfortable writing a blog post about it.
While Jared writes from the point-of-view of practicing, playing, and coaching football, I work in the domain of voting machines and elections software. So that's where some of my examples will come from.
Any discussion of Scrum needs to start with a discussion of Agile methodologies. "Agile" has become such a buzzword in software development, and it's one that like many buzzwords, few people really understand before they bandy it about. Software development is a very, very recent and evolving practice. If you think about it, man has been building houses since he first moved out of the caves. The art of architecture is at least older than the Great Pyramids. The art of creating software is not so old, so new rules and practices are always being tried. Well, some years back, a bunch of programmers got together and (I like to think) had a bunch of pitchers of beer trying to solve all the problems inherent in this nascent practice and came up with a manifesto, the Agile Manifesto for Software Development:
To me an Agile software development methodology is one that values those things on the left sides of the statement over those on the right. That leaves a lot of room for interpretation on just how to accomplish that, but it also means that just saying that your team embraces responding to change doesn't make it an Agile team. There are three other lines in that manifesto. Certainly those values aren't only valuable to software development, and could easily be applied to other types of business. So I want to highlight in this discussion those areas where Agile practices and Scrum in particular could be generalized.
So I'm already about halfway through my friend Jared's book dealing with sports psychology. I had said to him that I was looking to mine it for ideas for helping me as a ScrumMaster considering that a ScrumMaster is a sort of coach. We certainly coach teams, especially new team members in the Scrum process. We deal with monitoring the team performance and trying to find ways to improve. ScrumMasters help motivate and focus the development team. Finally, we shield them from negative outside influences that would detract from the team performance. So, there are ways where being a ScrumMaster is very much like being the coach of an athletic team, though I said previously that it may be a little more like coaching a golf team than a football team. (Of course, as I'll point out, a Scrum team is like a rugby team in more ways than one.)
Well, Jared turned the question back on me, saying he'd like to learn more about Scrum to see how it might apply to what he does in regards to sports psychology. I thought about that. How would I describe Scrum to someone completely outside the domain of where we use it? That idea certainly isn't foreign to anyone who has practiced Scrum for any length time: You need to get business managers and executives to buy into Scrum or Agile practices at least, you need to sometimes guide product owners in why it works, and there are sometimes when you need to explain it to the customer directly. Still, while they are all stakeholders in the process, besides the product owner they really only need as much understanding as needed to let the dev. team do its thing. Customers, upper management, they aren't really "practicing Scrum" (unless you are lucky). So where does one start to get relatively good understanding from someone outside the domain of software programming?
First off, I'll say as an aside, that if you are a business person interested in how Scrum can affect business practices, you are really better off looking into Lean practices. The Lean software development practice was adopted from the Lean manufacturing process which was built from the Toyota Production System. Frankly, I don't know Lean near as well as I know Scrum. Maybe someday I'll learn enough to feel comfortable writing a blog post about it.
While Jared writes from the point-of-view of practicing, playing, and coaching football, I work in the domain of voting machines and elections software. So that's where some of my examples will come from.
Any discussion of Scrum needs to start with a discussion of Agile methodologies. "Agile" has become such a buzzword in software development, and it's one that like many buzzwords, few people really understand before they bandy it about. Software development is a very, very recent and evolving practice. If you think about it, man has been building houses since he first moved out of the caves. The art of architecture is at least older than the Great Pyramids. The art of creating software is not so old, so new rules and practices are always being tried. Well, some years back, a bunch of programmers got together and (I like to think) had a bunch of pitchers of beer trying to solve all the problems inherent in this nascent practice and came up with a manifesto, the Agile Manifesto for Software Development:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Kent BeckMike BeedleArie van BennekumAlistair CockburnWard CunninghamMartin FowlerJames GrenningJim HighsmithAndrew HuntRon JeffriesJon KernBrian MarickRobert C. MartinSteve MellorKen SchwaberJeff SutherlandDave Thomas
© 2001, the above authorsThis declaration may be freely copied in any form, but only in its entirety through this notice.
To me an Agile software development methodology is one that values those things on the left sides of the statement over those on the right. That leaves a lot of room for interpretation on just how to accomplish that, but it also means that just saying that your team embraces responding to change doesn't make it an Agile team. There are three other lines in that manifesto. Certainly those values aren't only valuable to software development, and could easily be applied to other types of business. So I want to highlight in this discussion those areas where Agile practices and Scrum in particular could be generalized.
