Agile development is not a methodology in itself. It is an umbrella term that describes several agile methodologies. At the signing of the Agile Manifesto in 2001, these methodologies included Scrum, XP, Crystal, FDD, and DSDM. Since then, Lean practices have also emerged as a valuable agile methodology and so are included under the agile development umbrella in the illustration later in this topic.Each agile methodology has a slightly different approach for implementing the core values from the Agile Manifesto, just as many computer languages manifest the core features of object-oriented programming in different ways. A recent survey shows that about 50 percent of agile practitioners say that their team is doing Scrum. Another 20 percent say that they are doing Scrum with XP components. An additional 12 percent say that they are doing XP alone. Because more than 80 percent of agile implementations worldwide are Scrum or XP, MSF for Agile Software Development v5.0 focuses on the core processes and practices of Scrum and XP.Our highest priority is to satisfy the customerthrough early and continuous deliveryof valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
The path to any successful solution is a long and winding road with many challenges along the way. From initial idea to eventual solution the challenges can be numerous and varied. There are many reasons why software projects fail and not all failing reasons are the same. One of the biggest reasons why 44% of projects are challenged relates to two issues:Estimation – Over 50% of projects will cost almost 200% of their original budget. These cost overruns make the whole process problematic and may result in projects being cancelled. Scope Management – Large projects only deliver a little over 40% of features that they originally planned (but that does not mean they have not added more features or spent loads of time on the 60% features they did not deliver writing specs etc..).When you look at the macro level it tends to be associated with value and predictability:Predictability – On top of general estimation providing feedback loops into the process that allow directional changes and make the right decisions is crucial.Value – Building the right software is massive. Most organizations do a very poor job of deciding what software to build and if doing x is more important than y.In terms of engineering issues that make projects fail. Classical problems are:Build quality – Not having a well-defined, predictable build process and instead having a random approach to build management. This causes many problems in terms of quality, with teams unable to answer the question ‘didn’t we fix this’, and operations deploying the wrong software.Integration Hell – When everything is complete at the unit level it is then input into integration and everyone finds everything does not play well together.Analysis paralysis – Consensus is important, but the amount of time thinking, talking and sharing requirements can deeply reduce effectiveness of development.Chinese whispers – with many classical development approaches, artifacts are handed off with very little support collaboration and support. This leads to problems be re-solved and different ideas creeping into the development process. The bigger the artifacts the more likely that is.Of course there are individual issues that if not managed can cause project failure in the areas of architecture and quality. But the majority of those issues manifest themselves in second or third releases. These include:Low Cohesive and High Coupling – at the heart of any poor architecture is bad structure. Regression testing backlog – As you grow the software it becomes more and more expensive and time consuming to test.Poor documentation – the majority of legacy systems are maintained by trial and error, as no one understands them.
Set the stage for Dev is on par with several other stake holders in the enterprise. What are you using today to aggregate and rationalize the data and work flow????
With Visual Studio 2010 the investment in Agile continues. The Agile process template has been improved and now has out-of-the-box tools for Agile teams. This increased level of Agile support means that you can take advantage of best practices including creating and maintaining a Product Backlog, planning iterations with an eye on previous performance—including managing planned interruptions such as holidays and Spikes, and managing status with an Excel based burndown.The new Agile Planning Workbooks enable you to use the most popular tool used by Agile teams and Scrum masters – Microsoft Office Excel. The new Product Backog and Iteration Backlog workbooks enable you to plan your efforts with a light weight easy to use tool that is completely integrated with your team’s repository, Team Foundation Server. As you add user stories to the Product Backlog, they are added as new work items in Team Foundation Server. As you distill stories into tasks, those too are added as new work items in Team Foundation Server. Finally you have light-weight, easy to use Agile planning tools that integrate with Team Foundation Server right out of the box.