Kanban/BDD Case Study

The first lesson I had with Behaviour Driven Development (BDD) is that Kanban is ideal project management match. And particularly suitable for re-factoring projects, though prepare yourselves for more admin and management.

The remit was to implement a clearly defined set of new features, into an unknown arena. No developer likes picking up code in such advanced state as there are many possibilities as to what can go wrong. There were no registered open bugs of any note, as but development progressed, issues regularly surfaced at integration point. Here we hit what we realised was accidental Kanban. Because of the unpredictability of re-factoring projects, the development timeline became more fluid and subject to change. Although not generally done as default, I created new feature files in the Specflow BDD tool to cover the bugfix or where possible added or edited a scenario to an existing feature file (a feature file comprises of a user story and one or many scenarios). This meant that the developer fixing the bug could still follow the BDD process.

Exploratory Testing (ET) is much used (and abused) term, but is very valid description of testing done outside of BDD boundaries. However there is no reason that you can’t still keep to the feature file process when devising ET scope. No application is perfect, so the record of no outstanding issues looked likely to be a simple project closure exercise. So I used the ramp of issues closed near project end date as start point and sure enough, found many existing issues. Due to resources these issues were reviewed with harsh eye, only prioritising ones that could not be postponed. For example, one of the first issues found was that weekly newsletter emails were not being sent out, and had accumulated on mailbox server.

Security testing was not considered in the original project work, but with any website I believe is performing standard checks for security to highlight the more common XSS-scripting and SQL Injection vulnerabilities. It is surprisingly how many developers leave basic holes such a password field autocomplete set active. Security testing can go to real depths, but you can catch most hackers out with basic tests using specific lightweight tools. Remember, most hackers are amateurs.

Kanban provided a dynamic way to manage Work in Progress, which is at Kanban core. The idea is the keep your Kanban board well weighted, with work spread out to resources evenly and identifying the cross-functional elements of the team. Due to my overall experience I was able to offer consultancy on improvements from Kanban perspective. Scrum is iterative in approach, but Kanban is Iterative AND Incremental – managing the parts and the whole. More challenging from management perspective, but extremely effective at gelling a team.


BDD – Behaviour Driven Development is a set of practices which help software development teams to have conversations about the behaviour of their system and how it delivers value to the project stakeholders. BDD has changed from its early roots as a replacement to TDD and now works as a mini-methodology across the whole software lifecycle. Over the last few years the adoption of BDD has grown globally, with dozens of tools created, used by hundreds of projects around the world. In this talk we look at the original reasons behind the creation of BDD, bringing the focus away from the tools and back to its purpose and the philosophies which support it, including Real Options, Deliberate Discovery and Feature Injection.

Funky tester

People getting into testing now, are having an easier job – not least because there is a lot more discussion and information around the benefits of testing. And a general acceptance that testing has lagged behind modern development approaches, to extent it was covered in other ways. Continue reading

Using the Agile skeleton

Agile provides a skeleton set of rules that you can apply to any other Agile-related methodology – apply them with iron fist, then allow projects to define their own variations, especially at development level. These rules are:-

  • Full-Time ScrumMaster Identified and Team Members Available to Do Work
  • Team Agrees to Demonstrate Working Software in No More Than 30 Days
  • Stakeholders Invited to Demonstration

That is pretty loose, but get to grips with fundamentals of project team structure, and what is expected high-level, it’s a good start to developing your own Agile approach. Don’t forget, no methodology takes account of company culture, human resources or budget constrictions. Follow Agile to the letter, and it could prove very costly for you, without adding much comparative benefit.

The ScrumMaster role is a vital role, as it is he/she that keeps development on track with user stories, and is first point of contact for the business. This role is a common area of weakness – if you omit the role altogether, then you will simply have a Waterfall project (driven, as it would be, by the Product Owner). Product Owner thinks in terms of milestones, as they will have a stakeholder breathing down their neck. The Scrummaster brings some order to the input/output of requirements.

The team members include everyone that drives the daily SDLC, i.e. developers and testers. They may or may not be applying Agile software development method, but any Agile-friendly method is OK to use – best fit for the team and company. Length of Sprints is flexible and driven by realistic vision of what is possible given resources. 2 weeks is a common choice, which is sensible. A broad guide is to assume you need same amount of testing time and development time. 1 week Sprints can work, but difficult to sustain without sizeable team.

It is often stated that Agile is intended for smaller projects, and indeed SCRUM is very specific on this (ideal team size 7-12). This is a recognition that Agile was primarily for smaller projects. But if your project is large and complex, you can still apply the Agile skeleton rule, and choose a longer (and some would say more traditional) monthly release cycle. Corporation generally adopt this approach, largely because corporations are a slower machine. It doesn’t matter how dynamic or Agile your development team is. If stakeholders are rarely available, your project will slow up accordingly, as Agile assumes continual stakeholder contribution to the process.

Startup companies can adopt Agile more fully, as they have a lot more at stake for project delivery. No project, no funding, no company. So they can afford a more aggressive implementation of Agile, and SCRUM is ideal for an average startup structure. For s start everyone is usually in same building, if not on same floor. Interaction between employees is far more frequent, and feedback is very fast, up and down the chain. I have often thought the way corporations should be thinking is of each project as its own company, rather than attempting a corporation-wide strategy. While one project may suit Agile for software development method, another may be better using kanban (which is more developer-centric). Project methodology should be judged per project.

That’s not to say you cannot have an overall Agile strategy in a corporation – just adopt the Agile skeleton as the high-level framework. Then work out the development method to follow – taking parts of several methods, if appropriate.



The reason sleep has been a memory 😉 but nothing like a baby to get you evaluating whats important, and where you are going in life. Keeping it together with exercise, and not losing sight of long-term dreams – that’s my way anyhow. He arrived in the world 7 weeks earlier, and 3 months on all the early drama seems a long time ago. But that would make sense, as days with babies and children are always seem a lot longer to them – a day is an eternity. So I curse sometimes how the work week seems to be longer and drawn out, then I remember why – i am trapped in a baby’s timezone, which is not so bad a place to be 🙂

Words to inspire UX designers

A great site I use but I get too bogged down in the business and technical sides of design.  However we like to portray the web, it is a succession of linked documents, and how they look is every bit as important as the functionality underneath.  Good design doesnt have to be a work of art, but it must be intuitive and guide/help the user.

Gallery Slideshow | inspireUX – words to inspire user experience designers

Bluehoo – friends you bever knew you wanted


Up to now my only experience of bluetooth, outside of file transfer or wifi, was fending off numerous virus attempts.  I am sure there have been efforts before, but found this little app for social networking using bluetooth.  A simple enough service – just download software to your (probably already burgeoning!) mobile, and then you are enabled you to communicate with other Bluehoo users.

My biggest bugbear with these type of ideas is in order for it to work, everyone has to download the software.  Does this then preclude me from other mobile social networks, purely the software doesnt work that way?  As usual social networking applications are anything but – the “walled garden” approach to social networking is sadly still prevalent.

Surely applications that are portable and flexible are way forward.