April 25, 2014

All Posts Tagged With: scrum

Agile Coaching Blog

The Role of Scrum Master – A Permanent Position?

As agile frameworks grow in both popularity and widespread use, especially with Scrum leading the way, Scrum Masters have grown in popularity with companies, and we see an increase in job postings specifically for them. However, we have to understand that “being” an SM is not a position to occupy, it’s living up to a set of responsibilities.

Although the role itself is an artifact of Scrum, the responsibilities of the role are nothing new for a healthy team environment. A Scrum Master needs to support the team’s ability to focus on what is important and deliver on commitments.
team leadership
When organizations implement agile frameworks, a Scrum Master role is needed to help teams re-learn the discipline of healthy delivery. But as time goes by, the responsibilities need to be absorbed by the entire team. There may be one person that takes a lead, but the mantle lies on the entire team’s shoulders, and the position of Scrum Master slowly phases out as a new team capability emerges: leadership.

Leadership at the team level is something we have slowly diverged from in the name of organizational efficiency over the last few decades. Management theory has taught us that the most efficient way of managing the work is to remove tasks and responsibilities outside of each person’s job description. So developers should only do development, QA only testing, etc. Leadership is seen more in terms of a craftsman expertise with a focus on tightly controlling the work itself.

I don’t know if “Scrum Master-ing” is a professional endeavor for a life-long career or more of a step along the way. I think that the more you practice it, the more you really dive into becoming a change agent. The responsibilities of the role lend themselves naturally to that progression. For instance, the more teams you lead as a Scrum Master, the more you learn to read the patterns of impediments, and the more you will seek to prevent/mitigate the formation of problems you have observed in the past. Why wait until challenges materialize when we can go out and influence the outcome early, right? And you would do that by influencing the environment in which the patterns are forming to help “change” the circumstances that are developing. Now, you’re now thinking like a change agent.

Like a good leader, a Scrum Master builds a legacy for the team to perpetuate once the position is no longer needed. And now the role persists through the team.

Want additional actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.



What Big User Stories Could be Telling You

User stories are intended to be a high level description of some functionality. It is, however, common to find user stories growing into specs or large use cases that resemble whatever the organization used to do, back when they did large requirements documents. Comments like “The stories are not detailed enough to start development” or “This took much longer than expected so we should have more acceptance criteria for next time” can become common. There is a balance here that we should watch and adjust carefully. And most of the time we think the solution is more story documentation.

Here is the story card AND all the acceptance criteria, wire frames, specs, use cases, test plans, flow diagrams, architecture...

Why User Stories Get Big

I like user stories as an easy to understand idea for a company to start thinking about a light weight way to communicate needs, features and benefits. It is hard to describe in brief sentences all the forces that pull organizations to keep them thinking in lots of details. A few might be:

  • A culture and history of Big Design Up Front that makes it hard for feature definition to happen just in time.
  • A continued need for long range planning requiring estimates for work that will possibly take months before it actually starts.
  • Skilled technical people who are accustomed to talking about technical details instead of the needs of the user.
  • And more…

Lack of Focus

The most powerful and subtle force to cause “user stories” to grow is a continued lack of focus for the people defining features and those creating the features.

For example, if I am Product Owner of 5-12 products working with 3 teams who are all working on multiple products, I am not able to think of a feature, collaborate on it’s definition as it is built, see it created and then think about the next feature. I have to document my thinking of every feature because one hour from now I have to think about other features that also might not be built right away.

The key to being truly Agile is to finish stuff. The more inventory of ideas, features, undeployed code, etc. that we have, the less Agile we can be.

Have Conversations

In short, Ron Jeffries, the inventor of User Stories, said that the user story should have “3Cs” of attributes: Card (small enough to fit on an index card), Conversation (is a place holder for conversation) and Confirmation (a definition of when we are done, such as acceptance criteria). Most of the symptoms prevalent when stories grow big are likely indicators that the Conversations are not taking place and people are writing stuff down in an attempt to fill the gap.

Don’t write more stuff down. Figure out why the right conversations are not happening. i.e. “Individuals and interactions over processes and tools.” That said, sometimes what we see as an over-documented abuse of the user story is a vast improvement on what the organization used to do. We have to temper our zeal with a dose of client reality as we work to get incrementally better.

Do you see user stories getting too big? If you don’t use user stories, does what you use help or hinder conversations? What is your balance between the ability to deliver vs. the need to document thinking?

Want additional actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.



Scrum Meeting Success for Distributed Teams

In a previous blog, I discussed ways to make distributed daily scrum meetings more effective. This blog reinforces those ideas and provides additional tips to run successful scrum meetings with geographically distributed teams.

Productive, timely, 15-minute Daily Scrum meetings, remain a challenge. As many practitioners will attest, co-located Daily Scrum meetings are nearly as challenging for some of the same reasons:
- Meetings go beyond 15 minutes
- Not everyone has a chance to be heard
- Conversations wander into resolutions and opinion
- Impediments are not captured and addressed
- Others interrupt
And more…

Holding team meetings where members are not in the same physical or mental space is quite challenging, and it becomes more so when the team is geographically distributed. As I mentioned previously, the initial rule of thumb was to breakdown the daily meeting into small deliverables and then focus on each part of the meeting. The overall Definition of Done is the teams take ownership of the Daily Scrum meeting and use this as a foundation/basis. This idea has evolved into a goal for Daily Scrum meetings of having the team take ownership and management of their daily meeting. With this, we can create “Definitions of Done” for each part of the meeting.

For example:
Part 1: The team listens to each other’s ‘questions 3’ with no interruptions.
- Definition of Done: each team member has an equal voice to state their answers and be heard by their team members.

Part 2: The ScrumMaster reads the impediments/issues they recorded and the team adds, corrects and confirms the list is correct
- Definition of Done: the ScrumMaster reads off the impediments and has the team approve them

Part 3: The participants in the Daily Scrum meeting organize additional conversations around the Sprint and the results of the Daily Scrum Meeting the team.
- Definition of Done: the team members self-organize and work on the issues at hand and have these groups communicate what they did before the next scrum meeting, to the rest of the team.

When it comes to implementation there‘s a way to execute this process. For example:.
The meeting begins with one team member (initially the ScrumMaster) asking a team member the ‘questions 3’.
- The team member identifies the task and the story they are working on. They describe at a high level what they are doing and how much more time they need to finish.
- The team member then describes what they plan on doing tomorrow. If they will be moving to a new task, they should state which task.
- The team member then states what issues/impediments/ concerns they have about getting the work done or completing the sprint..
- Team member #1 then asks another team member the ‘questions 3’. This is a sure way to transfer ownership of the meeting to the team.

This is not a ritual. It is a basic pattern of action that can be used to start off a new team, orient new team members and get a team back into a rhythm. I have found that getting back on track is a lot easier if there is a simple base or foundation to structure and define roles. From there, teams can quickly self-organize…and it works well when things get stressful!

Roles and Actions for the Daily Scrum
ScrumMasters don’t run the Daily Scrum – they guide the team to run it themselves. Their primary focus is to collect the impediment list and get it approved by the Team. There should be a task on the task board regarding impediments for reporting the status of impediments.

Team Members individually and collectively run the meeting.

The Product Owner should be there listening and ready to answer questions immediately after the meeting closes.

Anyone who has committed to deliver something to the team during the Sprint must have a task on the task board and attend and answer the questions 3. This includes Product Owners, stakeholders, and management.

Guidelines and Techniques for the Daily Scrum
1) Turn the meeting ownership over to the team by having each team member ask another member the ‘questions 3’. Since there is no pattern or set order when one team member asks another, people on phones pay attention because they do not know when the questions will come their way.

2) The ScrumMaster is the servant leader, helping the team stay focused on the conversation, the task board, and the questions. It’s surprising how quickly the rest of the team picks up on this focus and brings the more loquacious and “off tangent” teammates back on track by asking “what task are you talking about?” Some teams go as far as including a protocol statement in their team charter stating all questions in the daily Scrum meeting begin with the user story and the task.

3) At the end of the first part of the meeting, the ScrumMaster, who may have been taking notes on the impediments, begins the second portion of the meeting by going over the impediment list to see if any were missed. This action reinforces that this meeting is for the team and that all issues are visible and noted.

4) The third and final part is a call for the issues to be discussed immediately after the meeting. Any team member, including the Product Owner may ask for conversations on story or task issues.

5) As soon as that is sorted out, the ScrumMaster requests that all decisions resulting from the upcoming conversations be communicated before the next daily meeting.

6) The daily meeting is closed and the conversations continue.


Agile Transformation: Go Faster, But Not for the Reason You Think

A common reason people give for undergoing an agile transformation is that their projects will “go faster.” When most people think of faster they think of getting all the work done sooner. And they are not wrong to think that way. A recent industry survey [PDF] and other sources point to increased productivity as one of the benefits of agile practices. I do not dispute this but I’d like to look at faster from a different perspective. Agile practices pave the road, so to speak. It doesn’t matter how fast your car can go if you are driving on a dirt road.

Pave the Road to Agile Transformation

Magical Agile Transformations?

In this discussion I will focus on Scrum as the framework the team has chosen in order to become agile. Assume a team of good people is formed, trained in Scrum and starts Sprint 1. Suddenly the programmers can write code faster? Or the product owner can define features faster and tests are written and run faster? No, there is no magic. The reality is that most of the individuals on the team are just as fast at their usual tasks as they were before Scrum. Each individual, in fact, is probably not any faster at their specialized skill even after several sprints.

So, given that the individuals on the team are not actually faster, what is happening to make productivity go up? Or does it only look like productivity is up? [Read more...]


ScrumMasters and Agile Transformation: Are We There Yet?

After you finished your first CSM class, you probably felt that the ScrumMaster role was pretty simple. Facilitate a few meetings, keep everyone true to Scrum—how difficult can it be? We’ve found that most people return from introductory Scrum training feeling like they can easily add a few ScrumMaster duties to their current responsibilities with little to no disruption.

What you have likely realized since serving as a ScrumMaster, however, is that the ScrumMaster role is far more complex and rich than you had originally envisioned. Although it can be done alongside other responsibilities, the ScrumMaster role takes a lot more expertise than just scheduling meetings and passing the CSM exam. The reality is that being an effective ScrumMaster is anything but easy. [Read more...]


Lessons in Agile Development from a Wooden Train Set

I should be working on continuing my posts about Lean Startup and the Enterprise, but Winter Storm Nemo has had me pretty close to home for this weekend and given me the opportunity to spend a lot of time in the house with my kids. For those of you who don’t know my children, they love trains. Actually, love probably doesn’t quite convey the level of feeling my almost 4-year-old son has for them, and his little sister is not far behind. As such, one of their favorite activities is to build a train set on the table in their room. This introduces several challenges, including the constraints of the table, demands of two different and very vocal stakeholders, as well as the need to use the track as it is being built. When we play on the set, we can end up with some very sophisticated tracks, like this one below.

Train TrackAfter building several such tracks, it occurred to me that we’ve been doing it using many concepts from Agile Software Development including evolutionary design, continuous integration, short iterations, and refactoring to name just a few. For some time, I’ve been meaning to catalog the evolution of one of these tracks, all it took was being snowed in under 3 feet of white powder for me to finally have the opportunity. This blog encompasses the building the track you see above from Friday evening through Sunday morning (February 8th – 10th, 2013). [Read more...]


Scrum: Easier Done Than Said

On one of the earliest Scrum projects I coached, a developer said something that has always stuck with me about all this Scrum and agile stuff. We were beginning to move beyond the original skunkworks project towards more of a company-wide integration and ran up against some roadblocks. Yes, the usual ones… We were commiserating over Skype one day when the developer asked, “Why do we have to tell everyone what we’re doing—it’s easer to do than say”

As a card-carrying member of the “apology before permission” club this hit me like a bolt from the blue. [Read more...]