Agile project management has taken the business world by storm for the better part of the last two decades, and most recently, Scrum is dominating the landscape
On a project team, the goal is to get the project done. Historically, using traditional methods, this meant planning and designing the whole project at the beginning and sticking to that plan with no variation. In real life, project work is completely unpredictable. The Agile Project Management movement comes out of a desire to adapt in real time to the changing circumstances that teams face.
Empirical work is more like a science experiment. You try something, check out the results, and if it didn’t work, you try something else. You certainly can’t do that when building a house, but with software or some other products, you do it every day.
There are a couple of overriding themes that make Agile different. One of the key changes is that we’re asking our business partners to work with us throughout the whole project, not just show up at the beginning to describe what they want, then show up at the end and tell us how we missed the mark. We need direct, ongoing interaction to deliver what they really need. Another key is that we no longer want to measure success using milestones and project phases. We want working software to tell everyone how we’re doing, and we want to hear feedback the whole time.
Failure is okay, as long as you’re learning from it, but if you have to wait too long, you’re not going to learn nearly as much from it. Scrum takes the agile manifesto and its key principles and boils them down to a very simple framework that encourages small scale focus and rapid learning cycles.
Business needs are changing more rapidly than ever. Project requirements are shifting just as quickly to keep up.
Agile is a broad umbrella of many methodologies that follow the same principles. Scrum is one of them. Scrum took it a step further by creating a framework to help teams stay focused and protect them from distractions.
Scrum set the boundary for teams to deliver value as anywhere from two to four weeks.
- Planning
Getting Involved Early. Knowing who to talk to and how will help your team efficiently self-organize.
Picking your tools. This can be anything from project management and version control software, to third-party development libraries, and really anything in between.
To document or not. “Produce no document unless”its need is immediate and significant." So if the answer is no, don’t document until you feel it’s absolutely necessary.
- Design
Flexible architecture. When your hands touch the keyboard, you need to consider not only how you’re going to write good clean code, but how you can make it as flexible as possible for later expansion.
Avoiding premature optimization. Be aware of the trade offs between optimizing your code and moving forward with sprint tasks. It’s not about solving every problem before it happens. It’s about having a foundation that is adaptable enough to handle new problems and features as they come.
- Development
Determining velocity. It’s a good rule of thumb to think of your potential development velocity as about 30% of your actual sprint time. Now that might seem like you’re low-balling yourself, but I’m sure you’re no stranger to meetings, emails, random questions that turn into hours, and the like. Once you have a baseline velocity, each successive sprint can be planned more effectively. You want this to be steady or if possible, increasing. So if you aren’t hitting your sprint goals, decrease the load in the next sprint.
Refactor, then refactor more. The idea is more along the lines of small, continuous changes that improve your code base. This way, you have time to test your refactored improvements right alongside your development.
- Testing
Choosing your testing regimen. Use test-driven development. It’s important to get into the mindset of thinking about testing as a sprint priority.
Handling leapfrogging bugs. There will always be bugs that come up after the fact. You want to address bugs as early as possible. The product owner or client could decide on priority, but the important thing to focus on is not letting them build up in your production code for too long. If you’ve got bugs stacking up towards the end of a sprint, consider having the next sprint be focused on clearing them up and load up less on new development work.
- Release