“We don’t need to do <blank>, we’re doing Scrum.”
I’ve heard some beginning Scrum teams say this. They think that doing Scrum is their get-out-of-jail-free card, freeing them from doing architecture, design, documentation or even thinking about what they are doing. Compared to waterfall, Scrum is a lightweight process but it is a process and there are essential pieces that cannot be skipped. In fact, the purpose of Scrum is to help us stay aware of these things throughout the development process, not just in the beginning.
“We don’t need to worry about architecture, we’re doing Scrum.”
In Scrum, we try to avoid a big upfront architecture but that doesn’t mean we do no architecture. There are certain things that we must figure out upfront, like what platform our code will run on. Our approach will be different if we are building a high availability online reservation system verses a point-of-sale cash register system for the local grocery store.
Our goal in Scrum is to figure out upfront what needs to be figured out at the beginning and defer on what we can figure out later. Why? Because we’ll know more later and we want to take advantage of that knowledge so we make the most informed decisions when we know the most.
“We don’t need to do any design, we’re doing Scrum.”
Again, I hear new Scrum teams say they don’t need to do design. In reality, we do more design in Scrum than we did in waterfall. In waterfall development, we do design upfront in a distinct phase and then we implement that design, sometimes blindly. In Scrum, we design as we go throughout the development process. There is never a point in Scrum development where we go on “automatic” and just execute the specification. We use the many feedback mechanisms in Scum to refine our designs as we go to build a better system for our customers.
It is easy to overdesign. If you have ever “painted yourself into a corner” when coding then you know how painful this can be and you probably want to avoid getting into that situation again. The remedy for most of us is to do a really good job at upfront design and be as complete as we can. But the problem is that we can’t predict the future and it is often a futile effort to try.
Like architecture, design is something best done as we go, for the most part, because we will know more and be more familiar with the problem when we get into it. There are some design decisions we must make up front but many design decisions, both big and small, can be done as we go if we know how to keep ourselves from getting stuck.
In reality, even waterfall development does a lot of design throughout the development process because even the best specifications cannot account for every little detail and many details are best worked out when we code. Scrum simply acknowledges this and provides a framework to support it.
Of course, if you see a design solution early in the process and you will need them later, there is nothing in Scrum that says you have to ignore it. Scrum just says that we should not be overly focused on design for work that may or may not be needed in the future.
The idea here is not to blindly follow a plan, the idea is to stay alert and focused on the problem as we are solving and not get too concerned with what might be needed later. If we build our software with good engineering practices then new requirements will be easy to add later.
“We don’t need to write any documentation, we’re doing Scrum.”
In XP we say “Barely sufficient documentation.” Software development projects are about developing software and creating artifacts can get in the way of that. Internal documentation can be useful but what tends to be even more useful is code that can be read and understood without having to reach for a separate document. If our code has unit tests then you can see exactly how the code is intended to be called by looking at the tests and there is less need for internal documentation.
I’ve heard these kinds of excuses from more than one development team but this is not what Scrum says! Scrum, XP and other Agile methodologies are lightweight compared to waterfall but we still have to think about what we are doing, not just upfront but throughout the entire development process. We don’t want to do all our planning in the beginning, we want to do it throughout the development process and be flexible to change our plans as needed.
Scrum projects do not need all the checks and balances of waterfall if we focus on building the right things and keeping our quality high. This is a key presupposition for Scrum projects that I don’t always see beginning teams fully get. We must follow development standards, keep code clean, and pay down on technical debt as we go in order to build software that can support a lightweight process.
If we know and follow good engineering practices then we don’t need as many of the checks and balances as in traditional waterfall development and we can put that effort into building more features and building them with higher quality because this is ultimately what will benefit our users the most.
“We don’t need to do <blank>, we’re doing Scrum.”
I’ve heard some beginning Scrum teams say this. They think that doing Scrum is their get-out-of-jail-free card, freeing them from doing architecture, design, documentation or even thinking about what they are doing. Compared to waterfall, Scrum is a lightweight process but it is a process and there are essential pieces that cannot be skipped. In fact, the purpose of Scrum is to help us stay aware of these things throughout the development process, not just in the beginning.
“We don’t need to worry about architecture, we’re doing Scrum.”
In Scrum, we try to avoid a big upfront architecture but that doesn’t mean we do no architecture. There are certain things that we must figure out upfront, like what platform our code will run on. Our approach will be different if we are building a high availability online reservation system verses a point-of-sale cash register system for the local grocery store.
Our goal in Scrum is to figure out upfront what needs to be figured out at the beginning and defer on what we can figure out later. Why? Because we’ll know more later and we want to take advantage of that knowledge so we make the most informed decisions when we know the most.
“We don’t need to do any design, we’re doing Scrum.”
Again, I hear new Scrum teams say they don’t need to do design. In reality, we do more design in Scrum than we did in waterfall. In waterfall development, we do design upfront in a distinct phase and then we implement that design, sometimes blindly. In Scrum, we design as we go throughout the development process. There is never a point in Scrum development where we go on “automatic” and just execute the specification. We use the many feedback mechanisms in Scum to refine our designs as we go to build a better system for our customers.
It is easy to overdesign. If you have ever “painted yourself into a corner” when coding then you know how painful this can be and the temptation to avoid getting into that situation again. The remedy for most of us is to do a really good job at upfront design. But the problem is that we can’t predict the future and it is often a futile effort to try.
Like architecture, design is something best done as we go, for the most part, because we will know more and be more familiar with the problem when we get into it. There are some design decisions we must make up front but many design decisions, both big and small, can be done as we go if we know how to keep ourselves from getting stuck.
In reality, even waterfall development does a lot of design throughout the development process because even the best specifications cannot account for every little detail and many details are best worked out when we code. Scrum simply acknowledges this and provides a framework to support it.
Of course, if you see a design solution early in the process and you will need them later, there is nothing in Scrum that says you have to ignore it. Scrum just says that we should not be overly focused on design for work that may or may not be needed in the future.
The idea here is not to blindly follow a plan, the idea is to stay alert and focused on the problem as we are solving and not get too concerned with what might be needed later. If we build our software with good engineering practices then new requirements will be easy to add later.
“We don’t need to write any documentation, we’re doing Scrum.”
In XP we say “Barely sufficient documentation.” Software development projects are about developing software and creating artifacts can get in the way of that. Internal documentation can be useful but what tends to be even more useful is code that can be read and understood without having to reach for a separate document. If our code has unit tests then you can see exactly how the code is intended to be called by looking at the tests and there is less need for internal documentation.
I’ve heard these kinds of excuses from more than one development team but this is not what Scrum says! Scrum, XP and other Agile methodologies are lightweight compared to waterfall but we still have to think about what we are doing, not just upfront but throughout the entire development process. We don’t want to do all our planning in the beginning, we want to do it throughout the development process and be flexible to change our plans as needed.
Agile projects do not need all the checks and balances of waterfall if we focus on building the right things and keeping our code quality high. This is a key presupposition for Scrum projects that I don’t always see beginning teams fully get. We must follow development standards, keep code clean, and pay down on technical debt as we go in order to build software that can support a lightweight process.
If we know and follow good engineering practices then we don’t need as many of the checks and balances as in traditional waterfall development and we can put that effort into building more features and building them with higher quality because this is ultimately what will benefit our users the most.
{1 Comments }
Previous Post: « Do You Mentor?
Next Post: Don’t Do (Up Front) Design »
Excellent points! Scrum is simpler and leaner than most waterfall approaches but it is not an excuse to put blinders on and crank code. Every software project needs structure and discipline. The Scrum team, including the PO, need to decide which project artifacts are needed. The business situation may demand piles of documentation or lots of charts and diagrams. If so, the team should find someone skilled at generating the required artifacts and get that person on the team.
Then, an educational process can begin to teach people outside the team how software can be developed without all the artifact overhead. In the end, Scrum teams can only succeed with the support of the business. It’s our responsibility to inform and educate so we can win that support.