Laszlo Szalvay

In August 2000, Laszlo Szalvay founded Danube Technologies, Inc. with his brother Victor in Seattle, Wash. When an internal tool that Danube developed to improve its own processes became a hit with clients, Danube inadvertently discovered its flagship product, ScrumWorks Pro. Danube has also introduced a services division, now called ScrumCORE, in August 2004, which provides Scrum and XP coaching to clients through public and private courses as well as onsite engagements.

Currently, Laszlo serves as president of Danube Technologies, Inc. As such, he drives the company’s vision, creating business initiatives that influence everything from sales and marketing to human resources and employee retention to accounting.

Direct communication as a half-dead project saver: When you start in an over-waterfall company

Picture courtesy of clagnut@flickr

At the end of year 2008 our team was given a project that was critical from the $$ point of view. We had to deliver the project by the end of March 2009 in order to avoid huge fees from our customer. The problem was that the project we got was being developed by different team in different location and the quality of the existing solution was at least questionable. It turned out that the whole old team left the company and our small commando squad had to save the day. I just have to mention that the company we all worked for was a pure-waterfall monster.

You know, agile books are fun to read, but how do you start it if you happen to be a developer in a pure waterfall company on an impossible project? I went through it and going to show what worked well for us. I will tell how we were able to get an impossible project apply the agile principles and survive.

A bit of a history
The company I used to work for sometime didn’t know/use Agile methods. Everything there was pure waterfall i.e. there was a marketing that defined what it wanted (previously negotiated the contract i.e. feature list with the customer), then it passed the specification docs to product definition team that was in charge of designing the solution, finding ALL possible problems and answering ALL possible questions. Then after couple of months the technical specifications were passed to the development team that… started everything all over again. I mean that the development team usually found documents received from product definition team useless – it’s not my opinion, rather my conclusion after talks with many friend-developers. Some docs like protocol specifications or conversion specs were REALLY useful but they were vast minority.

Anyway, when developers started working on the project it usually took just few classes to find some blocking issues that had not been predicted/designed in the docs. “How it’s possible?” “They were supposed to find ALL possible problems and answer ALL possible questions”. Well, they were supposed to but it was IMPOSSIBLE to do so. Even perfectly prepared and thoroughly checked documentation will not replace direct communication channels.

The project I’m going to describe was quite different – there was no documentation, no specification but more so there was not a single person understanding the problem. This was a real shocker for the company used to work in an “ordered” and “predictable” way.

The Project
In short we had to develop an unknown communication protocol to connect the two unknown existing systems. And the time we were given was pretty much estimated as we already knew all the guts and gears in this system. Ah – I forgot about some pretty “unimportant” detail: the test database for the test system was located around 1000 km from our desks and the VPN connection was not yet established. So, for couple of weeks we were just having a pretty “black box” environment – it was not so bad though because we had some time to learn how to compile given sources (still, this was the time when we were supposed to be developing software).

What did we have?
We had the documentation for the protocol we had to implement with examples (requests and responses). The documentation was not very useful, though because it was designed for people who knew this protocol before. This documentation was not explaining many concepts – it was assuming the reader’s knowledge on quite high level – unfortunately we were GREEN.
We also had some stored procedures (in our unreachable database) that were supposed to contain business logic and they were supposed to work already – we were told that they require just small changes. Basically we had to develop a part that had to receive the requests, parse and process it and invoke already existing stored procedure with transformed parameters – we knew that we would also modify or create completely new stored procedures from scratch.

When we eventually got to know what to do we knew that we had to implement hotel availability (3 different request/responses) and booking (couple of quite complex transaction flows) messages. The availability part was supposed to be 100% ready (this way we could focus only on booking) – we just had to test it and confirm (probably do some small fixes).

To summarize: we had some germ of the C# code, fully functional stored procedures in T-SQL (MS SQL server) that required some significant rework and proprietary ASCII format specification. I also have to mention that neither of the team members was C# or T-SQL expert (I put it as delicate as possible).

Finally @Work
After some time of investigation we knew how the frontend and backend work but we still couldn’t test the system because we had no database. When it was ready we established a test environment and we finally was able to integrate the whole system. We were able to start this machinery and inject some requests. We were even receiving some responses – but at this moment we had completely no idea whether these responses were correct or not.

Here is the moment we started communicating directly with our customer who started testing delivered system in test environment and giving us feedback. If you ask why we didn’t communicate with them earlier I would answer that we had nothing to show them as the test environment was unreachable for developers. If we couldn’t show them anything we weren’t able to get any feedback. That sucked…

I will leave the details of our communication process with customer for the next post.

Lessons learned so far
We took over the project in a rush and were just given a source codes from the previous team – which wasn’t the first class anyway (I mean the code). There was no unit tests, no continuous integration environment, no single product backlog but we started creating those artefacts. And you know what – this was the best decision we could make – we took as much as we could from the agile world in this project.

The main problem that was probably the root cause of all other issues was lack of communication. Before starting contacting directly with customer (who became our product owner, in fact) this was the worst part of the project because we not only didn’t know what to do but also we had no one who could verify our assumptions. Lack of communication was very visible and the deadlines were getting closer. We were really thinking that we will be late with such pace and information flow (or rather lack of it). We knew that with such level of uncertainty agile practices – especially open and effective communication – could help us saving our jobs.

In the next part I will explain how we solved our communication problems, how agile practices helped keep the project on track and keep the number of bugs close to zero as well as how the whole project finished. Stay tuned!

Feedback
Do you recall such situation in your own project(s)? What was the solution that worked for your team? I’m really curious your opinions and thoughts.

10 Contracts for your next Agile Software Project

As a customer or supplier of software services at the beginning of a Software Development Project, you know that there is too much at stake to work with just a verbal agreement. A contract is really just a set of written playing rules. The right rules increase the chance of success for both parties. The wrong rules make cooperation difficult and hinder progress. What are the available playing rules and what is the best approach for a agile project?

Last week, we looked at the purpose and contents of a contract and identified criteria for evaluating contracts for Scrum and agile projects. I suggested 4 points for comparing contract forms:

  • How is the contract structured?
  • How does it handle changes in scope (requirements)?
  • How does it apportion Risk and Reward between customer and supplier?
  • What model of customer relationship does it foster: competitive (my win is your loss), cooperative (win-win), indifferent (I don’t care-you lose) or dependent (heads-I-win-tails-you lose)?

This week, let’s look at a number of possible contracts, and see how they work with agile and Scrum development projects:

  1. the "Sprint Contract"
  2. Fixed Price / Fixed Scope
  3. Time and Materials
  4. Time and Materials with Fixed Scope and a Cost Ceiling
  5. Time and Materials with Variable Scope and Cost Ceiling
  6. Phased Development
  7. Bonus / Penalty Clauses
  8. Fixed Profit
  9. “Money for Nothing, Changes for Free”
  10. Joint Ventures

Sprint Contract

Working with Scrum, I have found the metaphor of a “Sprint Contract” to be helpful in understanding (and sometimes enforcing!) the relationship between product owner and implementation team.

Structure: This is not really a commercial contract, but simply the agreement between the Product Owner and the Team for one sprint.

Scope: The implementation team agrees to do its best to deliver an agreed on set of features (scope) to a defined quality standard by the end of the sprint. (Ideally they deliver what they promised, or even a bit more.) The Product Owner agrees not to change his instructions before the end of the Sprint.

Risk: a Scrum project can be considered is a series of mini projects with fixed parameters: Time (Sprint Length), Scope (Sprint Backlog), Quality (Definition of Done) and Cost (Team Size*Sprint Length). Only the scope can vary and this is measured every sprint.

Tip: Confirming Sprint Contract in via E-Mail or posting it on the project Wiki at the beginning of every Sprint is usually good idea. It builds trust, regardless of the underlying contractual form.

Tip: The Sprint contract can be referenced in the commercial contract. I have found that after a couple of releases, the commercial contract can wither down to a one page time & materials agreement, maybe with a cost ceiling for the quarter or next major release.

Fixed Price / Fixed Scope

Structure: Agree on the deliverables, deliver it. Send a bill. Customers like fixed price projects because it gives them security (or at least they think so).

Scope changes: The name says it all, doesn’t it? The change request game (correction: change request process) is intended to limit scope changes. This process is costly, and the changes are usually not preventable. Since the customer almost by definition wants more scope, ending the project can be difficult. The supplier wants the customer to be happy, so the supplier usually yields. The words ‘et cetera’ are very dangerous in the specification of a fixed price requirement.

Risk: Obvious risk is on the side of the supplier. If the estimates are wrong, the project will lose money. Less obvious risks are the change request game, through which the supplier negotiates additional revenue through scope changes. If the supplier had badly underestimated the effort or risk, or quoted an unrealistically low price, the losses can even threaten the existence of the supplier, which also presents a problem to the customer.

Relationship: Competitive to indifferent. Customer generally wants to have more and the supplier wants to do less. The supplier wants the customer to be happy, so usually the supplier yields.

Tip: Specify the functional requirement with user stories. I’ll discuss strategies for hitting the target on a fixed price project in a future article.

Time and Materials

Structure: Work for a month, then send the customer an invoice. Suppliers like it, because the customer carries the risk of changing his mind.

Scope: Not a priori fixed. Sooner or later, the customer doesn’t want to pay any more, so the project comes to an end.

Risks: carried 100% by the client. Supplier has little incentive to keep costs down. Effort to ensure that only legitimate effort and expenses are invoiced can be substantial.

Relationship: Indifferent. The supplier is happy when more work comes because more work means more money.

Tip: recommended for projects where the customer can better manage the risk than the supplier. This is often combined with a cost ceiling. How well it works can depend on how the scope is handled.

Time and Materials with Fixed Scope and a Cost Ceiling

Structure: Same as fixed price, fixed scope, except if the vendor gets finished early, the project costs less, because only actual effort is invoiced.

Scope: Same as fixed price, fixed scope.

Risks: This appears to represent the ‘best of both worlds’ from the customer’s point of view. If it requires less effort than expected, it costs less. But the once the cost ceiling has been achieved, it behaves like a fixed price project.

Relationship: Dependent. From the supplier’s point of view, the goal is to hit the cost ceiling exactly. There is no incentive for the supplier to deliver below the maximum budgeted cost. The customer has probably treated the project internally as a fixed price project, and so has no incentive little renounce scope to save money.

Time and Materials with Variable Scope and Cost Ceiling

Structure: Same as time and materials except a cost ceiling limits the financial risk of the customer.

Scope: Same as a fixed price, fixed scope project.

Risks: the budget will expire without achieving the necessary business value for the customer. Customer won’t get everything he asks for.

Relationship: Cooperative. The combination of limited budget and variable scope focuses both customer and vendor on achieving the desired business value within the available budge.

Tip: From experience, I would say this contract form mixes well with Scrum. The customer has control over each individual sprint. A constructive relationship means that even if problems develop on the way, the emotions are right to come to a mutually agreeable solution.

Phased Development

Structure: Fund quarterly releases and approve additional funds after each successful release.

Scope Changes: Not explicitly defined by the model. Releases are in effect time boxed. The knowledge that there will be another release next quarter makes it easier to accept postponing a feature to achieve the time box.

Risk: Customer’s risk is limited to one quarter’s worth of development costs.

Relationship: Cooperative. Both the customer and the supplier have an incentive that each release be successful, so that additional funding will be approved.

Tips: Venture capitalists often work on this basis. This mixes well with Time and Materials with Variable Scope and a Cost Ceiling. I have worked quite happily under this model. We simply specified the Release goal, hourly rate and cost ceiling in the commercial contract. The customer provided the product owner. Everything else was determined in the sprint contracts.

Bonus / Penalty Clauses

Structure: Supplier receives a bonus if the project completes early and pays a penalty if it arrives late. The amount of bonus or penalty is a function of the delay

Scope Changes: difficult to accept because changes potentially impact the delivery date, which is surely not allowed.

Risk: Does the customer have an incentive for early completion? The ROI arguments must be compelling and transparent. Otherwise the customer gets a cheaper solution the longer it takes.

Relationship: could be cooperative, but might degenerate into indifferent if the customer does not truly need the software by the date agreed.

Tip: Often applied for construction projects, e.g. roads, tunnels and runways, for which it works well. Scope changes are not issue and genuine economic costs drive the customer to achieve the deadline as well.

Fixed Profit

Structure: any project budget consists of effective costs and profit. The parties agree on the profit in advance, e.g. $100,000. Regardless of when the project is completed, the contractor receives the incurred costs plus the agreed profit.

Scope is fixed-

Risk is shared. If project finishes early, the customer pays less, but the supplier still has his profit. If the project exceeds budget, the customer pays more, but the supplier does not earn additional profit. After the target delivery date, the supplier may not invoice any more profit, just cover his costs.

Relationship: Cooperative – both have a clear incentive to finish early. The customer saves money and the supplier has a higher profit margin.

“Money for Nothing, Changes for Free”

Structure: This works with agile software projects because there is little or no work in progress. After each sprint, functionality is either complete or not started. Work is basically on a Time and Materials basis with a cost target, often with the intention that the project should not use up the entire project budget. After a certain amount of functionality has been delivered, the customer should realize that enough business value has been realized that further development is not necessary and can therefore cancel the project. A cancellation fee equal to the remaining profit is due.

Scope: can be changed. Planned but unimplemented features can be replaced with other stories of the same size. Additional features cost extra.

Risk: Shared. Both parties have an interest in completing the project early. Customer has lower costs, supplier has a higher margin.

Tip: If the budget is exceeded, the rules of the fixed profit or cost ceiling contracts can be applied. The fixed profit approach is more consistent with the goal of a fostering a cooperative relationship.

Joint Ventures

Photo courtesy of hydropeek@flickr

Structure: Two partners invest in a product of joint interest. Money is unlikely to flow directly between the partners in the development phase, but each party must have an ROI, which may come from revenue sharing or just benefits from using the software.

Scope: Defined to suit the needs of the partnership.

Risks: Two of everything. Decision chains can get long. Rivalries can develop between the teams. Different models for extracting value from the product can lead to different priorities differing willingness to invest.

Tips: Treat the project as a separate company: One team, co-located, with development and product marketing/product owner role. Think realistically about friendly and not so friendly separation scenarios.

Recommendations

I have worked quite happily for years with a phased development contract. The original contract was a fixed scope contract with a cost ceiling, but as we worked together and built up the level of trust, the surrounding text just withered away. Trust, a bit of boilerplate, the sprint contract and a quarterly sign-off from top management worked quite nicely.

“Money for nothing, changes for free” contract turns the advantages of the Scrum and agile development processes into a competitive advantage.

  • By prioritizing and delivering business value incrementally, the chances of an outright failure are dramatically reduced. This advantage is passed on to the customer.
  • Furthermore, it’s a cooperative model, so it offers incentives to both parties to keep the costs down.
  • The early cancellation clause rewards the higher productivity achieved with Scrum teams. On the down side, this clause feels a bit like a ‘golden parachute’ which may not be politically acceptable in the current economic climate.

This contract might be work with a cost ceiling although I would be wary of losing the cooperative relationship.

The contract form lays the important groundwork for a successful project. And the Agile Manifesto got right: working with the customer is more important than the contract. So whatever you do, keep the customer relationship positive!

Further reading

The value of Big Design up Front

Lets start my first article on AgileSoftwareDevelopment.com with a controversial title. Just to get your attention. You’re still reading? See! It works!

I often see teams, even teams that claim to be doing agile spend several weeks or even months at the start of a project doing requirements, analysis, design and planning. BDUF is a habit many people find hard to give up. Team members instinctively feel there’s something of value in that first stage of a project they’ll lose when they just dive in and start creating software. That value is not in the documentation they deliver, but it’s something they do during those activities that they forget to do later on. Lets look at a typical project to see what people do during that first phase that makes it valuable.

In traditional projects the change in dynamics is often quite obvious. At the start of a project the team has energy. The analyst talks to clients and stakeholders, the architects meet with the developers, managers meet with everyone to make plans and get estimates.

Three months later the situation is quite different. The analysts has moved on to a new project and is only available to the team for a few hours a week. The architects have finished their design documents, the manager only wants status reports, the developers are behind their workstations in crunch mode and the schedule is slowly starting to slip.

The value teams get from the big design phase is not in the documentation like people often seem to think. In fact it’s quite the opposite. The documentation actually causes them to stop doing what made that first phase of the project so energizing. The value is in communication. But as more documentation is written the need for communication seems to be less and less, as communication stops the team is unable to react to setbacks and deadlines start to slip.

This is an important observation to make when you want to make a team like this more agile.

I’m not saying we should just keep doing big design up front, I think this is a wasteful practice. But before dropping it and forcing a team to work iteratively we should look at the value it brings and try to reintroduce that value through other means. Teams have to communicate before they can iterate. This can be done by introducing practices like daily stand-ups, pair programming and getting a customer on the team. Only then will the team be ready to drop big design up front.

Welcome Mendelt

Let me introduce a new permanent contributor to the site. We were lucky to get Mendelt Siebenga on board.

Mendelt Siebenga has been working as a software developer for close to ten years. For the last five years he has been applying practices and ideas from XP, Scrum and Lean in several adverse conditions like in fixed-price projects, teams distributed over several timezones and even during a SOX compliance implementation. Mendelt intends to cover particularly comprehensively the point of view of an agile developer acting as a change agent in a more traditional environment

Please, join me in welcoming Mendelt and take a look at his private blog as well.

Public survey on Agile practices

Jurgen Appelo, a popular blogger and a former regular contributor to AgileSoftwareDevelopment.com is conducting a public survey on which practices people use and which practices are actually be considered to be the Agile ones. The survey consists of several parts, but you are free to take only some of them. Jurgen is known for handling data and calculations carefully so go fill the survey and help us all to understand which practices are actually used and which ones need more attention.

Coping with change on Scrum projects (part II)

Introduction

Interestingly, this week saw a spate of posts dealing with this very topic – although much more specific. In particular, one of the questions raised was “How does a manager add value on a Scrum team?” This segues nicely into this weeks post in which I intended to cover how the management roles (general managers and project managers) are expected to change in an Agile environment.


General Management

Since Agile teams are supposed to be self managing, where does this leave general management, and what are they supposed to be doing. Hopefully the following will give you some food for thought.

#1. Managers should be there to act as a sounding board for the team, especially if the manager has good experience. This will help the teams avoid the obvious gotchas that many teams especially teams new to Agile make.

#2. Managers should be there to help with the heavy lifting. What I mean by that is that they should be assisting the Scrum Master to eliminate “BIG” blockers that require stakeholder involvement.

#3. New teams, especially require support and buy-in from executive management in order for Agile process to take hold. Managers should go to bat for the team to keep them on track. It’s so easy for teams to slip back into their old habbits.

#4. Managers should be their as team coach. Assisting team members with career path planning, doing performance reviews, training or organizing training.

#5. I save the best for last. Managers should be focusing on the longer term strategic initiatives in the company. i.e. figuring out how to deal with competitive threats, increasing sales, reducing costs etc. Managers should be working on defining, the longer term “Epics” and prioritizing them including figuring out the product roadmaps together with the Product Managers.

Project Management

Scrum essentially does away with the traditional Project Management role. So where does that leave these employees. Well most often, Project Managers transition into the role of the Scrum Master. Naturally it makes sense, however great Scrum Masters also come from Development, and QA believe it or not. But trust me, the Scrum Master role is not even vaguely close to that of the Project Manager. So what can you expect as you transition to this role?

#1. For starters, as Scrum Master you have to come to terms with the fact that the Team owns the schedule, so no more updating the good old MS Project Gantts any longer. Instead, you have to sit back and maybe initially prod the team to keep their daily estimates current.

#2. You will need to be responsible for ensuring the Scrum process is followed, that everyone understands Scrum and what is expected.

#3. You will need remove blockers (impediments) as quickly as possible

#4. You will need to ensure the team stays true to the sprint goals defined at the beginning.

#5. You will run the daily scrums, well at least ensure that they’re organized and kept at the same time, same place.

#6. You will run the retrospectives and organize the end of sprint demos

#7. You will need to ensure that the subtleties of Scrum and in particular the inspect and adapt points are taken seriously and used for the manner in which they’re designed. To learn and get better Sprint by Sprint.

This is by no means an exhaustive list. I am sure many of you could add your own flavor to this and in fact I’d encourage you to do so. Looking forward to your comments as always.

Jack

Mendelt Siebenga

Mendelt Siebenga has been working as a software developer for close to ten years. For the last five years he has been applying practices and ideas from XP, Scrum and Lean in several adverse conditions like in fixed-price projects, teams distributed over several timezones and even during a SOX compliance implementation.

Contracting for Agile Software Projects, Part 1

As a customer or supplier of software services at the beginning of a Software Development Project, you know that there is too much at stake to work with just a verbal agreement. Although the Agile Manifesto values customer collaboration above contracts, contracts are necessary when working with external suppliers. A contract is really just a set of written playing rules. The right rules increase the chance of success for both parties. The wrong rules make cooperation difficult and hinder progress. Which contract forms are best for agile software development projects?

This is the first of two articles. In this article, we’ll look at the purpose and contents of a contract and some criteria for evaluating agile contracts. Next week, we’ll look at contracting alternatives for Scrum software projects and examine their strengths and weaknesses.

What is the purpose of a contract?

Contracts set the basic playing rules for the project. In theory, they are freely entered by both parties to create optimal conditions for successfully completing the project. In practice, contracts are often seen as competitive games, in which the objective is to place the other party at a disadvantage, especially if things go badly. Very large companies and governments often have standard conditions which have to be accepted en bloc as a pre-requisite to doing business with them. These conditions are seldom fair, so a reasonable project outcome depends heavily on a good relationship with the actual customer and avoiding recourse to the contract or the law. (The Agile Manifesto is right in this point: customer relationships are more important than written contracts!)

Even negotiated contracts do not always strive for a win-win situation, so you may need the help of experts. However from the customer perspective, contracts produce no added value. They are a waste product, so the effort spent negotiating & producing them should be minimized.

A contract apportions risk and reflects trust between the parties. What happens if something goes wrong? Who pays how much if the project is more difficult than expected? Who benefits if the project is finished earlier than planned?

The wrong playing rules can be detrimental to the success of the project. Bad rules can lead to unrealistic prices, time frames or functional expectations. Win-lose games are detrimental to project success. Quality most often suffers. Do you want the ‘A-Team’ or the ‘B-Team’ working on your project? Think carefully about how much pressure you put on the supplier.

How to evaluate contract forms

Commercial contracts can take many forms. What are the contract alternatives that are suitable for agile development projects? For any contract, I would look at:

  • How is the contract structured? What are the basic rules for delivering scope and invoicing revenue?.
  • How does it apportion Risk and Reward between customer and supplier?
  • How does it handle changes in requirements?
  • What model of customer relationship does it foster: competitive (my win is your loss), cooperative (win-win), indifferent (I don’t care-you lose) or dependent (heads-I-win-tails-you lose)?

If I did not draft the contract, I would also look for traps – contact negotiation can be competitive game. The question is what do you do if you find one? Try to get it taken out, or accept it and move on? Let’s just call this a ‘business decision’.

What information should a contract include?

The more trust that exists between customer and supplier, the less you will need to write down. In my experience, there are a couple of points which belong in every contract:

  1. Objectives of the project and of the cooperation between the companies. This follows pretty directly from the elevator pitch and product mission.
  2. An outline of the project structure – Scrum process, key roles and any differences from Scrum which apply.
  3. Key Personnel – who is responsible at the operational and escalation levels and what is required of these people?
  4. Payment and billing, including any bonus and penalty clauses
  5. Early and normal termination.
  6. “Legal Details.” Depending on local law and legal customs, you may need to limit civil liability, specify venue, ensure severability (that portions of the contract are remain in effect, even if parts of the contract are found invalid) or include other text to prevent various legal bad things from happening. Sample or reference contracts from your jurisdiction can be helpful (and are cheaper than a lawyer!).

Do you need to include the scope in the contract? Often it is present (at least in the government contracts I’ve had the privilege signing, it was included by law), but fixing the contract in scope also renders scope inflexible. If possible, it is better to specify how you will manage the scope (e.g. Product Backlog, Sprint contract), but operational details should be left to the project team.

Points 2, 3, 4 and 5 determine the playing rules for your project. If you get these right, you will have the foundation for a good project. But what are the best rules? There are at least a half dozen different kinds of contract, from time and materials to fixed price, fixed scope.

Next week, I will look at the different contract types and how compatible they are with Scrum and agile projects.

Coping with change on Scrum projects (part I)

Introduction
Most folks don’t like change. I know I don’t. But one things certain, adopting an Agile approach to software development requires much change in an organization. Whether it’s corporate culture, roles or process, as an organization switching to Agile you’re going to have to learn cope with change. This series deals with how various functions in the Agile organization are expected to change in order that teams new to Agile can learn what to expect and better adapt to this new and invigorating environment. This week covers the changes one can expect for the Customer and Product Management function in the Agile organization.


Customers/Stakeholders
With traditional waterfall projects customers are typically at arms length and only engaged at the beginning and end of a project. Nine times out of ten, we (development teams) force customers to “spit it all out” up-front, and we make it quite clear to the customer that any change after the start of a project requires change control processes and penalties. Then after we’re done coding, which can be many months after the start, we hand the code over only to find out that “we got it wrong”. Needless to say this approach is a recipe for disaster and so on Agile projects, customers need to be far more engaged throughout the development process. In fact on Agile projects we actually expect change and welcome customer feedback. And so customers are expected to participate and provide input at all “inspect and adapt” points. This minimizes risk and give customers and stakeholders options.

Product Management

If you’re a Product Manager on a team shifting to Agile, you can expect change too. For starters your title changes from Product Manager to Product owner. But that’s not all. Product Managers in traditional environments are mostly front and back-end loaded as well. Besides their specific marketing duties, Product Managers are typically responsible for the Product Requirements document. I have already spoken at length about the new Product Owner role in a previous blog. Suffice to say, in many situations, the Product Owner is in actual fact the proxy for the customer. Either way, the Product Owner is an active participant. The buck stops squarely with the Product Owner as they become ultimately responsible for the product direction and priorities for a project. Contrary to popular belief, the Product Owner also has deliverables and as a result is requred to avail him/herself to the team at all times. Whether or not the Product owner is at every single Daily Stand-up is debatable but the more engaged the Product owner is throughout, the more chance there is of success. The Product Owner also becomes partly responsible for defining the acceptance test criteria and in this regard they’re somewhat responsible for the quality of the product – especially since these acceptance test criteria allow the development team to build quality in right from the start.

In summary then, as a Customer and/or Product Owner, expect to be more involved day to day. And be prepared to get your hands dirty