Go scrum yourself

<RANT>

It looks like I'm out of a job. And it turns out that everybody who thinks they're doing agile right, is not. Who came up with this dogma? And if agile is so bloody hard to get right, then why is it apparently the ducks nuts of software development? So many questions, but let's start at the top.

I stand before the agile bandwagon and everybody is jumping on board. Just when you think you've perfected the project lifecycle, apparently it's time to throw your old workflow in the bin. Apparently it was called 'waterfall' and it doesn't work. Unfortunately, I'm not a big fan of change, and for the record, change also hates me. So I tend to question everything, drag the chain and eventually be dragged kicking and screaming into new work practices and processes. Hardly agile! Well, for me the jury is still out but here are my initial thoughts.

The new world order

"Scrum Master"? It sounds like a fancy name for the bloke who referees a jelly-wrestling match. As the entire office sat around watching a video on Scrum 101, the first question that popped into my head, was where do I fit in this new world order? And initially, it seemed that the Producer (or project manager) would be the obvious fit for Scrum Master role.

Oops, apparently not. Hit Google, and it quickly becomes evident that a scrum master is not a project manager by another name. Agile breaks all the rules associated with traditional project management, which kind of leaves the Producer twiddling their thumbs a bit, and somewhat pondering redundancy. According to the Scrum Alliance - a non-profit advocacy group for everything scrumptious - Project Managers are not needed at all. This is because the duties undertaken by the former PM are split between the Scrum Master and another role, the Product Owner (which I'll get to in a moment).

There is no need for a project manager to undertake staff monitoring or task assignment. The scrum team decides what and how to work on tasks from the product backlog, and organises itself. There is no budget management because in theory, a budget in the traditional sense doesn't exist. You just build something, test it, build it out a bit more, test again, and then keep building and testing, repeat, repeat and repeat forever because development (hence testing) of the product never really ends. (Budget that!)

Additionally, scope management is turned on its head, because in agile you are supposed to welcome changing requirements, even late in development! Coming from a traditional project development lifecycle background, that's a hard pill to swallow, but I found a really good article that explains it well. It comes down to the fact that while you know what purpose you are building an applicaiton for, you don't know all the requirements from the start because you are always testing and learning. One good quote from the scrum video was along the lines of "you are never more ignorant of what you are building than you are at the start of the project".

One of the key differences between agile and the traditional project lifecycle is the elimination of the requirements definition document, in favour of 'user stories' which drive the development team to meet the desired outcomes for identified scenarios. The requirements of the application simply become whatever design and development work is needed for each 'user' to successfully complete the task in each individual story. The flexibility of agile allows this, where old methodologies did not, requiring the identification of all requirements without testing, and often without even the creation of personas to apply stories to. This meant no repetitive testing cycles, and is now recognised as an expensive way to build an application since you haven't tested until you've completed all the work. And it's almost guaranteed you won't get it right the first time.

Hence the minute details of comparing the scope document to the development tasks, is virtually eliminated. This is a good thing in terms of reducing the management workload. It does not mean that agile is completely agnostic to scope creep. It can happen but generally it's limited to situations where the client has radically changed the goal posts. For example, you have built them a motorbike, but now they want you to turn it into a car.

All Wiliam Producers need to be sacked immediately and re-apply for their jobs

I digress. The point of all this is that when it comes down to it, in a perfect agile utopia, there is basically nothing for a project manager to do. All Wiliam Producers need to be sacked immediately and re-apply for their jobs under the guise of agile! There is no need to monitor staff or the prioritisation of work, no budget to manage in the traditional sense, and no need for annoying project plans and gantt charts, since the scheduling is conducted in regular weekly sprints. You don't need a PM to liaise with the client, champion the product or assure project success, as this is the job of the Product Owner.

Which brings me to the second little epiphany that I had: the client would be the ideal choice for the "Product Owner". Oops, wrong again! Turns out that this role is nearly a full time job (so they say) and your client already has one of those. There are some in the scrum world who will argue the now unloved 'Producer' - who has found themselves on the outer in this new world order - could be more suited to shifting into the role of Product Owner, rather than sideways into Scrum Master. This is due to their probable experience in prioritisation, versioning, ticket management and working with product backlogs (think JIRA), as well as having good communication skills when it comes to liaising with clients and other stakeholders.

One thing that is universally agreed upon by agile evangelists, is that all members of the scrum team should come from within the organisation responsible for development of the application (i.e. the web agency). It is possible that the client wants to appoint somebody from their side - to the position of Product Owner - which isn't recommended. This is despite the fact that the product owner is typically described as a project's key stakeholder. Traditionally one would argue that this is the client (or the bloke coughing up the money) is the key stakeholder and it's easy to see why you would think to include somebody from the client side on the scrum team. But ultimately, you need somebody who is experienced at this process, and that person is going to come from the agency side which has the experience in building out successful applications, using the scrum methodology. It might be a hard arguement to win over your client, but then, when was the last time you saw a client invited to participate as a member of any development team? And when this happened (if it ever did), was it anything but a road-block to getting things done??

Back to Earth

The reality of the situation is, of course that any organisation that has a desire to make the transition from waterfall (or other) to agile... is going to have a period of disruption and it's not something that can happen overnight. There is an arguement that even if you are willing to embrace agile/scrum, that you may still find that it's not the right methodology for ALL projects. Some clients are bigger than others. I have a strong suspicion that for start-ups and clients who require significant discovery, market research and testing - scrum would work very well. On the other end, multi-nationals or larger corporations would probably be slower to embrace scrum, or find it as effective. Unless you are willing to really challenge existing ideas and re-design applications already in production - literally start from scratch - then this could be more frustrating than beneficial. Sometimes you just need to build software to specification, and you don't have a choice in the matter. Take the money and get it done!

As far as I'm aware, there are no plans to sack my entire team and hire a bunch of SM's and PO's (phew!) Therefore, we're going to have to implement agile to the best of our ability. And that means that despite advice to the contrary, it is going to be the Producer for each client, that ends up team leader for each scrum team. And that by default makes us some kind of quasi "Scrum Owner". Immediately, all the evangelists around the world unite to lump us into the same bucket as everyone else who is 'not doing it right'. And to be frank, I really don't care at this point. I'm not some fanatic that thinks there is only one brilliant way to achieve project success, and that agile is perfect as long as it's applied perfectly.

Time - allowing for trial and error - will tell whether or not we can make this work in some kind of hybrid fashion. And I have a strong suspicion that any Producer / Project Manager who is worth their salt, will also be able to make a good Scrum Master or Product Owner. I have faith in the Wiliam team.

An epic misunderstanding

Do you know why I hate Starbucks? It's because the only things I know about coffee, is that it smells great, tastes like goats pee and if you order a mocha, that means they've tried to make it taste better by adding chocolate, but failed. So when I go into Starbucks I feel like I've fallen into a strange abyss where nothing is normal and rules of English don't apply. Coffee is challenging enough with all the various ways you can serve it up these days, so I don't need to feel belittled further because Starbucks have invented their own language. You walk in to find they have trademarked new words (what the hell is a Frappucino™?) and then stand behind the most pretentious twat while they order a 'quad grand, non-fat 10 pump upside-down, wet (?) decaf dolce soy Macchiato at 74 degrees celsius with 2 percent foam, no whip and sugar-free caramel drizzle'. Yep.

A few years back I had the misfortune of having to rescue the website of a non-profit (always the lucrative client, with all their money). The site was built on top of a Drupal CMS, and unfortunately the thing was ruined beyond help. But what didn't help was that the fine folk behind Drupal had done the IT equivalent of Starbucks. Part of the reason behind Drupal's steep learning curve - compared to similar products such as Joomla or WordPress - is that you need to frustratingly re-learn, even though there's no real point to it. Think you know what a page is? Sorry, you don't. Because a page is actually a 'region' containing a mess of blocks which contain pages (huh?) and probably also nodes and views. How about we also chuck out categories and call it 'taxonomy' instead (feels like I'm stuffing animals). Then we can create a vocabulary to group them. See what I did there? I confused you. That's what it's like trying to figure out Drupal.

I can only see similarities here between Starbucks, Drupal and now agile. As far as I'm concerned, epic is an adjective used to describe grand scale, a story is what you read your kids at bedtime, and a scrum belongs in a game of rugby league. Don't get me started again on 'scrum master'. While I'm at it, 'lean kit kan ban' sounds like the mispelt name of some skimpy French cabaret show.

I have no idea why we need to bastardise our perfectly good English language. I doubt that I'm about to start referring to tasks as 'epics' any time soon, and I don't expect to be called anything other than my first name, so these new titles and things... I'm not sold.

The daily grind

Some of these new agile rules seem to have come into existence without somebody giving any thought to real world practicalities. Top on my hit list is the idea of these morning 'scrum team' meetings, which we are now encouraged to hold for up to 15min each morning, in order to plan out the day and resolve any blockers or issues and update everybody on progress. I'm all for increased collaboration - even before we actively chased the idea of being more agile, we've trended to being more collaborative on recent projects - and the projects have anecdotally (so far) run smoother, faster and resulted in better end products for our clients. Hence gathering the whole project team at the start of each day (UX, designers, slicers, developers, producers, anyone else we need...) seems like a clever and natural thing to do, in order to ensure we continue to collaborate well.

However, they are a fantastic idea assuming the project team exists for a single purpose only. In an office like Wiliam, that reality is far from fact. Producers generally handle dozens of clients with numerous active projects at any one time. Billable resources also, can regularly flit from job to job. The UX department might be in full swing with one particular project, but the design and development teams are still knee deep in previous projects and could be weeks or months away from properly contributing to a project in its infancy. It's a nice idea to bring them in early, and at the right times I think you can definitely benefit - such as early intervention from a technical perspective, severely reducing risk. I'm personally not yet convinced that we need every resource at every daily meeting.

The reality is, it is simply not feasible to have every resource attend every daily meeting. Take a step back for a moment. I get to work and the first thing I'm thinking about is whether to put peanut butter or jam on my toast. Or I'm toweling off after a cycle into the office. Or I've got a hangover and I just can't bring myself to summon the team together. I finally get into my projet headspace, and find that because we have numerous projects happening at once, I can't have my meeting at 9am because there are five other producers all with the same idea. In fact just yesterday, I asked someone how they were progressing on a new project, and turns out they'd been in meetings all morning and hadn't done more than 30min of billable work before 11:30am. Oh dear. That's a lot of meetings and not a lot of progress. Good thing we're all on the same page though, right?

Wrestling the bill

Who pays for scrum? How do you convince a client that they can afford an agile development process, or decide on a budget, when it the development is undertaken with no fixed number of iterations in mind, with an open scope?

If agile is purely being adopted as an internal development process in your agency (which doesn't involve the client) then the chances are any pricing negotiation isn't really going to be an issue. The job has been sold on a fixed cost basis, upfront with billable milestones, and there is a high-level brief of what needs to be achieved. I.e we are building a booking engine for a transport company which takes online payments and interfaces with the client's mainframe. We know the basics enough to cost out the project, and the agile process can be used to build out the interface to meet the brief.

On the other hand, if you have a client who has already bought into the agile methodolgy, perhaps there is a way to work out an approximate scope of work, but charge on an hourly basis. To make this work, there is likely going to have to be a significant amount of trust between the agency and the client, but it does mean that you are covered for any time spent on the project.

When you're so used to having requirements documented up front, it becomes a little scary to be faced with a development process which is open-ended, yet still needs to be delivered to a specific budget and timeframe. Ultimately, I suspect that as long as everybody on the project team is made aware of any budget restraints or fix-cost agreements, then the group can work to ensure that these targets are met. Working backwards, you can probably figure out, if you have a budget of say, $100,000 and each development sprint (between 1-2 weeks) costs around $20,000, then that means you have enough room to produce five iterations of the product, and could potentially get improvements to market several times during that period.

Conclusion

Wiliam are investing serious time and energy into discovering and implementing agile workflows. We especially like the scrum idea, and recently, even if we didn't realise we were, we've been gradually venturing down the agile path by implementing better workplace practices such as increased collaboration, more frequent team communication and a desire to explore new ideas such as lean UX, kan-ban boards, more regular testing and the idea of getting MVP (minimal/most viable product) to market earlier. All these things are traits of agile and we are doing them better than ever before.

We will definitely see more agile project management at Wiliam, but whether it's 100% 'strict' agile, or some hybrid that suits our business or clients or our expertise, time will tell. One thing is for sure, I'm not about to say we've been doing it wrong all these years, just because agile has only come across our desks relatively recently. To all those people out there following the agile dogma, what was your excuse when your project failed? It still happens all the time for a variety of reasons. Agile is not a guaranteed road to success, it's just a different approach that may suit you better than other methodologies.

If Wiliam isn't doing it right then why do we keep making brilliant websites?

And if we've been doing agile wrong all these years, then how come we've got such a fantastic track record of project success? I'd like to think that Wiliam's exploration of agile will be an exciting time, and we will apply the principles of agile as best we can to further improve our rate of success, and to improve some parts of the workflows we currently have in place.

Jut don't change my job title to Scrum Master* just yet. There's still life in this old Producer!

 

_{(* Though I may consider Scrum Overlord)}

 

</RANT>