Posts Tagged ‘agile’

I recently attended the regional Scrum Gathering for 2015 in Johannesburg. This is a post in a series on the talks that I attended. All posts are based on the sketch-notes that I took in the sessions.checking

Initially, this talk was called “Automated Testing”. Apparently testing can not be automated because testing implies trying to break things when you don’t know what you’re looking for. The preferred term for when code can automatically check itself is “Automated Checking”.

Joshua had an interesting perspective in terms of a test approach. It’s based on the premise that the most important thing, at the end of the day, is the value delivered to the user and this is where all testing should start. His proposed approach is an outside-in approach:

  1. Identify tests/checks that confirm system behaviour and that the output produced is what the user would expect given the inputs.
  2. Once you have identified these checks (typically at the user interface level) then find the highest level where you can write automated checks without increasing the cost to a point where the cost of automation exceeds its benefits.

He did acknowledge that this kind of outside-in approach will not help one find where things are breaking. However, there are certain other benefits to consider when it comes to high level checks:

Benefits Table of High Level Checks

For those who are strong advocates of Test Driven Design, that did get a mention. Joshua acknowledged that when writing complicated pieces of code where there is a large amount of uncertainty, unit tests could be helpful in finding one’s way. He called these Scaffold Tests and drew the analogy to the scaffolding used when constructing tall buildings. Similarly to scaffolding, remove these tests once they have served their purpose, otherwise they become an unnecessary maintenance overhead.

What is your take on an outside-in rather than inside-out approach to automated checking?

I recently attended the regional Scrum Gathering for 2015 in Johannesburg. This is the first post in a series on the talks that I attended. All posts are based on the sketch-notes that I took in the sessions. Note, this was my first ever attempt at sketch-noting, so be kind!

keynote1

My main take-outs

Our working culture needs to shift

The environment in which organisations need to operate has shifted significantly from the time in which the science on which we base most (if not all) of our organisational and management structures was formed and tested. In those days, the need was for mass production. The demand was greater than what could be produced. For example, when cars were invented, people wanted a car. They didn’t care how many passengers would fit, how many doors it had, or what colour it was. They wanted to be able to afford a car (any car) because their neighbour had one.

Times have changed. The internet is a well-established part of our world and people expect goods to be tailored and customised and that this happens quickly. The environment in which organisations operate is one that is constantly changing. Applying the old sciences, proven with very different outcomes in mind, no longer makes sense. And hasn’t made sense for quite some time!

The new organisation needs to:

  • Have a client and value focus. They need to focus on learning about the product
  • Allow for self-organising and autonomous teams. No more single wringable neck. No more bosses or ‘leads’. People must be encouraged to ask questions and learn from each other.
  • Build things in an iterative and incremental fashion so that they can continuously reduce the risk of building the wrong thing.
  • Strive for excellence, which means striving for continuous improvement.
We are still bad at implementing change
  • Change should be principles focused
  • Change should allow people time to stabilise (how they work) before we try to standardise (how they work)
  • Change should not be about copying and pasting what worked in your pilot team to all of your other teams
    • Context is lost when you do this
    • Teams need to learn for themselves
    • It is better to coach teams through small, incremental changes that give them the opportunity to inspect and adapt
  • Change is not linear

You can find the full slides, video and transcript of the talk here.

What struck you about this topic?

I unfortunately did not attend the Agile Africa conference held recently in Johannesburg, but did follow the various tweets over the two-day duration. The last keynote speaker was Kent Beck, who apparently did a sterling job. Below are some of the key tweets I picked up on from the session as well as a summary sketch note for his speech by the very talented Sam Laing from Growing Agile. I’ve also included a link to a Kent Beck post on pruning as I had no idea what that was when I first encountered the word in Sam’s sketch!

1 2 3 4 Sketch

chasm1I’m currently a member of a coaching circle and our topic last week was “Non co-located or distributed teams”. Then this week someone from our marketing department approached me. We’ve decided to bring our public website in-house and they need a new team, but history has shown us that finding new developers of the calibre we want is no easy feat. One option we haven’t explored to date is developers who work remotely (which would mean we could look farther afield) and he wanted to know what my opinions were. I offered to compile some information for him, including some of the conclusions from my coaching circle discussion, and then figured it was worth adding it to my blog too.

I have worked in distributed teams before – from formal project teams with developers on-site in Cape Town working with off-site analysts, testers and project managers in London; to informal ‘leadership’ teams across offices over three locations and two countries; to performance managing direct reports working in an office 2000 km away. The common point of success or failure every time? The people on the team. The next biggest point of frustration every time? The type and quality of communication tools available.

People

There is a lot of literature out there around the types of behaviours you want in agile team members and, obviously, each company also has its own set of values and culture it looks for in new hires. This list is a list of traits that stood out for me as things that made someone great to collaborate with when working in a distributed fashion. All too often, people without these traits made distributed collaboration quite difficult and sometimes impossible!

  • Emotional maturity – able to communicate without getting emotional about things; can handle openness.
  • Strong team norms – when the team agrees to try something or work in a particular way, this person will take accountability for whatever they have to do even if it wasn’t their preferred way of doing things
  • Effective communication – verbal and written. Can write and read well. Can get their point across and summarise well.
  • Takes responsibility for preparation – if things are distributed beforehand for people to read or prepare, then this work is done. Doesn’t walk into meetings “blind”.
  • Knows how to use tools and knows about conference call etiquette (this could be covered as training for the whole team).
  • Is proactive in staying ‘in the loop’ – will ask questions if they see something that they don’t know about (defaults to information gathering rather than assuming if it was important enough someone would let them know).
  • A T-shaped person – or at least someone who is prepared to do tasks that are not ‘part of their job description’

 

Other Success Factors

This list was compiled by my coaching circle:

  1. Face-to-face is necessary for initial trust building and to create coherence. Where possible, having everyone co-located for a period at the start of the project makes a huge difference. Also gets people used to the way others work without the ‘noise’ of not being co-located.
  2. Would be helpful to find ways to have online virtual interaction (outside of work) e.g. online games/ice breakers/other experiences.
  3. Face-to-face tools are a must.
  4. After an extended period, it helps to have team members ‘rotate’ as traveling ambassadors.
  5. Need to understand cultural differences. Probably worth having a facilitated session to highlight/understand these.
  6. If you have teams working in areas, then have an on-site SM/coach per team.
  7. Keep teams small.
  8. Try pair/collaborate with an offsite person as often as possible.
  9. If you have teams in different locations, have a dedicated facilitator in each location for meetings (like planning, review).

CoherenceCulture

Links

What has your experience been with working in or with distributed teams? What did and did not work for you?

These are some tweets I made while reading “User Story Mapping” by Jeff Patton.

It’s a great read that I highly recommend!

2

How inspirational!

1

 

 

 

 

4

I like this because it can be applied regardless of the type of product you’re delivering or product life-cycle stage you are in.

3

 

5

If you have the book, I’m referring to the picture on page 71

 

 

6

10

A.k.a. an organisational profile

 

789

1

Grooming ideas

 

2

Grooming to envision a product that is valuable, usable and possible to build.

 

 

 

 

 

 

 

 

 

 

3

Grooming to plan your development strategy. Intention is building what you need to learn the most, first.

4

Grooming to plan your next development cycle (sprint).

5

I’ve always struggled a little with the concept of sustainable pace. Most examples are around team burn-out and not having a ‘death march’. I can buy into that kind of work-life balance idea(l) – although humans generally like a little bit of pressure to get things going – but always felt there must be more to it than that. Then I stumbled across this quote in an article:

‘Sustainable pace’ means that speed takes second place to good QA practices that keep technical debt low.

I like that. How do you feel about this statement?

StoriesThis photo is the list of actions/changes/learnings one of my teams came up with in their most recent retrospective. This did not come from someone who went on training or read an article. It also didn’t come from a new Agile coach or Scrum Master. It came from them missing their sprint commitment and goal. This team only managed (on paper) to complete 8 out of 18 points; but they all knew they had delivered and learned a lot more than that measure reflected.  Here are some things that they decided to do going forward:

1. If the team cannot reach consensus about the size of a story, then split it into two stories and size the smaller stories

One of the main reasons the team had such a poor burn-down is that they took in one quite large story which did not quite meet the INVEST requirements. For one, it was a ‘common component’ that was to be used in most of the later stories (so not independent). It also was not small enough – and turned out to be even bigger than the team had thought. During sizing, there had been some debate about its size and eventually reluctant consensus was to make it the smaller size. Turns out the less optimistic team members were right. This was one of the stories that was not done at the end of the sprint.

2. Keep Planning II – and use it to verify the sprint commitment

This is a team that often decides to skip Planning II (I don’t like it, but ultimately it is the team’s decision and so far we’ve muddled along without it). For this sprint, they decided that they did need a session to unpack the stories and how they would be implemented. Everyone agreed that without Planning II we would have been even worse off. They also realised that at the end of Planning II, there were already some red flags that the big story was bigger than everyone had thought and they could have flagged,  at that point, that the commitment for the sprint was optimistic. The team agreed that, in future, if going into the detail during Planning II revealed some mistaken assumptions, then the team would review the sprint commitment with the Product Owner before kicking off the sprint.

3. Feel free to review story-splits in-sprint

Early in the sprint, the team were already aware that the big story was very big and probably could be split into smaller components. Their assumption was that this wasn’t possible once the sprint had started. For me, re-visiting a story split mid-sprint or once you start the work is not a bad thing: sometimes you don’t know everything up-front. It also, in the case where a story is bigger than expected, gives the Product Owner some more wiggle room (negotiation part of INVEST) to drop/keep parts of the story to successfully meet the sprint goal. Of course, where we have got things really wrong, then sometimes the sprint goal cannot be rescued and the sprint would be cancelled.

4. Raise issues as they happen

Pretty much summarises most of the above points. One of the agile principles is responding to change over following a plan, so when change happens make it visible and decide how to adjust the plan at that point. There’s no point in battling on as planned when you know that the planned path is doomed to fail.

Some references: