docs

SUMMARY.md

@@ -13,4 +13,13 @@
    * [Labels](labels.md)
    * [Planning](planning.md)
 * [Agile Principles](agileprinciples.md)
-
+	* [80% rule](agileprinciples/Pareto.md)
+	* [Change Is Not Bad](agileprinciples/ChangeIsNotBad.md)
+	* [How To Eat An Elephant](agileprinciples/HowToEatAnElephant.md)
+	* [Fast But Not So Furious](agileprinciples/FastButNotFurious.md)
+	* [Done Means DONE!](agileprinciples/DoneIsDone.md)
+	* [Team Empowerement](agileprinciples/TeamEmpowerement.md)
+	* [Agile Requirements](agileprinciples/AgileRequirements.md)
+	* [End User Involvement](agileprinciples/UserInvolved.md)
+	* [Testing Is Not For Dummies](agileprinciples/Testing.md)
+	* [No Place For Snipers](agileprinciples/Collaboration.md)

agileprinciples.md

@@ -1,2 +1,7 @@
-# Agile Principles
+## Agile Principles
+
+We distiled our own list of agile principles, we got lots of inspiration & text from [here](http://www.allaboutagile.com/category/10-key-principles-of-agile/).
+
+Because we are not 100% scrum or 100% kanban not everything is 100% relevant, that is why distilled our own list.
+
 

agileprinciples/AgileRequirements.md

@@ -0,0 +1,26 @@
+## Agile Requirements
+
+Agile development teams capture requirements at a high level.
+
+Agile Development can be mistaken by some as meaning there’s no process; you just make things up as you go along – in other words, JFDI! That approach is not so much Agile but Fragile!
+
+Although Agile Development is much more flexible than more traditional development methodologies, Agile Development does nevertheless have quite a bit of rigour and is based on the fairly structured approach of lean manufacturing as pioneered by Toyota.
+
+We believe Agile Development teams can build better products if they have a reasonably clear idea of the overall requirements before setting out on development, so that incorrect design decisions don’t lead the team down dead ends and also so a sensible investment case can be made to get the project funded.
+
+However any requirements captured at the outset should be captured at a high level. At this stage, requirements should be understood enough to determine the outline scope of the product and produce high level budgetary estimates and no more.
+
+An Agile Development team (including a key user or product owner from the business) visualises requirements in whiteboarding sessions and creates requirements and storyboards (sequences of screen shots, visuals, sketches or wireframes) to show roughly how the solution will look and how the user’s interaction will flow in the solution. There is no lengthy requirements document or specification unless there is an area of complexity that really warrants it. 
+
+This is a big contrast to a common situation where the business owner sends numerous new and changed requirements by email and/or verbally, somehow expecting the new and existing features to still be delivered in the original timeframes. Traditional project teams that don’t control changes can end up with the dreaded scope creep, one of the most common reasons for software development projects to fail.
+
+Agile teams, by contrast, accept change; in fact they expect it. But they manage change by fixing the timescales and trading-off features.
+
+Stories can of course be backed up by documentation as appropriate, but always the principle of agile development is to document the bare minimum amount of information that will allow a feature to be developed.
+
+Using the Scrum agile management practice, requirements (or features or stories, whatever language you prefer to use) are broken down into tasks of no more than 16 hours (i.e. 2 working days) and preferably no more than 8 hours, so progress can be measured objectively on a daily basis.
+
+One thing I think should certainly be adopted from PRINCE2, the very non-agile project management methodology, is the idea of making sure all items are deliverables rather than activities or tasks. You can see a deliverable and “kick the tyres”, in order to judge its quality and completeness. A task you cannot.
+
+original content from [here](http://www.allaboutagile.com/category/10-key-principles-of-agile/)
+

agileprinciples/ChangeIsNotBad.md

@@ -0,0 +1,25 @@
+## Change Is Not Bad
+
+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 or after the software is built. Some organisations quote some impressive statistics designed to frighten users into freezing the scope. The result: It becomes imperative to include everything they can think of – in fact everything they ever dreamed of! And what’s more, it’s all important for the first release, because we all know Phase 2’s are invariably hard to get approved once 80% of the benefits have been realised from Phase 1.
+
+Ironically, users may actually use only a tiny proportion of any software product, perhaps as low as 20% or less, yet many projects start life with a bloated scope. In part, this is because no-one is really sure at the outset which 20% of the product their users will actually use. Equally, even if the requirements are carefully analysed and prioritised, it is impossible to think of everything, things change, and things are understood differently by different people.
+
+Agile Development works on a completely different premise. Agile Development works on the premise that requirements emerge and evolve, and that however much analysis and design you do, this will always be the case because you cannot really know for sure what you want until you see and use the software. And in the time you would have spent analysing and reviewing requirements and designing a solution, external conditions could also have changed.
+
+So if you believe that point – that no-one can really know what the right solution is at the outset when the requirements are written – it’s inherently difficult, perhaps even practically impossible, to build the right solution using a traditional approach to software development.
+
+Traditional projects fight change, with change control processes designed to minimise and resist change wherever possible. By contrast, Agile Development projects accept change; in fact they expect it. Because the only thing that’s certain in life is change.
+
+There are different mechanisms in Agile Development to handle this reality. In Agile Development projects, requirements are allowed to evolve, but the timescale is fixed. So to include a new requirement, or to change a requirement, the user or product owner must remove a comparable amount of work from the project in order to accommodate the change.
+
+This ensures the team can remain focused on the agreed timescale/milestones, and allows the product to evolve into the right solution. It does, however, also pre-suppose that there’s enough non-mandatory features included in the original timeframes to allow these trade-off decisions to occur without fundamentally compromising the end product.
+
+So what does the business expect from its development teams? Deliver the agreed business requirements, on time and within budget, and of course to an acceptable quality. All software development professionals will be well aware that you cannot realistically fix all of these factors and expect to meet expectations. Something must be variable in order for the project to succeed. In Agile Development, it is always the scope (or features of the product) that are variable, not the cost and timescale.
+
+Although the scope of an Agile Development project is variable, it is acknowledged that only a fraction of any product is really used by its users and therefore that not all features of a product are really essential. For this philosophy to work, it’s imperative to start development (dependencies permitting) with the core, highest priority features, making sure they are delivered in the earliest iterations.
+
+Unlike most traditional software development projects, the result is that the business has a fixed budget, based on the resources it can afford to invest in the project, and can make plans based on a launch date that is certain.
+
+original content from [here](http://www.allaboutagile.com/category/10-key-principles-of-agile/)

agileprinciples/Collaboration.md

@@ -0,0 +1,20 @@
+## No Place For Snipers!
+
+Agile development relies on close cooperation and collaboration between all team members and stakeholders.
+
+Agile development principles include keeping requirements and documentation lightweight, and acknowledging that change is a normal and acceptable reality in software development.
+
+This makes close collaboration particularly important to clarify requirements just-in-time and to keep all team members (including the product owner) ‘on the same page’ throughout the development.
+
+You certainly can’t do away with a big spec up-front *and* not have close collaboration. You need one of them that’s for sure. And for so many situations the latter can be more effective and is so much more rewarding for all involved!
+
+In situations where there is or has been tension between the development team and business people, bringing everyone close in an agile development approach is akin to a boxer keeping close to his opponent, so he can’t throw the big punch! :-)
+
+But unlike boxing, the project/product team is working towards a shared goal, creating better teamwork, fostering team spirit, and building stronger, more cooperative relationships.
+
+There are many reasons to consider the adoption of agile development, and in the near future I’m going to outline “10 good reasons to go agile” and explain some of the key business benefits of an agile approach.
+
+If business engagement is an issue for you, that’s one good reason to go agile you shouldn’t ignore.
+
+original content from [here](http://www.allaboutagile.com/category/10-key-principles-of-agile/)
+

agileprinciples/DoneIsDone.md

@@ -0,0 +1,21 @@
+## In agile development, “done” should really mean “DONE!”.
+
+Features developed within an iteration (Milestone in our process), should be 100% complete by the end of the Sprint.
+
+Stories on fixed should be 100% done.
+
+Too often in software development, “done” doesn’t really mean “DONE!”. It doesn’t mean tested. It doesn’t necessarily mean styled. And it certainly doesn’t usually mean accepted by the product owner. It just means developed. THIS IS NOT GOOD!!!
+
+In an ideal situation, each iteration or milestone should lead to a release of the product. Certainly that’s the case on BAU (Business As Usual) changes to existing products. On projects it’s not feasible to do a release after every milestone, however completing each feature in turn enables a very precise view of progress and how far complete the overall project really is or isn’t.
+
+So, in agile development, make sure that each feature is fully developed, tested, styled, and accepted by the product owner before counting it as “DONE!”. And if there’s any doubt about what activities should or shouldn’t be completed within the Sprint for each feature, “DONE!” should mean shippable.
+
+The feature may rely on other features being completed before the product could really be shipped. But the feature on its own merit should be shippable. So if you’re ever unsure if a feature is ‘done enough’, ask one simple question: “Is this feature ready to be shipped?”.
+
+It’s also important to really complete each feature before moving on to the next…
+
+Of course multiple features can be developed in parallel in a team situation. But within the work of each developer, do not move on to a new feature until the last one is shippable. This is important to ensure the overall product is in a shippable state at the end of the Sprint, not in a state where multiple features are 90% complete or untested, as is more usual in traditional development projects.
+
+In agile development, “done” really should mean “DONE!“.
+
+original content from [here](http://www.allaboutagile.com/category/10-key-principles-of-agile/)

agileprinciples/FastButNotFurious.md

@@ -0,0 +1,29 @@
+## Fast But Not So Furious
+
+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 to break what would have traditionally been a project into a list of features, and deliver incrementally on a very regular basis – ideally even feature by feature.
+
+On the web, it’s increasingly accepted for products to be released early (when they’re basic, not when they’re faulty!). Particularly in the Web 2.0 world, it’s a kind of perpetual beta. In this situation, why wouldn’t you want to derive some benefits early? Why wouldn’t you want to hear real user/customer feedback before you build ‘everything’? Why wouldn’t you want to look at your web metrics and see what works, and what doesn’t, before building ‘everything’?
+
+And this is only really possible due to some of the other important principles of agile development. The iterative approach, requirements being lightweight and captured just-in-time, being feature-driven, testing integrated throughout the lifecycle, and so on.
+
+So how frequent is *frequent*?
+
+Scrum says break things into 30 day Sprints. That’s certainly frequent compared to most traditional software development projects. We break things up in milestones which also happen each couple of weeks, it has the same goal as classic scrum.
+
+Consider a major back-office system in a large corporation, with traditional projects of 6-12 months+, and all the implications of a big rollout and potentially training to hundreds of users. 30 days is a bit too frequent I think. The overhead of releasing the software is just too large to be practical on such a regular basis.
+
+30 days is a lifetime!
+
+Competitors won’t wait. Speed-to-market is a significant competitive edge. The value of first-mover advantage is potentially enormous. Whilst it’s not always the case, research shows that those first to market 80% of the time win; and end up clear market leaders.
+
+So how frequent is *frequent enough*?
+
+A regular release cycle also allows you to learn more effectively. Your estimating might be good, it might be bad. Hopefully it’s at least consistent. If you estimate features at a granular level (ideally less than 1 day) and track your velocity (how much of your estimate you actually delivered in each Milestone), in time you’ll begin to understand your *normal* delivery rate. And when you understand this well, you’ll be surprised how predictable you can be.
+
+And let’s face it, managing expectations is really all about predictability. If people know what to expect, they’re generally happy. If they don’t, they’re not happy. Maybe even furious!
+
+So, in agile development, focus on frequent delivery of products. And perhaps even more importantly, focus on consistent delivery of products.
+
+original content from [here](http://www.allaboutagile.com/category/10-key-principles-of-agile/)

agileprinciples/HowToEatAnElephant.md

@@ -0,0 +1,23 @@
+## 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 (we call them milestones which do consist out of X stories).
+
+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 the entire product is fit for release.
+In agile software development, the cycle is Analyse, Develop, Test; Analyse, Develop, Test; and so on… doing each step for each feature, one feature at a time.
+
+Advantages of this iterative approach to software development include:
+
+- Reduced risk: clear visibility of what’s completed to date throughout a project
+- Increased value: delivering some benefits early; being able to release the product whenever it’s deemed good enough, rather than having to wait for all intended features to be ready
+- More flexibility/agility: can choose to change direction or adapt the next iterations based on actually seeing and using the software
+- Better cost management: if, like all-too-many software development projects, you run over budget, some value can still be realised; you don’t have to scrap the whole thing if you run short of funds
+
+For this approach to be practical, each feature must be fully developed, to the extent that it’s ready to be shipped, before moving on.
+
+Another practicality is to make sure features are developed in *priority* order, not necessarily in a logical order by function. Otherwise you could run out of time, having built some of the less important features – as in agile software development, the timescales are fixed.
+
+Building the features of the software ”broad but shallow” is also advisable for the same reason. Only when you’ve completed all your must-have features, move on to the should-haves, and only then move on to the could-haves. Otherwise you can get into a situation where your earlier features are functionally rich, whereas later features of the software are increasingly less sophisticated as time runs out.
+
+Try to keep your product backlog or feature list expressed in terms of use cases, user stories, or features – not technical tasks. Ideally each item on the list should always be something of value to the user, and always deliverables rather than activities so you can ‘kick the tyres’ and judge their completeness, quality and readiness for release.
+
+original content from [here](http://www.allaboutagile.com/category/10-key-principles-of-agile/)