47

We keep being told we are going to be working in an agile way on a new project by senior management. They have set up stand-ups, sprint planning, retrospectives etc. etc. However, they have now come up with a plan detailing all work they want us to deliver with dates against each element and showcase dates again with what will be demoed in each one. This plan goes out to Q2 2017.

To me this seems like Waterfall in the worst sense, a plan with no input from the technical team has been drawn up where certain stories on the plan are very unclear and none have been estimated by the dev team.

However, I know their argument will be "senior stakeholders have to have dates and there has to be a plan, we can't just work from a backlog." To me this seems senior stakeholders have not bought into Agile and therefore we are doomed to fail implementing it at a lower level.

Is this a fair judgement or am I overreacting to this plan!?

user2428118
  • 109
  • 6
Sutty1000
  • 1,379
  • 1
  • 12
  • 15
  • 2
    Possible duplicate of [How to sell Agile development to (waterfall) clients](http://programmers.stackexchange.com/questions/215562/how-to-sell-agile-development-to-waterfall-clients) – gnat Jul 18 '16 at 07:45
  • 1
    see also: [How do you explain to an “agile” team that they still need to plan the software they write?](http://programmers.stackexchange.com/questions/78263/how-do-you-explain-to-an-agile-team-that-they-still-need-to-plan-the-software) – gnat Jul 18 '16 at 07:45
  • 28
    What your management came up with has absolutely nothing to do with Agile. – Euphoric Jul 18 '16 at 11:40
  • 13
    "this seems like Waterfall in the worst sense" -- by all means dislike Waterfall, but it doesn't follow that everything you encounter that you dislike is Waterfall. For example if your process results in you having an early "spike", that is to say a working implementation of part of the system before designing other parts, then you probably aren't doing Waterfall even if you aren't doing Agile (properly) either. If you aren't writing lots of design documents in response to lots of requirements documents you definitely aren't doing Waterfall even if you aren't doing Agile either. – Steve Jessop Jul 18 '16 at 11:49
  • 3
    As soon as something happens that means that massive plan is unrealistic (and it likely will happen), throw the whole thing out. When management complain, remind them that the Agile manifesto values values "responding to change over following a plan". Either they'll tell you to stick to the plan and you'll be able to say with confidence that you're not working in an Agile manner, or they'll agree and let you adapt, and hopefully learn that it's worthless planning further ahead than you can confidently predict, and next time, they won't waste their time on such a detailed (and doomed) schedule. – anaximander Jul 18 '16 at 14:27
  • 1
    "We keep being told we are going to be working in an agile way on a new project by senior management." Already it's not agile, then, because self-determination is a fundamental component of agile. However, it sounds like they're actually imposing Scrum, not agile. The two are vastly different. Scrum is quite palatable to management who want delivery dates and metrics, but it isn't agile. – Kyralessa Jul 18 '16 at 15:23
  • Even when working agile you need a direction - and a direction is the same as a line from you current point to a defined goal. So just take the first milestone-goal as your direction and work in sprints to implement the prioritized features. - everything else is a management problem – Falco Jul 18 '16 at 15:27
  • If the teams did not estimate the tasks, and the deadlines and functionality are cast in concrete, then the dev teams should take a day to verify the estimates. Who knows, they could be generous. Once these estimates are done, throw them into sprints to determine where there are risks. Inform management as soon as possible. – Tony Ennis Jul 19 '16 at 03:12
  • 3
    @Kyralessa At least from my experience, Scrum is almost always sold as an agile methodology. – T. Sar Jul 19 '16 at 15:32
  • 3
    @kyralessa from the quick research I could do it seems you are the only one to say SCRUM is not agile. If you do have some reference to back this up i'd love to read them up. – Newtopian Jul 19 '16 at 17:18
  • 1
    @Newtopian I think Scrum is a tool (specifically, a framework) under the larger, more broad "agile" umbrella and the point Kyralessa was trying to make is that because it's precise enough in terms of what it prescribes to do without prescribing other important tenets of agile (like ground-up self determination instead of top-down determination), it's often sold AS agile itself - which is misleading and somewhat of a lie to make hard change more palatable. – Mattygabe Jul 20 '16 at 14:30
  • @Mattygabe Comparing Scrum to agile is akin to comparing Java to OOP. Saying that Scrum is agile is just as correct as saying that Java is OOP. Java is part of the OOP family, philosophy just as Scrum is part of the Agile way. I do agree with your point though that there is more, a lot more to agile than Scrum. Kyralessa however claimed that Scrum is NOT agile, which I felt was wrong and I was curious to see on what basis this claim was made, keeping an open mind that I could have been wrong instead. – Newtopian Jul 20 '16 at 17:06
  • 1
    @Newtopian [Scrum is not agile](http://www.drdobbs.com/architecture-and-design/scrum-agile/240164386). Its a project management system that is *sold as* agile, but it fails at so many aspects of true agile systems. The easiest complaint to make about it is that Scrum is like a series of mini waterfalls. The problem generally though is that people doing scrum follow the scrum processes religiously and blindly, forgetting the agility part of agile. – gbjbaanb Jul 24 '16 at 13:12
  • If in your experience SCRUM equates to a whole bunch of waterfall you are most likely doing it wrong. Then again, how do you define waterfall ? if it is the process of thinking about what you are about to do before you get to do it, then all programming should fall in here. Now, I do agree with Mr Holub in part here, SCRUM is far from the ideal Agile process, but it is, when done correctly much more Agile than strict waterfall. Most results when searching about SCRUM not being agile equates to experience in an environment that were basically doing it wrong. – Newtopian Jul 25 '16 at 18:02
  • @Newtopian, that's the line I hear over and over again. "If Scrum isn't working for you, you're doing it wrong." People seem to have the bizarre notion that Scrum is some kind of gold standard against which all else can be measured, while it itself is impervious to criticism. I myself have never worked at a company where Scrum *did* work right. Maybe they all did it wrong (though they sure gave the impression of going by the book), but then you also have to ask if there's a point in using a method that everyone somehow manages to do wrong. – Kyralessa Oct 04 '16 at 04:52
  • @Kyralessa I think you missed my point. SCRUM is not for everyone, some will have success with it, some won't. But to state that a process is not working one has to first try it, for real. Stating SCRUM does not work because they did iterative waterfall and called it SCRUM does not mean much, in this particular case, IMHO, they are indeed "doing it wrong". – Newtopian Oct 04 '16 at 11:52

9 Answers9

62

There's a difference between meeting the deadline and fulfilling all requirements. Its like the old adage "fast, good or cheap, pick two".

So here you have fixed dates for delivery - that's good, it means you are time-boxed in that what you deliver at the end of your last sprint will be the final product. You remember that you always have to release working software at the end of each and every sprint don't you.

What may happen is that the final software will be missing some features. Well, this happens with all development methodologies, waterfall included. All that will happen is that you'll be tasked with producing a patch release afterwards, or a version 2. That assumes your final delivery is good enough of course!

So fixed dates are not a non-agile way of working. Agile doesn't mean there's an unlimited budget for you to play with your new planning tools. It does mean you'll have to focus on delivery, that's never a bad thing.

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
gbjbaanb
  • 48,354
  • 6
  • 102
  • 172
  • 5
    This is true, but if the management then decides that they want to be feature-complete at the delivery date anyway then the developers are left holding the bag. You do get my upvote because as you point out, what the OP describes isn't *inherently* opposed to working Agile. – Cronax Jul 18 '16 at 13:40
  • 3
    @Cronax Every manager worth the name will understand time and features are opposing forces. You choose which one is most important. If they decide they have to be feature complete and timeboxed, then its their fault for not manning the team appropriately. (I know, I know...) – gbjbaanb Jul 18 '16 at 13:45
  • I see you have a lot more faith in managers than I do...in my experience most managers don't see the basic correlation between the two, they will happily promise the customer features A through Z even if the developers tell them that's a 'magical Christmas land' timeline. I have yet to meet the manager who will instead promise A through K with a good chance that they'll be able to go back to the customer to inform them there is room for more...My experience is that 90% of the time, the features and date are fixed and it's the quality that's left variable. – Cronax Jul 18 '16 at 13:52
  • 3
    @Cronax don't be too hard on the poor managers, its often Sales that drops them in it. – gbjbaanb Jul 18 '16 at 13:55
  • That's definitely true, at most shops Sales gets away with far too much... – Cronax Jul 18 '16 at 14:03
  • 5
    Reading this as stated "all work they want us to deliver with dates against each element and showcase dates again with what will be demoed in each one," it doesn't seem that the plan is flexible on what is delivered o the given dates. – JimmyJames Jul 18 '16 at 14:35
  • 14
    This answer makes a good point, but it seems to only be applicable to a different situation. From the question, it seems that *what* will be delivered and *when* it will be delivered are both being dictated by management. – Ben Aaronson Jul 18 '16 at 14:54
  • 2
    @gbjbaanb a manager worth his name should be able to say 'thats not possible' just as much as a developer – GoatInTheMachine Jul 18 '16 at 15:32
  • 2
    @GoatInTheMachine often you just don't know how much you can achieve, so you either assume the worst - and plan with massive contingency, or assume the best and try to fit more features in. Either way, you end up having to be flexible near the end when you find how things have gone. Saying "its not possible" right at the start just makes you just sound like someone whose not going to be getting a promotion :-) – gbjbaanb Jul 18 '16 at 15:48
  • But perhaps, perhaps, someone who should get a promotion @gbjbaanb. – RubberDuck Jul 18 '16 at 22:13
  • @BenAaronson sure, but that's the way it always is - "I want it all and I want it now" has always been the planning scheme. They will face reality when it gets closer to the deadline date, and they will either drop features or extend time, as its always been done. But no-one starts a project thinking they'll fail, even devs think they can get more done than they do. Agile methods have velocity to get a better idea of what you will end up with sooner, but even Agile methods have a huge backlog to work through. – gbjbaanb Jul 19 '16 at 07:40
38

No. This is the exact sort of things that non-software companies tend to do. There are plans, and deadlines, and budgets. And it will inevitably fail, since humans suck at predicting the future.

Let's go through the various points here:

We keep being told we are going to be working in an agile way on a new project by senior management.

If you were Agile, then you'd be having self organized teams, not being told how to work by management.

However, they have now come up with a plan detailing all work they want us to deliver with dates against each element and showcase dates again with what will be demoed in each one.

Nope. That is pretty much the antithesis of iterative development. Something will happen (someone gets sick, someone leaves, some requirement was forgotten, your servers die, whatever) and then you miss one of these goals. Now management either gets to recalculate the entire plan, or crack the whip on development.

none have been estimated by the dev team.

So how does management know that this plan is viable at all? In Agile, work is a negotiation. Business says: we would like this. Engineering says: okay, assuming XYZ, that will take 3 weeks. There is no customer collaboration in what you're describing. No individuals and interactions.

To me this seems senior stakeholders have not bought into Agile and therefore we are doomed to fail implementing it at a lower level.

You're not necessarily doomed, but if not, it's only a coincidence. When all of the work shows up because management can't see the future, you'll miss your dates (or produce shoddy code, or require more resources than expected). That will then be your fault. Management will likely then pressure you to work more hours to hit the date, or maybe throw people at the problem.

Best case, management is actually agile, and is smart enough to reduce scope. Meaning they just spent all of this time building a big detailed plan that is worthless.

Telastyn
  • 108,850
  • 29
  • 239
  • 365
  • *"And it will inevitably fail, since humans suck at predicting the future."* Really? What a blanket statement. What pessimism. How fatalistic. – Wildcard Jul 18 '16 at 21:57
  • 6
    Pessimism @Wildcard? Or is it *realism*? – RubberDuck Jul 18 '16 at 22:16
  • 7
    @Wildcard And ironically very self referential, making predictions about the future ;-) – Cort Ammon Jul 18 '16 at 22:16
  • 1
    Wildcard is right, I'm pretty sure we nailed the date for when the sun is going to explode or how much more disastrous natural disasters will become due to climate change, that world peace will remain a joke for the foreseeable future, etc. See Telastyn, we are great at predicting the future so please cut down on your overly pessimistic statements! – null Jul 18 '16 at 22:25
  • Hmmm, reading it again, perhaps the "it" refers to the specific scenario in the question. I had read it as saying, essentially, that "plans, deadlines and budgets will inevitably fail." THAT'S fatalism, no question. But perhaps that wasn't quite @Telastyn's intent. – Wildcard Jul 18 '16 at 22:29
  • Even on the reason given, though, I have to disagree. *"...since humans suck at predicting the future."* I think this is a very unhelpful and false conclusion to draw. It doesn't solve or improve anything, only attempts (rather badly IMO) to *explain* something. If plans fail, it is because of a lack of knowledge of how to make the intention become a reality. (Who wants to *predict* the future? Let's *make* the future we want to happen, happen.) :) – Wildcard Jul 18 '16 at 22:32
  • Maybe they use Asimov’s *psycohistory* to predict the human issues, and contracted the Oricle of Delphi to plot the natural disasters. – JDługosz Jul 18 '16 at 22:42
  • 8
    @wildcard - `No plan survives contact with the enemy`. And you can't tell me who the biggest winner is going to be on the NYSE January 2020. It is true. We have many millennia of data to show that it is true. And knowing what you don't/can't know is of _vital_ helpfulness when planning to construct software. Look at the OP's situation - the overwhelming majority of their plan is built on _guesses no better than chance_. I think that's a terrible way to plan. **Even if** you think it's naive and fatalistic of me, it's still in no way Agile. – Telastyn Jul 19 '16 at 00:24
  • 2
    Completely agreed it's not Agile, what's described in the question. And yet targets can and do get accomplished every day. It is true that *tactical* targets often require adjustment in accomplishing a broader *strategic* target, but that doesn't make it impossible to ever meet a deadline or do so within a budget. By the way, I think we may actually be in closer agreement than it seems: I agree people aren't great at predicting the future. I disagree that that *precludes* accomplishing an intended aim. – Wildcard Jul 19 '16 at 01:08
  • 1
    @Wildcard the problem isn't having goals or objectives and target milestones for them, the problem is _rigidly holding to those regardless of reality._ Most often, situations like this end up in shoddy or botched work because management has committed to someone that feature X, Y, Z will be done by date ABC. If the date isn't realistic (which it probably won't be if it was planned with no dev team input) then it's almost inevitable this will happen because management normally has an expectation that "if you work them hard enough more work comes out!" or some other variation. – enderland Jul 19 '16 at 12:23
  • @Wildcard in ten years I have not seen (as a part of or even as an observer) a single project (over 40 hours of work or $10k budget) that was done on time and on budget, regardless of quality. Not one. Even when you factor in the 20% contingency. Not one. – corsiKa Jul 19 '16 at 16:57
  • @enderland, that is an excellent statement of the situation and a good distinction to make. And I would only add to it: that the key ingredient omitted in such unattainable plans was actual observation (input from the dev team, as you say). And without that, goals can indeed be impossible to attain as they are *not* based on reality. – Wildcard Jul 19 '16 at 18:04
  • 1
    @corsiKa, that is fascinating, actually. If I ever am in a position to guide a software project from an executive position from beginning to end, I will take that as a personal challenge and see what can be done. :) Thanks for giving that info. – Wildcard Jul 19 '16 at 18:05
  • @corsiKa My assessment of the situaiton is that there's a laziness/ignorance around estimation. Proper estimates are propabilty distributions but I see demands for a single number and obviously, you can't draw a curve with s single point. The reponse to that is implied range and distribution (presumably normal) I hear +/- 100% a lot which is supposed to be really generous to the estimator but that simply means the lower bound is 0 and estimate should be half the worst case which usually isn't useful. Estimates in ranges would be much more accurate and useful. – JimmyJames Jul 20 '16 at 14:25
  • Strongly disagree, because you are creating a conflict between developers and management. There is no development without business, so development should always strive to get as much business value produced as possible. It is normal that the company needs features, so you better deliver the best product you can by that deadline. – winkbrace Jul 22 '16 at 09:44
  • @winkbrace - but developers' idea of best product and business' idea of best product will always vary. Developers see the code, so understand maintenance implications. Developers do the work, so understand the effort involved in actually doing things. Business sees customer needs, and better understand budgets. These differences _will_ cause conflict. Either you can work together and use the diverse views to build a better product, or you can fight. – Telastyn Jul 22 '16 at 11:20
  • @winkbrace "so development should always strive to get as much business value produced as possible" I completely agree and I would be really surprised if anyone on the thread disagrees with that. The point here (and IMO the whole point of agile) is that letting the developers self-optimize allows them to create **more** value. Micromanagement will not create more value, it's 100% overhead. Again and again I've seen project managers gum up a product and destroy value. The point of Agile is to have the business owners control 'what' and the project team control 'how'. – JimmyJames Jul 22 '16 at 13:20
18

If there's an expectation that specific sets of features are to be delivered on specific dates, then no, this is not agile project management. Agile project management is empirical in nature. Projections are not made based on the wishes of executives but rather on analysis of prior performance.

Your description matches up with what I consider to be cargo-cult agile. The focus is on the specific processes and ceremonies and not on the core concepts of evidence-based project management. You might have some luck getting business people to understand if you relate this to Lean or TPS. The real problem you need to solve here is getting management past their fear of the unknown. The right answer to the executives is "we can't tell you now when things will be done but once we start delivering value, we can build projections based on our experience." Developers tend to say things like "it's done when it's done" and "I don't know when it will be done." Managers won't say things like that to the executives, it makes them sound like nincompoops. They are simply doing what they know.

Most likely, the plan will fail and need to be revised. The biggest risk for the team is that there will be a big push to hit the deadlines and quality will suffer. At some point you will not be on target (most likely, it will be the first deadline) and there will be a push to hit that date. Overtime will be expected and there will be pressure to cut corners (skip unit test, code reviews, etc.) This is a slippery slope and once you start down this path, it's a bit of a downward spiral and things will get ugly. Productivity will get worse as the project continues in this way.

If you can get the dev team to present a unified front, you really should push back and hold the line on quality. My experience is that project managers tend to think software output is linear. That is, each period X will produce Y 'precentage complete'. That is, if you aren't "50% complete" by halfway through the allowed time, the klaxons start blaring. In reality, if you are doing it right, the first feature tends to take a lot longer than the 50th feature (of similar size.) If you can get through that initial danger crisis period ("what's happening?", "I don't see anything getting done!") you'll probably be OK.

JimmyJames
  • 24,682
  • 2
  • 50
  • 92
9

Welcome to real business.

There is an older style of business, which I tend to derisively call "traditional development" and then there's a new style, "agile development." If I try to treat these as opposing ideals, we see a straightforward division down the middle: plans and requirements go on the traditional column, discovery and evolution go in the agile column. It's neat, tidy, and wrong.

In reality, business is a search for the happy medium between the two. It's easy to show that either extreme actually falls flat on its face. We who love Agile eagerly demonstrate all the issues of the pure ideal of traditional development, and there are plenty who can show the many ways pure Agile falls apart. The successful agile companies are the ones that find their particular balance between the two. The successful traditional companies are the ones that find their particular balance between the two. You can't have one without the other.

Even our blessed SCRUM process shows a balance between the two. While there is a clear attempt to maximize agility, there are a few key tradeoffs made. For instance, the Product Owner has the mighty job of advocating for all of the customers. SCRUM intentionally does not specify how that interaction works. It intentionally handwaves over the fact that everyone needs to get paid at the end of the day. Its' the Product Owner's job to create the illusion that that doesn't matter.

(Its interesting to note that pure agile works great, so long as you don't get paid until you produce a product, and you don't get access to proprietary information until you are vested. I think the only software engineers that are comfortable with this trade are the entrepreneurs)

So the management has dictated what features will be in there and when they need to be there. That's fine. A phrase I have heard is "the customer picks the what and the when, the producer picks the who and the How." You've been signed up for the "what" and the "when." They have not stated anything about the who or the how, other than to offer you a chance to use "Agile" as your how. All that's left is to help management understand how many people they are going to need to hire to meet their needs.

In a perfect world, your company is agile from the outside. It interacts with its customers in an agile way, letting the developers develop agily for them. However, very often the company must interact with the outside while developing agily inside. In between is always a complex set of tradeoffs, unique to each company.

Personally, I treat this situation as a test case for anyone who thinks they understand agile development. At some point in the future, you will have to develop a product for a deadline, and that product/deadline pair will be relatively fixed. If a fixed product/deadline shatters your process, can you truly say you were Agile in the first place?

My advice: don't think of this as a waterfall. You still control the "how." You can still do all of the rapid sprinting and flexible prototyping that Agile is so famous for. You merely have to be aware that the rubber meets the road, and you have to deliver. This is the real world, not the ideal world. Would it have been better for them to ask you in the first place? Sure. It may not have been your call. There may be a thousand business-related reasons to do it their way that you simply do not fully understand. Feel free to push back on them, but understand that they may have a very good reason for what they did.

Cort Ammon
  • 10,840
  • 3
  • 23
  • 32
4

Agile does not prevent you from planning milestones (E.g we will release V 1.0 in 3 months), but what goes into each milestones cannot be fixed.

I think how you should react depends on the nature of the project. If the project is to send a man to the moon by Q2 2017 everyone would agree that it is doomed to fail. If you think you can deliver an MVP by the end of Q2 2017 you should work on it sprint by sprint.

If the management thinks your team is doing their best and you can show progress with each sprint you should be able to negotiate for more time.

Erik Eidt
  • 33,282
  • 5
  • 57
  • 91
Chamindu
  • 328
  • 1
  • 6
4

EVERY business relevant project has constraints:

  • Time
  • Resources
  • An expected minimum feature set

This is nothing else. Developing agile doesn't mean "people pay us money, so we can develop whatever we want for whenever it may be ready" - you will always have some time-frame. There will always be some date with some minimum requirements and if they are not met the project will be cancelled and be called a failure. They may sometimes be implicit - so the manager knows "If I don't have a working UI with these features after 4 weeks, this project is doomed to fail" - or there may be shareholders who set a goal.

There are many projects resulting from legislation. - If the government decides you have to implement Feature X until 2017 to respect a new law, you will have an non-negotiable dead-line and a set of features which need to be ready. The only variable is the amount of resources which management can allocate to the task. - And in these projects, where the deadline is an external decision, they will need to watch your progress, hear you prognosis and staff up the teams or outsource part of the work to meet their goals.

All this doesn't oppose agile development. You will still have your sprints, develop your features in your own time-frame. You will always get your feature-priorities from a client - and you will work to deliver as many of these features as you can until the deadline.

If the deadline will actually be met with the available resources is a management problem. You can give your prognosis and weekly/daily status updates and they can decide if they need more resources. Otherwise you will continue working in sprints and deliver runnables - the same as any project.

Falco
  • 1,293
  • 8
  • 14
2

Imagine asking someone to paint a wall, a house and then a whole street for you, how much time would you give that person to do it ?

Whatever your answer is, you'll be wrong. That's it.

There's no way they could be right about dates if they didn't ask the people who need to do the work what they think.

By the way, if you (as a team) accept these dates, you're in the wrong there.

You should ask for some time to work on this planning along with the stakeholders, so that you can set priorities depending on how easy and fast it is to get things done.

For example, maybe the final work will take twice as long as they thought, but they could use a beta much sooner than they expected.

All in all, you can't let people think you'll be able to do X in Y time if you can't or could be faster, that's your responsibility to make it clear about what you need in terms of details and time.

Steve Chamaillard
  • 1,691
  • 1
  • 11
  • 20
  • 1
    This is not really about **accepting** a deadline. What do you do, if the government decides your company has to comply with a certain law until 2017 ? You cannot say "I don't accept this" - you will have to work in sprints, prioritize and try to implement the required features. You report your progress in each sprint and management can decide to acquire additional resources if the number of features you present doesn't meet their expectations. – Falco Jul 18 '16 at 15:11
2

As someone has already pointed out before the manifesto says:

Individuals and interactions over process

I would suggest you have a look at the plan put forward and suggest changes to it. Remember the Manifesto says that the backlog is never final, it keeps evolving.

So you could take your suggestions to the team. If you have a valid reasoning and the team agrees to it, any product owner worth his/her salt will consider them and evlove the backlog to reflect the opinion of the entire team.

This is the point where it could go two ways.

  1. Product owner and business agree with your reasoning and may increase resources to meet the deadline if that's a options OR they may select to drop some features to meet the deadline.

  2. They may still want to stick to their own version against the collective opinion of the team.

If the outcome is #2 then this is not Agile.

If you end up with #1 then I would say the team is on the right track , because Agile is not about just the Devs "Responding to change" it's also about the business being able to respond to change.

JDługosz
  • 568
  • 2
  • 9
Pratik
  • 129
  • 1
-2

Its not aglie planning no.

But if you prentend you dont know the plan and just work sprint by sprint. It could be aglie working.

There are always going to be dates and budgets. There is always a risk they will be missed or overrun and when that happens you are always going to have to fall back to a plan B.

If you have been working in an agile way then plan B is hopefully last sprint's demo

Ewan
  • 70,664
  • 5
  • 76
  • 161