Month: June 2016

Daily Scrum Personas

Daily Scrum Team

The Scrum Guide defines the Daily Scrum as a “15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours”.

Each person answers 3 questions:

  • What did I do yesterday that helped the Development Team meet the Sprint Goal?
  • What will I do today to help the development Team meet the Sprint Goal?
  • Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

The Development Team leverages these 3 questions to inspect, self-organize and empirically adapt to deliver the Sprint Goal.

The above information is straight out of the Scrum Guide, but as we practice our Daily Scrum we just might meet up with some of these people, listed below, that will provide us some coaching opportunities.

I hope these examples are helpful for the person just starting to implement Scrum at their organization and a review for other experienced Scrum practitioners.  Anyone who has any additional examples, please feel free to add them as a comment and we can build on the list!

Larry

Larry “Looking for a Leader”

Larry is 45 years-old and has been in IT for nearly 25 years.  All of those years have been working in a strong command and control environment. He’s a very structured individual and a compartmental eater.

Larry looks directly at the Scrum Master while answering the 3 questions.  This is a tell-tale sign that Larry is looking to provide a status report to a person in charge.  He has not yet embraced the philosophy of a self-organizing and empowered empirical team.  He should be speaking to the team and not any one person. Explain and reinforce the empowered empirical team through coaching, games and exercises.

Penelope

Penelope “Problem Solver”

Penelope went to well-respected university and was a double-major in Computer Science and Philosophy.  She doesn’t have much patience for useless formality or rules that get in her way.  She loves to dive into the detail and solve problems.  Her mantra is “Patience is a waste of time!”

Penelope conducts an immediate deep-dive into details surrounding information voiced during the Daily Scrum.  When an issue comes up during Daily Scrum, she asks questions and begins to solve the problem on the spot.  We need to coach Penelope and the team to list topics for further discussion in a parking lot or discussion list.  When the Daily Scrum is done then you can identify who wants to participate in the discussions.  There is no reason to involve teammates who are not interested in that topic.  The conversations can be conducted right after the Daily Scrum or later as the team sees fit.

Nicholas

Nicholas “New Guy”

Nicholas is 22 years old. He just graduated college and joined the company about 3 months ago.  He’s a little overwhelmed with all the things he needs to learn at the new job.  He’s hardworking, but insecure about the amount of work he can get done in a day compared with his experienced teammates.

Nicholas talks about anything he can think about that he did in the day, so that his team will not think he is unproductive.  He mentions the meetings with his manager and other non-sprint related activities.  Nicholas and the team need to be reminded that they need not speak about non-sprint related activities during the Daily Scrum.  They should only be speaking about information that pertains or impacts the sprint.

Sammy

Sammy “Scrum Master”

Sammy was a project manager for 5 years until his company adopted Scrum and he transitioned to Scrum Master.  Sammy likes nice orderly meetings and ensuring that the team is on track for delivery.

Sammy sets rules for the team, such as punctuality, no interrupting, etc.  He sets the order in which people should speak to increase efficiency.  Although rules are not necessarily a bad thing, the team should create rules of engagement and determine the speaking order on their own.  We need to take every opportunity in having the team realize and practice that they are a self-organizing team.  Conduct activities and games to fortify this concept.  Try having the person currently speaking choose the next person to speak.

Priscilla

Priscilla “Product Owner”

Priscilla has worked for this company for 20 years.  She is very intelligent and understands the sales and advertising business very well.  She also loves technical work and is adept at pulling data and analyzing it.  She always wants the latest technology solution and, even though she works in sales herself, is an easy sell.

Priscilla listens to the Daily Scrum, but cannot help advising the team on how to order their work effort to be more efficient.  She questions remaining time on tasks and pushes the team regularly at the Daily Scrum. We need to counsel Priscilla that the Daily Scrum is for the Development Team to assess progress and figure out as a self-organizing team how to accomplish the Sprint Goal and deliver the agreed upon sprint backlog items by the end of the Sprint.  As the Product Owner, Priscilla should not be interjecting during the Daily Scrum.

How Should We Structure Our Agile Teams?

Agile Team

There are two types of teams, Functional Teams and Cross-Functional Teams.  A Functional Team, sometimes referred to as a Component or Specialty Team, is comprised of people with the same skill set.  Cross-Functional teams on the other hand are centered around delivering the same business value and consist of people with different primary skill sets.

The Functional Team benefits from frequently sharing and bettering their specific skill set knowledge across the team.  It is easier establishing and enforcing standards. Communication and collaboration within their specific skill set is very efficient, since they are all on the same team.

A Cross-Functional Team on the other hand benefits from having people with different primary skill sets so it can deliver the requested business value without or with minimal dependencies on other teams.

When looking at the two different team types, there are a couple of important questions we must ask ourselves to decide team structure.

Question 1:  Do we currently have enough people with that skill set so we can place a person on each Cross-Functional Team that has a need for that primary skill set?

We don’t want someone being a member of four different teams.  In fact, many Agilists believe that a person should only be a member of one team.  I believe there may be exceptions, but there should be a good reason for it and once you split a person across more than two teams it should certainly raise a red flag.

Question 2:  What will be the most important and most frequently needed communication and collaboration?  Is it with others with the same skill set or is it with people delivering on a common business initiative?

Communications with and dependencies outside of the team are responsible for most of the delay in software development.  If we can keep the need for cross-communications to a minimum, then we can minimize this delay.

I learned a valuable lesson a few years ago when I took an existing group of integration specialists and divided them up across cross-functional product teams.  On the surface this appeared to make perfect sense.  I thought the cross-functional teams would benefit greatly by requiring less hand-offs, better design decisions, simplified planning and improved speed of delivery.  What I didn’t realize was the integrations people needed to communicate more with each other.  The integrations code was legacy code.  It wasn’t very loosely coupled at all and every time you changed something you had to coordinate with the rest of the team.  Obviously, this technical debt needed to be addressed, but until that time it made more sense for the integrations people to be on one team.

The main point is to determine where the communication needs are and base your team structure on those findings.  After I learned this important lesson through failure, I also found a book, “Management 3.0” by Jurgen Appelo, which addressed the topic in “Chapter 13: How to Grow Structure”.  I highly recommend this book for this subject and other great information and insight.

Happy Team Growing!