Let’s be honest. What a lot of teams call “Agile development” is really just Waterfall without all the documentation. How about your organization? Are you truly Agile? Or are you just treading the no man’s land between Agile and Waterfall without seeing the full benefits of either? Take this quick quiz to find out:
1. Do your “sprints” look more like “phases”?
A. We’re working in short sprints with our eye on the short-term.
B. We’re working in phases centered around analysis, design, coding and testing and are focused more on the end result.
Two- to four-week sprints are the cornerstone of Agile development. If you work in phases, you can almost guarantee that your testing process will be cut short (because the project has run out of time or money). Worse, if product requirements change – and they usually do – you’ll have a lot more work to undo. By working in sprints, risk is reduced and changes cost far less.
Agile methodology dictates that focus should be on each sprint, not on the end prize. The Agile answer is A.
2. What happens when you fall behind?
A. We sometimes alter the delivery date.
B. We delete items in the current sprint.
Scrum methodology does not allow the altering of delivery dates. Instead, you should delete stories (points) from the current sprint. If you find yourself ahead of schedule, you can ask the product owner for more tasks. The Agile answer is B.
3. How are you handling product owner involvement?
A. The product owner is heavily involved at the beginning and end of the project, but not in day-to-day development.
B. The product owner participates in all daily meetings during development.
While the product owner may think repetition is a waste of time, daily, structured meetings ensure everyone stays on task. Yes, it’s asking a lot. But the consequences of not having the product owner involved daily are worse.
Both the business and tech side should be in perfect union. Bottom line, Agile is about fast feedback – and that’s difficult if the owner isn’t readily available. The Agile answer is B.
4. What’s the chain of command on your team?
A. Someone owns a particular module’s code, and the Scrum Master acts as Project Manager.
B. All code belongs to everyone, and the Scrum Master has a different role from the Project Manager.
All code should belong to everybody to ensure feedback is incorporated. Group ownership is often difficult, and it might even cause conflicts. But this methodology is proven to make code better.
Further, the Scrum Master should not act as Project Manager as these two roles are different. A Project Manager is typically in charge and is the decision maker. A Scrum Master serves as a facilitator. The Agile answer is B.
5. When do you release and test code?
A. We release and test the code developed at the end of each sprint.
B. We prefer to wait till a lot of code is developed before we release and test.
It’s not over just because you say it is. If your organization is Agile, code should be released and tested at the end of each sprint. Otherwise, tasks that should’ve been completed may not have been. If you wait too long, developers might not even remember the particulars of their deliverables! The Agile answer is A.
6. Do your product features ever change?
A. Sometimes product features get changed, and sometimes we develop features that had not originally been planned for the project.
B. The features that we start to build never change.
It’s difficult to know exactly what’s best when starting a project. When you have daily collaboration and honest feedback, changes will – and likely should – occur. Agile teams not only accept change, they embrace it. Requirements evolve … often in short periods of time.
Waterfall environments deal poorly with change. Agile environments? They don’t call it agile for nothing. Yes, the Agile answer is A.
So how did you do?
Got all the answers correct? You’re likely operating a true Agile environment. Missed some? You’re in Water-scrum-fall land, and it’s time to get out.