How To Be a Successful Distributed Agile Team

Distributed Agile teams are nothing new, teams have been working remotely for a long time even before what has recently happened in the world with people working remotely full time due to travel restrictions and lockdowns.

I've already heard a lot of people online saying, "Wow this remote working can actually work" and "It's so much better when we use video..."

That is exactly right, distributed agile teams are a thing! Can you believe it?!! However it needs to be done in the right way.

There are a number of studies that support Distributed Agile Teams and their success out there if you simply Google scholar search "Agile Distributed Teams" you will see a bunch of studies and articles.

One of my favourites that I have come across is the "Theory of One Team" by Siva Dorairaj which focuses on how teams that are co-located can be successful with teams working remotely around the world.

I don't usually get very theoretical, but taking b…

Establishing your Agile Development Workflow for Ultimate Efficiency (Scrum/Kanban)

Have you ever had a time when…
A user story kept going back and forth between “In Test” and “In Development”?A user story was “Ready for Product Owner Walkthrough” but did not meet the Product Owner's requirements?Your team were unclear of the Acceptance Criteria and Definition of Ready/Done?
Today I want to tackle how to manage expectations with your team and ensure the correct workflow is agreed and in place for your Scrum or Kanban process to avoid rework, risk and failure and most importantly is team contributed.
Team Activity: Establishing a new workflow from scratch: 1. Firstly you will need to start with a basic workflow, I'd recommend starting with a standard workflow such as "To do", "In Progress", "In Test", "Review" and "Done". Depending on which team or industry you are building for this can change dramatically, this can be due to external blockers or different definitions of done.

2. Get the squad together

3. Place …

RetroThemez: Making Your Retrospectives More Enjoyable

Retrospectives can be repetitive for well established agile teams, especially when you are in your 27th sprint (54 weeks). So it is important for the Scrum Master to come up with ideas to make these ceremonies which sometimes feel mundane and turn them into enjoyable sessions for the team to increase engagement and excitement.

This idea was given to me by a colleague of mine which allowed me to start thinking more creatively. In honour of me leaving the organisation she created a retrospective in theme of my new organisation. This was such an awesome spin on our existing retros I thought "why stop there?". So in collaboration with her we have started a collection of themed retrospectives for all teams to use and contribute to.

We call it "RetroThemez" and it can be found on github here. 

The flow of the retrospective follows the following structure:

Team shout outsWhat went well?What needs improvement?How can we mitigate risk? From…

Rainbow Sprints, What are they? and Why should we do it?

So before I wrote this post I did a quick google search to figure out what people believe a"Rainbow Sprint" is and it is completely different to what I originally thought so lets change that shall we. What I coin a "Rainbow Sprint" is "a sprint that contains multiple epics or team objectives that have been agreed in sprint planning".

Why is this important you ask? Well I bring this topic up as it is very easy for agile scrum teams to be in 110% feature mode and not be able to provide value to other areas of the team's responsibilities.

For example the scrum team have been allocated multiple features to deliver into production, let's call them feature "Green" and feature "Red". Priorities based on value and capacity do not allow the team to also have some tech debt "Blue" to close out and not to mention are wanting to continuously work on their automation framework "Purple".

Rainbow sprints are another term f…

Agile delivery projection, transparency and an agile mindset

I recently had a question about how we track agile delivery in the team I currently work in. Let's all agree up front there is some rigidity to agile delivery and project work that we all do in the digital & technology space. Usually a project goes like so, there is a product vision, we agree the features we want to deliver for a first release (MVP) and then build on it iteratively from there. This creates a sense of scope, we then try to estimate a timeframe for this and from there we kick-off development.

In some of my previous posts I have explained details around Agile Estimation P1 and P2 which is up front estimations to gain an idea of release effort and time. However in this post we go into a bit more detail about real-time projection and transparency of teams.

The example I will use today is building a new front-end customer facing platform. This can take some time and the team have estimated up front potentially how long it might take them. Let's fast-forward to …

What makes an effective user story?

We've all heard the phrases INVEST and SPIDR (or maybe not, I didn't know about SPIDR until two weeks ago) but there are certain techniques that can make an effective user story. I don't want to focus too much on how to split user stories, but more so how I believe a well elaborated user story may look after working with various team members.

I have a set template (found here) that I tend to always use and seems to work well with my teams.

The scenario that we will talk through today will be a customer wanting to login to their portal using their mobile phone number.

House keeping tableWho are the various stakeholders?What is the reference number? (JIRA) This provides a context of who the collaborators of the story were/are and how we can navigate the land of JIRA. User StoryYour usual format of "As a...I want...So that..."Who is the user? (As a), What are we building? (I want)What is the value (So that)As a customer I want to provide my mobile number on the logi…

A valuable retrospective

In my opinion a retrospective is one of the most valuable ceremonies that you can bring to a agile delivery team. The aim is to reflect on the last sprint usually two week cycle of agile delivery and provide feedback and find improvements.

Retrospectives are sometimes overlooked for their value that they provide to a team. Usually for the following reasons:

1. They are not run effectively and efficiently
2. Actions are not taken
3. Action are not actioned
4. Feedback is not captured

The usual method of a retrospective is to get the team to all provide feedback on:

What went well? What should we keep doing?What didn’t go well? What should we stop doing?What are you confused about?
One method that I usually use is the happy :) confused ? sad :( boards with post-it notes.

1. The scrum master will re-cap on some of the work in the last sprint along with any milestones or key meetings or showcases
2. The team will spend 10 – 15 minutes reflecting on this and write their reflections down on …

Agile estimation and how to... (part 2 of 2)

So we left off in the previous post on "How do we take estimates and turn them into a projected timeline?"

Now that you have identified the total scope of a project and the estimated story points it’s now time to identify how long it will take your team to achieve the goal.

We do this by using what is called velocity. This is a metric for work done, usually used for planning and measuring team performance.

Usually product owners (PO) would like to see a total view of a project so even the blue sky scenarios and not just Minimum viable product (MVP) can be used in your estimates and timelines.

There are a few methods to do this but recently I have been using the three round velocity estimation game and this is usually done with new teams. If you already have a well established team then you would apply your current average velocity.

To do this have your story map in front of you and as a team get your product owner to ask for the commitments of each developer for the first sp…

Agile estimation and how to... (part 1 of 2)

You would have seen my recent post on story mapping and bringing a project to life with UI, features and user stories. Now comes the fun part, estimates and how to use these in an agile process.

Understanding the size of a piece of work is always important to people, some more then others, especially when there is cost involved. The idea of estimates is to gain this understanding and provide guidelines to your stakeholders.

Some questions you are trying to answer here are:
"How long will this take us?""How much will this cost us?" One way that works for me is carrying out estimates for an MVP, which is a subset of user stories that are identified as a minimum delivery for added value.

Using the story map from an earlier post we use a tool called estimation poker.

How to play estimation poker
Prerequisites: Run through each story so the team understand the end-to-endBreak any stories down if something is to largeAgree on a Definition of Done - e.g. passed user testing …

The importance of story mapping

Ode to the story map...
This week i've been working through a number of features and doing a bit of a deeper dive into feature/story analysis of my current projects' minimum viable product (MVP) and how these can be placed onto a story map.
Story maps in my opinion provide a number of benefits to teams and other stakeholders in the business, such as: End to end visionAllow visual thinkingProvoking thought Gain an understanding of sizeContextualise customer journey and interaction Story mapping is a term coined by Jeff Patton an Agilist who has written a number of blog posts and books about all things agile (i'll post some references below).
Story maps have always been a must for me, they drive conversations in the early days of the project and provide a sense of vision for everyone to see openly. They are also a great tool to run in your inception (which I will get to eventually in this blog)
I like to run my story maps with visuals (User Interface), followed by features (…

Being a Business Analyst

Coming into a new project or piece of work is sometimes confronting and it is essential you have the right tools and techniques to be successful in the fast paced environment of being a business analyst.
This is the first post of many posts which will go over what I believe are some of the important tips, techniques and processes that will help you master the skills of a BA from the beginning of the project to a happy production release and then some.
Here is a sneak peak into some of the topics coming soon... Understanding the business objectiveMerging business and technologyWhat is the project Scope?Working with designersHow to run a valuable inceptionProducing an MVP (Minimum viable product)Highlights of a good user storyEstimation techniquesThe life of a hybrid business analyst and scrum masterOther references This should be a perfect toolset to add to your arsenal of skills whether you are a business analyst or not.
I'd like to call out that I am not the master here, it is th…