Happy to publish this guest post.
Joe Woods is one of the top SEO and Internet Marketing Specialists in the Southeast US and has worked with Agile and Scrum since 2007. Joe currently works with Version One and many of the industry’s leading Agile coaches to help IT teams and practitioners evangelize the many different process from Agile, Scrum, XP and Kanban.
This is my view of the agile software development process from an outsider’s perspective. Now I’m no agile expert, far from it actually. I was always told that we’re an agile shop or that we use waterfall (cringe). Ok, that’s fair enough. All that meant to me was that we do releases every couple weeks or weekly and I have to go to a bunch of team meetings. I also would have to write these things called stories and they couldn’t be too broad and being too narrow meant I missed some functionality. It always seems to be the case that the last place I worked did it wrong, so I always had to learn another way to write a story, how to assign points, and what I had to do to accept or reject a story. Not a big deal once you learn what’s expected.
Now, I’ve been in the internet marketing space for about 10 years now and have had the opportunity to work for many different companies from small start-ups to Fortune 100’s. I’ve had to wear many different hats in this time. Sometimes I was the marketing jack-of-all trades, other times I was the SEO guy, and more recently the consultant/project manager/product manager, slash this or that. Basically, I’ve always been a stakeholder in agile terms. I’ve worked in agile shops, waterfall shops and shops where there is no process. My job success has always been measured by how far I can take the business from points A, B, C and D. It’s vitally important that I get some quick wins starting out to prove my worth and then continue to move the ball or move the needle or get to the next level. Speed and buy-in are always a factor, results are a must, and time is of the essence.
Waterfall versus Agile
Working in a waterfall shop usually meant that I had to spell out all requirements for a typical request, bug, or functionality in great detail. All requirements had to be included and every detail accounted for. I find breaking it down to a very basic level seems to work best here without insulting anyone. Drawing a picture and placing arrows seem to work best to get the point across. Then everything had to go through a vetting process and get signed off multiple times. Waterfall releases were always planned months in advance and pretty much set in stone. This meant that if I started with a company right at the beginning of the new cycle, which always seemed to be the case, then I had months of waiting to get anything done. Even the simplest change took an act of God to make happen, if it were to happen mid-cycle or in the next release. Well, that’s never a good thing as mentioned above and I always knew it was a matter of time before I was gone. Later, I would watch my requests get worked in and the site become successful as a result. This is more of an issue with impatient management and managing expectations on my part than the process itself, but I think it points out the inefficiencies with Waterfall project management.
Fast forward to agile development success. I have to say that I really like agile much better. The reason I like it better is simple: speed. We have more releases which mean I can effect marketing changes and web changes much faster. Sprints can be planned out months in advance as well, but most times they are only planned a release or two ahead. There is also some flexibility in adding additional stories to the queue. So for me, getting a couple stories placed in a sprint or added if the points are available is always a good thing. Marketing things get done faster, numbers come in faster and everyone is happy. More importantly, I get to keep my job. However, agile isn’t without its quirks either.
Joe Woods is one of the top SEO and Internet Marketing Specialists in the Southeast US and has worked with Agile and Scrum since 2007. Joe currently works with Version One and many of the industry’s leading Agile coaches to help IT teams and practitioners evangelize the many different process from Agile, Scrum, XP and Kanban. This is my view of the agile software development process from an outsider’s perspective. Now I’m no agile expert, far from it actually. I was always told that we’re an agile shop or that we use waterfall (cringe). Ok, that’s fair enough. All that meant to me was that we do releases every couple weeks or weekly and I have to go to a bunch of team meetings. I also would have to write these things called stories and they couldn’t be too broad and being too narrow meant I missed some functionality. It always seems to be the case that the last place I worked did it wrong, so I always had to learn another way to write a story, how to assign points, and what I had to do to accept or reject a story. Not a big deal once you learn what’s expected.
Now, I’ve been in the internet marketing space for about 10 years now and have had the opportunity to work for many different companies from small start-ups to Fortune 100’s. I’ve had to wear many different hats in this time. Sometimes I was the marketing jack-of-all trades, other times I was the SEO guy, and more recently the consultant/project manager/product manager, slash this or that. Basically, I’ve always been a stakeholder in agile terms. I’ve worked in agile shops, waterfall shops and shops where there is no process. My job success has always been measured by how far I can take the business from points A, B, C and D. It’s vitally important that I get some quick wins starting out to prove my worth and then continue to move the ball or move the needle or get to the next level. Speed and buy-in are always a factor, results are a must, and time is of the essence.
Waterfall versus Agile
Working in a waterfall shop usually meant that I had to spell out all requirements for a typical request, bug, or functionality in great detail. All requirements had to be included and every detail accounted for. I find breaking it down to a very basic level seems to work best here without insulting anyone. Drawing a picture and placing arrows seem to work best to get the point across. Then everything had to go through a vetting process and get signed off multiple times. Waterfall releases were always planned months in advance and pretty much set in stone. This meant that if I started with a company right at the beginning of the new cycle, which always seemed to be the case, then I had months of waiting to get anything done. Even the simplest change took an act of God to make happen, if it were to happen mid-cycle or in the next release. Well, that’s never a good thing as mentioned above and I always knew it was a matter of time before I was gone. Later, I would watch my requests get worked in and the site become successful as a result. This is more of an issue with impatient management and managing expectations on my part than the process itself, but I think it points out the inefficiencies with Waterfall project management.
Fast forward to agile development success. I have to say that I really like agile much better. The reason I like it better is simple: speed. We have more releases which mean I can effect marketing changes and web changes much faster. Sprints can be planned out months in advance as well, but most times they are only planned a release or two ahead. There is also some flexibility in adding additional stories to the queue. So for me, getting a couple stories placed in a sprint or added if the points are available is always a good thing. Marketing things get done faster, numbers come in faster and everyone is happy. More importantly, I get to keep my job. However, agile isn’t without its quirks either.
2 comments:
interesting blog. It would be great if you can provide more details about it. Thanks you.
SEO Solutions
Interesting post about software development, software development company when going to develop any type of software their team feed up accurate information to get efficient result. All well reputed organizations made effective strategies to prevent from errors and bugs.
Post a Comment