Serious Agile Stuff

And now for the eagerly awaited nerdy bit (thanks Dave C)....

As promised in my previous (and very first) blog, I'm going to talk about the serious agile stuff I do in between the fun stuff. Actually, that's not entirely true because, believe it or not, agile software development can also be fun! No, it's true I tells ya!

Ok, I can see you don't believe me, so let me explain. I recently (2 months ago) started a new role as a QA Developer. “What’s one of those?” I hear you ask. I know, it sounds like an oxymoron (like Military Intelligence or Honest Politician), but that’s because in many cases it usually is. I expect anyone reading this that has a QA or Developer type role thinks so too based on their experiences. So let me explain. QA Developer means I am primarily a software tester who is able to write & debug software, including, but not exclusively, automated testing frameworks. When I worked for Microsoft as a tester, my title was Software Development Engineer in Test (SDET). Leave off the “in Test” and you had a developer (SDE). Get the idea? Basically, I am embedded in the development team, in the trenches, on the front line, whatever your chosen analogy is. I work alongside the developers and crucially, in parallel. Yep! At the same time, not after they have “finished” writing their code and handed it off to a tester (me) a.k.a. “throwing it over the wall”. More on this later.

Now, on to the Agile part. Agile is about software development and nothing else. There is a manifesto and 12 key principles you can read about. But what’s that all about? What does that mean in practice? Essentially it’s about tearing up the old rule book: throwing away those unwieldy tomes know as Specifications, streamlining and automating your Processes and disposing of all that Red Tape. It’s about getting people together to collaborate and to start writing software as soon as possible, to deliver early and often, to learn from what you have done and progressively enhance. Teamwork and collaboration are the name of the game and it focuses on developing software (iteratively), so there are very few different roles in an agile team. Another crucial part is stakeholder or customer involvement.
I will talk about the Scrum flavour of agile for simplicity, as it is the most commonly used. Scrum is a way of bringing an empirical measure of progress to a self-organising agile team. There are no Project Managers within an agile team so most organisations are more comfortable with Scrum as a form of project self-management.

An agile Scrum team is essentially made up of just four types of member:

1.      Software Developer

2.      Software Tester

3.      Product Owner, the customer proxy

4.      Scrum Master, the facilitator

The developers and testers in the team are the Engineers, the “doers”. The Product Owner is the go to person for a timely decision about something the engineers within the team are working on. The Scrum Master is the go to person for something you need doing to enable you to complete your task, usually something that is blocking or significantly slowing you down. Engineers collaborate and work closely together to produce working software. The team works in short bursts called Sprints or Iterations that typically last between 2 and 4 weeks. Working software is delivered at the end of each Sprint.

Simples!

Here endeth the first sermon. More on agile later...