Archive | Event Report RSS feed for this section

Event Report – Product Owners: Dealing with Capacity and Prioritisation

Last night’s talk by Karen and Sam from Growing Agile was an inspirational eye-opener for Product Owners. It was also one of the best attended events with 80 Agilists present!

Sam and Karen co-presented the event, using a highway as an analogy for capacity. Their slides were refreshingly hand-written.

Of course, the mingling after the event – with good food and wine on a warm Spring evening – made it just extra special!

The evening was made possible by our generous sponsor, BSG.

See some photos of the event on our Meetup group.

BSG Logo no tag-line

Event report – The five dysfunctions of a team

slide headerThis was the first time that we used Welgemeend as a venue – a historic Cape Dutch manor house in the CBD which once was one of the original 3 farms in the city, supplying fruit and vegetables to Greenmarket Square.

During the event Leon circulated a questionnaire about the Common causes of team conflict. The top three results are as follows:

(9 votes) Lack of team responsibility

(8 votes) Misunderstanding of job responsibilities

(7 votes) Misunderstanding of requirements

Here are the slides of the presentation.

event1

event2

 

 

 

 

 

Event Report – Product Roadmapping 101

Somewhere between vision and features, between product manager and owner, and customers, teams & the Board of Directors lies the mysterious Product Roadmap – the topic for our March event in Cape Town.

It’s a blurry landscape and on reflection, I don’t often see roadmaps that work as meaningful guides for developing products.1403 Product Mapping

Tackling such complex topics as vision vs strategy, Annu Augustine took us through the typical traps and challenges facing product managers, and shared her insights from the field with more than a little dry humour.

From all of this, Annu provides a clear set of steps to incorporate strategic vision, profit opportunities and input from internal and external stakeholders, without compromising the product or injuring relationships.

Take a scroll through her slidedeck Product Roadmapping 101

 

Event Report – Playing Innovation Games

Innovation games help us create and validate new ideas, and our February workshop brought them in abundance… along with a lot of laughter!

false facesWe started with an improv-inspired exercise telling ridiculous and improbable stories.

Our opening game was ‘False Faces’ from Thinkertoys, where the groups listed assumptions about their issue, and then wrote them in reverse. Breakthrough ideas came from asking “what would the world look like in order for the new assumption to be true?”.

With a bunchbodystorming of new ideas, we picked one to validate and used the highly interactive Bodystorming technique to design and test out interactions with our new system.
Much more laughter ensued, and with that came some very viable ideas, which we assessed according to their Consumer Desirability, Business Viability and Technical Feasibility.

Mostly what we took out of the event was the real experience that with a focused creative thinking framework, every one of us is capable of producing breakthrough ideas… so exciting times lie ahead 🙂

Laughter

Scrum Gathering 2013- Karen Greaves: Agile Performance Appraisals Nobukhosi Dlamini

Karen Greaves: Agile Performance Appraisals – Do we need a number?

On the first day of the Scrum Gathering we kicked off with Karen Greaves presenting a talk on Performance Appraisals. As can be expected, the room was packed to capacity as many in the audience were eager to listen in and join the discussion on this thorny issue. After all, performance appraisals are that process we all love to hate. And with good reason too, many in the audience shared stories of negative experiences they have had with performance appraisals and there were only but a few positive experiences shared. The anxiety, discomfort and disappointment experienced around performance appraisals came both from those who were giving them as well as those who were receiving them. What was interesting to see were stats on how few CEO’s actually believed that performance appraisals were an accurate measure of individuals’ performance in their organization. Also, less than 50% of HR actually believe that performance appraisals in their current form are accurate.

Karen then shared her experience of how she felt about performance appraisals over the years in her career. When she started off working for Microsoft she had a very positive experience receiving an outstanding performance appraisal (and the relevant increase) for her hard work and effort. With that great motivation she maintained her hard work but the following year she received a lower rating much to her disappointment. When she did some investigation into why she might have received this low score, she was told that everyone gets a turn to have an outstanding rating, and she had already had her turn. Working at another company for a year and a half, she received neither a performance appraisal nor any increase. She didn’t mind the former, but was unhappy about the latter which led her to leave the employment of that company. In another company she had an outstanding employee whom she wanted to reward with the highest rating, however, her manager informed her that the company never awards that rating to anybody.

Karen explained how she was able to implement a fair performance appraisal system at Fundamo during the time when she was a development manager there. She explains that to do this she needed to gain support from her line manager as well as reach an agreement with HR. She was able to get both support from her manager as well as cooperation from HR by providing HR with the information they required. Her system started off with monthly 1-1 feedback sessions with each of her developers to continuously build the relationship and ensure that each person was always aware of how they were performing. This way no-one was ever surprised at the end of the year when they received their increase. She also eliminated the rating in the performance appraisal and made sure that the appraisal was delivered verbally, not through a letter.
However, HR required a number (as they always do), and she provided them with a number calculated based on each persons’ performance. She placed all her team members into one of three categories: the poor performers (which were very few), the average performers (which was the majority), and the superstars (which were also very few). However, this number was never disclosed to the team members as she felt it added nothing to the appraisal other than what she had already provided them with.

Based on that score, everyone was awarded their annual increase at the final appraisal. Although the final appraisal was nothing other than the monthly 1-1 meeting with the increase letter. In this way she managed to decouple the performance appraisal from the rating and increase based on a rating.

The discussion was interesting and thought provoking. The main thing that was highlighted is that there are some steps we can take to introduce changes in the performance appraisal process instead of suffering through them year after year. It requires some negotiations with the stakeholders, senior managers and HR being the main stakeholders. We can make changes by ensuring that we still provide the data that is essential in the HR process, but also reduce the pain and bureaucracy it has on our lives.

Written by: Nobukhosi Dlamini

Event Report: Mobile UX

Before anyone wants you to make an app for them, make sure they watch this video:

Read More…

Event Report: Agile Antipatterns

Karen and Sam from Growing Agile give us a runthrough on how antipatterns sneak in over time, often with the best of intentions with some examples:

WHAT: Burndowns updated by Scrum Master.
WHY: This antipattern features in many a team but if you do it, you own it. But who cares about the status the most? The team should, so it is best for them to own the burndown.
TRY: Don’t do it. Maybe the team will do it, it might even take 3 sprints, even longer..But the team need to fully understand their progress to do something about issues when they can fix it, rather then at the end when its too late.

WHAT:Same velocity every sprint.
WHY: Velocity should vary and should overall be going up.
TRY: Let the team know its ok to fail. Prepare management for failure. Commit honestly if you honestly believe you can do the work.

WHAT: Fines for being late to meetings.
WHY: You are giving people permission to be late.
TRY: When someone is late, don’t update them on whats happened in their absense, its their responsibility to find out what they missed after the meeting. Finish your meetings early to give people time to get to their next meeting. If people are continually late find out why.

We also discussed the difference between an antipattern and a problem. For instance a 45 minute standup is not an antipattern, its a problem.

For the remainder of the event we broke up into teams and discussed other antipatterns we found in our teams.

It was a thought-provoking evening and I really liked thinking about the differences between an antipattern and a problem. I also would use the format of WHAT/WHY/TRY again, its a good framework to use when thinking about issues.

Event Report: Leading Self-Organising Teams

At the October SUGSA meeting Peter Hundermark shared his views on how to lead self-organising teams, along with some honest experiences of his successes and failures and growth in understand as to what self-organisation actually means to how an organisation needs to change as a whole.  The key to success seems to be in understanding organisations.  Peter’s partnership with Dr Sigi Kaltenecker, a seasoned organisational coach, has led him to better understand organisations and organisational change.  Over the years they have partnered to build a model for leading self-organising teams and the organisational change to support them.  Peter touched a little on this model and on the classic examples of what self-organisation is about.

Some key things that stood out to me were:

  • The reminder that any self-organising team needs a facilitator in order to work properly.  This is to help avoid a single leader from surfacing and potentially dominating the team, destroying its self-organisation.
  • Trust is a key factor – on all levels.  Without trust it is hard to enable a self-organising team.
  • Middle Managers need to become change agents focused on maintaining the change to allow self-organisation.  The common scenario is that upper management and/or the development teams becoming deeply involved in trying to adopt the new agile way of working.  Too often middle management isn’t focused on.  However they are key in order to aid and promote the change.  While we often succeed in giving a safe space for the team to fail – we too often don’t give that same safe space for middle managers to fail.  As a result a lot of the transition doesn’t get supported in the middle of the organisation.  In order to succeed with self-organisation – all levels of the organisation need to be supported and be able to fail and learn.

It was great to hear some new insights on self-managing teams – and to be reminded of the ones that we already knew.  It was also interesting to get a taster of the model that is being taught by Sigi and Peter in their course.

We adjourned as usual for drinks and snacks afterwards – yet another SUGSA event enjoyably completed.

Event Report: Close the Loop! Simplifying A3 Thinking for Team Retrospectives

I have always enjoyed doing new and different things for Retrospectives. Believing that valuable retrospectives allow the team to truly reflect and improve.

A3 Thinking is a problem solving technique present in Lean which help solve problems at the organizational level.

Cara took us on a whirlwind tour of some concrete concepts used in Lean and Agile. Using the Deming model to illustrate that we do checking very well (retrospectives) and then Acting on it, but how often do we test and verify that the improvement goal are actually improving anything. A3 thinking applied to Team retrospectives help create testable hypothesis and keeps the system in mind.

 

The Simulation:

Groups, Understand the Context

Cara introduced us to 2 companies, fictitious she assured us J.  Each group was given 1 out of the 2 companies with their specific environment and current states. Knowing the context allowed us to study and understand the problem. The notes were extremely valuable and it was just the right detail to allow our imagination to fill in the rest.

We were encouraged to understand the problem and context but not to try and solve the problem, solving the problem was not the intention of the talk and Cara facilitated the problem solvers back to the exercise at hand.

 

Influencing factors

We identified any factors that could increase the rate of change. These items are not positive or negative but to understand their impact on the rate of change in the system.

 

Clarifying Expectations

Articulate the current state (current problem) and the desired target state (long term ideal)

 

Write a hypothesis

Introducing a hypothesis creates the opportunity to make our goals testable.

“By [doing something] we expect [this result]”

Pass Conditions / / Fail Conditions

(if our hypothesis is right)

(if our hypothesis is wrong)

We can now test our goals at the end of the sprint to ascertain if the improvement goal is proving our hypothesis correct or not.

 

The Sprint

Using our imaginations and some guided “Real life” scenarios our group had a 3 week sprint, during the sprint we responded to all of the events and could say what our progress was on our retrospective goal.

 

Retrospective

We looked at what happened in the whole system. We tried to understand if our hypothesis was met proven true or false and we took that information to change some of the assumptions on expectations. We changed our expectations where needed and adjusted \ created new hypothesis to take into our next sprint.

~fin Simulation

 

Creating testable hypothesis, just testing it without worrying to get them right and understanding that the whole system has an impact helps us see problems differently. What Cara did was allow us to distill the essence of A3 thinking to an empirical experience that can be used by teams trying to kill some of their tougher impediments or at least understand the problem better. We now have another tool to add to a team’s toolbox.

Slides

Close The Loop

Team work:


Code Lab Slides and Videos

We will be adding links to all the slides and videos from Code Lab in this post. Please bear with us as we assemble these.

Closing Keynote:

Ideas Aren’t Precious, People Are: What we’ve learned so far at the Nordstrom Innovation Lab – Jeremy Lightsmith

Slides

Video

Video’s shown in the talk

http://www.youtube.com/watch?v=szr0ezLyQHY

http://www.youtube.com/watch?v=M66ZU2PCIcM

Talks:

DEVOPS & Continuous Deployment – Len Weincier

Code is up on GitHub at https://github.com/CloudAfrica/vagrant_example.git

Slides

Hands on Agile Software Architecture and Design – Martin Cronje

Slides

Git Workshop – Kevin Trethewey
Slides

Unit Testing for SQL- Alain King

Slides

You want me to do what??? – Neil Zeeman
Slides

Fast Tracking GUI development – Herman Lindvelt
Slides

xUnit Test Patterns – Peter Wiles

Slides