agile

“We’re doing our own flavour of Agile/Scrum”

by Oliver on Tuesday, December 13th, 2016.

I won’t descend into hyperbole and say you should run, shrieking and naked into the dark night, when you hear these words. But, it’s worth pondering what exactly it means. I think I’ve (over)used this phrase myself plenty over the years and right now find myself examining why so many people find themselves needing to invent their own version of well accepted software workflow methodologies.

You might say “we just pick the parts that work for us” or “we continually iterate on our workflow and so it is constantly evolving rather than sticking to static definitions of Agile”, or “we haven’t found estimations useful”. Many teams that have a significant infrastructure component to their work find themselves split between Scrum and Kanban. I always imagine that traditional or strict Scrum works best when you are working on a single application and codebase, with pretty well restricted scope and limited technologies in play. I actually crave working in such an environment, since working in teams with broad missions and wide varieties of technologies can make organising the work extremely difficult. At the same time you don’t want to split a reasonably-sized team of 6-8 people into teams of 1-2 people just to make their mission/vision clear.

Some reasons I think “custom Agile/Scrum” happens:

  • Most or all of the team has never actually worked in a real Waterfall development model, and can’t appreciate the reason for all the Agile/Scrum rituals, processes and ideals. This will continue to happen more and more frequently, and is almost guaranteed if you are dealing with those dreaded Millenials.
  • Estimations are hard, and we’d rather not do them.
  • Backlog grooming is hard, and we don’t want to waste time on it. Meeting fatigue in general kills a lot of the rituals.
  • Unclear accountability on the team. Who does it fall on when we don’t meet our goals? What is the outcome?
  • Too many disparate streams of work to have one clear deliverable at the end of the sprint.
  • Various factors as mentioned in the previous paragraph leading to a hybrid Scrum-Kanban methodology being adopted.
  • The need to use electronic tools e.g. Jira/Trello/Mingle/TargetProcess (have you heard of that one?) etc, rather than old fashioned cards or sticky notes on the wall. Conforming to the constraints of your tool of choice (or lack of choice) inevitably make a lot of the rituals much harder. Aligning processes with other teams (sometimes on other continents) also adds to the friction.

So anyway, why is any of this a problem? Well, let’s consider for a moment what the purpose of these workflow tools and processes is. Or at least, in my opinion (and if you disagree, please let me know and let’s discuss it!):

  • Feedback
  • Learning
  • Improvement

I think these three elements are so important to a team, whether you implement Scrum or Kanban or something else. If you pick and choose from different agile methodologies, you’d better be sure you have all of these elements present. Let me give some examples of where the process fails.

You have a diverse team with a broad mission, and various roles like backend, frontend, QA, design etc. Not everybody is able to work on the same thing so your sprint goals look like five or 10 different topics. At the end of the sprint, maybe 70-80% of them are completed, but that’s ok right? You got the majority done – time to celebrate, demo what you did finish and move what’s left over to the next sprint.

Unfortunately what this does is create a habit of acceptable failure. You become accustomed to never completing all the sprint goals, moving tickets over to the following sprint and not reacting to it. Quarterly goals slip but that’s also acceptable. You take on additional “emergency” work into the sprint without much question as slipping from 70% to 65% isn’t a big difference. You’ve just lost one of your most important feedback mechanisms.

If you had a single concrete goal for the sprint, and held yourself to delivering that thing each sprint, you would instead build up the habit of success being normal. The first sprint where that single goal is not delivered gives you a huge red flag that something went wrong and there is a learning opportunity. What did you fail to consider in this sprint that caused the goal to be missed? Did you take on some emergency work that took longer than expected? It’s also a great opportunity for engineers to improve how they estimate their work and how they prioritise. It also facilitates better discussions around priorities – if you come to me and ask me to complete some “small” task, I will ask you to take on responsibility for the entire sprint goal being missed, and explaining that to the stakeholders. 100% to 0% is a much harder pill to swallow than 85% to 80% – and in the latter case I believe these important conversations just aren’t happening.

But let’s say Scrum really doesn’t work for you. I think that’s totally fine, as long as you own up to this and replace the feedback mechanisms of Scrum with that of something else – but not stay in some undefined grey area in the middle. Two-week (or some alternative time period) sprints may not work well, or you might deliver to production every week, or every three weeks. Something that doesn’t align with the sprint. Now you are in a situation where you are working in sprints/iterations that are just arbitrary time containers for work but aren’t set up to deliver you any valuable feedback. Don’t stay in the grey zone – own up to it and at least move to something else like Kanban.

But if you are using Kanban, do think about what feedback mechanisms you now need. Simply limiting work in progress and considering your workflow a pipeline doesn’t provide much intelligence to you about how well it is functioning. Measuring cycle time of tasks is the feedback loop here that tells you when things are going off the rails. If you get to the point where your cycle time is pretty consistent but you find your backlog is growing more and more out of control, you have scope creep or too much additional work is making its way into your team. Either way there is a potential conversation around priorities and what work is critical to the team’s success to be had. Alternatively if cycle time is all over the place then the team can learn from these poor estimates and improve their thought process around the work. Having neither cycle time nor sprint goal success adequately measured leaves you unable to judge healthy workflow or react to it when it could be improved.

I guess you could also disagree with all of this. I’d still argue that if you are in a business or venture that cares about being successful, you want to know that how you are going about your work actually matters. If it isn’t being done very efficiently, you want to know with reasonable certainty what part of your methodology is letting you down and respond to it. If you can’t put your finger on the problem and concretely say “this is wrong, let’s improve it” then you are not only avoiding potential success, but also missing out on amazing opportunities for learning and the challenge of solving interesting problems!

Tags: , , ,

Tuesday, December 13th, 2016 Tech No Comments

MBTI and pair programming

by Oliver on Friday, March 27th, 2015.

I had a meeting this week where among other things we talked about our teams and team members and how things were doing, generally, in the sense of team health. Oh yeah, since I haven’t explicitly called it out on this blog, for the last 9 months I’ve been an engineering manager and since the beginning of the year took on a second team. So I’ve got two teams of developers to manage currently.

Within the discussion we touched on personalities of team members and how some people are more likely to engage in pair programming, but others generally not. This reminded me of my own habits. I aspire to pair program, but when the opportunity is there I usually avoid it. This isn’t setting a great example to my teams so I feel guilty about this, but in the moment we were discussing the topic I started to reflect on this tendency a little.

Part of the new management training programmes that are being explored at SoundCloud involves a reasonable amount (ok, a LOT) of self-discovery and self-awareness. One form this takes is in doing an MBTI test and getting familiar with your tendencies, preferences and communication styles. I’ve done this test at least twice in the past and nothing had changed this time around, but I’m more familiar now with the implications. I tend to live the factual, data-based world, and without delving too much into my own personal MBTI type, prefer to plan things out and think them through in advance rather than acting spontaneously in the moment, talking out problems and making on the spot decisions.

This really reflects on my hesitation when it comes to pair programming. Innate in the process is talking out problems when the situation is not understood, making on the spot decisions without having much time to reflect internally and rely on internal thought processes (since there’s another person there waiting for you). This directly conflicts with my personal pre-dispositions. No wonder I am not a willing pair programmer! It’s quite likely members of my teams may be the same, and hence taking a universal approach of everyone pair programs may at best lead to poor results and at worst lead to a dysfunctional team full of unhappy members.

I’m sure this is not an original thought (in general) but it was a useful realisation for me. I think that taking into account different personality types and different personal motivators for your team member, and using this when it comes to planning how to work and what to work on, can be one potentially powerful tool in building a strong and happy team.

Tags: , ,

Friday, March 27th, 2015 Tech, Thoughts No Comments

On Pair Programming

by Oliver on Thursday, June 13th, 2013.

It has been a while since my last blog post; certainly not because I wanted to write less but I’ve just been trying to learn so damn much recently it hasn’t left much time for anything else. Whether or not I’ve actually learned anything is yet to be seen. This leads me to a subject which I am still struggling with – Pair Programming.

Not that I don’t “get it”, “understand it”, or “enjoy it” – I hope that I have attained all three of these – but due to my situation with software development it can be a bit of a struggle. What is this situation? Well, let me briefly explain.

My background, ultimately, is in Computer Science. I have a Bachelor’s Degree in it, and did study several years of programming in various languages and contexts. However my career up until the last couple of years has been decidedly in the Systems Administration realm. I enjoyed this immensely, and while my programming skills grew rusty I eventually grew to envy some of my colleagues whose abilities far exceeded my own in tailoring their own solutions to problems while I had to reuse whatever OSS fit the bill.

While at Nokia I was fortunate to get a lot of time to myself to implement some next generation configuration management solutions, and found myself hacking away at Ruby for quite some time. Enough, I guess, at least to make it possible to start my current job at SoundCloud as a Software Developer again. The environment is extremely challenging in that we have a lot of very interesting problems to solve, and many very talented developers working around you on these problems.

My team in particular seems to have tasks which span a number of systems, and we are aiming very much to approach our work end-to-end rather than just focussing on the back-end or front-end systems. The current situation is that I am most comfortable in Ruby (but don’t particularly like it anymore), working up my experience in Go, learning Javascript and ActionScript, and reacquainting myself with C and Python (ok, these last two aren’t used a lot). The codebases we work on are frequently not “owned” by us (which fortunately doesn’t really matter), and we often have to switch between several different systems and languages to solve the one end-to-end problem.

That was a rather long introduction. What’s the point? I find when I attack a problem, aside from the initial paralysis of indecision due to not knowing how to get started, I also can spend a good hour or two just acquainting myself with the codebase and finding my way around it. Where the hell do I make the change I want to make? How do I do it? How can I most quickly learn the conventions of this codebase? All of these questions have answers, but if I were to pair on the task from the beginning, it would also involve someone looking over my shoulder (or I over theirs) for a couple of hours while my brain just starts to fire. It doesn’t feel very productive for one, let alone two people.

The end result unfortunately is that after I’ve acquainted myself with the codebase, I probably won’t end up pairing with someone else to complete the work. I’ve figured out the problem, prototyped it until it worked, and then tidied up enough to call the problem “solved”. Maybe I’ve even added tests! Where in this process was I supposed to have started pairing? I genuinely do enjoy it, but when I’m faced with the prospect of wasting another co-worker’s time and exposing my ineptitude it doesn’t feel as enticing. I’m anything but a coding Ninja or Rockstar, and often it feels like that’s all I’m surrounded by.

If you are in a similar position, how do you deal with this? If you have any suggestions or comments on the subject I would love to read it and discuss further.

Tags: , ,

Thursday, June 13th, 2013 Tech 5 Comments