Posts Tagged ‘agile’

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. 

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?

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

Despite its short length, this was an interesting talk for me. There were two new ideas that I’d not been exposed to before and quite liked. The first was the term “Most Loved Product” (MLPLOL-48). A MLPLOL-48 (rather than MVP) is a slice of a Product that can be used to gather feedback about the user experience i.e. does my Product makes my customer smile? The important part about a MLPLOL-48 is to not forget the smiley!

CaptureSecond, and largely related, was the concept of what a MLPLOL-48 vertical slice needed to consist of. Whereas vertical slices traditionally relate to the stack on which the Product was built, the UX slice needs to include the functional, reliable, usable and emotional design layers to be a full vertical slice.

The presenters also touched on user feedback and how it was important to consider all aspects of the user experience: what they hear, see, say, do, feel and think. They did caution, though, that “not every colourless liquid in a glass is water”, so although user feedback can tell us what they are hearing, seeing, saying, doing, feeling and thinking; we need to probe a little deeper to determine WHY they are having that experience.

Have you ever heard of a MLPLOL-48? What are your thoughts on the UX vertical slice concept?

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. 

Kniberg

I was very excited at the fact that Henrik Kniberg was presenting at Agile Africa this year. And his opening keynote did not disappoint. First, he made it clear what he meant by Scale. He didn’t mean a couple of teams, or even many teams working on different teams working on separate things – he meant numerous team with various inter-dependencies. And then he told us some ways we could avoid becoming “unagile” when working with lots of teams.

 

He said that the first thing to realise is that for such a complicated ecosystem to work, you want everyone to be operating from a space of high autonomy and high alignment. When you achieve that, then everyone understands the problem and also has the mandate to figure out how to solve it. kniberg1

Kniberg then introduced the concept of a “soup” of ingredients required for an environment in which many teams could thrive and continue to operate in an agile fashion. The ingredients of his soup included:

  1. Shared Purpose
  2. Transparency
  3. Feedback Loops
  4. Clear Priorities
  5. Organisational Learning

1. Shared Purpose

Kniberg emphasised that in order for everyone to have a shared purpose, over-communication was essential. Every team member needs to be in a position where they are able to answer the questions:

  • What are you working on?
  • Why are you working on it – what is its impact?
  • How will you measure when it is done?

He described the following top-down model as an example:

  1. The company agrees on their beliefs. This belief relates to how they are to remain a viable operation. It could be around how the company believes they make money; who their customers are; or what is likely to happen in the future.
  2. Beliefs then break down into North Star Goals. This is a goal that the organisation wants to achieve in order to realise a belief. It needs to have metrics.
  3. Goals are then broken down into “Bets“. It is called a bet because it is a hypothesis: if we do this, then we think (bet) that this will be the impact on our goal.
  4. And, finally, teams have goals which contribute to proving or disproving bets (Kniberg called these tribe goals).

2. Transparency

Being clear about what everyone is working on and why helps to provide context that enables autonomous teams to make intentional rather than accidental decisions. One of the tools Kniberg shared with us was the DIBB Framework.

DIBB Framework

DIBB stands for Data, Insights, Belief and Bets. Basically you have a single space listing all the prioritised Bets and it is very clear what data was used to generate insights that led to the Bets, and then the Belief that particular Bet relates too. Bets can be tracked on a single Kanban taskboard with the columns: Now (what we’re working on now); Next (the Bets we will work on next); and Later (not priority for now). Kniberg emphasised that all of this information should be in a simple format that was easy to share with all (one of the companies he worked for used a simple spreadsheet).

3. Feedback Loops

We all know feedback loops are important. Feedback loops help us adjust our course. Scrum and other Agile frameworks already have built-in feedback loops for single teams. It is necessary to increase the feedback loops to cover multiple teams when scaling. Examples of multi-team feedback loops could be a Scrum of Scrums, multi-team retrospectives, Friday demos, Whole Product Review or Alignment Events, and Management Reviews.

Whole Product Review

A whole product review is when all the teams working on a particular product (whether building features or working as a support team) get together to plan for their next timebox. It includes the following components:

  • A demo by each team of what they have done since the last Product Review (to create context)
  • Break-outs per team to plan ahead for the next timebox.
  • Creation of Team Boards that include
    • The goals for the next timebox ordered by impact
    • Stretch goals for the next timebox – these may not be achieved
    • Risks in the next timebox
    • The deliverables that will be delivered at the end of the next timebox
  • A management review of the team boards on the same day before the next timebox starts

Triple Feedback Loop

This actually came out of a conversation I was listening to during one of the Fish Bowl sessions at the conference (and not from Kniberg), but an idea for these multi-level feedback loops could be:

  1. Normal team reviews (Loop 1)
  2. Monthly product reviews (Loop 2 – with all the teams)
  3. Quarterly Sponsor review (Loop 3 whole day with team and management)

4. Ordered Clear Priorities

Ordered priorities help teams make the right decisions when trade-offs are required. Priorities should feed down into teams from the Company Beliefs and North Star Goals. Clear priorities help teams answer the questions “If we can only do one, which one would we do and why?”.

5. Organisational Learning

In order to improve, we need to learn. We cannot learn if we don’t have time to stop and process feedback that we receive. Or have time to practice skills we are growing. Kniberg suggested a couple of ways to create slack time in teams:

  • A pull team schedule where teams pull work as they have capacity to do it
  • Scheduled slack time e.g. retrospectives, gaps in sprints, etc.
  • A culture of promoting learning over busyness

Some ideas for cross-team learning:

  • Holding “Lunch and Learn” events where teams get together in an informal session to discuss a particular topic
  • Cross-team retrospectives
  • Embedding team members i.e. having a team member from the team that is sharing temporarily sit with the team that is learning

chef The last part of the keynote dealt with the “chef”. The chef is the person who ensures all the ingredients are available for the soup and continuously tweaks them to ensure the soup is as tasty as possible. In traditional organisations, we used to call this person or persons “leaders”. Leaders are not there to tell the team how to solve the problem. They are there to ensure that the team environment contains the ingredients for autonomy and alignments.

Leader chefs:

  • Create a shared sense of accountability
  • Enable teams to align their decisions to company goals and with other teams
  • Ensure that decisions can be made through transparency and clear ordering of priorities
  • Create slack

My main take-outs were:

  • Intentional rather than accidental decisions
  • Scaling needs autonomous teams that are aligned
  • Some cool ideas for creating top-down goal alignment and transparency
  • Some cool ideas for creating peer-alignment and transparency
  • The role of leaders in an Agile set-up

What were yours?

 

https://sketchingscrummaster.files.wordpress.com/2016/08/hendrik-kniberg1.jpg?w=648

With thanks to sketchingscrummaster.com

We’ve all bbigcompanyeen there. Someone describes a problem that they want solved (and possibly suggests how they think you should solve it) and in the very next breath asks: “So, how long will it take?”.

Invariably, we get talked into providing some kind of gut feel indication (days/weeks/months/quarters) based on nothing much besides (perhaps) experience. But how often in software do you actually do a rinse-and-repeat of something you’ve done before? In my 10 plus years in IT, never. Never ever.

Unfortunately, we don’t yet work in a world where most people are happy with “we’ll be done when we’re done” so a vague timeline is always needed: if only for coordinating training or the launch email and party. So where does one start?

First, there are some principles/facts-of-life that are important to bear in mind:
1. The cone of uncertainty
2. Some practical examples of the developer cone of uncertainty
3. A good analogy of why our estimates always suck, no matter what data we’ve used

In the beginning….

For me, the first time you can possibly try get a feel for how long your horizon might be, is after you’ve shared the problem with the team and they have had a chance to bandy around some options for solutions. At this point, assuming your team has worked together before, you can try do some planning poker at an Epic level. Pick a “big thing” that the team recently worked on, allocate it a number (3 usually works) and then have the group size “this big thing” relative to the one they have previously completed. I prefer to use a completely random number (like 3) rather than the actual story points delivered for this exercise because otherwise the team might get tied up debating the actual points and not the gut feel relative size.

Now, if you have a known velocity and also know the points delivered for the big thing we already built, you should be able to calculate an approximate size for the new piece and use your velocity to find a date range with variance (don’t forget about that cone!). For example:
– If we agreed our “Bake a cake” epic was a 3
– And then sized the “Bake a wedding cake” epic as a 5
– And “Bake a cake” was about 150 points to deliver
– Then “Bake a wedding cake” is probably about 3/5*150 = 225 points to deliver
– Which means you’re probably in for 225/velocity sprints (with 50% variance)

At the very least, this should help you pin-point which year and perhaps even quarter this thing is likely to be delivered. (Don’t make any promises though – remember the cone!)

When we know more….

Now, if you’re doing things properly, your team will groom the big epic and slowly start agreeing on small to medium stories and perhaps even slices. Ideally you’ll have a story map. At some point, you should have a list of stories (or themes or whatever) that more-or-less cover the full solution that the team intends to build. At this point, it is possible to do some Affinity Estimation, which will give you another estimate of the total size (in points) relatively quickly that you can sanity check with the help of velocity against your previous guesstimate. If you’re working with a new team and haven’t got a velocity yet, this is also the time when you can try ‘guess’ your velocity by placing a couple of stories into two-week buckets based on whether the team feels that they can finish them or not. This article explains this process in a bit more detail.

Keep checking yourself…

You will probably find that when you do Affinity Estimation that you will still have some biggish stories in the list, which is OK. Over time as these break down, it’s probably a good idea to repeat the exercise (unless you’re so great at grooming that your entire backlog has already been sized using Planning Poker). Until you have sized everything in detail to ready stories, Affinity Estimation is the quickest way to determine a total remaining backlog size that is reasonably useful. Over time, if you maintain your burn-up, you’ll be able to track your progress and re-adjust plans as you go along.

Did you find this post useful? Have you used these techniques before? What other techniques have you used to try build a view of your release roadmap?

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?

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.

First, watch this video about making toast.

maps

I really enjoyed the workshop on story mapping. Sadly, I still feel that although I ‘get it’ at a theoretical level, I still cannot see easy ways to use it in practice. It seems harder to create a map than it looks!

Suggested approach to creating your story map:

  1. Create a vision (e.g. using the Business Model Canvas)
  2. Write up the process or map (as described in the video). Think about the various user roles.
  3. Explore the map with questions. “What if…?” “What about…”?
  4. Group your activities to form a backbone. Focus on breadth and not depth. Consider the goals for your user personas.
  5. Slice your activities into outcomes based on your persona goals.
  6. Build your development strategy (order in which you will release)
Other notes
  • On average, you will usually identify about 15 user roles. These can usually be combined into about three user personas.
  • Unless you are working with a mature product in a stable environment, your road-map should be about delivering goals and not features.
  • When building your development strategy, it usually makes sense to build your high value, high risk items first.
Links
More on Story Mapping

Have you tried story-mapping? Was is successful? What worked for you? What did you struggle with?