When Scrum/Agile/XP works your own way

Recently, I’ve been working on a project that is rebuilding approximately 18 websites with a new theme, latest CMS software (Sitecore 7.2), MVC and other fancy front-end things (AngularJS, latest jQuery, Bootstrap, font-awesome, and a bunch of other “vendor” packages). What I have noticed is that although we are using some aspects of Scrum or Agile or whatever it is called these days (it’s just a revision of eXtreme Programming right - but people aren’t called “programmers” any more for some reason), there are many things that you need to see if they work for you.

We all know that pure -insert-methodology-here- isn’t going to work for anyone. But aspects of said methodology could work.

The most interesting aspect of the project is that we are seen as being the “cowboys” (well, Cowboy Dan from Parenthood is our mascot because of this) in our software development/delivery arm of our IT department. Despite this, we’re the only project that is not only tracking on-time and on-budget, but is also delivering to expectations without escalations or much fuss.

The project is simply just working, under our “standard” methodology, whatever you wish to call it. Sometimes it feels like we make things up as we go along, and I think sometimes we do. But we always review what we do and either keep it, change it or ditch it. It’s probably worth mentioning the role I am playing is a tech lead, but really I like the scrum idea of having 3 roles only: product owner, scrum master and EVERYone else.

So this is the story of what happens when you don’t get approvals. You don’t pass all commercials before commencing. You don’t complete key project framework deliverables status reports or financials, and just basically go for the target with every effort. Take off every zig, as it were.

Here is a list of what is working for us and what’s different from a “regular” IT project (which usually costs a lot, runs late, hits issues constantly and generally annoys the hell out of the customer) in our organisation:

Nick’s Tips

• The project was kicked off with a visit (in a mini bus) to 3 locations to see how the business actually operates and what pain points we need to solve in the new sites for the content authors
• All team members were hand-picked by the scrum master / tech lead
• The product owner is a direct representative, stolen from her day job in marketing, to work with us on site and sitting next to the project team 4 days per week. (5 days would be better but day jobs must be done sometimes!)
• The product owner is taken through the journey of discussing how difficult certain features are and estimations
• The entire project team is co-located in the one office. One bank of desks.
• The product owner has adopted OUR techie tools (TFS 2013) and is using it to track the backlog, priorities, business value and acceptance criteria
• Latest versions of all software packages have been used including MVC 5.2, which makes every developer warm and fuzzy
• The front-end developer is sourced from the same creative agency that is providing the visual design, and both people work on site with us
• The testers are working a sprint ahead of the developers to ensure test cases are written before the development is complete
• The visual designer is working a sprint ahead of everyone
• There is as ratio of 2:1 developers to testers
• We are using tools like Invision for communicating the visual design as well as feedback and comments
• We have banned email and are using Yammer in it’s place, so the whole team can read discussions and things aren’t lost in inbox hell
• The project manager is the scrum master and runs stand-ups, retros and sprint planning, leaving the tech lead to be technical
• Next one is a bit more CMS-related, but there is a strong focus on the content authors experience at the expense of a technically “perfect” solution
• We hold a weekly PR campaign with other teams on the same platform including support teams to showcase what we’ve done in the past week
• Showcases are performed every sprint showing the latest solution, working or not, to all team members
• We post up as much as we can on the physical walls around us: designs, solutions, photos, diagrams, Cowboy Dan, you name it
• 95% of annoying bugs and device-specific issues will be front-end, so prepare to mix the team up or get additional resources to get over humps
• We play music during work
• Bugs aren’t fixed until stabilisation, helping developers stay focused on delivering features
• Team members can pick up tasks they wouldn’t normally do (ignore rules of role) such as testers writing acceptance criteria, tech leads developing or project managers being scrum masters

Back to the project

So where is the project up to now? Well we’ve finished 2 initiation sprints, 4 feature development sprints and we are now going through the first of 2 stabilisation sprints. We then have 1 remaining sprint to finish off the remaining work. It’s coming to the pointy end now but so far things have been working very well.

Expect an update from me in about one month’s time talking about if everything above did actually work or if the whole thing crashed into a stinking pile.

Let’s hope for the former!

Comments (0)