Posts Tagged ‘sgza’

I not-so-recently attended the regional Scrum Gathering for 2017 in Cape Town. This is a post in a series on some of the talks that I attended. All posts are based on the sketch-notes that I took in the sessions. 

Image result for help your team

I think a better title for this talk by Gavin Stevens would have been “How to be an awesome Product Owner”.

The basic structure of this talk for Product Owners was:

  1. A dysfunction and how you will notice it
  2. What you (as the Product Owner) can do about it
  3. Some ideas for how you can take action

The seven dysfunctions that Gavin touched on were:

  1. The team has lost sight of the vision
  2. The Corporate Mentality is that the PO is the leader of the team
  3. The team is not autonomous in the sprint
  4. The team isn’t motivated to finish the sprint early
  5. The PO is the middle man
  6. The PO needs to check everything
  7. The PO is not with the team

The team has lost sight of the vision

What you will notice are “weird” statements or questions like:

  • “How does this fit in?”
  • “Why now?”
  • “If I had known…”

The solution is to ask the team those weird questions when they are planning / discussing their work before the sprint starts.

Corporate Mentality: the PO is the leader

You will hear language like “Gavin and team”. Or “well done to Gavin for this great delivery”. The organisation has not yet realised that the PO is a leader – not THE leader.

What you need to do is create an understanding of the team structure. That the team structure is flat and that there is no single leader in a self-organising team.

The team is not autonomous in the sprint

The team doesn’t seem to be able to make decisions about how they work in the sprint. You, as the PO, are always the “go-to” guy.

What you need to do is empower the team.

Some ways you can do this are:

  • Don’t interfere during the sprint. Trust that the team knows what the goal is (because that was your job) and let them decide how to achieve it.
  • You make the decisions about why, and maybe what, but never how.

The team is not motivated to finish the sprint early

The team doesn’t seem motivated to try to achieve the sprint goal before the end of the sprint. This may be because, as soon as they finish, more work is automatically added to the sprint.

You need to create space. People need time to be creative. One way to achieve this is to tell the team that when they hit the sprint goal, the remainder of the sprint time is theirs to do with what they please.

Gavin mentioned that what the team then chooses to do is also often insightful. If they’re bought into the roadmap, they’ll usually choose to pick up the next pieces on the backlog. If they choose to do something completely different, then it’s usually a good idea to question why they feel that the work they chose to do is more valuable.

The Product Owner is the Middle Man

Which also means the PO is a blocker. Because if you’re not there, everything stops.

Some of the signs that you are a blocker are:

  1. You are the admin secretary who needs to check everything before the team releases
  2. Selfish backlogs – no one besides the PO is allowed to touch the Product Backlog
  3. You are a layer between the team and stakeholders

If you find the reason you are checking everything at the end is because it’s not aligned to what you expected, then you need to examine all the up-front areas where you are responsible for conveying what the team needs to deliver the right thing

  • Have you communicated the vision properly?
  • Did you help the team ask (and answer) the right questions in grooming and planning?

Once you believe that you have given the team the right information to build the right thing, then make each team member the “final checker”. Any team member can do that final check that something is ready to release (because a second set of eyes is usually a good thing – it just doesn’t need to always be the PO).

Fixing selfish backlogs is “relatively” easy – let others add to the Backlog. Ordering is still your decision, but what goes onto the list can be from anyone.

The Product Owner needs to check everything

The reason for this is normally related to a lack of trust: this happens when the PO doesn’t trust the team. Some of the signs are the same as when the PO is the middle man.

Building trust is a two-way street: the team need to trust the PO as much as the PO needs to trust the team.

One way to build trust is to create a safe space. Do this by

  • Allowing team members to learn from their mistakes
  • Not blaming
  • Protecting the team from external factors
  • Taking the fall when necessary

A second way to build trust is to tell team members that you trust them. For example, when a team member says “I’ve done all the tests and I think this is ready to go. Can we release?”, then don’t answer with a yes. Rather say “I trust you know when it is ready so you can make that call”.

The Product Owner is not with the team

The Product Owner needs to be available – to the team and to stakeholders. Although the PO should not be a middle man, one of the main functions of the role is to act as a translator between the team and stakeholders. How much you need to sit with your team does depends, and is somewhere on a continuum between “Always” and “Never”.

Some things you can try to make yourself more available are:

  1. Don’t schedule/accept consecutive meetings
  2. If you do have downtime and work in an environment where working distributed would be an option, rather choose to spend it at your desk if possible.

 

I found this an interesting talk and what was especially great was it paralleled much of what we have experienced as a team. Are you a Product Owner? What are your thoughts on what Gavin had to say?

Advertisements

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

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