Agile Development: Demystified

Transcription

1 Agile Development: Demystified by Scott Warner Sprint, Agile, Scrum - words we normally associate with sports. Agile Methodology is 1 very much [like ] a sport with a highly-structured, rules-based engagement and a clearly defined definition of victory. Who is this article for? This article is for software development managers, business leaders, IT professionals, and others interested in learning how to leverage the benefits of Agile Software Development whether the full methodology or a subset of the principles is used. What is Agile Development? The Agile Methodology is an approach to software development based on a set of 12 principles according to the Agile Manifesto. The primary goal of Agile is better alignment with customer expectations and faster overall completion. Agile Methodology can be employed with strict adherence to the principles and methods or leveraged in a way that maximizes the benefits and mitigates the risks. A simple way to think about Agile versus traditional sequential development (known as Waterfall ) is that Agile will take the full set of product requirements and choose only the most important features, code and deploy those as a product, get feedback, then continue to choose additional high-value features iteratively until the product is accepted by the customer. Agile vs. Waterfall Agile Methodology Iterative Development 1. Choose Sprint duration; 1-4 weeks usually. 2. Select highest value features that can be done during Sprint (even if coded minimally). 3. Get user feedback with every iteration. 4. Continue iterations with additional features until the Product Owner decides it s ready for market. Integrated Quality Assurance (code testing). Focus on working code as measure of progress. Code and technology is expected to evolve throughout entire project. Waterfall Methodology Linear Development 1. Define complete requirements. 2. Define project as Alpha, Beta, Final release. 3. Assign tasks, track progress against plan. 4. Get user feedback no earlier than Alpha. 5. Project is Released after all requirements coded, tested and documented. QA separated in time typically at end of project. Focus on the project plan as measure of progress. Technology decisions (such as platform, SDKs etc.) are chosen up front and changes are considered problematic. 1 It is left to the reader to decide if Agile is a sport or just similar to one. The author is still thinking about it.

2 What is the single biggest benefit of Agile Methodology? My opinion is that an agile approach allows a company to see working code much sooner than with linear development. This offers many benefits but the main one is that the translation between specifications and code becomes manifest very quickly and technical challenges are uncovered much earlier. What are the benefits of an Agile approach to software development? Teams can start coding much sooner as all code and technology decisions are impermanent. Technical challenges are discovered earlier in the process. Tight integration between all participants on a regular basis keeps things moving quickly. Accountability and transparency are natural as deliverables are days or weeks instead of months. Code quality is not an independent process left to the tail end of a project. The focus is always on working code as opposed to updates in a project plan. There is no separation between the development team and the business folks. Minimal Viable Product (MVP) is a natural outcome. Significantly less effort is expended on writing elegant code with copious comments as it s understood 2 that the code will likely be refactored or completely re-written later in the project( ). Teams make their own adjustments over time to be more effective. Is Agile the best way to get my project coded? Yes and maybe no. All software development projects will benefit from the adoption of at least some of the principles of Agile. The key is to understand which principles and methods are appropriate for your organization and how much change your development team is willing to adopt. But not all projects will benefit from a full-on Agile methodology because this only works if everyone is committed to it and has the discipline to follow through. What is Scrum? It s the framework for managing an Agile development with cross-functional teams with iterations called Sprints. Scrum defines in detail the structure and activities of a software project including roles, responsibilities, how meetings are conducted, work assigned etc. Do I need to hire a Scrum Master? This depends on how far you want to take your Agile Methodology. If you want to employ a strict adherence to all the principles then you will need someone to manage the process. There are many details of Agile development that need constant attention in order for complete adoption to work. 2 This is a very important issue and one that many software engineers resist. Most developers prefer writing a piece of code just once then move on taking great pains (and time) to write clean & elegantly structured code with lots of comments, however, the only way to end up with the highest quality code in the shortest amount of time is to write minimalist code the first iteration and later as the project matures refactor or better yet re write the code based on the new understanding of the requirements. Often, code modules are eliminated from a project being subsumed into another module or the functionality is deemed unnecessary. Developers fear they will not be given the chance to refactor as demands for new functionality are ever present, an agreement should be made at the outset to incorporate this.

3 What are some of the pitfalls of Agile Methodology? The most common issue companies face in adopting Agile is overcoming the resistance to change by everyone involved. Agile development does not allow programmers to spend months working on code before showing results. Further, a good measure of a successful Agile process is that change requests are very welcome - but how many coders want to re-write the code they just got working? The simple truth is that only a subset of software engineers can adapt their coding style to a strict Agile approach. Beyond the dev team, everyone else involved must understand, accept, and contribute to the Agile method. For example, product managers must be able to adapt to getting frequent releases and be able to provide valuable feedback quickly. How do we avoid the pitfalls of Agile? The main thing to understand about Agile is that it is a set of principles that can be modified to adapt to the realities of your project. Agile is not an all-or-nothing methodology. In fact, one of the 12 principles is Simplicity. I suggest that this be utilized as the guiding principle in how you adopt Agile itself. Does a Sprint need to be 2 weeks? No. A Sprint, which is a defined period of development effort that produces a result, is generally from one week to one month. A Sprint can be any length of time and each iteration can be it s own duration. The most common duration is 2 weeks because this is plenty of time for programmers to get a set of new features coded and it creates the opportunity to incorporate changes and feedback frequently which is what drives the quality of the final product. 3 What are the 12 principles of Agile Methodology? I have listed these approximately in order of importance. 1. Working software is delivered frequently. This is the most important principle as it drives everything else. Iterative development means that at the end of each Sprint working code is delivered to the customer (internal, external or both) that has, at least partially, been productized - meaning there is enough there to use/test the code. This generally means that UX design, user documentation, QA etc. are all iterated along with the code. As new features are added, the documentation etc. are iterated as well. A Sprint only works if the functionality chosen is able to be coded and all other expectations are clear to all involved. There are many approaches to determining what will be done for each Sprint but this has to include feedback and acceptance from each coder or things will break down quickly. 2. Simplicity maximizing the work not done. The real principle is that everything should have Occam s Razor applied whenever possible. Simplify then simplify again. Coding tasks are broken down into bite size pieces (requiring less than 8 hours of work) in order to be added to the Sprint backlog. However, even before asking a developer to estimate time required for a task, the task definition should be simplified as much as possible and a value score should be assigned to all features. Trust me, complexity can always be added later. 3 Source:

4 3. Close cooperation between developers and all other stakeholders. This just sounds like; communication is good, but it s really an acknowledgement that developers and business people will often see things differently and this gap needs to be closed with open communication. 4. Changing requirements are welcome at all times. This is a crucial component of good software development - regardless of methodology. It s a simple truth that software meant to be used by humans must evolve over its entire lifespan. Change is good. Uncontrolled change for the sake of change - not so much. Good software development means there is a process in place to assess and include positive change requests on a regular basis. 5. Customer satisfaction is ensured through early and continuous delivery of valuable software. This principle essentially means to gather feedback and involve users as early as possible. This is not always easy to do and can easily lead a project astray if the right customers are not selected. 6. Continuous attention to technical excellence and great design. This principle can be restated as; Perfection is a process, not a goal. An Agile team will review technology decisions, code architecture, code quality, user experience, customer satisfaction, code security, performance and everything else on a fairly regular basis. 7. Best architectures, requirements, and designs emerge from self organizing teams. This principle is essentially a plea for greater autonomy for the development with regards to all technical details. In other words, trust the team to make the right choices and let s all focus on outcomes. 8. Working software is the principal measure of success. This is self explanatory however it misses the point that working can be very subjective and that real success is always determined by the customer. The real message of this principle is that it s a waste of effort to try to measure a developer s contribution to a project in any other way. 9. Projects are built upon motivated and trusted individuals. With a good software development process this principle becomes manifest as unmotivated individuals are spotted quickly. 10. Face to face conversation is the best form of communication. There certainly is value to having people talk (with offshore teams included via video conference) - but verbal communication has its limits so it s necessary to document the results of discussion in a cohesive manner.

5 11. Regularly, the team reflects on how to become more effective and adjusts accordingly. This needs to be done separate from other processes - but it also needs to be a part of each team member s daily activity. 12. Sustainable development, able to maintain a constant pace. This is a fairly complex principle to achieve as there is a natural ebb and flow to development. But the principle is sound as a goal of any good process is that it is ongoing and focus does not wane. This is one of the biggest problems with the traditional Project Plan approach to software development and why so many software projects take much longer than expected. Traditional software development does not have a metric of pace which is integral to agile methodology. What is the best way to get my project done fast? Forget software project plans based on asking developers how long each feature will take to code. The error rate of these estimates are generally > 100% - meaning the actual time will be at least double. But the real problem is that typical project plans attempt to corral and distill far too much complexity, make numerous assumptions and ignore many items that no one can anticipate months in advance. Can we adopt a subset of Agile principles and still benefit? Yes. A full-on Agile process may not be the best first step for a team new to it. Simply by iterating development and adopting the principles over time, most teams will benefit from the process with fewer problems. As one of the Agile Principles states, the team should continually review how to be more effective and this should include adopting more of the principles as organizational buy-in allows. Summary Agile addresses most of the issues experienced with traditional Waterfall development. There are a variety of ways for an existing team to adopt Agile principles but all participants need to be fully on board. It s not a good idea to adopt Agile by edict. Managers need to have a thorough understanding of all the changes required to benefit from Agile as it s a truly cooperative process that some will require time to adjust to. My recommendation for all software product teams is to openly discuss the principles of Agile to discover how to benefit from the approach with the least amount of complexity and overhead. ======================== About Covation Technology We are a software development firm with local project managers and offshore (Ukraine) senior software engineers that specialize in building web and mobile platforms and applications very cost effectively. Visit us at