Posts Tagged ‘sgza’

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

Advertisements

#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?

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. 

devops

I was extremely interested in hearing Biase talk about the journey a large bank in South Africa has recently embarked on to realise the benefits of integrated DevOps. Sadly for me, as we have many of the same challenges, their journey is not yet complete so they haven’t yet answered all the questions! I guess no one will ever have the perfect answer, however some recommendations would have been helpful 🙂

Their journey began with a pilot to try to realise the benefits of a team owning the entire value stream and not having different hand-offs between delivery, release management, and support. Some of the benefits of doing this would include:

  • Improved quality
  • Increased knowledge sharing
  • Increased organisational effectiveness
  • Shorter time to market
  • The ability to deploy faster with fewer failures

Their pilot initially consisted of two teams:

  1. A feature team (building the features); and
  2. A DevOps team (building tools to support CI and deployments for the feature team)

The feature team prioritised the work that the DevOps team did and their working relationship was governed by a set of principles and a working agreement. Apparently, through this experiment, they have realised that having two teams doesn’t really work and it is better to integrate DevOps skills into each feature team. Their challenge now is there aren’t enough DevOps skills available for the number of teams that they currently have, so they are trying to find ways to change that. Rather than taking a push approach, they are trying pull techniques like hackathons, demodays and gamification, to encourage the Feature Teams to build the skills from within.

Biase highlighted a number of challenges they experienced at the start of their journey and also the value of finding experts to help teams work through the technical issues. Their next set of experiments on this journey are related to

  • Growing skills from the ground up
  • Creating the necessary culture shift
  • Allowing for organic growth

I look forward to hearing more about their journey to come. What is your experience in including DevOps skills in your cross-functional feature teams?

#SGZA 2015: Owning your slippers

Posted: October 29, 2015 in Team
Tags: , , ,

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. 

slippers

This was a very interesting and insightful session. We only had 45 minutes, but apparently Danie, Jo and Kevin also offer a full-day version. They refer to plenty of models that are all tied together nicely in a non-threatening activity (which is pretty fun too) in their workshop. One thing that was very clear from the exercises is just how bad we are at making valid observations that are not clouded by our own perceptions and interpretations. One example is when Danie asked someone to say what they had observed about their group, at which point the person responded “everyone looked happy” (judgement). Danie kept repeating the questions and eventually we arrived at the valid observation that “most of the people were smiling”. This is an observable fact – sans any inferences and interpretations – and can be challenged on facts alone.

We also briefly explored the drama triangle. A person can enter an interaction as any one of the triangle points (rescuer, persecutor or victim) but everyone will eventually end up as a victim. The only way to avoid the drama triangle is to practice mindfulness (owning your own slippers) which will help you stay off the drama triangle entirely. Owning one’s slippers means accepting them for what they are. Until you own your slippers, you cannot change them.

Finally, the facilitating team provided a nice idea for practicing true observation:

  1. Attend a session and write down everything you observe, moment-for-moment. Imagine you are a video recorder.
  2. Review what you have written and note how many items are not true observations of fact, but have been coloured by your Ladder of Inference. (As a variation, you could ask someone else to check your observations for you).
  3. Rewrite these judgments as true observations.

Have you used any of the models in my sketch-note? Which ones did you find useful? How have you practiced using them?

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 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. 

Questions

This was an interactive workshop type session by the ladies from @GrowingAgile.

My main take-outs from the session:

  1. You can ask powerful questions without understanding the problem: One of the exercises we did was to pick a random powerful question from a pack of cards. We gave our partner two minutes to explain their problem and then asked the powerful question. Majority of the time, the person found the question helpful, even though it was randomly picked.
  2. Your intent matters: The intent is not to fix the problem. The intent needs to help the person expand their own thinking so that they can get themselves out of a rut (and hopefully solve their problem themselves).
  3. Your role matters: Depending on the context, your role in terms of the person may impact the authenticity of using powerful questions.
  4. The most powerful questions are questions about the “why”.

There are some examples of powerful questions in the sketch note. Try using one of them next time you’re struggling with a problem and see what happens. One of my ideas is try them out at one of our Community of Interest sessions.

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?