1.3: Agile Manifesto - Video Tutorials & Practice Problems

<v ->The advancement of traditional project management</v> and the power of lean thinking made the emergence of agile software delivery only matter of time. Like many great ideas, agile was born out of frustration. In February 2001, 17 software practitioners met at Snowbird Ski Resort in Utah. They went there to ski, but also they wanted to discuss practices in software delivery. They were all frustrated about the inefficiency of software delivery management. In the 1990s, software projects were managed the same way as construction project, which is to say, sequentially. For example, to build a house, you first need to create and finalize designs and blueprints, prepare the construction site, pour the foundation, complete framing, install plumbing, electrical, complete drywall, install exterior, interior, and so forth. You cannot start plumbing until your foundation is complete. The same traditional or waterfall project manager management principles were applied to software delivery phase by phase. It took weeks to write requirements. After those were signed off, the software design phase started, which took several more weeks. Then, the development would start. It would go on for a few months, followed by testing. During testing, bugs were found, which would require a significant amount of rework by developers, and sometimes would even lead to a redesign. When testing was completed, users would get engaged in user acceptance testing and frequently, they would say, "This is not what we envisioned," or, "This is what we wanted a year ago when we started this project, but it is no longer valid." And then, the whole project would have to start from scratch or just got canceled. This was referred as waterfall project management because of the sequential nature: design, development, testing, user testing, and release. But frequently, it meant going back multiple times. The reasoning that those 17 people had was that in software delivery, it should only take hours, if not minutes, to change code, compile if needed, run it, and then review the result. Software delivery is different from house construction, so why should construction rules apply to software delivery? Meanwhile, an average project at that time was measured in years rather than months or even weeks. In some industries, such as aerospace or defense, sometimes it took 10, 15, even 20 years to develop a complex system before it went into production. For example, the Space Shuttle program that was launched in 1982 used information and processing technologies from the 1960s. So, when the waterfall model was widely adopted, alternatives were already emerging. The 17 signatories of The Agile Manifesto had already been experimenting with different frameworks that are now United under so-called agile umbrella. Jeff Sutherland and Ken Schwaber invented the Scrum process in the early 1990s. The term came from the British game of rugby and referred to a team working toward a common goal. Kent Beck developed extreme programming during his work at Chrysler and published his findings in 1999. So this group of 17 practitioners did not challenge tools or techniques. They came together to solve a fundamental problem, which had a root cause in obsolete thinking. To do so, they suggested a new set of values and principles, which they called The Agile Manifesto. They spoke about valuing individuals and interactions over processes and tools. They spoke about valuing working software over comprehensive and frequently unneeded documentation. Some requirements' documents were hundreds of pages long. Who actually read them? Not even the developers who worked on the code. Why should negotiation over hundreds of pages of requirements specification take 30 to 50% of project delivery time if it would just take hours sometimes to build this feature, show it to the customer, and receive their direct and immediate feedback? Why would it take weeks to improve project plans, which became obsolete the moment a new requirement came in, which happens, as we know, in 89 to 93 of all software project, according to the Project Management Institute. As intuitive as it seems now, this was a major, major breakthrough in thinking about software delivery. The Agile Manifesto did not materialize out of thin air. One of the major sources of agile is lean thinking. If we consider the lean framework based on customer value, value stream, continuous improvement, and collaboration, these principles will sound familiar. Working software is the primary measure of progress. Deliver working software frequently from a couple of weeks to a couple of month with preference to the shorter timescale. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Maintain simplicity, the art of maximizing the amount of work not done. Doesn't it remind you the lean concept of waste and avoiding waste? The Agile Manifesto took lean thinking to the next level. It added or emphasized several important components, such as teamwork, self-organizing teams, and focused on end-to-end delivery. The best architectures, requirements, and designs emerge from self-organizing teams. They took the quality concept well-known from lean to the new level. Continuous intention to technical excellence and good design enhances agility. They also put customer in the center of software and delivery rather than as recipient of the end result. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Business people and developers must work together daily throughout the project. They paid a lot of attention to people versus process and face-to-face communication versus documentation. Build projects around motivated individuals. Give them the environment and support that they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a team is face-to-face conversation. So as you can see, Agile Manifesto addresses major challenges of waterfall software delivery. One of them is inconsistent utilization. In waterfall, people were allocating to projects rather than working together continuously as a longstanding team. Allocation usually happened at the beginning of the project, meaning that testers sat idle for weeks until the coding was completed. Even worse, capacity management was done by project. So people were working on multiple projects at a time, linking predictable work management and losing time at contact switching. They were overloaded towards the end of the project, while not being utilized in the beginning of it. That's about agile. Now, how did agile lead to the customer-centric approach to product development?