- Agile Development Process
- Why use agile development methodology?
- Agile minimizes risk
- Lean Startup = Agile Development
- Agile contracts
- Agile focuses on results and low-hanging fruit
- Agile principles
- Problems with Agile development methodology
- How agile development works
- Fixed price contracts require fixed scope of work and acceptance standards
- inQbation Labs and the agile development process
Agile Development Process
As opposed to the traditional waterfall method of software development, Agile development is about producing the simplest, quickest, most basic website and then rapidly evolving that website based on feedback from real users and their demonstrated needs.
Most organizations try to come up with every possible requirement on their wish list, drop it into a Request for Proposal (RFP), and then require a detailed project plan, crystal ball for the cost estimates, and a complete work breakdown structure (WBS) associated with milestone-driven payments. Agile doesn’t work this way. If this is what your organization needs, please consider the traditional method of web development.
Why use agile development methodology?
The agile development approach is very different from the traditional waterfall model in that the scope of work is not clearly defined up front. The reasons for working in an agile development model are primarily to:
- Produce visible results quickly
- Create a proof-of-concept and early rapid prototype
- Get feedback from the target audience in order to guide future development
- Test different types of functionality and user experiences for best results
- Limit the risk and investment
- Start using the product as soon as possible
- Quickly iterate and evolve the product based on demonstrated user needs
Agile minimizes risk
If you are uncertain if your project is going to be successful or not then an agile approach is the better way to mitigate risk because it allows you to test the concept, get feedback and guidance from target users, and change priorities or direction during the process. You can also cut your losses early if you realize the product has no market feasibility or user demand.
With the traditional waterfall development approach, change orders are discouraged and costly because it requires a significant amount of documentation, clear and specific standards of acceptance, significant amount of time refining estimates, and changes to the contract or task order.
With agile, change is encouraged because it usually means that you have discovered an important requirement that you did not know before – or that a requirement is no longer needed and should not be developed further.
With agile development, you do not wait for the design to be completed until you move onto development. You actually design and develop simultaneously, fostering a form follows function approach to elegant design. You don’t wait until the entire project is over to test the system. You test as you go, train as you go, deploy as you go, and get feedback as you go. If the project ever loses funding or leadership, you will have working legacy software because we only take on as much work as we know we can finish.
Lean Startup = Agile Development
There is a movement going on in the high-tech world called Lean Startup, which is based very much on the needs-driven development approach. With agile development, it is very much a needs-driven approach. We start off with 2 or 3 of the most important needs in the wish list, define them very well, build them, test them, deploy them, and get feedback on them before moving on to the next set of needs. The agile development approach ensures that the project meets current needs.
Agile development emphasizes customer collaboration over contract negotiation.
Agile works on a pure time and materials basis. From a cost perspective, there is uncertainty because the makeup of the team could change from sprint to sprint. Because we don’t have all the requirements up front, it is difficult to estimate the entire project costs in advance or the rate of development. Effective agile development requires total transparency to work.
With the traditional waterfall model of software development, you typically spend months specifying requirements, then months defining the user acceptance test plan, then months developing the code, then months designing the user interface, then months testing the code, and then months debugging the code, etc. By the time you are done, if you the project hasn’t run out of cash, the finished product is often obsolete or fails to meet expectations because end users were not involved in the process and didn’t give their feedback along the way.
Agile development, on the other hand, performs these tasks in parallel. With agile we plan, analyze, design, develop, document, and test simultaneously and iteratively. And, we invite user groups to steer development by being part of the process.
Focus on results and low-hanging fruit
With agile, we deliver products early and often by demonstrating working software and getting acceptance along the way. We document as we go, train as we go, deliver as we go, and get feedback as we go. We use cross-functional teams including designers, developers, usability specialists, business analysts, quality assurance professionals, and team leaders to create a strong fabric of skills and abilities.
Agile development avoids excessive documentation and requirements specifications up front, preferring instead to specify and analyze only enough details to plan the next 2-3 week sprint, while keeping the ultimate road map and wish list set off to the side.
A common misunderstanding about agile is that we don’t document or plan when in fact we tend to invest more time and energy in planning and documenting because the plan is always evolving. We are always revisiting and revising the plan based on the continuous feedback loop we get from our client and the ultimate web visitors.
Being agile means providing a flexible process that anticipates and embraces change, allowing the team to adapt to evolving requirements and unexpected developments or priorities.
- Deliver usable website components early and continuously.
- Welcome changes to scope of work throughout the process.
- Keep sprints short and frequent, preferably in weeks, not months.
- Use cross-functional teams with a variety of business and technical skills.
- Meeting face-to-face meetings or web-conference, at least once a week.
- Provide daily communications and status updates.
Problems with Agile development methodology
The problem is that many people say they want Agile but don’t really understand how it works. Even worse, they don’t have the financial system, procurement system, contract system, or trust required to allow it to work.
How agile development works
The way Agile works is that you have a Product Owner who represents the business unit that is financing the software development. This person has the vision and road map for what the ideal solution might be. Then you have the agile team, or the scrum team. The agile development team has a leader, often called the scrum master. The scrum master works with the product owner to develop and prioritize a wish list of features.
Then, the scrum master works with her developers to take a wild-assed guess, or perhaps educated guesstimates, of how long it will take to satisfy each wish on the list. They use this system of points and iterative debates among various members of the team. Truth is, nobody knows exactly how long it’s going to take to develop any piece of software. It’s always an estimate, it’s never an exact science.
The scrum master works with the Product Owner to define the functional tasks that will be completed during a relatively short sprint. Usually, sprints are a few days to a few weeks in length. Once this sprint is defined, then the teams blow out the details of the requirements, the work breakdown structure, the tasks, dependencies, required skills, and required team to design, develop, test, and deploy this limited set of functional requirements.
Sometimes, a software release may require a few sprints. But, the idea is that you don’t bite off more than you can chew. You don’t invest a lot of time defining, specifying, and analyzing a bunch of requirements that aren’t going to built during the upcoming sprint. And, everything you deliver works such that if you ever run out of funding, at least you’ve got a working set of functionality. You don’t want to, after all, have a half-finished Harley Davidson sitting in your garage taking up space. You either want to ride it or use that garage for other purposes.
Fixed price contracts require fixed scope of work and acceptance standards
For most organizations, they want a guarantee that a laundry list of items and functionality WILL BE DELIVERED as part of the contract and there will be a Firm Fixed Price (FFP) associated with this contract. They want to make sure that everything, including the kitchen sink will be delivered – even if they don’t need a kitchen sink – and that there will be an absolute ceiling in place for costs. Agile doesn’t work this way. It takes a huge amount of trust, faith, and an open mind on the side of the client to allow agile to work properly. If you want FFP contracts, go with the traditional waterfall method.
The thing about Agile is that its purpose is to get a minimum viable product out there working, tested, and being used by people. Then, you get feedback on its usage. Based on how people use it and that feedback loop, the things on your wish list might change. You could re-prioritize, add new things, get rid of things, or change course completely. If the project fails, it will fail fast. You don’t need to waste 3 years and a million dollars to see it fail. You can expedite that process.
inQbation Labs and the Agile Development Process
When we’re not serving clients, we’re in our own R&D lab building products for ourselves. When we do that, we embrace Agile development in its purest form. We believe in Agile and practice Agile. But, we also understand it and accept how it works. We have built, or tried to build, web applications the old fashioned way and have never been successful. But with Agile, we have proven to ourselves that this can be an extraordinarily successful way of managing projects and getting results fast.
Back to the top of Washington DC agile developer