Fixed-price projects are a challenge to manage when using agile practices, as software teams need the flexibility to change what they are building based on customer need, and that often alters what can be done within a fixed budget. However, there are ways to achieve agility even within a fixed-budget constraint. Here are three ways to make a fixed-price project a win for all parties involved.
Agile isn't something you can adopt through tooling; you have to adhere to the agile principles every step of the way. The top articles from 2018 show that people were looking to improve and refine their agile practices, with popular topics including how to enhance your daily standups, retrospectives, and planning. Check out this roundup for ways to enhance your agile operations.
Agile teams can easily get puzzled by the heated debate happening between advocates for estimation and those in the #NoEstimates camp. However, by comparing how they solve these problems, we can identify many common practices between the two groups and see they are not truly at odds—they actually complement each other. Let's bridge the gap.
Agile projects are ideally a collaborative effort among the team members and with the customers, and the planning process should be a similar endeavor. Everyone should get a clear understanding of the project as well as their respective roles and responsibilities. As the saying goes, well begun is half done. A well-planned kickoff meeting sets the tone for a successful project.
You've heard of a minimum viable product, which has only enough features to create a working model and provide feedback for further development. If you want to get started on a new project quickly, Allan Kelly suggests assembling a minimum viable team—only a few people, with only the necessary skills. They begin work right away, with a small budget and tight feedback loops, driving down risk.
What has agile taught us about trying to plan everything up front? It usually doesn’t work. So why does your company still use a yearly strategic planning approach that takes six months to develop and requires significant time and effort to pivot to new opportunities and challenges? We need to rethink strategic planning to incorporate design thinking, collaboration, and agility.
Many organizations appear to suffer anxiety at the thought of programming. They want to get everyone but the programmers in a room to discuss a project down to the minute and the dollar, without a full understanding of the coding required. But a few hours of code experimentation generates far more understanding than days of debate by architects and analysts. Don't be scared of programming.
Test plans are essential for communicating intent and requirements for testing efforts, but excessive documentation creates confusion—or just goes unread. Try the 5W2H method. The name comes from the seven questions you ask: why, what, where, when, who, how, and how much. That's all you need to provide valuable feedback and develop a sufficient plan of action.
In agile development, a bloated backlog results from teams accumulating huge lists of requirements, usually in the form of user stories. Retaining every possible story for building the product weighs down the backlog while squeezing (or obscuring) the highest-value stories. The best way to help minimize this risk is to optimize the time spent defining and refining the product priorities.
When you're working on a project and are presented with a big story or requirement, resist the urge to treat it as a single piece of work. One of the principles of the Agile Manifesto is to deliver working software frequently. This allows you to learn from what you built and make adjustments. See if you can break down the request and find a small piece of work within the big.