If you missed last month’s webinar on How to Grow High Performance Teams Through Mentorship by Peter Saddington, I attached the audio and slide deck below. Enjoy!

Learn about what mentoring is and what mentoring isn't and how it could help your organization.

Here are 6 tips for Mentors from the webinar:

1. A mentor takes time to know people and reveal to them new possibilites and realities
2. A mentor gets excited when good things happen to others
3. A mentor takes initiative to help others
4. A mentor raises up leaders
5. A mentor is willing to take a risk with a potential leader
6. A mentor is not position conscious

A few problems came up when recording, but we were able to save the audio.

Thank you Peter Saddington for taking the time to be a presenter for our continued Staying Agile Webinar series. We greatly appreciate it.

Lastly, be sure to register for the upcoming free agile webinar on Thursday, June 27, 2013 at 11:00 AM – 12:00 PM PDT.

Originally posted at: http://www.axosoft.com/blog/2013/06/12/staying-agile-webinar-grow-high-performance-teams

Get 94 Tips for Agile Teams from the Experts

Here are 10 articles from 10 different authors that provide valuable advice for Scrum teams. These articles are in no particular order, so feel free to skim down the list and start with the ones that are most relevant to you.

1. 10 Tips for a Great Daily Scrum Meeting by Platinum Edge – The daily Scrum meeting is a powerful tool that keeps your project moving. At the same time, it is also easy for the meetings to not bring any added value.
2. Tips for Effective Backlog Grooming  by Charles Bradley – Are you wasting time in your Sprint Planning Meetings? Increase the value of your team’s Sprint Planning Meetings by grooming your Product Backlog.
3. Yoda’s top 10 tips for a new Scrum Master by Nigel Steane – As a new Scrum Master, you face unfamiliar challenges and your success is very much based on your ability to utilise coaching and soft skills to gently guide your team and colleagues.
4. Top ten tips for distributed Scrum team teleconferences By Jon Archer –  After acting as a Scrum Master for several months on a distributed team with people in six different locations, three different countries, learn ten tips to help get past those inevitable awkward silences.
5. 10 tips for adopting Scrum to save your project by Matthew Hodgson – Are you interested in adopting Scrum for your next project? Here are 10 tips from his experience with moving a number of projects from their existing project management frameworks to Scrum.
6. Five Tips for Impediment Resolution with Scrum by Stefan Roock – Impediments can slow down or even halt the progress of an otherwise well-functioning Scrum team. Take a look at the most common challenges that crop up on teams and what steps you can take to resolve them.
7. 10 Tips for Succeeding with Enterprise Agile Development by Tools Journal – Many enterprises are experimenting with agile development approaches like Scrum, Kanban, Lean, and XP hoping that introducing a new development approach will help. Yet, agile development has struggled to achieve critical mass in large enterprises.
8. 6 Tips for Good Scrum by Martin Harris – If you are doing these 6 tips, then you are doing very well and are likely to get better over time.
9. 9 Tips for Creating a Good Sprint Backlog by Luciano Felix – Giving attention to the sprint backlog creation process is fundamental to the team’s understanding of what should be done and how to better plan during the sprint.
10. 7 Tips for a More Effective Daily Scrum by Richard Lawrence – The main purpose of the Daily Scrum is for team members to make and follow-up on commitments to one another that work towards the team’s shared sprint commitment. Here are seven ways to get your Daily Scrum back on focus If your it has become unfocused, too long, or otherwise ineffective.

If you have any other good articles related to agile, please share them in the comments. Thanks.

94 Expert Tips For Agile Teams was originally posted on Axosoft's blog.

Agile and Scrum Q&A Webinar

Hi All,

We are hosting a free live agile webinar (Agile and Scrum Q&A Webinar) on March 28, 2013 at 11:00 AM PDT that is going to consist of questions sent in from the agile community. The content of what we talk about is entirely up to you.

We need your help to make this webinar informative and awesome. Please submit an interesting question or problem you are currently facing in your organization that you would like covered during the webinar. If there is time at the end, we will answer follow up questions.

If your question or problem is used during the webinar, we will send you a $25 amazon gift card. Please send your questions to team@axosoft.com.

Register at: http://www.ontimenow.com/training/scrum-webinar

If you can’t make it on that day, register anyways and we will send you the video recording of the full webinar.

Originally posted on Axosoft's blog: Agile and Scrum Q&A Webinar.

Your Scrum team's velocity and how to misuse it.

Your team has a velocity, whether you choose to measure it or not is irrelevant. On an average day, your team decreases the amount of work they have left in a release or a sprint. The average amount they decrease that work remaining per day is the velocity of that team.

This shouldn't be new information to most Scrum teams (if it is then let me know) but something I run into on a frequent basis is the misuse of velocity. Let's run through a couple examples:

Individual Velocity: This is by far the most common question I get about velocities and the simple answer is that individual velocity is not a meaningful measurement.

Let's say that we have a developer named Bob. Bob's a fantastic developer and can think his way through very complex problems, build amazing algorithms and writes beautiful easy to read code, but he's never spent a great amount of time with C# which the current project is built in. Luckily Bob's part of a great team, they interact in a really meaningful way and as a result Bob still writes great code and he's getting up to speed in C# as his team can help him fill in the gaps when he's struggling with the language. We'll say that based off of the backlog items he scratching off the list every week that he's got an individual velocity of 7.5 hours per day.

Now based off of this information, we could expect to see a 7.5 hrs/day improvement for the velocity of any team we add Bob to, right? Not so much, let's put Bob on a different team that works very fast but doesn't communicate all that well (a team of cowboys if you will). Suddenly Bob's velocity drops significantly because his team can't help him fill in language specific gaps in his knowledge. What's worse is that Bob's old team saw a dip in the their velocity that's more than Bob's 7.5 hrs/day since they no longer have Bob's amazing mind to help them through some of their more complex problems. This is to say nothing of the velocity of our cowboy team now that they have to "carry" Bob.

What we're seeing is that Bob's velocity is more than just the completed items with his name attached, it's also the way that he contributes to his team and the way that his team contributes to him. In all reality, there's no practical and meaningful way to separate Bob's velocity from the team itself. Even worse, it invites us to act on bad information since measuring individual velocity gives us the illusion of empirical data.

Point Velocity is absolute: Story Points and I don't see eye to eye but we understand one another and I think they can be used effectively in a lot of places (I just don't feel like they're a requirement for doing good Scrum). One thing that always makes me nervous though is when I see multiple teams working on a single product backlog and sharing point values.

Here's the thing, a story point is not an absolute value. When used correctly, a story point doesn't equate to time and it's value is unique to the team that created it. This means that Team A may look at a story and determine that it's value is 5 story points and Team B may look at that story and label it as 8 story points. This might be because Team A is more familiar with the type of work for that story or maybe they just view points on a different scale, it doesn't make their estimate wrong and it also doesn't make the other team's estimate wrong; just the opposite, it makes that team's estimate more accurate since they created it, it makes the estimate relative to the team doing the work.

None of this is really a problem for the estimate's main purpose which is helping the team establish the correct number of stories to forecast for the next sprint based off of their previous velocity. The problem is when I start combining the velocity of Team A with the velocity of Team B for an overall sprint velocity, since the two team's estimates don't always mean the same thing I'm essentially adding apples to oranges, assuming they're the same price and heading to the checkout counter. Compounding this problem is that this behavior invites stakeholders to compare velocities and make value judgements where they may not be warranted (Team B is finishing twice as many story points as Team A which means Team A must be slacking off), this can lead to estimate inflation (which make the estimate essentially worthless) or lower quality work in order to deliver more points than the other team.

Now an absolute estimation method will fare better under this scenario but it's got it's own problems. It's up to you to decide where to compromise with your estimates but if you decide to use points just keep in mind that your team velocities, while useful by themselves, shouldn't be combined.

I could go on with other velocity pitfalls but these are the most common that I see and this post is already getting a little long in the tooth. If you'll direct your eyes to the top of the page you'll notice that I'm putting on another Scrum webinar this Thursday at 11am PST. I'd be tickled pink to see you there, admission is $49 and you can find all the details by visiting the link above.

(Update: The Scrum Webinar went very well and I appreciate the great group of people that attended! I will inform everyone when we schedule the next one.)

Why self-organized teams are so important

It's a situation that I run into with new Scrum teams all the time.

Their work is complicated you see, there's all of these dependencies for every backlog item to be implemented and each task needs somebody with a special skill and we have to schedule how each person with the correct skill will finish each task in a certain order so I need some way of planning all of this and managing it within each sprint. Before you know it, there's gantt charts up on the walls and people are calling other people "resources". This is the reason why I keep my migraine medication handy at all times.

The problem here is that the very first assertion made here is absolutely true. Implementing a new feature in a complex system is complicated and there are certainly more factors involved than any one person can manage effectively.

Luckily the solution is actually rather easy. Make the management of this complexity as close to the work as possible, this actually means removing the project manager and allowing the team to decide for themselves how the work should be done.

Now almost as soon as you start doing this you'll begin to find impediments to the team getting their work done. The most major of these is that many new features and bugs need more than just a single person to complete them, at the very least you'll need somebody to code it and somebody else to test it but you may also need someone to modify a database or code a UI or design graphics or write up a help file.

To be clear, I actually don't agree with the approach of classifying developers by specific competencies. I feel like a developer should be able to code something into an application from beginning to end regardless of which part of the app needs to be modified. This makes development much easier, a complex feature may be developed by a single person and the only reason another person may be needed is for testing or pair programming.

I do realize that this is not always possible in every organization so I invite you to the middle ground: the self-organized cross functional team.

Cross functional means that the team as a whole includes everyone needed to implement any backlog item from beginning to end, including testing. This means that the team will consist of UI designers, Backend Developers, Database Administrators if needed and definitely testers.

Self-organized means that the team decides as a group how to implement those backlog items. This means that if a feature was started by Joe the UI developer but he needs something changed by Jim the DBA then all he needs to do is tell Jim to make that change when he gets a chance, no complex scheduling needed just individuals and their interactions getting things done.

Now in order for this to work you need a lot of collaboration between team members. Please note that this does not mean that the developers spend more time shooting emails back and forth, it means that they spend more time actually interacting. Preferably with real face to face communication.

 In many cases a lot of this collaborative talk will be done during the daily standup as developers chat about what they're planning for the day and their impediments, as a Scrum Master you'll want to allow enough of this during the standup for them to plan out who they'll team up with to complete their work but not so much that it makes the standup longer than it should be. Get used to the phrase "You two should be able to work out the details after the standup, let's keep moving". Also, try to keep the team from planning their individual plans more than 1 or 2 days ahead of time, any more than that and plans become hazy.

You may also consider a couple other options for increasing collaboration (and therefore the team's ability to self-organize) by removing the cubicles and allowing the team to work in a single room with no walls separating them. This way if a developer needs somebody else for a particular change or task they can simply ask them without having to visit their individual office or cube. When doing this (or when deciding on teams in general) keep in mind your individual team sizes, a team larger than say 9 people will begin to find it difficult to communicate as a group effectively and you'll actually begin to hinder collaboration rather than help it. The ideal team size is 7 plus or minus 2 and the same should hold true for your team rooms.

Finally, it never hurts to encourage the team members to become cross functional as a whole. Introduce the team to pair programming. It's up to them to adopt it or not or to modify it into something that fits their own team culture but the more they can see of code outside of their own specialty then the easier it will be for their team to take on complex work.