How can a client support agile development methodology?

Question

My company works in the field of public infrastructure in Europe, specifically as a software provider and operator. All of our development work is currently outhoused, to two main suppliers relevant for this question. Our company background is in the (semi) public sector, so some development methods take a little longer to get here.

One of our suppliers has recently undergone a merger with a larger IT company and as a result, is now embracing agile development methods more deeply. Thus far, we have been working with detailed specification sheets and lump-sum payments for our systems, but from my (limited) understanding of agile development methods this is not really feasible with the model. Additionally, we made the experience that projects run over budget anyway, so the meticulous planning beforehand seems a bit like crystal-balling, with the same amount of relevance to the future ahead.

We have had a discussion with our suppliers about this, of course, and they told us very neat sounding things including how we will monitor the total expenditures during the project as it goes on and which knobs we can turn as it progresses in order to control the cost. They also mentioned that instead of developing large, unwieldy specification sheets we should formulate our requirements where possible as User Stories ["As an X I want to be able to do Y in order to achieve Z", in all brevity]

Our other supplier mentioned today that they have trouble estimating the amount of work beforehand, and discussing a similar model to above, they were enthusiastic about it, however they have relatively little experience with agile development methods thanks to their background being in the public sector as well. They mentioned that agile models mean "You can't say at the beginning what the final product will look like." and "You cannot say with reasonable certainty how much a specific product or feature will cost.", which are usually dealbreakers for their clients.

From my understanding, however, not being able to say what the final product looks like is allievated by the fact that as the project progresses, the client (us, in this case) is kept in the loop and able to bring input into the project, to shape it the way they wish it to be or how they 'meant' it to be. Because to be frank, I do not know how each system should look as I specify it either, and I doubt many of their other clients do. About the cost, as explained above, I have come to understand that while an estimate ahead of time is not possible, controling the cost is by e.g. reducing features, simplifying parts etc.

Questions: Is my above understanding of the differences between agile development and traditional waterfall models correct, in terms of planning a project?

How can I, as a customer, best support agile development by my suppliers? Any recommended reading would be helpful.

Is there something we should ask for or insist on, like a maximum amount of manhours per month that we're willing to pay, a minimum amount of features/functionalities, or something like that?

P.S. If this is the wrong Stack to ask the question feel free to move it.

EDIT: For clarity, the first company proposed going with a Kanban model, perhaps borrowing some aspects from a Scrum approach.

Answer 1

Your understanding is generally correct.

I really like your approach, because one of the big complaints I hear when I discuss pure Agile is "client needs to know exactly what will be done, when will it be done and how much will it cost". The fact that you are willing to accept that uncertainty and take the risk on yourself already makes you a great client. But you should be careful. Agile is extra easy to get wrong. And while it is true that good Agile process will give you all that was promised to you, when it is done incorrectly, it will bite you in the ass.

First thing you should deal with is a legal contract. Contract that enables the high-feedback and continous-payment are rare. And many legal contract experts don't have experience with them. I would highly recommend contacting your legal department and talking in depth about what kind of contract you want to create between you and your supliers. Your legal experts will most probably be strongly inclined to create a "traditional" contract that defines what, when and how much will it cost. You should use all your effort to resist this approach.

One of the other answrer mentions demos. Yes. You want to see a demo of a working software every week or two. But be careful, as it is easy to "fake" a demo. You shouldn't accept anything less than promised piece of a feature running in production. This means it was developed, tested, deplyed and is being supported. You should be able to use the feature yourself in your prefered environment. Having demos on different than production environment or done by someone else than you makes it easy to hide additional effort necessary to actually turn it into production-ready feature.

You should also be careful about "flacid Scrum" scenario, when accumulated technical debt slows down development and makes it more expensive to make changes. It takes lots of discipline and motivation to keep the code and architecture in high enough quality to keep the development pace fast. It is easy to get lulled into false sense of speed, when development starts and features are created fast. But as time progresses and more and more features are added, development slows down. So feature that could have taken few days before, now takes few weeks. I don't know what you, as a client, can do to ensure this doesn't happen. You might have trust in your supplier's abilities. But if they never did proper Agile development, they probably lack skills and experiences to maintain quality long-term. Maybe having an independent 3rd party contractor check for development quality and report to you every so often? You might want to have them demonstrate that their development process and environment is supporting the agility and that there is minimal waste in the process?

Answer 2

As a client you can add great value by collaborating with the development teams.

Talk to them directly as much as possible. Explain to them how your business works and why the software they are building is going to help it move forward. When working on specific parts of software for a department of your business, bring an expert from that department with you.

Create a shared language/vocabulary and insist that the developers use this language in their code and internal communication as much as possible. It will be a lot easier to communicate with the dev team and you can test their knowledge about your business. Ultimately it is the understanding that the developers have about your business that ends up in the code.

Together with the team, create a backlog of features, your job as product owner is to order this backlog, so the things most important to your business are created first.

Ask the team(s) to release often, daily, weekly, bi-weekly, as often as they’re comfortable with. This doesn’t have to be to production, but make it as close to the production environment as possible. Have real users test these releases. Gather feedback from these real users. Adjust the feature if necessary.

If you follow these guidelines, the chances of creating a useful software product will be much higher than with any detailed specification upfront. It might not be exactly what you had in mind at the start, it probably will be better!

Answer 3

Agile is about continous feedback. You're going to be seeing the work in progress, and perhaps begin using it, very early on, and very often. Rather than meeting with the developers once a month or even less, you'll want to meet at least weekly -- but these should not be boring meetings, they are more like "demos" where you and your end users get to try out the new software features they're developing. That's how the Agile team finds out whether they're on the right track, and how they correct things if not.

Another important aspect is to have a clear sense of priorities -- both of risks and of needs. The first things you should work on are either the things you're most uncertain of, or the things that you absolutely require most. That way, you get these things resolved early on (with the smallest investment of time and money). If one of those uncertainties turned out to be a dealbreaker, you can cancel the project or re-plan it without having lost very much. If the software satisfies such an important need that your users don't want to live without it, you can begin putting it into production without waiting for the rest of the features to be developed. In this way, Agile is both more economical and better at risk management than other approaches.

I'd recommend reading Lean From The Trenches by Henrik Kniberg. It's a case study from a public sector project in Europe, like yours.

Answer 4

One of the underlying values of Agile Software Development is "customer collaboration over contract negotiation". You probably aren't going to simply dispose of contracts, but you can collaborate directly with the supplier to figure out what both of you expect from the relationship so everyone can get what they need.

There's no singular agile methodology out there. Even organizations using the same framework are likely to end up with differences in how they do things. Open lines of communication and collaboration to define the relationship is the best answer you're probably going to get. Your suppliers may be able to point you to resources that describe the methodology that they are using so you can better understand it.

Answer 5

It's important to remember that Agile is not a panacea for all the problems that can vex a software project, nor is it an excuse for a lack of planning or lack of design experience and expertise. It is also not necessarily more efficient than waterfall, for exactly the same reasons that building a steel skyscraper is not more efficient when done via a doghouse, then a domestic dwelling, then a small commercial office, then the skyscraper.

Amongst other things, Agile attempts to solve two defects of waterfall models - firstly, that it might be difficult to specify the ideal workings of an information system until there is already some experience of operating it or something like it, and secondly, the circumstances which the software is designed to suit may change over time. These risks are proportional to the size and length of the development.

The risks created by Agile are that there may be a great deal of rework, or the fundamental design may quickly lose integrity. Clients or developers may neglect doing hard work on proper design early when it would have been fruitful to do it early. Also, whilst a part-implementation of a software project usually has some usefulness, it may not have significant usefulness, or more usefulness than alternatives available at the outset.

For a bespoke software supplier, the benefits of what they call Agile is also that they are not compelled to deliver any functionality in particular, and that financial risk is passed back to the client. Commercially it is similar to a gangmaster model of employment for software developers, and clients have to be careful that they possess the skill and experience necessary to manage such gangs.

Answer 6

You can play along with all the contemporary agile practices and become real intimate with your suppliers. And you may well reap some of the advertised benefits. Just be sure to nail down two things from the start.

• Reserve the right to stop the project and part with your suppliers at any moment without the need to explain yourself. You will pay for the hours spent and nothing more.

This is important because you may find yourself at a point at which it is obvious the project is not going to succeed. Or it is no longer relevant. Or a better option pops up. This will also keep your suppliers on their toes, they will be motivated to keep you happy.

• Make sure you do not move beyond a point of no return.

Have a backup plan. This could be continuing to do things the old way for a bit longer and try something different. This is not always possible but it is important because if you do not have this, the first thing will be a moot point. You will be toast, your suppliers will have you for breakfast.

Answer 7

A very good question and a very good attitude as a client to want to work with software providers! +1

Agile is a mindset, a way of thinking that consists of a few values and a bunch of principles - and it is something teams and companies can use to guide their decision making. For example: should we focus on building an iron-clad contract with the client, or perhaps put something simple in place that would be more inclusive and promote collaboration?

Scrum & Kanban are 'managerial frameworks' that help structure how work is planned, done and deployed - and they are used to promote shorter deployment cycles with quicker feedback from users which allows teams to be more flexible and adjust to client needs.

Companies that are new to applying Agile and/or frameworks like Scrum may tend to follow what the book (or consultant) says without understanding WHY their doing it. From a project management approach try to keep the following in mind:

• Focus on WHAT it is you want (feature, application, flow etc) and understand WHY you want it (the business value you intend to get from it) and allow the technical specialists to focus on the HOW to build it for you.
• The business value you intend to get from the work you are requesting adds a lot of contexts to HOW something should be built - help the teams understand that. For example, building a login screen for a bank will be done differently from building one for a kids website.
• Try building a relationship with your 'project team' so they are comfortable exposing you to the progress of work. Scrum and Kanban are all about flexibility - your feedback during the iteration may help make value-adding changes before they actually deploy. I don't mean scope creep, but rather something like "the popup actually doesn't work, now that I see it, so rather remove it and don't spend more time trying to make it fit on the form".

Regarding paying for deliverables. How we pay differs from country to country so within the context of what you need to so legally you could pay-per-iteration. In our industry we pay for deliverables after a sprint - For example, a team takes on work they feel confident to complete in a sprint (2 weeks) and you are charged per hour for the member(s) of the team that would work on your request. Should the agreed-upon deliverable be ready for deployment at the end of the sprint then you pay the rates - if due to the teams own fault they cannot deliver the promised outcome then their company covers the cost for the team for that sprint. Within context, this could also mean that partial payments happen for partial deliverables etc

Answer 8

This might turn into a question for the attorneys: how are contract negotiations with these suppliers done now? You should have the right to determine what system gets built for you and how much you are going to have to pay to get it. You have such a system in place now. It sounds to me like, under the guise of "agile mumble mumble ..." this supplier is trying to change the rules of the game.