tag:blogger.com,1999:blog-34828623318719183292024-03-13T14:56:07.832+11:00Implementing AgileTips and best practices on implementing AgileBob Boydhttp://www.blogger.com/profile/12902323994439824982noreply@blogger.comBlogger31125tag:blogger.com,1999:blog-3482862331871918329.post-83181847292152346122022-02-12T17:00:00.002+11:002022-02-12T17:17:46.854+11:00Transformation: Attitude over Aptitude<p>When you’re involved in any type of
Business Transformation, the success or failure of that transformation may lie
with the company’s culture. However, there’s more to culture change than the
environment everyone works in as there’s a bit of culture within each of us
that struggles and resists against change; it’s likely our fight or flight
reflex.</p>
<p class="MsoNormal" style="margin-bottom: 12.0pt; margin-left: 0cm; margin-right: 0cm; margin-top: 12.0pt; margin: 12pt 0cm;"><span lang="EN-US">Years ago I met Gary Swart, former CEO
of ODesk, and asked him how he chose people to join the company. He said he
looked for three things in order: Personality, Motivation, and Skills. He said
skills are last because you can teach skills. The point is not to abandon those
who are of the right mindset and are motivated. Believe in the people you’re
working with and it’s much more likely they’ll pull through.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 12.0pt; margin-left: 0cm; margin-right: 0cm; margin-top: 12.0pt; margin: 12pt 0cm;"><span lang="EN-US">In my view, the team is central to any
transformation success once the executive management team has agreed to change.
To embolden a team to seize control of the product or service and their
customers is the aim. Success is more likely to happen once the team and
customers are working together to solve customer problems. A great team solves
customer problems to meet business goals. <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 12.0pt; margin-left: 0cm; margin-right: 0cm; margin-top: 12.0pt; margin: 12pt 0cm;"><span lang="EN-US">When hiring, the first thing most
people look at are skills which can mean future change of the work force will
be just that much harder. While skills are important, personality and
motivation are more important. The ability for someone to change is more
strongly connected to personality and motivation than the ability to say, write
code. Let’s look at a situation where personality and motivation come to the
forefront. <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 12.0pt; margin-left: 0cm; margin-right: 0cm; margin-top: 12.0pt; margin: 12pt 0cm;"><span lang="EN-US">Have you ever sat in with a ‘team’ and
heard someone say, “it’s not my job” or “it’s so-n-so’s job” or “I’m here to
work” or “I wasn’t hired to do that” or “This is the way forward”? Or perhaps
you’ve seen a situation where the team has accepted a particular way of working
but then a person does their own thing their way? If you haven’t then you might
be in the presence of a high-performance team. For the rest of us, this
behavior is an anti-pattern to a successful self-organizing, cross-functional,
and high performing team. Attitude is arguably more important than aptitude in
any team.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 12.0pt; margin-left: 0cm; margin-right: 0cm; margin-top: 12.0pt; margin: 12pt 0cm;"><span lang="EN-US">I believe there are two different
people who say these things:<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 0cm; margin-left: 36.0pt; margin-right: 0cm; margin-top: 12.0pt; margin: 12pt 0cm 0cm 36pt; mso-list: l0 level1 lfo1; text-indent: -14pt;"><!--[if !supportLists]--><span lang="EN-US"><span style="mso-list: Ignore;">1.<span style="font: 7pt "Times New Roman";">
</span></span></span><!--[endif]--><b><span lang="EN-US">Person A</span></b><span lang="EN-US"> says this because they’re apprehensive about doing something
they’re unfamiliar with but there’s a reluctant willingness to try. They are
not sure how to proceed but a glimmer of opportunity exists in their eyes.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 12.0pt; margin-left: 36.0pt; margin-right: 0cm; margin-top: 0cm; margin: 0cm 0cm 12pt 36pt; mso-list: l0 level1 lfo1; text-indent: -14pt;"><!--[if !supportLists]--><span lang="EN-US"><span style="mso-list: Ignore;">2.<span style="font: 7pt "Times New Roman";">
</span></span></span><!--[endif]--><b><span lang="EN-US">Person B</span></b><span lang="EN-US"> says this because they’re stead-fast determined to do what they
want to do or do what they perceive as their role to do full stop. They are
closed to new and different ideas. They hear the new ideas and say, “but”. They
are happy if nothing really changes for them but are quite happy to see others
change as long as it doesn’t impact themselves.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 12.0pt; margin-left: 0cm; margin-right: 0cm; margin-top: 12.0pt; margin: 12pt 0cm;"><span lang="EN-US">Let’s deal with Person A; Person B
should be relocated out of the team and given training or a job were this
behavior is an asset. <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 12.0pt; margin-left: 0cm; margin-right: 0cm; margin-top: 12.0pt; margin: 12pt 0cm;"><span lang="EN-US">Fear of the unknown, fear of failure,
and fear of change are pretty much the same thing (a $1300/hr. psychiatrist
might disagree). Helping someone become a better team mate is certainly within
the scope of an team’s obligations and duties but it may take time and an
abundance of patience. If you’re in an agile environment, having the team solve
their internal issues is a great step in building trust and empowerment. <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 12.0pt; margin-left: 0cm; margin-right: 0cm; margin-top: 12.0pt; margin: 12pt 0cm;"><b><span lang="EN-US">Prerequisite:</span></b><span lang="EN-US"> If there’s a manager of the team, ensure this person is practicing
servant leadership and not C&C. This may take several weeks to months to
get the desired manager behavior. This step is a prerequisite before a team
will feel responsibility for self-management of team members.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 12.0pt; margin-left: 0cm; margin-right: 0cm; margin-top: 12.0pt; margin: 12pt 0cm;"><span lang="EN-US">How to start the process of building a
better team from within:<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 0cm; margin-left: 36.0pt; margin-right: 0cm; margin-top: 12.0pt; margin: 12pt 0cm 0cm 36pt; mso-list: l1 level1 lfo2; text-indent: -10.5pt;"><!--[if !supportLists]--><span lang="EN-US" style="font-family: Symbol; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font: 7pt "Times New Roman";">
</span></span></span><!--[endif]--><span lang="EN-US">Recognize and understand the
specific self-organizing, cross-functional, high-performing goals the team
wants to achieve. Person A must understand and agree to these goals.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left: 36pt; mso-list: l1 level1 lfo2; text-indent: -10.5pt;"><!--[if !supportLists]--><span lang="EN-US" style="font-family: Symbol; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font: 7pt "Times New Roman";">
</span></span></span><!--[endif]--><span lang="EN-US">Recognize and understand the
specific goals the individual wants to achieve. Fully understand how individual
and team goals compliment or compete with each other.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left: 36pt; mso-list: l1 level1 lfo2; text-indent: -10.5pt;"><!--[if !supportLists]--><span lang="EN-US" style="font-family: Symbol; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font: 7pt "Times New Roman";">
</span></span></span><!--[endif]--><span lang="EN-US">Determine specific measures
that can be used to determine progress toward a goal, either personal or team.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left: 36pt; mso-list: l1 level1 lfo2; text-indent: -10.5pt;"><!--[if !supportLists]--><span lang="EN-US" style="font-family: Symbol; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font: 7pt "Times New Roman";">
</span></span></span><!--[endif]--><span lang="EN-US">Setup work tasks that allow
team members to work with Person A in a pairing environment toward achieving
team goals.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left: 36pt; mso-list: l1 level1 lfo2; text-indent: -10.5pt;"><!--[if !supportLists]--><span lang="EN-US" style="font-family: Symbol; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font: 7pt "Times New Roman";">
</span></span></span><!--[endif]--><span lang="EN-US">Have the Team Coach help the
team understand the benefits of being a self-organizing, cross-functional,
high-performing team. Connect this to business and customer value.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left: 36pt; mso-list: l1 level1 lfo2; text-indent: -10.5pt;"><!--[if !supportLists]--><span lang="EN-US" style="font-family: Symbol; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font: 7pt "Times New Roman";">
</span></span></span><!--[endif]--><span lang="EN-US">The Coach is continuously
helping the team to improve and learn from previous actions and work results;
blame is not an option.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 12.0pt; margin-left: 36.0pt; margin-right: 0cm; margin-top: 0cm; margin: 0cm 0cm 12pt 36pt; mso-list: l1 level1 lfo2; text-indent: -10.5pt;"><!--[if !supportLists]--><span lang="EN-US" style="font-family: Symbol; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font: 7pt "Times New Roman";">
</span></span></span><!--[endif]--><span lang="EN-US">Allocate some time in every
retrospective to discuss further both individual & team growth.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 12.0pt; margin-left: 0cm; margin-right: 0cm; margin-top: 12.0pt; margin: 12pt 0cm;"><span lang="EN-US">The measures for achieving individual
& team goals are usually simple. For example, to help someone become
familiar with a specific product or outcome so they can contribute, the team
and Person A should complete a skills matrix on all areas the team is
responsible for. For Person A, the goal may be to achieve a knowledge score of
‘3’ on a scale of 1 – 5 in a specific area. While the measurements are
subjective, by having the team determine what great looks like and using the
same measurement scales within the team, a meaningful measure will result.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 0cm; margin-left: 30.0pt; margin-right: 30.0pt; margin-top: 12.0pt; margin: 12pt 30pt 0cm;"></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEiNeSIwPMryw0e8pOAEDpvMyk4lMc7VC3gEDf1yAtsVr08f3KKGg90dAYUBaV_dmB_nSZHNr4bWN_aszm2vWv61eaPpTQx0MsXkoWbtPQjUovPtmfqrsl_0pbsvinAk5BPA7y6G8PedoTUhDDA1S4T8rmSAW3HOeHvCay3ovPyDu5xvvIReHL2DCwV0gQ" style="margin-left: 1em; margin-right: 1em;"><img alt="" data-original-height="519" data-original-width="973" height="278" src="https://blogger.googleusercontent.com/img/a/AVvXsEiNeSIwPMryw0e8pOAEDpvMyk4lMc7VC3gEDf1yAtsVr08f3KKGg90dAYUBaV_dmB_nSZHNr4bWN_aszm2vWv61eaPpTQx0MsXkoWbtPQjUovPtmfqrsl_0pbsvinAk5BPA7y6G8PedoTUhDDA1S4T8rmSAW3HOeHvCay3ovPyDu5xvvIReHL2DCwV0gQ=w521-h278" width="521" /></a></div><br /><p></p>
<p class="MsoNormal" style="margin-bottom: 12.0pt; margin-left: 30.0pt; margin-right: 30.0pt; margin-top: 0cm; margin: 0cm 30pt 12pt;"><span lang="EN-US">Team skills matrix can help
identify areas for improvement.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 12.0pt; margin-left: 0cm; margin-right: 0cm; margin-top: 12.0pt; margin: 12pt 0cm;"><span lang="EN-US">I once worked with a team who were
very much thinking roles and role based responsibilities. The team was having a
problem getting new development work delivered. It was found that the 8
developers were feeding all their great work to one person for testing. All
their work flowed to one person who did the acceptance & system testing.
Here was a bottleneck requiring people to move outside their areas comfort.
When I first raised the issue with the team, one developer said, “hire more
testers.” The problem was resolved with the COO and General Manager of Product
both saying testing was the “job of the team”. The unspoken truth was you act
as a team to get stuff done or you’re not likely to be better. The second point
is there needs to be a strong, very strong, buy-in from management for the team
to be agile in their behavior and work practices.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 12.0pt; margin-left: 0cm; margin-right: 0cm; margin-top: 12.0pt; margin: 12pt 0cm;"><span lang="EN-US">Another measure a team might consider
using is: <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 12.0pt; margin-left: 0cm; margin-right: 0cm; margin-top: 12.0pt; margin: 12pt 0cm;"><i><span lang="EN-US">“Number of hours in iteration spent
helping team members grow and be better”</span></i><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 12.0pt; margin-left: 36.0pt; margin-right: 0cm; margin-top: 12.0pt; margin: 12pt 0cm 12pt 36pt; mso-list: l2 level1 lfo3; text-indent: -10.5pt;"><!--[if !supportLists]--><span lang="EN-US" style="font-family: Symbol; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font: 7pt "Times New Roman";">
</span></span></span><!--[endif]--><span lang="EN-US">This reflects the total hours
per iteration where the team spends time learning new skills, honing existing
skills, teaching other team members new skills (T-Skills), interviewing and
discussing customer/user problems with the customer/user. Measure in hours of
an aspect of a self-organizing team: caring and improving the team.<o:p></o:p></span></p>
<h2 style="break-after: auto; margin-bottom: 14.95pt; margin-left: 0cm; margin-right: 0cm; margin-top: 14.95pt; margin: 14.95pt 0cm; page-break-after: auto;"><span lang="EN-US" style="mso-bidi-font-style: normal;">Summary</span><span lang="EN-US"><o:p></o:p></span></h2>
<p class="MsoNormal" style="margin-bottom: 12.0pt; margin-left: 0cm; margin-right: 0cm; margin-top: 12.0pt; margin: 12pt 0cm;"><span lang="EN-US">It’s the team’s collective
responsibility to help individual team members channel the fear of new things
into excitement about new things. It’s also in the team’s self-interest to see
themselves as responsible for the team’s collective behavior. If the team is
unable to enact change then it’s almost a certainty the person is removed from
the team and management takes over the disposition of the individual. In my
experience this has happened only twice and each time the team and team coach
(scrum master) spent more than a month trying to enact change without result.
However, overwhelmingly, the team is able to work within itself to improve
individual & team behavior in a most positive direction.<o:p></o:p></span></p>Bob Boydhttp://www.blogger.com/profile/12902323994439824982noreply@blogger.com0tag:blogger.com,1999:blog-3482862331871918329.post-54916713477283129222020-07-30T07:22:00.002+10:002023-02-06T13:02:15.267+11:003 More Questions to Ask During Stand-upsMost everyone is familiar with the three traditional Scrum questions answered during the daily stand-up as presented in the 2016 Scrum Guide by Sutherland and Schwaber:<br />
<ol class="ili-indent">
<li>What did I do yesterday that helped the Development Team meet the Sprint Goal?</li>
<li>What will I do today to help the Development Team meet the Sprint Goal?</li>
<li>Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?</li>
</ol>
The purpose of the daily stand-up is for the Development Team to review the previous day's plan and then arrive at a plan for the next 24-hours. In most cases, the Development Team can do this pretty well. The daily stand-up is a straight forward and simple meeting that focuses on the sprint goal but what could be done different to enhance the team's daily goals and daily commitments, commitments which the Development Team will hold themselves accountable for.<br />
To help focus the Development Team on the day's planned delivered value, "What will I do today to help the Development Team meet the Sprint Goal?", it is helpful to expand this into 3 questions before taking about today's plan:<br />
<div style="padding-left: 30px;">
2.1 What is the customer value you'll deliver at the end of today?</div>
<div style="padding-left: 30px;">
2.2 Is there something you can show the Product Owner today?</div>
<div style="padding-left: 30px;">
2.3 Is there something you can do to help get the most important story done today?</div>
Now these three questions are not simply the fantasy of the Scrum Master but are arrived at jointly with the Development Team. Each of the above questions have their roots in team retrospectives and, in the beginning, the team wanted the Scrum Master to ask them. It's very important that the team agree to any enhancements to the daily stand-up. For teams still early in their Agile journey, these questions will probably not seem unreasonable. However, for more mature Agile teams, there definitely needs to be a strong motivation to adopt them. In my particular circumstances, the Scrum Team was very mature and each of these 3 questions addressed a very specific problem the team recognized.<br />
<h3>
2.1. What is the customer value you'll deliver at the end of today?</h3>
When the question is asked, the team provides an answer in terms of acceptance criteria/tests that would pass at the end of the day that currently fail.<br />
I started asking this question of the Development Team several years ago when it was brought up during a retrospective that during the daily stand-up, the team was focusing on the technical aspects of the work more than the customer problem they were actually meant to be solving. It wasn't that the technical stuff wasn't important, it is, but we wanted the team to keep some focus on what why and who they're doing the work for. During the retrospective, the Product Owner said he was unclear of the progress of the user story, specifically the progress of the user story from a value perspective. More focus on the acceptance criteria and tests was a natural way to convey progress on value completed. The Product Owner was happy and the Development Team added the acceptance tests results as part of their daily planning.<br />
This question provides an additional opportunity to further communications and collaboration between the Development Team and Product Owner. This is achieved by tying the customer, the acceptance criteria, and the solution together as a daily goal, a measure of value delivered each day.<br />
<h3>
2.2. Is there something you can show the Product Owner today?</h3>
This question sprang from the Developments Team's observation that some work was being rejected by the Product Owner, especially user interface work, too late in the sprint to correct it. The problem was the team was waiting until the story was complete before showing it to the Product Owner. This usually resulted in a new user story being written and added for the next sprint.<br />
During the retrospective, the team recognized that some user stories and the intended value were being missed during the sprint because of the delay in showing progress to the Product Owner. The Development Team and Product Owner quickly saw that viewing incremental progress was the answer but the Development Team needed to alter how they broke down the work into tasks to facilitate this. It was breaking down the work differently that was the real challenge for the team as it required some work to be done that would ultimately be thrown away. This was the occasional stub or driver code to get some display components looking 'right'.<br />
This question provides an excellent opportunity to further collaboration between the Development Team and Product Owner. It serves to help focus on what 'done' means for a particular user story and helps reduce rework through a more collaborative approach to solving a problem. It can also make for a better product faster as the Development Team and Product Owner make any adjustments as a story progresses.<br />
<h3>
2.3. Is there something you can do to help get the most important story done today?</h3>
This question got its start while 4 teams were working the same backlog and it was observed that new stories were being started while higher priority stories were still in progress sometimes with a large number of tasks in 'To Do'. Although this question came from a Large-Scale Scrum (LeSS) implementation, it scales down nicely to a single team working a single product backlog.<br />
What the Development Team was trying to improve during a retrospective was their ability to swarm until done. When I was developing, I would prefer to work it alone, without outside help whether I could use it or not. The Development Team saw that this mindset tended to slow down getting stuff done and suggested that the question be asked during the stand-up to heighten awareness that getting to 'done' was important. The way it eventuated was tasks still in 'To Do' for the higher priority stories were picked up. It also helped in identifying tasks that needed further breaking down.<br />
The question provided additional visibility to getting stuff done rather than getting stuff in progress. Getting work done quicker gives the Product Owner maximum flexibility in releasing or A/B testing of new features. Unfortunately, companies sometimes look at 6 developers and wonder out loud why there aren't 6 stories in progress.<br />
<h3>
Outcomes</h3>
After having the Scrum Master ask the 3 additional questions at the start, the Development Team began using the questions in context to their plan for the day and the questions themselves weren't asked after a time. These 3 questions helped the team find the deeper meaning to the question, "What will I do today to help the Development Team meet the Sprint Goal?"<br />
<br />
Please drop me a line and let me know what you think and your results if you give this a try.Bob Boydhttp://www.blogger.com/profile/12902323994439824982noreply@blogger.com0tag:blogger.com,1999:blog-3482862331871918329.post-38731921853283415222019-03-13T05:50:00.003+11:002019-03-13T05:50:54.807+11:00The Manager and Agile<br />
In a recent post by <a href="https://www.linkedin.com/feed/update/urn:li:activity:6508416438468956162">Michael Sahota</a>, he challenged an assumption the company hierarchy stands in the way of achieving a great agile culture. Michael counters that the way we hold hierarchies within ourselves is in fact the real challenge. While looking at his post it occurred to me our first 18 years of life were spent deeply imbedded within hierarchies. As people, we are fully evolved to live within the hierarchies life puts before us. Here are a couple thoughts on the topic of hierarchies and how we learned to live and expect them. I’d be happy to hear your points of view.<br />
<br />
<h3>
Our Earliest Days</h3>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://3.bp.blogspot.com/-kLloWXreMjM/XIf-GcnsGQI/AAAAAAAAATs/XlmmwFrQkNUhhrvnmKi7e3lsSJ5BnOqegCLcBGAs/s1600/kid%2Bon%2Ba%2Bleash.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="375" data-original-width="500" height="240" src="https://3.bp.blogspot.com/-kLloWXreMjM/XIf-GcnsGQI/AAAAAAAAATs/XlmmwFrQkNUhhrvnmKi7e3lsSJ5BnOqegCLcBGAs/s320/kid%2Bon%2Ba%2Bleash.jpg" width="320" /></a></div>
<div style="text-align: center;">
“<a href="https://www.flickr.com/photos/danox/2794348247/">Leashed children</a>” (<a href="https://creativecommons.org/licenses/by-sa/2.0/">CC BY-SA 2.0</a>) by <a href="https://www.flickr.com/people/danox/">danoxster</a></div>
<br />
When we’re young, very young, ... <a href="https://www.improvingagilepractices.com/2019/03/11/the-manager-and-agile/">Read more here</a> (<a href="https://www.improvingagilepractices.com/2019/03/11/the-manager-and-agile/">https://www.improvingagilepractices.com/2019/03/11/the-manager-and-agile/</a> )Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-3482862331871918329.post-79966484394387039852016-10-23T07:50:00.000+11:002016-10-23T07:50:08.541+11:00New Scrum Master: Problems to solve in your first days<div style="color: #1a1a1a; font-family: Merriweather, Georgia, serif; font-size: 16px; margin-bottom: 28px;">
In the previous two posts. <a data-mce-href="http://www.improvingagilepractices.com/2016/09/24/first-day-as-scrum-master/" href="http://implementingagile.blogspot.com.au/2016/10/first-day-as-scrum-master.html" style="box-shadow: currentcolor 0px 1px 0px 0px; color: #007acc; text-decoration: none;">First day as Scrum Master</a> and <a data-mce-href="http://www.improvingagilepractices.com/2016/10/17/second-day-as-scrum-master/" href="http://implementingagile.blogspot.com.au/2016/10/second-day-as-scrum-master.html" style="box-shadow: currentcolor 0px 1px 0px 0px; color: #007acc; text-decoration: none;">Second day as Scrum Master</a>, I talked about you as a new Scrum Master to a team and some steps you can take to ease yourself into the team's world. The first post talked about a group meeting with all team members including Product Owner. That meeting set up some introductions and gave you some clues as to how the team interacts and possibly some team dynamics. You followed that up with some one-on-one talks with each member of the team. In this post I'll talk about interpreting the results of your one-on-one discussions with the team members.</div>
<div style="color: #1a1a1a; font-family: Merriweather, Georgia, serif; font-size: 16px; margin-bottom: 28px;">
Once you've finished your talks with the team it's time to pull all the information together and begin planning your actions. The problems mentioned by the Product Owner, developers, testers, BA's, UXD, and others on the team will likely fall into several categories. What's listed below can be used as a guide but doesn't take the place of your own analysis based on your unique set of circumstances.</div>
<h3 style="clear: both; color: #1a1a1a; font-family: Merriweather, Georgia, serif; font-size: 23px; line-height: 1.21739; margin: 56px 0px 28px;">
Team's ability to self-organize and be cross-functional</h3>
<div class="mceTemp" style="color: #1a1a1a; font-family: Merriweather, Georgia, serif; font-size: 16px;">
<div style="margin-bottom: 28px;">
</div>
<div style="margin-bottom: 28px;">
<div class="separator" style="clear: both; text-align: center;">
<a href="https://1.bp.blogspot.com/-KznHZEDaUig/WAmZB8-NOzI/AAAAAAAAAMo/QqeOsxS0_68461tuWGz_k7PTG1COUk8SwCEw/s1600/Ft_hdr.5.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="300" src="https://1.bp.blogspot.com/-KznHZEDaUig/WAmZB8-NOzI/AAAAAAAAAMo/QqeOsxS0_68461tuWGz_k7PTG1COUk8SwCEw/s400/Ft_hdr.5.jpg" width="400" /></a></div>
<br />
One Team, One Goal.</div>
</div>
<div style="color: #1a1a1a; font-family: Merriweather, Georgia, serif; font-size: 16px; margin-bottom: 28px;">
This will be by far the most common area of weakness based on the many discussions I've had. The clue to this will be problems brought up by the team that they can clearly solve themselves but they'll need your help. Some comments might include:</div>
<ul class="ili-indent" style="color: #1a1a1a; font-family: Merriweather, Georgia, serif; font-size: 16px; list-style-image: initial; list-style-position: initial; margin: 0px 0px 28px; padding: 0px 0px 0px 40px;">
<li>"Requirements are poorly written",</li>
<li>"Working on things before we know what to do e.g. UX Designs incomplete",</li>
<li>"Too many hand-offs", and</li>
<li>"Definition of Ready and Definition of Done missing".</li>
</ul>
<div style="color: #1a1a1a; font-family: Merriweather, Georgia, serif; font-size: 16px; margin-bottom: 28px;">
I'll look into the first comment, "Requirements are poorly written" in some detail. When the Scrum Development Team say this, I'm thinking there's both a communication issue and possibly some role based barriers in place. The comment given by the Development Team makes me think they're not feeling completely responsible for making sure the user stories are backed with heaps of conversation. Both communication and not feeling it's their job can be resolved through well facilitated grooming sessions. The team can become better at self-organizing by tackling head-on the issue of shared understanding of the customer problem documented in user stories. The team can also build their cross-functional capabilities through greater contributions to the user story including the acceptance criteria. For a developer whose experience may be waterfall and where the sole contribution of the developer was code, helping to write the requirements can be a new and possibly frightening turn of events. You as Scrum Master are there to help facilitate this transformation.</div>
<h3 style="clear: both; color: #1a1a1a; font-family: Merriweather, Georgia, serif; font-size: 23px; line-height: 1.21739; margin: 56px 0px 28px;">
Business or company culture as impediments</h3>
<div class="mceTemp" style="color: #1a1a1a; font-family: Merriweather, Georgia, serif; font-size: 16px;">
<div style="margin-bottom: 28px;">
</div>
<div style="margin-bottom: 28px;">
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://4.bp.blogspot.com/-kBiU46DD_l4/WAmYe0WBSjI/AAAAAAAAAMw/ltQRBIR_KxkhLdGpc3BZ-0G4d6Ksor1eACEw/s1600/Culture-Picture.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="282" src="https://4.bp.blogspot.com/-kBiU46DD_l4/WAmYe0WBSjI/AAAAAAAAAMw/ltQRBIR_KxkhLdGpc3BZ-0G4d6Ksor1eACEw/s400/Culture-Picture.jpg" width="400" /></a></div>
<br />
We do it that way because that's the way we do it.</div>
</div>
<div style="color: #1a1a1a; font-family: Merriweather, Georgia, serif; font-size: 16px; margin-bottom: 28px;">
Problems or issues cited by the team that fall into this category might include:</div>
<ul class="ili-indent" style="color: #1a1a1a; font-family: Merriweather, Georgia, serif; font-size: 16px; list-style-image: initial; list-style-position: initial; margin: 0px 0px 28px; padding: 0px 0px 0px 40px;">
<li>"Too many sign-offs and approvals (Designs)",</li>
<li>"Little interaction between test and other departments",</li>
<li>"Business emergencies and no way to stop them", and</li>
<li>"Fixed end date regardless of start date"</li>
</ul>
<div style="color: #1a1a1a; font-family: Merriweather, Georgia, serif; font-size: 16px; margin-bottom: 28px;">
It's clear the company culture is not controlled by the development team but they can have an influence. The comments above could make you think the company is a top down Command & Control shop and you'd be right. One thing I've seen in this kind of environment is nothing is written down, it's all done based on memories of past practices. One way to begin affecting this culture is to document how current work is done paying specific attention to the time it all takes. The Scrum Master and team can do this documenting of existing process and then present an alternative process with the now documented benefits and savings. As Scrum Master, you should also seek out and secure executive support or at least, a powerful mid-level manager who can support change. Without support, you're chances of success are severely limited as I've recently learned first hand.</div>
<h3 style="clear: both; color: #1a1a1a; font-family: Merriweather, Georgia, serif; font-size: 23px; line-height: 1.21739; margin: 56px 0px 28px;">
Technical challenges or knowledge gaps that are impediments</h3>
<div class="mceTemp" style="color: #1a1a1a; font-family: Merriweather, Georgia, serif; font-size: 16px;">
<div style="margin-bottom: 28px;">
</div>
<div style="margin-bottom: 28px;">
<div class="separator" style="clear: both; text-align: center;">
<a href="https://4.bp.blogspot.com/-gdjt7XcDgBc/WAmZB17f3PI/AAAAAAAAAMs/-Mq1-4Q18ec-FMv9pYqEbY26JwxDVOkfQCEw/s1600/thomas%2Bedison.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="286" src="https://4.bp.blogspot.com/-gdjt7XcDgBc/WAmZB17f3PI/AAAAAAAAAMs/-Mq1-4Q18ec-FMv9pYqEbY26JwxDVOkfQCEw/s400/thomas%2Bedison.jpg" width="400" /></a></div>
<br />
Thomas Edison - Incandescent light bulb</div>
</div>
<div style="color: #1a1a1a; font-family: Merriweather, Georgia, serif; font-size: 16px; margin-bottom: 28px;">
This is something I usually note as a result of listening to the development team but it's rare that the team will directly say something with the exception of how testing is done. What I commonly see is a team hampered due to:</div>
<ul class="ili-indent" style="color: #1a1a1a; font-family: Merriweather, Georgia, serif; font-size: 16px; list-style-image: initial; list-style-position: initial; margin: 0px 0px 28px; padding: 0px 0px 0px 40px;">
<li>Specialist on team that can't assist in other technical areas</li>
<li>Test treated as a separate group or sub-team</li>
<li>Testing always done at the end of sprint</li>
</ul>
<div style="color: #1a1a1a; font-family: Merriweather, Georgia, serif; font-size: 16px; margin-bottom: 28px;">
These fall under a team being cross-functional but to get there will require specific training and strong guidance from the Scrum Master. I once had a team with one tester doing all the testing. I suggested that the developers help out with the testing to speed it up and relieve the pressure on the sole tester. Luckily there wasn't a rope handy as I'm sure the developers would have hung me then and there for speaking such blasphemy. One developer suggested to the managers that they needed to hire more testers. The managers, GM of Product and GM of R&D both told the developers that hiring wasn't an option and that they would need to better support test. Once the management support was established, I was able to help get the developers to run acceptance and system tests. Baby steps. It was the opening needed to begin the longer term goal of spreading a little knowledge throughout the development team. When I left that company, the Scrum Teams did all the UX, testing, and infrastructure work themselves whereas in the beginning, each of these areas had specialist teams doing this work.</div>
<h3 style="clear: both; color: #1a1a1a; font-family: Merriweather, Georgia, serif; font-size: 23px; line-height: 1.21739; margin: 56px 0px 28px;">
How this helps</h3>
<div style="color: #1a1a1a; font-family: Merriweather, Georgia, serif; font-size: 16px; margin-bottom: 28px;">
After my first days and weeks with the team, I continued doing one-on-one talks with all the developers and Product Owners, noting what changes they felt had occurred in the previous month or two, how exactly these changes affected them, what further changes they wanted to see, and what makes them happy to come to work. I often find myself listening to the team chatter but asking the team to tell me their struggles and their delights helps me focus better on serving them. That's my role as Scrum Master, to serve the team.</div>
<div style="color: #1a1a1a; font-family: Merriweather, Georgia, serif; font-size: 16px; margin-bottom: 28px;">
I welcome your thoughts and comments.</div>
<div>
<br /></div>
Unknownnoreply@blogger.com2tag:blogger.com,1999:blog-3482862331871918329.post-22159071643910520882016-10-21T16:12:00.000+11:002016-10-23T07:44:39.322+11:00Second day as Scrum MasterIn the first post of this series, <a href="http://implementingagile.blogspot.com.au/2016/10/first-day-as-scrum-master.html" target="_blank">First day as Scrum Master</a>, I talked a little about he first day with your new team. In this post I want to talk about conducting your first one-on-ones with the team members.<br />
<br />
After your first day or so with your new team, it's time to get intimate and personal through one-on-one discussions - I don't call them interviews because I want an informal atmosphere for a discussion and not one where people feel they're playing a role.<br />
<br />
I use one-on-one to gain insight into the team members world in a non-threatening way. This is a three step process, setting up an one-on-one, conducting the one-on-one, and making sense of the results. For the team members, this process generally gives them a chance to voice their concerns and issues but it almost always leaves them with a sense that someone cares. For you as a Scrum Master, you do care but it's important the team gets the idea that you are there to serve them, that you actually care more about them than yourself.<br />
<br />
<h2>
Setting up the one-on-one</h2>
<br />
To get started I approach each of the team members and simply ask if I could have 30 minutes of their time to talk about what's working and what isn't from their unique point of view. This establishes a few things:<br />
<br />
1) I value their time by setting a time limit,<br />
2) I value their opinion because I want it from their point of view, and<br />
3) I hold out hope and optimism that I might be improving their personal situation.<br />
<br />
Most often the person will give me their time right then but if they're too busy, I don't press too hard but ask when would be a better time and suggest a time. This gives them lots of space in case there's apprehension but also lets them know I'm respectful to their time.<br />
<br />
For the one-on-one session, select a neutral, non-threatening, private, and casual space. You should avoid meeting rooms if you can as these are usually sterile and a bit too formal for your purposes. At one company they had a room with sofas where I did these and it provided a very relaxed atmosphere.<br />
<br />
<h2>
Conduct the one-on-one</h2>
<br />
I open the discussion with a promise of non-attribution and ask if it's ok for me to take notes. If you can do this without notes that's better. I have a standard set of questions that ask, worded appropriately for the context. I ask these specifically in this order starting with what are their expectations of me followed by things that might be slowing them or the team down. I finish with a very personal question that almost always is a surprise to the team member. Examples of these are:<br />
<br />
<ol>
<li>Why do you think I am coaching your team?</li>
<li>What difference do you hope I'll make?</li>
<li>What do you want to learn from me?</li>
<li>What outside influences hold the team back?</li>
<li>What internal barriers/impediments hold the team back?</li>
<li>What can we continue doing or do more of to make life on the team better?</li>
<li>How can we work more effectively?</li>
<li>Why did you come to work this morning?</li>
</ol>
<br />
The first question is important as it sets up all the followup questions but it also sets the tone. I might specifically say, "My job description says to implement Scrum but I didn't get a strong sense of team's perspective of what that means. Why do you think I'm here?" The tone I'm trying to set is I'm here to learn and not coming in with an agenda.<br />
<br />
It's also important that however these questions are put forward, use the exact same structure if not word for word, with each team member. This makes it better and easier to compare and consolidate their responses.<br />
<br />
At the end of 30 minutes, conclude the session with a very sincere thank you, repeating the key results and promises to follow up.<br />
<br />
Spend a few minutes after the person's left to collect your impressions. Clearly note the issues brought up and what you may have promised to do.<br />
<br />
<h2>
Making sense of the results</h2>
Once you've gathered your notes from all discussions with team members, including the Product Owner, begin consolidation and looking for common threads. Use this to help prioritize you contributions for improvements. How to do this with examples will be the topic of my next post coming soon.<br />
<br />
Thank you for reading and I welcome your comments and suggestions.<br />
<br />
<br />Bob Boydhttp://www.blogger.com/profile/12902323994439824982noreply@blogger.com0tag:blogger.com,1999:blog-3482862331871918329.post-90454773651133854592016-10-01T11:10:00.000+10:002016-10-17T10:21:24.513+11:00First day as Scrum MasterIf you've been hired as a Scrum Master, you'll most likely have a vision of the future state of the team based on interview questions. But do you really know what's going on? Here's what I have done to start integrating myself with the team and building my knowledge.<br />
<br />
The very first thing to do after you get a brief tour of the place, it always starts with a tour, is have a general meet and greet session with your team. Tell them your story, invite questions, and if appropriate, like the team is new to Scrum, discuss why you're there. This is a light-weight meeting more about introductions than any deep understanding. But, you're not just saying hello, you're watching and listening closely. The team will almost certainly be on their best behavior at this first meeting so the clues of how they interact will be subtle and mostly come from body language. Watch how the others react when someone speaks.<br />
<br />
Start by asking each team member in turn what their most recent proudest moment, greatest success, or greatest satisfaction was as a member of the team. As you go, note the introverts and extroverts, the cynics and optimists, and note how many shared the same positive experiences. If everyone shares the same experience as their best then this becomes your target of understanding later, that is, what about that experience pulled the team together. If there are several 'greatest' moments then you'll need to dive into this during the one-on-one meetings with the team after to figure out how each person measures success.<br />
<br />
Ask each member in turn what their biggest issue or impediment is. Write this down. Be seen as writing it down. This is important as you need to follow-up. The first question is about past successes but the second question is about the team's future and although not explicitly stated, it's setting the goal of more successes in the future.<br />
<br />
On your first day, you're looking to set the tone as an open and honest person, as someone who cares about the team, as someone the team can be open with, and as someone there to help. You can do this following these three steps:<br />
<br />
1. Telling your story with some personal details, family, pets, an awkward moment but use caution to not go too far. You want to leave the team yearning to learn more about you, not for them to make final judgments.<br />
<br />
2. Ask a question about team successes that helps to reveal team dynamics and ask it of each individual. Listen and watch closer for clues to the team. Be cautious that you're not judging but ask any follow-up questions to draw out the experience they felt.<br />
<br />
3. Ask the question of what the team expects or hopes you can do for them. You make it clear that you serve the team. Resist any temptations to "solve" problems here, this is not the setting. Do follow-up on any issues or problems, you need to establish that you're there to actively help.<br />
<br />
The next thing to do is conduct a one-on-one interviews but this is another topic.<br />
<br />
Have a supremely successful week.Bob Boydhttp://www.blogger.com/profile/12902323994439824982noreply@blogger.com1tag:blogger.com,1999:blog-3482862331871918329.post-10647366320152217232016-09-25T07:01:00.000+10:002016-09-25T07:01:40.508+10:00Leadership and Vision<header class="entry-header"><h2 class="entry-title">
<br /></h2>
</header><!-- .entry-header --> <br />
<div class="entry-content">
<em>If you want to build a ship, don’t drum up the people to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea.</em> – Antoine De Saint-Exupery, Author of The Little Prince<br />
<br />
When you’re working to change the way things work, always strive to provide a strong and compelling vision. If you’re simply telling people to do ‘A’, ‘B’, and ‘C’, and you have the authority to do so, then you’ll most likely get compliance. You’ll also probably get something done in the near term but it’s very unlikely that the change will sustain itself.<br />
<br />
Instead, share the the vision of a better world with the team, share the hoped for impact of the change and share why it might be better. Share too the idea that it’s an experiment to be better. If the team can see the vision, have them provide the way to achieve it. Then, serve the team by helping them achieve it.<br />
<br />
Try these three steps: Vision, Actions, and Outcomes.<br />
<br />
<b>Vision:</b> As a Scrum Master or as a Product Owner, I see the Team talking with customers, understanding their pain points; getting to the heart of the problem the customer most wants solved.<br />
<br />
<b>Actions:</b> Create an interview script that has the interviewer asking some questions. Pair off the team members so that only two meet with the customer. Identify what customers to talk to and arrange a casual meeting over coffee. Conduct the interview using a pull technique to get their number one problem and what their world would look like with it solved.<br />
<br />
<b>Outcomes:</b> A Lean Business Canvas to make visible the hoped for business outcomes, a release plan if the the business plan is feasible<br />
<br />
The Vision in the example above doesn't specify what happens afterward but only after the vision is established do the Actions and Outcomes become apparent.<br />
<br /></div>
Bob Boydhttp://www.blogger.com/profile/12902323994439824982noreply@blogger.com0tag:blogger.com,1999:blog-3482862331871918329.post-8672380125170404722016-03-12T12:43:00.000+11:002019-08-29T09:30:41.873+10:00Agile: Don’t Sell It, Demonstrate It<div class="MsoNormal">
<br /></div>
<h1>
<!--[if gte vml 1]><v:shapetype id="_x0000_t75" coordsize="21600,21600"
o:spt="75" o:preferrelative="t" path="m@4@5l@4@11@9@11@9@5xe" filled="f"
stroked="f">
<v:stroke joinstyle="miter"/>
<v:formulas>
<v:f eqn="if lineDrawn pixelLineWidth 0"/>
<v:f eqn="sum @0 1 0"/>
<v:f eqn="sum 0 0 @1"/>
<v:f eqn="prod @2 1 2"/>
<v:f eqn="prod @3 21600 pixelWidth"/>
<v:f eqn="prod @3 21600 pixelHeight"/>
<v:f eqn="sum @0 0 1"/>
<v:f eqn="prod @6 1 2"/>
<v:f eqn="prod @7 21600 pixelWidth"/>
<v:f eqn="sum @8 21600 0"/>
<v:f eqn="prod @7 21600 pixelHeight"/>
<v:f eqn="sum @10 21600 0"/>
</v:formulas>
<v:path o:extrusionok="f" gradientshapeok="t" o:connecttype="rect"/>
<o:lock v:ext="edit" aspectratio="t"/>
</v:shapetype><v:shape id="Picture_x0020_1" o:spid="_x0000_i1025" type="#_x0000_t75"
style='width:468pt;height:343.2pt;visibility:visible;mso-wrap-style:square'>
<v:imagedata src="file:///C:\Users\BobB\AppData\Local\Temp\msohtmlclip1\01\clip_image001.jpg"
o:title=""/>
</v:shape><![endif]--><!--[if !vml]--><!--[endif]--><span lang="EN-US"><o:p></o:p></span></h1>
<div class="separator" style="clear: both; text-align: left;">
<a href="https://3.bp.blogspot.com/-DtPv363w2r0/VuNyGlQLm8I/AAAAAAAAALY/csWYHCzKyEQfbK5ipq8rWuGQKEyoAjU9w/s1600/journey%2Bof%2Bagility.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="291" src="https://3.bp.blogspot.com/-DtPv363w2r0/VuNyGlQLm8I/AAAAAAAAALY/csWYHCzKyEQfbK5ipq8rWuGQKEyoAjU9w/s400/journey%2Bof%2Bagility.jpg" width="400" /></a></div>
<div class="MsoPlainText">
<br /></div>
<div class="MsoPlainText">
<span lang="EN-US"><br /></span></div>
<div class="MsoNormal" style="margin-bottom: 24pt;">
<span lang="EN-US">There are many things you can sell including some ideas but
you can’t “sell” behavior and you should not try to sell Agile to people. Both
of these are learned and become part of what you are; they become the standards
of behavior by which you live. Because these are learned, try substituting
“demonstrate” for “selling”. This is not to say you don’t persuade your
C-Levels of the merits of Agile so you can experiment but selling alone isn’t
going to be enough. If you approach your C-Levels about being Agile you might
start at a disadvantage because, unless they're planning on becoming an
Executive Scrum team, their main interest in Agile will most likely rest on
results and outcomes, not theories. To put another way, if the business needs a
hole, talking about the merits of using a shovel over a spoon won’t get the
hole dug and won’t bring any value to the business. Instead, demonstrate a
great and mighty hole can be dug quicker and more efficiently with a shovel,
then do it again just to show it’s repeatable.<o:p></o:p></span></div>
<h2>
<span lang="EN-US">The
Experiment<o:p></o:p></span></h2>
<div class="MsoNormal" style="margin-bottom: 24pt;">
<span lang="EN-US">When I first started using Agile, the CEO & company were
faced with a particularly challenging business opportunity requiring an
innovative software solution in 3-months. The CEO asked if development could
meet a hard commitment in 3-months but the answer was no. We followed a
Waterfall paradigm at the time but we knew we couldn’t execute successfully in
the short time available using our current methods and practices. Being in the
right place (the business needed an alternative) and at the right time (we had
just completed research into the various Agile methodologies), and of the
proper Agile frame of mind (we were eager to experiment with Agile), I was able
to implement a variant of Agile Scrum that allowed us to pivot 180 degrees and
build a software solution within that 3-month window. Agile and Scrum made it
possible for Development and Product Management to capitalize on our business
opportunity quickly and efficiently. Did the CEO want us to do Agile? The
simple answer was he really didn’t care what means or tools we used to be
successful; what he wanted was for us to be successful. Adopting a flavor of
Agile gave him and the business the result and success they wanted. And once he
had seen a positive result, he asked why all the development teams weren’t
using “that Agile thing”.<o:p></o:p></span></div>
<h2>
<span lang="EN-US">The
Demonstration</span><span lang="EN-US" style="font-family: "calibri" , sans-serif; font-size: 11.0pt; line-height: 107%;"><o:p></o:p></span></h2>
<div class="MsoNormal" style="margin-bottom: 24pt;">
<span lang="EN-US">The CEO was never “sold” the idea that Agile was anything
special but instead we demonstrated that Agile could bring special results. The
CEO, the board, and the shareholders want the company to be successful and
profitable. If the way to achieve success is both repeatable and sustainable,
all the better. If they had that success using Waterfall or Agile or any of the
dozen or so other software methodologies, everyone would be happy. The R&D
Manager and Head of Product Management suggested to the CEO that the only real
possibility of success lies with using an Agile Scrum framework and practices.
This was essentially the only executive coaching needed. The high visibility
resulting from using Agile Scrum and Agile’s built in ability for the team to
absorb changing requirements, gave the company a fighting chance to take
advantage of the opportunity which, in the end, was met, exceeding most
expectations.<o:p></o:p></span></div>
<br />
<div class="MsoNormal" style="margin-bottom: 24pt;">
<span lang="EN-US">To move the business at its highest levels often requires a
demonstrable success. A business may still choose not to change after a
demonstration (or two) but what are your chances for change if all you have are
theories and anecdotal data from other companies?<o:p></o:p></span></div>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-3482862331871918329.post-65161912238176747502015-10-28T10:00:00.001+11:002015-10-28T10:00:27.716+11:00Product Backlog FlowsThere are plenty of discussions in the agile community about how agile teams work and develop over time. Often neglected or poorly understood is how that work makes its way from the customer to the team. Below is a blueprint for creating an effective and efficient flow of work. I’ve included details but also left it flexible enough to be customized for your company’s specific circumstances. <br />
<br />
- See more at: <a href="http://pragmaticmarketing.com/resources/product-backlog-flows#sthash.7ZvUkYFt.dpuf">http://pragmaticmarketing.com/resources/product-backlog-flows#sthash.7ZvUkYFt.dpuf</a><br />
<br />
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-3482862331871918329.post-91961347023134475432015-10-28T08:07:00.000+11:002015-10-28T08:07:27.314+11:00Self-Organizing Development Team
<b><span lang="EN-AU" style="font-size: 16pt; mso-ansi-language: EN-AU;"><span style="font-family: Calibri;">Definitions<o:p></o:p></span></span></b><br />
<br />
<div class="MsoListParagraph" style="margin: 0in 0in 0pt 0.5in; mso-list: l1 level1 lfo1; text-indent: -0.25in;">
<!--[if !supportLists]--><span lang="EN-AU" style="font-family: Symbol; mso-ansi-language: EN-AU; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"> </span></span></span><!--[endif]--><span lang="EN-AU" style="mso-ansi-language: EN-AU;"><span style="font-family: Calibri;">Self-organizing
teams are composed of individuals who manage their own work, pick up work based
on need, and participate in team decision making.<o:p></o:p></span></span></div>
<br />
<div class="MsoListParagraph" style="margin: 0in 0in 0pt 0.5in; mso-list: l1 level1 lfo1; text-indent: -0.25in;">
<!--[if !supportLists]--><span lang="EN-AU" style="font-family: Symbol; mso-ansi-language: EN-AU; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"> </span></span></span><!--[endif]--><span lang="EN-AU" style="mso-ansi-language: EN-AU;"><span style="font-family: Calibri;">Self-organizing
teams must have a common focus, mutual trust, and respect.<o:p></o:p></span></span></div>
<br />
<div class="MsoNormal" style="margin: 0in 0in 0pt;">
<span lang="EN-AU" style="mso-ansi-language: EN-AU;"><span style="font-family: Calibri;">By being
self-organizing and self-managing, the team brings decision making to the level
of the problem. This increases the speed and accuracy of problem solving.<o:p></o:p></span></span></div>
<br />
<div class="MsoNormal" style="margin: 0in 0in 0pt;">
<b><span lang="EN-AU" style="font-size: 16pt; mso-ansi-language: EN-AU;"><span style="font-family: Calibri;">Self-organizing and the Scrum Framework<o:p></o:p></span></span></b></div>
<br />
<div class="MsoNormal" style="margin: 0in 0in 0pt;">
<span lang="EN-AU" style="mso-ansi-language: EN-AU;"><span style="font-family: Calibri;">The Scrum
Guide gives the Scrum Master the role of coaching the
Development Team in self-organization but doesn't provide insight or
guide as how this is accomplished. So …<o:p></o:p></span></span></div>
<b><span lang="EN-AU" style="font-size: 16pt; mso-ansi-language: EN-AU;"><span style="font-family: Calibri;"></span></span></b><br />
<b><span lang="EN-AU" style="font-size: 16pt; mso-ansi-language: EN-AU;"><span style="font-family: Calibri;">Tips For Management, Agile Coach, and Scrum Master to organize a team
toward self-organization<o:p></o:p></span></span></b><br />
<br />
<div class="MsoListParagraph" style="margin: 0in 0in 0pt 0.5in; mso-list: l0 level1 lfo2; text-indent: -0.25in;">
<!--[if !supportLists]--><span lang="EN-AU" style="font-family: Symbol; mso-ansi-language: EN-AU; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"> </span></span></span><!--[endif]--><span lang="EN-AU" style="mso-ansi-language: EN-AU;"><span style="font-family: Calibri;">Management
(yes, management) must establish any parameters that the scrum team is required
to work within. For example, usually only managers can hire and fire people.
Otherwise, management should ensure they don’t get in the team’s way. Managers
need to support the scrum teams rather than be a distraction.<o:p></o:p></span></span></div>
<br />
<div class="MsoListParagraph" style="margin: 0in 0in 0pt 0.5in; mso-list: l0 level1 lfo2; text-indent: -0.25in;">
<!--[if !supportLists]--><span lang="EN-AU" style="font-family: Symbol; mso-ansi-language: EN-AU; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"> </span></span></span><!--[endif]--><span lang="EN-AU" style="mso-ansi-language: EN-AU;"><span style="font-family: Calibri;">Give
a scrum team room enough to fail in order to allow them to succeed. Managers
must not ‘step in’ every time they perceive the team is on the wrong track. The
team may very well be on the wrong track but there are several inspect &
adapt opportunities for the scrum team to correct itself. This is the big
reason sprints are short, no more than 30 days, and most often 1 or 2-weeks
long. I've seen a development team start a sprint, go down the wrong architectural
path, discover it, do a re-design, re-do work they had already done,
and still meet the sprint goal. True story. However, the chief architect had
chewed his nails down to the knuckle while not saying anything. How proud was
the development team after this? Extremely – they were trusted to get the job
done and done right.<o:p></o:p></span></span></div>
<br />
<div class="MsoListParagraph" style="margin: 0in 0in 0pt 0.5in; mso-list: l0 level1 lfo2; text-indent: -0.25in;">
<!--[if !supportLists]--><span lang="EN-AU" style="font-family: Symbol; mso-ansi-language: EN-AU; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"> </span></span></span><!--[endif]--><span lang="EN-AU" style="mso-ansi-language: EN-AU;"><span style="font-family: Calibri;">From
the start, guide the team to do scrum (scrum guide). Shape the mindset and expectations from the start as this will be
harder to influence and change later. Doing scrum by-the-book will not make you
good at doing scrum but it will be easier for the team to later learn and adopt
the nuances and spirit of scrum. <o:p></o:p></span></span></div>
<br />
<div class="MsoListParagraph" style="margin: 0in 0in 0pt 0.5in; mso-list: l0 level1 lfo2; text-indent: -0.25in;">
<!--[if !supportLists]--><span lang="EN-AU" style="font-family: Symbol; mso-ansi-language: EN-AU; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"> </span></span></span><!--[endif]--><span lang="EN-AU" style="mso-ansi-language: EN-AU;"><span style="font-family: Calibri;">Help
the team become confident in their use of scrum early on. Use examples of how
each inspect & adapt meeting can help improve the team’s work and their
environment.<o:p></o:p></span></span></div>
<br />
<div class="MsoListParagraph" style="margin: 0in 0in 0pt 0.5in; mso-list: l0 level1 lfo2; text-indent: -0.25in;">
<!--[if !supportLists]--><span lang="EN-AU" style="font-family: Symbol; mso-ansi-language: EN-AU; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"> </span></span></span><!--[endif]--><span lang="EN-AU" style="mso-ansi-language: EN-AU;"><span style="font-family: Calibri;">Remove
any misconceptions the team has of scrum. Most teams will perceive that scrum
is easy to do but it is actually hard to do scrum right day after day.
Anticipate the development team’s reaction to this truth. <o:p></o:p></span></span></div>
<br />
<div class="MsoListParagraph" style="margin: 0in 0in 0pt 0.5in; mso-list: l0 level1 lfo2; text-indent: -0.25in;">
<!--[if !supportLists]--><span lang="EN-AU" style="font-family: Symbol; mso-ansi-language: EN-AU; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"> </span></span></span><!--[endif]--><span lang="EN-AU" style="mso-ansi-language: EN-AU;"><span style="font-family: Calibri;">Use
positive reinforcement and build a sense of achievement in the team by helping
guide the team to successfully completing their sprints. Do not allow a team to
over-commit in their sprint planning meeting based on hope alone. Guide the team to select a sprint
goal that is achievable and don’t let ‘hope we’ll get it done’ be the team’s
strategy. Hope is not a strategy.<o:p></o:p></span></span></div>
<br />
<div class="MsoListParagraph" style="margin: 0in 0in 0pt 0.5in; mso-list: l0 level1 lfo2; text-indent: -0.25in;">
<!--[if !supportLists]--><span lang="EN-AU" style="font-family: Symbol; mso-ansi-language: EN-AU; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"> </span></span></span><!--[endif]--><span lang="EN-AU" style="mso-ansi-language: EN-AU;"><span style="font-family: Calibri;">Encourage
ongoing adherence to scrum and agile practices. Watch for danger signs the team
is reverting to older, non-agile ways of thinking and doing. For example, do
they want to skip the daily scrum or sprint retrospective. Do they think only
one person can do work in a specific area. Are they not forthcoming at
meetings.<o:p></o:p></span></span></div>
<br />
<div class="MsoListParagraph" style="margin: 0in 0in 0pt 0.5in; mso-list: l0 level1 lfo2; text-indent: -0.25in;">
<!--[if !supportLists]--><span lang="EN-AU" style="font-family: Symbol; mso-ansi-language: EN-AU; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"> </span></span></span><!--[endif]--><span lang="EN-AU" style="mso-ansi-language: EN-AU;"><span style="font-family: Calibri;">Get
the customers and users involved in the process. Customers and users need to be
engaged during requirement gathering but most importantly, must be engaged with
the scrum team during the sprint review. If the customers or users are
consistent no-shows at the sprint review or not showing interest at the sprint
results, the development team will more likely lose their sense of purpose and
possibly blame agile for their lowered self-worth.<o:p></o:p></span></span></div>
<br />
<div class="MsoListParagraph" style="margin: 0in 0in 0pt 0.5in; mso-list: l0 level1 lfo2; text-indent: -0.25in;">
<!--[if !supportLists]--><span lang="EN-AU" style="font-family: Symbol; mso-ansi-language: EN-AU; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"> </span></span></span><!--[endif]--><span lang="EN-AU" style="mso-ansi-language: EN-AU;"><span style="font-family: Calibri;">Inspect
& Adapt over blame. When someone on the team messes up, don’t say “Jane
screwed up” or anything like this. I would try and restate it along the lines,
“how was it the team allowed this thing to happen and what can the team do to prevent this from happening again?” Encourage the team to
re-examine their team processes to see if something needs to change to avoid
repetition. Every effort should be made to make the team, as an entity,
the focal point during inspect & adapt meetings and discussions rather than
specific individuals. This will help reinforce that the everyone on the team is
equally responsible and accountable for the results and outcomes of the
team. This is along the “all for one and one for all” philosophy. While it’s
important to know someone forgot to get their code, document, etc. reviewed,
it’s more important to understand how the <u>team</u> allowed this to happen
and to see if there’s something the <u>team</u> can do in the future to prevent
it from happening again. <o:p></o:p></span></span></div>
<br />
<div class="MsoListParagraph" style="margin: 0in 0in 0pt 0.5in; mso-list: l0 level1 lfo2; text-indent: -0.25in;">
<!--[if !supportLists]--><span lang="EN-AU" style="font-family: Symbol; mso-ansi-language: EN-AU; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"> </span></span></span><!--[endif]--><span lang="EN-AU" style="mso-ansi-language: EN-AU;"><span style="font-family: Calibri;">Identify
team members who hamper or slow down the team’s productivity because of their
personal characteristics and practices. Individual personality of team members
can be considered more important than skill sets when selecting people for a
development team. Work with the team and management to remove people who have
difficulties adjusting to agile. This is a hard decision but one that needs to
happen quickly; these are not ‘bad’ people but are people who can’t adjust to
agile and scrum ways of thinking. Many believe the most productive scrum teams
are open, honest, willing to change, and can see the team being greater than
the sum of the individual team members. If a person doesn’t have or can’t
quickly acquire these characteristics, then they may be an obstacle to
self-organization and pose a threat to productivity necessitating their
removal.<o:p></o:p></span></span></div>
Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-3482862331871918329.post-28418310102560278582015-04-29T06:59:00.001+10:002015-04-29T06:59:42.136+10:00Why Just Saying "Good Job" Might Be a Bad IdeaHave you been to a Sprint Review where someone sings out, "good job"?<br />
<br />
When this happens we might feel happy or encouraged to continue doing whatever it is we did in the review but what does this comment really mean? The idea that someone calls over their shoulder "Good Job" as they leave a meeting, can leave the team in a slight quandary, what exactly was good?<br />
<br />
Scrum Teams need to be able to improve in areas where improvement is warranted. Having constructive criticism is healthy for the team and can help them focus on improving whether that be taking a valuable behaviour or practice and making it better or re-thinking actions and activities that don't add much value. The key is getting valuable feedback. For the Scrum Team, it's important to get as specific as possible about what someone thought was good (or in need of improvement) but more importantly, is why they thought to mention it in the first place.<br />
<br />
Understanding why is arguably more important than the what in two aspects: 1) it can bring the Scrum Team insight to what the stakeholder values and 2) it can inspire the Scrum Team to design and build better solutions to meet stakeholder expectations of valuable software. For example, if a stakeholder says they liked the demo segment of the sprint review because it showed an easy way to make a credit card payment, the Scrum Team might conclude that the stakeholder values simplicity in the user experience. The Scrum Team might also conclude that in the future, they'll put a little more attention in the UX design to exploit simplicity.<br />
<br />
Scrum Teams need feedback to self-improve and need to find the best way to get the gather this information. The easiest way is for the Scrum Team to listen for all stakeholder comments during any of the team's Inspect & Adapt events (daily standup, sprint planning, sprint review). The team may need to follow up with the stakeholders to understand the what and why of their statements. Through the practice of 'Active Listening' and developing a deeper understanding of stakeholders intent, the Scrum Team can improve and provide greater value to the team's customers and stakeholders.Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-3482862331871918329.post-72427243288023515922015-03-20T05:30:00.001+11:002015-03-20T05:31:00.800+11:00The Scrum Master: Career Path or Career Oblivion<br />
What is the career path for a Scrum Master?<br />
<br />
That question was raised recently when I was asking people in the Development department if they thought they'd like to be a Scrum Master and whether they would apply for a Scrum Master role. Of course the question and answer related to their specific company but I've heard the same question asked at Agile meetups and Agile conferences. The short answer [to me] is: there's a clear career path for Scrum Masters. The key to this career path is growth. Let me explain.<br />
<br />
Those of you that work in Development are sometimes isolated from the business. This is not an insurmountable problem but let's be honest, work on products occurs in Development and the business of the company occurs in the sales/marketing offices of the various regions. You could think of Development having the intellectual property of the product, the brain, whereas the regional sales/marketing teams (Americas, Asia, Europe, Australia, Africa) form the heart. Neither can survive without the other and both are necessary for growth and vitality. The best scenario is that the brain (Development) and the heart (sales/marketing teams with their customer insights) work together in a seamless, symbiotic relationship. Establishing and maintaining a great communications link, having everyone working from the same page, and working toward a shared product vision are essential ingredients for growth. From a Scrum prospective, the Scrum Masters are the people whose role it is to find a way to make this happen.<br />
<br />
In the <a href="http://www.scrumguides.org/" target="_blank">Scrum Guide</a>, Ken Schwaber and Jeff Sutherland imagine a world where the Scrum Masters, get the organization to understand and work with the Scrum Teams by:<br />
<br />
<ul>
<li>Leading and coaching the organization in its Scrum adoption,</li>
<li>Planning Scrum implementations within the organization,</li>
<li>Helping employees and stakeholders understand and enact Scrum and empirical product development, and</li>
<li>Causing change that increases the productivity of the Scrum Team.</li>
</ul>
<div>
A Scrum Master will hasten the adoption of Scrum Values (from the <a href="https://www.scrumalliance.org/why-scrum/core-scrum-values-roles" target="_blank">Scrum Alliance</a>) </div>
<ul>
<li>Focus - Because we focus on only a few things at a time, we work well together and produce excellent work. We deliver valuable items sooner. </li>
<li>Courage - Because we work as a team, we feel supported and have more resources at our disposal. This gives us the courage to undertake greater challenges. </li>
<li>Openness - As we work together, we express how we're doing, what's in our way, and our concerns so they can be addressed.</li>
<li>Commitment - Because we have great control over our own destiny, we are more committed to success.</li>
<li>Respect - As we work together, sharing successes and failures, we come to respect each other and to help each other become worthy of respect.</li>
</ul>
<br />
But how does this lead to a career path?<br />
<br />
By improving lines of communications, by getting those in direct contact with customers communicating the pain customers feel, by getting the product development teams to have empathy with the customer, by understanding the impact of technical solutions on the customers, by keeping all aspects of the business informed of customer problems and potential solutions, by being transparent, by continually striving to improve, by creating a culture where learning trumps blame, by creating a culture where the question is not, "what have you done?" but instead, "how can I help you?", by doing all these and more, the Scrum Master will create the opportunity for the company to experience unprecedented growth. And when you have growth, you create more jobs and a larger product base and with that comes the need for more sales people, more marketers, more product managers, more products, more projects, and more Scrum Teams. I should say that Scrum Masters are almost never ever directly responsible for a company's growth. However, through the actions of the Scrum Master and many of the communication improvements and process streamlining, the inevitable result will most likely be growth.<br />
<br />
Scrum Masters typically move into roles like product owner, product manager, head product owner, head of product management, program manager, project director, program director, agile coaching, development manager, technology manager, and others. Most of these roles may not exist today but with growth and expansion, some of these roles will come into being.<br />
<br />
Whether your company or business has a global footprint or is a young Start-up, Agile and Scrum can be tools for growth and the Scrum Master role is positioned so that the results of good Scrum Mastery is company growth. Once there's growth, there almost always follows more and greater opportunities. Who is better positioned to move up and forward than the Scrum Master?<br />
<br />
Your thoughts?<br />
<br />Unknownnoreply@blogger.com5tag:blogger.com,1999:blog-3482862331871918329.post-31397613350434373752013-06-20T06:00:00.002+10:002013-06-20T06:00:50.401+10:00Organizational Adoption of Agile<div style="text-align: justify;">
F<span style="font-family: Calibri;">rom <a href="http://www.craiglarman.com/" target="_blank">Craig Larman</a> - </span><a href="http://www.craiglarman.com/wiki/index.php?title=Larman%27s_Laws_of_Organizational_Behavior"><span style="color: blue; font-family: Calibri;">Larman's
laws</span></a><span style="font-family: Calibri;"> of organizational behaviour:</span></div>
<div style="text-align: justify;">
</div>
<div class="MsoListParagraph" style="margin: 0cm 0cm 0pt 36pt; mso-list: l0 level1 lfo1; text-align: justify; text-indent: -18pt;">
<!--[if !supportLists]--><i><span style="mso-bidi-font-family: Calibri; mso-fareast-font-family: Calibri;"><span style="mso-list: Ignore;"><span style="font-family: Calibri;">1.</span><span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";">
</span></span></span></i><!--[endif]--><i><span style="font-family: Calibri;">Organizations are implicitly optimized to
avoid changing the status quo middle- and first-level manager and
"specialist" positions & power structures</span></i></div>
<div style="text-align: justify;">
</div>
<div class="MsoListParagraph" style="margin: 0cm 0cm 0pt 36pt; mso-list: l0 level1 lfo1; text-align: justify; text-indent: -18pt;">
<!--[if !supportLists]--><i><span style="mso-bidi-font-family: Calibri; mso-fareast-font-family: Calibri;"><span style="mso-list: Ignore;"><span style="font-family: Calibri;">2.</span><span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";">
</span></span></span></i><!--[endif]--><i><span style="font-family: Calibri;">As a corollary to (1), any change
initiative will be reduced to overloading the new terminology to mean basically
the same as status quo</span></i></div>
<div style="text-align: justify;">
</div>
<div class="MsoListParagraph" style="margin: 0cm 0cm 0pt 36pt; mso-list: l0 level1 lfo1; text-align: justify; text-indent: -18pt;">
<!--[if !supportLists]--><i><span style="mso-bidi-font-family: Calibri; mso-fareast-font-family: Calibri;"><span style="mso-list: Ignore;"><span style="font-family: Calibri;">3.</span><span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";">
</span></span></span></i><!--[endif]--><i><span style="font-family: Calibri;">As a corollary to (1), any significant
change initiative will be derided as "purist" and "needing
customization for local concerns" -- which deflects from addressing
weaknesses and manager/specialist status quo</span></i></div>
<div style="text-align: justify;">
</div>
<div class="MsoListParagraph" style="margin: 0cm 0cm 0pt 36pt; mso-list: l0 level1 lfo1; text-align: justify; text-indent: -18pt;">
<!--[if !supportLists]--><i><span style="mso-bidi-font-family: Calibri; mso-fareast-font-family: Calibri;"><span style="mso-list: Ignore;"><span style="font-family: Calibri;">4.</span><span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";">
</span></span></span></i><!--[endif]--><i><span style="font-family: Calibri;">Culture follows structure. <o:p></o:p></span></i></div>
<div style="text-align: justify;">
</div>
<div class="MsoListParagraph" style="margin: 0cm 0cm 0pt 36pt; text-align: justify;">
<i><span style="font-family: Calibri;">i.e., if you want to really change culture, you
have to start with changing structure, because culture does not really change
otherwise. and that's why deep systems of thought such as organizational
learning are not very sticky or impactful by themselves, and why systems such
as scrum (that have a strong focus on structural change at the start) tend to
more quickly impact culture. John Seddon also observed this: "Attempting
to change an organization's culture is a folly, it always fails. Peoples' behaviour
(the culture) is a product of the system; when you change the system peoples'
behaviour changes."</span></i></div>
<div class="MsoListParagraph" style="margin: 0cm 0cm 0pt 36pt; text-align: justify;">
</div>
<div style="text-align: justify;">
<span style="font-family: Calibri;">I think that those who believe Agile and Scrum are
the way forward will be at odds with most businesses that have a deep
institutionalized Command & Control structures that rests responsibility,
but usually not accountability, within groups/committees while diverting
responsibility away from individuals. In Scrum we rest most responsibility on
the Product Owner and hold this person accountable for the business value
delivered at the end of each and every sprint. It is often this simplicity
Scrum provides that is in direct conflict with the ‘status quo’. So how to
begin changes to the existing structures?</span></div>
<div class="MsoNormal" style="margin: 0cm 0cm 0pt; text-align: justify;">
</div>
<div class="MsoNormal" style="margin: 0cm 0cm 0pt; text-align: justify;">
<span style="font-family: Calibri;">First and foremost, you must have an Executive Sponsor.
Without Executive Sponsorship your attempt to <u>directly</u> adopt Agile will
almost certainly fail. This is more than just having managers that agree to
allow you to use Agile; this is a person who has the rank and status in the
business structure who can influence the often many groups/committees who
collectively and traditionally have controlled projects. Agile is a
movement that requires top-down leadership to say ‘this is going to happen,
here is why it is good and we should all start rowing in that direction.’ The
Executive Sponsor, along with possibly one or more Agile Coach specifically
trained and experienced in agile adoption at the executive level, will be
handing out the oars.</span></div>
<div class="MsoNormal" style="margin: 0cm 0cm 0pt; text-align: justify;">
</div>
<div class="MsoNormal" style="margin: 0cm 0cm 0pt; text-align: justify;">
<span style="font-family: Calibri;">What if you have no Executive Sponsor or the Executive
Sponsor’s influence is severely limited? Under these circumstances, full Agile
adoption is very unlikely to happen. However, there is a strategy that could
overcome the tremendous obstacles that are in the way but it does depend on you
finding some in Mid to Upper level Management more interested in results rather
than institutionalized processes. The ultimate result is usually a hybrid
adoption of Agile where all or some of the institutional controls remain in
place but an Agile sanctuary is carved out with fewer of these institutional
controls than a traditional waterfall project. This hybrid Agile project is not
truly Agile but neither is it true waterfall. The strategy follows a bottom up
Agile Adoption approach that will take time, maybe a lot of time, to slowly
chip away at the traditional structure and replace it with an Agile structure
and Agile mindset.</span></div>
<div class="MsoNormal" style="margin: 0cm 0cm 0pt; text-align: justify;">
<span style="font-family: Calibri;"></span> </div>
<div class="MsoNormal" style="margin: 0cm 0cm 0pt; text-align: justify;">
<span style="font-family: Calibri;">The strategy is twofold:<o:p></o:p></span></div>
<div style="text-align: justify;">
</div>
<div class="MsoListParagraph" style="margin: 0cm 0cm 0pt 36pt; mso-list: l1 level1 lfo2; text-align: justify; text-indent: -18pt;">
<!--[if !supportLists]--><span style="mso-bidi-font-family: Calibri; mso-fareast-font-family: Calibri;"><span style="mso-list: Ignore;"><span style="font-family: Calibri;">1.</span><span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";">
</span></span></span><!--[endif]--><span style="font-family: Calibri;">Target getting support from managers in the
organization that are more likely to support Agile; and<o:p></o:p></span></div>
<div style="text-align: justify;">
</div>
<div class="MsoListParagraph" style="margin: 0cm 0cm 0pt 36pt; mso-list: l1 level1 lfo2; text-align: justify; text-indent: -18pt;">
<!--[if !supportLists]--><span style="mso-bidi-font-family: Calibri; mso-fareast-font-family: Calibri;"><span style="mso-list: Ignore;"><span style="font-family: Calibri;">2.</span><span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";">
</span></span></span><!--[endif]--><span style="font-family: Calibri;">Target going around the organizational structure
of “over seers”</span></div>
<div class="MsoListParagraph" style="margin: 0cm 0cm 0pt 36pt; mso-list: l1 level1 lfo2; text-align: justify; text-indent: -18pt;">
</div>
<div class="MsoNormal" style="margin: 0cm 0cm 0pt; text-align: justify;">
<span style="font-family: Calibri;">The strategy includes targeting those executives in middle
to upper management that are more likely to support an Agile process and have
some influence on those in the organization who are stanch supporters of the
institutional controls. The idea here is not to change these people completely
over to the Agile mindset but rather get these targeted managers enthusiastic
enough about Agile so they can see the possibilities and potential of Agile.
Targeting managers who don’t have influence over supporters of the processes or
targeting managers who are the stanch supporters of the processes is usually a
tactical mistake. Targeting a manager who doesn’t directly influence those in
control of the processes might be an easy convert but other than a quick burst
of satisfaction, the real battles will still lie ahead. The manager who is a
supporter of institutionalized processes is very difficult to convert; they
probably believe in their familiar processes and controls much like you believe
in Scrum, albeit for different reasons. A word of caution, because you’ve
gotten some support for your Agile project, you must remember that “success has
many fathers, failure is an orphan.” For those in middle to upper management
who supported you earlier, to ensure their continued support of Agile and
endorse its use, hybrid Agile projects must succeed and succeed “loudly”. If
your project fails or succeeds but with only a whimper, some, most, or all
middle to upper manages may forget that they ever supported Agile.</span></div>
<div class="MsoNormal" style="margin: 0cm 0cm 0pt; text-align: justify;">
</div>
<div class="MsoNormal" style="margin: 0cm 0cm 0pt; text-align: justify;">
<span style="font-family: Calibri;">The second part of your Agile adoption strategy will be to
identify all those organizational groups and individuals who traditionally
sign-off on projects and find a way to exempt the Scrum project from these. These groups are
those who sit on gate committees, steering committees, technology committees,
or any one of a dozen other committees that approve, sign-off or use other
mechanisms of “over-seeing” a project. These groups are often a source of power
and prestige for its members and are traditionally very difficult, if not
impossible, to get around without an appropriately positioned Executive
Sponsor. The best way to get around these groups is to make your project a
separate business unit that answers to the CEO/board. This follows along how IBM
built its PC division in order to get out from under the bureaucratic thumb of
IBM’s corporate structure. Another tactic is to chip away at the
required process these groups require projects to follow. This can lead to some
relief for the project but will probably not succeed at allowing full Agile
adoption for quite some time. </span></div>
<div class="MsoNormal" style="margin: 0cm 0cm 0pt; text-align: justify;">
</div>
<div class="MsoNormal" style="margin: 0cm 0cm 0pt; text-align: justify;">
<span style="font-family: Calibri;">Is doing a Hybrid Agile Scrum adoption good? The short
answer is yes. By simply following the activities defined for Scrum, (Sprint
Planning, Daily Scrum, Sprint Review, and Sprint Retrospective), Jeff
Sutherland has said that this will increase productivity by 20%-30%. However,
the greater benefits of Agile are really attained through following of and
embracing the deeper meanings of the Agile Manifesto, the Scrum Guide, and
Scrum Primer. To become “hyper-product” would require everyone involved in the
project (managers and scrum teams) to believe in and live Agile and Scrum.
Unless the Mid to Upper level Managers of the business are only interested in
results and don’t really care how you achieve them, your best approach to
adopting Agile is incrementally, one step at a time.</span></div>
<div style="text-align: justify;">
<span style="font-family: Calibri;"></span> </div>
<div class="MsoNormal" style="margin: 0cm 0cm 0pt; text-align: justify;">
<span style="font-family: Calibri;"><a href="http://www.craiglarman.com/" target="_blank">Craig Larman</a> is co-author of:<o:p></o:p></span></div>
<ul>
<li><div style="text-align: justify;">
<span style="font-family: Calibri;">Practices for Scaling Lean & Agile Development: Large, Multisite & Offshore Product Development with Large-Scale Scrum</span></div>
</li>
<li><div style="text-align: justify;">
<span style="font-family: Calibri;">Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum</span></div>
</li>
<li><div style="text-align: justify;">
<span style="font-family: Calibri;">Agile and Iterative Development: A Manager's Guide<o:p></o:p></span></div>
</li>
</ul>
<div style="text-align: justify;">
</div>
Unknownnoreply@blogger.com2tag:blogger.com,1999:blog-3482862331871918329.post-67165520561308125312013-06-03T05:44:00.000+10:002013-06-03T05:45:02.893+10:00Sprint Review Facilitation & Customization<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
<span style="font-family: "Verdana","sans-serif"; font-size: 10pt;">The Scrum
Sprint Review is a key Inspect & Adapt meeting where the Scrum Team
discusses with Users, Customers, and Business stakeholders what was
"Done" in the just completed Sprint. The Sprint Review meeting is
short but must cover the agenda items listed below.
The attendance by the Scrum Team is required. Attendance by stakeholders is
optional but should be strongly encouraged for those key stakeholders most
affected by the Sprint results. This article gives some advice on how to conduct the Sprint Review when stakeholders are unable to physically be present.</span></div>
<div style="text-align: justify;">
<span style="font-family: "Verdana","sans-serif"; font-size: 10pt;"></span> </div>
<div style="text-align: justify;">
<span style="font-family: "Verdana","sans-serif"; font-size: 10pt;">During the
Sprint Review, the Scrum Team and stakeholders collaborate about what was done
in the Sprint and the Product Backlog is amended if needed. Based on that and
any changes to the Product Backlog during the Sprint, attendees collaborate on
the next things that could be done. The Product Owner provides the stakeholders
the likely completion date for the release based on the Development Team's
velocity and work remaining in the Product Backlog. This is an informal
meeting, and the presentation of the Sprint results is intended to elicit
feedback and foster collaboration.</span></div>
<div style="text-align: justify;">
<span style="font-family: "Verdana","sans-serif"; font-size: 10pt;"></span><o:p></o:p> </div>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
<b><span style="font-family: "Verdana","sans-serif"; font-size: 10pt;">One hour Sprint
Review Agenda includes the following elements:</span></b><o:p></o:p></div>
<div style="text-align: justify;">
</div>
<ul type="disc"><div style="text-align: justify;">
</div>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l2 level1 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 36.0pt;"><div style="text-align: justify;">
<span style="font-family: "Verdana","sans-serif"; font-size: 10pt; mso-fareast-font-family: "Times New Roman";">The
Product Owner identifies what has been “Done” and what has not been “Done”
(suggest 5 minutes) </span><span style="mso-fareast-font-family: "Times New Roman";"><o:p></o:p></span></div>
</li>
<div style="text-align: justify;">
</div>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l2 level1 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 36.0pt;"><div style="text-align: justify;">
<span style="font-family: "Verdana","sans-serif"; font-size: 10pt; mso-fareast-font-family: "Times New Roman";">The
Development Team discusses what went well during the Sprint, what problems
it ran into, and how those problems were solved (suggest 10 minutes)</span><span style="mso-fareast-font-family: "Times New Roman";"><o:p></o:p></span></div>
</li>
<div style="text-align: justify;">
</div>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l2 level1 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 36.0pt;"><div style="text-align: justify;">
<span style="font-family: "Verdana","sans-serif"; font-size: 10pt; mso-fareast-font-family: "Times New Roman";">The
Development Team demonstrates the work that it has “Done” and answers
questions about the Increment (suggest 15 minutes)</span><span style="mso-fareast-font-family: "Times New Roman";"><o:p></o:p></span></div>
</li>
<div style="text-align: justify;">
</div>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l2 level1 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 36.0pt;"><div style="text-align: justify;">
<span style="font-family: "Verdana","sans-serif"; font-size: 10pt; mso-fareast-font-family: "Times New Roman";">The
Product Owner discusses the Product Backlog as it stands. He or she
projects likely completion dates based on progress to date (suggest
10 minutes)</span><span style="mso-fareast-font-family: "Times New Roman";"><o:p></o:p></span></div>
</li>
<div style="text-align: justify;">
</div>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l2 level1 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 36.0pt;"><div style="text-align: justify;">
<span style="font-family: "Verdana","sans-serif"; font-size: 10pt; mso-fareast-font-family: "Times New Roman";">The
entire group collaborates on what to do next, so that the Sprint Review
provides valuable input to subsequent Sprint Planning Meetings
(suggest 20 minutes)</span><span style="mso-fareast-font-family: "Times New Roman";"><o:p></o:p></span></div>
</li>
<div style="text-align: justify;">
</div>
</ul>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
<span style="font-family: "Verdana","sans-serif"; font-size: 10pt;"></span> </div>
<div style="text-align: justify;">
<span style="font-family: "Verdana","sans-serif"; font-size: 10pt;">The
feedback from the stakeholders, directed toward the Product Owner and Scrum team, is the
most important thing to get out of the Sprint Review. The result of the Sprint
Review is a revised Product Backlog that defines the probable Product Backlog
items for the next Sprint. The Product Backlog may also be adjusted overall to
meet new opportunities.</span></div>
<div style="text-align: justify;">
<span style="font-family: "Verdana","sans-serif"; font-size: 10pt;"></span><o:p></o:p> </div>
<div style="text-align: justify;">
</div>
<h2 style="text-align: justify;">
<span style="font-family: "Verdana","sans-serif"; font-size: 10pt;">Customization
for Stakeholders who cannot be physically present at the meeting</span><o:p></o:p></h2>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
<span style="font-family: "Verdana","sans-serif"; font-size: 10pt;">A Scrum
Team strives to ensure the key stakeholders, as identified by the Product
Owner, are in attendance at each Sprint Review. The key stakeholders identified
may differ from Sprint to Sprint based upon the work selected in each Sprint,
but it is important to the success of the project that those identified feel
compelled to attend the Sprint Review when asked. When a stakeholder cannot be
physically present at the Sprint Review meeting, the Scrum Team loses out on
viewing subtle hints on the reception of their Sprint results and future Sprint
plans. Stakeholder body language and tone are indispensable clues to the observant
Scrum Team which can be lost when stakeholders are not with the team during the
Sprint Review. Unfortunately the realities of the business means that
stakeholders are distributed across several locations and cannot always be
physically present at the Sprint Review. Below are the options in order of
preference.</span></div>
<div style="text-align: justify;">
<span style="font-family: "Verdana","sans-serif"; font-size: 10pt;"></span> </div>
<h3 style="text-align: justify;">
<span style="font-family: "Verdana","sans-serif"; font-size: 10pt;">Telepresence:</span></h3>
<div style="text-align: justify;">
<b><u><span style="font-family: "Verdana","sans-serif"; font-size: 10pt;"></span></u></b><o:p></o:p> </div>
<div style="text-align: justify;">
</div>
<div style="margin-left: 36pt; text-align: justify;">
<span style="font-family: "Verdana","sans-serif"; font-size: 10pt;">Telepresence
is the preferred method for stakeholder involvement in the Sprint Review when
not able to physically attend. Scrum Master would schedule the telepresence
rooms locally and at all remote locations if possible. The Sprint Review
meeting should be conducted as if all people were in the same room.</span></div>
<div style="margin-left: 36pt; text-align: justify;">
<span style="font-family: "Verdana","sans-serif"; font-size: 10pt;"></span><o:p></o:p> </div>
<div style="text-align: justify;">
</div>
<div style="margin-left: 36pt; text-align: justify;">
<u><span style="font-family: "Verdana","sans-serif"; font-size: 10pt;">Advantages:</span></u><o:p></o:p></div>
<div style="text-align: justify;">
</div>
<ul type="disc"><ul type="circle"><ul type="square">
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level3 lfo2; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 108.0pt;"><div style="text-align: justify;">
<span style="font-family: "Verdana","sans-serif"; font-size: 10pt; mso-fareast-font-family: "Times New Roman";">Stakeholder sees what those present in the meeting
room see</span><span style="mso-fareast-font-family: "Times New Roman";"><o:p></o:p></span></div>
</li>
<div style="text-align: justify;">
</div>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level3 lfo2; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 108.0pt;"><div style="text-align: justify;">
<span style="font-family: "Verdana","sans-serif"; font-size: 10pt; mso-fareast-font-family: "Times New Roman";">Stakeholder is not a disembodied voice but a real person</span><span style="mso-fareast-font-family: "Times New Roman";"><o:p></o:p></span></div>
</li>
<div style="text-align: justify;">
</div>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level3 lfo2; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 108.0pt;"><div style="text-align: justify;">
<span style="font-family: "Verdana","sans-serif"; font-size: 10pt; mso-fareast-font-family: "Times New Roman";">Scrum Team and other meeting attendees can see and
gage stakeholder's reactions to product demo and artifacts</span><span style="mso-fareast-font-family: "Times New Roman";"><o:p></o:p></span></div>
</li>
<div style="text-align: justify;">
</div>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level3 lfo2; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 108.0pt;"><div style="text-align: justify;">
<span style="font-family: "Verdana","sans-serif"; font-size: 10pt; mso-fareast-font-family: "Times New Roman";">Scrum Team and other meeting attendees can see and
gage stakeholder's reaction to comments, statements, and suggestions</span><span style="mso-fareast-font-family: "Times New Roman";"><o:p></o:p></span></div>
</li>
<div style="text-align: justify;">
</div>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level3 lfo2; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 108.0pt;"><div style="text-align: justify;">
<span style="font-family: "Verdana","sans-serif"; font-size: 10pt; mso-fareast-font-family: "Times New Roman";">Facilitator of the Sprint Review can better steer the
Sprint Review back to the Sprint Review agenda when necessary</span><span style="mso-fareast-font-family: "Times New Roman";"><o:p></o:p></span></div>
</li>
<div style="text-align: justify;">
</div>
</ul>
<div style="text-align: justify;">
</div>
</ul>
<div style="text-align: justify;">
<u><span style="font-family: "Verdana","sans-serif"; font-size: 10pt;">Disadvantages:</span></u><o:p></o:p></div>
</ul>
<div style="text-align: justify;">
</div>
<ul type="disc"><ul type="circle"><ul type="square">
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level3 lfo2; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 108.0pt;"><div style="text-align: justify;">
<span style="font-family: "Verdana","sans-serif"; font-size: 10pt; mso-fareast-font-family: "Times New Roman";">Difficult to overhear side conversations from remote
stakeholders</span></div>
</li>
</ul>
</ul>
</ul>
<h3 style="text-align: justify;">
</h3>
<h3 style="text-align: justify;">
<span style="font-family: "Verdana","sans-serif"; font-size: 10pt;">Webex / LiveMeeting / Net Meeting / or other online
collaboration tool:</span></h3>
<div style="text-align: justify;">
<b><u><span style="font-family: "Verdana","sans-serif"; font-size: 10pt;"></span></u></b><o:p></o:p> </div>
<div style="margin-left: 36pt; text-align: justify;">
<span style="font-family: "Verdana","sans-serif"; font-size: 10pt;"><span style="font-family: "Verdana","sans-serif"; font-size: 10pt;">Online collaboration tool is the preferred method for stakeholder involvement in the Sprint Review when not able to physically attend and access to a telepresence room isn't available.</span></span></div>
<div style="margin-left: 36pt; text-align: justify;">
<span style="font-family: "Verdana","sans-serif"; font-size: 10pt;"><span style="font-family: "Verdana","sans-serif"; font-size: 10pt;"></span></span> </div>
<div style="margin-left: 36pt; text-align: justify;">
<span style="font-family: "Verdana","sans-serif"; font-size: 10pt;"><span style="font-family: "Verdana","sans-serif"; font-size: 10pt;">Product Owner should specifically ask remote stakeholders for their input on the way forward for improving the product.</span></span></div>
<div style="text-align: justify;">
<br /></div>
<div style="margin-left: 36pt; text-align: justify;">
<u><span style="font-family: "Verdana","sans-serif"; font-size: 10pt;">Advantages:</span></u></div>
<ul type="disc"><ul type="circle"><ul type="square">
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level3 lfo2; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 108.0pt;"><div style="text-align: justify;">
<span style="font-family: "Verdana","sans-serif"; font-size: 10pt; mso-fareast-font-family: "Times New Roman";">Stakeholder most often see what those present in the
meeting room see</span></div>
</li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level3 lfo2; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 108.0pt;"><div style="text-align: justify;">
<span style="font-family: "Verdana","sans-serif"; font-size: 10pt; mso-fareast-font-family: "Times New Roman";">Stakeholders can follow and participate in discussions on the just completed work shown in the demonstration</span></div>
</li>
</ul>
</ul>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<u><span style="font-family: "Verdana","sans-serif"; font-size: 10pt;">Disadvantages:</span></u></div>
</ul>
<ul type="disc"><ul type="circle"><ul type="square">
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level3 lfo2; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 108.0pt;"><div style="text-align: justify;">
<span style="font-family: "Verdana","sans-serif"; font-size: 10pt; mso-fareast-font-family: "Times New Roman";">All stakeholders will need the same online
collaboration tool installed and available</span><span style="mso-fareast-font-family: "Times New Roman";"><o:p></o:p></span></div>
</li>
<div style="text-align: justify;">
</div>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level3 lfo2; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 108.0pt;"><div style="text-align: justify;">
<span style="font-family: "Verdana","sans-serif"; font-size: 10pt; mso-fareast-font-family: "Times New Roman";">Higher likelihood that remote stakeholders will talk
over people in the meeting room</span><span style="mso-fareast-font-family: "Times New Roman";"><o:p></o:p></span></div>
</li>
<div style="text-align: justify;">
</div>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level3 lfo2; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 108.0pt;"><div style="text-align: justify;">
<span style="font-family: "Verdana","sans-serif"; font-size: 10pt; mso-fareast-font-family: "Times New Roman";">Higher likelihood that people in the meeting room
will talk over the remote stakeholders</span><span style="mso-fareast-font-family: "Times New Roman";"><o:p></o:p></span></div>
</li>
<div style="text-align: justify;">
</div>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level3 lfo2; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 108.0pt;"><div style="text-align: justify;">
<span style="font-family: "Verdana","sans-serif"; font-size: 10pt; mso-fareast-font-family: "Times New Roman";">Easier to mis-read voice inflection and tone without
seeing the body language</span><span style="mso-fareast-font-family: "Times New Roman";"><o:p></o:p></span></div>
</li>
<div style="text-align: justify;">
</div>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level3 lfo2; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 108.0pt;"><div style="text-align: justify;">
<span style="font-family: "Verdana","sans-serif"; font-size: 10pt; mso-fareast-font-family: "Times New Roman";">Difficult to overhear side conversations</span></div>
</li>
</ul>
</ul>
</ul>
<div style="text-align: justify;">
</div>
<h3 style="text-align: justify;">
<span style="font-family: "Verdana","sans-serif"; font-size: 10pt;">Speakerphone:</span></h3>
<div style="text-align: justify;">
<b><u><span style="font-family: "Verdana","sans-serif"; font-size: 10pt;"></span></u></b><o:p></o:p> </div>
<div style="text-align: justify;">
</div>
<div style="margin-left: 36pt; text-align: justify;">
<span style="font-family: "Verdana","sans-serif"; font-size: 10pt;">Using
only a speakerphone (no video link or web sharing) is the last option available for stakeholders
who don't have access to collaboration tools and no access to telepresence
equipment.</span></div>
<div style="margin-left: 36pt; text-align: justify;">
<span style="font-family: "Verdana","sans-serif"; font-size: 10pt;"></span> </div>
<div style="margin-left: 36pt; text-align: justify;">
<span style="font-family: "Verdana","sans-serif"; font-size: 10pt;">To
give the stakeholder a voice in the Sprint Review, the Scrum Master or Product
Owner, as appropriate, would ask those who are remote to provide their input before the Sprint Review meeting so the Scrum Team and stakeholders at the
meeting can review their input together. This way the remote teams know that
their input counts and will heard by all people in the room.</span></div>
<div style="margin-left: 36pt; text-align: justify;">
<span style="font-family: "Verdana","sans-serif"; font-size: 10pt;"></span> </div>
<div style="margin-left: 36pt; text-align: justify;">
<span style="font-family: "Verdana","sans-serif"; font-size: 10pt;">Product
Owner should specifically ask remote stakeholders for their input on the way
forward for improving the product.</span></div>
<div style="margin-left: 36pt; text-align: justify;">
<span style="font-family: "Verdana","sans-serif"; font-size: 10pt;"></span><o:p></o:p> </div>
<div style="text-align: justify;">
</div>
<div style="margin-left: 36pt; text-align: justify;">
<u><span style="font-family: "Verdana","sans-serif"; font-size: 10pt;">Advantages:</span></u></div>
<ul type="disc"><ul type="circle"><ul type="square"><div style="text-align: justify;">
</div>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l1 level3 lfo3; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 108.0pt;"><div style="text-align: justify;">
<span style="font-family: "Verdana","sans-serif"; font-size: 10pt; mso-fareast-font-family: "Times New Roman";">Remote stakeholders have a proxy voice in the Sprint
Review</span></div>
</li>
</ul>
</ul>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<u><span style="font-family: "Verdana","sans-serif"; font-size: 10pt;">Disadvantages:</span></u></div>
</ul>
<ul type="disc"><ul type="circle"><ul type="square"><div style="text-align: justify;">
</div>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l1 level3 lfo3; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 108.0pt;"><div style="text-align: justify;">
<span style="font-family: "Verdana","sans-serif"; font-size: 10pt; mso-fareast-font-family: "Times New Roman";">Speakerphone stakeholders will not see what's being
presented</span><span style="mso-fareast-font-family: "Times New Roman";"><o:p></o:p></span></div>
</li>
<div style="text-align: justify;">
</div>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l1 level3 lfo3; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 108.0pt;"><div style="text-align: justify;">
<span style="font-family: "Verdana","sans-serif"; font-size: 10pt; mso-fareast-font-family: "Times New Roman";">Speakerphone stakeholders will find it
difficult/impossible to follow discussions during the product demo and
presentation of any related artifacts</span><span style="mso-fareast-font-family: "Times New Roman";"><o:p></o:p></span></div>
</li>
<div style="text-align: justify;">
</div>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l1 level3 lfo3; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 108.0pt;"><div style="text-align: justify;">
<span style="font-family: "Verdana","sans-serif"; font-size: 10pt; mso-fareast-font-family: "Times New Roman";">Speakerphone stakeholders may find it difficult to
collaborate with those in the meeting room without seeing the Sprint
results</span><span style="mso-fareast-font-family: "Times New Roman";"><o:p></o:p></span></div>
</li>
<div style="text-align: justify;">
</div>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l1 level3 lfo3; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 108.0pt;"><div style="text-align: justify;">
<span style="font-family: "Verdana","sans-serif"; font-size: 10pt; mso-fareast-font-family: "Times New Roman";">Higher likelihood that remote stakeholders will talk
over people in the meeting room</span><span style="mso-fareast-font-family: "Times New Roman";"><o:p></o:p></span></div>
</li>
<div style="text-align: justify;">
</div>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l1 level3 lfo3; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 108.0pt;"><div style="text-align: justify;">
<span style="font-family: "Verdana","sans-serif"; font-size: 10pt; mso-fareast-font-family: "Times New Roman";">Higher likelihood that people in the meeting room
will talk over the remote stakeholders</span><span style="mso-fareast-font-family: "Times New Roman";"><o:p></o:p></span></div>
</li>
<div style="text-align: justify;">
</div>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l1 level3 lfo3; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 108.0pt;"><div style="text-align: justify;">
<span style="font-family: "Verdana","sans-serif"; font-size: 10pt; mso-fareast-font-family: "Times New Roman";">Easier to mis-read voice inflection and tone without
seeing the body language</span><span style="mso-fareast-font-family: "Times New Roman";"><o:p></o:p></span></div>
</li>
<div style="text-align: justify;">
</div>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l1 level3 lfo3; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 108.0pt;"><div style="text-align: justify;">
<span style="font-family: "Verdana","sans-serif"; font-size: 10pt; mso-fareast-font-family: "Times New Roman";">Difficult to overhear side conversations</span><span style="mso-fareast-font-family: "Times New Roman";"><o:p></o:p></span></div>
</li>
<div style="text-align: justify;">
</div>
</ul>
<div style="text-align: justify;">
</div>
</ul>
<div style="text-align: justify;">
</div>
</ul>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
<span style="font-family: "Verdana","sans-serif"; font-size: 10pt; mso-bidi-font-family: Arial; mso-bidi-font-style: italic; mso-fareast-font-family: "Times New Roman"; mso-fareast-language: EN-US;"> <o:p></o:p></span></div>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
<span style="font-family: "Verdana","sans-serif"; font-size: 10pt; mso-bidi-font-family: Arial; mso-bidi-font-style: italic; mso-fareast-font-family: "Times New Roman"; mso-fareast-language: EN-US;"> <o:p></o:p></span></div>
<div style="text-align: justify;">
</div>
Bob Boydhttp://www.blogger.com/profile/12902323994439824982noreply@blogger.com0tag:blogger.com,1999:blog-3482862331871918329.post-10415925300993423992013-04-24T08:02:00.003+10:002013-04-24T08:02:32.642+10:00Developing a Sprint Goal<div style="text-align: justify;">
<span style="font-size: small;"><span style="font-size: small;">The sprint goal is used to help focus the Scrum Team on the objectives of the sprint, the higher purpose of why the sprint is necessary. The </span></span><span style="font-size: small;"><span style="font-size: small;">Scrum Guide has this to say about creating a sprint goal:</span></span></div>
<div style="text-align: justify;">
<span style="font-size: small;"><span style="font-size: small;"></span></span><br /></div>
<div style="text-align: justify;">
<span style="font-size: small;"><span style="font-size: small;"><em>"After the Development Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum Team crafts a Sprint Goal. The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment. </em></span></span></div>
<div style="text-align: justify;">
<em></em><br /></div>
<div style="text-align: justify;">
<span style="font-size: small;"><span style="font-size: small;"><em>By the end of the Sprint Planning Meeting, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment."</em></span></span></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
My team's Sprint Goal was, at times, essentially a summation of the user stories but the better Sprint Goals in my mind were those that served as a milestone for the development team, the customers, the business, or any combination of these. For example a Sprint Goal for the first sprint of a newly formed Scrum Team might be, "Show that we can add value to the customer using scrum." To achieve this goal the team would need to complete at least one story. You'll note that this Sprint Goal has two parts: one part is about adding value for the customer and the second part is about the Scrum Team realizing their own potential to deliver value using scrum.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
In order to keep the development team motivated throughout the sprint, I would suggest helping the team find a higher purpose and develop a metaphor to describe that purpose. Look for the benefit or who benefits from the sprint and coach the team to use this information in crafting their Sprint Goal.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
During the daily scrum, I would ask the development team if any impediments might put achieving the Sprint Goal at risk. I would discontinue this once the development team themselves began alluding to the Sprint Goal in the daily scrum as they planned the day’s activities. My intent was to re-enforce the Sprint Goal as the primary focus rather than the stories, which served as a means to achieving the Sprint Goal.</div>
<div style="text-align: justify;">
<br /></div>
<h3 style="text-align: justify;">
The Sprint Goal and Shorter Sprints</h3>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
If the sprint length is short, one or two weeks, then the Sprint Goal might not have the bite or grab the imagination as firmly as when sprints are longer. It could be that by the time the Scrum Team fully embraces the Sprint Goal, the sprint is over. The probable issue here is two-fold: 1), the development team, being technical in nature, will tend to associate themselves with the work rather than the reasons for that work, and 2), the Scrum Team may not be spending a lot of time developing the Sprint Goal for shorter sprints thinking time is at a premium. </div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
As scrum master, you can encourage the Scrum Team to think about the bigger picture and understand the benefits and who benefits from the forthcoming sprint. The length of the sprint fades into the background as the team concentrates on these benefits. The amount of time taken to develop the Sprint Goal is rewarded by the development team gaining insight to the customer's, end user's, or business's needs, and satisfying these needs or moving toward the satisfaction of these needs is the real intent of the sprint.</div>
<div style="text-align: justify;">
<br /></div>
<h3 style="text-align: justify;">
Technical Sprint Goal</h3>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
When the Scrum Team first formed up, Sprint Goals tended to be a reflection of the specific stories in the sprint, that is, they tended to focus on the technical nature of the sprint rather than the beneficiaries. This is most probably due to the former way software development was run using waterfall techniques. In a waterfall environment, the development team was not always privy to the reasons behind the requirements and the product owner, often a former BA, product manager, or project manager, hasn't yet learned the benefits of having development team understand the driving force or purpose behind the requirements.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
In this scenario the product is the principal beneficiary of the effort rather than any customer, user, or business. The scrum master needs to show the product owner, and quite probably the business, that having the development team involved with the customers, end users, and the business is necessary to getting a better product, increasing the number of customers, and growing the business. The development team needs to understand the customer, end user, and business so better for them to put themselves in their position and visualize the customers', end users', and business's point of view. </div>
<div style="text-align: justify;">
<br /></div>
<h3 style="text-align: justify;">
Unfocused Sprint</h3>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Sometimes the product owner has prioritized the product backlog to do several features or functions at the same time rather than concentrating on one at a time. This probably is another throw-back to the waterfall days when all developers were kept busy on several aspects of the project at the same time. The result is that everything is "in progress" but nothing is "done".</div>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
There are a couple of reasons that this approach can be considered flawed. The first is this kind of approach can be construed as going against the agile principle, "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software." By working several features at the same time over several sprints, the team runs the risk of not delivering value at the end of each sprint. A customer may not be particularly thrilled being at sprint review after sprint review without seeing a completed feature.</div>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
The second potential flaw is the lack of flexibility to release early with only a partial set of planned functionality completed. For example, if a planned release has 5 new features, it's entirely possible for the business to release the product with only 3 of these completed if it can be determined that the product in its current state achieves "product/market fit." In other words, the cost of completing the remaining 2 features is greater than the perceived value of the product if these 2 were completed. If the product owner elects to do all 5 features in parallel, then the opportunity to release early, and begin generating revenue sooner, is lost.</div>
<div style="text-align: justify;">
</div>
<h3 style="text-align: justify;">
Not Meeting the Sprint Goal</h3>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
The Scrum Guide states that if the Sprint Goal becomes "obsolete", then the product owner may cancel the sprint. Since this implies a sudden, massive shift away from the perceived business value of the work in the sprint, this will be a very rare occurrence.</div>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
It's entirely possible for a development team to not meet the Sprint Goal but this doesn't mean the team has failed or that the sprint should be cancelled. What this most likely means is an unknown factor has made itself apparent during the sprint causing a slow-down of progress or a change in direction regarding design or technology. Not meeting the Sprint Goal is something that happens to all Scrum Teams and shouldn't be taken as a personal team failure but rather as a call to understand the root causes and correct them. Usually missing a Sprint Goal is due to an insufficient understanding of the work pulled into the sprint or, with less experienced Scrum Teams, over-committing and taking on more work than the team can handle. </div>
<div style="text-align: justify;">
</div>
<h3 style="text-align: justify;">
Summary</h3>
<div style="text-align: justify;">
<br />
Select a Sprint Goal that focuses on the beneficiaries of the sprint using the work as a guide. As a team, try to develop a metaphor to describe what the objective of the sprint is. Avoid the temptation to develop a Sprint Goal that reflects the work, i.e. product, over the beneficiaries.<br />
<br />
With shorter sprints the Sprint Goal may not have enough impact on the team. The team should spend the time necessary to develop a Sprint Goal that adds meaning to the sprint even if the sprint is one week long. All sprints, regardless of length, should add value to the customer, end user, or business and the work in the sprint is a means toward achieving this value.<br />
<br />
Try and keep a tight focus on the sprint and Sprint Goal. Working one feature at a time can get value to the customer quicker than working several features at once. It is better to have one feature "done" than to have several features "in progress" at the end of the sprint.</div>
<div style="text-align: justify;">
<br />
Do not get overly anxious if the Sprint Goal will be or is missed and don't be tempted to abort the sprint because of it. Use the sprint retrospective to analyse the root causes and make the appropriate corrections for the next sprint.</div>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
</div>
Bob Boydhttp://www.blogger.com/profile/12902323994439824982noreply@blogger.com4tag:blogger.com,1999:blog-3482862331871918329.post-44204647749818369712013-04-12T10:13:00.000+10:002013-04-12T10:13:59.197+10:00Agile Project Manger or Scrum Master?<div style="text-align: justify;">
I find that there's a tremendous amount of prejudice against certain words in the Scrum community and "manager" is near the top. A business can and will give their roles any title they feel is appropriate. I would bet the farm that in some companies, the Scrum Master role is more aligned to a Project Manager of old and that Agile Project Manager role is more aligned to the Scrum Guide’s definition of the Scrum Master. So far no help, right?</div>
<div style="text-align: justify;">
<br />Most businesses that are or will be transitioning to Scrum will have an Agile champion on board to guide the transition. I was this person at my previous company and after some time the role of Scrum Master was identified and added to HR’s list. However, before that happened, the person in the Scrum Team coaching and helping the developers and product owner was known as “Scrum Master”. This happened due to training and coaching the software and product management departments received during the transition to Scrum. The internal view was that the servant-leader of a development team was called “Scrum Master”. The external view of the role as projected by the HR department, possibly following 10 – 20 years of tradition, might have still have the role listed as “Project Manager” but now with the added term “Agile” plopped in front. This shouldn’t be too much of a surprise as the adoption of Scrum starts within the software department and will only spread once the successes due to the application of Scrum are recognised. As the Agile champion, my focus was on the software department and not HR, (in the beginning). After a couple months and Scrum had an obvious foothold in the company, efforts to re-align HR roles and role descriptions (Scrum Master, Development Team Member, Product Owner) began. </div>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
As a practicing Scrum Master and I saw a job ad that said, “Agile Project Manager”, I would apply with the knowledge that the role is most likely that of a Scrum Master for a company in transition (or possibly stuck in transition). I might find out otherwise at the interview but that’s the point of the interview: the prospective employer and prospective employee determine if there exists a common understanding of expectations and responsibilities surrounding the role. Some may see this as waste but as the interviewee, I see interviews as a learning experience even when the ultimate outcome is no job.</div>
<div style="text-align: justify;">
<br />One of the responsibilities of the Scrum Master in the Scrum Guide is, “Leading and coaching the organization in its Scrum adoption”. This is where it can be argued that the Scrum Master is charged with aligning the roles and role descriptions in HR with the roles and descriptions found in the Scrum Guide. If the Scrum Master(s) are unsuccessful in doing this today, then it means they try again tomorrow, and the next, and so on. As long as the internal application of Scrum roles is correctly aligned with the Scrum Guide, then this view external of the Scrum Team might be an annoyance but not necessarily a terminal problem.</div>
<div style="text-align: justify;">
</div>
<h3 style="text-align: justify;">
Summary</h3>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
In the final analysis the Agile coach and Scrum Masters need to pick their battles with an eye on impact and results. Getting management and the Scrum Team following the Scrum framework is to me, job one. Pulling the rest of the corporate structure in line with Scrum role descriptions i.e., HR and management, is of secondary concern in my view.</div>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
</div>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-3482862331871918329.post-41447177023991194172013-04-05T10:40:00.000+11:002013-04-05T10:40:19.644+11:00How To Recognize A Self-Organizing Team During Sprint Planning<div style="text-align: justify;">
As a Scrum Master, one of the ways you serve the development team is by coaching them in self-organization. Several [hundred] definitions of self-organizing exist on the web but I'll use the Scrum Guide and add a point or two.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<em>"Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. ... No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality."</em> - <span style="font-size: x-small;">Schwaber, Ken and Sutherland, Jeff. "The Scrum Guide", October 2011.</span></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
The Scrum Guide definition focuses on the development team understanding and undertaking the work they do during a sprint. The Scrum Guide specifically wants the development team to control how they do the work of the sprint. I would add to that definition two points: the development team acts as their own technical (not line) manager and the development team displays strong professional bearing, unity, and are respectful of others. This manifests itself with the development team understanding and anticipating the technical actions required to implement scrum in the most efficient and expedient manner and the development team working very closely with the product owner (PO) throughout the project.</div>
<div style="text-align: justify;">
</div>
<h3 style="text-align: justify;">
Self-Organizing During the Sprint Planning Meeting</h3>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
The Scrum Guide suggests time-boxing the sprint planning meeting at 2-hours for each week of the pending sprint but as the development team becomes more self-organizing, the amount of time necessary for planning should greatly decrease. The two main reasons sprint planning can become shorter are:</div>
<ol><div style="text-align: justify;">
</div>
<li><div style="text-align: justify;">
The development team has a very good understanding of PBI's coming into the planning meeting primarily due to helping the PO develop the PBI's and conducting product backlog grooming sessions.</div>
<div style="text-align: justify;">
</div>
</li>
<div style="text-align: justify;">
</div>
<li><div style="text-align: justify;">
The development team and PO work very closely together, discussing customer wants and desires, customer requirements, and customer expectations throughout the project.</div>
<div style="text-align: justify;">
</div>
</li>
<div style="text-align: justify;">
</div>
</ol>
<h3 style="text-align: justify;">
Sprint Planning Meeting Part I</h3>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
The first half of the sprint planning meeting has the PO presenting the ordered product backlog to the development team and the development team forecasting what they can do in the upcoming sprint. In an ideal first half, the self-organizing development team "pulls" off the top x items from the backlog the PO presented and adds these to the upcoming sprint. The development team and PO have already discussed the PBI's during previous grooming sessions but the PO may have made some changes since. The development team and PO review the selected items and any changes made by the PO since the last grooming session. The development team and PO then conjure up a sprint goal and the first half of the sprint planning meeting is done, probably in less than 20-minutes. </div>
<div style="text-align: justify;">
</div>
<h3 style="text-align: justify;">
Sprint Planning Meeting Part II</h3>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
The second half of the sprint planning meeting has the development team figuring out how to deliver the PBI's for the sprint. The self-organizing development team will identify enough tasks for the first few days of the sprint. The development team may re-negotiate with the PO if they determine that they cannot do all the PBI's in their present form (i.e. a need to reduce scope) or the development team may find they can do more PBI's and "pull" in these from the product backlog. The second half of the sprint planning meeting now concludes and the sprint starts.</div>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
The elapse time for the sprint planning meeting should be less than an hour, under 30-minutes for a two week sprint, when the development team takes on the responsibility to groom the product backlog and understand PBI's to the extent that these PBI's are "sprint ready" i.e., ready to be worked with only minimum review and recap.</div>
<div style="text-align: justify;">
</div>
<h3 style="text-align: justify;">
A Clue That The Development Team Isn't Fully Self-Organizing</h3>
<div style="text-align: justify;">
<em></em> </div>
<div style="text-align: justify;">
<em>During the sprint planning meeting, the product owner pushes the requirements onto a "dazed" development team.</em></div>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
Picture a sprint planning meeting with a team only recently introduced to agile and scrum. In the first half of this meeting, the PO is presenting product backlog items to the development team. A development team member asks why a story [feature, requirement] is in the upcoming sprint. The PO and development team spend considerable time discussing the necessity and merit of each PBI for the upcoming sprint. In this scenario, there's no indication the development team understands the product backlog items and are merely reacting to what the PO has presented.</div>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
There are a few reasons this kind of behavior might be present:</div>
<div style="text-align: justify;">
</div>
<ol>
<li><div style="text-align: justify;">
The development team is in command & control mode and doesn't feel it's their place to "pull" work,</div>
</li>
<li><div style="text-align: justify;">
the product owner is in command & control mode and feels the need to "manage" the development team, </div>
</li>
<li><div style="text-align: justify;">
the development team is not grooming the product backlog with the product owner, or</div>
</li>
<li><div style="text-align: justify;">
the development team doesn't understand the product backlog is ordered.</div>
</li>
</ol>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
It can be the hard for a development team used to command & control to become self-organizing, especially if the team is transitioning from waterfall. Similarly, if the PO is formally a product manager or project manager, they may have difficulties letting go of the command & control aspects of their former roles. Either of these two is likely to occur and have much the same solution, the scrum master needs to train these people on the philosophy of agile, specifically agile principles:</div>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
</div>
<ul>
<li><div style="text-align: justify;">
<em>Business people and developers must work together daily throughout the project.</em></div>
</li>
<li><div style="text-align: justify;">
<em>The best architectures, requirements, and designs emerge from self-organizing Teams.</em></div>
</li>
<li><div style="text-align: justify;">
<em>Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.</em></div>
</li>
</ul>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
These agile principles coupled with the rules and practices of scrum outlined in the Scrum Guide, can start the journey towards a self-organizing team. </div>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
The third reason the development team is not involved may be the team isn't working with the product owner to groom the product backlog. Product backlog grooming helps to develop an understanding of the requirements both technically and from a business value (customer) point of view. The scrum master should ensure the development team and PO do grooming and may need to facilitate the initial grooming sessions to make sure this happens. The scrum master can encourage the PO and development team to work together developing PBI's for the customer requirements, develop the acceptance criteria for the customer requirements, and to discuss any risks or issues associated with the customer requirements.</div>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
The forth reason a development team isn't "pulling" in work from the product backlog could be they don't quite understand how the product backlog is structured. The Scrum Guide states that the product backlog has the attributes description, order, and estimate and "is often ordered by value, risk, priority, and necessity." Although the PO can decide how to order the product backlog, the product backlog is not the private domain of the PO. There should be no secrets or surprises in the product backlog. The scrum master can help maintain the transparency of the product backlog by facilitating product backlog grooming sessions and by encouraging the PO and development team to break down and write the more detailed customer requirements together.</div>
<div style="text-align: justify;">
</div>
<h3 style="text-align: justify;">
Summary</h3>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
One of the ways the scrum master serves the development team is to coach them in self-organizing behavior. The development team will become more self-organizing as time passes and one way to see this progress is by observing the way the sprint planning meeting runs. As the development team becomes more self-organizing, one effect should be the swiftness of the sprint planning meeting. This will be primarily due to the PO and development team working in close harmony together as customer requirements are developed, broken down with details added, and the PO and development team sharing a common understanding of the value of each "sprint ready" requirement.</div>
<div style="text-align: justify;">
</div>
Bob Boydhttp://www.blogger.com/profile/12902323994439824982noreply@blogger.com0tag:blogger.com,1999:blog-3482862331871918329.post-83025718260827203662013-03-04T11:18:00.003+11:002013-03-04T11:18:26.307+11:00Measuring the Success Of The Scrum Master<div style="text-align: justify;">
The Scrum Guide states, "[T]he Scrum Master is responsible for ensuring Scrum is understood and enacted." Scrum is defined in the Scrum Guide as follows: "Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value." So, one could logically conclude that the scrum master role is responsible for ensuring the scrum team is "productively and creatively delivering products of the highest possible value." I think that the CEO, CTO, Development Department Manager will particularly note the "highest possible value" aspect of the scrum master role and want to know if the scrum master is coaching the team toward this goal. Here are a few points to track the success of the scrum master:</div>
<ul>
<li><div style="text-align: justify;">
Is the scrum team (development, product owner, and scrum master) following the 12 principles of agile as defined in the agile manifesto?</div>
</li>
<li><div style="text-align: justify;">
Is the scrum master ensuring the scrum team (development, product owner, and scrum master) is following the rules of scrum as defined in the scrum guide?</div>
</li>
<li><div style="text-align: justify;">
Is the scrum master helping those outside the scrum team understand agile and scrum?</div>
</li>
<li><div style="text-align: justify;">
Is the scrum master protecting the development team from interruptions?</div>
</li>
<li><div style="text-align: justify;">
Is the scrum master removing obstacles and problems affecting the scrum team e.g. getting better computers, coffee, baby sitters, listening to problems ...?</div>
</li>
<li><div style="text-align: justify;">
Is the development team moving toward being self-organizing?</div>
</li>
<li><div style="text-align: justify;">
Is the development team moving toward being cross-functional?</div>
</li>
<li><div style="text-align: justify;">
Is the development team enjoying work or do they dread coming to work?</div>
</li>
</ul>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
I think most measures for scrum master are subjective but that really means you must exercise greater caution when applying your scientific methods. For example, if the product owner randomly asked ten customers if they liked the user interface to a product and one voiced the opinion that it's bad, then you probably wouldn't change the interface. If however, nine of the ten voiced the opinion that the user interface is bad then this means something even though it's still all very subjective. What the product owner is doing is taking purely subjective measures and objectively applying them to the science of statistics. Could all nine customers be an anomaly with your other 991 customers happy with the user interface? Of course the answer is yes but it's also very unlikely.</div>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
Measuring the scrum master's performance against the expectations found in the Scrum Guide can follow the same principles as above. For example, measuring the scrum master’s service to the development team in "coaching the Development Team in self-organization", one could use several subjective measures together, with any weighting you choose, and reasonably determine over time if the development team is becoming more, less, or remaining static in self-organizing, assuming the method of measuring and weighting remains constant. These measures might include:</div>
<div style="text-align: justify;">
</div>
<ul>
<li><div style="text-align: justify;">
How does the scrum team rate itself in forming-storming-norming-performing?</div>
</li>
<li><div style="text-align: justify;">
Does the development team pull items from the product backlog rather than having them pushed onto them?</div>
</li>
<li><div style="text-align: justify;">
At the daily scrum, is the development team providing status to the chickens or are they planning the day's work?</div>
</li>
<li><div style="text-align: justify;">
At the daily scrum, does one development team member repeatedly advise others of what work they should be doing?</div>
</li>
<li><div style="text-align: justify;">
At the retrospectives, does the scrum team actively pursue areas for improvement and then execute on these improvements?</div>
</li>
<li><div style="text-align: justify;">
Does the development team often seek outside assist on how to implement a user story?</div>
</li>
</ul>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
Enough subjective measures can be found to objectively determine if the development team is self-organizing.</div>
<div style="text-align: justify;">
</div>
<h2 style="text-align: justify;">
What Is Success?</h2>
<div style="text-align: justify;">
You may often times hear that working software is the measure of a scrum team's success and this is then used to determine the general success of every person in the scrum team, including the scrum master. I would argue that this is not enough since working software doesn't necessarily mean it's valuable. Think about delivering working software after the company had already lost a competitive advantage or delivering working software that no one wanted or bought. It's also conceivable that some customers, early adopters spring to mind, would tolerate software that doesn't completely work in order to see the concepts and the potential of the product. The Scrum Guide specifically allocates responsibilities to the product owner and scrum master with regards to adding value; not so for the development team. I think that "value" in the context of the Scrum Guide is value for the customer and, consequently, for the business. The rules and practices in the Scrum Guide are there to support the 12 agile principles including the very first, "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software." It's the scrum master's role to ensure that the scrum team "satisf[ies] the customer" through the “continuous delivery of valuable software". The scrum master does this by making sure the scrum team "adheres to Scrum theory, practices, and rules". It's the responsibilities of the scrum master, as defined in the Scrum Guide, that business can use to measure the success and effectiveness of the person given the role of scrum master.</div>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
</div>
Bob Boydhttp://www.blogger.com/profile/12902323994439824982noreply@blogger.com2tag:blogger.com,1999:blog-3482862331871918329.post-81609730364300746342013-02-25T08:33:00.000+11:002013-02-25T08:34:23.181+11:00Documenting Your Best Practices<div style="text-align: justify;">
I think it's important for the software organization to have documented Best Practices to provide a common starting point for all engineers, whether new or well-seasoned. The term Best Practice simply means this is the most efficient or simplest or greatest customer/business value, (I would stress the latter) way of doing something known to date. What Best Practice doesn't mean is that it's a rule. Rules change infrequently but Best Practices are always open to change.<br />
<br />
The business may have a rule that an agile team must have a daily stand-up meeting visible and accessible to anyone who wishes to attend given the space available. How an agile team implements the daily stand-up meeting is subject to one or more Best Practice. There may be a Best Practice that has the Scrum Master facilitating this meeting, asking three questions: what have you done, what will you do and what problems are you having. There can be another Best Practice that has a different development team member facilitating the daily stand-up each day in a round robin fashion. Both these Best Practices can exist at the same time, in the same document, until one is proven better or, if they are equally beneficial, one is proven more popular.<br />
<br />
I think that Best Practices are potentially updated after each agile teams' retrospective. One major pitfall of documenting Best Practices is these are never reviewed and updated. The business must guard against Best Practices becoming static and agile teams or the development manager need to ensure there's an ongoing effort to review and validate all Best Practices. If the Best Practices document hasn't changed in 30 days then maybe the agile teams are not trying to improve since most Best Practices are used in each sprint and subjected to retrospective review at the end of each sprint. If for example, all agile teams adopted the practice of having the Scrum Master facilitate the daily stand-up, having tried and rejected having a development team member facilitate, I would probably remove the Best Practice of having a different development team member facilitating the daily stand-up.<br />
<br />
One last point, I don’t think there’s generally a great amount of detail in Best Practices as these are not always step-by-step procedures, at least not in an agile environment. If there’s a Best Practice to use planning poker in a sprint planning meeting (or grooming session) then there’s probably a brief description of what planning poker is and maybe a link to Wikipedia. Planning poker is a good example since there are at least a dozen different implementations that are almost but not quite the same. However, a code review Best Practice may be very detailed because there’s proven value in your company by following these detailed steps.</div>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
Best Practices document the way you do things now so you have something to use to measure improvement against. Best Practices become the organizations best training aid for new-hires and is the guide for all. Best Practices change all the time as agile teams experiment and replace outdated practices with new and better practices. Taiichi Ohno of Toyota Lean Manufacturing fame is quoted as saying, <em>"There is something called standard work, but standards should be changed constantly. Instead, if you think of the standard as the best you can do, it's all over. The standard work is only a baseline for doing further kaizen. It is kai-aku [change for the worse] if things get worse than now, and it is kaizen [change for the better] if things get better than now. Standards are set arbitrarily by humans, so how can they not change?"</em> All you need do is replace "standard" with "Best Practice".</div>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
</div>
Bob Boydhttp://www.blogger.com/profile/12902323994439824982noreply@blogger.com0tag:blogger.com,1999:blog-3482862331871918329.post-31462297296637985292013-01-22T18:08:00.000+11:002014-12-12T15:31:37.461+11:00Retrospectives With Scientific ValidationDuring retrospectives, agile teams would benefit from following the Lean Startup concept of testing their improvement hypotheses using scientific methods. My experience during agile retrospectives has been that for most 'improvements', there's no deliberate validation that the change actually makes the hoped for improvement. The trick is to select quantifiable measures that can be directly linked to the 'improvement' i.e., cause and effect are firmly linked. In essence, the Scrum team conducts a scientific experiment to determine if for some action/activity/change they get a measurable improvement.<br />
<br />
It's important that the team only do one improvement at a time so that any effects can be attributed to the improvement. For example, if you're introducing pair-programming to reduce acceptance tests failures but you've also introduced a new test harness to help increase test coverage, you might find it difficult or impossible to determine which of these two affected acceptance test results and by how much.<br />
<br />
The retrospective process steps:<br />
<br />
<ol>
<li><b>Problem Statement:</b> Clearly state the exact problem the improvement will solve</li>
<li><b>Desired Outcome:</b> Clearly state what the results will be with the improvement in place</li>
<li><b>Experiment Summary:</b> Develop the falsifiable<b>*</b> hypothesis for the improvement</li>
<li><b>Measures:</b> Identify the metrics and measures to collect</li>
<li><b>Data Collection:</b> Identify how the metric data are collected. Identify how the collected data is presented</li>
<li><b>Results Validation:</b> Identify how the team will know the hypothesis is proven true beyond a reasonable doubt. Identify how the team will know the hypothesis is proven false beyond a reasonable doubt</li>
</ol>
<br />
The information gathered above is the output of the retrospective. The team should place the falsifiable hypothesis for improvement [retrospective experiment] in a prominent location so everyone in the organization can understand the problem the team hopes to solve, what the experiment is to solve it, and the hoped for results of the improvement.<br />
<br />
<b>*</b>A falsifiable hypothesis is a statement that can be proven wrong through observation or experiment. The structure of a falsifiable hypothesis is, "The team will [make this improvement] by [doing/not doing this action or activity]."Bob Boydhttp://www.blogger.com/profile/12902323994439824982noreply@blogger.com0tag:blogger.com,1999:blog-3482862331871918329.post-34012540386300538782012-05-02T11:08:00.000+10:002012-05-02T11:08:44.670+10:00Development's First Sprint: Things To Improve<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
There are many concepts of Agile and Scrum that new Development Teams may have trouble with in their first couple of sprints; daily builds not working, acceptance tests not automated, regression tests not automated, and on and on. These problems will pop up and the team will need to deal with them as well as anything else that comes between the team and a quality product they can be proud of. I've listed below some problems that by themselves aren't that big but I think have a long term impact on how well a Development Team becomes self-organized and cross-functional. I believe these are transitional problems that once solved, can help turn a group of individuals into a strong Scrum Development Team. </div>
<div style="text-align: justify;">
<br /></div>
<h3 style="text-align: justify;">
Development Team isn't collaborating on designs and task identification.</h3>
<div style="text-align: justify;">
<br />
The last thing a Scrum Master wants to hear at a retrospective is that team members couldn't help one another during the sprint because, "I didn't know anything about ___ ". This, or something like it, will happen in the Development Team's early sprints. The biggest reason for this is not everyone in the Development Team understands the high-level design or knows exactly what the tasks are about. This is usually the result of the walls people have built around technology areas or themselves. This behavior is often seen in a waterfall environment where the individual hero is praised and usually given the greatest rewards. However, the reason you and the company are most likely moving to Agile is to increase productivity, have more frequent releases, have happier customers, and increase profitability. The concept of individual heroes now becomes a drag on these plans; no one can pick up the work of a hero if that person is sick, on vacation, or wins the lottery and leaves. Heroes also tend not to ask for help if they find themselves in some kind of trouble; that wall they built not only isolates the technology but it also hides mistakes and indecision. Agile and Scrum welcomes these heroes into a Development Team but asks that they do two things: teach their specialty area to other team members and to learn the specialty areas of other team members. Having a Development Team that can do most any job, even if it takes 3 times longer to do it, will have profound benefits for the Scrum Team, the customers, and the company. A Development Team where everyone can collaborate on the design will result in the best designs. A Development Team that collaborates to find the simplest tasks to accomplish work will maximize the amount of work not done.<br />
<br />
The Development Team's collaboration begins with the second part of the sprint planning meeting. This part of the meeting is for the Development Team to start "designing the system and the work needed to convert the Product Backlog into a working product increment." This is meant to be a collaborative effort by the Development Team to identify the work necessary for the first couple of days of the sprint. The Scrum Master should not only ensure this collaboration happens during the sprint planning meeting but should also ensure that the team does this throughout the sprint to identify the designs and tasks needed to complete each story.<br />
<br />
</div>
<h3 style="text-align: justify;">
Development Team feels estimating is a life and death struggle.</h3>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
I was once at a sprint planning meeting where one person could not live with an estimation of 8 hours and insisted the 'correct' estimate was 12 hours. This person could not compromise on 9, 10, or even 11 hours: the correct estimate was 12 hours. I'm sure that in every company, every person estimating has experienced this in one form or another. There are going to be people in the Development Team who are afraid of being wrong or insist they're right. There may even be rumours that someone was let go because of poor estimations. Where I worked, this was a commonly stated 'fact' but even the smallest amount of research showed that this never happened; no developer was ever fired simply because they made an estimate that proved wrong. The Scrum Master can limit this by having the Development Team use story points and Planning Poker. Story point are just abstract enough to help the team reach consensus without getting too bogged down in precision. Another technique that can help is the Fist-of-Five for reaching a consensus. Use a 2 or 3 minute egg timer to hold debates over different estimations to a reasonable time limit will also hasten consensus. </div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
The Scrum Master can show that there are no adverse repercussions with estimations by noting the estimates of tasks and stories and comparing the estimates with the actuals (don't attribute names to these). During the sprint retrospective ask the team to explain why some estimates differed from the actuals and let them suggest improvements to estimation techniques. The team will come to recognize that they provided the best estimates they could based on the knowledge they had at the time. However, the Scrum Master must be prepared to answer the inevitable suggestion that the Development Team do prototyping and design before doing story estimates and task breakdowns. The answer to this lies with the estimates Vs actuals. I had found Development Teams estimates are generally around 10% - 20%; a very good showing (the Nokia test has the goal of +/- 10%). It's likely that the Development Team does pretty well on their estimates but may have the occasional anomaly where they're off. Every time team estimates are off by > 50%, they should analyse the possible reasons during the retrospective. All of this analysis is done within the Development Team and isn't something that is made public although lessons learned are often shared with the organization. Outside the Scrum Team there really isn't any indication of estimation accuracy except maybe the team's velocity. However, velocity is an average over several sprints and won't be meaningful for new Development Teams until the 4th, 5th, or even 6th sprint. By this time, the Development Team should be less anxious over their individual estimates.</div>
<div style="text-align: justify;">
<br /></div>
<h3 style="text-align: justify;">
Tasks should be pooled and not assigned to individuals.</h3>
<div style="text-align: justify;">
<br />
Development Team members may assign or take sprint tasks during planning and not concern themselves with other tasks not assign to them. Prior to adopting Agile, this is the generally accepted behavior but it will get in the way of a Scrum Development Team's being self-organized and cross-functional. The Development Team must exercise collective ownership of all work necessary to complete a story, after all, the team is held accountable to doing the work, not one individual. One thing the Scrum Master can do to help re-enforce accountability and provide cross-functional training is to have the Development Team members take the task from the person on their right and do that task instead of the one they announced during the meeting. This won't be popular with the Scrum Team and it probably won't be too popular with managers attending the daily scrum so don't do this too often; once or twice in each of the early sprints. This will drive home the lesson that there will be times when team members are sick, on vacation, or leave the company and the other members of the team need to step up and do work in areas they're uncomfortable with. In my experience, the discomfort is fear of the unknown rather than being technically incapable of doing the work. </div>
<div style="text-align: justify;">
<br />
The Scrum Master can also suggest that the Scrum Team do 1 week sprints. This forces the team to concentrate on just a few user stories, generally working on 1 story until it's completed before going on to the next. The Development Team members will often say that there isn't enough work on 1 story to keep everyone busy. My suggestion is for the team to sit down together and lay out all the tasks of a story showing what bits can be done in parallel and which ones have dependencies. This will generally result in a tasks for a story that are smaller and more detailed than the team would have previously done. Following a 'test first' philosophy, for both acceptance tests and unit/integration tests, will allow more people to work a single story and can even get the story completed faster.<br />
<br />
</div>
<h3 style="text-align: justify;">
Development Team is found skipping peer reviews and testing of software prior to delivery to repository.</h3>
<div style="text-align: justify;">
<br />
This is one of those issues that occurs most often when the team feels pressure (real or perceived) to deliver something, anything by a specified time or date. If the Product Owner or management is exerting undo pressure on the Development Team, creating anxiety, the Scrum Master needs to re-educate them on the rules of Scrum, specifically, "Development Teams are structured and empowered by the organization to organize and manage their own work." It may be very hard or impossible for the Scrum Master to protect the team against excessive management pressure but the Scrum Master must try and convince management that the Development Team deserves the chance to be successful. Finally, if the Scrum Master is exerting pressure then you probably need to find a new Scrum Master, one better informed on Scrum. <br />
<br />
I've also seen this problem because the developers are skipping reviews and tests on their own initiative. During a retrospective after a particularly embarrassing delivery to the customer, the Development Team asked that the Scrum Master double check the team's quality controls by asking for each completed task identified in the daily scrum: 1) was the new/modified code peer reviewed, 2) has all new/modified code been unit tested, 3) has the new/modified functionality been system tested, 4) have acceptance tests been run or partially run, and 5) has the product been regression tested in the affected areas. The scope and depth of testing is left to the Development Team's collective common sense. This actually worked well and after a couple of sprints the questions were no longer asked. What was interesting was how the developers reacted to these questions in the daily scrum. At first, some team members were sheepish and I got the impression that sometimes the answers weren't completely true but no one else on the team said anything. After a few more daily scrums with these questions, the other team members would occasionally question a team member's answer. Eventually the team members would question what was done before the Scrum Master could ask a question. <br />
<br />
<br />
<br />
<br /></div>Bob Boydhttp://www.blogger.com/profile/12902323994439824982noreply@blogger.com0tag:blogger.com,1999:blog-3482862331871918329.post-30194445645439482212012-04-26T09:34:00.001+10:002012-04-26T09:38:39.109+10:00Before the First Scrum: Development Team<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
The members of the new Scrum Development Team are usually drawn from the company's existing software development organization and have probably been following a waterfall methodology until now. If your company's planning on using a Scrum Coach, then most of what follows may not be applicable as the coach with have their own methods and techniques. However, for those organizations that will have their Scrum Teams self-start from within, here are some points on how to select the Development Team and prepare them for their first sprint.<br />
<br /></div>
<div style="text-align: justify;">
<span style="font-size: large;"><strong>Selecting the Development Team</strong></span></div>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
<br />
The Scrum Guide lists the Development Team's characteristics as: self-organizing, cross-functional, having no titles other than Development Team member, equally shared accountability for the sprint, and no sub-teams within the Development Team e.g. database, test, GUI, etc. Although it's possible that your first Development Team will have these characteristics, it's very unlikely. These characteristics are what the Development Team hopes to achieve and it's the Scrum Master that will help guide the team as quickly and with as few detours as possible over the first half dozen sprints or so.<br />
<br />
So what is it you're looking for when forming a Scrum Development Team for the first time? There's really only one thing that needs to be considered: the Development Team will need to have the technical expertise to do the work that the project's requirements demand. The company I worked at did exactly this when forming their very first Scrum Development Team and it proved to be a success. A step by step approach to select and prepare a Development Team for Scrum might look like this:</div>
<ol><div style="text-align: justify;">
</div>
<li><div style="text-align: justify;">
Review the project's requirements to determine the necessary functionality and necessary technical competencies needed for implementation. The review is probably done by Product Managers, Project Managers, senior architects, and team leads. The irony is that with the exception of Product Manager, these roles will almost certainly disappear as the software organization moves toward Scrum. The Scrum Team as a unit will replace the team leads, architects and project managers as they become more self-organizing. </div>
<div style="text-align: justify;">
</div>
</li>
<div style="text-align: justify;">
</div>
</ol>
<div style="margin-left: 5em; text-align: justify;">
<em>My first experience with Scrum started this way. The company was doing waterfall when a new business opportunity came along. Once management, particularly Product Management and R&D Manager understood the requirements, it didn't take long to see that waterfall methods wouldn't be able to meet the contract dates. They concluded that a different development methodology was needed that could quickly implement a few hundred requirements but be transparent enough so unnecessary and problematic requirements could be dropped long before developers wasted a lot of time on them. Agile and Scrum provide the transparency and seemed a logical fit in order to meet the contract.</em></div>
<ol start="2"><div style="text-align: justify;">
</div>
<li><div style="text-align: justify;">
Based on these needs, create a list of 5 - 7 software personnel that will satisfy most or all of the technical competencies needed. Everyone in a development organization should be considered for membership in a Scrum Development Team. The only exception might be someone known to be totally unable to work in a team environment. Even then I would suggest placing these people in a Scrum Team as you might be surprised who fits in and who doesn't. Management should allow everyone a chance to succeed in Agile. Try to avoid putting only the very best software people into a single Scrum Team. It isn't necessary since the total of knowledge in a Scrum Development Team is usually greater than the knowledge of any one individual. And besides, if your company decides it will have 2, 4, or more Scrum Teams, the more experienced people can be seeded to every team rather than all in one team.</div>
<div style="text-align: justify;">
</div>
</li>
<div style="text-align: justify;">
</div>
</ol>
<div style="margin-left: 5em; text-align: justify;">
<em>My first Scrum Team consisted of the most experienced people (team leads) in the software organization and were selected based on the technical requirements of the project. The project had 4-2 week sprints and was a great success. After the two month project ended, the Scrum Team split up. Although they did the principle Scrum activities; sprint planning, sprint, daily scrum, sprint review, and sprint retrospective, they didn't really do Scrum all that well. In my view, having only the most experienced or senior engineers in one team, the ones who have been doing waterfall the longest, will slow progress toward self-organizing and being cross-functional. These senior people will have to change the most to adopt Agile and Scrum. </em><em>For example, during a daily scrum meeting it became apparent that one team member wasn't doing any of the tasks on the scrum board in his specialist area. No other Development Team member questioned this. When I asked what task he was doing h</em><em>e said it would take longer to explain what he was doing than to do it. He didn't ask his fellow team members for assistance but neither did any other team members offer to assist. The Scrum Team's team lead called in an architect to help on the problem and after working the weekend, the problem was resolved. In the post project review it turned out that because most everyone on the team was a fairly senior engineer and team leader, they felt that the Scrum Team's team lead would sort it out as they would do if they were the team lead. In the pre-Agile environment, the team lead had the responsibility for solving technical problems for the team and was generally held accountable for the team's success. In Scrum, the accountability for the success of a sprint rests equally among all the team members. This is a significant power shift for former team leads.</em><br />
<br /></div>
<div style="margin-left: 5em; text-align: justify;">
<em>On the other hand, getting the more senior software people on board with Scrum through a short-ish project can have long term benefits. Once this team breaks up, they can go to other new teams and be champions of Scrum within their new teams.</em></div>
<ol start="3"><div style="text-align: justify;">
</div>
<li><div style="text-align: justify;">
The Scrum Master introduces Agile and Scrum to the newly formed Development Team. The focus should be the Agile Manifesto and the 12 principles. The Scrum Master should describe the Scrum Roles, the expectations of the Development Team as they relate to Scrum, and emphasize the Development Team's empowerment to find and implement an appropriate solution. I would suggest this be a short introduction; no longer than 60 minutes. Review the Agile Manifesto and Scrum Guide and then tell the Development Team that they're empowered to run the sprint as best they see. Start sprint planning that day or the next. </div>
<div style="text-align: justify;">
</div>
</li>
<div style="text-align: justify;">
</div>
</ol>
<div style="text-align: justify;">
</div>
<div style="margin-left: 5em; text-align: justify;">
<em>A short meeting (< 60 minutes) just to present the facts of Agile and Scrum will help the Development Team 'hit the deck running.' If you have a long, drawn out session, the conversation will eventually lead to discussing waterfall which will invite comparisons between "the way we used to do it" and Scrum. This will lead the team members making choices between the two i.e. which is better. The purpose of this meeting is to familiarize the Development Team on Agile and Scrum and not to debate whether the company should be changing to Agile (I assume those discussions and decisions had already taken place). I suggest going through the Agile Manifesto first and then the Scrum Guide. When doing the Scrum Guide, relate the points in the Scrum Guide back to the Manifesto to help re-enforce the principles of Agile. An agenda might look like this:</em><br />
<br />
<ol>
<li><em>Agile Manifesto</em></li>
<li><em>Scrum Roles</em></li>
<li><em>Scrum Principle Activities</em></li>
<li><em>Scrum Rules</em></li>
<li><em>New Techniques And Concepts [user stories, planning poker, acceptance tests, continuous integration, daily builds, ...]</em></li>
</ol>
</div>
<ol start="4"><div style="text-align: justify;">
</div>
<li><div style="text-align: justify;">
Co-locate the Development Team removing any partitions, bookcases, or other office furniture that prevents the newly formed team from being able to make eye contact and hear each other talk. Get some whiteboards or have a wall located with the team where they can track their sprints (Scrum Board), add notes, do designs, document user stories and acceptance criteria, and plan the release. All this will help facilitate communication within the team. The Scrum Master and Product Owner should sit next to the Development Team's area where they can hear snatches of conversation and be summoned quickly but they shouldn't sit with the Development Team. Co-locating the Development Team, will help empower them to self-organize, makes it easier for the team to learn from each other (cross-functional), and fosters direct, face-to-face communications.</div>
<div style="text-align: justify;">
</div>
</li>
<div style="text-align: justify;">
</div>
</ol>
<div style="text-align: justify;">
</div>
<div style="margin-left: 5em; text-align: justify;">
<em>A few people, usually the shy or paranoid, will absolutely loath moving but the majority will be able to see the benefits. After a few sprints, the shy people will be noticeably more open and communicative and the paranoid people will be less fearful of their work being scrutinized. Be sure to have plenty of white board space for the team.</em></div>
<div style="text-align: justify;">
<ol start="5">
<li>Establish a Definition of Done for the Scrum Team (see the short paper <a href="http://implementingagile.blogspot.com.au/2011/09/definition-of-done-how-to-ensure.html" target="_blank">Definition of Done: How to Ensure Compliance</a>). The Scrum Master might want to assess the Development Team's capabilities for their first couple of sprints and allow the team to adopt a Definition of Done that offers the team a chance to succeed and yet has room for growth. As the Scrum Team re-assesses their Definition of Done at each sprint retrospective, any weaknesses in the Definition of Done can be addressed and the Definition of Done modified to strengthen and improve the team's sprint results.</li>
</ol>
</div>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
</div>
<div style="margin-left: 5em; text-align: justify;">
<em>I found that the Scrum Teams had a terrible time adhering to their Definition of Done, especially in their first few sprints. I think the reason for compromising the Definition of Done is due to the long tradition of shipping products even when they weren't ready. The line goes something like; the customer would rather have something that almost works than to have nothing. In pre-Agile you deliver something that doesn't always work whereas in post-Agile you deliver something that works but may not have all the features. This is a subtle difference but I think it's the key to Agile. The customer is meant to see new and working features and capabilities at each sprint review.</em></div>
<ol start="6"><div style="text-align: justify;">
</div>
<li><div style="text-align: justify;">
The team needs to develop the capability to generate daily builds before starting the first sprint. This phase is often called sprint zero. To take full advantage of Agile, the team needs the ability to generate workable builds on a daily basis. This is part of continuous integration. Continuous integration is the practice of performing a clean build, conducting full integration, and running all tests every time a change is committed to the code repository. This is accompanied by frequent integration of each developer’s work into the code repository.</div>
<div style="text-align: justify;">
</div>
</li>
<div style="text-align: justify;">
</div>
</ol>
<div style="margin-left: 5em; text-align: justify;">
<em>Working builds were a luxury during my first sprint but steadily improved during the subsequent sprints. This was a most import lesson learnt in our first venture into Scrum. At a minimum, the team needs to successfully run automated unit/integration tests on a daily basis to help ensure the quality of new code and ensure there's no regression on legacy code. The team needs to have a build notification message, usually emailed, that lets people to know what the build status is and exactly which feature was being delivered or what in a feature was being fixed. The team should be striving to have acceptance tests automated and run on a daily basis. The team needs to get to the point where it is unacceptable for a build to be broken. If the build breaks or the product regresses, the offending code is removed from the build and the daily build is then released. The team must fix the bad code before any new functionality is added to the code base. </em><br />
<br />
<em>The Development Team should also automate their legacy acceptance tests and other system tests and have these run on the daily build. Legacy tests will most likely not be automatic but the team can add user stories to the product backlog to create automatic tests. </em></div>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
<br />
The Scrum Guide places the responsibility for educating and training the Development Team, along with the Product Owner, on the Scrum Master. Getting the Development Team together and ready for their first sprint is the easy part; the Scrum Master must now teach the concepts and intent of Scrum and Agile to the Development Team until they can do Scrum in their sleep. Hopefully, the day will come when the Scrum Master recognises that the Development Team really doesn't need a Scrum Master anymore.</div>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
<br /></div>Bob Boydhttp://www.blogger.com/profile/12902323994439824982noreply@blogger.com1tag:blogger.com,1999:blog-3482862331871918329.post-43286560942494319242012-04-07T17:10:00.000+10:002012-04-07T17:10:34.747+10:00Before The First Scrum: The Scrum Master<div style="text-align: justify;">The role of the Scrum Master is arguably the most important role on the Scrum Team. The 2011 Scrum Guide by Ken Schwaber and Jeff Sutherland define the role of Scrum Master as:</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><em>"The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practises, and rules. The Scrum Master is a servant-leader for the Scrum Team."</em></div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">If a Scrum Team is having problems following Scrum practises and rules or is being interrupted and distracted, it's the Scrum Master we hold accountable to correct this. It is imperative that the right person is selected, appointed, or steps into the role of Scrum Master.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><span style="font-size: large;"><strong>Selecting The Scrum Master</strong></span></div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">The Scrum Master must understand Scrum. This doesn't necessarily mean that the person has committed to memory the Scrum Guide or completed a Certified Scrum Master course but should have an understanding of Scrum that goes beyond these two artifacts. The prospective Scrum Master should have an ingrained knowledge and comprehension of the Agile Manifesto and the twelve principles behind it. The prospective Scrum Master should be committed to following the 5 principal Scrum activities, <u>Sprint Planning</u>, <u>Daily Scrum</u>, <u>Sprint</u>, <u>Sprint Review</u>, and <u>Sprint Retrospective</u>, and the rules of Scrum as outlined in the Scrum Guide.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">The Scrum Master is usually selected from within the existing software organization. This may be project managers, team leads, senior software engineers, senior testers, etc. I've listed what seems to be the more experienced personnel of a software organization but I really don't think that a lot of software experience is essential for a Scrum Master. You won't find any technical requirements in the Scrum Guide for the Scrum Master role. In fact, a lot of technical experience could work to the detriment of a Scrum Master. For example, a strong technically minded project manager or team lead is usually an asset in a waterfall, command and control environment but in Scrum, a strong, technically minded Scrum Master may start 'telling' the Development Team how to do their work. The Development Team is meant to be self-organizing and Scrum assumes the people doing the work know best how to do it. From the Scrum Guide: "No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality".</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Where I worked, the first Scrum Master came about when the person was asked by management to research the various Agile methodologies but focusing on Scrum, and provide a recommendation on how to best adopt Agile. This exercise really served two purposes: 1) Figure out which Agile methodology best suited the company's current situation (Scrum hands down) and 2) Give the potential Scrum Master a means to obtain a broad understanding of Agile and build a solid knowledge base of the recommended methodology.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Whoever the company or software development organization chooses to be Scrum Master, this person should have the following qualities:</div><ul><li><div style="text-align: justify;">Be an early adopter,</div></li>
<li><div style="text-align: justify;"> Understand, embrace, and be fluent in the Agile Manifesto,</div></li>
<li><div style="text-align: justify;"> Be fully conversant in Scrum,</div></li>
<li><div style="text-align: justify;"> Be well read on adopting Agile and Scrum,</div></li>
<li><div style="text-align: justify;">Have the stamina and patience to teach Scrum to the organization, and</div></li>
<li><div style="text-align: justify;"> Have enormous enthusiasm for all things Scrum.</div></li>
</ul><div style="text-align: justify;"><strong>Be an early adopter:</strong> For most organizations, adopting Scrum is or will be a big change from a waterfall methodology. The Scrum Master must believe that Scrum is a better approach to software development. The Scrum Master can help convince the Development Team and software organization that Scrum is a better than waterfall if and only if, the Scrum Master believes this to be true to the core. Suppose a retrospective is skipped because the Development Team couldn't see the value in it two weeks after the last retrospective. If the Scrum Master allows this, the Scrum Master is not convinced a retrospective is needed after every sprint.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><strong>Understand, embrace, and be fluent in the Agile Manifesto:</strong> This document is the heart of Agile. Customer collaboration, high visibility of work, frequent deliveries, openness and honesty, continuous improvement, face-to-face communications, working software: they're all part of the Agile Manifesto as they are to Scrum.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><strong>Be fully conversant in Scrum:</strong> The Scrum Master will need to understand the Scrum Guide and it implications. Following the Scrum framework right from the start is essential; anything less will weaken the value of Scrum and can eventually lead back to waterfall. At first, the Scrum Team will probably resist the change to Scrum and will be reluctant to self-organize. What I found was developers new to Scrum are able to go through the mechanics of Scrum but with little appreciation of the benefits of Scrum. A Scrum Master must be able to identify and correct any variances from Scrum immediately. </div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><strong>Be well read on adopting Agile and Scrum:</strong> When a Scrum Team first forms, there will be some resistance to change but the Scrum Master can help ease people through it by citing examples of how other organizations got through the various issues the team will face. If the Scrum Master can address the issue and provide possible solutions immediately, the Scrum Team will gain confidence in Scrum and the Scrum Master. Almost any issue a team will face has probably been seen by someone else and they have somewhere documented it on the web. The Scrum Development Group on Yahoo (<a href="http://tech.groups.yahoo.com/group/scrumdevelopment/">http://tech.groups.yahoo.com/group/scrumdevelopment/</a>) is an excellent source of information but there are many blogs and other web sources that can be mined for solutions. Or, if you like, you can email me with your issue which I promise to answer quickly. Some areas that will probably cause confusion are:</div><ul><li><div style="text-align: justify;">User Stories-How to write them and how to estimate them.</div></li>
<li><div style="text-align: justify;">Story Points-How to do relative estimations.</div></li>
<li><div style="text-align: justify;">Acceptance Testing-How to write acceptance criteria and who runs these tests.</div></li>
<li><div style="text-align: justify;">Continuous Integration-How to deliver new/modified capabilities every day.</div></li>
<li><div style="text-align: justify;">Daily Builds-Automating a daily build with automated system, acceptance, integration, and unit testing.</div></li>
<li><div style="text-align: justify;">Daily Scrum- Getting the most out of the meeting in < 15 minutes.</div></li>
<li><div style="text-align: justify;">Technical Debt-How to deal with partially completed stories and bugs.</div></li>
<li><div style="text-align: justify;">Self-Organization-What this means and how to achieve it.</div></li>
<li><div style="text-align: justify;">Development Team Structure-How to deal with former hierarchy and titles in Scrum.</div></li>
</ul><div style="text-align: justify;">There are many other issues that will pop up but the ones above I've seen in every team new to Scrum.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><strong>Have the stamina and patience to teach Scrum to the organization:</strong> I think this is the most demanding aspect of the Scrum Master's job. I was lucky in that my boss was a superb listener and I was able to talk to him and come to better understand some of the issues I was confronted with.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Usually when I had problems with an individual or worst, the whole Development Team, it was paramount to separate the emotion from the logic and facts. I tended to speak a bit slower with carefully chosen words and appeal to the logic of the situation. I once spent over an hour with 2 people trying to explain that failing to meet a commitment (sprint goal) is not the end of the world. The team was unable to complete one of the user stories in the sprint and felt they had failed. My argument was that the complexity of some user stories is not entirely known at the start of the sprint and that the team's velocity, the average amount of work the team can expect to achieve during a sprint, is really a guide of the amount of work the team <u>might</u> achieve. If the team doesn't feel they can meet the goal of the sprint then the goal should be re-negotiated. In this case, the team was unable to see that they weren't going to meet the sprint goal-a common practice of developers I've seen over the years. Like the people on the Titanic, they believed that rescue was only moments away even while the ship was so obviously sinking. Why developers sometimes feel they'll be fired; not yelled at, not take a pay cut, but fired for making an inaccurate estimate is beyond me. In almost 30 years I've never seen the slightest disciplinary action against an individual for making an estimate that proved in fact to be wrong. In any case, after spending over an hour talking about vagaries of software estimates and about using the retrospective to figure out why the team over committed, I went home thinking that I failed to reach these people. You can imagine my surprise and strong emotional response when early the next morning I found an email where one person got it and realized that with Scrum, they can only do what they can do and that over commitment, especially in the early sprints, is something nobody is too upset over and that during their retrospective, the team needs to understand why it over committed and make the appropriate modifications.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><strong>Have enormous enthusiasm for all things Scrum:</strong> If you need to pretend to be enthusiastic about Scrum then being a Scrum Master is not for you. I really loved being a Scrum Master. I was genuinely moved when the light turned on for team members as they comprehended the various facets of Scrum. My philosophy was that you initially do Scrum by the book (i.e. Scrum Guide). If something isn't working after you've given a fair chance then solicit from the Scrum Team on what should change. However, after two years doing Scrum, nothing about Scrum changed. Of course there were changes on how user stories were written, how to do acceptance testing, and other technical components but nothing about Scrum actually changed. The Development Team may take a while to make the transition between waterfall and Scrum but the Scrum Master knows Scrum is better and will be constantly pointing out to the team why Scrum is better. </div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><br />
</div>Bob Boydhttp://www.blogger.com/profile/12902323994439824982noreply@blogger.com2tag:blogger.com,1999:blog-3482862331871918329.post-11409700801682887892011-12-14T11:03:00.000+11:002011-12-14T11:03:23.080+11:00Before the First Scrum: Velocity<div style="text-align: justify;"></div><div style="text-align: justify;">Before an organisation goes Scrum, they're most likely to be following a waterfall paradigm and using Function Points, Lines of Code (LOC), Analogy, etc., for software estimation in hours per task. They'll probably also use Earned Value or Microsoft Project as a means to measure their progress and ultimately, their profitability. In Scrum, story points are generally used as the estimation mechanisms and Velocity is used to measure progress and, indirectly, profitability.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><strong><span style="font-size: large;">Velocity In Hours</span></strong></div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">If the Scrum development team chooses to use hours as their estimation mechanism then velocity is easily arrived at: (number of team members * effective hours/day) * number of days in sprint. Using hours has a certain appeal to teams unfamiliar with Scrum and story points but using hours implies a estimation precision that simply doesn't (and never did) exist. Another issue with using hours is the 'User Stories' can read more like the waterfall-ish requirements that preceded them and be of a technical nature. Although these may capture the basic functionality, they may fail to grasp the end users' point of view, give little or no hint of usability, and tend to read like development tasks; telling the development team how to implement the feature.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Unlike estimating in hours, story points are at best only an approximation of the effort required. The Scrum Master should steer the team toward using story points as soon as practical.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><strong><span style="font-size: large;">Velocity In Story Points</span></strong></div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Prior to the first sprint, have the development team define a reference user story. A reference user story is one were the entire development team can reach an agreement on the effort involved in developing the feature, the complexity of developing it, and the risk inherent in it. This can be one of the user stories the product owner has written for the team or can be some small bit of previously implemented functionality that is familiar to the team. In either case, the reference story is usually something that can be completed by the whole team within a day or two. Once the reference user story is established, give this story 2 story points. All other user stories are estimated compared to this 2-point reference story. A story that is assigned a 4 should be twice as much as a 2-point reference user story. A story assigned 1 is one-half as much as the 2-point reference user story. The actual length of time eventually becomes unimportant. Planning Poker is probably the best estimation technique to use when estimating user stories. </div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">All stories considered for the first sprint are estimated by comparison to the reference story. The team selects and estimates stories they believe can be completed to the satisfaction of the team's Definition of Done in the first sprint (see <a href="http://implementingagile.blogspot.com/2011/09/definition-of-done-how-to-ensure.html" target="_blank">Definition of Done: How to Ensure Compliance</a>). The total count of story points becomes the team's initial estimated velocity.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><strong><span style="font-size: large;">Velocity Is For The Scrum Team</span></strong></div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Once the team has arrived at an estimated velocity, the Scrum Master can then begin using this as a KPI for the team. However, care should be taken to ensure that velocity is not used to compare between teams (see <a href="http://implementingagile.blogspot.com/2011/05/velocity-as-kpi-in-scrum.html" target="_blank">Velocity as a KPI in Scrum</a>). The Scrum Master can track the team's velocity and over time, measure the team's performance (see <a href="http://implementingagile.blogspot.com/2011/09/increasing-velocity-vs-stable-velocity.html" target="_blank">Increasing Velocity Vs Stable Velocity</a>).</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><br />
</div>Bob Boydhttp://www.blogger.com/profile/12902323994439824982noreply@blogger.com2tag:blogger.com,1999:blog-3482862331871918329.post-17007116606051733712011-11-12T11:20:00.000+11:002012-04-28T07:11:10.650+10:00Before the First Scrum: Management<div style="text-align: justify;">
You're a manager, a process person, developer, or product manager and your business success has been OK but you think it could be [much] better if your development strategy switched from waterfall to Scrum. How will you begin the transition? This entry will provide some advice on what needs to happen to convince a reluctant management team of the advantages of adopting the Scrum framework.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<span style="font-size: large;"><strong>First Steps For Management</strong></span></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
You've heard it over and over again that management needs to support the philosophy and practical applications of Scrum in order for it to work and be successful. In my situation, the R&D Manager and Product Management Manager were both experienced with Agile and were eager to experiment with Scrum to determine if the results would be better than the waterfall methodology then currently followed. The key point was that it was an experiment and not a full commitment; Agile would have to prove itself and that proof would be measured in the quality of the product and the speed at which the delivery was made. The business itself was not fussed on the means but were very keen on the results. Having the two department managers who are directly responsible for new product development supporting Scrum was, I believe, crucial for our ultimate success of adopting Scrum. </div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
But what if there's no management support or worst, opposition to change i.e., adopting Scrum. </div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
I worked at a defence company in the early 80's and the company's policy was no one would be hired as an engineer unless they had a 4 year college degree. My manager wanted to bring in someone as an engineer but without the necessary 4 year degree. The manager ended up writing a memo (remember those?) and eventually got the person in as an engineer. He later told me that the length of the memo was directly related to the hurdles before him and to get the person hired as an engineer required an eight page memo. The point of course is that the bigger the obstacle blocking your goal, the bigger the effort in making your case to reach that goal. To convince management that Scrum is a better alternative to current development methodologies, usually waterfall, you need to make the business case that Scrum can improve both quality and productivity; get better products out to the paying customers more quickly.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
You must sell the idea of Scrum to management starting the first day and every day following without letup. Management needs to learn that through Scrum, there's higher productivity, greater innovation, quick reaction to customer or competitive changes, high visibility to progress (or lack of progress), higher product quality, and more potential evaluation deliveries to customers after each sprint. At a training session given by Jeff Sutherland, he stated that even if you do nothing else but have a daily scrum meeting, you should see a 20-30% increase of productivity. <a href="http://scrum.jeffsutherland.com/" target="_blank">Jeff Sutherland</a> has lots of practical information and statistics that can be used to help convince your management that Scrum can help your business. There are also many, many resources on the web that have anecdotes and other stories that can help bolster your arguments for Scrum adoption. You will need to understand what exactly the manager's opposition to Scrum is and address those issues directly. </div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
I also think that trialling Scrum is a better approach than trying to completely change the way things are done all at once. By trialling, management is more likely to allow a single team to adopt Scrum without, in their minds, risking everything. When my company first trialled Scrum, only one team was formed. After the team was able to deliver a new product in only three months, a feat that had never happened before with waterfall, the CEO asked why all of development wasn't doing Scrum. </div>
<br />
If you have any stories on how you succeeded in winning over management to use Scrum, please let me hear from you.Bob Boydhttp://www.blogger.com/profile/12902323994439824982noreply@blogger.com0