Daily Digest for December 26th
Sketchnoting
Now, THIS is right up my alley.
I am really getting into visual thinking. Ever since I was introduced to Mindmapping when I was still in Upper Secondary School, I have strived for more creative ways of taking notes, using different colored pens and so on.
This is the same, but at a new, more techie, level.
Rebirth
Well, what did you know, three posts since Friday (four including this one).
No proper blog rebirth is complete without some sacrifices, all my old posts (170+ since the start) has been Drafted (changed from Published to a Draft) which means they are no longer available.
Next step will be some refurnishing of my Pages, and perhaps even a proper facelift. But please, don´t hold your breath.
Release Management and SCRUM
At my company we always have the GONOGO meeting before every release. This is a meeting that is not covered in any SCRUM related article or book that I have read, but somehow I believe some version of it exists at every company, Agile or not.
The meeting is held by the Release Team and includes Managers from every department and the discussion is whether or not the current build of the system is good enough to be deployed in our production environment. Is it a GO or a NO GO?
We suffer from a very common problem in the Agile world, what do we do when a Sprint is finished, and the shippable version is not as thoroughly tested as we would like, and some features just aren´t really Done or Shippable? Let´s put the whole Done discussion aside a bit, we all know that if we live and die by the Done criteria, this would not be a problem, but that is really HARD and what do we do until we nail it?
Todays GONOGO meeting was a bit different. The usual thing is that we dedicate the first couple of days to every new Sprint to fixing those last bugs and maybe adding that feature that wasn't so clear in the User Story or was just missed during the breakdown, and when we feel ready we have the GONOGO meeting and in at least 9 times out of 10 when have a GO and the Release Team starts with the deployment procedure.
But not today. Due to some late additions from two external parties we were still performing tests late in the afternoon and we had four new builds during the day. When the scheduled GONOGO meeting was to be held, we still had not deployed the "final" version in our Test environment, not to mention our Staging environment (we have four environments: Development, Testing, Stageing (a copy of the production environment where we test the installation procedure and look for any problems related to the actual physical environment, and the actual Production environment). Our Product Manager simply said that he felt extremely uncomfortable in sanctioning a release at this point. Test more, work more and get back to me was his answer. But how do we do that? Or SHOULD we need to do that?
The main question I have been thinking about is how to see the meeting from a SCRUM perspective. As I see it, it is not a part of the SCRUM process or the Sprint lifecycle. In perspective of the Sprint, we should have shippable code. Worst case scenario is that none of the functionality from the Sprint is fit for actual deployment, that is part of the Product Owners responsibility, but the product should be shippable. The decision on what to do with the shippable product, deployable or not, fully functional or not, should be taken outside the SCRUM process.
I know what my Agile mentor would say, that we should focus on the Done criteria, and I am not arguing against him. I am just contemplating on what to do until we get there...
Agile Testing books
The last couple of days have been intense to say the least. Trying to keep up to my new work responsibilities with the old ones have kept me busy.
Finished a good session today, where our small team really came through. Felt good!
Go a few books delivered today, where the most anticipated is Agile Testing: A Practical Guide for Testers and Agile Teams which is endorsed by Agile evangelist Mike Cohn. Looking forward to read it, whenever that may be...
Testing, testing
OK, long time no post. Let´s see if we can add some life to this small space...
Since Friday I am acting Test Manager at my work. That´s what you get I guess when you are the IT version of a Swiss knife. Well, perhaps not exactly, but since I am the guy running around fixing things randomly (well, not as random as it may seem), and the former Test Manager leaves the company, the role more or less falls into your lap.
The last years or so I have been working with Agile methodology, SCRUM and Kanban, and with some lessons learned I feel that the Agile thing is actually my thing. So, I would really like to try to take our testing for an Agile spin. The question is, how do I do that? And that is what I think I will start to blog about.
This will hopefully be the story of a journey to Agile Testing Guruhood, where all my brilliant ideas will naturally fall into place, where no programmer will say no to Unit Tests, where there will be plenty of time for the company to provide the staff availability needed to do real life usability tests that actually mean anything.
More likely, there will be frustration, stress and quite a few dead ends. But as always, there will be some enlightenment, and entertainment, along the road. With a bit of luck, the blog might actually fill a hole, and someone somewhere will learn something, and share their own insights. Modest? I think not...
Well, no time to waste, there is a release coming up next Wednesday and I have some testcases to read, and write...
