Self-motivating individuals

One of the most important of Agile principles is to organise projects round self-motivating individuals.  It never ceases to amaze me how well projects can be rescued in this way.  Of course ideally the self-motivated individuals should be there at the start, but sometimes people are far more inspired by solving problems than avoiding them to start with.  Having both skills is difficult as it is more about a state of mind, rather than tangible skill sets.

The phrase that always makes me wince is “I can do more with less code”.  Translates as “I can code fine, until there’s a problem”.   OK, a little brutal, unfortunately the phrase is associated with lazy development (developers).  Modern development langauges provide a lot of helper apps and features that make it quicker and easier to code.  That is not necessarily a bad thing – The concepts of using components over objects, in programming, is part of the evolution.

But it can be done badly. And majorly.  You can’t have developers who only understand their programming environment from component perspective, as issue diagnosis will involve lower level understanding.  Developers like this can uffer from severe copy/paste syndrome which can result in bloated application impossible to maintain. These projects need a re-factoring approach to fix (if project is not just dumped, scapegoat usually being QA or Project Management, never development).

So where do self-motivating individuals come in?  It is probably better to clarify what distinguishes a self-motivated individual.  In a developers, it is being very skilled at coding, very skilled at communicating and drives the team towards his/her way of thinking.  The real trick here is that they can also listen and are prepared to learn themselves.  Too much arrogance is not a positive quality.  It is important for the other developers to push back otherwise your nice Agile team ends up as a dictatorship.  Decisions should be by consensus. A developer of this nature could run the entire project, not optimally, but could get the job done with at the very least, a quality application.

You don’t have to try that hard to organise this setup.  Find that individual and you will find people gravitate towards them naturally.

Scrum Case Study 1

In the most perfect of methodology application, there is always room for improvement. To assume otherwise is misguided over-confidence. Take Scrum, the most used (and abused) of the modern methodologies. The principle, as always is simple – better project management and more control over requirements. It requires more future planning, consitent review pattern, and following through to the development process. It is no good having good project management, if the development teams are not following through with code.

The project was a middleware service providing Always-On email system. Though common now, this was in 2005 so the concept of a true mobile LAN email service was relatively new. The first action was devising a test strategy, which defines the high-level testing scope and testing cycles. Though a middleware service, it still has to be verified for the input and output, i.e. email sent, delivery and verification of content. The company had adopted a system of using real phones and emulators to test email content and user experience. The focus of our testing was on the core application and database, which would pontentially servic a high level of traffic.

The project was working with an efficient Scrum management and Continuous integration process. They were very competent developers and the architectural team also very skilled. But what comes with these talents is overlooking chances for improvements. The end-user experience was paramount in gauging success of the middleware. End to end testing was the most efficient and useful method of testing. I am not there to pointlessly increase scope of testing for financial gain. Consultancy should have morals. What I needed to add to ensure a controlled QA gate for releases, was a test environment, and test framework to provide the external and better overview that QA can provide. The problem I identified to begin with is that they were working in solely Incremental fashion, when Iterative AND Incremental is a better approach to deliver to requirement. People may now at the mention of “milestones”, but when else is a client going to get what they want?

For the essential load testing I chose STAF, an open source load testing framework, driven by xml-based user profiles. This was perfect, as user profiling was very appropriate for email users. The advantage of using open source tools is they act as a kcik-start to what you are actually looking for. Rather than letting the tool dictate what you test and how your test. It some work to get it up to the standard you want, but ultimately more useful and can be included in development cycle. Developers will find them useful also, and more likely to gravitate to open source, over bespoke commercial products.

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.

Can’t see wood for the trees

Business needs to move away from Procrustean solutions approach, which inevitably affect the way projects are managed.

A Procrustean solution is the undesirable practice of tailoring data to fit its container or some other preconceived structure. A common example from the business world is embodied in the notion that no résumé should exceed one page in length.

Look at any job spec, and you will see this attitude. The person writing the job specs generally lists the experience in technologies and processes, that is required for the role. That spec will never be completely fulfilled, as its firstly unrealistic – the equivalent if a very large fishing net. Secondly, you will simply encourage applicants to embellish and customise their real selves to suit what they think you want. That at least can be changed, but we also need to change the way we educate, and the way we currently think. That seems like an even taller order! I can’t directly change the way business operates, but I can change the way I operate, and work on promoting that attitude to others.

Business still leans to the X Theory, assuming that people don’t want to work, therefore have to be actively managed and driven. Well, that does sound like they have given up already. You cannot deny there are elements of truth to the assumption, but it is a sliding scale and having Y Theory approach (assuming that work can be a fulfilling experience) would be provide more inspirational environment, and more working done.

A start-up is generally closer bond naturally (there are fewer people, and and an “all in it together” feel. Also no room for wallflowers, or unproductive people. So almost self-maintaining. I have worked at poor start-ups (usually started by ex-blue chip), where application of blue chip business philosophy creates a very strained environment.

But what is forced by circumstance, is a plot harder to apply in reality. Though we all appreciate the benefits of Kanban, it goes against our fundamental education system. The hardest part to understand is when exactly does the project finish, if management of work can change at any time? Well, that’s where skill comes in – project management are supposed to be managing expectations and have skills in planning. After a long time of Agile projects having project management of vastly differing ability, projects have collapsed or succeeded based on the quality of the developer(s). The crunch is you need skilled people. Methodology or tools never fixes that problem.

You can have happy workers, but they also have to work effectively. Now this is point where I have been harsh on the business world. Changing to the modern styles of development, let alone the way we interacted with business, was hugely underestimated early on. Some coped by just cherry-picking Agile practices that suited their needs, or even just what they understood. what has become apparent over the years, is that Agile development was rarely ever implemented properly. But because it was under the hood, the project management took the blame. Agile salesspeak includes many references to “efficiency”, “speed”, “quality” – words business likes to hear. As with any advert, the product rarely matches the glossy ad. But, to be fair, our brains just weren’t ready and we need to change the way we educate ourselves and others. Its a tall order – but there’s no choice.

37+ and still learning …

After working for 37 companies, I consistently blamed business as main point of weakness on IT projects. But after reading this article, I felt I had slipped into the same generalisations that just plain aren’t helpful. I do believe it is far easier to point out problems rather than solutions (stand up, way too many testers).

Process always sounds so logical, doesn’t it? My origins are from working on step-down projects, where each project stage was completed before moving on (with little chance of going back).   That is perfectly suited to the way we are educated to break down problems into smaller parts. To do things in order, with structure. Resolve the parts and you resolve the whole. Well, that’s the idea. Agile and Lean introduced new concepts around creating fluidity in project stages. Requirements and development could run in parallel (as could testing). It sounds great – but it requires us to battle the education implant – to break down and analyse in sequential chunks.

The current obsession with finding ultimate tools to manage Agile projects shows how far off the point people have gone. Agile has become a money-making exercise, with little relevance to what its (admittedly vague) manifesto was. It wasn’t intended to go global, and struggled with continual addendum to fill the gaps around project management. Agile was after all primarily a development methodology. Common sense tells you that when you have a collection of tasks and bugs to organise, you don’t just timetable at random – some work will be better done in parallel, and some may need to be combined.

There is a lot of project management involved in maintaining Agile effectively, and I mean ongoing and daily! It’s no good if development is Agile, but project management is ineffective (regardless of methodology).

I’ve fallen, and I can’t get up

In so many interviews I have heard that a company is working Agile, accompanied by either hollow laugh or slight look of embarrassment. No finger-pointing is necessary, as the way things were did have to change. And the rough ride that Agile took most people is just an unfortunate stepping stone, in hindsight. Without attention to real agile development or, at the other end of the process, without engaging to client fully in the project management process, you will have a hard time having a successful Agile projects. Of course there are success stories, but usually a result from a lot of learning rather than following a guidebook.

Agile to Lean

Lean is based on the principle of creating true value for the customer and meeting his real, rather than perceived, needs.

I’m getting lazy – too much over-analysis is never a good thing.   Much better to understand the foundations, then let things happen, rather than chasing them down a rabbit hole.  I am talking Agile, of course, and my decade of learning.  Though in hindsight, it is difficult to pinpoint any real point of thought-revolution.  Even now, I think this is different … but the same.  In fact, most software engineering principles outlined decades ago still make a lot of sense. As with anything, it’s about packaging and marketing.

The illusion of the Scrum “safety net” with Kanban

It can take decades for methodologies to fully gain momentum and be understood. Agile was no different, as it’s taken 10 years for people to realise Agile had been misunderstood dramatically. Read that again – “to realise Agile had been misunderstood …”. That means we haven’t even reached point we have addressed the problems fully. But instead of recognising our own failures, there is now murmurs of other methodologies – that points to fact we haven’t learn enough.

It’s behind you

I try not to let anything get to me to much, but I am seeing a repeated pattern when I see managers attempting to deal with Agile process issues. And what is largely discussed and changed is … surprise, project management. Project management side is not usually the issue, but easier for managers to discuss and debate on – but the real problem is likely to be right under your nose, and common area of failure. Why? Because development can still be a very hidden process, sometimes masked by double-talk and hyperbole.

Test Strategy

Designing & Implementing Strategic Test Approach

We bring many years of experience in modern web development, and adept and introducing test processes in most constrictive of projects – integrate testing into your development approach and you will immediately see results across the board. A solid test approach provides a rock in a storm, and can identify weak areas in project management and development failures.