SOGETI UK BLOG

I do a lot of Agile transitions as an Agile coach for management. And in every transition, sooner or later, I find myself in a discussion over ‘mandatory deliverables’; but, is that a discussion? Doesn’t ‘mandatory deliverables’ contradict everything Agile stands for? Aren’t they a relic from ‘desire for control thinking’ by old school management? How could you possibly reconcile this ‘desire for control’ with the Agile ‘team autonomy’?

Before you dismiss me as someone that definitely does not understand Agile and the Agile mindset, let me set the stage where I think the answer may be yes.

Agile teams, however autonomous, do not exist in a vacuum; they are part of an organization that provides them with an environment in which they can flourish. This environment may also instigate some constraints e.g. set by legislation or by internal or external parties i.e. by the European Central Bank (ECB).

Is it really strange when an organisation requires software not only to be tested before deployed into production but also requires that the coverage of the requirements by the test cases is known? How this coverage can be demonstrated may differ from team to team and relates to the team way of working and the technology at hand: is testing automated, is exploratory testing employed, are certain test types (security/penetration test, End-to-End test?) ‘outsourced’ to a separate team, are we talking mainframe development or Cloud development?

But even when we agree on an organisation’s legitimate claims for what to deliver, does that transfer to ‘mandatory deliverables’? Don’t the Agile Manifesto and the 12 principles obstruct that? I don’t think so.

Mandatory deliverables may appear at odds with the Agile Manifesto and several Agile principles, but that’s not an absolute truth.

Let’s examine some a little further:

“Working software over comprehensive documentation”

It states comprehensive not any (as ‘Agile in name only’ practitioners tend to read it). We still document, often and a lot – just not as much as we used to, in the good old Waterfall days. We are very conscious as to what we document, and why, and how. So if we have a sound reason to document, we do, and we document it close to its subject, preferably as an integral part. External, separate documents (Word, PDF, Excel, ..) often are the least favourable form! Self-documenting deliverables (Java code with JavaDoc) or (hyper-)linked documentation are our choice of preference. And let’s not forget the final sentence of the manifesto: “That is, while there is value in the items on the right, we value the items on the left more.” Documentation, even some comprehensive documentation has its value!

“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done”

This principle is often quoted as the basis for a team’s autonomy (“trust them to get the job done”) and by inference the ‘right’ of teams to ignore imposed standards or templates. But there is more to this principle than “trust them to get the job done” it also states “give them the environment and support they need”.

An Agile team can only thrive when the proper preconditions are set – this environment may contain objects that are not self-evidently beneficial or even useful for the team but are of paramount importance to the company as a whole, e.g. guidelines or templates for external compliance. When this is the case, the team cannot invoke their autonomy but must comply for the greater good.

dsc_1024_lowres

“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation”

No argument here, but documentation isn’t always about conveying information! The mandatory deliverables may not bear to team-internal information sharing and the like. They are sometimes required by ‘the environment’ as mentioned earlier and serve a purpose in e.g. the compliance obligations by the organisation.

Let’s not get trapped in the pitfall of categorically dismissing mandatory deliverables in Agile development under any circumstances, without ever giving them a second thought.

Ben Visser AUTHOR:
Ben Visser is a highly experienced test manager and test consultant. In a career of over 15 years as a tester, he has fulfilled a wide range of test functions, from programmer of automated scripts, to test manager of a large international program. He has worked in traditional waterfall developments as a change manager responsible for test and acceptance environments, as well as model-based testing.

Posted in: A testers viewpoint, Agile, Business Intelligence, Cloud, Collaboration, communication, Developers, Digital strategy, Human Interaction Testing, Opinion, Test Environment Management      
Comments: 0
Tags: , , , , , , , , , ,

 

Moving a task on the sprint plan during daily scrum. Scrum is an agile project management method mostly applied to software development projects.

Have you noticed the shift in attitude towards Quality in Agile teams?

To set the stage: I’m a Quality Consultant and I don’t usually participate in an Agile development team. So, not being a member of the team I felt often perceived as ‘pig’ or less: irrelevant at best, a counterproductive nuisance at worst. The prevailing notion was: why waste time paying attention to Quality, when Agile – remember, everybody tests! –  Inherently leads to Quality? Or, to better reflect the Agile mindset: Agile inherently leads to customer value!

Lately, I’ve come across more and more developers that value testers or ‘Quality guys’ in their team, acknowledge our valuable, different perspective. For sure, the aphorisms “Agile fosters Quality” or “Agile equals Customer Value” remain true, but we’ve all experienced that true, 100% Agile – if that exists at all … – is hardly ever accomplished and it’s commonplace that Agile practices need to be combined or synchronized with non-Agile, Linear practices. This can be induced by ‘the business’ through an annual portfolio or budgeting cycle or by ‘IT itself’ through a back-end release cycle that allows for no more than two major release a year. At any rate, Value doesn’t just happen by itself, especially not in an Agile transition that invariably sets off with a hybrid situation that carries both Agile and Linear characteristics. Value must be actively and purposely pursued by all involved.

I’ve always found it very useful to support organizational changes by a catch phrase or logo, something easily remembered that acts as a placeholder for the most relevant concepts and notions.

My catch phrase for Agile transitions is “Value by Design”. It refers to intent, to upfront activities and purposely created artifacts, to not leaving matters to chance, to an array of ‘things’ that you need to do, to create, to think about when you enter a TOP* Agile transition process!

In the weeks to come Hans Lantink and I will post a series of blogs discussing how we implement Value by Design!

* the acronym TOP refers to the fact that any successful change process carries Technological, Organizational and Process-oriented aspects.

 

Ben Visser AUTHOR:
Ben Visser is a highly experienced test manager and test consultant. In a career of over 15 years as a tester, he has fulfilled a wide range of test functions, from programmer of automated scripts, to test manager of a large international program. He has worked in traditional waterfall developments as a change manager responsible for test and acceptance environments, as well as model-based testing.

Posted in: Developers, Infrastructure, Innovation, Quality Assurance, Scrum, User Experience      
Comments: 0
Tags: , , , , ,

 

ModelThree weeks ago, SogetiLabs published the “Innovation in Quality” report (download here) in which Geert Vanhove and I discussed the changing role of the tester. We see that testers develop a second skill set, next to their ‘testing skill set’ and that this second skill set is either IT-oriented or business-oriented. But there is also a third option, a ‘road in the middle’, namely using models more extensively combining the best of both worlds! And for quite some time now I’ve been urging people, testers and business people alike, to start using models. There is so much benefit in them!

ModelTest1Let me first elaborate a little on Model Based Testing, or MBT in short. The core of MBT is generating test cases from models. For this to be possible, a model must be unambiguous and straight forward, to the point that a computer can interpret and process it. A flow diagram (a picture) depicting a process is easily recognized as a model, but pseudo code (pure text!) as a means to define business rules, satisfies the description just as well! Developing models requires an abstract way of thinking, that mostly appeals to ‘techies’: the ‘IT-oriented’ side of MBT. But models also force us to focus on ‘what matters’, leaving out what can be left ignored. This is the ‘business-oriented’ side of MBT.

ModelTest2Still, this ‘best of both worlds’ aspect in itself does not explain the benefit of using models. This benefit follows from the improved feedback capabilities when developing models: discussing 1 or 2 pages of ‘structured text’ in e.g. a use case can be bothersome (is it consistent, complete, correct, …?), 10 pages become really cumbersome and let’s not even think about non-structured text (verbal diarrhea, as someone called it!). But when the contents of a design or analysis is poured into models, anything that violates completeness, consistency, correctness or what have you catches the eye much more easily.

In other words: the title of the blog is a little misleading … by modeling your test, you automatically test your model! The title should be: Model your Test AND Test your Model!

 

Ben Visser AUTHOR:
Ben Visser is a highly experienced test manager and test consultant. In a career of over 15 years as a tester, he has fulfilled a wide range of test functions, from programmer of automated scripts, to test manager of a large international program. He has worked in traditional waterfall developments as a change manager responsible for test and acceptance environments, as well as model-based testing.

Posted in: Innovation, SogetiLabs      
Comments: 0
Tags: , , , , , , , , , ,

 

April-foolsRecently I entered a project that was well underway and I was given an elaborate test plan and some recent progress reports to get up to speed. I’m not a big fan of elaborate test plans. Test plans, especially the elaborate ones, tend to end up at the bottom of a pile of ‘to do documentation’ or in the proverbial bottom drawer. But this time I was pleasantly surprised, because of the way preconditions and assumptions were stated and because they were addressed persistently in the progress reports.

Why did this make me happy? Because they were used to increase the controllability of the project rather than an excuse why certain things might go wrong,… and they’re not to blame.

Have you ever come across preconditions like “the test environment is properly set up and running by April 1st” (pun intended or “enough support is delivered by the supplier”. Never mind the vague ‘properly’ or ‘enough’, what I dislike about these preconditions is the fact that no one is responsible. Test environments don’t mysteriously get up and running by themselves! That requires a lot of hard work, let alone a test environment that does exactly what you need!

So, what made me happy was the explicitly stated responsible party for provisioning the test environment, in concert with the explicit reference to the mail in which the responsible party confirmed the agreement. The progress reports subsequently listed all the preconditions and their actual status as reported back by the responsible. So no surprise if the environment is provisioned one week late, or without a certain interface, or without …. what have you. That will all be anticipated. And it won’t be a surprise either if the environment is provisioned on time with all the trimmings!

So, project managers, client representatives, scrum masters, test managers, … etc.  don’t settle for quick and easy ‘preconditions’ that will only allow for finger pointing and shifting blame, go for meaningful  preconditions that are clear and actionable and have an owner!

Ben Visser AUTHOR:
Ben Visser is a highly experienced test manager and test consultant. In a career of over 15 years as a tester, he has fulfilled a wide range of test functions, from programmer of automated scripts, to test manager of a large international program. He has worked in traditional waterfall developments as a change manager responsible for test and acceptance environments, as well as model-based testing.

Posted in: project management, Test Environment Management, Test Plans      
Comments: 0
Tags: , , , , , , , ,

 

How valuable is thinking about test process improvement in a time and age where Agile is rapidly becoming the dominant mind-set for software development? Are we evolving so fast that an approach towards test process improvement like TPI NEXT®, which was successfully launched in 2009, has become all but obsolete 4 years later? I think not.

Testing is an inextricable part of agile development. It can be done badly, just as it can be done well or even very well (very badly is also possible ;-)).

Every beginning is hard, so when you and your organization set out to practice agile development, you probably won’t get it right on the first time. There is room for (test process) improvement, but how does this ‘improvement room’ relate to existing models like TPI NEXT? Is the basic paradigm of such an ‘old school model’ not waterfall? And by implication unsuited for an agile way of working?

So, can we apply a model like TPI NEXT in an organization that’s turning agile?

The answer is “Hmmm … Yes and No”.

No, in so far that in a truly agile environment focusing on just one aspect of the entire development process is sub-optimizing by default. This applies just as much to testing as to, for example, requirements management or software design. But who dares to state that he or she is working in a “truly agile environment”?!  The crux being ‘environment: are you truly confident that not only you and your development team can act agile, but that the same applies to ‘all the others’ in your organisation?!

So Yes as well, since it provides ideas and guidelines as to what ‘good testing’ means and as to where and how to align agile practices with not-so-agile practices. Indeed, one of the core concepts of TPI NEXT is the Enablers, which pay special attention to the interaction of testing and non-testing activities.

And let’s keep in mind that when you – even for a moment – hesitated to answer the question full heartedly with “No, impossible!” the answer is, at least partly, “Yes”.

Key to this all is the underlying assumption that we want to get better at what we are doing and that we all understand and appreciate the direction we’re collectively heading. In this respect ‘waterfall supporters’ that refuse to follow an organisation’s growth towards agility – or even actively oppose it – are just as undesirable as ‘agile advocates’ with no eye for the ideal pace of an organisation to grow into an agile community.

So, to stay in line with the Agile Manifesto: while there is value in the contradiction, we value the “two sides of a coin” approach more!

Epilogue: having said all the above, I’m very interested in real life cases of struggling with testing and Agile. I would like to call upon you – testers and non-testers, Agile adopters or not (yet) – to share and exchange thoughts on your Agile testing challenges. Be it on this forum or on a more personal note through mail.

Ben Visser AUTHOR:
Ben Visser is a highly experienced test manager and test consultant. In a career of over 15 years as a tester, he has fulfilled a wide range of test functions, from programmer of automated scripts, to test manager of a large international program. He has worked in traditional waterfall developments as a change manager responsible for test and acceptance environments, as well as model-based testing.

Posted in: Agile, Opinion, Software testing      
Comments: 0
Tags: , , , , , , , , , , , ,