A Software Developer in an Agile World
Scrum from a developer’s point of view.
Scrum is a form of agile project management that makes a team more flexible and capable of handling changes more efficiently than the other competing project management techniques. However, we seem to overlook one crucial aspect, and that’s the aspect of the developer working in the agile team. I want to make a couple of observations regarding being an agile developer in this post.
We all hate meetings...
Most people, myself included, almost cringe at the term “meeting”. Is it my introverted personality not wanting the human interaction? Or is it that I may not get what I need? Either way, I hate unnecessary meetings. I would rather have a one-on-one conversation with my client to discover their needs instead of long, drawn out talks about items that may or may not pertain to my situation. This is what I love about Scrum, because a lot of meetings are delegated to the product owner. They are responsible for creating our user stories and seeing the vision, meaning that my focus can actually be toward the client and what they want to see rather than having those meetings that I really don’t want or need to have.
The process is meant to help, not hinder!
A lot of the opposition for Scrum or Agile comes from the fact that we have a lot of processes that people may deem unnecessary like iteration planning, grooming or retrospectives. However, these processes are put in place to help keep everyone in check and focused on what is important at this time!
Iteration (Sprint) planning may be a pain to some, but they are the kind of meetings that I find value in. They give me all the information I need to truly understand the scope of work that we are to complete during the current iteration.
Grooming provides a valuable insight into future work and how it ties into what we are doing now. This is beneficial when you start thinking about the bigger picture, and making sure you are planning your architecture for everything you need in the future.
Retrospective is usually quick, but can be that slap in the face you need to get back on track with reality. Maybe you didn’t do something you should have, or maybe you are doing something you shouldn’t be doing. Retro provides an open platform for your team to address that so you can get better as a developer and team member.
There’s no Scrum bible! The process can be tweaked!
Looking back into my experience with Scrum, I don’t think I belonged to a single team that practiced scrum to a T. We always took things away from the process, or simplified our planning sessions to save on time and sanity. Even though we tweaked the process, we still maintained our high velocity while delivered quality products to the customer. If anything, this has served as an example of where you can still be successful and not follow every aspect of Scrum. So, pay attention to your team and your client; you may be able to save your team some time by eliminating unnecessary processes.
Don’t forget the bigger picture!
Last, but not least, never forget the bigger picture. I’ve seen it before and I’m sure I’ll see it again, where someone fails to understand the requirements and codes themselves into a corner by developing on an idea that doesn’t meet future requirements. Make sure you understand EXACTLY what your requirements are, not just what you need to work on during your current iteration, but what you’ll have to work on during future iterations.