I recently attended the regional Scrum Gathering for 2016 in Cape Town. 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. 

A lot of this talk was a repeat of things I’ve heard before:

  • Efficient feedback increases effectiveness
  • We need to build things to learn things through measuring
  • We need to start with understanding user needs
  • When we define a problem, we’re usually guessing, so we need to validate our guesswork (through feedback loops) as quickly as we can

A wicked problem is a problem that one can only fully understand or define once one has found the solution to the problem. Software in a wicked problem: when we find the solution (note: find not build), then we can usually answer what the problem actually was.

One of the new ideas for me from this talk was the #ConstructionMetaphorMustFall idea. Traditional engineering models treat coding as part of the build process, however Jacques argued that code should actually be treated as a design document and that writing code actually forms part of the creative design process. The code equivalent of bricks and mortar is actually only the conversion of code to bits together with the (hopefully automated) checking process i.e. when we release. In this model, things like Continuous Integration and Continuous Deployment are actually design enablers: they allow us to test our theories and verify our design through feedback.

Shifting your mindset to view writing code as part of the experimental design process rather than execution of a final plan/design would probably lead to a paradigm shift in other areas too. I’ve been saying for a while that, as software tooling improves and more “routine” activities become automated, writing software is becoming less of a scientific engineering field and more of a creative field.

What are your thoughts on shifting the “coding” activity out of the build phase and into the design phase? What does this mean for how we should be thinking about code and feedback?

Recommended reading: SPRINT

I recently attended the regional Scrum Gathering for 2016 in Cape Town. 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. 

As we’re also looking to move a very complicated, fragile system over to a new technology stack, I found this talk by @NigelBasel quite interesting. One of the most interesting parts was his application of Conway’s Law to the problem: the software had evolved and modeled when there were only a handful of developers working on the system; and now it needed to change to model the communication structures required between a number of teams working on the same codebase. He also showed us the output from a really cool tool (I think) called Gource which he’d used to model changes in their source code repository over time. Made me wish I could see the same animation for ours! I’m sure it would be fascinating!

Nigel gave a suggestion of two steps one could take when faced with this legacy code-wool problem:

  1. Stop digging (yourself into the hole)
  2. Get out of the hole (carefully)

They’re still progressing on their journey, but these are the steps they’ve taken so far to try and bring their code base back under control:

  1. They identified and fixed any coincidental cohesion – they moved parts of code which logically belonged together and just happened to be where they were because they were written into things like libraries and services.
  2. They shifted their thinking of layers to services and considered things like whether certain services like authentication be provided by 3rd party tools and removed from their code base. If a service seemed to make sense, they created it and then migrated functions as they were needed, thereby “starving” the old code base.
  3. The considered their code base in terms of business features and the data required and tried to group these together
  4. They write all their new code using their new strategy (as far as possible)

One issue Nigel admitted that they haven’t really got to grips with yet was version control. He emphasised that their journey is not yet done. I’m hoping we will hear more about their adventures and learnings once they have traveled their path. Did you find any of these points helpful? Do you have experience changing old code to reflect new organisational communication patterns?

#SGZA 2016: “Just Right”

Posted: November 17, 2016 in Agile, Team
Tags: , , , ,

I recently attended the regional Scrum Gathering for 2016 in Cape Town. 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. 

Danie Roux gave an entertaining opening keynote which started off with a re-telling of the well-known fairy tale: Goldilocks and the Three Bears. We also touched on the adventures of Cinderella (and her glass slipper) and the Hunchback of Notre Dame during the talk. Danie challenged us to consider the modern versions of the fairy tales (Shu) against the logic they contained (Ha – or huh?) and their actual origins in history (Ri). Besides some fascinating facts about the origins of some fairy tales, other take-outs from his talk were:

  1. Perspective matters.
  2. Roles are meaningless on their own – they need to be considered in the context of a relationship.
  3. A cadence is a pause. Pauses between notes create music.
  4. The three hardest things to get a team to do are: (1) Talk (2) Talk to each other; and (3) Talk to each other about work.
  5. The definition of ScrumBut: (ScrumBut)(Reason)(Workaround)
    1. Translation: When we say Scrum But we usually go “this is what Scrum would recommend”, “but this is why it won’t work for us”, “so this is what we’ll do instead”
    2. Perhaps we should try for Scrum And?

Finally, he told us the story of his friend and the glass Sable antelope… As a reminder that when we give someone a gift, we cannot be upset with what they do with it (even if they destroy it), regardless of what we invested in getting it for them.

Some references from the talk:

Anything in there that you found interesting?

This is a post in a series on the talks that I attended at my first ever Agile Africa Conference in Johannesburg. All posts are based on the sketch-notes that I took in the sessions. 

Some of the slots were really short, which meant speakers couldn’t really go into a lot of detail. These are sketch-notes from some of the shorter talks.

Popcorn Flow

agileafrica.JPG  popcornflow

Find out more: https://popcornflow.com/

 

 

Leader Transformation

agileafrica

The full title of this case study was “Leader Transformation – a side effect of an agile transition”.

Key take-outs for me:

  • Different parties have different motives and often change driven from the top is feared or regarded as a ‘fad’ to ‘survive’.
  • Beware early successes- sometimes they create a false sense of confidence which leads to running before one can properly walk
  • Start from where you are

Mob Programming Case Study

mob

An interesting talk on the before and after effects of having a team practice mob programming. Some of my key take-outs for if you want to try it:

  • Start by following the rules and then inspect and adapt.
  • There are some things where mob programming doesn’t work very well, e.g. doing research, where learning is not an outcome of the work, and problems that are still very large.
  • You need to mob program with a cross-functional team with all the perspectives (problem knowledge, testing expertise, developers, UX, etc.).
  • You also need to create time for team members to do things on their own i.e. not all of their day is spent with the ‘mob’. This “alone time” could be spent on things that aren’t suited to mob programming and/or other creative initiatives.

 

This is a post in a series on the talks that I attended at my first ever Agile Africa Conference in Johannesburg. All posts are based on the sketch-notes that I took in the sessions. 

I was hoping the video for this talk would be available before I got round to blogging about it, however unfortunately it isn’t🙂 I’ll update this post with a link once it is available, because I don’t feel my notes will really do the talk by Neal Ford full justice.

agileafrica

The talk kicked off with a couple of tales about QWERTY keyboards and the legacy that remains. Most people have heard of the fable that QWERTY keys are arranged to help typists type more slowly to prevent jamming (apparently not true…), however how many of us have ever considered the underscore? Sure, we use it now, because it’s there, but did it  really make sense to port if over to modern-day keyboards when it was originally there to enable manual typists to underline pieces of text? Perhaps not🙂

To Neal, anti-patterns are wolf ideas in sheep’s clothing: they are ideas that look like a good idea at the time, but sometimes turn out to be a terrible idea. He then went on to describe six practices that have potentially proven to create anti-patterns over time:

1. Abstraction Distraction

Abstraction seemed like a clever idea to black box certain functions, however as the abstraction layers increase, things become increasingly complicated and confusing, eventually resulting in so much abstraction that the code is almost unusable and people are afraid to go in and make changes because they have no idea what will break

2. Code Reuse Abuse

Code reuse in principle, is good, but it can also lead to a whole bunch of dependencies that need to be managed.

3. Overlooking Dynamic Equilibrium

Things change all the time – and they change at different paces – so it’s really hard to plan an architecture for the future because you don’t know which parts will change when and at what pace. It’s no longer possible to be predictable, so rather focus on being adaptable.

4. Dogma

“Do it because I said so” or “do it because that’s how it’s always been done”

5. Sabotage
  • Cowboy coding
  • Focusing on cool stuff rather than necessary stuff
  • Inventing cool puzzles to solve
6. Forgetting that some things scale non-linearly
  • Examples are code, teams, and tools over time.
  • As the size increases, the pain increases exponentially
  • Tools have life-cycles and Neal recommended that when you are using a tool and it starts becoming painful to use, the you should probably start looking for a new tool

 

Neal also recommended a book called “Evolutionary Architectures” and mentioned some key concepts to bear in mind:

  • Components are deployed
  • Features are released
  • Allow for incremental change at an architectural level
  • Embrace experimentation and remember to include users in your feedback loop

And I’ll leave you with one last thought from the talk: Is Transitive Dependency Management tomorrow’s GoTo anti-pattern?

LINKS
nealford2

Thanks to sketchingscrummaster.com

 

This is a post in a series on the talks that I attended at my first ever Agile Africa Conference in Johannesburg. All posts are based on the sketch-notes that I took in the sessions. 

I’m not sure if you recall our first experiment with self-selection? Imagine my surprise when I realised that our keynote speaker on the topic, Sandy Mamoli, was the very same person who had been part of the team that created the material we’d used for our own self-selection attempts. As we’d also run a second less successful experiment, I was quite interested to hear a little more “from the horse’s mouth”, so to speak.

agileafrica.JPG

There were some key points shared by Sandy that helped me understand a little more why our second attempt had not succeeded from an expected outcome perspective, but had, in fact, succeeded from a feedback perspective.

  1. Purpose is important. Squads form around a strong purpose that they can buy into.
  2. Self-selection will always fail if management selection is going to be done afterwards to ‘tweak’ the outcomes. (Her solution: make the blueprints for the new squads very visible everywhere as soon as possible after the session.)
  3. She shared a story where squads would not form around a particular vision or goal and usually where that happened there were deeper issues at the root which needed to be resolved before a team would be successful.
  4. Self-selection should NOT directly or explicitly impact reporting lines.

So, upon reflection, after comparing our first and second experiment and adding in some of the tips from Sandy, these were my conclusions:

  • Self-selection should happen independently of reporting lines
    • The first time we did it, there was no impact on reporting lines; the second time we did it, reporting lines were impacted by which squad you moved into.
  • Try keep “people owners” as observers not players
    • There was a subtle form of “Liar Liar” in our second attempt as every time there was a significant shift in numbers to one or other ‘cost center’ then the managers (who were also the Product Owners) had a quick chat about how to re-balance things. In our first experiment, everyone remained in the same “cost center”.
  • Ensure the Product Owners are well prepared in terms of their vision
    • The second time we ran self-selection, one Product Owner had a very clear and mature view of what the squad would be achieving; whereas the other Product Owner was new to the space and hadn’t really had time to formulate their thinking and strategy properly.

Sandy also advised the following:

  • Where squads have fully formed after a couple of rounds, move forward with those squads (regardless of the state of the others).
  • Where squads aren’t fully formed because there just aren’t enough people, have the squad members identify what ‘imaginary friends’ they need to ‘hire’ to form a full squad.
  • Where squads haven’t formed for less obvious reasons and/or people refuse to participate in the process (and choose no-squad), revert to traditional management selection for those people and root cause the reasons for the resistance.

This keynote was very valuable to me as it shifted my perspective of our second attempt from being a failure to being a great source of useful feedback about the state of a particular space. Have you tried self-selection? What was the outcome? What did you learn?

 

This is a post in a series on the talks that I attended at my first ever Agile Africa Conference in Johannesburg. All posts are based on the sketch-notes that I took in the sessions. 

agileafricaSam and Karen started by clarifying what they meant by distributed teams: teams that don’t sit in the same location. They then categorised distributed teams into three main categories:

  1. Teams that work in the same time zone and/or the majority of their working/office hours overlap
  2. Teams that work in different time zones but there is some overlap of working/office hours
  3. Teams that work in different time zones or have different shifts so that there is no overlap of working/office hours.

For each, they then shared some common characteristics and where best to focus energy.

Full Overlap

These teams are characterised by synchronous communication. Here the best focus would be on technology and tools to ensure that communication is as easy as possible when people are distributed. They suggested some ideas like a video wall (expensive option) or running Skype continuously in the background (cheap option) to allow synchronous communication and cues to happen as naturally as possible.

Partial Overlap

Communication in these teams is largely asynchronous (e.g. email), so time together is valuable. Rather than use this time for things that can be communicated is an asynchronous manner, focus on using team time to create understanding. A practical example in the Scrum world is rather than use overlapping time for something like a stand-up (which can also be done via an update in most cases), use it for things like Grooming and Planning where more complicated conversations are required to flesh out understanding and work through difficult problems.

No Overlap

Their main ideas here related to being creative with

  • Tools e.g. creating a video for reviews and stand-up that can be distributed to the other team(s)
  • Rotating a team member who “takes one for the team” and changes their office hours so that there is some overlap with the other team(s).
  • Planning work to try to keep work where there are dependencies in teams that are working in similar time zones.

Besides the advice above, they also had the following general tips:

  • Use Good Technology
  • Have and Use Working Agreements
    • “Bottom Line” – a phrase used when people start to waffle and need to get to the point
    • Talking Over – agreement on what happens if people talk over each other. One idea is to give the facilitator permission to provide the order of who speaks in what order.
    • Multiple back-up plans – So if (when) the technology fails, everyone automatically knows which one to try next (and it doesn’t need to be discussed)
    • Silence – Silence is OK
  • Good Voice Trumps Bad Video
  • Same Experience for All
    • If one person needs to dial in, then everyone should dial in
  • Prepare
    • Prepare for sessions more than you would for face-to-face: agendas, tools, pre-reading, etc.

You can find more tips at RemoteAgileCoach.com.

I’ve shared some of my thoughts on distributed teams in a previous post. What have your experiences been with working on a Distributed Team?