An Outsiders View of Agile Software Development - Part One

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.

IdeaPaint– A new dimension to Agile Workspace

Big Visible Charts, and collaborative environment are the distinct characters of Agile workspaces. Many researches have clearly indicated that visibility of information, posture of people and flexibility are the critical elements to enhance creativity. If you are interested to know more about how to improve creativity through a proper design of workspace, read the article here.

In my world, here is how we have used some tools in the past, and at the end, I have made an attempt to predict the future.

Past and present
Depicting/Sharing ideas has evolved over years.

1. We started with the black boards	2. Before moving to Flipcharts
3. To avoid marks on the walls, people paste the Post-Its on A3 sized sheets	4.Many teams use Glass walls to sketch thoughts
5. Cling on sheets was one of the effective ways to move notes from one room to another without scratching walls

The future

Nowadays,  many new organizations  have started making use of this innovative technology called “IdeaPaint”. 

According IdeaPaint’s website:



Titled IdeaPaint, it is available for half the price of an actual whiteboard and works just as well or better, leaving no marks behind when you wash down your work (and, without the rest of the infrastructure, it turns out to be greener, too).

Imagine the ability to write ideas, thoughts, designs and release plan on the white walls without getting worried about the office admin.

 

If you are a truly Agile enterprise, it is high time to move towards IdeaPaints. I am convinced that, IdeaPaint is going to revolutionize the way people collaboratively work.

Here are few sample pictures of how people use IdeaPaint.

Watermelon Agile

We have heard about ScrumBut and Water Scrum Fall. On similar lines, I thought I would coin another term “Watermelon Agile”.

As we know, watermelon has green outside, and red inside. Similarly, the “Watermelon Agile” projects too show a greenness of Agile outside, however, they would still be “red” inside stuck with Waterfallish mentality.


Some of the Watermelon Agile practices include:

1. They will do Daily Stand ups,   but  team members are forced to do it.  It won’t stop there, blockers are screened before it goes to the blocker wall.

2. They will set up beautiful Kanban walls, but only to satisfy Agile coach or the management, who treat setting up Kanban walls means “Agile”.

3. The Scrum Master still drives the project in command and control mode. Some examples include, asking the team members to report to work at a certain time, micro-managing the team, cultivating blame-game culture within the team.

4. They will still do retrospectives, but team members have fear to expose anything negative about the project.

5. Team members are punished for doing any mistakes. This behaviour automatically pushes the team not to try new things, and in turn the project ends up with no innovation.

Do you know of any other Watermelon Agile practices ?