You look at drag and it’s bad and getting worse.

The first thing I’d take a look at for a team in that scenario is, who’s doing live support?

It’s a tricky one, after all, someone has got to do live support but in an attempt to distribute a pretty unpopular job, you’re asking all of your scrum team, at one point or another, to look at live support issues on an ad-hoc basis during their sprint. Whilst you think you’re doing the right thing, you’re not, you’re doing this:

• Introducing context switching for (probably) all of the members of your team (50%+ reduction in productivity)
• Making live support doubly unpopular by now raising its status from “Boring” to “A Boring Distraction”
• Reducing the quality of live support by asking developers to balance it with their scrum commitments
• Providing less-committed team members the perfect excuse at scrum meetings (e.g. “I would have done what I committed to yesterday, but I had to fix that css on live and it was a bit more fiddly than I first thought”)
• Breaking one of the principal rules of Scrum by not protecting the team from change during a sprint (they didn’t commit to do live support and factoring it into drag is just lazy management/resourcing)

The best answer I’ve seen to this was when I worked for Sean Sullivan at BCA. He had two teams of developers/testers, all working on the same product. One, the larger team, were the guys and gals dealing with the current Sprint Backlog and the other, smaller, team was working on live support. Crucially, the members of the live support team were rotated very frequently at sprint boundaries.

We don’t all have the luxury of a large team of developers and testers whom we can switch around at will. In fact, in the startup community, we might only have 2 developers and a part time tester who also does customer support. The principles though, hold absolutely firm no matter how large/small the team.

If you’re two developers sat in some incubator who are constantly trying to balance the needs of live customers with continuous product development, split your team down the middle and fight as hard as you can to make sure that the guy who’s working on the Sprint Backlog is left alone and rotate every sprint.

Of course, in a startup, there are times when this isn’t practical but if you’re trying to increase productivity, even in micro-teams, dealing properly with live support is imperative.

Oh, hang on a minute, I’m not an HR professional, I don’t even like HR professionals so what was I doing there?

Simple really, learning about a great tool that’ll help with recruitment decisions in the future and has changed the way I think about job adverts entirely.

If you look at a selection of ads for technical staff on the likes of CWJobs, you’ll find they read very much like the spec for a PC:

1 x Intel Xeon Quad Core knowledge of the .Net Framework

8GB SQL

160GB ASP.NET (with an 800MB css/ajax cache)

Dual HD eyes

102 key driving licence (UK) and mouse must be included

I’m afraid that ads like this are completely missing the point. When was the last time you found yourself saying “Dave’s a brilliant team-worker, it’s down to his great C# I think” or “Andy’s a good motivatior, he can use the WITH PIVOT function in SQL Server 2005 without even looking on Google”. My guess is, you never have.

When you’re putting together a team, you’re not hiring a collection of skills, you’re hiring a collection of individuals. Each of the team has unique personalities, needs and desires that require fulfilment and unique skills and values that they can bring to the table. If you’re going to get the best out of your people, whatever working practices you adopt, you’re going to have to treat them as individuals and help them gel together as a team. There’s no point in hiring that top drawer architect if he’s going to completely turn the team on it’s head. This doesn’t just apply for new hires either, internally sourced project teams should be put together with the same care and attention. Cherry picking the best techies from your wider talent pool and expecting them to deliver rarely works.

There are some lessons here:

1. Hire for attitudinal fit, train for skills gaps. I’m not saying hire a Luddite plumber as an architect for a .NET project, just don’t write someone off if they don’t tick all your technical boxes. It’s immeasurably more difficult to train to mitigate for ill-fitting personalities than it is to teach a time-served techie to cut some HTML5.
2. When interviewing, don’t allow technical matters to dominate the interview. Most candidates can talk the talk and there are a number of coding tests that will be able to establish whether your candidate can walk the walk (the best of which, as far as I’m concerned, is Codility). A very good alternative, of course, is asking the candidate to write code with pen and paper during the interview, but that’s a bit mean.
3. Use a psychometric tool. Whatever your preference, be it the Thomas PPA,  Belbin, Meyers-Briggs or something else. At a recent seminar at Entrepreneur Country, an industry commentator made the case that talent recruitment/retention exercises were some 75% more likely to be successful by using a psychometric tool in combination with a CV and an interview than simply by the use of a CV an interview alone. His advice on the choice of tool – “you get what you pay for”.
4. Don’t rush recruitment. It doesn’t matter how pressing the need (after all, when we need staff, we always need them “asap“), taking your time will pay off in the long run. Google gives every candidate up to a dozen interviews in different forms. I’m not suggesting we’ve all got the time, patience or resource for that but finding the right balance between that and a quick chat on the mobile whilst you nip out of the office for a cigarette is desirable.
5. When you’re writing job advertisements, don’t just focus on skills. Figure out what you really need from a person first and try and attract the person and the skills. Many of the psychometric offerings will give you a method for doing this, I happen to think that the job profiling tools offered by Thomas are particularly good.

The last lesson I took from the Entrepreneur Country event:

“If you think that hiring the right staff is time consuming and expensive, wait and see what hiring the wrong staff is like”

Probably the biggest responsibility I’ve got is for product development. We’ve got a decent sized team and we’ve got a new starter joining that team whilst I’m off. They’re starting a new, very exciting project and we’ve got to deliver, fast. It’s more important that this team delivers right now than anything else. In previous lives I would have been picking up the phone several times during my break to a temporary project manager I’d have had to put in place and there’s every chance that I’d have had to dish out a fair few complaints to the team for under-performance on my return.

Not this time. We run scrum. I’ve asked one of the team to be scrum master whilst I’m away. I know she’ll do a good job and the team are so motivated and producing such a volume of good quality work, there is very little that can get in their way.

I guess I’ll have to find something else to worry about whilst I’m off…

I’ve had at least a dozen discussions with people who don’t believe that dedicated testers are necessary. Many of them sit in the “the developers should be testing their own work” court. Spolsky says that teams should have dedicated testers so that you don’t have a $100/hour programmers doing work that could be done by $30/hour testers. I don’t agree entirely with either of these positions.

Of course developers should be testing their own work to a point, the first test of which is “does it build?”, but would I expect  a developer to want to build and run dozens of test cases every time they produce some new piece of functionality? No, for a number of reasons:

1. There is a good reason by the QA function in any walk of life is very rarely performed by the person(s) who produced the work in the first place – people are very bad at finding fault in their own work.
2. Developers and testers are different beasts and have a very different focus in life. Devs are naturally impatient, I don’t think I’ve met one who isn’t itching to move on to the next module/product. Devs, once they’ve solved the problem in their mind, written the code and got it working, they’ve done most of the “fun bit” of development. Testers aren’t so restless and their challenge is different. All of the good testers I’ve met have a dogged determination to ensure that the software as a whole is the best it can be, no matter what it takes. These two sets of personality characteristics are not natural bedfellows and the result of this is that a great developer is unlikely to even be able to do the work of a tester, let alone willing.
3. Testers make developers more productive. The more time developers get to occupy that “solving mental problems” space (see 2 above), the more you’ll get out of them. The more confidence that they have that there is a good testing team (or single tester) behind them, the happier they’ll be in that space and the less anxious they’ll be about the code they’ve already produced.
4. Testers make product owners less busy. If anyone in your team needs a clear, full understanding of the big picture, it’s the tester. Invariably, in my experience, it’s the testers that “get it” where quite often the developers don’t (perhaps  because they tend to make the mental  jump straight from User Story (or equivalent) to implementation). The testing team are often the first point of reference for the developers when there’s a choice to make or an ambiguity to iron out.
5. Testers give you confidence come roll-out. Anyone who has ever been up at 3am on a Sunday hitting the “go” button on a deployment doesn’t need me to elaborate here.

As for hiring testers on a purely financial basis (they’re cheaper than developers), again, I don’t agree. Testing is a highly skilled profession. Sure, anyone can “have a go” but great testers are just the same as great developers – worth their weight in gold and rewarded as such.

In our scrum team at KashFlow the testing function isn’t just about test cases and their execution, it’s much more than that. Our testers are a proxy for the voice of our customers. Sure, the customers come up with the product backlog pretty much on their own, but when it comes to implementation it’s our testers who can balance the combined requirements of several thousand customers to achieve the right result for the vast majority.

I’m sure there are loads of other reasons why testers are a good idea, but these are the important ones for me and, sorry Joel, “cheap” isn’t anywhere on my list. Any I’ve missed?

Just like a group of lads in the pub will invariably end up talking about football; get a bunch of CIO/CTOs in the room and they’ll, at some point, get around to talking about outsourcing. As it happened, it was during the first part of the programme, a panel debate. Somebody in the audience asked what members of the panel thought of outsourcing and all of the members of the panel reeled off an interesting, sometimes insightful, list of anecdotes. I will share with you the two that, in my opinion, lacked insight.

The first was Darrell Stein, CIO of Marks & Spencer. His experience was that he found he “had to send a really great project manager over there[sic] to sit on them” in order to achieve a positive outcome. The second was Catherine Doran, Director of Corporate Development at Network Rail. Catherine’s experience was that the cost benefit of outsourcing was substantially reduced by virtue of the fact that the work output of “one of them” is substantially less than you might get from someone “over here”. If you can’t see why this wound me up, stop reading.

Schein (1988) in his work on  Organisational Culture and Leadership, said that we can make an assessment of organisational culture based on a number of things, including the language used in an organisation. Here we have the Leaders of the IT Leaders Forum using language like “sit on them” and “one of them” and I don’t think it too unfair to assert that these “visible products” of culture (by Schein’s definition) infer that there is a generally negative perception of outsourcing in big business.

I can hear you saying “no s**t Sherlock”, and I agree. That there is a negative perception of outsourcing amongst many IT leader is not news. What I did realise is that, despite my question to the panel on the subject, these leaders couldn’t really explain why they think that’s the case. I can.

Whether you have a team of 2 or 200, it doesn’t matter where they are, Birmingham or Bangalore, if you don’t manage them, they will fail. Whatever their location, cultural background, native language or any other variable, the team need to be respected and treated as professionals. As IT managers, we must invest substantially in bringing the team on board and getting up to speed with the processes, products and expectations of the company they are working with/for. This applies equally to an in-sourced or outsourced team. Without doubt, it takes much more management effort to instill the values and beliefs of an organisation in an outsourced team than it does if they are in-sourced but that’s because they are not there to see and feel the artifacts of culture like an in-sourced team are (Schein ibid.).

The mistake that many IT organisations that outsource make is to fall into the trap of believing that an outsourced team doesn’t require as much mangement as a domestic team. One of the great business benefits of outsourcing is that it reduces your people management headaches, surely? In fact the opposite is true. Furthermore, managing an outsourced team when your Leader espouses the cultural values of the purchasing organisation by using language like “sit on them” and “over there”, is going to be a challenge.

When you outsource, it puts your skills as a manager to the test. If you can’t manage a team in your own office, you sure as hell can’t manage a team 5000 miles away who may not even be employed by you. Any decent manager could manage an outsourced team but we’ve go to be aware that it will involve a considerable investment of time, just as much, if not more, than would be involved in on-boarding a team in the domestic office. Approach an outsourced project with that in mind and you won’t go far wrong. Approach an outsourced project expecting that the team will just “get on with it” at your, and your project’s, peril.

P.S. As for another argument I heard at the IT Leaders Forum that went something like “you can’t outsource the ‘clever stuff’ (architecture)” – what drivel. India invented Chess, Dentistry, Fibre Optics, the USB….oh and the binary and decimal number systems (amongst hundreds of other inventions/discoveries). Last time I checked they had clever people in India too, and if you’re a decent manager, you’ll find them.

P.P.S. I enjoyed the IT leaders forum a great deal and, for the most part, was particularly impressed by Darrell Stein. I enjoyed his general approach, inisight and the levity (with a serious subtext) that he brought to the gathering. Not sure they’ll invite me back though…

References:

Schein, E. H. 1988.Organizational Culture and Leadership. San Francisco: Jossey-Bass.

Guess what? Like most things in business and, for that matter, in life…it’s all about the PEOPLE. Put very creative, very intelligent but poorly motivated people into a room with the best tools and materials available and they won’t be able to come up with a prototype for a matchstick together. Put some “average” but well motivated people in a room with no materials and tools, point them in the right direction and they’ll improvise, pull together, accept their environmental limitations and work magic.

I interviewed a “Senior Developer” a couple of months ago who had 3 years .Net web development experience with Citibank or some such similar organisation. Her 3 years of experience had been rebranding a single web form for various co-branded credit card partners. She had a Masters in Software from somewhere or other and had basically used all of her OO design skills to manipulate the same chunk of HTML for 3 years! This isn’t going to inspire motivation in anyone…but why?

Hackman and Oldham (1976) said that the failure of the developer described above to be motivated is directly attributable to the core characteristics of the job . Hackman and Oldham (ibid.) described, in their work on motivation theory, the Job Characteristics model which saw motivation as an outcome of job design with a number of heirarchichal dependencies. They said that in order to achieve motivation at work, the design of your job must help you achieve three Critical Psychological States (Meaningfulness, Responsibility, Knowledge of Results) and in order to do that, your job must have certain core characteristics (Skill Variety, Task Identity, Task Significance, Autonomy, Feedback from Job). It looked a bit like this:

Without too much of a leap in faith, we can map the attributes of the Scrum process to Hackman and Oldham’s (1976) core characteristics. What I’ve presented below is just a starting point, there’s plenty “missing”:

I’m sure you’ll agree, the fit is pretty straight forward.

Scrum works, QED.

References

Hackman, J. R. & Oldham, G. R. (1976). Motivation through the design of work: Test of a theory. Organizational Behavior and Human Performance, 16, 250-279.

The thrust of the argument was “We don’t need you, managers. We’re developers using scrum and can do anything you can do”. The answer to that is, of course, “Yes, you can”.

According to the Scrum Guides you can get from http://www.scrum.org/scrumguides/ your Product Owner and your Scrum Master can both be members of the team (but never the same person). So, leave “the Team” alone and they’ll produce top-drawer results, end of discussion, right? ‘Fraid not.

It all goes back to what Scrum is all about – hyperproductivity/maximising ROI (choose your phrase). I’ve got another article under my hat about how Scrum actually creates that hyperproductivity but, from the perspective of any business, for the sake of efficiency, it’s imperative that the right people are doing the right jobs – jobs that they’re fully equipped for. If you’ve got someone in a role that they don’t possess the right skills/experience for (e.g. a developer filling the BA role as a sideline) then, by definition, you’re spending money training them on the job and they’re making their novice mistakes on your watch. That’s fine, if you’re making a conscious decision to do this*, but don’t be fooled that a productive, self-organising team can rule the world and turn their hand to anything. Developers are good at cutting code, make sure they have the head-space to do so.

Skill matching is not the only thing to consider, there are also some very basic operations management principles at work in a Scrum team too. One of the many ways in which Scrum achieves hyperproductivity is by reducing the time-costs associated with task switching. Developers who are also BAs, the voice of the customer, support guys (& gals) etc on top of their Developer role will waste buckets of time jumping between one thing and another. Besides the wasted time, the developer won’t be able to get so much “done”, thereby reducing his/her sense of achievement/motivation and, it’s a fact, multi-tasking makes you stressed.

There’s another facet to this debate, too. Even though “The Rules” say you can have a Product Owner as part of the Scrum team, I’d strongly advise against it. Why? Imagine the conflict of interest a Product Owner would experience if they were put under pressure (external/commercial) to change the contents of the Sprint Backlog half way through a sprint. Imagine how uncomfortable the Scrum Master would be if the team-based Product Owner started making “I know we shouldn’t really do this…but” sort of noises. The Product Owner in this scenario is probably the business owner too and, in terms of the food chain, almost certainly sits above him. This is exactly the sort of situation you shouldn’t design in to your team if you can possibly avoid it.

A relevant, recent example in my own experience could have played out like this but, for exactly the reasons outlined above, we went with a far-too-techie Product Owner sitting outside the team, picking off Product Backlog items at his leisure, outside the Sprint Capacity timebox. It works pretty well.

The bottom line is, whilst you can stick a square peg in a round hole, it requires some effort and you’ll find there are gaps around the edges.

* I believe strongly that investing in your team in respect of their training is imperative, but only when you can afford it. 

A “good” employer tends to pride themselves on the fact that they deliver hours, sometimes days, of training before a new pin can actually get on with some work. Invariably the Health and Safety Stasi and someone with a week long ”Post-Educational Higher National Secondary Certificated Diploma in HR” get in on the act and the bright, enthusiastic new team member has the will to live sucked out of him/her over a matter of a few days whilst they answer pop-quizzes about correct lifting techniques and the location of fire exits.  

I’m lucky. I work in an entrepreneurial environment and can try things out without the aforementioned Stasi breathing down my neck asking why I was submitting the appraisal forms of my grade 14 staff 3 working days late. I’m also lucky in that I only have to deliver scrum training, which is one of the most straight forward things in the world to do. What makes it particularly easy is that, unless you’re some kind of Scrum fundamentalist, the scrum community does not present Scrum as the panacea for all the ills of waterfall (or chaos – depending on your alternative). Scrum training is not a matter of indoctrination, it’s more of a “well, this is how we choose to do it around here, and it’s not perfect but it suits us” type conversation.  

The manner in which Scrum training is delivered should reflect the themes or the principles of Scrum/Agile itself so I always try to apply the Agile manifesto to the training environment.  

Agile Manifesto

One or two of these we can take verbatim and apply them to the training context very easily but others need a bit of metaphorical treatment:  

• “Individuals and Interactions over Process and tools” can be quite easily applied. Scrum training sessions chez moi are informal affairs and for each one the style of delivery is tailored to the group.
• The principle of “Working software over Comprehensive documentation” too applies well to the training environment. When software works, it does so because the requirements have been correctly reflected in code and the developer’s understanding crystallised. In a training context, if you see someone taking exhaustive notes about what you’re saying, they don’t “get it”. Scrum is not something you can learn by remembering, it sits firmly in the “learning by understanding” camp. If you see somebody you’ve trained at their first scrum referring to notes to see what they should be doing, you’ve done a bad job!
• “Customer collaboration over Contract negotiation” in a training scenario is a curious one. Its application in an employee training scenario is, though, quite simple. As I said earlier in the piece, I never present Scrum as a panacea, merely, “how we do things around here”. Furthermore, I don’t present it as a rigid framework. The trainee(s) must, rightfully, feel that their input in the team does not extend only to the work output, but the method of working itself. So, the new team member can, in his first retrospective, completely change the manner of working if he can achieve the agreement of his team members. Scrum will never be a rigid framework, at least in application.
• “Responding to change over Following a plan” should apply to any training environment, not just for Scrum training. Sure, there’s some knowledge to impart but any decent trainer knows that the best way to impart that knowledge to a group will depend on many factors. If the trainer doesn’t adapt to that, (s)he is lost.

I’ve attached the slide deck that I use to train Scrum. It has come from a mixture of sources, including www.mountaingoatsoftware.com (from which the basic framework was sourced) and a friend and mentor (and exceptional Scrum trainer to boot) Sean Sullivan. The Mountain Goat framework has been significantly enriched by Sean, placing Scrum in a theoretical/academic/evidence-based context. I hope some of you find it of use. I don’t ask for a mention but it’s important, at least to Mountain Goat, that you retain their references.  

Click here to download the slides (Powerpoint 2007 format)

Click here to download the slides (Powerpoint 2003 format) 

I’ll let you all know in another post whether the late training worked, or not but, a parting message:

Train early or train late, make sure you train and if you’re training about agile, train agile!

A side note -   

I don’t like the word “training” as applied to the general knowledge enhancement of humans. We train animals, we educate humans. However, who’s going to Google for “Scrum Education”?

At a glance, these “information radiators” as the Head of Web used to call them, anyone in the office could see how each sprint was going and, scratching the surface a little, they could see which tasks were proving problematic.

This works beautifully in an office based team where everyone could attend scrum on a daily basis and update their hours against each task on the sprint backlog. Where it doesn’t work quite so well is in a distributed team where the team members may be in different offices, homes or even countries. In my current company we’re putting together just such a distributed team and I want to try and make sure we don’t lose the effect that these whiteboards have on the visibility of the progress of the team.

TFS offers a solution and allows developers to update their hours spent/hours remaining against sprint backlog tasks, but it’s all a bit “hidden” for my liking and in order to keep scrum quick, the team need to be able to see the state of the sprint at the end of each scrum without running reports.

When I first saw Google Wave I thought it might offer a solution. Real time application collaboration with data stored in and retrieved from the cloud asynchronously – fantastic. What’s more, Torben Weis had already written Plany, a neat little project management gadget that provided a good framework to get going with.

After a fair bit of tinkering and a lot of learning, out popped Sprintboard, which emulates almost everything that we used to do with whiteboards in my former role. There’s plenty I want to do with it (Product Backlog tba) and I wasn’t going to put it public until it was much further down the line than it is, but that wouldn’t have been very agile of me now, would it.

Take a look, leave your feedback in comments and I’ll get requests put on the backlog. I’m also going to put this in some kind of shared source control (possibly google project hosting) which should help things no end.

You can add the gadget, for the moment, from http://www.devballs.com/wave/table.xml

And now…I’ve done it in Wordpress!