Bloggo back to the blog
Agile Testing Days – Thursday, Open Space-->
Just over half of the final day was Open Space, as it also had 3 more keynotes.
Isabel Evans had titled her keynote: Becoming Great …(anything): Inspritation, Perspiration, Renewal.
In her humble and inspiring style, Isabel explored what skills are needed to achieve Greatness in general, and what is needed for agile testing.
You need to develop new knowledge and skills to remain relevant – and employed.
Look at the things you are not good at, embrace your fear, and do them anyway!
A skill model was presented that contained broad knowledge, thinking skills such as problem solving and systems thinking, and of course interpersonal skills.
Getting there is a lot of hard work. Self-motivation and perseverance are the keywords there.
Isabel spoke highly of a 19th century book “The Rose and the Ring“, supposedly written for children. The quote she gave was: “The best thing I can wish you is a <little> misfortune”. From that stems inspiration, perspiration, renewal, perseverance, kindness, honesty, and wanting the general good as well as the personal good.
“The secret of discipline is motivation. When a man is sufficiently motivated, discipline will take care of itself.” (Sir Alexander Paterson)
The harder you work, the luckier you get. Self improvement, if I can do it, so can you.
Isabel closed with
1) the second half of the “ Jerusalem” song (inspration after the sad, hard start).
2) repeating a quote from Sir Winston Churchill: “I have nothing to offer but blood, toil, tears, and sweat”.
At the Open Space, I chose to join a group with topics that revolved around the communication and synchronisation in large distributed teams. The group rose to about 20 people, about half of them actually having experience in distributed agile projects.
Points that the group agreed upon:
Having a physical (face-to-face) kick off session is a must, with sufficient represenation from all locations.
Continuous integration must be exercised to the limit of the infrastructure.
Having sprints that are overlapping across the teams is not bad. In a way it makes sense: aligning all sprints would make it hard to attend simultaneous meetings. Members of the business and the supporting organisation would have to clone themselves.
To cater for the endgame that would also be taking place on a continual basis, the term ‘sprint’ had to be clarified somewhat.
One of the best ways to solve a Communication problem, is to create or enhance Visibility. For example, a product owner can probably should have a ‘mission control’ room at each location, where information such as the burndown (plus some explanation) is printed out on adaily basis – from every single team across the project, no matter wehere they are.
A mail group was formed to exchange ideas on this topic after the conference.
As before, the lunch break was an integral part of the conference. I was able to talk with Jennita Andrea shortly before her keynote. Isabel Evans and I reviewed the results from the “alternatives to certification” workshop, hosted by Elisabeth Hendrickson.
Keynote: Andrea Jennita: Reinvigorate your retrospectives
A very brief group exercise highlighted the two most important topics for a Retrospective: observation and change. Key objective: learn to be more observant.
With the people from front row, she played a game of Jenga. The players were careful not to make the tower topple. The idea actually was that the tower would fall, and the debriefing question is asked: whose fault was it? That way, the group can reach the same conclusion: we’re here to learn, not to assign blame.
Andrea explained a model for holding retrospectives, that went much further than the typical 1 or 2 hour session. As such, doing it in full may be more appropriate at the end of a release, rather than each iteration.
Safety, Discover, Analyze, Plan, Close
I expecially liked the start (Safety), which was focussed on identifying individual perspectives, teambuilding, and assuring that all would participate. With those objectives, assigning only 5-10% of the total amount of time actually seems rather low.
Ensuring that all team members would have to speak up in the first few minutes was noted as a goal in itself, as early participation means continual participation.
When establishing team norms, members may write down Collaboration blockers. E.g. I don’t like it when… I am continually interrupted.
This in turn allows other team members to respond with a positive approach, with statements like: In this meeting we allow others to speak without being interrupted. In this meeting we make sure everyone has a chance to speak.
In the Discover stage, it’s all about the big picture. On the timeline, one may start by plotting one’s energy / emotion, as part of a focussed simulation:
Describe what happened
Account for your feelings/actions
Transfer this to the real world
Action plan for change
After describing the Analyze step in some detail, the last two had to be rushed a bit because of the time.
Overall, I got several ideas that could help in future retrospectives,and I am glad that I attended the session. Truth be told however, there was preciously little that was specific to agile testing.
At the planning stage with the group for the Open Space, many people had been nodding and smiling when I proposed a session about having two styles of testing on a single team, and the possible implications of this on matters such as team size, and career paths for testers. I have written and spoken about these topics before, and I have been able to apply this in a few projects.
At the time for my session, only a small group turned up. There was a meaningful discussion, before disdanding to join other sessions.
Later, I found back many of the people who had been nodding and smiling. They had gathered around Michael Bolton in the Speaker’s Lounge, playing a game with dice and numbers as the inputs, and Michael taking the role of the computer. Of course, it had a learning objective, and a debriefing session followed afterwards.
@Ajay Balamurugadas: Michael Bolton spoke highly of your Weekend Testing initiative.
A testing dojo ensued in the lounge, one from which I excused myself to attend the last keynote.Tom Gilb would be the last speaker; especially since we had such a nice chat at the bar the evening before, I didn’t want to be late.
The crowd at that last keynote had been reduced to half of what it was at the start of the day.
The title was very long: How to Evaluate if Requirements Specification are good enough for Testing: the Agile Inspection Process and Numeric Exit.
I was expecting a talk that would be an elaboration of last year, much was actually a repetition, albeit with a slightly different angle.
After asking the audience how they defined ‘Requirements’, Tom Gilb gave his definition, along with the following statement: “Requirements are not required by stakeholders, they need to undergo a process of prioritization.”
‘Requirements’ stand out in the software industry, as there are absolutely no standards for formulating them, and that in a typical software project the requirements are totally inadequate.
Testers can drive the change to get better requirements for everyone to use.
The search for a basic standard for testable requirements led to a re-statement of the 4 rules from last year:
1. clear [enough to test]
2. unambiguous [to the intended readership] // let’s list the readership
3. no unintentional design
4. consistent with itself and all related documentation
5. requirements regarding quality attributes (such as Performance) must be specified quantitatively. (This means that a ‘scale’ must be defined, and a future point on that scale.)
Near the close, Tom referred to the “Testers Bill of Rights“. As testers we may demand better requirements, but of course we need to take a pro-active attitude.
Shortly after this, it was time for rapid close of the conference and a few hasty goodbyes, as it was already past 18h30. In my case, I still had five hours of driving ahead of me.