Many agile and Scrum teams struggle to limit their work in progress. This results in task switching, delays and other wastes, overall reducing how much the team delivers. Physically limiting space on a team task board asks as a mental barrier. This can be used to limit their work in progress and hence deliver more. I have had good success with Funnel Boards. The User Stories fall from the backlog into one of three spots available in the funnel for User Stories. It is a simple and effective way to limit the teams WIP. I heard of Funnel Boards at Agile Tour London 2013.
Zombie Team Funnel Board
The funnel board, leaves plenty of space around the edges for avatars, notes and other visualisation.
Switching from traditional waterfall development to Scrum is a very big mental change for many people. These people can be resistant to the change and potentially lead to a failed transition. It you have detected resistance to the transition to Scrum, before making the big change, consider an intermediate step to ease everyone into Scrum and lower the resistance to change. Consider changing to ‘Waterfall Iterations’ for a while before moving to Scrum.
When faced with transitioning from traditional waterfall development to Scrum, there are many unknowns and misunderstanding to be overcome. In some organisation this breeds significant resistance to the transition. If left unchecked this resistance to change can derail the whole transition. It is a great idea to find out what unknowns and misunderstanding exist and deal with them one by one. However that approach is not scalable and some issues will remain as the switch over looms. What I have used and seen to be successful in change resistant organisations is to stage the transition. Teams change from Waterfall to Waterfall Iterations for a couple of months, then the switch over to Scrum. Teams can be switched over a couple at a time, so that they can learn from and support each other. There is a co-ordination cost to having teams operating in different approaches; however it is generally worth it to smooth out the transition.
This phase introduces everyone to Iterations, co-location, cross functionality, Product Owners and Scrum masters.
Cross functional, co-located teams of 5 to 9 people.
Teams use Sprint Retrospectives, Task boards, Burn-downs and Daily Stand-ups just as in Scrum.
Iteration planning occurs every two weeks, where the Product Owner works with the team to pull in work items that have been created by whoever in waterfall created/allocated work items.
Iteration Review occurs every two weeks where the team demonstrates their completed work items to the Product Owner.
Functional testing carried out by the team with in the Iteration.
System testing carried out by separate testing team, outside of the Iteration.
The switch to Scrum from Waterfall Iterations; focuses teams on completing (including System testing, deployment) User Stories, that they themselves have created, split and sized.
In organisations where there is strong support for the transition (or even only light resistance) I would recommend switching straight to Scrum.
Kanban is an evolutionary process improvement approach that dramatically reduces resistance to change. That is another option to consider. Photo Credit: https://www.flickr.com/photos/16516058@N03/
Helping people to grow and improve is very satisfying. Hence constructive and re-enforcing feedback seems natural to me and I use it often. However there is a continuum of behaviour that prompts me to give feedback and unfortunately it should not always result in re-enforcing feedback. The feedback approach coaches’ use should change to suit the type of behavior we are providing feedback about. Choosing the correct approach is crucial in effecting the outcome that will help the individual, team and yourself.
Use Adjusting or Corrective feedback when someone is doing something that they must stop, or must change. I.e. Their behaviour is destructive, career limiting, negatively affecting others.
Do prepare (gather specific examples of the behaviour, talk to peers, draft what you will say, practice what you will say)
Do follow a structure and be directive in your delivery. Here is a template that you can use: it has been observed here, here and here, that you are doing X which is causing Y, this behaviour needs to stop, because it is causing Z. If the situation comes up again please do A instead.
Do give this feedback is private.
Do not give this feedback immediately after the event. Make sure you wait until everything has calmed down, so that it can be talked about in a rationale and deliberate manner.
Do not combine with other types of feedback, as it sends mixed messages.
Constructive or developmental feedback should be used when helping some to do better, or to help them see opportunities that they missed. This is covered in combination with Re-enforcing in my article Coaching Scrum Masters. The feedback sandwich puts two slices of re-enforcing feedback around a sliver of Constructive feedback. I have found this approach to be highly effective and have received plenty of positive feedback about it.
Re-enforcing / Encouraging feedback
Use it to praise people for effective behaviour and encourage them to do more of it, and perhaps do it even better next time.
Can be given in public (as it publicly promoting the behaviour that is appropriate), however be aware of who you are giving it to, some people will be embarrassed through to down-right upset at public acknowledgement.
This type of feedback should be approached as discussion with the recipient. You are not telling them to repeat their behaviour you are merely discussing the benefits that you noticed and that you would like to see more of that behaviour.
After years of working in a command and control culture moving to an agile methodology feels liberating for many team members. Unfortunately it can also feel over whelming. The first time a team needs to plan their iteration for themselves the can struggle to think of appropriate (and importantly small) tasks to split their User Story into. What follows is a list of ideas that I use with new teams to open their eyes to some of the options they have available to them. Additionally of the following information is available on this one page PDF cheat sheet.
When thinking about how I could further improve my skills
and knowledge as an Agile Coach, I came to the question of ‘How does an Agile Coach
differ from a Scrum Master?’ Both provide coaching and work in agile, hence any
division could appear to be very arbitrary. Writing out the competencies that I
feel a good Scrum Master should have and then the competencies a good Agile
Coach should have helped me answer the question. One good way to split the
roles; is to look at what they focus on.
If I assume a Scrum Master is someone focused on providing
Servant Leadership for a single team or a couple of teams. Than an Agile Coach
is someone who focuses on coaching the department (and/or company) that those
teams exist in. The Agile Coach provides training and coaching that is aimed at
delivering value across the department/company, not just the team level. Sure a
Scrum Master can do this, however it is not their focus when there are Agile
Coaches and Scrum Masters in the same company.
With all of that in mind, I have updated my post on Scrum Master Competencies, and I present the competencies that I want a good Agile
Coach to have.
* Reading the audience * Keeping energy levels up * Kolbs learning styles * Learning Modalities * Fleming's VARK model * Games for learning * Run Dojo’s * Run Lean Coffees * Run World Cafes * Competency Based Training * Creating training material * Creating games
* 30s elevator pitch for agile * Exhibit passion
* Interviewing Techniques * Competencies to look for
* Awesome emails * Excellent written * Creating memorable presentations * Presenting * Using appropriate medium
This is one way a work group can improve their interactions and hence become a high performing team. Individuals and Interactions are crucial for a team to have a chance of being a successful agile team. I often see teams that are full of great individuals yet the team is not performing as well as they could be. One common cause of this is that they are all working as individuals and not interacting effectively. These work groups can become great teams by progressing themselves from Co-ordination to Cooperation to Collaboration.
Dictionary Definition: the organization of the different elements of a complex body or activity so as to enable them to work together effectively. The working definition I use: Pursuing individual success over team success, by staying well out of each other’s work. i.e. Team members working on separate user stories within the same iteration. Symptoms at Stand ups:
Many user stories in progress.
Reporting their status to the ‘leader’, not the team.
No interest in user stories that are not their own.
No concern regarding delivery of user stories that are not their own.
Dictionary Definition: the action or process of working together to the same end. The working definition I use: Pursuing team success, by working as individuals. i.e. Team members working on separate tasks within the same user story. Symptoms at Stand ups:
Few user stories in progress
Present their information to the team.
Asking questions about user stories that they are not working on.
Interest in the delivery of user stories that they are not working on.
Rushing to select the most interesting tasks for themselves.
Rarely offering to assist each other.
Dictionary Definition: the action of working with someone to produce something. The working definition I use: Pursuing team success, by working as one. i.e. Team members working on the same task within a user story. E.g. Test Scenario workshops, design workshops/sessions, pair programming, pair testing. Symptoms at Stand ups:
Few user stories in progress
Present their information to the team.
Regularly offering to assist each other, especially when a user story is at risk.
Requesting the team input into selecting the next task that will best help the team achieve its goal.
Regularly offering to pair with each other, and regular acceptance of those offers.
Useful discussions often break out. It is sometimes hard to keep the stand up short because there is some much input and interest is effective plans and strategy.
Collaboration improves creativity
Effective collaboration results in something far greater than any contributor could achieve by themselves. Here are some creative collaborations, were I believe the result was superior to the input of any individual: Monty Python, Pink Floyd, The Beatles. They all bounced ideas off each other, helping each other to reach great heights. When separated they were all still great individuals yet failed to reach the dizzying heights they reached when collaborating.
Collaboration improves reviews
It is hard to provide an effective review without in-depth understanding of the work being carried out. That is why it is difficult and sometimes ineffective to review each other’s work when team members are just cooperating with each other. When team members collaborate with each other they are able to review as they progress, and/or review the work with deep understanding that results in superior feedback and hence a superior result.
Collaboration improves planning
Planning is only as good as the input it receives. When team members are collaborating they are more invested in the work, and hence more motivated to provide input. Additionally they are more motivation to ask the tough questions at stand ups, that help teams deliver when the going gets tough.
Team members should aim to always be Cooperating and often be collaborating.
Monday seems like a logical time to start your Sprint,
right? The start of the calendar week, rested after the weekend, let’s go! In
reality it is a bad idea, and I will explain why…
Primarily it comes down to interruptions to the sprint cadence.
The start and finish days of a sprint are the days where it is crucial that the
entire team is in attendance. Everyone needs to know what we are doing, why,
and to learn together from our mistakes.
Public or Bank Holidays usually occur on a Monday. If your
sprint is scheduled to start on a Monday, which is also a Public Holiday, you
need to reschedule all of the sprint meetings, shorten the sprint and this
causes significant admin overhead and critically it interrupts your cadence. The
other issue that often occurs is the impact of changes arising from Monday
morning management meetings. These
changes hit the team just after they have started their sprint, resulting in re-planning
costs, and a diminished sense of autonomy.
Fridays are bad too as this is often the day that people
book off to extend their weekend into a mini break. Fridays are often the day
that leaving lunches, leaving drinks and other celebrations occur, resulting in
So instead of Monday, start your sprint on Wednesday or
Thursday. The sprint end/start being the middle of the week has several
advantages. It avoids the issues of Monday/Friday. Meeting rooms are generally
more readily available in the middle of the week.
I do not recommend
Tuesday because when there is a public holiday on Monday the sprint will effectively
be ending the Friday before a long weekend (which is when everyone is mentally
So in summary avoid Mondays and Fridays it will save a lot
of heart ache.