The Unanswered Offshore Question, Pt 2

So, how do you know if your offshore team is as productive on onshore, and therefore saving money (as is typically the primary reason for offshoring)?

Work from one backlog (combine backlogs if working from more than one). Without specifying which team would do which story, have both onshore and offshore teams participate in sizing, or estimating, from one larger pool of user stories. You may do it together, or start by doing a few together and the rest separately. In the end, sample enough of the stories that both teams agree on how many story points various stories are.

At or before the planning meeting(s), randomize the stories or alternate each team getting whatever story is the next one pulled. At the end of the planning meeting, you'll have an estimated amount of work for each team, which gives you an idea. At the end of the sprint, you'll know for sure. Even with various issues (no product owner, newer/smaller/etc team), you'll have a number.

If you can't have both teams estimate and pull work without upfront planning or designating due to resource, knowledge, or other silos or barriers, I think you have other problems that Scrum will fix (if you want it and let it).

Thanks for all the great feedback from the first offshore post (and all the spam comments for offshoring ;-)

Why a ScrumMaster Might Lie

One question I ask in working with new groups or retrospectives is how far away is everyone now from where they were born. If we're talking about self-organization, I can ask the team to line up in that order, and watch the interactions go.

It's surprising to me how little we know about the teams we work with. That knowledge we gain, with sometimes only minutes of talking, pays dividends in a more trusting, productive working relationship and environment. 

I worked with one Project Manager turned ScrumMaster, and he was struggling with a decision the team wanted to make that he didn't agree with. He even went so far as to tell the team that their Director wanted it the ScrumMaster's way, which turned out to be not true. Not very good servant leadership. Management wondered if we needed to pull this guy out of the ScrumMaster role, for he had been an effective project manager, from what I understood. 

Then one night I ran into the ScrumMaster at Chili's and we shared a meal. In the course of that hour, I learned how he had come from a powerful Middle Eastern family. He was the eldest son and had high expecations put on him, a burden that he seemed trying to meet, thousands of miles away from his family, through work performance. All these details helped me see a fuller picture of this man who had been raised to make things happen and carry the full burden of responsibility himself. 

In this case, the struggle wasn't about Scrum, it was about a new personal definition of success and learning to trust. I would never have changed my coaching approach had I not stumbled across this new perspective of my teammate. 

ScrumMasters, I Hope You're Being Criticized!

This recent post, The Catch 22 of Criticism, was great. Here's why it matters to you.

ScrumMasters, one of the most powerful aspects of your role is that of Organizational Change Agent.

Whomever started your large company, he or she surely didn't say to themselves at the beginning, "You know, I'd really love to create a large, slow bureaucracy. That'd be awesome!"

Yet, the company grows. And adds dev, QA, and business analyst silos. And grows. And adds management layers. And grows. And adds project management layers. And grows. And suddenly management is wondering why it takes so long to get anything done.

As the change agent, you're giving constant, prompt feedback to what is keeping your product-focussed team from being super productive. And I've seen again and again pushback from those in the middle who are fearful, or resistant to change, or have other motives, or have something to "lose." But...

Don’t let it change what you’re doing entirely or who you are. You must understand the type of criticism, the story line, and the intentions. Don’t be reactive, simply sit back, enjoy the show.
The catch 22 is that if you’re being successful at pushing boundaries, you’ll get criticism. If you aren’t getting criticism, you’re not pushing hard enough or actually making change. So look at criticism as a gift, or a sign that you’re doing something right. 

By the way, I love the storyline mention. That's the topic of a session I proposed (and was accepted) at Agile 2013. More on that to come...

3 Reasons to Give Story Points to Defects

An agile manager recently asked if the teams in his department should size bugs, the same as they estimate user stories with story points.

My response was that I prefer to story point escaped bugs. Escaped defects are those not found within the sprint (because sprints should be zero-defects).

Sizing defects helps:

1. development teams get credit for the work that they do, which often can often include fixing bugs.
2. the Product Owner determine priority (maybe he doesn't really want to fix a defect for IE 5.5 users in Estonia if it means 40 points of work.
3. track another view of defect trends for your product (not just defect count but also total effort/complexity/doubt, priority when combined with feature requests, real progress trend, etc).

5 Things To Do on Your 1st Day as ScrumMaster

As I work with students in my Certified ScrumMaster classes, coming from all roles (developer, lead engineer, project manager, quality assurance, and on), I find there is perhaps a gap in clear next steps guidance.

Scrum helps teams to focus, but perhaps it's a bit overwhelming at first. Here's somethings you might consider on Day 1.

In Scrum, the first day or step in the process is a sprint planning meeting, but let's assume that you're not there yet, but simply have been told your you're now a ScrumMaster.

1. Are all your meetings (daily stand-up, planning, sprint review and retrospective) scheduled? What about grooming meetings? Check my blog post for ideas on a "day in the life of Scrum" calendar. Just having the dates for the meetings will help you and your team to focus. Will you have stories ready to demo at the sprint review? Maybe, maybe not, but it's better do something and then inspect then results, rather than wait until you or others feel ready.
2. Do we have a prioritized backlog of product backlog items (typically user stories, and the top ones with acceptance criteria)? If not, schedule a story brainstorming meeting with the Product Owner and team. To start, you only need enough work backlog to fill the first sprint, plus another one to two more. That gets you going. 
3. Do we have a Product Owner? Does that person understand what expected of them in this new role? Here are two videos - a short animated video on the Product Owner role, and an hour conference session on the Essential Product Owner that might help.
4. Do we have a team? Ideally five to nine members, dedicated (not shared on other projects), cross-functional (not a dev Scrum team, and a QA scrum team), and co-located (all in the same location and within talking distance). Any variations to this, and the challenges and likely weakened results should be communicated to the stakeholders and sponsors of the agile effort.
5. Has your team had agile training or experience? If not, I encourage you to set up an Introduction to Agile or Agile 101 type session. You may not feel qualified, but even walking through Mike Cohn's PowerPoint presentation Introduction to Scrum (and you can find lots of SlideShare and PDF's on this) will stir and help conversation, shared understanding and agreement. It might lower your anxiety and the expectations you put on yourself if you consider yourself less an instructor and more of a facilitator. I would expect at least one to two hours, but formal training is typically a day on this.

I also wrote a document for next steps after the ScrumMaster training. It is broad and beyond Day 1, but it might help.

Good luck, and enjoy the journey!

We're Distributed - Can Scrum Work for Us?

Another common question at my classes - "Our teams are distributed and remote. Can Scrum work for us?"

Before I answer that specific question, let me quote something recently that struck me -

When we're trying to make distributed work as well as co-located teams, why aren't the teams co-located? Is it to save money?

Henry Ford said that if he listened to what customers said they wanted, he would have given them faster horses. That's partly because customers will ask for what they think will solve their problem, but our job is to try to solve the problem. And if it's a complex problem, then our job is to plan on making multiple passes at a solution, evaluating the results each step of the way.

So, most of the time teams are distributed because they are outsourcing because management saw it as a strategic way to save money. Traditional management doesn't understand agile, how it works and how good it can be. It's often seen as a cost-cutting approach, as well. And you can imagine the frustration, and confusion, when management expects to add another layer of cost savings (agile) on top of outsourcing, when in actuality they are mostly in conflict. Perhaps a first step is to run an experiment with a team or teams fully co-located and measure their productivity.

Sadly, every time I've asked either how the company is measuring the cost savings, or how they even measure productivity of the teams, there's no answer. This might be a good opportunity to start.

As far as making your distributed team work. Did you ever have a long distance relationship? How well did that long-distance relationship work? For those whom it did work out for, what did they do? Most often they said, "This isn't working. We either move to the same city or call it quits." Okay, but in lieu of that, how much were you on the phone? How much did you visit each other?

Keep in mind, a lot of the following involve changing behavior, culture, how we work, opinions and raising the bar. Having said that small bit...

Best practices from a number of agile leaders from companies include:

• Most importantly, you must travel, at least yearly. Preferably quarterly. Both ways. One company measure the productivity increase at 50% after a 3 week visit by just a few people from the offshore team.
• Video chat. Given all the options and low cost, this should be a given. Have a webcam in all the meetings, and each team member should have one and ability for others to know when they're available. And get a good, hi def camera.
• Screen sharing. Expect developers to pull up the code with remote team members when discussing questions and issues. There are even people who pair program remotely most of the day.
• Collaborative design tools like Cacoo, and estimate together using planningpoker.com or everyone hitting the number key for their vote at the same time when conferencing.
• Dedicated desk or person place. Some teams keep a computer and webcam running for the remote person. If you need to talk, just walk over to them as if they were there. 
• Rolling video cart with multi-account video chat and large flat screen to have others join your team's meeting where ever it is. Cheaper than you think to build one yourself, and there are sites out there that provide the specs and how-to.
• You must have the all the meetings together, as much as possible. To show respect for the other team members, alternate who (onshore or offshore) has to be joining at odd hours. 

ScrumMasters, Be Different from the Inside Out

Reading up on Design Thinking, I came across this part of the process and was dumbfounded.

"Set aside emotion and ownership of ideas."

Oh, really? Is it that simple?

Personally, I've practiced self-awareness, servant leadership, and been coaching teams and individuals for years, and I struggle with setting aside emotion and ownership of ideas. What about people who don't even understand others, much less themselves?

And here's where I think Scrum and Agile struggle. We can teach the framework and values, but it doesn't equip us for

• the people issues, 
• the resistance to change, 
• the turf wars and politics, 
• and the fear, uncertainty and doubt that these newly minted ScrumMasters will face back at their organizations.

Besides the classic resources I would recommend, I can honestly say that I think the ScrumMaster or agile servant leader needs to be a different person from most of the people in the workplace, different inside than 95% of the people around them.

1. They need to be hopeful and believe they will prevail, regardless of the circumstances. And when bad things happen, they need to believe that good will come out of it.
2. They need to be patient, continuing to work and work towards the goals. Not patient in terms of days or weeks of not seeing results, but sometimes months or years.
3. They need to look for the good in people, while having firm and respectful boundaries that cordon off the bad.
4. They need to know the worst of humanity that impacts our efforts in the workplace - ego, selfishness, inability to admit mistakes or lack of knowledge, revenge, fear, control, but not react to these when they come out. 

Not should they not be naive about these negative aspects of the workplace we navigate. In fact, they will have even greater impact if they have been the victim of some of these abuses and not only come through it, but have no resentments. They dealt with the emotional baggage, have forgiven the person or people, and let it go. These are people that no how the game is played, don't get angry about that reality, and are still effective in getting immediate results with that environment, while slowly helping to change it and make it less dysfunctional. When South Africa began to deal with all the residue from apartheid, Desmond Tutu actually asked for just these sort of people to lead the cultural change.

Finally, they need to have a source of fulfillment that doesn't depend on their results - personally or with their projects, because these results may or may not come, not fully in this person's control. Yet they should still be a leader in that they always have something to give others, and they can if their personal tanks are full. This could come from their own personal growth, or how they've helped others grow.

We want these leaders in our workplace, but they are rare gems indeed. Be the change you want to see. Don't try to act like someone amazing, that will run out. But start becoming someone amazing, and then the actions just become natural.

Find a guide to help you grow:

• The Road Less Travelled - A classic text on personal growth
• Storyline - a new workbook to trackback the events in your life and how they are telling a story of your purpose here
• How People Grow - Thorough book by well known psychologist
• The Search for Significance - Another workbook that is a guide for finding significance over success

and be inspired - find some heros:

• Love Does: Discover a Secretly Incredible Life in an Ordinary World - A fun read by a surprisingly unconventional, almost wacky attorney who founded Restore International, a nonprofit human rights organization operating in Uganda and India.
• The Hiding Place - The riveting story of how a middle-aged Dutch watchmaker became a heroine of the Resistance and a survivor of Hitler's death camps.
• Kisses from Katie: A Story of Relentless Love and Redemption - An 18 year old leaves everything in American to start an orphanage in Uganda.
• Pranitha Timothy - Has lead dozens of rescue missions to free slaves.
• Freedom Writers - A movie about the teacher in the inner city who changed lives.
• Amazing Grace - The movie of William Wilberforce who began the movement to end slavery in Britain.

10 Most Used Resources in My Certified ScrumMaster Class

This is what I reference most often in my Certified Scrum Master training, or show during the lunch breaks in class. Enjoy!

Material Used in Class

1.     New Scrum Primer 2.0, from four Scrum Trainers - http://assets.scrumfoundation.com/downloads/1/scrumprimer20.pdf

2.     Agile Manifesto and 12 Principles - http://agilemanifesto.org/

3.     Do Better Scrum - http://www.scrumsense.com/resources/do-better-scrum

4.     Scrum Handbook – http://jeffsutherland.com/scrumhandbook.pdf

5.     (CSPO) User Story Primer - http://trailridgeconsulting.com/files/user-story-primer.pdf

Videos Often Shown in Class

1.     Marcus Buckingham, Strengths. We watched one of two videos:

a.     Trombone Player Wanted http://www.tmbc.com/assets/sc/go/tpw-player.html

b.     The Business Case for Strengths http://www.youtube.com/watch?v=1KeNfhw7bK0

2.     Daniel Pink on Motivation – The longer TED talk, and the RSA animated version on YouTube

3.     Simon Sinek, Start with Why – “Very, very few people or organizations know why they do what they do. And by "why" I don't mean, "to make a profit." That's a result.  By "why," I mean: What's your purpose? What's your cause? What's your belief? Why does your organization exist? Why do you get out of bed in the morning? And why should anyone care?” http://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action.html

4.     Agile Product Ownership in a Nutshell - http://blog.crisp.se/2012/10/25/henrikkniberg/agile-product-ownership-in-a-nutshell

Videos Related to Material Often Mentioned in Class

1.     Switch, How to Change When Change Is Hard - Heath 

a.     Want Your Organization to Change? - http://www.youtube.com/watch?v=JhBzxy7CneM 

b.     Why Change is So Hard - http://www.youtube.com/watch?v=RpiDWeRN4UA 

c.      How to Find the Bright Spots - http://www.youtube.com/watch?v=zbLNOS7MxFc 

d.     Shrink the Change - http://www.youtube.com/watch?v=j-iXOvkyAOk 

e.     It's the Situation, Not the Person - http://www.youtube.com/watch?v=Qp1_6hufkoU 

6 Common Wrong Ways to do Scrum

There's a lot of differences in how people are doing Scrum. Some (not many) differences are with the core framework, and more are outside of it. I get very concerned with any changes with the core framework.

If a company decides they need:

•  a role of Technical Product Owner or Proxy Product Owner, or 
•  a five week sprint, or 
•  a services team creating only web services for other teams, or 
•  a design team doing UX work, or 
•  an architect team doing look-ahead work, 
•  or are writing stories that span two sprints because the testing process alone takes over a week.

I want to talk with them about why. Although they are breaking part of the core framework, to me it's less about breaking the rules and more about violating the principles underneath why Scrum works, and to help them see and understand that. It's more important that they understand why Scrum works rather than are they or are they not following the rules.

For example, a team has a Technical Product Owner because neither the Product Owner nor team members understand the system well enough to make educated decisions. Do they want the team members to have that knowledge? They usually say yes. Then that is the goal (and the issue), and not the Technical Product Owner role. Ask why the work-around is there, and then see if that root cause shouldn't really be the focus and problem to solve.

Growing up, I was trained to turn the wheels when parking on a hill. I didn't understand the importance of that until one day I drove up the hill to school and saw what used to be Karen's VW bug. She had parked it at the top and but the parking brake had slipped, and the car had rolled down the hill, gained momentum and flipped several times. Had the tires been turned, the car would have just bumped in the curb and then stopped. Rules and principles can be disregarded if there's not an understanding and respect of why they're there.

For variations I've seen outside the Scrum framework, I'm interested but not always concerned. For example:

•  the user story format
•  how non-functional requirements are handled
•  the estimation point sequence
•  whether estimation is done using planning poker or team estimation
•  whether the stories are broken down into tasks or not
•  how project work is approved
•  the role of the Project Manager, managers or architects

These topics become conversations about what works best for the team, and that's who I'm primarily listening to. If it works for them, they'll do better work, and that's a win for the business.

A Sample iCal Calendar for Meetings in Scrum

In my Scrum training classes, one of the most common requests is that I draw up what a schedule might look like for all the meetings we've been talking about (Sprint Planning, Daily Scrum/Daily Stand-up, Sprint Review and Sprint Retrospective) in a two week sprint. I've created that sample here. Below, there are links to an iCal format for import into Microsoft Outlook and also a PDF version. On the iCal file, each meeting has a link to a description of the meeting, for additional reference.

Sample Sprint Calendar

The reason that I have sprints beginning and ending on Wednesday is mainly to avoid Monday and Friday due to common impact of people taking vacations, planning to be sick :-) or holidays. You could certainly use Tuesday or Thursday without much difference. Also, I have Sprint Planning and Sprint Review and Retrospectives happening on the same day. Although it makes for a very full day, that's what I commonly did as ScrumMaster with my teams. You could spread that over two days, but I choose to keep continuity over tiring people out (and in consideration of this, I did try to bring caffeine and sugar to the afternoon planning meetings).

Also, I wrote up a sample agenda for the Sprint Planning meeting. I plan to do the agendas for Sprint Review and Retrospectives as well.

• Sample Sprint meeting schedule - iCal format
• Sample Sprint meeting schedule - PDF file 

My Brother-in-Law Says Scrum Doesn't Work

The question inevitably comes up at my internal, or more often, at my public Scrum classes. "Does this really work? My brother-in-law worked over that Barf-o Software, and it was all messed up over there."

Deciding whether Scrum, or any other agile methodology, really works based solely or your or someone else's personal experience is anecdotal. It's the person who doesn't want kids because his brother's kids are out-of-control mini monsters, or doesn't like wiener dogs because one bit him when he was seven. For me, it was football. I didn't play because my brother said the coaches were mean to him when he was in 7th grade. I finally tried out my senior year and loved it. And the coaches weren't mean to me. Well, not very. I did have to run extra laps for talking to David Stewart when coach was talking to us.

Scrum works (better in some in contexts than others), but when it's going poorly, it's often because of 1) people doing Scrum wrong, 2) bad company culture, or 3) difficult team and project structure.

I've seen ScrumMasters (the role that should know Scrum the best, and therefore educating others) let the daily 15 minute Scrum go over 45 minutes, do planning poker estimating for each person's task for every story in the sprint, post a formula that showed the ratio of story points to developer and QA (it was 1 and .5, just so we all finally have the answer to that secret recipe), tell the team what their tasks would be, make every decision, lie to the team (FYI - that's bad), and more. Of course, this has an impact on the team. They don't do as well as the could, maybe even poorly. But that doesn't mean Scrum doesn't work. It means the ScrumMaster isn't doing it right. And worse, the team isn't owning the principle of continuous improve to work through these, and other, issues and get past them.

Secondly, bad company culture will make Scrum, and any other process, go poorly. Management that sets unrealistic deadlines on a project with fixed scope without asking the team for estimates will be bad for the team whether they do Scrum or traditional waterfall (although it won't be as bad with Scrum because at least you can tell management within two weeks that it looks like it's not all going to get done when they asked for it). Project managers who let every new change or request pass right through to the team without asking good questions or request priority or feature trade-offs when new, valid  needs are discovered will cause problems on any type of project. Some company cultures simply don't value the project teams, but hold to Theory X and see them solely as resources who need the whip cracked in order to get results. These executives will try Scrum because they hear it will get more results faster. But when they find out that these improvements (and others) come in part through self-organized and self-managing teams (who expect to be supported and empowered), senior management won't let go and trust, but instead tries to implement the Scrum practices without the Scrum and agile values. The results are predictably bad (and the teams upset, too boot).

Last, Scrum works best with cross-functional teams of people sitting together, and preferably kept together long term and fed different project. Once, a ScrumMaster was saying he felt his team wasn't gelling and collaborating well together. It turned out that every one of his team members lived in a different country. In Scrum, we work better and more efficiently in part because we move away from our functional team silos and heavier-than-needed process and towards individuals and interactions (just simply talking to each other more in order to solve problems and get stuff done). If you don't have that, it won't work as well. And that's not Scrum, that's your organizational structure. I've seem team members on a team matrixed on 17 different projects. How effective can you be, really, with 10% of your time on a given project? On paper, with some resourcing tool splitting everyone's time up, the math deceptively looks good. But in reality, ramping up and down daily on different projects and activities thrashes productivity. That's not a Scrum problem, that's someone somewhere not wanting to prioritize and say, "Really, these three initiatives are the most important. The other 14 will have to wait."

These, and other, challenges are some of the problems covered in the Certified ScrumMaster class. Scrum doesn't solve these people or culture problems for you. It simply makes the problems you have clear, and gives you great tools to show, if you change, how good things can be right away.

Should the ScrumMaster be Telling the Team How to Do our Work?

In a word, no. The Scrum Master is a servant to the team, not managing the team or their tasks. The Scrum Master should facilitate the team meetings, not tell people what to do. The Scrum Master should encourage and empower the team to solve their problems themselves, not inflicting their help by solving all real and perceived problems. The Scrum Master is the shepherd and guardian of the process - more of an evangelist and trustee than the Scrum Police or Scrum Boss.

The more the Scrum Master can back away from making sure work gets done, control things so that there are no problems or failures, or coordinate all the orchestration details of how things get done, the more the team can step in, step up and own the execution and delivery. One linchpin seems to be allowing the team to fail - giving them the freedom in a safe-to-fail environment (culturally and the framework of short sprints of small, shared stories), and trusting them to learn from it and get better.

In the end, no matter how smart and hard working one person is, nothing beats the power and smarts of a committed team working together and focused on a clear, shared goal.

Who Should Be the ScrumMaster?

Who should be or become the ScrumMaster for your new team? That is, which role: project manager, lead developer, functional manager, or anyone but one of these roles?

Although, understandably, most management wants a standard answer for who they should select to be the ScrumMaster in this new work paradigm, there is not a one-size-fits-all answer. And the reason is because it depends on the person, the team and the environment.

Before I walk through some of the roles, I think it's a good question to ask "Who is deciding who becomes ScrumMaster?" I see management decide often times, but they make the decision without knowing what Scrum is and, more importantly, how it works. The decision on who the ScrumMaster will be does not need to be made months, or even weeks, in advance. I've seen teams decide hours before their sprint begins. If at all possible, take this important decision to the team to see what they think. There needs to be prudence in this, certainly, but I'd rather lean towards making this statement of empowerment and trust of the team from the very start of adopting Scrum.

I commonly see Project Managers given the role of ScrumMaster, but there's a trade-off. What makes a great project manager may not make a great ScrumMaster. In fact, it might be counter. Often, management wants project managers who "get things done." That is, they drive performance. They push the team. They may even micro-manage for results and visibility by tracking every task, status, risk, change and deviation from the plan. And management might love this (or, more truthfully perhaps, love the results). On the other hand, I've also seen Project Managers who provide management what they want (helping get more productivity and more visibility to progress, issues and options) by serving, empowering and trusting the team. If you are currently a Project Manager, which type are you? My experience has been about 50% of project managers are on each side, with very few changing. For some, their "driver" approach impacted the team so badly that management was considering removing the person from the team.

I've seen managers also take on the ScrumMaster role. This, more often then project managers, has negative consequences, only the consequences are not so obvious, but these can be corrected more often and more easily than I've seen with project managers. Some managers, due to their company's culture and expectations, carry the responsibility of getting results from their people (for the projects their people are on). Along with this, many more are expected to make sure their direct reports are busy (that management is getting their money's worth from the employees). For these managers, even if they wanted to embrace the transformative qualities of the ScrumMaster, the company culture will push back, and most often win. For managers in these tough positions, I'd rather see them find someone else to be the ScrumMaster, and then the manager can focus more time and energy towards the bigger need of being a heat shield, organizational impediment remover and management mindset and company cultural change agent. Truthfully, that is the great need and value immediately and long term. For those managers not in culture or carrying those "busyness" mandates, and who have the right attitude towards their role and their team, I have seen great things happen. For these managers, this new role in the business and IT world of ScrumMaster opens new pathways to work with their team, provides new tools to let their people learn and grow, and fosters collaboration between their people. In many ways, this is what these managers were looking for in terms of moving away from needing to make sure things got done (which now the team commits to and owns getting things done), and wanting to focus on growing their people. For those managers wanting some book recommendations specifically for this new "Agile Manager" aspect of their work, take a look at my Agile Management and Leadership book list on Amazon.

My preferred option for whom should be the ScrumMaster is to look to those who are individual contributors (developer, lead developer, business analyst, QA). Ideally, the ScrumMaster is a fulltime role, which has the downside of giving up a fulltime employee. Again, this is contextual. The ScrumMaster will certainly need to be fulltime if the team (and/or company) is starting with agile, or if the project or product that the team is working on is fraught with challenges outside the scope of the basic context taught in my Certified ScrumMaster classes of a "single, co-located, cross-functional team." That is, if there are challenges of having multiple Scrum teams, or using offshore or remote team members, or a larger team, than the need of a ScrumMaster's time and help will be greater. On the other side of the scale, in a simple context, supportive environment, and/or experience ScrumMaster, I've seen the ScrumMaster still do 50% of his or her time doing development (or other tasks) as a player and coach. The biggest trade-off there is that the ScrumMaster needs to know their personal limits on commitment to tasks and stories they take on, as well as balancing personal and team focus. Not easy. 

I'll end with my favorite stories that illustrates what I'm really after when thinking of who should be the ScrumMaster on team. First, I was at a company that was deciding how much to grow their agile adoption. They had one team doing Scrum for six months with great results and a second team had just finished their fourth two-week iteration and was also doing well. The conversation among the executives came to a seemingly trivial point of who the ScrumMaster happened to be on the six month team. When a manager informed the executives that the ScrumMaster also happend to be the most junior developer on the team, there was unanimous appreciation and excitement about how this was exactly what the company wanted for it's culture - that anyone could make very significant contributions! 

My second story is from when I was working with a team that had a working agreement that included rotating the ScrumMaster every two months or so. After finishing their second rotation, at the meeting to decide whom would be next, the team unanimously, and quite noisily, voted to keep their current ScrumMaster. Forever. They loved her and how she helped them. She had grown to love the role and the team as well. And this was a person who was had a fair bit of self-doubt about even trying out the ScrumMaster role the first time, only agreeing to do it because of the guarantee of the ending (surely in failure, she assumed). 

It's stories like these that show how Scrum can help individuals, teams and companies thrive.

Scott recently posted an updated version of this post on the Rocket Nine Solutions blog: http://rocketninesolutions.com/implementing-the-scrummaster/

He also posted a companion piece: Who Should Be the Product Owner, http://rocketninesolutions.com/who-should-be-the-product-owner/

And you can find a video about it on http://rocketninesolutions.com/ as well.
http://youtu.be/4hqywLT0mWM

Common Scrum Questions

I recently did an agile overview for a company's IT group, and was again surprised by the number of questions that could be answered by someone attending a Certified ScrumMaster class and, living out the role as educator, lets the team and others know how and why Scrum works. I'll go through the more common questions on my blog over the next few weeks.

Here's a few questions I see commonly.

1. Who should be or become a ScrumMaster? That is, which role: project manager, lead developer, functional manager, anyone but one of these roles?

2. Should the ScrumMaster be telling us how to do our work?

3. Does Scrum really work? I had a friend that worked over that Company X, and it was all messed up over there.

4. What's the right way to do Scrum? I worked at Company Y where they did Scrum, and my friend at Company Z does it a different way.

5. What about budget?

6. Our teams are distributed and remote. Can Scrum work for us?

7. How long until we start to see improvement?

8. Should we still have project managers and a PMO (project management office)?

9. I'm in QA, and this Scrum stuff stinks for me. I'd rather have it the old waterfall way.

10. Do we still need to do requirements in agile?

11. We don't have a Product Owner, but we know what needs to be done. Can we still do Scrum?

12. Management says we still have to hit deadlines that were set 15 years ago. Isn't that not really agile?

13. Is the ScrumMaster a fulltime role? What about what I used to do?

14. What if some of our work is dependent on people in other departments, like Operations (and they don't care that we're in two week sprints!)?

15. What if there are dependencies on other Scrum teams, and our commitment is dependent on them getting their stories done?

16. How do we do good architecture without doing some sort of good (or good enough) design upfront?

17. What do we do if our stories aren't complete at the end of our sprint?

I'll answer these, and more, over the next few weeks.

It's Not Scrum, It's You

I was recently teaching a Certified Scrum Master class and was told by a student that Scrum didn't work because management still comes and demands additional features or projects and sets or keeps the deadlines and not asking for estimates of how long it will take. 

That is not a Scrum problem. That's a business environment problem. And the solution is often the person lamenting it the most. Perhaps it's like the guy that complains about women because he is married to someone who makes demands and doesn't respect him. It's not women that's the problem, it's his allowing his wife to control him. 

These are the type of complex organizational development problems that are difficult to solve. They take more than a two day class on Scrum fundamentals to solve. They may be very difficult and take a long time, but they are possible. Don't think that they are not. There is a world of difference in the mindsets behind possible and impossible.

If you fall into the trap that they are impossible, you give up trying - looking for possibilities, options, trying out new ideas. You lose hope. Certainly if you are a leader, it is incumbent upon you for the sake of the people who follow you. The book Strengths Based Leadership lists the four needs workers have of their leaders: hope, stability, compassion and trust. If you are an agilist, you are acting as a servant leader, and therefore need to maintain hope. 

I couldn't tell this student how to solve his problem - that's contextual and that's why there are coaches helping organizations with these types of cultural and management changes. Even without a coach helping, there's a lot of places to look for good information on this.

But you won't take that first step if you are stuck thinking it's impossible. 

Strengths of a ScrumMaster

In previous posts, I listed some introductory material on strengths and how to start the process of beginning to build a strengths-based agile team. The next deeper and more powerful step in the process is working with team members one-on-one through the lens of their specific strengths.

When speaking at events, or after facilitating taking the profile test and walking through the results, I am often asked "What strengths do good ScrumMasters have?" I think there could be a good number of different strengths, depending on how the individual leverages them, the make-up of the team and projects needs and the surrounding organization. I'll list several that I think are good or that I've seen leveraged well. I've also listed strengths that "pair well", balance and support, that strength. These could be other strengths that individual has, or strengths that other team members have. In the latter case, those team members need to be interacting and working closely enough together that those strengths come to play directly and collaboratively with the ScrumMaster. I think that a strength not being leveraged specifically when it's needed is like the superhero not responding to the call.

Some Strengths of a Good ScrumMaster
Belief
Belief is good for several reasons. One, I think believing in something, truly believing in it, is infectious. It spreads. Other people can't help but catch it, find out about it, get interested in it when they're around people who are staunch believers in it. Also Belief is great for ScrumMasters because people will surely have good questions, raise tough issues and even come against you. Your rock solid Belief will handle these, and often people need to see there is something real beneath what they see as the latest business fad or self-serving or just not well though through (which in all fairness does happen in our workplaces ). And sometimes it's only your belief in something that carries you through the hard times. And we all know that doing Scrum, and adopting agile in the bigger picture, can be quite difficult.

Pairs nicely with Woo so that you're winning people over to what you believe, and also pairs well with Leaner and/or Input so that you are always taking in information that fills out and supports your belief. That way you can engage in informative dialog rather than "because I/they/boss/Santa Claus said so, that's why" belligerent debates. Also, Learner/Input will broaden what you believer in, so that you become just as much a true believer in, say, test-driven development or continuous integration, as having retrospectives.

Futuristic
Another strength that can pull you through the difficult times and challenges is Futuristic - the ability to really see what could be. That vision should, of course, be shaped and defined by Scrum and agile, and related areas, so it also pairs well with Learner and/or Input. But where Belief is contagious because it provides a solid rock, Futuristic is contagious because it pulls people forward, positively, toward the vision. This is effective in good times and bad, because you can always move forward, ahead. To say Futuristic is important for leadership is an understatement because people, and especially teams, want to get behind, support and follow a vision. Paint that picture you see (cast the vision) repeatedly because vision does leak - life gets in the way and distracts people.

Input
Input is great simply because there is so much to learn, and to quote S.H.R., "it's great to learn, 'cause knowledge is power." As the ScrumMaster understands what's happening at a detail level in his team (with the QA tests, with the designers dealing with the outside vendor) or his company (with management decision making process, and new market they are consider) or with agile (the best books, good blogs), all those bits of information are fuel for good decisions at some later, who-knows-what time. Some people are good at listening and collecting information, but only when they know (or think) it's important information or an important time. As humans though, we make mistakes in judgement (such as what we deem 'important') and timing, much less simply missing information. On top of all of this, frequently it is the most specific details that have the truest value - such as the difference between getting an error versus no response on the call, or there's a new open source CI tool, or which server the problem was on, or that the newest version of the Spring framework coming out in five days can consume XHTML natively (I made that up). But the wonderful thing about Input folks is that they can't turn off the collecting machine. And as a ScrumMaster, this strength can be grown to take in all these great details all the time, every day from every team member and then, like a pollinator, carry it around to other teams, stakeholders, and resources to help them: make better decisions, solve problems, collaborate, raise the bar, help YOUR team.

Input pairs well with strengths that give it guidance and/or limits. Otherwise, the Input can be on the web gathering information for hours. And hours. And hours (trust me, I know this…). So, good with Deliberative, Maximizer, Activator, Achiever.
When paired with Relator, it might yield someone who likes to learn about others, which makes everyone on the team feel loved. Not a bad thing. Input also feeds Belief and Futuristic.

Maximizer
Going from good to great, that's the Maximizer. If you don't think you're group is even at "good", then consider that the fact you are there and know what you know means they are already better than they were before. That's good. Striving for excellence will propel you and the team forward through whatever means you have, whether forming allies, relationship, or using the other strengths you have. Watch that you don't get discouraged because the goal is so far away or hard to reach. Don't become frustrated with others who don't "get it" that we should do X, Y and Z (obviously!). Break down your goal into smaller, attainable pieces. Limit your work in progress to perhaps only focus on a couple items, areas or people. Learn to look for, and celebrate each step towards those.

Pairs well with some form of getting information in order to know what "best" is. That could be Input, Learner, Relator, Harmony, Empathy, Connectedness.

Relator
In the end, it's all about people, and here's where the Relator is powerful and effective. It the personal relationships that the Relator will form that will influence others to come to the meetings on time, try the new method of writing tests, be willing to hear out the person they're frustrated with, get management to agree to pay for the celebration meals, get the Product Owner to show up at the daily stand-up. More than that, though, the Relator is able to see what's in people that is causing them to either impede the agile adoption, or even just personally holding themselves back on the team. When we're running around dealing with people problems (and it's said that all problems in software are people problems), often the "issue" isn't the issue. For example, the problem isn't that testers don't have enough time, it's that the QA Manager hasn't been walked through the new approach slowly enough that he fully understands it and knows that the change isn't really a risk and that nothing bad will happen to his people (making him a bad manager, right?) or upset them with the changes so much that they are all freaking out and giving him more of a headache than it's worth (i.e., it would be easier to stonewall you with "problems" and "risk" and "process"). But imagine the change when he knows you genuinely care about him, how he does, and you understand that he has a team to look after, and that you want him to do a good job at that, and you have his best interests at heart, and will be there if there's any problems, questions or just to help. Wow. He can step forward now, even without all the answers. Even knowing there will surely be some issues.

In every problem and discussion that adopting Scrum brings about, or each new project, or even each new sprint, Relator comes to bear. Being present. Listening. Caring. Connecting. Which is to say, investing in others. And all those investments are money the Relator can borrow when he needs help, an extra effort, grace, trust, the benefit of the doubt, willingness.

Relator pairs well with those strengths that would shape and direct it. Otherwise, it can just sit there being "present" with anybody and everybody, not helping anything move forward. Maximizer, Strategic, Input, Learner, Deliberative, Futuristic, Restorative and perhaps the other feeling strengths Empathy and Harmony.


There are some other strengths that I will add later and update this same post.
Technorati Tags: agile, scrum

Salesforce.com's Success with Agile

Perhaps the best slideshow I have seen on agile implementation\agile adoption in the enterprise.

• How do you roll-out Scrum?
• How do teams learn Scrum?
• Are there metrics or proof that agile works?
• How do you get executives to buy-in?
• What about the problems with Scrum or some saying that Scrum is failing?
• What is the role of agile coaches?
• How many product managers should go to product owner training?
• What does successful agile adoption look like?

From the Scrum Gathering conference of 2008 in Chicago, presented by Salesforce.com, titled "A Year of Living Dangerously".

The Year of Living Dangerously: Extraordinary Results for an Enterprise Agile Revolution

View more presentations from Steve Greene.

Technorati Tags: agile, scrum, management, saas, web2.0

Offshore Agile Teams

Good webcast on offshore development teams using agile (perhaps Scrum). The image below shows the medicine that must be taken - colocated teams. Although it sounds like a tough sell, companies that have done this report not only good results but positive experiences from team members.

The notes in red are mine, pointing out the fact that most offshore teams that I have worked with or know people involved with are operating in a dysfunctional structure.

Technorati Tags: agile, offshore, Scrum, software development

Iteration vs Release Planning

Saw this simple sprint iteration and releases comparison chart in a Rally training page. I like the line on the difference of focus - release is "what" and iteration is "how." Just keeping that in mind will help guide sprint planning meetings much better. Also, given that the focus of sprint planning is task-estimating, not story-writing, the assumption is that the top of the product backlog (sprint backlog) is well groomed. Taken from Rally's Agile Planning Step-by-Step Guides.

Technorati Tags: agile, scrum, project management

Should ScrumMasters Code?

One of my mentor's believed that ScrumMasters should be programming as part of their general duties. If you're in IT, it's likely you know some piece of the programming being done, and if not, have the ability to learn some small aspect (SQL, scripting, batch files, etc).

As I finish up my first Rails project several months ago, I learned a number of things. In the end, I switched my laptop over to a dual-boot Windows\Ubuntu machine. I'm been using Ubuntu ever since, and only had to use Windows for old specialty apps (and even those now have web-based versions). I'm emailing, exchanging and editing documents, tracking bugs, organizing and prioritizing work all from Ubuntu. The boot time is faster, installing apps is easier, and viewing all my windows greater in Ubuntu.

I went to Ubuntu in order to get the developer's web site up and running on my machine. Along the way, I've learned about Subversion and Git, production vs. dev mode on Rails, and how configurations are saved and published (or held).

On my current project, I've started using soapUI to help do some testing for the QA team members. By reading a few pages of the documentation, I learned how to automate the tests and use XPath to confirm data items in the responses. Just getting that hands-on to know the versions of our WSDLs, the endpoint changes, seeing data and changes in the payload gave me a deeper and stronger understanding of the work (and challenges) of what the team is trying to accomplish.

I have a renewed belief that the agile project manager is much more effective when their hands are in the code at least some small percent of the time.

If you're a ScrumMaster, are you doing any programming? Would it help? If so, how? If no, why not? If you're not a ScrumMaster, but a team member, how would you feel about your ScrumMaster getting involved in this way? What if it meant asking more questions, learning and perhaps even making some mistakes?

Technorati Tags: scrum, project management, agile, scrummaster, programming