Agile development is all about frequent delivery of products. In a truly agile world, gone are the days of the 12 month project. In an agile world, a 3-6 month project is strategic! Nowhere is this more true than on the web. The web is a fast moving place. And with the luxury of centrally hosted solutions, there’s every opportunity
How do you eat an elephant? One bite at a time! Likewise, agile development projects are delivered in small bite-sized pieces, delivering small, incremental *releases* and iterating. In more traditional software development projects, the (simplified) lifecycle is Analyse, Develop, Test – first gathering all known requirements for the whole product, then developing all elements of the software, then testing that
One of the key agile principles is about fixing timescales and varying scope. In DSDM (Dynamic Systems Development Methodology) these iterations are called Timeboxes; in Scrum agile management practice they are called Sprints. For Business-As-Usual (BAU) changes to existing products, one Sprint may equal a release of the product. However for projects it’s more than likely multiple Sprints will be
In the more traditional world of managing software development projects, it is widely acknowledged that developers can’t test for toffee! Yet agile development methods increasingly seem to require or imply that all people in the project team should test, including developers. So, first of all, why is it that developers can’t test? Are we to believe that these highly intelligent
In my experience, some people implement agile principles within the development team itself, but leave other key roles (for instance business users or testers) out of, or on the fringes, of the agile team. Earlier in my blog I wrote that active user involvement is imperative in agile development for a wide variety of reasons. It’s just as important for
Agile development teams capture requirements at a high level and on a piecemeal basis, just-in-time for each feature to be developed. Agile requirements are ideally visual and should be barely sufficient, i.e. the absolute minimum required to enable development and testing to proceed with reasonable efficiency. The rationale for this is to minimise the time spent on anything that doesn’t
XP (eXtreme Programming) advocates Test Driven Development, where test cases are written before the code. Radical, huh? If you think about it, it makes complete sense. Assuming you are planning to write test cases anyway, it’s no more effort than writing them later. And the big advantage of writing them first? If you know how you’re going to test it,
In agile development the timescale is fixed. So one thing you can be absolutely sure about, is that it’ll deliver on time! The question in agile development is the other way up – how can I be sure enough features will be delivered to achieve the objectives and realise the benefits? And the truth is, that’s still a really tough
What do you do if someone in your agile development team is simply not playing ball? Particularly if their behaviour is counter-productive to the key principles of agile development and is affecting the team’s performance. One comment I’ve heard (not at my organisation by the way) was to apply the self-organised nature of Scrum and allow the team to raise
In agile development, requirements evolve, but timescales are fixed. This is in stark contrast to a traditional development project, where one of the earliest goals is to capture all known requirements and baseline the scope so that any other changes are subject to change control. Traditionally, users are educated that it’s much more expensive to change or add requirements during
In my experience, most developers are over-optimistic and tend to under-estimate. However it’s not uncommon for some teams to estimate on the cautious side. If you find yourself in this situation and finishing the Sprint (or timebox) early, include a couple of nice-to-have “stretch tasks” (or features/stories) in future Sprints. It’s important to specifically identify them as stretch tasks, i.e.
An agile development team must include all the necessary team members to make decisions, and make them on a timely basis. Active user involvement is one of the key principles to enable this, so the user or user representative from the business must be closely involved on a daily basis. The project team must be empowered to make decisions in
Search the Blog
What am I interested in?
Agile Management Made Easy!
All About Agile
By Kelly Waters
“’Agile’ is one of the biggest buzzwords of the last decade. Agile methods often come across as rather more complicated than they really are. This book is an attempt to unravel that complexity. To simplify the concepts. This book breaks the concepts into small bite-sized pieces that are easy to understand and easy to implement and delivers the message in a friendly and conversational style. Allaboutagile.com is one of the most popular blogs about agile on the web. ”
Agile 101 is available to purchase. GAME ON!