Starting a new project? A new product? Have a team transitioning to “Agile” (aka Scrum) and wanting to get ready?
Why not try a Sprint Zero? – Why not indeed.
Sprint Zero is a way to get everything ready to start work, to buy the tools you need, set up your databases, perhaps do some architecture review, tell the rest of the organization about what you are doing, maybe write some requirements, get some additional training, etc. etc.
Sprint Zero doesn’t need to happen in a time box, you can take all the time you need, after all, you haven’t become “agile” yet, Sprint Zero will make you Agile.
Sprint Zero is a get-out-of-jail-free card that pushes really change down the road a little bit further.
The truth is: there is work to do.
Just start “sprinting”. Schedule an iteration to start tomorrow and get going. Do what you plan for the next week, then review and plan again.
Doing anything else delays the change and potentially reduces motivation.
If you want to call your first iteration Zero then fine; you can call it Zero, or One, or Two, or 57 or even -1 if you want, I don’t care. Give it a number and make sure the next iteration adds one to that number.
All those things I just listed – and more – that you need to do to “get started” are themselves work that needs doing. Why not write them on a card and schedule them like you would any other piece of work in an iteration?
If you haven’t worked out what those things are then No problem, try and schedule some real work. When you find you don’t have something (a database instance for example) simply write out a card, schedule it, do it. The things you need to do to “get ready” are actually things you need to do to build something you do want.
My big worry with Sprint Zero (apart from it injecting unnecessary delay and loss of change momentum) is that it makes work. You may think you need to do something in advance and you might be right. But, then again, you might be wrong. You might do something – like install a database – when you could quite easily postpone that work for a few weeks or even skip it entirely.
Similarly some say “How can we start work until we know what we need to do? – we need to gather requirements, write some stories….”
But again: determining what needs doing, requirements gathering, is itself work to be done.
If it is not clear what needs to be done on day-1 then the first thing to do is to do some work to find out what needs to be done. The initial work may well be requirements discover and story writing with only a little bit of product building.
Speculative, early, requirements gathering, may actually increase the amount of work to do because you capture all the things people think you need to do. Once you start to put the product together you may not need those things but once they are listed as part of the work to do – and especially if they have been promised to someone – then not doing them can be problematic.
Anyway, having written this blog I now wonder if I should have bothered. Now I look about a lot of other people have made similar points already. As I have been writing this post I thought I should find a definition of Sprint Zero, so I did a search. Interestingly, most of the articles that came up on page 1 of Google are also critical of Sprint Zero for similar reasons to myself. So maybe Sprint Zero is an idea whose time has already come and gone.
Si: Welcome Peter, thank you for taking the time to attend this annual performance review
Peter: As long as you know I don’t want to be here, performance reviews are pointless, I told that to my manager Roger. I should be at my desk coding.
Si: Yes, I understand your position, in fact many of us sympathise with it, including Roger and myself
Peter: Well, good, does he also agree that management is a waste of time? If we were really following Agile the way we should then Roger wouldn’t be getting in the way all the time and I could write more code.
Si: Yes, well, we’ve had that feedback from other people and the company is committed to change. In fact, one of the things I wanted to speak to you about today was to tell you Roger is stepping aside.
Si: Yes, Roger is undertaking retraining and will become a Product Specialist, he himself rejected the title Product Manager because he doesn’t see the need for Managers and even refused the title Product Owner because he doesn’t feel he can “own” something that is a community effort and is ultimately owned by the company shareholders.
Peter: Wow… he has been listening to me?
Si: Yes, in my long conversations with him he has spoken many times of the points you have been making. Of course as part of the management team it wouldn’t have been right for him to speak about his changing views too publicly lest people wonder what was happening.
One of the things I wanted to discuss with you today was how we go about distributing Roger’s other responsibilities. As one the longest serving employees Roger suggested you would have the best insights.
Peter: Right, erh, so what responsibilities are these? – apart from asking me “how long will it take?”
Si: Well some relate to the product. As Product Specialist he will continue to support sales staff making customer visits, he will continue administer the backlog, prioritise work in the planning meeting and draw-up the product roadmap – although he wants to involve more people and change the concept of a roadmap. He plans to increase the number of customer visits, competitor analysis and market scanning activities he has been doing already.
Peter: Good, we need a proper product owner, he was doing the role anyway but didn’t have enough time.
Si: Well yes, in fact he has also requested that you and the other engineers accompany him on customer visits in future.
Peter: What? – but our customers are everywhere but here!!! Saudi Arabia, Finland, Argentina, USA… it takes days to get to those places, I’m needed here, I need to be coding!
Si: Well I’ll let the two of you come to a decision on that. Right now we need to redistribute Roger’s work.
There are the administration matters, signing off holiday, arranging sabbaticals, maternity/paternity leave; the new monthly check-points replacing annual performance reviews need to be staffed. There is a lot of work around contractors, time-sheets, extensions and terminations, to be honest there are constant political battles over the number of contractors and whether we should be using them at all. Personally, I believe these changes will abolish office politics but some people think I’m being naive.
Anyway, a lot of this work could be for someone like myself in HR…
Peter: But that will slow everything down! HR is never responsive and most of them – unlike yourself – don’t know one end of a code stack from another
Si: Yes, quite right, HR is atrociously understaffed so we take forever to do anything, and many of my colleagues just aren’t close enough to the teams – frankly they don’t understand technology.
For those reasons the company is also closing the HR department. The work will be distributed to the teams. So my colleagues and I are all being made redundant. Some larger teams, such as yours, will be allowed to hire “Talent specialists” to help with recruitment matters and I hope to secure a such a job myself. But that also means members of your team will need to interview and select their own Talent Specialist. I expect you’ll be on the interview panel, I hope you will see the depth of my experience.
Peter: O, but we are all so busy coding, that will slow us down! And we don’t know anything about recruiting HR people. Can’t Roger arrange that before he leaves?
Si: Roger’s re-assignment is immediate, he insisted on it. I suggest you and your colleagues get started on selecting your Talent Specialist as quickly as possible.
Still, many of the things I just listed will not fall under the Talent Specialists remit. A self-managing team really should manage a lot of those things itself. The Talent Specialist will be there for staffing issues, CV filtering, negotiating with recruitment agents, diversity monitoring, visa applications, university recruitment fairs, exit interviews, legal issues, and so on.
Peter: Right, well I’m sure out team can dispense with a lot of the administration, we can trust one another to take holiday responsibly.
Si: Quite so, I’m sure you can organise away a lot of the admin work but there will be a rump.
Peter: Could we bring back the Scrum Masters?
Si: Well the Scrum Masters we had were always at pains to point out they were not managers or administrators – I know they are in some other places. Plus, they said they “did themselves out of a job” in the end and recommended their own removal.
Peter: Arh… I remember, I guess we will share the administration around the team. We can work out a process for that – the same as we do in planning meetings.
Si: Remember as you do that some of your team may need management training
Si: Management, even administration, has its own on standards, rules, jargon, if members of your team are going to do administration and management work, let alone talk to others doing it then they need to know their CapEx from their OpEx, their 4 Ps from their 5 Forces, front-of-house from back-of-house, what you can and can’t say in an exit interview, a SWOT analysis from a …
Peter: Yes, yes I get it, a lot of mumbo jumbo if you ask me…
Si: All the same, is it fair to throw people in at the deep-end? Shouldn’t we help them learn if they want to?
Moving on next we come to Roger’s role in the hierarchy. Sharing company information down to the team and team information up the chain. Plus annual strategy meetings, quarterly reviews, product portfolio boards, key customer engagement.
Peter: We have Slack and Wiki’s so I’m sure we can manage the information alright.
Si: Arh… well, when we rolled this program out in Norway some of the teams tried just that. In a couple of months most of the team members were complaining about information overload. I believe the quote was “How can you expect me to do any coding when Slack keeps interrupting me?”
Si: And the Norwegian executives felt they never got a consistent message from the teams because different people would turn up to quarterly reviews each time while strategy sessions started to resemble a Stackover flow argument. Some customers complained that they no longer had a point of contact or got conflicting messages. And lets not even talk about the auditors.
Peter: Well the thing is, none of us have been trained in Strategy or, what did you call it? Portfolio review?
Si: Good thinking, I guess one of Roger’s strengths was the time he spent studying that on his American MBA. Do you want to arrange a coupe of days training in strategy and portfolio review for your team?
Peter: Erh, I’m not sure I know enough to book a training course, and isn’t that going to take people away from coding?
I mean the whole team, all 10 of us, out for 2 days training? And the people going to attend meetings with other departments and teams?
Si: Yes of course it is, but you will be self-managing. The team won’t have anyone else.
And mentioning the team, there is also another issue you’ve raised yourself in the past. Here we are, two very similar males discussing this. In fact your whole team is quite like the two of us. The team are going to have to challenge themselves to improve their diversity.
Look, we’ve been here half-an-hour and haven’t started even reviewing my performance, will this take much longer? I’ve got code to write.
Si: Well, there is quite a bit more of Roger’s work to discuss, plus his boss, Jane, is also stepping aside so we need to reconvene with people from the other teams to allocate her remaining work.
Peter: If we are self-managing, could we decide to employ a specialist to pick up a lot of this work?
Si: I expect you could, you’d need to put some costings together.
Peter: Right, I’ll talk it through with the team and see if we can hire a secretary.
Si: Good idea, although the secretary is going to need more than just typing skills.
Peter: Sure, secretary might be the wrong job title. We need someone with skills who we can trust to make these decisions, someone with experience.
Si: Although, you know, such a person may become a bit of a gate-keeper to the team
Peter: Certainly, thats what we need, we don’t want interruptions!
Si: Well, the problem with a gate keeper is that they decide what goes through the gate and what does not. That gives them a degree of power.
And if someone is picking up all the left over work, making decisions for the team, and controlling access to the team, and information flows into and out of the team…
Peter: Yes, is there a problem? That all sounds good to me, this gate keeper will have the power to defend the team
Si: Well… what I was about to say is such a person might be seen by some as having authority… and how will the team members feel about someone else deciding what is told to others?
Peter: Well, we could review their decisions and tell them what to do
Si: Yes… well, that might be seen as a lacking trust or even micro-manegement…
So you think you want to contract out some development work? – yes, you know this area is full of banana skins to slip on, and you know others have problems but you still want to do it.
And you want to contract it out to an “Agile” development shop?
There are no laws against opening a development shop – a digital agency, an outsourcer, a consultancy, call it what you like. That is the beauty of capitalism, it allows pluralism. The hard part is choosing one that is competent, some outsourcers are pretty awful.
Everyone who can spell “Agile” can claim to be Agile, and most hire a copywriter to give them an online spin so they all end up making the same claims.
Those who are half good can coach their staff in what to say. And in truth, most of them genuinely want to do the best possible job for you – and be agile too. But how can you really tell?
Well… when I’m being cynical I think you can’t. The only way to really tell is to give them some work and see what happens. Of course once you’ve engaged someone you need to be both legally and mentally prepared to walk away.
So to help you here are some warning signs that you have stepped on a banana skin and your supplier isn’t as good as you – and they – want to be. You might even say these are warning signs that they aren’t really Agile.
1) Customer involvement
They don’t want customer involvement. They don’t want your people on site. They claim that your people get in the way. They want to be left alone to do things.
Obviously I’m thinking primarily of actual Customers, Users, Product Owners, Business Analysts and so on. These people should be working closely with the suppliers people. They should have direct contact, they should be discussing stories.
If your supplier isn’t embracing your people and treating them as their own team members something is probably wrong.
The supplier should be challenging your people – after all the suppliers are the experts, if they are simply accepting everything you ask for then something is wrong.
The same is true of other people you might want involved: a consultant or Agile coach should be welcome too. And if you decide to ask a third party to inspect their development then they should be open to this too.
Naturally they should also be open about the code too. After all the code will be yours one day.
2) Regular demonstrations
The supplier should be providing regular demonstrations – “show and tell” – as a very minimum. Every couple of weeks I expect the supplier to show the latest work. You – and your people – should be able to see working software offering more than the previous demo.
If the supplier is NOT providing regular demonstrations then you should be worried. Likewise, if the demonstrations don’t show progress get worried. Most of all, if the supplier doesn’t want to talk about why demonstrations aren’t happening, or how they can show progress then something is wrong.
3) Release, release, release
Show and tell demonstrations are good but the real test is to release to live. Releasing all the way to your live system. You might hide it on an obscure URL that nobody knows, or call it a beta release or something, I don’t care, the closer they can get to real live the better.
You supplier should be releasing to a live environment – or an exact copy – very very regularly.
The longer the supplier goes without an actual release the more nervous you should be. Sure, once in a while things go wrong and nobody is perfect. They may go two weeks with nothing to show for it. I don’t like it – and neither should you – but an occasional gap is OK.
Going four weeks without a release… I suppose it might happen in the early stages of the work. But it is in the early stages that you most need reassurance that they can deliver something – anything!
Six weeks with no release… well here we are into “3 Strikes and you are out.” Sure they will be able to give technical reasons why things messed up three times in a row. But take it from me, something is wrong.
The longer they go without an actual release to more concerned you should be and the more you should offer to work with them to address the issue.
Eight weeks? – eject, eject, eject.
4) Show me the tests
Maybe this should be warning sign #1 but for this you need someone technical, someone who knows what a test looks like. In the show-and-tells your supplier should be able to show you automated tests executing. Not very exciting perhaps and certainly not meaningful to the business but if they can’t show you then how do you know they even exist?
And if your supplier doesn’t have an automated test suite then it is certainly time to get out.
Ultimately the system they are building is yours. Your people will need to maintain it, or you will need to pay someone else to maintain it. Without automated tests that is going to be hard. Skipping tests now might make it look like you are saving money but you are not, even in the short term the lack of tests will bite you hard, it will push up costs and destroy schedules.
5) “Feature complete”
The phrase alone should be a warning sign. Equally the words “75% feature complete” (or any other percentage) is a big red flag.
If the supplier doesn’t have a test suite, if they can’t show working (preferably releasable) code then its probable they are feature stuffing. They will say they are making progress because “60% of features are done”. They may even start to claim they are feature complete but remember: a feature without a test isn’t done.
A feature without a test is pure risk. At any time a defect can put a hand up and say “Fix me!”
An automated test isn’t a guarantee of bug free code but without automated tests then I guarantee you have defects waiting to appear.
If you are in a relationship exhibiting any of these five sign then it is certainly time to talk. It may be time to end. But how do you avoid getting into that position?
Let me be as clear as I can: both you and your supplier should prioritise working, usable, functionality over more functionality. As the old saying goes “A bird in the hand is worth two in the bush”, working, deliverable (even better released) features are the priority, there should be less work in progress, fewer incomplete features, fewer “almost done” and as few as possible defects.
While cynical me thinks you might not be able to avoid it that doesn’t mean you shouldn’t try, so here are four warning signs that you are about to step on a banana skin:
1) “Agile is not that different”
Don’t let them tell you Agile isn’t different. In many ways it isn’t but if a supplier is trying to persuade you that you don’t need to change the way you work then it is a sign that either a) they don’t appreciate the magnitude of the change or b) they will tell you anything to get the contract signed.
Since you want a supplier who will challenge you it might not be a good idea to hire one who doesn’t like challenging you or doesn’t prepare you for difficulties.
2) “We are certified”
An extension of warning sign #1 is that the supplier is proud of how certified they are: ISO-9001, PMI, PRINCE-2, CMMI – some in the Agile world would regard these certifications as warning signs in their own right.
Scrum Master Certified, Agile Project Manager Certified, Scrum Product Owner Certified: these are slightly better but anyone who can’t tell you the flaws in all these certifications has myopia.
Question any organization that offers up badges rather than working products.
(Disclosure: for better or worse I hold a couple of Kanban certifications, while I think Lean Kanban University have done a better job than many in making their certifications meaningful I don’t think they are a panacea either. Anyway, Kanban certifications aren’t as recognised as those I just mentioned.)
3) Fixed or long term contract
IT suppliers have a long history of locking clients into “fixed contracts” – fixed scope, cost and time. These contracts are utterly flawed. Anyone claiming they can fix everything is a charlatan. Give them a copy of “Dear Customer: The Truth about IT”(the Xanpan prologue) and say goodbye.
Similarly locking yourself into a long term contract with a supplier before you have done some work with them is a bad sign. Do a small piece of work, for a small fee, with your potential supplier and see if they are as good as they say.
In my experience the best – most “agile” – digital suppliers can pick and choose their customers. If your supplier needs you more than you need them then it is a bad sign.