Post tweets for you...

So I read a article on Forbes and decided I want to comment.

I decided to login with my twitter account.

I got this.

Now.....

My understanding of this is that Forbes want to use your account, to tweet.  Is that a thing????  I've not noticed it elsewhere.  Or maybe I missed it, which is worrying.

Does the second sentence, part of which reads 'follow new people' mean that Forbes can use your account to follow people?

Also, updating your profile?

Have I been asleep? What's going on?

Read the article, kind of funny considering...

UPDATE: OK not just Forbes. Awesome :/

agile schmagile

Am I the only one bored of 'agile'? It doesn't seem like it.  As far as I can see it's causing confusion and still has bureaucracy issues and can be a right pain in the behind.

There seems to be a number of issues , here are some I’ve picked up on.

1. agile as intent is great* but agile is not defined, there is no one concept, people have their own understanding and this can cause problems because people are trying to achieve different things

* So when I write that 'agile as intent is great' that's my understanding of agile, which probably differs to yours

2. People have pre-conceptions and stick to them

3. People have a cookie cutter approach

4. People try change without help.  It's extremely difficult for a group of people to change their ways, especially if they don't see why things need to change

5. People don't see the bigger picture, 'what am I doing is fine (at least I think it is) so I'm going to keep doing it this way, it's not my problem if there are issues with the team/project/organisation'.  People also try keep a hold of their corner

6. agile is not a silver bullet, agile will cause confusion and uncertainty, all change will and does

 7. There is a huge psychological factor to changing to agile, in all kinds of areas, trust, egos, a change of thinking, etc.  This needs to be taken into consideration. The change in thinking required to 'be agile' will not be for everyone

8. agile and/or change can take time, most people don't like change and uncertainty, people won't 'get it' at first and it can causes scepticism, stubbornness and resistance

9. agile is not about productivity, it's about improvement, productivity will happen by default when you improve

10. Scrum is not agile, it's a project management methodology

11. For most of the organisations that have success with agile it's been hard and took years to get there, realise this

13. There is no one way to 'be agile' it requires trial and error, things will go wrong, mistakes will be made, things will also go right and great improvements will be made

You need to realise this and be able to deal with both scenarios

14. Learn from what others have done and consider that it might not be quite right for you. IE 'that's not a user story, there is no xyx'.  Who cares? Does it work for you? Yes? Great, keeping doing it. No? Tweak it until it does.   If it doesn’t work, ditch it. By the book doesn't always work

15. People hold back because of uncertainty, fear and worry

Re-Regression Checks + Regression testing = Regression testing?!

Sharath recently wrote a blog post to which I decided to write my own post in response.
Sharath's post is here.

Sharath mentioned being slightly confused by BDD and ATDD which I see a lot, however the confusion I see is based on my ideas of what is what, make your own up and decided.

I've included some stuff from Liz as she writes better than me do write as well as my own 2 cents.

ATDD vs. BDD, and a potted history of some related stuff
Acceptance Criteria vs. Scenarios

What is interesting to me though is that as far as I've seen, ATDD doesn't include the business as much as BDD does. I see a lot of Testers and Devs getting together for ATDD and for BDD alot of everybody getting together like PO's, BA's, business people, etc.  That is where I personally see a difference. I prefer BDD and getting as many people as I can involved.
On the other hand, call it whatever name works for you.

Back to Sharath's blog.

One of the things that can (and in my opinion should) be done is that every time a bug/issue is reported automation is written that would find that issue before the issue is fixed - essentially creating a regression/consistency suite/pack/whatever. 
As well as automating any useful information gained from the ET.

I've also tried to use a test points reference (idea from paper by James Lyndsay and Niel van Eeden) with little success, mainly as I didn't push it hard enough.

What I have done is similar to what Sharath has done and created a mind map with areas for further investigation/automation.  Had slightly more success with that.

If you don't have people to automate you can essentially use your regression doc (mind map, doc, whatever it may be) to cover off areas, splitting it between the whole team.

I also try and push the idea of a demo before check in, together we can spot anything obvious before it gets checked in (and therefore a bug/issue).

There is really no one answer, is a case of finding what works for you with the people you have.

I'll be speaking at....and attending....

I'm speaking at Belgium Testing Days with Adrian Rapan about different project scenarios and how we did, wished and would now deal with them.
There will be a lot of awesome stuff going on.

And I'm speaking at CAST 2012 on change. Again there will be a lot of awesome stuff happening.

I'll be attending Lets Test and running/hosting/whatever is needed at a Tester Mega Gathering.

I've booked myself onto Agile Coaching Skills with Rachel Davies. Rachel is one of the authors of Agile Coaching. Course should be fun and is being run through Skillsmatter