In part I of my blog posting on estimating agile projects, I discussed how a prior employer attempted to use waterfall techniques to ensure that customer's projects were delivered on time and on budget. In the end the waterfall project management techniques added a lot of overheard with negligible benefits. Of course this was just one company's experience. Having said that, I worked for several more companies that also used waterfall techniques and those techniques rarely resulted in software projects that were on time and on budget. On the contrary they added a lot of overheard and did little if anything to improve the quality of the software.
Within the last few years agile practices, including Scrum, have become common place in software development. I first used Scrum about seven years ago, and immediately saw the benefits. The focus was on producing usable software, while detailed specs and projects plans were no longer needed. At the time I worked for a company that was producing software that was to be used internally to the organization. We were creating large, complex systems that took months to develop. Most importantly, we were building the project in small increments that allowed the business to immediately use what we developed. While at the onset of the project it was difficult to know how much time was needed to complete all of our systems, the business leaders were happy because we were constantly producing value.
Fast forward a few years and the majority of the companies developing software are using Scrum or some agile variant. The benefits are clear, although there are some tradeoffs as well. In traditional waterfall the entire project is mapped out, from start to finish. While in my experience waterfall projects are rarely on time, there is an attempt to know exactly when the project will finished. Alternatively in Scrum you don't claim to know when a set of features may be finished, beyond the current Sprint. Even then it's accepted that there are enough unknowns that a lot can change in even a two week Sprint. Essentially no guarantees are made.
How does this work for companies that develop software for external customers? Customers want to know how much something will cost them and how long it will take. Of course this is not an unreasonable expectation. At the same time, it's accepted in agile that you simply can't know how long a project will take. There's no attempt to account for everything that will be needed, priorities and scope are accepted as things that can change. Simply put agile practices don't fit with fixed priced, fixed scope projects. (To be fair many companies come up with their own waterfall/agile hybrids that attempt to do this, but there's very few success stories out there.)
So the question remains, as a company wanting to obtain business what do you do? At the time of writing this blog posting there is no commonly excepted answer to this question. The reality is that it's a hotly debated topic and it's a problem that I will attempt to address in this posting. I'm sure that not everyone will agree, but if someone has a better answer I'm all for hearing it.
One of the main ideas behind Scrum is that you constantly create potentially shippable software. Another way to state it, your goal is to constantly deliver software that makes your customer(s) happy. As long as you produce something that they can see, use, and like, chances are they will want you to continue to do what you're doing. If that sounds a little too idealistic, it's because usually it is.
Ultimately building software is a partnership between the technical and those that have the vision for the product. Often a customer might have a rough idea of what they want, but they still need someone to walk them through the process. Essentially this could involve, for a lack of a better word, a lot of hand holding. Even if the customer has very detailed plans, chance are they are not familiar with software development. Someone familiar with product development needs to work with the customer to help bring their vision to life. This can involve white boarding, exercises to capture requirements as user stories, and relating feedback for features that have been delivered. Informally I'd refer to this individual as the Customer Manager.
It's also the Customer Manager's job to help ensure that the project moves forward. Often customers may focus on small details, and forget the bigger picture. While it's ultimately the customer's decision on what to focus on, it's the Customer Manager's job to remind the customer of the key features still remaining and the potential budget spent on reworking a feature. Essentially the Customer Manager is the glue between the technical and the vision. The job is challenging, may result in occasional friction, and is essential to the success of the project.
Of course the customer plays a significant role in the success of the project too. And while a customer has their choice of who they do business with, a company would be wise to also pick and choose the right customers for them. As was stated before, it's a partnership and a unsuccessful partnership will most likely result in an unsuccessful project. While it might be nice to "seal a deal" on a sale without having to consider these factors, the ultimate measure of success is the quality of the product. At best a poor product will result in a dissatisfied customer; at it's worst it can result in a withholding of payment, possible legal action, and a potential hit to your reputation.
Now there's still the topic of convincing a customer that this is the best way to move forward on a project. Essentially you're asking them to trust you, and believe that you have their best interest in mind. Realistically that's a tall order and the topic is simply too large to get into for now, but makes a great topic for a future bog post. All that I'll say for now is that many businesses rely on their reputation and their past successes to instill faith in their customers.
So to reiterate, it's all about managing the customer, their expectations, and most importantly your company's relationship with them. It's a far cry from trying to document every possible detail imaginable ... it's actually closer to being the opposite of that mentality. To put it another way, customer collaboration over contract negotiation.
What are your thoughts? Is this perhaps a bit too idealistic? Regardless of what you think, I'd love to hear your feedback. Until next time.
Within the last few years agile practices, including Scrum, have become common place in software development. I first used Scrum about seven years ago, and immediately saw the benefits. The focus was on producing usable software, while detailed specs and projects plans were no longer needed. At the time I worked for a company that was producing software that was to be used internally to the organization. We were creating large, complex systems that took months to develop. Most importantly, we were building the project in small increments that allowed the business to immediately use what we developed. While at the onset of the project it was difficult to know how much time was needed to complete all of our systems, the business leaders were happy because we were constantly producing value.
Fast forward a few years and the majority of the companies developing software are using Scrum or some agile variant. The benefits are clear, although there are some tradeoffs as well. In traditional waterfall the entire project is mapped out, from start to finish. While in my experience waterfall projects are rarely on time, there is an attempt to know exactly when the project will finished. Alternatively in Scrum you don't claim to know when a set of features may be finished, beyond the current Sprint. Even then it's accepted that there are enough unknowns that a lot can change in even a two week Sprint. Essentially no guarantees are made.
How does this work for companies that develop software for external customers? Customers want to know how much something will cost them and how long it will take. Of course this is not an unreasonable expectation. At the same time, it's accepted in agile that you simply can't know how long a project will take. There's no attempt to account for everything that will be needed, priorities and scope are accepted as things that can change. Simply put agile practices don't fit with fixed priced, fixed scope projects. (To be fair many companies come up with their own waterfall/agile hybrids that attempt to do this, but there's very few success stories out there.)
So the question remains, as a company wanting to obtain business what do you do? At the time of writing this blog posting there is no commonly excepted answer to this question. The reality is that it's a hotly debated topic and it's a problem that I will attempt to address in this posting. I'm sure that not everyone will agree, but if someone has a better answer I'm all for hearing it.
One of the main ideas behind Scrum is that you constantly create potentially shippable software. Another way to state it, your goal is to constantly deliver software that makes your customer(s) happy. As long as you produce something that they can see, use, and like, chances are they will want you to continue to do what you're doing. If that sounds a little too idealistic, it's because usually it is.
Ultimately building software is a partnership between the technical and those that have the vision for the product. Often a customer might have a rough idea of what they want, but they still need someone to walk them through the process. Essentially this could involve, for a lack of a better word, a lot of hand holding. Even if the customer has very detailed plans, chance are they are not familiar with software development. Someone familiar with product development needs to work with the customer to help bring their vision to life. This can involve white boarding, exercises to capture requirements as user stories, and relating feedback for features that have been delivered. Informally I'd refer to this individual as the Customer Manager.
It's also the Customer Manager's job to help ensure that the project moves forward. Often customers may focus on small details, and forget the bigger picture. While it's ultimately the customer's decision on what to focus on, it's the Customer Manager's job to remind the customer of the key features still remaining and the potential budget spent on reworking a feature. Essentially the Customer Manager is the glue between the technical and the vision. The job is challenging, may result in occasional friction, and is essential to the success of the project.
Of course the customer plays a significant role in the success of the project too. And while a customer has their choice of who they do business with, a company would be wise to also pick and choose the right customers for them. As was stated before, it's a partnership and a unsuccessful partnership will most likely result in an unsuccessful project. While it might be nice to "seal a deal" on a sale without having to consider these factors, the ultimate measure of success is the quality of the product. At best a poor product will result in a dissatisfied customer; at it's worst it can result in a withholding of payment, possible legal action, and a potential hit to your reputation.
Now there's still the topic of convincing a customer that this is the best way to move forward on a project. Essentially you're asking them to trust you, and believe that you have their best interest in mind. Realistically that's a tall order and the topic is simply too large to get into for now, but makes a great topic for a future bog post. All that I'll say for now is that many businesses rely on their reputation and their past successes to instill faith in their customers.
So to reiterate, it's all about managing the customer, their expectations, and most importantly your company's relationship with them. It's a far cry from trying to document every possible detail imaginable ... it's actually closer to being the opposite of that mentality. To put it another way, customer collaboration over contract negotiation.
What are your thoughts? Is this perhaps a bit too idealistic? Regardless of what you think, I'd love to hear your feedback. Until next time.
Comments