In the many years that we have been helping our clients, some common questions have been asked about what it’s like to work with an agile software development partner using a Scrum framework. In this article, we explore some of the most important of these questions.
What are the top two benefits of using an agile software development partner for my next project?
The proper use of an agile methodology to develop your software product provides you with these two main benefits:
- Predictability and the power to change the project direction and scope – Software development is a very complex process. Traditional methods of project management don’t work well with software projects because of this complexity. The proper use of an agile framework, like Scrum, gives you the ability to accurately predict the completion of the project. It also gives you the ability to control the direction and scope of the project. By knowing how much effort and time it takes to complete different “user stories” (high level specifications for the features), you have the ability to properly prioritize the user stories and decide when to go to production.
- Accountability and absolute ownership from the development team – The social engineering aspects of Scrum gives the Scrum team absolute ownership of the work that they do. This means that the team decides how much work they can fit into a 2-week sprint. Likewise, the team commits to completing this work by the end of the sprint. The benefit of this approach is that the team has extreme ownership of the work and has great pride in the work that they do. This results in a higher quality of work and higher productivity throughout the sprint.
How would an agile software development partner work with me if I don’t know how agile works?
It is not a requirement to be agile experts to work with an agile software development partner. A quality software partner will educate the client on the agile process as the project proceeds. Many of our clients are not familiar with agile when they hire us. Ascendle is great at teaching the agile principles and folding our clients in easily so they understand the process. A good software development partner will put their clients at ease by teaching the principles throughout the entire process.
Do I have to use agile if I work with an agile software partner?
It is not required for you to use agile, but an understanding of the general agile principles as well as your primary responsibilities are required. As mentioned above, this learning of the agile principles can occur during the project execution.
A basic understanding of the agile principles is important so that you, as the client, know how you fit into the software development process. Working with the product owner to update and prioritize the product backlog defines what work is to be completed and the order it is to be completed in. Attending the sprint reviews and providing feedback on completed work gives the development team the immediate direction necessary to refine their work to match your exact expectations. These two actions are the primary responsibilities of the client and are critical to the success of the project.
How do we define the scope of a project so we know how long it will take and how much it will cost?
Step 1: Identify the Features
When a project is started, we typically start with a “Strategy Phase.” The purpose of this phase is to make sure we fully understand the client’s goals, product, priorities, and business objectives. During this phase, brainstorming meetings are held to build a “dream list” of features. Nothing is held back at this stage. These brainstorming sessions are very important, and it’s best to capture as much information as possible. After these features are captured, we prioritize them into 3 main groups: “Must-Haves,” “Nice to Haves,” and “Someday Maybes”.
Step 2: Estimate the Features
Next we estimate the relative size of each feature, called a user story. After the estimating is complete, you can see how much work it’s going to take to complete all of the user stories in each group. At that point, the stories can be re-prioritized to get the size of the “Must-Haves” group, or the MVP phase of the project, to a size that fits the project schedule and budget. At the end of the Strategy Phase, we will create an estimate of a project completion date based on these size values and a “typical” production speed.
Step 3: Establish Velocity
After the development phase of the project is ongoing, we can establish the true production speed of the development teams, or velocity, typically after 3 sprints. This is the time where we can sharpen our estimate of a completion date range and create an optimistic and a pessimistic completion date for the project. We can then start the discussion of how to adjust the scope of the project to suit the scheduling and budget needs if necessary.
How do I know if a project is on or off track?
I love getting this question because this shows the true power of Scrum. A huge benefit of this framework is the ability to use the history of the team’s previous work, the velocity, to accurately predict how much time it takes to complete future work. Applying the team’s velocity to the remaining user stories in the product backlog can predict the completion date of the project. Of course, the more history there is to pull from, the better the prediction will be. Once a completion date is calculated, you have the power to change that date to suit your needs by adjusting the scope of the project. Following this process, it’s almost impossible for a project to go off track!
While a project is in progress, can I change or add new features? How does this affect the project completion date?
As we all know, things happen and business priorities change. Perhaps you find out that you need some new functionality added to the project to make an important sale. For this case, new features could be added to the product backlog while the development team is working on a sprint. At sprint review, the priority of these new stories should be positioned where they belong in the sorted list of stories in the product backlog. It should also be determined if these new stories should be part of the current release. If so, it can be shown how adding those stories to the release affects the estimated completion time of that release. Is this later date acceptable? If not, it can then be determined what stories should be removed from the release to make the release date when you want. Typically, these would be the lowest priority stories in that release.
This is exactly the reason we review the product backlog on a regular basis with our clients. You are involved in determining the scope of the release and the estimated completion date. There are no surprises at the end of the project.
How will I know that my software development partner is building the right product?
This question brings up another great example of the many benefits of using agile software development. At the end of every 2-week sprint, you will have a sprint review meeting with your development team. During this meeting, they will show you the work that they completed during the sprint. All work that is shown is at a “potentially shippable” state. This means that it has gone through all stages of quality assurance and is ready to be deployed to production.
During the sprint review, you have an opportunity to see the software application come to life. Piece by piece, you are seeing how it is evolving. At any time, if there are some changes you want to make, you can discuss those at the sprint review and shape the design of the product. You also have the ability at this time to completely change course if you see the development team is going in the wrong direction, or business objectives/priorities have shifted. The power of this approach is that you are seeing the product every 2 weeks and always have the reassurance that it is following your vision.
What can I do, as a client, to help achieve our project goals?
There are many things that you can do to help make the project go as smoothly as possible.
- Be fully engaged in the project – Your product owner and technical lead may have questions for you as work is progressing. Be available to answer these questions in a timely manner. It’s also critical to attend the sprint reviews. This is your first chance to see new features and to provide feedback on them. It’s also the time where the next stories to work on are determined. Without your engagement, the project can quickly go off track.
- Identify your value points – Having a clear understanding of the work that gives you the most value is key. We often ask our clients, “If you could do one thing, what would it be?” Having a clear consensus of the priorities ensures that your development team is working on the most important functionality at all times.
- Have the right stakeholders on the project – It’s important that the primary stakeholder representing your interests is the right person. This should be a person with a strong background in the areas that are the most important for that project, be it business or technical in nature.
- Trust your development team by giving up control to the Scrum team – many clients new to Scrum are accustomed to having full control of the development of a project. In order for Scrum to work, the team needs to decide on what work they will complete in each sprint, based on client backlog priorities, and how they will do their work. The stakeholders still have overall control of the direction of the project, but the decisions on how the work is completed are made by the team. For more information on this topic see our article Your Scrum Team is Out of Control and That’s Just How You Want it.
If my software development partner does not deliver on schedule, what’s next?
If the agile principles are followed correctly this situation should be avoided, but things can happen. Some of the development team could get sick, or work is delayed due to outside dependencies. For whatever the reason, a reputable agile software development partner should have a policy in place if they fail to deliver. At Ascendle, we are committed to producing fully-tested, working software, reviewed by you, every two weeks. At the end of any 2-week sprint, if you feel we didn’t deliver business value, we will invite you not to pay for that sprint. That is our guarantee.
