Over the last 10+ years as a Business Analyst, Product Owner & Product Manager in a wide variety of teams, environments, sectors & projects – and, indeed, as a Customer overseeing my own Product development (see flowdaq if you’re interested in that) – it has become clear that Agile philosophies, concepts and techniques do actually work – at least, when appropriately adapted to the circumstances. However, it is also clear that Agile does not suit some scenarios or some projects. Project professionals (hopefully) adapt the Agile techniques that work for their scenario or project and omit those that don’t.
More importantly, however, Agile does not suit some people. Unfortunately, it is often not possible to adapt people who Agile is suited to, or even to ask unsuitable people to adapt Agile ways of working.
Some of you will have heard me mention my ‘other’ work outside of my Business Analysis consulting duties in recent weeks. In fact, some of you might have heard me going on & on about it for years! Well [drum-roll please … this is a real “Water Cooler Moment”]: Flowdaq launched ‘ADAM’ this week at the “WaterCoolers Europe” Trade Show.
ADAM (which stands for Aqua Data Auto Monitor) is an invention designed from the ground up to do one thing: watch the bottles on Water Coolers. Here you can see ADAM at work on the side of an Oasis water cooler (although ADAM is designed to easily fit onto any water cooler).
ADAM actively monitors bottles and tells Distributors, Facilities Managers and Customers when a bottle is used & replaced. In a nutshell, ADAM makes it easy for bottled water Distributors to plan Logistics & Deliveries in the same efficient manner as a Point-of-Sale or Retail supply chain.
I skipped over this particular gem the first 50+ times I had reason to refer to the official #GDPR regulations but, for whatever reason, it jumped out at me this week. I’m curious to hear others’ views. I’m not looking for a definitive Legal interpretation (which can’t happen prior to May anyway!) – just interpretations & views.
This is the text of Article 12.1:
“The controller shall take appropriate measures to provide any information referred to in Articles 13 and 14 and any communication under Articles 15 to 22 and 34 relating to processing to the data subject in a concise, transparent, intelligible and easily accessible form, using clear and plain language, in particular for any information addressed specifically to a child. The information shall be provided in writing, or by other means, including, where appropriate, by electronic means. When requested by the data subject, the information may be provided orally, provided that the identity of the data subject is proven by other means”.
The last part is the bit I’m interested in:
“…the information may be provided orally, provided that the identity of the data subject is proven by other means”
This could/should(?) be interpreted to mean that any information provided orally (e.g. by phone) as a result of a GDPR rights request (e.g, SAR under Article 15), can only be provided orally (e.g. by phone) if identity verification is not carried out orally (e.g. by phone).
In other words, an Organisation cannot orally give me details of information it holds on me if it has orally verified I am who I claim to be.
This seems bizarre, counter-intuitive and unnecessarily restrictive. It also seems to rule out the possibility of automated voice-based Identity Verification leading to subsequent oral provision of data since – even though there is no actual person involved in the Identity Verification process – it is an oral process.
I’m very pleased and proud to have an article commissioned for (90,000-readership) Better Software magazine. My article – ‘Agile Outside the Development Team‘ – is chosen as one of the four ‘featured’ articles and the magazine also includes a wide variety of related material (I’ve been reading it for a few years).
You can subscribe to receive the quarterly magazine – free – or download the latest issue – also free – at the following link and, of course, I’d be happy to read any comments anyone might have on the article so feeel free to comment below…
Those of us involved in evaluating the General Data Protection Regulation (aka GDPR) and advising on how to implement it for different scenarios are well aware of the distinction between “Personal Data” and “Special Category” data and we know that our Clients need to pay special attention to “Special Category” data. However, I have been thinking more and more about scenarios where I might consider recommending Clients treat routine “Personal Data” as if it was “Special Category” data.
Read on for an example to illustrate the point, although there are more examples (and I expect there are many that I haven’t thought of). Dissenting and assenting opinions are welcome so feel free to chime in with your views.
The number of Blog posts, articles and discussions that ask or attempt to explain “How to be a BA” is a good indication that nobody really knows the ‘silver bullet’ answer. If you think you’ll find the perfect answer here…. don’t waste any more time reading on: I don’t have a ‘one size fits all’ answer either!
This is not because nobody actually knows what a Business Analyst is or does (although there are many Recruiters and Hiring Managers who obviously don’t!). It is perhaps because there are so many different types of BA, who do different things, in different roles, for different Projects and in different Organisations.
What makes an MVP an MVP…? Do you prioritize the ‘M’, the ‘V’ or the ‘P’…? Who should be the final judge of what an acceptable MVP looks like?
These might seem like strange questions but, like most things a Business Analyst has to consider, each is a simple question behind which lies a very complicated and very, very important relationship between all Stakeholders on a given Project.
For the record, and to prevent Sports fans having to read any further, MVP in this context stands for Minimum Viable Product, rather than Most Valuable Player!
NB: additional paragraph below marked with * added as a result of feedback.
So, which is more important in a software product development environment: Minimum, Viable or Product…?
The Agile Manifesto is 15 years old now. That’s 15 years… No matter how you look at it, 15 years is a hell of a long time, especially in technology. A lot has happened over the last 15 years in the world of Software, Technology, Information Systems and the Disciplines that support (or supported) these areas.
In February, 2001 (when the Agile Manifesto was published), Google was barely a baby, Windows XP was the new OS kid on the block, Industry had just been through the Y2K hype (look it up), the Dot.Com crash had just happened (look that up, too!), MySpace – the first real, modern, Social Network) was barely an idea, FaceBook and BeBo (don’t bother looking that up) were far in the distant future, as was YouTube and Skype. Twitter, Instagram, SnapChat, Pinterest and WhatsApp were so far into the future of mankind’s imagination that they might as well have been time travel, nanobots or cheap 3D Printing.
It doesn’t matter what your view on the Agile Manifesto actually is and it doesn’t matter whether you think Agile is the solution to all our IT and Software Dev problems (which it isn’t), Agile is – by technology standards – very, very ancient.
Last year, I flew to NYC on business over the 4th July weekend. I rented a car from Dollar (@DollarCars / http://www.dollar.com) well in advance. Literally from the moment of arrival, it was a very frustrating experience, including
a long, long wait for a vehicle (couple of hours, with about 15 people waiting ahead of me when I arrived and no available vehicles);
a demand by the Dollar counter staff to prepay for a full tank of fuel, even though I had Originally made the booking with an agreement to return the vehicle full of fuel;
a vehicle – eventually provided – that was not quite as clean inside as it might have been (probably because of the quick turnaround required);
You know the horror of having to change your password for your email address or some other login…? It is a nightmare to come up with a new password that you’ll remember and that will be strong enough to resist all of the hundreds (thousands?) of different hacks, exploits and attacks happening seemingly every week… So, when you painstakingly choose a new password, it’s only natural that you’ll use the same password (or a minor variant of it) when you later have to reset some other password.
Increasingly, workplace systems that require passwords are set up to force-reset passwords every 30 or 45 days (or whatever). This, of course, means you have to reinvent your password – and it has to be easy to remember yet hard to ‘break’ – every month or two.
Naturally, you don’t write down your passwords. That would be stupid. Instead, you save them in a note or an email, on your phone or on your PC or laptop, maybe synchronised to some public cloud storage provider… After all, who could know that your file call ‘blah.doc‘ contains potentially useful information, and how would they even know where to look…?