tag:blogger.com,1999:blog-74734108474042175722024-03-05T10:53:33.127-08:00Unscrum Hero | Scrum & Agile Development BlogThe Professional Life of a ScrumMasterTim Shttp://www.blogger.com/profile/06142698548560602518noreply@blogger.comBlogger17125tag:blogger.com,1999:blog-7473410847404217572.post-15396751213885473542017-10-11T12:53:00.000-07:002017-10-11T12:53:27.846-07:00Qualities of a Healthy Relationship Between Engineering and Product<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi89ioqJvBuOx1_gWCzvW1RYCwejICL5deEJDJo6Nfs0MG-uGRishReJSmyshTQH8_tEDYbY48eUzYQrUT0xkucz-EUmlPf7faWHTuWdWuDFADCZ2tQjXO_K0BT-yazYil5Q1_MAEn1s-Mj/s1600/ProductOwnerAndStakeholders.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" data-original-height="798" data-original-width="1030" height="247" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi89ioqJvBuOx1_gWCzvW1RYCwejICL5deEJDJo6Nfs0MG-uGRishReJSmyshTQH8_tEDYbY48eUzYQrUT0xkucz-EUmlPf7faWHTuWdWuDFADCZ2tQjXO_K0BT-yazYil5Q1_MAEn1s-Mj/s320/ProductOwnerAndStakeholders.png" width="320" /></a></div>
Early in my career in software development as I reflected on what makes a great product, I began to formulate the opinion that success was 90% engineering and 10% everyone else. What I mean by this is that if the engineering team was top class: filled with talented people, had great coding standards, embraced testing, had seamless continuous integration, etc that you would most likely have an amazing product.<br />
<br />
Now keep in mind, as a former developer, I was biased. Heavily biased.<br />
<br />
As my career progressed, I began to appreciate more and more the impact product managers and their teams can have in the overall quality and success of the product. I learned that you can have a rock-solid piece of software that has 100% test coverage and is functionally sound yet fails miserably in the market.<br />
<br />
I learned that if you really want to have a successful product, you need a healthy relationship between Product and Engineering.<br />
<br />
What does that look like?<br />
<br />
<h3>
Product Owners are team members</h3>
Are Product Owners really considered members of the team? The Scrum Guide,” clearly states that the "Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master," so it should be a settled matter yet much digital ink has been spilled on this point alone. And I don't think it's a trivial one.<br />
<br />
Many think that it's the ScrumMaster's job to handle the details throughout the sprint while the Product Owner (PO) goes back to their market research and wire-framing. This is not the case. Product Owners are the "CEO" of the product. While the success or failure of the product falls on everyone's shoulders, there is an extra amount of ownership and responsibility that rests on Product. Therefore, when some decisions need to be made during a sprint, such as negotiations on specs, the PO needs to be ridiculously available for these discussions.<br />
<br />
The PO should be an ever-present figure who is there for their product. This means the PO shows up at most of the stand-ups, sits in on retrospectives, and is physically located (when possible) near where the work is being done.<br />
<br />
Product simply doesn't hand off specifications and user stories to the development team then disappear for two weeks until demo time. This is a sure-sign of an unhealthy relationship that will ruin your product.<br />
<br />
<h3>
Product Owners and ScrumMasters are best friends</h3>
Professional best friends, anyways. What does this look like? It means that the ScrumMaster (SM) and the PO spend a lot of their time throughout the day together.<br />
<br />
Why do ScrumMasters and Product Owners need to spend time together? Two primary reasons:<br />
<br />
<ol>
<li>The SM should know almost as much about the product as the PO (yup, I said it).</li>
<li>The PO should know exactly how groomed the backlog should be for the development team to successfully build what they want.</li>
</ol>
<div>
These two facets can often times feel unnatural since the SM isn't normally as strategic and the PO not as tactical in the way they approach their jobs but they are areas both <i>need</i> to learn in order for their careers to thrive. </div>
<div>
<br /></div>
<div>
The better the SM can understand the product, the more effective he will be in identifying if the team is making the right kind of progress. The SM can also make better decisions with the team in the absence of the PO. </div>
<div>
<br /></div>
<br />
The better the PO can understand the level of story detail required to direct development the more efficiently engineering can go about their days. UAC should be defined for all known requirements. Not only will this show the team if they sufficiently completed a task, but QA will be using UAC to help build their tests. This drives the whole team forward to their shared goal of a successful release.<br />
<br />
As I mentioned before, these skills may not come naturally for the SM or PO, so it's the job of the Agile Coach to make sure the PO is educating the SM on the Product and the SM is educating the PO on the level of granularity acceptable for each story.<br />
<br />
I could go on at length on this topic, but if this relationship doesn't work, then the product will fail.<br />
<br />
<h3>
Product Owners and the team share the spoils of victory.... and blame in defeat</h3>
<div>
We're all in this together. And this all seems pretty obvious, but often times there are devastating rifts that can grow between Product and Engineering if we're not careful.</div>
<div>
<br /></div>
<div>
This is where good coaching comes in very handy. An effective Agile Coach can catch symptoms before it blows into a full-blown disease. Ask yourselves these questions:</div>
<div>
<ul>
<li>Who is writing the user stories? If it's the SM by his lonesome, you have a problem.</li>
<li>At what point in the process is the PO getting her hands on some version of the product? If it's at the end or around demo time, you have a problem.</li>
<li>Who owns and grooms the backlog? If it's your ScrumMaster alone, you have a problem.</li>
<li>What do retrospectives reveal about the health of the Product/Engineering relationship? If the team provides feedback around not being provided timely or detailed enough information from Product, you have a problem.</li>
<li>Can the SM effectively describe the product, its features, and where it's headed in 30, 90, 120 days? If not, you have a problem.</li>
<li>How often are the SM and PO seen collaborating? If these two appear more like ships passing in the night, you have a problem.</li>
</ul>
<div>
While there are many nuances to this relationship, it's now very clear to me after over 10 years of software experience that the ScrumMaster/Product Owner relationship can make or break your product. </div>
<div>
<br /></div>
<div>
How do your ScrumMasters and Product Owners get along?</div>
</div>
Tim Shttp://www.blogger.com/profile/06142698548560602518noreply@blogger.com0tag:blogger.com,1999:blog-7473410847404217572.post-8758171316835486702017-10-09T10:42:00.003-07:002017-10-09T16:12:09.729-07:00Are There Too Many Meetings in Agile Software Development?<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhn7_8moSB-BWjTlbk0J3cEndNozISUns6PiJA-Z_u-2KScjfxeL5xpBzMOaZR8PA-lPLwrEMzBcV8XKC0SSLpZgXXjdzZvT7NodfAyncvga5SBJsjnpUGu95nWi11tEFZNlC4zwqB5JI6E/s1600/boring-meetings-made-better.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" data-original-height="345" data-original-width="590" height="187" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhn7_8moSB-BWjTlbk0J3cEndNozISUns6PiJA-Z_u-2KScjfxeL5xpBzMOaZR8PA-lPLwrEMzBcV8XKC0SSLpZgXXjdzZvT7NodfAyncvga5SBJsjnpUGu95nWi11tEFZNlC4zwqB5JI6E/s320/boring-meetings-made-better.jpg" width="320" /></a></div>
I happened across an article that was suggested to me by Google written by someone in the software industry complaining that there were too many meetings in Agile software development, particularly in Scrum.<br />
<br />
In searching for the article so I could post the link here (with no luck), I found there's no shortages of articles containing people complaining about the amount of meetings as well as from those Agilists in defense of their framework.<br />
<br />
In thinking about this problem, I boiled it down to three questions:<br />
<ol>
<li>Who are the people complaining about the amount of meetings?</li>
<li>What is the core problem when people discuss meetings like this?</li>
<li>What can be done within the Agile framework?</li>
</ol>
<h3>
Who are the people complaining about the amount of meetings in agile software development?</h3>
<div>
Traditionally, when a company or team announces a desire to move to Agile software development, the framework of Scrum initially is on everyone's radar. When you attend ScrumMaster Certification training, the basic list of meetings is this:</div>
<div>
<ul>
<li>Daily stand-up</li>
<li>Sprint planning</li>
<li>Backlog grooming</li>
<li>Demo</li>
<li>Retrospective</li>
</ul>
<div>
Depending on your deployment process, you may have a release warroom-type meeting where the entire team is holed-up until code is released, tests pass, and all systems are green. (These "meetings" often suck)</div>
</div>
<div>
<br /></div>
<div>
When looking at the prospect of all those meetings that the team will have to embrace it's the engineers who generally start complaining to themselves about spending half of their week in meetings. </div>
<div>
<br /></div>
<div>
Being a ScrumMaster, I can't blame the team for this. As I've written before, I too <a href="https://www.business.com/articles/hate-meetings-4-hacks-ease-pain/">hate meetings</a>. Usually they are poorly organized, little to no preparation had done by facilitators beforehand, unnecessary participants are invited and not allowed to leave, and they drag on forever! Engineers are paid well because they are good at what they do.... building things. They want to be at their desks building things, and they should be!</div>
<div>
<br /></div>
<div>
When teams start openly deriding meetings, ScrumMasters can often receive that feedback as personal criticism, since it's sadly one of our tasks to round people up for meetings (maybe it shouldn't be, in a perfect world). Perhaps this is why ScrumMasters call meetings 'ceremonies'. We're not fooling anyone though; these are meetings. If not handled correctly, indeed the team will blame you for the meetings being so awful, so pay attention!</div>
<div>
<br /></div>
<div>
This is why good ScrumMasters are adept at identifying the core issue, which really aren't the number of meetings themselves.</div>
<div>
<br /></div>
<h3>
What is the core problem when engineers are complaining about too many meetings?</h3>
<div>
<div>
Yes, engineers need to be engineering but the plain fact of the matter is that meetings <i>need</i> to occur in order for the team to best know what they are trying to accomplish. You just can't get around that. There simply has to be planning; no one will be able to deny that.</div>
</div>
<div>
<br /></div>
<div>
The real problem behind the meeting complaint is not the number of meetings, but that <u>too much time is taken up with poorly prepared meetings</u>.</div>
<div>
<br /></div>
<div>
In my career, I've seen it all with regards to meetings. I've made all of the bad mistakes that are still sadly so prominent in software teams throughout the world. I've seen the "let's set apart mornings for meetings so we can work in the afternoon." I've been a part of the dreadful 6-hour sprint planning meetings that lead to so much soul-crushing.</div>
<div>
<br /></div>
<div>
These are dead giveaways that your software developers probably are frustrated at their companies.</div>
<div>
<br /></div>
<div>
This is one very important problem the ScrumMaster needs to be actively solving or risk losing the trust of their team.</div>
<div>
<br /></div>
<h3>
What can be done about awful meetings within the Agile framework?</h3>
<div>
<b><span style="color: red;">Keep. Meetings. Short.</span></b> Live by this motto; embrace this motto; weave it into the culture of your team. When I work with new teams, one way I get engineers excited about my being there is the promise that "I am going to ensure our meetings are no longer than 50 minutes." After about 50 minutes, people start to fade and the meeting loses its effectiveness exponentially.</div>
<div>
<br /></div>
<div>
Many people (mostly team members) will be excited at your seemingly bold claim. Some (mostly managers) will be skeptical. (After all, it's not uncommon for certain professionals to validate their usefulness by the number and length of meetings they facilitate.)</div>
<div>
<br /></div>
<div>
How can this be done?</div>
<div>
<br /></div>
<div>
Well, you don't start immediately, especially if long meetings are ensconced in the culture. You declare to the team that this is the goal we will be working towards and hopefully within the quarter, all meetings will indeed be down to 50 minutes or less.</div>
<div>
<br /></div>
<div>
One of the key ways this will be accomplished is through the unsung hero of agile meetings: backlog grooming. If you have painfully long sprint planning meetings, it's probably because the team doesn't groom well or at all.</div>
<div>
<br /></div>
<div>
If the team is <u>grooming in multiple short-bursts</u> in the run-up to the sprint, your planning meetings should be really short. The team should already be familiar with the stories at the top of the backlog. They should have already thought through key areas in how they will approach their solution. User Acceptance Criteria will have already been defined and thus QA will have been planning their tests in advance. Estimates are already made and agreed upon so we don't sit there and haggle for 15 minutes on each story.</div>
<div>
<br /></div>
<div>
How often you need to be grooming is up to the team, but the goal is to get the things at the top of the backlog refined in such detail that at the start of a sprint the team can immediately begin working. I wouldn't worry too much about grooming stories that may come into view more than a sprint or two down the line. It's just not worth it at this stage because things are so fluid in software development.</div>
<div>
<br /></div>
<div>
While engineers may initially balk at the thought of having yet even <i>more</i> grooming meetings, you will convert them into believers when you are in and out of a planning meeting in 15 minutes.</div>
<div>
<br /></div>
<div>
<i><b>Tip</b>: in order to not disrupt the artistic focus of the development team, try scheduling grooming meetings right after lunch or at the end of the day. </i></div>
<div>
<i><br /></i></div>
<div>
If you're grooming well and following a more 'kanban-style' approach, you may simply remove the sprint planning meeting altogether. Victory! (Just don't leave out the retrospective)</div>
<div>
<br /></div>
<div>
While all of this concern about meetings may seem trivial, it's really strikes at the heart of Agile software development which values the minimal amount of overhead in order to produce something of quality. Finding that balance is unique to every team, but rest assured if your team is spending over 25% of their time in meetings, not only are you not maximizing their value, but they're also likely unhappy with their jobs.</div>
<div>
<br /></div>
<div>
Ignore meeting optimization at your own peril.</div>
Tim Shttp://www.blogger.com/profile/06142698548560602518noreply@blogger.com1tag:blogger.com,1999:blog-7473410847404217572.post-38405108220987617812016-03-24T15:02:00.001-07:002016-04-07T05:21:21.545-07:00A Feel Good RetrospectiveIf you're not careful, retrospectives can sometimes feel like work or routine for your team. Chances are that if you see the retrospective on your calendar and think to yourself "ugh, another retrospective," that your team is saying the same among themselves. This is a sure indication of the need to freshen things up.<br />
<br />
A problem with freshening up your retrospective format is that many of them are pretty derivative. How many times have you tried to find a new format and come up with the "pretend your team is a hot air balloon or pretend your team is a boat" type of retrospective? Not very original and you're not fooling the team by changing your boat into a rocket ship. It's the same exercise.<br />
<br />
Most retrospectives end up with the team being told to identify some problems and a solution or two for these problems. Yay. We all get it.<br />
<br />
Having felt like this over our past few retrospectives I did lots of research to find something, <i>anything, </i>different. Lo and behold I came across a retrospective format on respected Agile evangelist and speaker Ben Linders' website.<br />
<br />
It's called the <a href="http://www.benlinders.com/2015/exploring-strengths-with-core-qualities/" target="_blank">Core Qualities retrospective</a> which focuses on identifying each team's members strengths and then aligning them with problems your team is facing.<br />
<br />
While we didn't come away with any takeaways (we ran out of time and I'm a stickler for schedule), I feel like this was one of our most enjoyable and beneficial retrospectives ever. In my almost five years at Business.com, I can't recall a time during a retrospective that our team members smiled and laughed so much. I found myself also grinning ear-to-ear as we went around and talked about the qualities we appreciate in one another.<br />
<br />
People simply don't get enough praise and appreciation in their lives (especially at work) and this exercise was really powerful for the team. I can honestly say that despite the fact that no problems were surfaced and no solutions provided our team came out of that room as tighter-knit group. It may sound sappy, but there you have it.<br />
<br />
Here is our tangible output:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhmGvd_TUQ_l-QMm-pKUynGmBZfMpYfXKUXMfEkzDj7J3AD8FseKqbTl7uz8keVGmXn6_hMYyOnIuIBhrr-fLq-LIrtUocDjZvPvuu7XttQ6B1HRHGZ4mFycN2ZqB9YisN5yTVQnBuJHh2t/s1600/20160317_162954.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="360" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhmGvd_TUQ_l-QMm-pKUynGmBZfMpYfXKUXMfEkzDj7J3AD8FseKqbTl7uz8keVGmXn6_hMYyOnIuIBhrr-fLq-LIrtUocDjZvPvuu7XttQ6B1HRHGZ4mFycN2ZqB9YisN5yTVQnBuJHh2t/s640/20160317_162954.jpg" width="640" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
How can you not feel good about seeing words like that under your name? (BTW I got helpful, organized, concerned, disciplined, flexible.... not bad for a ScrumMaster ;) )</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
So if your team is feeling a bit burned out on retrospectives I highly suggest giving this one a shot and your team will be able to reestablish why you all work together. You've got nothing to lose and I assure you that your team members will feel appreciated. What more do we want at work?</div>
<br />Unknownnoreply@blogger.com4tag:blogger.com,1999:blog-7473410847404217572.post-43029105886506700772014-09-18T12:18:00.002-07:002014-09-18T12:19:39.459-07:00Scrum and Large Projects; Yes They Work Well Together"Does Scrum work on large projects?" is a question that I often wondered throughout my career. I've participated in a lot of large projects which started off as Scrum but then morphed into some weird waterfally/agile hybrid mess. These types of projects still had bi-monthly planning, demo, and retrospective meetings but only had a singular release. We found these frustrating projects to be a part of because they usually ran long and were really buggy when launched.<br />
<br />
Because of our previous failed attempts, I had all but reserved myself to the grim reality that Scrum probably wasn't the most ideal methodology for projects that take at least 6 months and touch many different parts of your application. But that's only the start of the story.<br />
<br />
In the beginning of 2014, our development team was tasked with a large rebuild of Business.com, including; big data visitor intention profiling, a custom content management & tagging system for content publishing, overhauled site architecture, and more. I was skeptical that we'd be able to pull off a single public release while also continuing to adhere to the principles of Scrum, but we did it and learned lots of lessons in the process.<br />
<br />
I wrote an article about the <a href="http://www.business.com/technology/disrupt-the-market-with-agile-development/" target="_blank">agile development lessons learned on a large project</a>. If your team is embarking on a large project and you understand that benefits that Scrum brings to your organization, read the above link so you don't have to learn the lessons the hard way, as we did.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-7473410847404217572.post-8358378941005384592014-02-27T14:38:00.001-08:002014-02-27T14:40:31.488-08:00Are Your Agile Retrospectives Growing Stale?The other day I stumbled upon Michael James' <a href="http://www.scrumalliance.org/community/articles/2010/november/an-example-scrummaster-s-checklist" target="_blank">ScrumMaster Checklist</a> and decided to fill out and see where we were at as an agile team. While I'm not going to go into detail, there were some things that caused a great deal of self-reflection for me; in particular:<br />
<blockquote class="tr_bq">
Have you tried a variety of formats and locations for Sprint Retrospective Meetings?</blockquote>
This is something I've been wanting to do since last time I decided to <a href="http://how%20to%20breathe%20life%20in%20your%20retrospectives/" target="_blank">breathe life into our agile retrospectives </a>with great success. While this method has been a tremendous format for gathering feedback on the previous sprint, it seems that the team is getting a little too familiar with how it's supposed to go. Another problem is certain team members struggle to think of two positives and negatives in advance of the meeting so we waste time as they frantically try to get something on paper.<br />
<br />
In researching different formats that people have used, I stumbled across this list of <a href="http://retrospectivewiki.org/index.php?title=6_Thinking_Hats_Retrospective" target="_blank">agile retrospective formats</a> and think I'll be rolling out the <a href="http://blog.robbowley.net/2009/08/29/6-thinking-hats-retrospective-plan/" target="_blank">6 Thinking Hats Retrospective Plan</a> for next week's retro. I'll be posting my experiment on my blog when the results are in!<br />
<br />
What kind of formats have you used in your retrospectives? Any thoughts or suggestions are much desired.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-7473410847404217572.post-76429165260936652112014-02-20T10:12:00.001-08:002014-02-20T10:16:17.216-08:00Agile Manifesto in One Simple Image<div class="separator" style="clear: both; text-align: center;">
</div>
I ran across this tweet today and loved it.<br />
<br />
<blockquote class="twitter-tweet" lang="en">
Our "product" after a day of certified <a href="https://twitter.com/search?q=%23scrum&src=hash">#scrum</a> master training <a href="https://twitter.com/search?q=%23agile&src=hash">#agile</a> <a href="https://twitter.com/scrum_coach">@scrum_coach</a> <a href="https://twitter.com/macterry">@macterry</a> <a href="http://t.co/3PClFEuJTk">pic.twitter.com/3PClFEuJTk</a><br />
— Ryan Rhoten (@RyanRhoten) <a href="https://twitter.com/RyanRhoten/statuses/436305955232288768">February 20, 2014</a></blockquote>
<script async="" charset="utf-8" src="//platform.twitter.com/widgets.js"></script>
<br />
I couldn't think of a simpler yet effective summary of the goals of agile software development.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-7473410847404217572.post-76686112991572343422014-02-18T10:02:00.003-08:002014-02-18T10:03:37.290-08:00A Useful Resource to Share With Your Boss or Customers About Estimation<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgYp4MGw3jM1xvcBEM0x5v0yPXYrIx3d9tVKLWEVPO1xQBH9VIwQgoq_Zzjaa4ttaR-pCWB9SFjLEy3qv3Wk0ixS0_2KKFMcvMZpS8M-n6t-r-yc21ACzZgJ0Tf_K1eT6Xh96UtVddIyfSe/s1600/dilbert.jpeg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgYp4MGw3jM1xvcBEM0x5v0yPXYrIx3d9tVKLWEVPO1xQBH9VIwQgoq_Zzjaa4ttaR-pCWB9SFjLEy3qv3Wk0ixS0_2KKFMcvMZpS8M-n6t-r-yc21ACzZgJ0Tf_K1eT6Xh96UtVddIyfSe/s1600/dilbert.jpeg" height="193" width="400" /></a></div>
Our development team has recently undertaken a new project which is the biggest initiative for the company in 2014. Since we were dealing with some large and complex components, we've been struggling with how we can provide the business with a reasonable estimate for completion of our minimally viable product (MVP).<br />
<br />
I began doing research to see what others in our field have done and polled other Certified ScrumMasters on what their struggles & successes have been. I tapped into a such wealth of knowledge provided by leaders in our field that I felt compelled to compile that information and format it for broader consumption.<br />
<br />
<blockquote class="tr_bq">
<div dir="ltr" style="background-color: white; border: 0px; color: #62514e; font-family: Arial, Helvetica, sans-serif; font-size: 16px; line-height: 24px; margin-bottom: 1.2em; padding: 0px; vertical-align: baseline;">
Face it. Software development teams suck at estimating when their projects are going to be completed. For anyone involved in software development; be it engineers, product managers, and customers this scene is all too familiar:</div>
<div dir="ltr" style="background-color: white; border: 0px; color: #62514e; font-family: Arial, Helvetica, sans-serif; font-size: 16px; line-height: 24px; margin-bottom: 1.2em; padding: 0px; vertical-align: baseline;">
“How’s the project coming? Will it be done in mid-April like you said?”<br />
“Well, we’re actually way behind. April doesn’t seem doable, but that was always just an estimate.”<br />
“How is that possible? You estimated up front that it’d only take you 3 months!?”</div>
<div>
Read more: <a href="http://www.business.com/blog/tech-team-missed-deadline/" target="_blank">Why Your Tech Team Missed Their Deadline</a></div>
</blockquote>
Tell me what you think and how your team deals with estimates.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-7473410847404217572.post-37566245341632232582014-01-16T12:53:00.001-08:002014-01-17T14:26:55.131-08:00How to Start a Large Software Project With an Agile Development Team<div style="background-color: white; color: #222222; font-family: arial, sans-serif; font-size: 13px;">
<h3>
How not to introduce a development team onto a large project</h3>
<div>
<br /></div>
<div>
When beginning a large-scale software project, a common mistake for SMBs is having the agile dev team accept a very broad and loose scope for a project which then is translated into user stories by the engineers themselves (wrong) then break those into technical tasks and define UAC. This is backwards from the way it is supposed to be done if they are practicing true agile development, but many times engineering has to fill major gaps in the specifications in order to continue moving forward on a project.<br />
<br /></div>
<h3>
What agile development should look like at the start of a project</h3>
<div>
<br /></div>
<div>
Product develops the epic stories (components of the site) and then prioritizes them. Product then takes the top epic stories and works with stakeholders to create the user stories. Engineering can help with this but <u>it's imperative that product & stakeholders see a project as easily definable user stories which describe pieces of functionality</u>. Stakeholders develop UAC (or a checklist of things that need to happen in order to consider a story 'done') and these details are attached to each story. Product prioritizes these user stories in the backlog and then explains them to the development team. From this prioritized list, the engineers begin developing technical tasks and delivering features in normal sprint iterations. Product maintains the priority on user stories and development continues to churn out features. </div>
<div>
<br /></div>
<div>
With regular grooming, a backlog of technical tasks is built along with story points that the dev team will use to take a stab at estimated delivery of features based on velocity. Product is with development every step of the way to help clarify requirements, make concessions based on feedback from dev, readjust priority, and communicate back to stakeholders & management, etc. They are part of stand-up, retrospectives, grooming, & demos.<br />
<br /></div>
<h3>
The dreaded 'D' word - Deadline</h3>
<div>
<br /></div>
<div>
Notice above that only when list of features has been defined and the scrum team has achieved a reasonable team velocity can they start to think about deadlines (I understand this is tough for the business to accept, but think about it.... how can you apply anything but a <b>S</b>uper <b>W</b>ild <b>A</b>ss <b>G</b>uess to a deadline until the team has a well-defined understanding of the features of a product along with working knowledge of how quickly the team is proceeding.) </div>
<div>
<br /></div>
<div>
Agile should be viewed like this: <u>as long as the user stories are in priority order, the business begins to benefit from the first sprint because those features committed to are completed every iteration</u>. This is why the final deadline isn't as important as the team is always working on the most important features to the business. Yes, this is a big deviation from traditional project management, but one which is worthwhile to pursue because you transform from the business holding onto a fictitious and unrealistic deadline which was barfed out to some far away future time towards one which embraces the next features in the pipeline that are instantly usable upon release every two weeks.</div>
<div>
<br /></div>
<div>
If this process is not followed, there will be lots of confusion by the business on what is actually being done, when things will be done, etc. Typically small to mid-sized businesses find it easier to take a large nebulous scope and have people set deadlines based off a gut or hunch and then hold them to it. They deliver a 4 page document along with some unfinished mocks and then "leave engineering to it." This leads to frustration on everyone's part and degrades the quality of the project considerably. Product should not unload a multiple page general scope document on development only to disappear and have expect them to start being "agile", much less provide a deadline. The whole business needs to see the project as iterative development.</div>
<div>
<br /></div>
<div>
<i><b>Note</b>: I'm not saying that you need every component of the project to be fleshed out in painstaking detail up front. This is a tenet of old-school waterfall project management. All I'm saying is that there needs to be enough clarity by the engineers on how the top priority features should function. Bear in mind that most projects end up looking quite differently than originally intended by the product team. Not only is this fine, but it's actually a good thing. This is how agile helps us meet quickly changing business needs.</i></div>
<div>
<br /></div>
<div>
For a project to be successful, everyone from the top on down should understand this process and allow it to run its course. I'm confident this can be done even in the most complicated organizational structures, but not without a considerable shift in the way the company looks at product development and execution. The ScrumMaster plays a vital role in the adaptation and evangelism of this process</div>
</div>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-7473410847404217572.post-67048781040700739092013-04-17T10:35:00.002-07:002013-04-17T12:19:59.273-07:00How Not To Use VelocityIn the agile world, there can often times be nothing more misunderstood than team velocity. As most of you know, velocity is the average output of the team based on the number story points completed across a series of sprints.<br />
<br />
For those who are new to agile, all development requests are broken up into deliverable features, called user stories of which each have an associated point value determined by the team. For example, if the team delivers 10 points of work in the first sprint, 15 points during the second and 12 during the third, the velocity of the team by this point is 12 (always round down).<br />
<br />
Different teams have different values for a point, so let's not dwell too much on the actual definition of a point, but for the sake of the discussion our teams use:<br />
<ul>
<li>0 pts: trivial task, just pound it out</li>
<li>1 pt: uninterrupted half day</li>
<li>2 pts: uninterrupted full day</li>
<li>3 pts: uninterrupted two days</li>
</ul>
<div>
We know there is no such thing as an uninterrupted day for engineers, so points are just indications of general size. How does one task measure up with previous tasks which the team has encountered? Is it smaller, larger or about the same? </div>
<div>
<br /></div>
<div>
After a few sprint iterations, assuming your team's criteria for sizing remains constant, your velocity will be a decent indicator of how much work it can commit to for the next sprint. </div>
<div>
<br /></div>
<div>
Naturally, it appears as though there is a direct correlation with points and time so your management group will likely correlate team velocity to efficiency (or lack thereof). This is a very slippery slope that a seasoned ScrumMaster must avoid. Here are some tips to help avoid common pitfalls around people's interpretations of velocity:</div>
<div>
<br /></div>
<div>
<b>Manager: "Why did the team's sprint point output come in lower than the average velocity?"</b></div>
<div>
<br /></div>
<div>
Remember, velocity is an average and it sometimes takes numerous iterations to get to a useful number. As with every average, there are numbers above and numbers below this line. There are also outliers. It is not unusual for teams to have sprint outputs lower than their velocity. Now, if nothing has changed in pointing the stories or in your team's contributors and you only complete half your velocity you may want to investigate what has happened, but you should be catching these things early and make adjustments as you go.</div>
<div>
<br /></div>
<div>
Management should not be nickle-and-diming the team's velocity, though those who don't come from an agile background will most likely do this at some point. Many from the old school are used to seeing billable hours of work summarized weekly to account for productivity. They like to see where every minute of work is being spent. Beware. This could lead to more questions which don't jive with agile.</div>
<div>
<br /></div>
<div>
<b>Manager: "How can we increase the team's velocity?"</b></div>
<div>
<br /></div>
<div>
This is a pretty loaded question. For starters it implies that the team isn't doing enough. While that may be a caused by lack of transparency (which is another topic), you must remind them that points are an arbitrary number that are not directly indicative of productivity. If the team catches wind that management feels that they aren't getting enough points completed, guess what they'll do? They'll pad all of their estimations so next sprint they'll come in way ahead of their velocity.<br />
<br />
If your process is sound and roadblocks are being navigated efficiently, outside of increasing team resources, there's not much you can to meaningfully increase velocity.</div>
<div>
<br /></div>
<div>
And this is really the entire essence of software development. What do points mean to a customer or internal stakeholder? Nothing. They only care about features and improvements. All that points and velocity do is help us best understand how much can reasonably be committed to. Points give us a general size for a task while velocity provides us a view into how many of these tasks we can complete per iteration. If we're working on the most important features and delivering these every iteration, what does a number mean? Very little.<br />
<br /></div>
<div>
<b>Manager: "Let's make sure the team commits to the exact of number of points which match velocity."</b><br />
<b><br /></b>
When a manager approaches the team like this it is another attempt to make sure that developers aren't leaving effort on the table. This is dangerous because it can lead those outside the team providing input on how to best play what I call "Point Tetris" in an attempt to group stories together equaling the velocity.<br />
<br />
Remember, the number of the velocity doesn't matter to the end-users; features do. If you are delivering features in top down priority order, nobody is going to complain that the team came in 5 points short of their average velocity. It's imperative that as ScrumMaster you and your business are thinking about software development in terms of features delivered, not story points completed.<br />
<br />
<b>Pitfall: Don't ever leave a sprint planning meeting by grabbing stories with just the right amount points matching the velocity and saying "that's it." </b><br />
<b><br /></b>
You're forgetting the most important part of each sprint which is the team's commitment. While velocity can guide the team into making an educated decision, it shouldn't force commitment. Perhaps the team feels they can accomplish more features than what matches average velocity. Or maybe less. Either way, it's the commitment agreed upon by the team which provides real value and buy-in. If you try to force the team to commit to something, you've already ruined the sprint. This isn't totalitarianism; there are no executive orders that work in agile. It's freedom of assembly and the right to decide how much the team can do.</div>
<div>
<br /></div>
<div>
If you trust the team to commit to their work load you'll find (as long as they aren't held to the number of points they complete) that they won't sandbag the estimates. Their commitment will mean something to them and they will focus on owning up to their word. </div>
<div>
<br /></div>
<div>
Velocity is indeed important in helping to estimate how much the team can complete in a sprint as well as how many sprints it will take to finish a project, but velocity is just an average based on estimated arbitrary units of relative measurement. It should never be used to micromanage a development team or worse, individual team members. As someone who has experienced all of the above problems and more in my career, I can assure you that this is a legitimate challenge. It's up to you, as the ScrumMaster, to prevent that from happening.</div>
Unknownnoreply@blogger.com2tag:blogger.com,1999:blog-7473410847404217572.post-74470443370436599182013-03-28T09:30:00.000-07:002013-03-28T13:59:01.616-07:00Painfully Long Sprint Planning Meetings? Groom!So you have a ballin' prioritized product backlog but for some reason your sprint planning meetings take way longer than anticipated. As the meeting gets more monotonous, the team becomes disengaged, important questions are never raised, details are missed, and the sprint becomes a mess.<br />
<br />
Does this sound familiar?<br />
<br />
Truth be told, <u>any agile meeting that is longer than an hour is an inefficiently run one.</u> If it's the sprint planning meeting that drags on, you've basically crippled the entire sprint. The last thing you want to have is the team bolting for the door, just happy to escape the torture of planning because you've set a bad tone that will linger around your team like a grey cloud for the remainder of the sprint.<br />
<br />
The good news is that there is a solution: the backlog grooming meeting.<br />
<br />
Backlog grooming is the unsung hero of the agile cadence. Everyone knows about the planning meetings and demos; the alpha and the omega. Though you underestimate the grooming meeting at your own peril.<br />
<br />
The grooming meeting is a pretty simple concept. If your backlog is in order, take an hour during the middle of each sprint to discuss the details of the items from the top down. Try to get as many stories pointed as the team can in an hour and then leave. You may need to have a couple of these meetings throughout the sprint in order to get a big enough leg up on the next iteration.<br />
<br />
If you get far enough ahead, the team will have a good understanding of the upcoming tasks that they will be working on along with the details on how they will develop these user stories. Knowing what they will be doing in the future provides insight on where the business is headed and can often help the developers in their current tasks with a greater understanding of what's to come. Another benefit is that the team identifies areas of the project which need further development before they can begin coding. The product manager now has enough time to get those questions answered before the team starts development.<br />
<br />
All of this makes the Monday sprint planning meeting flow like a nice ocean breeze.<br />
<br />
If you are a particularly busy team (since you're agile I'm sure you are) finding times to get everyone in a room can often be difficult and the grooming meeting is usually the first casualty since "we can just do the pointing during planning." If you fall into this trap and your team's sprints seem to always start off on the wrong foot, be sure to schedule in some mandatory grooming meetings. Your entire sprint and team will benefit.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-7473410847404217572.post-61901275732961144542013-03-26T11:58:00.000-07:002013-03-27T17:04:30.925-07:00The Most Important Words For ScrumMasters<div class="separator" style="clear: both; text-align: left;">
In my continuing quest to identify the skills it takes to be a top ScrumMaster, I took ten random (current) ScrumMaster job postings to take a look at the top words that came up when employers were trying to identify their ideal candidate and the results were interesting.</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
*note: I excluded obvious words like 'Scrum', 'Agile', 'Master', etc</div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg7pbLtG9ua-tyS36jrobKkDv43mh2I1ehkNd8YGv111c2GcRblFGSMTQcg2gn8ALproiVdesyud8YW6fVdiQotw1cz07DmhfLr8Ptm4kWyFXFvCBCmKq3j7Mi6yjCGEFhqlSQ2qaVZ1vNs/s1600/scrum-word-cloud.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="199" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg7pbLtG9ua-tyS36jrobKkDv43mh2I1ehkNd8YGv111c2GcRblFGSMTQcg2gn8ALproiVdesyud8YW6fVdiQotw1cz07DmhfLr8Ptm4kWyFXFvCBCmKq3j7Mi6yjCGEFhqlSQ2qaVZ1vNs/s400/scrum-word-cloud.png" width="400" /></a></div>
<br />
Let's look at a few of the more interesting ones:<br />
<br />
<b>Team</b><br />
<br />
Team is the most common word throughout these ten job postings and I think tells an important story about what a good ScrumMaster does. First and foremost, SMs are members of a team. They are not greater than the team nor can they separate themselves from the successes or failures of the team. If the project fails in the eyes of the stakeholder, it is inappropriate for the ScrumMaster to respond with comments like "the developers weren't getting their work done efficiently enough," or even worse, "the team wasn't communicating well." If the team fails, you are just as much to blame as everyone else; don't use your position as mouthpiece for the dev team to throw people under the bus.<br />
<br />
<b>Solutions</b><br />
<br />
Everyday I come into the office, there is a list of problems (most of them urgent, the sender suggests) that need to be solved. Everyday I leave the office, there is a list of problems. One approach is to stop the presses until all of the day's problems have solutions, but if you head down this road you'll quickly find out that you and your team will be running around like chickens with their heads cut off as the urgent requests never stop. The alternate approach is to organize the team in such a way which maximizes their ability to foresee problems and adjust around them before they make it into production. A constant line of communication between team, product manager, & stakeholder(s) will ensure that you find more of these solutions during feature development than after deployment. This is a ScrumMaster's core responsibility. Don't be afraid of problems... there will be many. Communicate and adjust.<br />
<br />
<b>Transparency </b><br />
<br />
The last thing a stakeholder wants is for their development request enter a black box from which sometimes things exit and others get lost into the nether. It's the job of a ScrumMaster (with the help of the Product Manager) to ensure that the team's progress is open for all to see. Whether it's burn-down charts, company-wide release notifications, more visible tracking tools, etc, the ScrumMaster must make sure that stakeholders and management understand what will make sprint release, which roadblocks were faced & overcome, and any other developments which alter timelines or features to be released. If they can't see what the team is doing, it's likely that they think little is being done and that agile doesn't work. Don't let this happen; be transparent as possible.<br />
<br />
<b>Manager</b><br />
<br />
*WATERFALL ALERT!* *WATERFALL ALERT!*<br />
<br />
As members of agile teams, we all know that ScrumMasters are not called ScrumManagers. The 'M' word was left out of our title for a deliberate reason. We aren't managers in the traditional sense of "you do this," and "you do that." It's incredibly time consuming and limiting if we were to run the agile teams as micro-managers. Still, it shouldn't be lost on the reader that the word 'manager' comes up so often in a ScrumMaster job posting. It shows the amount of work we still have in evangelizing the business to understanding what agile/scrum truly is. If you have your pick of work, I would suggest avoiding job openings where the term 'manager' appears more than 'agile' or those which fluidly swap 'ScrumMaster' with 'Technical Project Manager'Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-7473410847404217572.post-41909441361508617502013-03-13T17:30:00.003-07:002013-03-18T11:03:00.450-07:00How to Breathe Life in Your RetrospectivesI mentioned in a post a few weeks ago that our development team was <a href="http://unscrumhero.blogspot.com/2013/02/killing-retrospective-blues.html">singing the retrospective blues</a> and was going to implement a <a href="http://www.scrumalliance.org/articles/496-iteration-retrospective-activity-turn-the-tables">retrospective meeting that turned the tables</a> on how feedback from the team was provided.<br />
<br />
Yesterday we relaunched the fantastic looking <a href="http://business.com/">Business.com</a>, which is the product of a lot of planning and hard-work across a project that lasted 4 development sprints. I took this opportunity to try out the format that Marc Nazarian laid out on ScrumAlliance.com and here's what happened:<br />
<br />
(note: we ran this as a project-wide retrospective, but the same process is to be followed on sprint retros)<br />
<br />
I sneaked into the board room early and laid out four cards with two different colors in front of everyone's seats. It was clear when everyone stepped into the room that things were going to be different this time.<br />
<br />
The first task for the team was to rate how the project went from their perspective. Needless to say I'm pleased with the results:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEibsR74Q4UpdBnJOuPAvbtOFn-dmTD99OmL4RKUUozWjzabn9nvivq2nc1MXN2AFAG5e_2qGgwW5zTzaRz5XbgbW6l9Fnt8igCyhvF9nOITw296DjNvVyacBfXwb8eZqBgw0mQtplaU9T6i/s1600/rating.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEibsR74Q4UpdBnJOuPAvbtOFn-dmTD99OmL4RKUUozWjzabn9nvivq2nc1MXN2AFAG5e_2qGgwW5zTzaRz5XbgbW6l9Fnt8igCyhvF9nOITw296DjNvVyacBfXwb8eZqBgw0mQtplaU9T6i/s1600/rating.png" /></a></div>
<br />
<br />
We hold our teams to really high standards and have communicated that a 5 in a situation like this would mean an absolutely flawless project, which in my eyes is nearly impossible to achieve. Our teams can always improve and this project was no different.<br />
<br />
With that out of the way, it was time for the team to find out about the cards. Each person was to write down one thing that went well on each yellow card and one thing that didn't go so well on each of the red ones. Instruct your team to keep it 3 words or less.<br />
<br />
<b>Tip:</b> Naturally, everyone said it would be difficult to keep feedback to just a few words, but encourage them to play along as it will become evident why in just a few minutes.<br />
<br />
<b>Tip: </b>Instructing people to come up with feedback on the spot can be tough in a group environment because time is always a constraint and people feel on the spot. What I did to mitigate this was tell everyone in advance to come up with two positives & two areas in need of improvement. Even with preparation this still took longer than I wanted so watch the clock.<br />
<br />
The next step is to tell everyone to pass their red cards to the person to their left and the yellow cards to their right. They now know each person will have to read someone else's cards. It was precisely at this time that, with a huge grin, one of my developers blurted out "this is so much better than what we've done in the past!" Results.<br />
<br />
You then go around the table with the team trying to explain the issues that were brought up on the cards in front of them. It's a very powerful exercise as it gets the team to put on the shoes of someone who may have a completely different job description and see the world from their perspective. After the presenter was through describing their cards, I asked the author of the cards to rate how the presenter did in getting to the crux of the issue. Every single one was rated 5. A well-aligned team indeed :)<br />
<br />
At this point the feedback was flying in fast and keep in mind that this is a team who normally would do their retrospectives in 5 minutes time with most of the feedback being of the "I think the sprint went great" variety. The team was noticeably excited to have an engaging forum to improve the process.<br />
<br />
<b>Tip:</b> As the feedback comes flying in, it can be helpful to write the areas of improvement on the board because you will be coming back to these.<br />
<br />
After everyone is finished presenting, the team passes their two red cards to the left (discard the yellow ones for now) and you go around the room suggesting improvements for each.<br />
<br />
<b>Tip:</b> As Mr. Nazarian warns, everyone is going to want to chime in on most issues, so be sure to have the person reading the card provide their ideas first. Everyone will have a say in the end, but it's best to get a suite of ideas instead of only from those who traditionally dominate meetings. Sometimes the best ideas come from the most unlikely sources.<br />
<br />
If you're doing this right, you'll have three lists on the board: what the team should stop doing, start doing, continue doing. From these the team will take the top priority ones and decide how they will change for the better.<br />
<br />
Our biggest issue that we're going to be tackling is how we use our tracking tools to aide the development process. We have a pretty basic configuration of JIRA to track requirements docs, psds, bugs, and issues while the developers use Pivotal Tracker for their "marching orders" and sprint organization. The team felt frustrated with our convoluted integration of these two tools as well as the difficulty in tracking versions of documents and the changes within. Since this is a large issue, there will be future discussions on how to fix these problems, but the feedback so universal around tracking that it's imperative we solve these problems.<br />
<br />
At the end of the meeting, I once again asked the team to rate something; this time being the return of investment of their time for the retrospective. Here was the result:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg2CmJkHnF8fEc9DDfiMgj-Ot6KQm_j_0L3hywdNYX4C83QBLPLliJ784oCfbcqWr5hAZLTsIFqxVIE9owudpQa2fgLTDM8jjDSLYDlxCLz9eJxDdaJL_hT-jebKS_QYqLeEwRUfiwF-Won/s1600/roi.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg2CmJkHnF8fEc9DDfiMgj-Ot6KQm_j_0L3hywdNYX4C83QBLPLliJ784oCfbcqWr5hAZLTsIFqxVIE9owudpQa2fgLTDM8jjDSLYDlxCLz9eJxDdaJL_hT-jebKS_QYqLeEwRUfiwF-Won/s1600/roi.png" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
Though I may have missed vote, the tally was merely for posterity. Everyone was delighted with the effectiveness of the new retrospective format and I honestly (and perhaps cheesily) think the team walked out of that board room with an improved sense of unity and camaraderie. The process was engaging, fun, and elicited a treasure trove of thoughtful feedback. I'm now tremendously motivated to re-evaluate all of our agile cadence meetings to hit the bar that was raised with this new retrospective.</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
<b>Tip:</b> As ScrumMaster, you are the time keeper. I knew we would be pressed for time and even so our meeting went thirty minutes over. Perhaps this was because we were reviewing the whole project, but there's a lot to discuss in 60 minutes so try to keep things moving.</div>
<br />
Here is some of the feedback I've received since the retrospective:<br />
<br />
As posted by our Lead Designer in Yammer (to our entire company):<br />
<blockquote class="tr_bq">
<blockquote class="tr_bq">
If you call it a debrief, postmortem or retrospective,the fact is Tim Sorweid nailed it today. Mr. Sorweid facilitated an excellent session with key members of the team. The focus of the event was to identify wins and opportunities for improvement. One team member was overheard saying "Tim is scrum master equal to none."</blockquote>
</blockquote>
And in an email to the team from an engineer:<br />
<blockquote class="tr_bq">
<blockquote class="tr_bq">
I want to thank Tim again for re-evaluating the Retrospective Meetings and coming up with a new format that was truly valuable. I think we can all agree that the old format had become monotonous, and we were no longer taking anything valuable away from the meeting. Once again thank you Tim, it's ideas and meetings like this that are going to help shape this company. </blockquote>
</blockquote>
I'm not trying to toot my own horn (that much), but am instead trying to show the immediate gratitude by the team of finding a format that is useful for them. If you've been struggling with your retrospectives you owe it to your team and company to try this right away!<br />
<blockquote class="tr_bq">
</blockquote>
<br />Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-7473410847404217572.post-15146161524878704632013-03-07T13:27:00.000-08:002013-03-07T14:15:38.169-08:00Can ScrumMasters Take Vacations? How ridiculous of a question. Of course ScrumMasters <i>can </i>take vacations. Whether or not things fall apart while you're out shredding the slopes in Tahoe, however, is entirely up to you.<br />
<br />
During my career, I ran into those managers (I'm not suggesting SM's are managers. Just play along...) who feel that things falling apart in their absence is a sign of how needed they are. They take joy when people say "don't ever leave again, we need you," upon return to the office. It makes them feel powerful and probably provides some sense of job security. These types are the micro-managers that we love so much.<br />
<br />
In my first managerial position as Director of Web Development for a $10-20 million a year company, my boss was a task-manager and encouraged me to be as well. I felt guilty taking vacation because emails still had to be answered, consistent direction was required, and processes still needed to be managed. If I ever did take vacation, I ended up answering most emails & calls and even got chewed out for lack of availability for a few days whilst in Germany for the 2006 World Cup. I never used up all of my annual vacation time and rarely took more than two days off at a time as a result.<br />
<br />
Leaving that company was one of the best moves of my life for many reasons, but in large part because being a full-time ScrumMaster allowed me to get my guilt-free vacations back. We aren't managers, task-managers, slave-drivers. We are coaches and plows for teams to use to get projects done. If you know what you're doing, you've already put the processes in place that allows the team to continue trucking towards release as you slip out of the office. The agile cadence is so ingrained into the team's ethos that come Friday before release the team knows to meet with stakeholders in the board room and demo their new features. On Monday post release, the team congregates again with the product owner to review the product backlog and commits to another sprint.<br />
<br />
One trap ScrumMasters can fall into is the feeling that they are running all of these meetings. <i>These are not your meetings</i>, they are for the team. I have made this mistake numerous times and if repeated can make you appear to be a task-manager which is counter-productive to the goal of agile software development. The team commits to work and then splits off to self-organize in order to meet their commitments much more efficiently than we can instruct each developer every step of the way. The ScrumMaster is there to make sure that the meetings move along, the team doesn't get stuck on any one discussion for too long, the team is free to speak their mind, outside forces don't steamroll the process, etc. An empowered team can run these meetings without a ScrumMaster present.<br />
<br />
Of course being a ScrumMaster does more than participate in sprint meetings. We bust up or navigate around road-blocks, but a well-oiled agile team should have all of the tools at their disposal to do so on their own. If you have a <a href="http://unscrumhero.blogspot.com/2013/02/product-owner-scrummasters-best-friend.html">top agile Product Owner</a>, you're unlikely to get someone who will wedge their needs into the process without the team saying "sorry, back in line. k thnks." The Product Owner can back them up should this happen.<br />
<br />
Like in soccer, where everything is improvised from the opening whistle, well-coached agile teams are prepared to tackle challenges on their own. All the coach can do is sit back and watch it unfold for 90 minutes while hoping that he did all he could to prepare them throughout the week.<br />
<br />
Despite being just days from release of our 6 week site rebuild, I just got back from an extended weekend in Colorado and was able to realize the hard-work that I put in developing processes & instilling agile methodology at our company. I made sure to schedule the meetings prior to my trip to ensure rooms were available & the proper people attended, and the team took it from there.<br />
<br />
Only a few things were missed: JIRA issue statuses were never updated and the team neglected to review a QA document, but all-in-all the business continued as usual and the project is still on track for release.<br />
<br />
Now to figure out how to convince my boss that I'm still needed....Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-7473410847404217572.post-53808308920074173462013-02-28T15:51:00.000-08:002013-03-07T14:24:46.118-08:00Product Owner: A ScrumMaster's Best FriendWhether you're trying to bring agile software development to a company or evangelize management to continue to support an agile team it's important for ScrumMasters to realize they aren't alone. In fact, if the SM is the sole evangelist for the process in the company you'll end up fighting an uphill battle that you'd wish you brought in support for. Even if the business (or customer, if you want to substitute) agrees with you and allows you to "go back to your desk and be more agile," you'll likely find yourself in a place where the engineering team thinks they are agile and the product/business side continues to be stuck in the waterfall. I've been here before and it's a tough position to find yourself in.<br />
<br />
The best support a ScrumMaster can have is a committed Product Owner. As the title implies, the Product Owner owns the product (duh), so they have lots of influence and sway over the way the business-side functions and how those outside of the engineering teams view feature development. While you already have your team of engineers on board, you're only halfway there. The Product Owner is the key influence in getting the rest of the business to think in an agile state of mind.<br />
<br />
<b>What Makes a Good Product Owner?</b><br />
<b><br /></b>
<i><b>The Product Backlog</b></i><br />
<br />
The Product Owner manages the product backlog which is really just the list of all feature requests created by stakeholders throughout the company. In other words, the Product Owner controls the priorities of the business and keeps them in balance with the direction of the engineering team. If you want something built, you go through the Product Owner first and make a damn good case for why your feature deserves the very limited resources of the developers.<br />
<br />
The product backlog is the <i>number one tool</i> for conveying to the business how beneficial agile/scrum can be in meeting everyone's needs in a quick & efficient manner. Throughout the month, my company allows various stakeholders to submit feature/project requests along with rationale for doing so and a suggested urgency (high, medium, low). At the end of the month, we meet with all stakeholders & executive staff to go over all items in the list for prioritization. The moment the backlog appears on the shared screen in the board room, it becomes apparent for most stakeholders that if they haven't done a good job developing their business goals (ie revenue gained, time saved, etc) not only will they look foolish in front of the company's decision makers but their feature, which they undoubtedly said is "high" priority, is unlikely to be developed without further upfront analysis. The features with the highest impact on the business rise to the top while those with the lowest impact drop to the bottom. For the next two sprints the development team works top down on priorities and we start all over again.<br />
<br />
This is the power of a well-maintained backlog. It gets everyone aligned with the company's top priorities which are quickly delivered into the hands of the engineers. It is impossible to be an effective Product Owner without maintaining a very high quality and organized product backlog since it is the document which business uses to pour their ideas into and development takes their marching orders from.<br />
<br />
When the business sees top priority features being rolled out every two week iteration the benefits of agile are pretty clear.<br />
<br />
But there's more to being a top Product Owner than just maintaining a list of priorities.<br />
<br />
<i><b>A Product Owner is a member of the team</b></i><br />
<br />
This is a fact that is lost on many agile shops and one that can make or break the success of a team. Traditionally, there are few groups more diametrically opposed as product and development. If you reread that sentence it seems ridiculous to consider, but technical staff sees the world differently than the "idea people" of a business. One group sits in a room with expensive machines with retina displays and dreams up the fluffy widgets while the other sits at the end of the assembly line and has to make sense out of all the unusual things that come out of "happy land". (Can you tell what side I'm on?)<br />
<br />
For agile to work, this orthodoxy needs to be torn down from the start. One side does not get to be the idea side while the other is the action side. Ideas are not simply handed off to developers and then forgotten about until demo when the engineers are left "holding the bag" on missed deadlines or features. The best agile teams have seamless integration and collaboration with the Product Owner and stakeholders. Good Product Owners know that their jobs don't end once development has begun and that engineers will never be stranded to confess their wrong-doings in front of a jury of their peers once the project comes to a close and things are missed.<br />
<br />
Product Owners are there, lockstep, with engineering every step of the way to make sure when the ScrumMaster or team comes to them with roadblocks (of which there will be many) that they are successfully navigated. Many times the things we're told to build just don't make sense or can't be completed in the time originally committed to by the team (google "cone of uncertainty"). This is one of the most glaring realities of software development and the biggest stumbling block for agile teams.<br />
<br />
Can't get all of the gee-whizz javascript features to work in all of the browsers required for launch? The Product Owner scales back the gooey requirements, adjusts which browsers we care to be compliant with, or extends the workload into another sprint to make sure everything works the way they want it. Most importantly, good Product Owners communicate any changes in scope or time to stakeholders and upper management. The business will be more than thrilled to be a part of the decision-making process when changes need to be made, but if they don't know that there are roadblocks to begin with, they will just assume that everything is on track and be stunned when things aren't the way they expect at the end.<br />
<br />
There is always an agreeable compromise to be made on any bump in the road but they have to be dealt with transparently and promptly by the Product Owner and team as soon as they arise. This constant stream of communication between the team, Product Owner, and management is the linchpin for success. Most professional adults can handle the truth and adjust accordingly. However only if stakeholders are given a view into the process and see how their decisions help shape the direction of the project can a development team expect to keep them happy. Making sure this occurs is the key to a great Product Owner.<br />
<br />
In top agile teams Product Owners are best friends with the ScrumMaster. They both know that all projects are collaborative exercises between developers, designers, & stakeholders. There is no baton hand-off as in relay races. Software development is not an assembly line. Same as the SM weaves agile fabric into the development team, so must a Product Owner evangelize to the rest of the business. Only when both have their constituents believing the message can an agile team truly flourish to deliver cutting edge features to market in the turnaround time now expected of modern software development teams.<br />
<br />
If your team is on the rocks or there is a big disconnect between what the business side thinks you do from what you actually do, start with reevaluating your relationship with the Product Owner. If you two aren't on the same page, it's impossible to expect company-wide trust in agile development.<br />
<br />Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-7473410847404217572.post-24089364473148364892013-02-27T09:00:00.000-08:002013-02-27T09:00:01.474-08:00ScrumMaster Identity Crisis Continued<br />
It couldn't have been more than a couple of hours from when I posted this about <a href="http://unscrumhero.blogspot.com/2013/02/scrummasters-what-are-we.html">ScrumMasters being unsung heroes</a> that I encountered a situation which proved my point about how ScrumMasters are so important to a development team yet so misunderstood.<br />
<br />
Upon the completion of a project release milestone meeting, we were discussing which members of the leadership team would be on the 'About Us' portion of our site rebuild. When it was mentioned that I would be included in that group, our executive in charge of product said, "you're going to have to change your title, it doesn't do you justice." When I asked why I would be considered something other than ScrumMaster, which is what I am and what I enjoy doing, she responded with, "because you do so much more than just that."<br />
<br />
It was a little off-putting because here is my product manager who I think is trying to compliment me, but at the same time completely misunderstanding the ScrumMaster role. Sure, I do a lot more QA than a traditional ScrumMaster (we're trying to build a QA department) and I spend a large portion of my time setting development standards and practices while focusing on the professional development of our engineers, but a ScrumMaster is the glue who keeps everything together.<br />
<br />
We are supposed to go above and beyond to make sure roadblocks for the developers have been removed, changes in scope have been communicated, and features are delivered. We thrust ourselves into any issue facing the team and remove impediments as soon as they arise. Clearly, we face an identity crisis and have to work to convey that to our colleagues, but we should wear that as a badge of honor. Being a flexible jack-of-all-trades is what we do. Needless to say, if I end up with my picture on this portion of our site, it will be with the title "ScrumMaster"<br />
<br />
I'm going to be thinking about how I can better communicate what it is I do to those I work with and I'm curious to hear how you all deal with this issue at your company.<br />
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-7473410847404217572.post-56388340681272779692013-02-26T17:15:00.001-08:002013-02-26T17:16:44.529-08:00Killing the Retrospective BluesOne recurring problem that has been happening on my projects lately has been ineffective retrospectives. Usually we go around the table and air our grievances in a very festivus-like manner and the feedback has dragged on to the monotonous "I think everything went great this sprint" by each developer.<br />
<br />
As I notice this happening, I began to encourage people to have "something negative" to say about the process with the understanding that our process isn't perfect and it's there for the team to mold and shape in a way that makes sense to them. I came to the (very late) realization that this is a pretty poor approach on many levels.<br />
<ol>
<li>Going around the room is generally an ineffective way to get meaningful feedback. Since this is tedious, people feel the need to keep it short so we can just get it over with. </li>
<li>Nudging people to say something critical about the process sends the wrong message to the team. In my experience, most developers are unlikely to volunteer anything critical for fear of upsetting anyone unnecessarily. It's not about being negative, it's about providing constructive criticism. Also good things can be mentioned and celebrated as well. The ScrumMaster needs to find a format that solicits the correct type of feedback in an engaging and constructive fashion.</li>
<li>In this format, you're unlikely to get a good list of improvements to make to your process. I'm pretty lucky these days to come away with one thing that we can change positively next sprint.</li>
</ol>
<div>
It's really not until writing this that I realized I have failed the team tremendously. Retrospective is designed to be a powerful tool for change and improvement to the development procedure. It is supposed to engage the team members to feel as owners of a living & breathing process. Meaningful adjustments should be identified every sprint and attempts should be made to instill these improvements the next time around. Simply going around the room and briefly talking about what transpired is a pretty awful attempt at this and we've been doing it wrong for so long. Ugh.</div>
<div>
<br /></div>
<div>
Coincidentally, I came across this blog post on ScrumAlliance.org about the very topic (written today to boot) where Marc Nazarian lays out a simple yet seemingly effective approach to <a href="http://www.scrumalliance.org/articles/496-iteration-retrospective-activity-turn-the-tables">turn the tables on retrospectives</a>. The idea is to get people to write very succinct feedback onto cards, pass them to other team members who then try to describe the issues written down by their colleagues. This is interactive and serves as an entertaining way to get cross-functional teams to see the process through the eyes of another.<br />
<br />
I recommend giving this post a read if you're like me and stuck on a retrospective process which is largely ineffective and tedious.<br />
<br />
Thanks Marc!</div>
Tim Shttp://www.blogger.com/profile/06142698548560602518noreply@blogger.com3tag:blogger.com,1999:blog-7473410847404217572.post-70984502722070248362013-02-26T13:36:00.000-08:002013-02-26T17:31:18.048-08:00ScrumMasters, What Are We?When trying to identify the title for this blog, I went back and forth on the made-up term "UnScrum Hero." What is a ScrumMaster? Is what we do really definable? Can we explain our job duties to someone outside of the company on a short trip down an elevator? Can we explain that to someone inside our company, for that matter? As ScrumMasters, these are all questions we've asked ourselves at some point in our career. This entire blog is an attempt to clear up the identity crisis as well as highlight some of the challenges I have faced as a SM of an eight person engineering team for an internet business-to-business marketing & lead generation company.<br />
<br />
Is the play on "unsung hero" a cheeky and accurate summary of our contributions or a bloated crowning of professional self-worth? Depending on who you ask (engineers, product managers, executives) it can be any one of these. If you ask me (and since it's my blog) I'll tell you that ScrumMasters are really all of these interpretations and more.<br />
<br />
Face it, the term "ScrumMaster" is a bit cheeky to begin with. You can't hand a non-technical person your business card without a smirk on your face as they read your title. If you're like me, the term "Technical Project Manager" may precede the funny made-up word in order to deflect the usual "what is a ScrumMaster?" type of questions. (We really shouldn't do that, btw).<br />
<br />
Whoever coined the term (was it Ken Schwaber?) knew the amused and misunderstood responses traditional professionals would have to it. We are supposed to get people to ask questions about what we do. We are supposed to inspire a little unorthodox excitement in the face of traditional engineering procedural methodologies. What we are doing is (relatively) new and a complete departure from the old-school DuPont-style of project development. Embrace your slap-stick professional title (just don't expect to see average salary information for the title on glassdoor.com). When you're trying to integrate businessy product people with nerdy developers, you had better have a sense of humor or you're going to find yourself losing weight because of stress. Sure we are under constant pressure to deliver features, but being able to laugh and make engineering fun is a critical part of what we do.<br />
<br />
So how about being an unsung or 'unscrum' hero? All non-executive staff thinks they are unsung heroes (coincidentally all executives think they are sung(?) heroes), so what makes us any different? Didn't they tell us in ScrumMaster Certification class that we are just members of a development team; no different than engineers or web-dev guys? Make no mistake about it, ScrumMasters are not above the team. Sure, we may deal directly with product managers, executives, and other external contacts so the tendency is for others to see you as a mid-level manager and sole representative of the development team, but you must resist the urge to see yourself as more powerful than your fellow engineers. Any praise you receive (and it will be little), make sure you step out of its way and push it onto the team. All you do is facilitate action and the team does the physical work.<br />
<br />
However, that's not to say facilitating action is easy. It's not. It's actually quite difficult and gets harder as the team grows, product managers come & go, executives shift corporate structure, etc. This is why I'll get on my soap-box for a moment here and tell you that I think ScrumMasters really are under-appreciated assets. It doesn't help that our responsibilities are hard to define. It's really easy to say that ScrumMasters are like shepherds who protect their flock from negative outside forces, but that only generically scratches the surface. Being a ScrumMaster is akin to being a director of a symphony. You prepare your musicians so well that come the performance, all you need to do is keep the tempo and make sure everyone is coming in on time. Ok maybe that's not the best analogy but you get it.<br />
<br />
ScrumMasters communicate complex issues to product, stakeholders & developers. We coach engineers. We coach product. We coach executives. We foresee roadblocks and adjust around or plow over them. We report. We manage tools. We define processes. We bust-up ineffective overhead. We laugh at everyone. We empower those around us. We manage (effective) meetings. We lead by example. We ship (damn good) code. We take the blame. We deflect the praise. We listen. We suggest. We test code. We manage code release. We rally the troops. We make work fun.<br />
<br />
More importantly than all else, however, we seek & speak the truth.<br />
<br />
Yes, we are unsung heroes because you can't put that stuff on a job description; it always comes off as a posting for a Director of Engineering job or something and even then you only scratch the surface on what a good ScrumMaster does. It's non-quantifiable come review time.<br />
<br />
We are unsung because we want to be. Because seeing your teammates get acknowledged in front of the company by a manager outside of the department makes you happier than receiving your own personal accolades. Because you'll go to war for your team just for those "you make my job so much better" comments from engineers at the holiday parties.<br />
<br />
An UnScrum Hero will always put the team first not because someone told them to, but because they know that doing so will empower the team and improve the entire company.Tim Shttp://www.blogger.com/profile/06142698548560602518noreply@blogger.com0