tag:blogger.com,1999:blog-83914046013433189832024-03-17T04:06:08.873-04:00transition 2 agileAgile transformation, for large IT organizations. Articles. Ideas. Thought leaders.Cliff Berghttp://www.blogger.com/profile/02103767196153470434noreply@blogger.comBlogger25125tag:blogger.com,1999:blog-8391404601343318983.post-5590869843158094662018-05-16T16:44:00.003-04:002018-05-16T16:47:13.459-04:00DevOps Release Management<br />
<span style="mso-fareast-language: JA;">The purpose of release
management is to ensure that the risks associated with deploying software
releases are managed.</span><br />
<span style="mso-fareast-language: JA;"> </span>
<br />
<div class="MsoNormal">
<span style="mso-fareast-language: JA;">Waterfall software
development is a phased and gated process, and so waterfall release management
is also phased and implemented as a gate. Waterfall processes also seldom use
much automation for testing and deployment, and so test reports tend to be
manually assembled. In the end, the release management gate consists of the
various stakeholders attesting that their test processes have completed
satisfactorily and that all governance artifacts have been completed.</span></div>
<div class="MsoNormal">
<span style="mso-fareast-language: JA;">These methods work
well for releases that occur a few times per year. However, organizations today
are moving toward “continuous delivery”, in which releases are frequent,
possibly monthly, possibly many times per day. (Amazon releases software to
production every ten seconds.) Manual processes, governed by attestation
meetings are too cumbersome for continuous delivery. A new approach is needed.</span></div>
<h1>
<span style="color: #a2c4c9;"><span style="color: #45818e;"><span style="mso-fareast-language: JA;">Managing Risk in a Continuous Manner</span></span></span></h1>
<div class="MsoNormal">
<span style="mso-fareast-language: JA;">Continuous delivery
requires that nearly all software and system tests are automated, and that all
deployment processes are also automated. As such, it is expected that all of
those processes are fully tested and exercised prior to production deployment.
The primary means of managing risk for automated processes is that those
processes are tested, and the primary metric for risk management is test
coverage. This applies to all areas of risks that are amenable to automation, including
functional testing, performance testing, failure mode testing, and security
scanning.</span></div>
<div class="MsoNormal" style="text-align: right;">
<span style="font-size: large;"><span style="color: #93c47d;"><b><i> The primary metric for risk management</i></b></span></span></div>
<div class="MsoNormal" style="text-align: right;">
<span style="font-size: large;"><span style="color: #93c47d;"><b><i>is test
coverage. </i></b></span></span></div>
<div class="MsoNormal">
<span style="mso-fareast-language: JA;">The goal of continuous
delivery is that release to production should be a “business decision” – that
is, any software build that passes all of its tests should be considered
releasable, and the decision whether to release (and deploy) it is therefore
based only on whether stakeholders feel that the user community and other
business stakeholders are ready for the new release. Risk management has been
automated!</span></div>
<div class="MsoNormal">
<span style="mso-fareast-language: JA;">For the above process
to work, <i>the software tests must be trustworthy:</i> that is, there must be
confidence that the tests are accurate, and that they are adequate. Adequacy is
normally expressed as a “coverage” metric. Accuracy is typically ensured by
code review of the tests, or spot checking them, and ensuring a separation of
duties so that acceptance tests for a given code feature are not written by the
same people who write the application code for that feature. For very high risk
code, additional methods can be used to ensure accuracy. In the end, however,
tangible metrics should be used, and preferably metrics that can be measured
automatically. (See the article series, <i><a href="http://www.transition2agile.com/2014/12/real-agile-testing-in-large.html" target="_blank">Real Agile Testing in Large Organizations</a></i>.)</span></div>
<h1>
<span style="color: #a2c4c9;"><span style="color: #45818e;"><span style="mso-fareast-language: JA;">Is Attestation Still Needed?</span></span></span></h1>
<div class="MsoNormal">
<span style="mso-fareast-language: JA;">In a continuous
delivery process, attestation is still needed, but the attestation should be on
the <i>testing process</i> – not on the result. Specifically, risk management
attestation focuses on whether the process for creating and assessing tests
ensures that the tests are accurate and that they have sufficient coverage.
Attestation does not occur for the releases themselves, because they arrive
with too much frequency. Instead, attestation is done at a process level.</span></div>
<h1>
<span style="color: #a2c4c9;"><span style="color: #45818e;">
Are Gates Still Needed?</span></span></h1>
<div class="MsoNormal">
Since release to production is a business decision, humans
make the decision about whether to release a given software build. In addition,
there are sometimes tests that fail, or quality criteria that are not fully
met, but release to production might still be justified. Therefore, for most
businesses, release to
production will still be governed by a gated process, even when all tests have
been automated. Release to production can only be fully automated and gateless if one automates <b><i>all</i></b> of the production release decision criteria and places quality control on those automated decision criteria.</div>
<h1>
<span style="color: #a2c4c9;"><span style="color: #45818e;">
What About Documents?</span></span></h1>
<div class="MsoNormal">
Some things cannot be automated. For example, design
documentation must be created by hand. Design documentation is important for
managing the risks associated with maintainability.</div>
<div class="MsoNormal">
The continuous delivery approach to such things is to shift
assessment into the Agile sprint. As such, updating artifacts such as a design
document are part of the “definition of done” for each team’s Agile stories. To
manage the risk that these documents might not be updated, one embeds risk
mitigation practices into the Agile team’s workflow. For example, one way to
ensure that design documents are updated is to include a design review in the
workflow for the team’s Agile stories. Thus, overall assessment and attestation
of the risk should occur on the process – not on the set of documents that are
produced. If the process is shown to be robust, then when the code passes its
tests, it should be “good to go” – ready to release – assuming that releasing
it makes business sense.</div>
<div class="MsoNormal" style="text-align: right;">
<b><span style="color: #93c47d;"><span style="font-size: large;"><i>The surest path to unreliability is to provide</i></span></span></b></div>
<div class="MsoNormal" style="text-align: right;">
<b><span style="color: #93c47d;"><span style="font-size: large;"><i>direct access to static test environments. </i></span></span></b></div>
<h1>
<span style="color: #a2c4c9;"><span style="color: #45818e;">
What About “Lower Environments”?</span></span></h1>
<div class="MsoNormal">
In many organizations that are early in their adoption of DevOps methods and therefore use static test environments, teams push code to the various
test environments. That is a legacy practice that we plan to eliminate. In a DevOps approach, build artifacts (not code) are <b><i>pulled</i></b> into a test environment.
Further, each test process is performed by a single build orchestration task (VSTS task or Jenkins job), and only
that task should have the security permission required to pull into that
environment. Thus, it should not be possible to push into an environment. This
eliminates the need for any kind of release management for the lower
environments.</div>
<div class="MsoNormal">
Many of these issues go away once one starts to use dynamically provisioned environments. Until then, it is absolutely critical that one control updates to the various test environments, using an orchestrated process as described here. The surest path to unreliability is to provide direct access to static test environments.</div>
<style>
<!--
/* Font Definitions */
@font-face
{font-family:"MS Mincho";
panose-1:2 2 6 9 4 2 5 8 3 4;
mso-font-alt:"MS 明朝";
mso-font-charset:128;
mso-generic-font-family:modern;
mso-font-pitch:fixed;
mso-font-signature:-536870145 1791491579 134217746 0 131231 0;}
@font-face
{font-family:"MS Gothic";
panose-1:2 11 6 9 7 2 5 8 2 4;
mso-font-alt:"MS ゴシック";
mso-font-charset:128;
mso-generic-font-family:modern;
mso-font-pitch:fixed;
mso-font-signature:-536870145 1791491579 134217746 0 131231 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;
mso-font-charset:0;
mso-generic-font-family:roman;
mso-font-pitch:variable;
mso-font-signature:3 0 0 0 1 0;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;
mso-font-charset:0;
mso-generic-font-family:swiss;
mso-font-pitch:variable;
mso-font-signature:-536859905 -1073732485 9 0 511 0;}
@font-face
{font-family:Cambria;
panose-1:2 4 5 3 5 4 6 3 2 4;
mso-font-charset:0;
mso-generic-font-family:roman;
mso-font-pitch:variable;
mso-font-signature:-536870145 1073743103 0 0 415 0;}
@font-face
{font-family:"\@MS Gothic";
panose-1:2 11 6 9 7 2 5 8 2 4;
mso-font-charset:128;
mso-generic-font-family:modern;
mso-font-pitch:fixed;
mso-font-signature:-536870145 1791491579 134217746 0 131231 0;}
@font-face
{font-family:"\@MS Mincho";
panose-1:2 2 6 9 4 2 5 8 3 4;
mso-font-charset:128;
mso-generic-font-family:modern;
mso-font-pitch:fixed;
mso-font-signature:-536870145 1791491579 134217746 0 131231 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{mso-style-unhide:no;
mso-style-qformat:yes;
mso-style-parent:"";
margin-top:6.0pt;
margin-right:0in;
margin-bottom:6.0pt;
margin-left:0in;
mso-pagination:widow-orphan;
font-size:12.0pt;
font-family:"Cambria",serif;
mso-ascii-font-family:Cambria;
mso-ascii-theme-font:minor-latin;
mso-fareast-font-family:"MS Mincho";
mso-fareast-theme-font:minor-fareast;
mso-hansi-font-family:Cambria;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:minor-bidi;}
h1
{mso-style-priority:9;
mso-style-unhide:no;
mso-style-qformat:yes;
mso-style-link:"Heading 1 Char";
mso-style-next:Normal;
margin-top:12.0pt;
margin-right:0in;
margin-bottom:6.0pt;
margin-left:0in;
mso-pagination:widow-orphan lines-together;
page-break-after:avoid;
mso-outline-level:1;
font-size:16.0pt;
font-family:"Calibri",sans-serif;
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:major-latin;
mso-fareast-font-family:"MS Gothic";
mso-fareast-theme-font:major-fareast;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:major-latin;
mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:major-bidi;
color:#365F91;
mso-themecolor:accent1;
mso-themeshade:191;
mso-font-kerning:0pt;
font-weight:normal;}
p.MsoFooter, li.MsoFooter, div.MsoFooter
{mso-style-priority:99;
mso-style-link:"Footer Char";
margin-top:6.0pt;
margin-right:0in;
margin-bottom:6.0pt;
margin-left:0in;
mso-pagination:widow-orphan;
tab-stops:center 3.25in right 6.5in;
font-size:12.0pt;
font-family:"Cambria",serif;
mso-ascii-font-family:Cambria;
mso-ascii-theme-font:minor-latin;
mso-fareast-font-family:"MS Mincho";
mso-fareast-theme-font:minor-fareast;
mso-hansi-font-family:Cambria;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:minor-bidi;}
p.MsoTitle, li.MsoTitle, div.MsoTitle
{mso-style-priority:10;
mso-style-unhide:no;
mso-style-qformat:yes;
mso-style-link:"Title Char";
mso-style-next:Normal;
margin-top:6.0pt;
margin-right:0in;
margin-bottom:15.0pt;
margin-left:0in;
mso-add-space:auto;
mso-pagination:widow-orphan;
border:none;
mso-border-bottom-alt:solid #4F81BD 1.0pt;
mso-border-bottom-themecolor:accent1;
padding:0in;
mso-padding-alt:0in 0in 4.0pt 0in;
font-size:26.0pt;
font-family:"Calibri",sans-serif;
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:major-latin;
mso-fareast-font-family:"MS Gothic";
mso-fareast-theme-font:major-fareast;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:major-latin;
mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:major-bidi;
color:#17365D;
mso-themecolor:text2;
mso-themeshade:191;
letter-spacing:.25pt;
mso-font-kerning:14.0pt;
mso-fareast-language:JA;}
p.MsoTitleCxSpFirst, li.MsoTitleCxSpFirst, div.MsoTitleCxSpFirst
{mso-style-priority:10;
mso-style-unhide:no;
mso-style-qformat:yes;
mso-style-link:"Title Char";
mso-style-next:Normal;
mso-style-type:export-only;
margin-top:6.0pt;
margin-right:0in;
margin-bottom:0in;
margin-left:0in;
margin-bottom:.0001pt;
mso-add-space:auto;
mso-pagination:widow-orphan;
border:none;
mso-border-bottom-alt:solid #4F81BD 1.0pt;
mso-border-bottom-themecolor:accent1;
padding:0in;
mso-padding-alt:0in 0in 4.0pt 0in;
font-size:26.0pt;
font-family:"Calibri",sans-serif;
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:major-latin;
mso-fareast-font-family:"MS Gothic";
mso-fareast-theme-font:major-fareast;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:major-latin;
mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:major-bidi;
color:#17365D;
mso-themecolor:text2;
mso-themeshade:191;
letter-spacing:.25pt;
mso-font-kerning:14.0pt;
mso-fareast-language:JA;}
p.MsoTitleCxSpMiddle, li.MsoTitleCxSpMiddle, div.MsoTitleCxSpMiddle
{mso-style-priority:10;
mso-style-unhide:no;
mso-style-qformat:yes;
mso-style-link:"Title Char";
mso-style-next:Normal;
mso-style-type:export-only;
margin:0in;
margin-bottom:.0001pt;
mso-add-space:auto;
mso-pagination:widow-orphan;
border:none;
mso-border-bottom-alt:solid #4F81BD 1.0pt;
mso-border-bottom-themecolor:accent1;
padding:0in;
mso-padding-alt:0in 0in 4.0pt 0in;
font-size:26.0pt;
font-family:"Calibri",sans-serif;
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:major-latin;
mso-fareast-font-family:"MS Gothic";
mso-fareast-theme-font:major-fareast;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:major-latin;
mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:major-bidi;
color:#17365D;
mso-themecolor:text2;
mso-themeshade:191;
letter-spacing:.25pt;
mso-font-kerning:14.0pt;
mso-fareast-language:JA;}
p.MsoTitleCxSpLast, li.MsoTitleCxSpLast, div.MsoTitleCxSpLast
{mso-style-priority:10;
mso-style-unhide:no;
mso-style-qformat:yes;
mso-style-link:"Title Char";
mso-style-next:Normal;
mso-style-type:export-only;
margin-top:0in;
margin-right:0in;
margin-bottom:15.0pt;
margin-left:0in;
mso-add-space:auto;
mso-pagination:widow-orphan;
border:none;
mso-border-bottom-alt:solid #4F81BD 1.0pt;
mso-border-bottom-themecolor:accent1;
padding:0in;
mso-padding-alt:0in 0in 4.0pt 0in;
font-size:26.0pt;
font-family:"Calibri",sans-serif;
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:major-latin;
mso-fareast-font-family:"MS Gothic";
mso-fareast-theme-font:major-fareast;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:major-latin;
mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:major-bidi;
color:#17365D;
mso-themecolor:text2;
mso-themeshade:191;
letter-spacing:.25pt;
mso-font-kerning:14.0pt;
mso-fareast-language:JA;}
span.Heading1Char
{mso-style-name:"Heading 1 Char";
mso-style-priority:9;
mso-style-unhide:no;
mso-style-locked:yes;
mso-style-link:"Heading 1";
mso-ansi-font-size:16.0pt;
mso-bidi-font-size:16.0pt;
font-family:"Calibri",sans-serif;
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:major-latin;
mso-fareast-font-family:"MS Gothic";
mso-fareast-theme-font:major-fareast;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:major-latin;
mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:major-bidi;
color:#365F91;
mso-themecolor:accent1;
mso-themeshade:191;}
span.FooterChar
{mso-style-name:"Footer Char";
mso-style-priority:99;
mso-style-unhide:no;
mso-style-locked:yes;
mso-style-link:Footer;}
span.TitleChar
{mso-style-name:"Title Char";
mso-style-priority:10;
mso-style-unhide:no;
mso-style-locked:yes;
mso-style-link:Title;
mso-ansi-font-size:26.0pt;
mso-bidi-font-size:26.0pt;
font-family:"Calibri",sans-serif;
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:major-latin;
mso-fareast-font-family:"MS Gothic";
mso-fareast-theme-font:major-fareast;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:major-latin;
mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:major-bidi;
color:#17365D;
mso-themecolor:text2;
mso-themeshade:191;
letter-spacing:.25pt;
mso-font-kerning:14.0pt;
mso-fareast-language:JA;}
.MsoChpDefault
{mso-style-type:export-only;
mso-default-props:yes;
font-family:"Cambria",serif;
mso-ascii-font-family:Cambria;
mso-ascii-theme-font:minor-latin;
mso-fareast-font-family:"MS Mincho";
mso-fareast-theme-font:minor-fareast;
mso-hansi-font-family:Cambria;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:minor-bidi;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.25in 1.0in 1.25in;
mso-header-margin:.5in;
mso-footer-margin:.5in;
mso-paper-source:0;}
div.WordSection1
{page:WordSection1;}
</style>
-->Cliff Berghttp://www.blogger.com/profile/02103767196153470434noreply@blogger.com0tag:blogger.com,1999:blog-8391404601343318983.post-63161639263760900732018-05-16T16:20:00.000-04:002018-05-16T16:21:02.206-04:00How Does Agile Deal With Requirements Traceability?Feature traceability is a hold over practice from waterfall, where requirements are checked against tests. If one is using an Agile testing practice such as, say, <a href="https://en.wikipedia.org/wiki/Behavior-driven_development" target="_blank">Behavior Driven Development</a> (BDD), then feature traceability is redundant and a great time waster. This is because in an Agile process, each Agile story has a set of acceptance criteria, and in the BDD process, each acceptance criteria has one or more associated test scenarios. Thus, there is a clear one-to-many relationship between acceptance criteria—which you could think of as requirements—and tests.<br />
<br />
On the other hand, there is no table of this mapping, and so organizations that use traditional (waterfall) controls will often insist on a requirements traceability matrix (RTM). This is a real nuisance, because it is make-work for an Agile team and adds zero value; however, if you are forced to create an RTM, and you use BDD, there are techniques that you can use to lessen the burden. I’ll explain some below.<br />
<br />
First of all, create a unique ID for each story (stories usually have IDs anyway, so this is easy), and also <i>for each acceptance criteria</i>. Then, given that you are using BDD, each story has a <a href="https://github.com/cucumber/cucumber/wiki/Gherkin" target="_blank">Gherkin</a> feature file (that is not actually true, but assume it is for the moment): tag the feature with the story’s ID, and <a href="https://github.com/cucumber/cucumber/wiki/Tags" target="_blank">tag</a> each scenario with the ID of the acceptance criteria that it pertains to.<br />
<br />
You now have an explicit linkage between an acceptance criteria and one or more test scenarios. The challenge is to provide that linkage as a deliverable. If the linkage must be provided as a table, then you will need to either write a script to parse the feature files and assemble the table, with each table column an acceptance criteria ID and each row a Feature/Scenario ID combination. A much better situation, however, is if you can get the organization to accept a different process, whereby a test lead or business analyst reviews each story’s feature file and attests, via a comment in the Agile story tool, that the acceptance criteria are all covered by the feature file. That approach does not require creating a separate RTM.<br />
<br />
Of course, any such process needs to accommodate a situation in which a story’s acceptance criteria or feature file change after the feature file has been attested to. Unfortunately, the tool for creating a feature file is usually a text editor (some BDD tools allow you to use a Word document), and so there is probably no workflow built into the tool. The feature file should be in the project’s source code repository, so you can create a trigger using a build tool to perform some action whenever the feature file is changed, such as posting an email to the team lead or the test lead.<br />
<br />
<h3>
Adding features over time</h3>
Another consideration is what happens over time, as features accumulate and tests accumulate. Eventually you get to a point at which a new story impacts an existing feature. The question then is, Do you modify the current feature file, or do you add a new one? When your project started, you created a feature file for each story, but now some stories are changing the features that were implemented by prior stories.<br />
<br />
If you continue to create a new feature file for each story, you will have good traceability between a requirement and a feature file. However, it will become difficult to maintain because the programmers will have to find out which feature files are impacted by a code change. That is generally impractical, and so teams prefer to update existing feature files, and this breaks the correspondence between story and feature file. For this reason, contrary to what I said earlier, do not create a feature file for each story: instead, for each story, identify and name a set of one or more features that the story implements or changes; then, make sure there is one and only one feature file for each such feature. In each feature file, tag the feature with the IDs of the stories that affected that feature. This makes it possible to search and find features pertaining to stories and stories pertaining to features - without needing a table.<br />
<br />
A ramification of this is that the analyst who reviews feature files will now have to sometimes review multiple feature files for a story, and so each story should state which features are impacted by the story.<br />
<br />
<h3>
Assessing coverage</h3>
One thing that is very important to acknowledge is that programmers write terrible behavioral tests. I am not talking about unit tests - I am talking about functional integration tests, which are what behavioral tests are. It is therefore essential to have a testing expert or QA person examine the feature files and assess the coverage to determine if there are enough test scenarios, covering edge conditions, error paths, etc. One test scenario for each acceptance criteria is not enough!!! Having an independent person who has a testing mindset assess the test scenarios will increase your quality enormously.Cliff Berghttp://www.blogger.com/profile/02103767196153470434noreply@blogger.com1tag:blogger.com,1999:blog-8391404601343318983.post-49907943346848005722018-05-15T14:23:00.003-04:002018-05-15T14:23:51.517-04:00Is DevOps Agile?So often I hear things like,<br />
<blockquote>
“The Agile methodology is different from SAFe”</blockquote>
or<br />
<blockquote class="tr_bq">
“We are replacing our waterfall methodology with the Agile methodology”</blockquote>
Agile coaches will sigh at these kinds of statements, because they know that Agile is not a methodology. Those who are familiar with SAFe will sigh as well, knowing that SAFe is also not a methodology, but rather a framework for considering how to adjust one’s organization to accommodate Agile teams.<br /><br />And then there is DevOps: is it a methodology? Is it an extension of Agile, or an evolution of Agile, or something different?<br />
<br />
DevOps evolved independent of Agile because the Agile community drifted away from its technical roots, and therefore failed to keep up with technical advances such as cloud computing. Organizations needed to know how to scale Agile—not merely in terms of the number of teams, but also in terms of the complexity of systems that they could build. The scale of computing had greatly increased: companies today can have hundreds of millions or even billions of users accessing their websites: so-called “Internet scale” needed new approaches. The Agile movement began with eXtreme Programming (XP), which was highly centered on technical practices such as test-driven development (TDD) and continuous integration, but the Agile community failed to say how Internet-scale applications could be developed. Instead, the Agile community became mired in an excessive focus on process and team behavior, such as the way that teams plan their work, epitomized by Scrum.<br /><br />And so DevOps arose apart from the Agile community. Initially it did not have a name: it was merely a set of solutions that organizations invented to solve real problems. Some of these solutions included (not a complete list),<br /> 1. Dynamic provisioning of virtual environments—aka “cloud computing”—to enable rapid integration testing and to enable new deployment approaches.<br /> 2. Containerization, in order to enable rapid turnaround in standing up new app instances on demand, and to provide isolation and repeatability for deployments.<br /> 3. Automated integration testing.<br /> 4. Large scale code repositories and integrating functionality across thousands of application components in real time.<br /> 5. Extremely thorough automated functional <i>and non-functional testing</i>, to enable continuous delivery and reliable and trustworthy continuous deployment, and ownership of deployment and support by dev teams.<br /> 6. Extensive real time monitoring of applications, to support a metrics based philosophy.<br /> 7. Increased knowledge of—and responsibility for—Web security by application teams.<br /><br />All that time, the Agile community was busy debating whether organizations should first change their culture before trying to adopt Agile—and by “Agile” they meant Scrum, because Scrum took over the Agile community to a degree that Scrum almost became synonymous with Agile.<br /><br />The rise of Scrum did great harm to the Agile movement, and indeed many have said that Agile is now broken as a result. (See my article <a href="https://medium.com/@cliffberg/agile-is-broken-b448328f168c" target="_blank">here</a>, and Dave Thomas's talk <a href="https://www.youtube.com/watch?v=a-BOSpxYJ9M" target="_blank">here</a>.) For one thing, the availability of certification for Scrum resulted in a large number of people who had never programmed in their life obtaining an Agile certification, which they then used to get jobs as Agile coaches and Scrum Masters. Think about it: people with no programming experience telling programming teams how to do their job. It is no surprise that that did not work well. Today, there is a glut of Agile coaches, forcing down compensation; yet a very large percent of those coaches only know the Scrum process. I personally would prefer a coach who has years of experience on a programming team, as well as other leadership experience (of the servant leadership kind), perhaps even sales experience and P&L responsibility experience, because those kinds of experience make one sensitive to the real needs of a business. But the skills needed for a programming team coach is a lengthy topic in its own right.<br /><br />The rise of Scrum occurred during the 2000s, with cloud computing coming onto the scene around the same time; but cloud computing was not really understood by most organizations until after 2010, and that is when the term <i>DevOps</i> came into being. By that time, the Agile community had finally figured out that Scrum cannot just be inserted into a large organization, but that other things also had to change to enable Scrum teams to work in that organization. The Agile community, by and large, did not understand large organizations, so its response was generally something like, “Don’t <i><b>do</b></i> Agile, <b><i>be</i></b> Agile”. However, that was not very helpful and it reflected the Agile community’s lack of knowledge of how to engage with organizations at the levels needed to make the necessary changes.<br /><br />What happened next was that frameworks such as Less and SAFe came onto the scene. Less was generally supported by the Scrum community because it echoed that community’s ideology, which one could characterize as team-centric with a strong preference for self-organization and abhorrence of any kind of explicit authority. SAFe, in contrast, proposes a-lot of structure, and the the Scrum community has been very derisive of SAFe from the start. It continues to be to this day, to the extent that if someone wants to be a Scrum trainer, they are not allowed to also be a SAFe trainer—the Scrum Alliance will not certify someone who is known to be a SAFe trainer. How Agile is that? (If anyone wants to challenge my assertion, I have an actual case to back it up.)<br /><br />Regardless of whether one prefers SAFe or Less or another framework, the important point is that the Agile community finally realized that its early dogma was too simplistic. It now has answers for how to “be” Agile, instead of simply saying that one should, as if it is the fault of the companies (the Agile coach’s customer) that they are not Agile—like they have a disease. Finally, the Agile community has useful answers to the question, <i>What should we do?</i>—other than “start doing Scrum”. It finally realized that to <i><b>be</b></i> something, you have to <i><b>do</b></i> something.<br /><br />Meanwhile, the rise of DevOps took the Agile community by surprise, and now the Agile community has embraced DevOps as if DevOps is merely an extension or evolution of Agile, while the truth is that DevOps evolved completely independently out of the need to scale to Internet scale and deploy changes to Internet scale apps in rapid sequence. Fortunately, DevOps and Agile mesh together very well, because while the Agile community has chosen to focus mostly on process and behavior, DevOps practices are mostly around the technical questions of how to scale and rapidly deploy. Thus, DevOps has added a technical dimension back to the Agile viewpoint—a dimension which had been lost.<br />Cliff Berghttp://www.blogger.com/profile/02103767196153470434noreply@blogger.com0tag:blogger.com,1999:blog-8391404601343318983.post-81663958168058945492016-04-13T11:57:00.000-04:002016-04-15T08:15:42.163-04:00Does DevOps Change Agile?Yes and no.<br />
<br />
Some time back, on my first day supporting a CIO on an Agile transformation, the CIO said that he wanted to implement DevOps. In his mind, they were the same thing - that DevOps was merely the latest Agile model for how to arrange IT functions. Indeed, it is.<br />
<br />
But it is also different. On the one hand, Agile is defined by a set of values and principles enshrined in the Agile Manifesto. In that sense, DevOps is Agile. On the other hand, Agile has become defined by a set of practices that are almost universal to Agile implementations - things such as standups, team rooms, test-driven development, a product owner, iterations, and so on. In that sense, DevOps does change Agile, in a very substantial way.<br />
<br />
<h2>
Pipeline Versus Team</h2>
Agile project culture is very team focused. DevOps does not change that, but it shifts the focus to something broader: the end-to-end "value stream", also known traditionally as a "<a href="https://en.wikipedia.org/wiki/Value_chain" target="_blank">value chain</a>", that consists of the sequence of activities that happen from requirement inception to actual deployment of the consequent features. That value stream is best thought of as a pipeline of activities, the term being borrowed from the computer science concept of "<a href="https://en.wikipedia.org/wiki/Instruction_pipelining" target="_blank">pipelining</a>". If drawn, a DevOps pipeline looks like a waterfall process, consisting of requirements followed by implementation, followed by various kinds of system level testing, followed by deployment. What makes is <i>not</i> waterfall, however, is the fact that the pipeline operates <i>continuously</i>. That is, any any moment, every portion of the pipeline has something in it - it is a non-stop flow.<br />
<br />
To make a value stream work, the development team must enlarge its horizon, to consider actors beyond the team - such as enterprise security, operations, and so on. The world does not revolve around the development team: it revolves around the value pipeline, and that means there must be lots of ongoing collaboration with parties beyond the team. This is perfectly consistent with Agile values and principles, but it is a different viewpoint than is traditional for Agile in the way that it is normally practiced. For example, should those parties that are external to the development team be in the standup? Normal Agile practices do not answer that question, and there are many other similar questions that need to be answered to make DevOps work.<br />
<br />
<h2>
Behavior-Driven Development Versus Test -Driven Development</h2>
The practice of Test-Driven Development (TDD) is deeply entrenched in Agile culture. Teams that practice it are often viewed as advanced, whereas teams that do not are considered by many in the Agile community to be less advanced. Alas, <a href="http://martinfowler.com/articles/is-tdd-dead/" target="_blank">TDD has come under fire</a>, and there are many people who feel that it is not the best approach for everyone in all cases. Regardless of that, it turns out that DevOps does not need TDD for an effective pipeline. What DevOps needs is Behavior-Driven Development (BDD).<br />
<br />
Loosely speaking, BDD consists of defining tests from a user perspective. Thus, tests are "end-to-end" because they are defined in terms of the behavior of the system - not the behavior of system components or even more granular "units". Historically it has been difficult to implement a BDD approach because one needs to assemble the entire system as an integrated unit to perform the tests. However, virtualization - the technology that has enabled cloud computing and DevOps - makes it possible - even easy - to create local instances of system components, so that one can assemble an integrated system very early. That makes BDD possible. Thus, one can use a test-first approach in which tests are defined at a behavior level, instead of a very granular unit level, as is the case with TDD.<br />
<br />
<div style="text-align: right;">
<span style="color: #d9ead3;"><span style="font-size: large;"><i>TDD is still useful, but the focus shifts to BDD. </i></span></span></div>
<br />
TDD might still be useful - that is a different discussion - but it is no longer necessary for having a high coverage automated test process. One can measure test coverage for behavioral tests just as easily as for unit level tests. In fact, DevOps teams typically use BDD as the foundation of their continuous integration test cycle: developers run the BDD tests - which are end-to-end - for a story before checking their code in. This is shown in figure 1.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiBRYkf3Dto4xYf_Aqj1V7AwfKwefXGmmwUar3Aqk3BNQoPEU7BTCVpui9DI-Z38PRTdkEw7kByxznrSQ2B0vJjQC4Ewtwn1u5u7v6m2XpKZDcSn-7tqIPzLbO7uC_cYe3ycKA3g81K0BaT/s1600/HowCIChanges.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="480" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiBRYkf3Dto4xYf_Aqj1V7AwfKwefXGmmwUar3Aqk3BNQoPEU7BTCVpui9DI-Z38PRTdkEw7kByxznrSQ2B0vJjQC4Ewtwn1u5u7v6m2XpKZDcSn-7tqIPzLbO7uC_cYe3ycKA3g81K0BaT/s640/HowCIChanges.jpg" width="640" /></a></div>
<br />
<div style="text-align: center;">
<span style="font-size: small;"><i> Figure 1: Comparison of traditional continuous integration (CI) and how CI is often done today in a DevOps setting.</i></span></div>
<div style="text-align: center;">
<a href="https://drive.google.com/open?id=0By4lfBwI0rt6VmxudHVmNlZnbEU" target="_blank"><span style="font-size: xx-small;"><i>As PDF </i></span></a></div>
<br />
<br />
To be able to perform end-to-end tests locally before checking one's code in, developers need a local build process that instantiates an
integrated system locally (or perhaps in a developer-specific cloud
instance - see figure 2). Linux container technology now makes this even easier: one
merely starts a container for each system component and runs one's tests
- starting a container takes a fraction of a second, so there is little
delay from instantiating the integrated system locally. If developers
work in Linux (locally or in a cloud), they can run docker and create
all the containers they need in a fraction of a second, test with those,
and then destroy the containers. Indeed, testing in the cloud right
from the beginning of the CI process is increasingly useful given that
one of the main things that needs to be tested is the <a href="https://en.wikipedia.org/wiki/Orchestration_%28computing%29" target="_blank">orchestration</a>
definition - which is currently tied to the type of target operating
environment (e.g., AWS, Azure, GCE, etc.), although there are efforts to
unify orchestration definition.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgYE1h7FqkYGN5PgI9lBdjThbcFsAfie8aLd4m_LKN8XugIJZhZVKoALH8uLjPdJxgkvR7rksG_x46NFFM2Lhk7V25JFkoIMmjAS2Pu5PyJoOMuLxaNNVqQCwRV7DJ-bQA7VXu5P3kXsXsN/s1600/HowEnvsChange.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="480" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgYE1h7FqkYGN5PgI9lBdjThbcFsAfie8aLd4m_LKN8XugIJZhZVKoALH8uLjPdJxgkvR7rksG_x46NFFM2Lhk7V25JFkoIMmjAS2Pu5PyJoOMuLxaNNVqQCwRV7DJ-bQA7VXu5P3kXsXsN/s640/HowEnvsChange.jpg" width="640" /></a></div>
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<div style="text-align: center;">
<span style="font-size: small;"><i> Figure 2: Traditional development environment versus DevOps development environment.</i></span></div>
<div style="text-align: center;">
<a href="https://drive.google.com/open?id=0By4lfBwI0rt6NFptN0Y0NFo1MjQ" target="_blank"><span style="font-size: xx-small;"><i>As PDF </i></span></a></div>
<br />
Again, all this is perfectly consistent with Agile values and
principles. What it conflicts with, however, is a longstanding Agile
practice of focusing on comprehensive unit testing as the bedrock of the
test automation cycle. DevOps does not preclude unit tests, which are
still valuable, but it shifts the focus to test-first development using
end-to-end tests, done early and continually, using locally provisioned
instances of all system components instead of shared test instances or "<a href="https://en.wikipedia.org/wiki/Mock_object" target="_blank">mocks</a>".<br />
<br />
<h2>
Testing the System Versus Testing Stories</h2>
The "user story" is the cornerstone of any Agile process. A story defines a requirement, from a user's perspective, in terms of an end result. Agile teams work against a backlog of stories, and a story is considered to be "done" when it has passed all of its tests; the tests in turn map one-to-one to a set of acceptance criteria that are attached to the story. A release of the system is considered to be "done" when all of its stories are "done".<br />
<br />
DevOps changes the last part. A DevOps pipeline begins with stories, but as soon as work passes through the continuous integration portion of the pipeline, the idea of a story ceases to have meaning: at that point, the entire system is being tested, and a test failure might be easy to correlate to a story or it might not be. As an example, consider figure 3: suppose that a story's tests have passed when run in the continuous integration (CI) environment, but subsequently the same tests are run again "downstream" is a more production-like environment, and one of the tests fails in that environment. Is the problem with the story, or the environment? It is not clear. Also, suppose a performance test fails: such a failure might be difficult to trace to a particular story. Thus, tests performed after continuous integration are system-level tests - not story level tests. This means that the release is not "done" when all the story tests have passed - the release is "done" when all of the story tests have passed, <i>and</i> all of the system level tests have passed, in all of the applicable environments. A typical full DevOps pipeline is shown in figure 3.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiNJZ5i_pWVSjL_qr4OM_wkpICyFc_zELcQwXVDbs-RfKbOr8MU-smBj5E6RojXfA1i8THVr3UgQuu2wOfi6OLc7K7rlS0XnPPUHQYjQN5K_PtjTvfb8-pKvupCTvJl9u9WCmE5bb3tHQqw/s1600/FullDevOpsPipeline.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="480" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiNJZ5i_pWVSjL_qr4OM_wkpICyFc_zELcQwXVDbs-RfKbOr8MU-smBj5E6RojXfA1i8THVr3UgQuu2wOfi6OLc7K7rlS0XnPPUHQYjQN5K_PtjTvfb8-pKvupCTvJl9u9WCmE5bb3tHQqw/s640/FullDevOpsPipeline.jpg" width="640" /></a></div>
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<div style="text-align: center;">
<i>Figure 3: A typical full DevOps pipeline.</i></div>
<div style="text-align: center;">
<a href="https://drive.google.com/open?id=0By4lfBwI0rt6VS1scHNSTXJ4TUE" target="_blank"><span style="font-size: xx-small;"><i>As PDF </i></span></a></div>
<br />
And again, this is consistent with Agile values and principles, but it departs from traditional Agile practice.<br />
<br />
<h2>
Is DevOps Itself a Sign Of Immaturity?</h2>
Organizations that deploy continuously have fully automated processes and so one might consider whether there are even separate "development" and "operations" teams. There are. A man who used to work for me went on to become head of deployment at Amazon for several years. In a large organization, you still need someone - a team - to focus on the challenges of operations. Leaving it to each team without any oversight or centralized support is a recipe for disintegration and a "tragedy of the commons" where things that are not urgent for a team but that are urgent for the organization as a whole fall by the wayside.<br />
<br />
Netflix has a very large "tools" team that supports all of the many different development teams. Netflix focuses on automating things, so that instead of manual monitoring they have alert systems that let the right people know when something is wrong. As Adrian Cockroft of Netflix <a href="http://perfcap.blogspot.com/2012/03/ops-devops-and-noops-at-netflix.html" target="_blank">puts it</a>, "[dev teams] never have to have a
meeting with ITops, or file a ticket asking someone from ITops to make a
change to a production system", but Josh Evans is Director of Operations Engineering and he oversees the way that their hundreds of microservices are integrated, so much of operations has, in effect, been replaced by an operational architecture team: the "Ops" has shifted to defining an architecture that is highly decoupled, that alerts the right people, and that is elastic and self healing. This approach is sometimes called "NoOps" because the ops people are more engineers than operations people: they build and operate automated deployment systems that enable development teams to deploy continuously with minimal human intervention. What NoOps is <i>not</i> is a group of autonomous development teams that operate without any centralized operational support.<br />
<br />
DevOps entails a considerable shift in responsibility, in that operational responsibility is now <i>shared</i> by development: programmers need to build systems that are easier to operate, and they need to test in production-like environments so that deployment does not reveal problems that could have been found earlier. Similarly, operations needs to focus mostly on automating operations, and needs to deploy with the same scripts and processes that are used by development. These two camps must design the pipeline together, and work together to continually improve it. The pipeline becomes their shared platform.<br />
<br />
<h2>
Some Agile Ideas That Are Even More Important Now</h2>
There is one idea that is not in the Agile Manifesto but has nevertheless been strongly embraced by the Agile community and that is even more important for DevOps: that is the idea of continuous learning. In order to implement a DevOps cloud-based testing pipeline, one must use a-lot of tools. It is a fact that those tools turn over at a rapid rate. For example, two years ago the most important tools for provisioning environments were chef, puppet, vagrant, and a few others. Today, the entire idea of provisioning environments is in question, because containers have emerged as a better alternative to VMs, and so the need to deploy software to VMs is going away - instead, one deploys container images. Those images are built locally, and so the need for remote software provisioning has been replaced by remote container management. This all happened essentially overnight, and it means that DevOps teams are going to have to eventually replace all of their chef/puppet/vagrant code with orchestration files and dockerfiles. Surely something else will take the place of these in a few years. We are now in an era in which tools change more rapidly than ever before, and teams need to accept that they are always learning new tools. The ability and willingness to abandon one's expertise and plunge into a new one is essential. This point is highlighted in Cal Newport's bestseller, <i><a href="http://calnewport.com/books/deep-work/" target="_blank">Deep Work</a></i>. According to him,<br />
<blockquote class="tr_bq">
<i>"...because these technologies change rapidly, this process of mastering hard things never ends: You must be able to do it quickly, again and again."</i> (page 30)</blockquote>
<br />
<h2>
Summary</h2>
DevOps needs us to change how we think about Agile. It requires us to loosen our hold on established practices, and go back to first principles. The technologies that enable DevOps - virtualization, cloud services, and behavioral testing tools - empower us to do things in an even more Agile way, but that requires changing some practices that are historically equated with "Agile".<br />
<br />Cliff Berghttp://www.blogger.com/profile/02103767196153470434noreply@blogger.com0tag:blogger.com,1999:blog-8391404601343318983.post-45916132587201156552015-02-02T17:24:00.000-05:002015-02-04T22:23:16.223-05:00Interview: Dean Leffingwell<div class="separator" style="clear: both; text-align: center;">
</div>
<span style="color: #cfe2f3;">Cliff: Today I am talking with <a href="https://www.linkedin.com/pub/dean-leffingwell/39/9b/985" target="_blank">Dean Leffingwell</a>, creator of the <a href="http://www.scaledagileframework.com/" target="_blank">Scaled Agile Framework</a>, commonly known as SAFe. Dean, can you please tell me a little about your background?</span><br />
<br />
Dean: My degrees are in aerospace and biomedical engineering, so I see myself as a systems engineer dedicated to software. In one form or another, I’ve spent my entire 40+ years career being responsible for software and complex systems development.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgAjr0FNuEWYaFAG_hYPhgAmIJYQaALrfyMMiYo2_bUyCiYFEZ-8YzdFFvHLdyMFfSzvkbEF__vAYIDTbRcHSLhpwiaVvVDWCJOSOzey_0PTLKqJiDmFwHCg59uDJlH2sAzBLFBHZuU0AA_/s1600/Dean.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgAjr0FNuEWYaFAG_hYPhgAmIJYQaALrfyMMiYo2_bUyCiYFEZ-8YzdFFvHLdyMFfSzvkbEF__vAYIDTbRcHSLhpwiaVvVDWCJOSOzey_0PTLKqJiDmFwHCg59uDJlH2sAzBLFBHZuU0AA_/s1600/Dean.jpg" /></a></div>
<br />
<span style="color: #cfe2f3;">Cliff: I can see the imprint of that: SAFe seems to have a systems view of things.</span><br />
<br />
<span style="color: #cfe2f3;">With regard to your origins, you created RELA and Colorado Medtech.</span><br />
<br />
Dean: In 1977, I founded RELA, and later absorbed the publicly held company, Cybermedic. The melding of those two organizations resulted in Colorado Medtech, also public. That was my first 20 years as a CEO, we built complex medical devices and other fun stuff that included one of the coolest adventure rides on the planet for a major theme park. I became a software quality methodologist by necessity because we were building systems that could literally save people’s lives, or if defective, could kill them. Since then, the focus on software quality has been a driving passion that informs everything I do. One of the reasons that I so enjoyed the transformation to Agile—especially after starting with eXtreme Programming—was the intense focus on the quality of code. <br />
<br />
My exposure to Agile came through XP first and Scrum second, and I saw two things that I had not seen earlier: in XP a set of courageous software practices that were technically sound, and in Scrum, a simple and lightweight project management method. I thought that the two applied together were really cool, but I immediately noticed a clash between the user communities. Technically, I never really understood the basis for the competition, because to be effective you have to have both approaches. But methodologists don’t agree with other methodologists.<br />
<br />
I’ve also been involved in Lean throughout my career. I was chairman a company that made a lean version of MRP [Material Requirements Planning]. Colorado Medtech had a manufacturing capability, so I also cut my teeth on Lean manufacturing. I attended a workshop from <a href="https://en.wikipedia.org/wiki/Eliyahu_M._Goldratt" target="_blank">Goldratt</a> on the Theory of Constrains, learning from Goldratt himself. Lean helped save a division of our company that was critical to our ultimate success.<br />
<br />
Fast-forward to the present day where we find ourselves building the world’s most complex systems with this incredibly robust body of knowledge that includes Lean, <a href="http://www.leanproductflow.com/" target="_blank">Product Development Flow</a> – Don Reinertsen – Agile, XP, Scrum, and Kanban. SAFe integrates and builds on that pool of knowledge to help address growing systems complexity. And after all, what software developer today should not understand all of these aspects? That is one reason that you see some of heat around SAFe; we don’t see it as a zero sum game. It’s all good. In fact, the next version of SAFe will incorporate kanban for teams, in addition to Scrum and XP, bringing optionality, balance and integration of the best of the best to the team’s choice of approach.<br />
<br />
<span style="color: #cfe2f3;">Cliff: As you pointed out, there seems to be quite a division in the industry. I don’t think that is healthy. Being from the same time period as you, I see all these things as different schools of thought that overlap in terms of ideas. These recent approaches do seem to complement each other. There is a long view that many people need to see.</span><br />
<br />
Dean: Your website reflects the larger perspective, which is why I agreed to invest some time in this interview. I don’t usually engage in defending the framework because it speaks for itself through the website, scaledagileframework.com, and the case studies. You don’t need a methodologist’s or service provider’s opinion about it, everyone can decide for yourself. There is nothing hidden.<br />
<br />
For example, about a year ago, a blogger was criticizing SAFe. That’s fine; there are plenty of improvements to be made. I criticize it myself. But he wrote that he could not figure out what he didn’t like about SAFe and then he realized that it was because there were no people in it. To me, that is like looking at the Eiffel Tower and seeing no iron. When you look at the Big Picture and click through to the articles behind it, you will see more people than anything else. <br />
<br />
To simplify SAFe, I’ll share a discussion that happened just yesterday with one of the world’s largest software companies. They have some enormous challenges in a really large program—involving 400–500 developers and stakeholders from many aspects of the business—and are looking to SAFe for help. Absolutely mission critical. I said that the first thing we could do is organize, train, and empower Agile teams. Second, communicate the mission, provide some UX and architectural guidance for consistency of purpose and usage, and then let them define it, design, it, plan it, build it, validate it, and gather customer feedback in a continuous series of two-week iterations. And finally, we facilitate largely face-to-face planning, feedback, JAD and problem solving sessions for the entire program, every ten weeks or so, on a fixed cadence. How could that not work?<br />
<br />
<div style="text-align: right;">
<span style="color: #fce5cd;"><span style="font-size: large;"><b><i>“There are at least three hundred thousand</i></b></span></span></div>
<div style="text-align: right;">
<span style="color: #fce5cd;"><span style="font-size: large;"><b><i>Agile practitioners using SAFe today.”</i></b></span></span></div>
<br />
When you look at it in such a simplified form, you wonder whether criticisms of SAFe are based are on its fundamental constructs, or misconceptions, or perhaps the fact we are in a competitive marketplace for thoughts and services? SAFe is clearly a disruptive change to the industry. But SAFe is built on Agile teams. Period. There are at least three hundred thousand Agile practitioners using SAFe today, who were previously locked out. They were living in waterfall SDLCs. Just last week someone told me that there was a time when they could not use the word “Agile” in their company. Of course they use it now with SAFe. For many, their organization’s very survival now depends on it. We hear things like: “You’ve given us a wee bit of hope for this company,” and, “It used to be easier to write software that didn’t work than it was to change a requirement.” We changed that with SAFe. <br />
<br />
That kind of personal feedback, along with the business results, are what motivate us every day. When we hear controversy about the method, we look at the measurable results companies are getting, see what can be improved, and move on to the next revision. And because SAFe is a work in process, we don’t get all emotional about it, rather, we learn and adapt. If I remember correctly, there’s an agile principle that speaks to continuous improvement, so I assume that applies to methods as well. <br />
<br />
<span style="color: #cfe2f3;">Cliff: One of the objections seems to be that SAFe is very prescriptive.</span><br />
<br />
Dean: SAFe documents a set of proven success patterns. For instance, the SAFe Big Picture depicts teams iterating and delivering value every two weeks, and every so often—8, 10, 12 weeks—they check in with their end customers and larger stakeholders to validate the net accumulation of those iterations. Then they run a larger Inspect and Adapt workshop at the Program level to address the larger issues. Is that prescriptive? Sure, but can you imagine that you shouldn’t do that?<br />
<br />
What’s more, XP and Scrum are very prescriptive as to how the teams do their work. Clearly, we need Agile guidance for people above the Team level, because it takes more than development teams to deliver end user value. Sometimes when you have a headache, maybe you need to take an aspirin. Might help with the pain. <br />
<br />
<span style="color: #cfe2f3;">Cliff: I think the push back is, why tell them that it has to be a certain number of weeks?</span><br />
<br />
Dean: When someone interprets SAFe so literally it usually means they haven’t taken the time to click beyond the Big Picture to learn about the actual intention. For instance, if you click on “Develop on Cadence,” you’ll find the following: “ … <i>while the Big Picture illustrates five sprints per program increment, that is arbitrary and programs can pick whatever cadence that best suits their abilities and context</i>”. That’s guidance around a principle, not a prescription of how many aspirins to take. <br />
<br />
And by analogy, can you fully understand a software system by simply looking at a sketch of the domain model? Obviously that’s not enough to reason about the underlying system. So it is with SAFe. The Big Picture is the domain model, but the principles and implementation lives deeper.<br />
<br />
<span style="color: #cfe2f3;">Cliff: It looks prescriptive if you don’t click through and read it. But what you are saying is that there is a lot of judgment in these things.</span><br />
<br />
Dean: Absolutely. It’s just a framework. <br />
<br />
<span style="color: #cfe2f3;">Cliff: Is SAFe hierarchical?</span><br />
<br />
Dean: There has to be a top of a picture and a bottom. Where does strategy come from?<br />
<br />
<span style="color: #cfe2f3;">Cliff: Strategy is inherently hierarchical because it is the outermost level of intent, in terms of what an organization is trying to do.</span><br />
<br />
Dean: Strategy and investment funding comes from the top. The teams don’t pay their own salaries or decide what business the enterprise should be in. I think there is also a misconception about what is meant by the SAFe core value of alignment. Is “alignment” management telling the teams what to do and how do it? Or is it guiding the mission for the program? What’s the alternative: no mission, misalignment?<br />
<br />
<span style="color: #cfe2f3;">Cliff: I have actually heard from some camps a rejection of alignment. The objection seems to be about bottom-up versus top-down, and about self-organization versus coherence.</span><br />
<br />
Dean: Therein lies the crux of the issue. A key principle of product development flow is that overall alignment delivers more value than local optimization. To achieve that alignment, empower teams, and speed value delivery, SAFe fosters decentralized decision-making under an umbrella of common mission and some architectural governance.<br />
<br />
For example, the group I spoke with last week has about 400–500 people working on a platform that processes billions of dollars of revenue and needs a major revitalization. They will be launching three or four Agile Release Trains with some 50 teams. Don’t you think there has to be some guidance that says, “Here is what we need to accomplish? These are the features that drive the most important behavior. These are the common UX patterns for the user navigating. Here is our view of an architecture that will hold it all together.” Do we believe that 500 people can independently and emergently arrive at a common conclusion? If you answer those questions truthfully, you’ll acknowledge that the vision for the new platform must be driven by the overarching business strategy. And there have to be people responsible for that. People who shoulder the ultimate responsibility for success of the enterprise. And yes, they tend to live at the top of the organizational chart.<br />
<br />
<span style="color: #cfe2f3;">Cliff: Is there a sweet spot for SAFe, or a range of organizations that it is a best fit for?</span><br />
<br />
Dean: SAFe was designed in real world context at places like John Deere ISG, BMC, Navteq, Nokia Siemens Networks, etc.; places where there are 300–1,000 practitioners that need to collaborate on their work. Last week I was at the <i>Scaling Agile for the Enterprise Consortium</i> in Brussels. There were a couple of Agile thought leaders on stage who, when asked about scaling, basically said “Don’t do it. Don’t scale agile. Don’t get that big.” Seriously, can you imagine the response from the enterprise, “Sorry, it’s too late, we are already incredibly successful, and we are already big.” <br />
<br />
If teams don’t need to collaborate on a common mission, that’s a different issue. For example. If there are even a large numbers of teams building largely independent products, the level of governance in SAFe may not be necessary – though a common way of working may well be. But if you are building, say, a field crop combine with many hundreds of people involved, and there is a virtual rat’s nest of complexities and dependencies—the electronics, transducers, computer systems, actuators, the control system that gets fed from GPS to move the combine straight down the field, the engine control unit, real time vehicle service information and status reporting—well, you get the idea. That’s what SAFe is designed for. <br />
<br />
And in the IT and ISV world, can a few agile teams build a significant enterprise class product these days? Should we compartmentalize the development of a such solutions into isolated teams, or should we build a team of teams that synchronize and work toward a common mission?<br />
<br />
<div style="text-align: right;">
<span style="color: #fce5cd;"><span style="font-size: large;"><b><i>“We sometimes work with applications so large that it takes<br />multiple instances of SAFe to support it.”</i></b></span></span></div>
<br />
To meet that enterprise demand, all of the sudden, there is a lot of energy going into various methods for scaling Scrum, and some are public about their belief that they are competing against a “big, one-size-fits-all framework.” That’s SAFe, of course, but I have news: we sometimes work with applications so large that it takes multiple instances of SAFe to support it. SAFe fits well for 8–10 release trains working together, but beyond that you’ll have a different level of problem of scale, and you’ll need multiple instances of SAFe. That’s one of the reasons we put Strategic Themes in 3.0, as a connector to other instances of SAFe, and to the enterprise’s overall business strategy.<br />
<br />
That makes SAFe a highly scalable framework, but it is not designed to solve the problems faced by just a few teams looking to align their sprints. It is the larger enterprises that need SAFe, many of which are in the process of a SAFe transformation. If you name almost any ten Global 1000 companies, SAFe is already being deployed in a number of them.<br />
<br />
Like with any disruptive technology, there is an adjustment phase that will come more easily to some than others – think S-curve ‘early adopters,’ ‘early majority,’ etc. When SAFe is deployed for the first time, it can feel top-down to the Scrum coaches who are coaching the teams, because with SAFe their teams need to be aligned on a release train. Is it worth it? The results say so. And the teams quickly get into it as they realize they are empowered to contribute to the larger value. Working on a team of teams that is delivering enterprise value faster is simply more satisfying for all. SAFe is successful in the market for only one reason, it works. Check out the case studies pages [<a href="http://www.scaledagileframework.com/case-studies/" target="_blank">here</a>] for the objective measures of the value of SAFe. Simply, winning is more fun.<br />
<br />
<span style="color: #cfe2f3;">Cliff: What got my attention when I first discovered it was the picture. It was the first picture that filled in the pieces of the puzzle.</span><br />
<br />
Dean: Didn’t it make sense to you when you saw it? Although if we both looked at that very first picture now, I’d be a bit embarrassed. It looks like Fred Flintstone might have drawn it. Oh, I guess that was me. But SAFe evolves. Version 4 will be out this summer.<br />
<br />
<span style="color: #cfe2f3;">Cliff: It does make sense to me.<br /><br />What are the reasons you would have multiple instances of SAFe? Is it because of different portfolios? Different sources of funding?</span><br />
<br />
Dean: It is typically driven by the different value streams, business units, and operating budgets. In a really large business, say a 25B company, each business unit may have a few hundred million in revenue, and each business unit will invest a percent of that in IT and software development. But because of the organizational challenges of managing large numbers of practitioners, and because many are working in largely separate domains, they tend to naturally fall into pockets of 300-500-1,000 people, each with an instance of SAFe.<br />
<br />
<span style="color: #cfe2f3;">Cliff: Do you end up with a SAFe steering committee that oversees the multiple SAFe instances?</span><br />
<br />
Dean: Well that’s up to the enterprise architecture and enterprise portfolio strategy, currently a bit outside the scope of SAFe. And in any case, they wouldn’t be steering SAFe instances so much as they would be defining and coordinating portfolio investments that business units use SAFe to realize.<br />
<br />
The root cause of much of this debate comes down to a discussion about who decides what gets built. If 3-5 teams are working together in a domain they know, can they largely determine together what gets built? Probably. Would 100 development teams in a global healthcare company be the ones to decide if the company should enter a different market, and provision teams to address that opportunity? Of course not. Strategy and investment funding is a centralized concern.<br />
<br />
<span style="color: #cfe2f3;">Cliff: Teams are not always aware of the long discussions and analysis that take place before that point.</span><br />
<br />
Dean: And perhaps we leaders cause some of that lack of visibility when we fail to have a systems, rather than a parochial or functional view – when we mandate waterfall SDLCs, when we fail to communicate a clear strategy and compelling mission, and worst of all, when we overload the teams with unrealistic and unachievable commitments. That’s why the SAFe model depends on Lean-Agile leaders, and the emphasis on taking a systems view, implementing flow, and empowering teams by constantly communicating vision and strategy. <br />
<br />
<span style="color: #cfe2f3;">Cliff: One hears a lot in the Agile community about culture, and being Agile versus doing Agile: What role does mindset of leadership style play in a SAFe implementation?</span><br />
<br />
Dean: It plays a huge role. [Dean calls up the SAFe website and clicks on “<a href="http://scaledagileframework.com/implementing/" target="_blank">Implementing</a>”.] Look at steps 2 and 3 of a SAFe rollout. [They are, “Train All Executives, Managers, and Leaders,” and “Train Teams and Launch Agile Release Trains,” respectively.] Let’s start with Executives. In a SAFe rollout, the process is as follows: Over on the left here [he points to “Train Lean-Agile change agents”], everyone needs to understand the principles behind SAFe. This is what the process of building that mindset looks like: We train change agents (SPCs, both internal and external) to teach “Leading SAFe,” a course that introduces managers and executives to Lean and Agile thinking. Those leaders participate in a release planning simulation and do an exercise sprint, right in the classroom. They study the Agile Manifesto. They learn about Lean and Product Development Flow. Then they learn about Agile Teams, Agile Release Trains and how to implement an agile portfolio. The last two hours is a leadership module. We finish there, because if they are not ready to lead, rather than follow, success will be limited. Then the teams are trained in SAFe Scrum and XP, and organized around value streams that can more reliably deliver value on demand.<br />
<br />
<div style="text-align: right;">
<span style="color: #fce5cd;"><span style="font-size: large;"><b><i><span style="color: #fce5cd;"><span style="font-size: large;"><b><i>“</i></b></span></span>Is there a new mindset required to be</i></b></span></span></div>
<div style="text-align: right;">
<span style="color: #fce5cd;"><span style="font-size: large;"><b><i>successful with SAFe? Yes.</i></b></span></span><span style="color: #fce5cd;"><span style="font-size: large;"><b><i>”</i></b></span></span></div>
<br />
Is there a new mindset required to be successful with SAFe? Yes. Do we achieve it? Almost always. Are we dependent upon it? Absolutely. How else would companies get the results they are getting? But you can’t see mindsets in the SAFe diagram, you gotta click!<br />
<br />
<span style="color: #cfe2f3;">Cliff: The site is pretty rich, there is a lot of stuff. How does servant leadership fit into this?</span><br />
<br />
Dean: We use “Lean-Agile Leadership” as our metaphor, which emphasizes taking a systems view, embracing the Agile Manifesto, product development flow, creating a learning organization, and enabling knowledge workers. Operating as servant leaders is part of that.<br />
<br />
<span style="color: #cfe2f3;">Cliff: There seems to be a misunderstanding in the industry about some core Agile concepts, such as what servant leadership is. Books I have read on servant leadership—and indeed ways in which I have experienced effective servant leadership—stipulate that servant leadership is not about totally leaving things up to the team: it is a style of <i>leadership</i>.</span><br />
<br />
Dean: It <u><i>is</i></u> indeed a style of leadership. It is not passive; it’s supportive, but it still has responsibility for outcomes. Managers do not abrogate their responsibility, or indeed their authority, just because we better understand the power, and indeed humanity, of self-organization and empowerment. We must have both, leaders who lead, and teams and programs that are largely self-organizing and self-managing.<br />
<br />
We are now are dealing with hundreds of thousands of practitioners who have embraced a new method, indeed a better way, more empowering, more fulfilling, and potentially far more effective, a new belief system. But it is a huge danger to exclude or belittle management. Perhaps this is because they haven’t been managed well in the past; and yes, we still see plenty of that. Perhaps they assume managers cannot learn new behavior; and perhaps some cannot. But we also see the opposite, an emergence of a new form of leadership. One that is based on common principles. We see that every day too, and that inspires us to keep moving forward.<br />
<br />
That includes new ways of planning work, which SAFe provides via large scale face-to-face planning. It’s absolutely key to what we do, and we take that to a level where some have said, “Well it’s not Agile to have 100 people planning together.” But face-to-face communication is a key tenet of Agile. For example, look at the group in the photo on our website [<a href="http://scaledagileframework.com/release-planning/" target="_blank">here</a>]; I know that group. They get as many as 175 people “together” every ten weeks, in multiple locations, and they plan simultaneously. Every ten weeks they pull together folks from the US, India, and Serbia, they bring the business owners in to participate. See that table in the middle? Those are the business executives. Every ten weeks they spend a part of two days with the teams. Frankly, it’s exhilarating. There is nothing like it, and if you read Lyssa Adkins’ article in InfoQ [<a href="http://www.infoq.com/articles/agile-coaches-coach-view-safe" target="_blank">here</a>], she attended one and noted that she had never seen anything like it. She called it an “agile accelerant.”<br />
<br />
<span style="color: #cfe2f3;">Cliff: That was quite an inspiring article. She talks about the arc of her thinking on it, and how it changed as she experienced SAFe.<br /><br />With regard to the release planning meeting, how flexible is that. Is it always a two-day session?</span><br />
Dean: Two days is very standard, but it depends a bit on scope. It isn’t just planning and alignment, its a joint requirements and design session. The group in the photo takes two and a half days, because they have a lot of folks in Mumbai with a 12.5 hour time delay.<br />
<br />
<span style="color: #cfe2f3;">Cliff: Does it ever take longer? When I have done release planning with teams, it can take a week.</span><br />
<br />
Dean: It doesn’t take that long with SAFe. You are planning only the next Program Increment; you will do it again in about 10 weeks. Take a small bite. Limit the batch size. One big international company plans across five trains at the same time—and they still do it in 2.5 days or so, but they plan together because they are interdependent. This is one aspect of SAFe that is prescriptive: you plan together every PI. Face to face communication is part of the Manifesto. You aren’t SAFe without it.<br />
<br />
<span style="color: #cfe2f3;">Cliff: How much preparation is needed?</span><br />
<br />
Dean: It depends on whether it’s your first time or tenth. Your first time can be more challenging. Alignment has to occur in management, development, system design, operations, etc. and it might not be present prior to the meeting. Some upfront preparation is going to be required.<br />
<br />
For example, I was recently talking to a company that had been worried about their first big room planning experience. They were afraid that the first session would be chaotic because they were obviously not fully ready—you never really are—and people were wavering in their support. What would happen if they met for two days and nothing useful came of it? Well, the CIO was a Lean-Leader. He said, “this is going to be a really critical learning experience for us. It’s just us, so what can possibly go wrong, really? Let’s get going with that first meeting.” <br />
<br />
Because of his leadership and what took place in release planning, they now have a common way of working, they have an aligned view amongst the executives and teams, they eliminated much of the excess work in process. You cannot underestimate the value of finding and addressing program level bottlenecks, identifying otherwise hidden dependencies, finding the way to flow, and navigating competing priorities.<br />
<br />
<span style="color: #cfe2f3;">Cliff: How do you deal with the organizational structure issues? These organizations must have existing functions for QA and Testing and release management and so on.</span><br />
<br />
Dean: The release train is usually virtual, at least initially. Just a group of the right people who agree to plan together, commit together, execute together and inspect and adapt. A business is not going to close down the business unit and merge with IT. The DevOps IT/OM group is still going to have a director who runs operations and deployment. But they have to operate as an extended team to accomplish the mission. [Dean points to <a href="http://scaledagileframework.com/value-streams/" target="_blank">this page</a>, and “Finding the Value Stream.”]. <br />
<br />
<span style="color: #cfe2f3;">Cliff: So it is kind of a matrix?</span><br />
<br />
Dean: It is. It typically starts as a virtual organization. In some cases—the easier ones—they are already organized on lines of business. <br />
<br />
<span style="color: #cfe2f3;">Cliff: Is that a natural path?</span><br />
<br />
Dean: In some cases. Lets say an automotive components supplier has four BUs building four product lines. Most of the business people, devs, testers, architects, etc. are all in the BU. That’s a pretty straightforward value stream, and the virtual and the physical organization are basically the same.<br />
<br />
But if someone is implementing single sign-on across a suite of products, or trying to improve the supply chain, you’ll have to bring people in from a number of areas and different platforms. And you can’t just create a new organization for the purpose of this large-scale initiative, even if it’s long lived. So release trains are often virtual. <br />
<br />
<span style="color: #cfe2f3;">Cliff: How does this compare to, say, Spotify? </span><br />
<br />
Dean: I’ve talked to them a bit, and I’ve followed the method. We have even discussed SAFe for scaling further. If you look at their organizational metaphor, they have Squads, which are 5-10 individuals and a product owner, pretty much the same as SAFe agile teams. They have Tribes, organized groups of Squads that deliver largely independent solution value of a type. There are up to 100 or so people in a tribe—a fairly natural social limit, a direct parallel to a SAFe Agile Release Train. As I understand it, Guilds are basically communities of practice: they advance skill development, which we don’t model in SAFe. At Agile Israel 2014, Spotify’s Head of People Operations gave a talk about their self-organizing and self-managing Squads, and he showed some of what happened initially. Lots of fast success stories, for sure. Then he showed the initial UIs for Android, IOS, Windows, etc. They looked like they were built by different teams, because of course, they were. He noted that was suboptimum for the user experience, and then described how they went back and reworked those apps with a common UX governance, so the user experience was largely the same across devices. <br />
<br />
We are all learning the same lessons by doing Agile at scale. Is great design emergent or intentional? Both! I have a great respect for those guys. I don’t see it as a competitive method; I see it as a different set of labels for accomplishing the same thing. We absolutely support communities of practice and what they are able to accomplish, but, for the time being, they are outside the scope of SAFe. Besides, if we added them, we’d be too prescriptive :)<br />
<br />
<span style="color: #cfe2f3;">Cliff: Have you ever had any organizations struggle in getting SAFe going, and if so, what are some of the suggestions that you have to avoid that?</span><br />
<br />
Dean: We have a very simple mantra: if you train everyone and launch Agile Release Trains, you will succeed. If execs, business owners, architects and product managers think that Agile is just a process for developers, it’s not going to work. Everybody has to understand what they are doing and what everyone’s role is. We believe that the success of the initiative is ultimately dependent, not on the framework, not on the consultants and coaches, or not even solely on the teams—it also depends on leadership. If leadership is trained in Lean-Agile thinking, people accomplish great things with SAFe. <br />
<br />
<span style="color: #cfe2f3;">Cliff: Is SAFe “Lean Systems Engineering” (LSE) already out, or is that coming out?</span><br />
<br />
Dean: It’s well under way. A lot of the content has been developed. For example, the principles of Lean Systems Engineering are built in explicitly, whereas they are a little more hidden in SAFe. We have defined most of the core concepts, what’s a system, a system of systems, how to express systems intent without over-specifying, adaptive requirements and design, set-based development, MBSE, kanban for teams and systems work, etc. We met with about 20 systems engineers yesterday in a feedback session, and they showed us some things we need to change. It will be available to the public sometime soon, but we have not fixed the date, because we are not sure when we will reach an MVP. But I think we are over half way there.<br />
<br />
<div style="text-align: right;">
<span style="color: #fce5cd;"><span style="font-size: large;"><b><i><span style="color: #fce5cd;"><span style="font-size: large;"><b><i>“</i></b></span></span>SAFe is designed for large-scale software solutions—</i></b></span></span></div>
<div style="text-align: right;">
<span style="color: #fce5cd;"><span style="font-size: large;"><b><i>banking, financial, insurance, ISVs, etc.</i></b></span></span><span style="color: #fce5cd;"><span style="font-size: large;"><b><i>”</i></b></span></span></div>
<br />
<span style="color: #cfe2f3;">Cliff: Why would someone use SAFe versus SAFe LSE?</span><br />
<br />
Dean: SAFe is designed for large-scale software solutions—banking, financial, insurance, ISVs, etc. But if you are building a satellite, where you have the satellite itself, the ground station, the web farm feeding data to the users, then that is really a system of systems, and you have to understand how the subsystems are built and interact. How one system may impose requirements on another, and how capabilities span subsystems. It’s a different problem, the systems and subsystems and their interfaces are physical and tangible, and the notion of value streams is not necessary the right abstraction at the highest level. <br />
<br />
The large systems builders—industrial, defense, automotive, home automation, and such—come to class to learn about SAFe and how to best to apply it to their context. But they also note that “We don’t really have a Portfolio level concern here, it’s just one really big system.” We are learning from them how to model things differently. Systems, subsystems, components, capabilities, and features all play a role.<br />
<br />
<span style="color: #cfe2f3;">Cliff: And you have hardware-in-the-loop testing.</span><br />
<br />
Dean: You still design with fast iterations and integrations. You build in small batch sizes. But you also probably have IV&V teams who may be the only ones that can put the whole thing together and test it. You have supplier subsystems and internal programs that may or may not be using Agile. You might have a customer that says “here is the system and software requirements specification, do it like it says.” You have delivery milestones for certain. You have a whole different set of constraints. It is not as free form as it is in SAFe, but you still want the benefits of a Lean and Agile approach. That’s the challenge of the modern systems builder and we think we can help with SAFe LSE.<br />
<br />
<span style="color: #cfe2f3;">Cliff: Is there anything that you would like to mention about what people can look forward to?</span><br />
<br />
Dean: You can look forward to the continuing evolution of SAFe. The next release, SAFe 4.0, will be out this summer. It will include a number of new constructs and content elements. For instance, it will integrate kanban guidance for Teams, alongside Scrum, so SAFe teams have a clearer choice of methods, and can even combine them as they see fit. <br />
<br />
And by the way, we are not so sure how well that news will be received in the Scrum and Kanban communities, but we think the teams deserve that choice. Let’s say you are adopting SAFe at a major systems builder, and you have a small group of 3-5 optics engineers, do they need a Scrum Master and Product Owner? Not clear. Do they need to visualize work and understand flow? Do they need to integrate with the rest of the system every two weeks? Absolutely. <br />
<br />
But personally, I look forward to SAFe Version 8.0! That should be awesome. Some of the people in my SPC class asked me why I don’t just call version 4 version 8, but we all know that would be cheating. And of course, we have SAFe LSE 1.0 that will launch sometime this year, along with companion courseware.<br />
<br />
Are there going to be multiple ways to scale, be it Scrum and others? Of course. Are we learning new and better ways to deliver bigger and better systems more quickly? I sure hope so. As of now, we are on Version 3.0 of SAFe, and it works. It has a large footprint of customers experiencing success, and a global community of consultants, partners, and practitioners implementing it, supporting it, and telling us how to improve it. We’ll keep listening and evolving. That’s a pretty good launching point for a next set of innovations. Cliff Berghttp://www.blogger.com/profile/02103767196153470434noreply@blogger.com2tag:blogger.com,1999:blog-8391404601343318983.post-13211316241939193272015-01-10T10:26:00.003-05:002015-01-10T13:17:06.672-05:00Cloud based apps are extremely vulnerable - here's what to do<h2>
<span style="font-size: large;">And the Two Design Patterns That All Developers Should Know</span></h2>
<br />
15 per cent of business cloud users have been hacked.<br />
<br />
That is according to a recent Netskope report (article <a href="http://www.prnewswire.com/news-releases/netskope-report-reveals-high-frequency-of-compromised-credentials-in-enterprise-cloud-apps-300017649.html" target="_blank">here</a>).<br />
<br />
Recent debates about whether cloud storage are secure have focusd on the infrastructure of the cloud: that is, if your data is in the cloud, can other cloud users see it? Can the cloud provider see it?<br />
<br />
But there has been little attention to the event more important issue of whether cloud apps themselves are secure. This is so important because if your data is in the cloud, then it is not behind your company’s firewall – it is accessible over the Internet. All one needs is the password. So if you think things were bad before, just wait until hackers shift their focus to the cloud.<br />
<br />
<div style="text-align: right;">
<span style="color: #c27ba0;"><span style="font-size: large;"><i><b>Executives think that IT staff know how to</b></i></span></span></div>
<div style="text-align: right;">
<span style="color: #c27ba0;"><span style="font-size: large;"><i><b>write secure software applications</b></i></span></span></div>
<div style="text-align: right;">
<span style="color: #c27ba0;"><span style="font-size: large;"><i><b>– but most don’t.</b></i></span></span></div>
<br />
Companies spend huge amounts of money trying to make their infrastructure secure, but they invest essentially nothing in making sure that their application code itself is secure. As I wrote in my book High-Assurance Design,<br />
<blockquote class="tr_bq">
• The average programmer is woefully untrained in basic principles related to reliability and security.<br />
<br />
• The tools available to programmers are woefully inadequate to expect that the average programmer can produce reliable and secure applications.<br />
<br />
• Organizations that procure applications are woefully unaware of this state of affairs, and take far too much for granted with regard to security and reliability.</blockquote>
<br />
The last bullet is the most important one: Executives of companies think that IT staff know how to write secure software applications – that to do otherwise would be unethical, and their staff are definitely not unethical. But this attitude is the heart of the problem, because the fact is, most software developers – and even most senior software architects – know very little about how to write secure software. Security just isn’t that interesting to most programmers: no one rewards you for writing secure code – not like you get rewarded for writing more features. And no one is asking for it, because there is an assumption – an <i>incorrect</i> one – that programmers create secure code in the course of their work, just as plumbers create well sealed pipes in the course of plumbing. True for plumbers, in general, but <u><i>not</i></u> true for programmers.<br />
<br />
Recently I was on a DevOps team in which the client was very concerned about security. The client ran its own scans of our servers in the cloud, and found many issues that needed to be fixed. All of these issues were infrastructure related: primarily OS hardening. None had to do with the design of the application. The general feeling of the team was that the security of the application itself would not be questioned, so we did not have to worry about it. At one point, one of our databases in our cloud test environment was hacked. The database was shut down and a forensic analysis was supposedly performed (we were never told what they found). There was no impact on the team’s work – it was business as usual.<br />
<br />
<div style="text-align: right;">
<span style="color: #c27ba0;"><span style="font-size: large;"><i><b>If we don’t fix this dysfunction in our industry,</b></i></span></span></div>
<div style="text-align: right;">
<span style="color: #c27ba0;"><span style="font-size: large;"><i><b>then the Internet Of Things (IOT) will be a disaster.</b></i></span></span></div>
<br />
This state of affairs is unsustainable. If we don’t fix this deep rooted dysfunction in our industry, then the Internet Of Things (IOT) will be a disaster: Imagine having every device you own connected to the Internet – to a cloud service of some kind – and all of these devices and accounts hackable. And imagine the continuous software updates to keep pace with newly discovered security vulnerabilities. This is not a future that I want – do you? Not only is George Jetson’s car a pain to maintain – with constant software updates – but it might come crashing down. People will be afraid to drive their car or use these IOT devices.<br />
<br />
The only way to fix this is for organizations to demand that developers learn how to write secure software. You cannot scan for application level security: doing so is <a href="http://samate.nist.gov/docs/SA_tool_effect_QoP.pdf" target="_blank">not effective</a>. Having a “security officer” oversee things is not effective either – not unless that person intends to inspect every line of code written by every programmer – and that is not feasible in an Agile setting, where the code changes every day. The only way to produce secure software in an Agile environment is to <i>for the programmers to know how to do it</i>.<br />
<br />
It is not that there are not lots of resources available for this, <a href="http://assuredbydesign.com/haa/" target="_blank">my own textbook</a> included. There are tons of books, there are online resources – notably <a href="https://www.owasp.org/" target="_blank">OWASP</a> – and there are even <a href="https://www.isc2.org/" target="_blank">certifications</a> – and these certifications are the real deal: these are not fluff courses.<br />
<br />
People like magic bullets. Unfortunately, there is no magic bullet for security: knowledge is the only path. But if I were asked what two things software developers should know to make their code more secure, I would have to say that they should know about these two design patterns: (1) <a href="https://en.wikipedia.org/wiki/Compartmentalization_%28information_security%29" target="_blank">Compartmentalization</a>, and (2) <a href="https://en.wikipedia.org/wiki/Privilege_separation" target="_blank">Privilege Separation</a>.<br />
<br />
<div style="text-align: right;">
<span style="color: #c27ba0;"><span style="font-size: large;"><i><b>Your systems will be hacked. The only question is,</b></i></span></span></div>
<div style="text-align: right;">
<span style="color: #c27ba0;"><span style="font-size: large;"><i><b>What will the hackers get away with?</b></i></span></span></div>
<br />
Your systems will be hacked. There is no question about that. The only question is, What will the hackers get away with? Will they be discovered right away through intrusion detection monitoring and shut down? And if not, will they be able to retrieve an entire database of information – all of your customers’ personal data? That is, will one compromised account enable them to pull down an entire complete set of information?<br />
<br />
Compartmentalization is an old concept: In the context of computers, it was first formalized by the <a href="https://en.wikipedia.org/wiki/Bell%E2%80%93LaPadula_model" target="_blank">Bell LaPadula model</a> for security. It became the basis for security in early military computer systems, and it formalizes the essential concept used by the military and intelligence communities for protecting sensitive information. It is based on the concept that a person requesting access to information should have (A) sufficient trust level – i.e., they have been vetted with a defined level of thoroughness – and (B) a need to know: that is, they have a legitimate reason for accessing the information. No one – not even the most senior and trusted person – can automatically have access to everything: they must have a need to know. Thus, if someone needs information, you don’t open the whole filing cabinet: you open only those files that they have an immediate need for. To open others, you have to request permission for those.<br />
<br />
Military computing systems are onerous to use because of the layers of security, but in a civilian setting for business applications there are ways to adopt the basic model but make parts of the process automatic. For example, restrict the amount of information that an individual can access in one request: don’t allow someone to download an entire database – regardless what level of access they have. And if they start issuing a-lot of requests – more than you would expect based on their job function – then trigger an alarm. Note that to implement this type of policy, you have to design the application accordingly: this type of security is not something that you can bolt on, because it requires designing the user’s application in such a way that they only access what they need for each transaction and are not given access to everything “in that file cabinet”.<br />
<br />
The other key concept that programmers need to know is “privilege separation”. No one should be able to access a large set – e.g., a table – of sensitive data <i>directly</i>: instead, they should have to access a software service that does it for them. For example, if a user needs to examine a table to find out which rows of the table meet a set of criteria, the user should not be able to access or peruse the table directly: the user should only be able to initiate the filter action and receive the single result. The filter action is a software service that performs the required action under the privileged account of the server – which the user does not have access to. The user performs his or her work using an account that is only able to initiate the software service. If the user’s account is obtained through a phishing attack, that account cannot be used to obtain the raw data in the database: retrieving the entire table would require a huge number of calls to the service and intrusion monitoring should be watching for abnormal use such as that. This does not prevent hacking, but it greatly limits what can be lost when a hack occurs.<br />
<br />
These measures are not sufficient, but they are a start, and they provide a foundation for how to think about application level security, from which programmers can learn more. The key is to start with an access model based on the kinds of actions that users need to perform and the subsets of data that they need direct access to for each transaction – access is not simply based on their overall level of trust or general need to access an entire class of data.<br />
<br />
<div style="text-align: right;">
<span style="color: #c27ba0;"><span style="font-size: large;"><i><b>Organizations are completely to blame for the current state of affairs – and organizations can fix it.</b></i></span></span></div>
<br />
Organizations are completely to blame for the current state of affairs: If organizations demand that programmers know how to write secure code, then programmers will respond. People are merely focusing on what their bosses are telling them is important.<br />
<br />
So if you are an executive in an IT organization, it is up to you. The industry will not fix things: <i>You</i> need to make security a priority. <i>You</i> need to tell your teams that you expect them to learn how to write secure code. <i>You</i> need to create incentives for programmers and software architects to become knowledgeable and even certified in secure coding. <i>You</i> need to create a culture that values security. Security is up to you.Cliff Berghttp://www.blogger.com/profile/02103767196153470434noreply@blogger.com0tag:blogger.com,1999:blog-8391404601343318983.post-74427434214644726222015-01-03T12:10:00.003-05:002015-01-04T10:41:55.157-05:00Real Agile Testing, In Large Organizations – Part 4(Continued from <a href="http://www.transition2agile.com/2014/12/real-agile-testing-in-large_22.html">Part 3</a>)<br />
<br />
<h2>
<span style="font-size: x-large;">Is everyone a tester?</span></h2>
This is one of the greatest debates about Agile testing: who does it? One camp claims that everyone on an Agile team is a tester: there should be no “tester” role. The Scrum camp is perhaps most adamant about this. Another camp claims that there are testers, and that the separate role is very important.<br />
<br />
Again, the right answer depends. Even Jeff Sutherland – the inventor of Scrum – has complimented the performance of projects that had separate test teams. <a href="http://pdf.aminer.org/000/248/971/projected_management_model_for_physically_distributed_software_development_environment.pdf" target="_blank">This one</a> stands out. So if it is ok with Dr. Sutherland, it should be ok for Scrum adherents. The question is, when does it make sense, and when does it not make sense?<br />
<br />
For Morticia’s website (see <a href="http://www.transition2agile.com/2014/12/real-agile-testing-in-large.html">Part 1</a>), <i>Thing</i> did most of the testing but we all chipped in, and that was fine. But for the EFT Management Portal, the testing is so complex that it would sure make sense to have a test lead, and several people to focus on pulling together the performance testing, the security testing strategy, the testing of the multiple back end partner interfaces, the testing of the legal compliance rules, and so on. These things are like projects in their own right and so they need leads. But don’t forget about learning: some people might want to learn about new types of testing and test automation, even if they have not done it before, so allow team members to change roles with appropriate supervision (e.g., through pairing).<br />
<br />
<div style="text-align: right;">
<span style="color: #d9ead3;"><span style="font-size: large;"><i><b>Saying “You should never have a test lead” is not very Agile,</b></i></span></span></div>
<div style="text-align: right;">
<span style="color: #d9ead3;"><span style="font-size: large;"><i><b>and saying
“You should always have a test lead”</b></i></span></span></div>
<div style="text-align: right;">
<span style="color: #d9ead3;"><span style="font-size: large;"><i><b>is not very Agile either.</b></i></span></span></div>
<br />
If unsure, use common sense: don’t use doctrine. Agile is first and foremost about applying judgment: that is why the <a href="http://agilemanifesto.org/" target="_blank">Agile Manifesto</a> is written the way it is, with phrases like “While there is value in the items on the right, we value the items on the left more.” In other words, it is not prescriptive. They wanted us to keep our thinking flexible: e.g., saying “You should never have a test lead” is not very Agile, and saying “You should always have a test lead” is not very Agile either.<br />
<h2>
<span style="font-size: x-large;">Who needs to understand these things</span></h2>
One of the most important aspects of Agile in general is the conversations among the team – the exchange of ideas, the helping each other, and the talking through of issues. This is critically important as it relates to testing and understanding when we have met the needs of the end users. Ensuring that the team understands – not just reads – the testing strategy, is critical, so that the testing strategies are ever present in the minds of the developers. Developers need to think about testability as they design and code, and they need to be thinking about failure modes and how those are going to be tested, because developers often identify situations that that testers have overlooked. Communicating testing concerns across team roles is extremely important.<br />
<br />
In <a href="http://www.transition2agile.com/2014/12/real-agile-testing-in-large.html">Part 1</a> of this article we pointed out that an Agile test strategy is developed and maintained by the team, in collaboration with external stakeholders. The team leader(s) (e.g., Scrum Master, coach, project manager, tech lead, etc. – however the team(s) is/are constituted) need(s) to understand what an Agile test strategy is for, so that it is accounted for during iteration planning. If the organization has support functions such as Security, Testing, Architecture, etc., those support functions need to understand how an Agile test strategy is different from a traditional test plan: the collaborative nature of Agile testing, the need to test continually, the need to automate as much as possible, and the need to evolve the testing strategies as the team learns more about the application and its requirements. The support function managers need to know all this so that they can make sure that they provide staff to collaborate with the team in the initial development of the testing strategies and throughout software development.<br />
<br />
The support functions will need to come to terms with the fact that their role changes significantly with respect to waterfall development: waterfall teams obtain services from support functions, services such as Testing, Architecture, etc., and those services operate largely independently. In an Agile setting, the support functions need to operate in a collaborative way, working side by side with the team. In fact, much of their work should shift from “doing” to “teaching” – i.e., the support functions need to coach the team in how to perform the things that the support function used to do – to the extent that that is practical. Thus, support functions become coaching centers and resource centers. (In the article <a href="http://www.transition2agile.com/2014/10/how-to-rapidly-infuse-technical.html"><i>How To Rapidly Infuse Technical Practices Into Your Agile Teams</i></a> we talk about how to transition waterfall oriented support functions to Agile support functions.)<br />
<br />
Agile coaches need to work with the various support functions to help them to think through these changes. Agile will impact the types of people who work in the various support functions – they need to be more people-oriented, with an interest in helping others instead of doing the work themselves. The suppot function staff will also have to learn about Agile practices and automation tools. Agile will impact how the support functions are measured by senior management: they will need to be measured on how effectively they help teams to become self sufficient in technical practices, and the support functions also need to be measured in terms of whether they stay current in the rapidly evolving landscape of Agile tools. Given these changes, Agile will therefore impact funding for these functions. It will shift the balance of power in the organization, and that is why the CIO needs to be the driver for these discussions. In a successful Agile transformation, the support functions are not eliminated: they are transformed and reorganized. Knowledge must <i>increase</i> – not decrease – and to make continual learning a sustainable practice, it really helps to have organizational functions that focus on helping practitioners – the teams – to continue to learn new things in an endless cycle of learning, doing, and improving.<br />
<h2>
<span style="font-size: x-large;">Creating a learning organization</span></h2>
In a <a href="https://www.linkedin.com/groups/Is-job-title-Project-Manager-37631.S.5944006808258490372?view=&gid=37631&type=member&item=5944006808258490372" target="_blank">discussion thread</a> in the LinkedIn group <i>Agile and Lean Software Development</i>, Claes Jonsson, a Continuous Deployment architect at TPG Objektfabriken in Sweden, asked this pertinent question:<br />
<blockquote class="tr_bq">
<i><u>How</u> is [assurance achieved] in an organization that is committed to delivering the right thing, with extremely high quality, minimal waste and with the shortest possible time to market using Lean Startup principles and Continuous Release practices? And do note that this does NOT mean unstructured, or disorganized, it instead relies on high organizational alignment, and extreme discipline.</i></blockquote>
<br />
The only way for an organization to preserve assurance – that is, manage risk – while becoming more Agile is to elevate people's knowledge. E.g., consider security: the process of having "gates" for security review is antithetical to Agile because gates impose risk management at discrete points instead of integrating it into the development process itself. But if you teach developers how to write secure code, then you don't need the gates anymore! The same thing applies to other areas of assurance.<br />
<br />
But wait: I am using a little bit of hyperbole here: gates are a form of oversight, and it is not really that you don’t need any kind of oversight – you do – but it takes a different form. In <a href="http://www.transition2agile.com/2014/12/real-agile-testing-in-large_8.html">Part 2</a> of this article we talked about how the concept of test coverage, and the role that a quality assurance (QA) function might play in an Agile setting. We explained that an Agile form of QA is still independent, but that it works alongside a development team – not as a gated phase. Again, Morticia’s website probably doesn’t need such a setup, but the EFT management portal probably does: you need to make a judgment about how much independent quality oversight is necessary to properly manage all of the risks in your project or program. Agile is about transparently and collaboratively making those kinds of judgments – not blindly following a plan or procedure.<br />
<br />
Many large organizations utilize gated software development processes due to historical reasons. These “gates” typically include a review phase for things such as security and regulatory compliance adherence. What we find when working with these organizations – and this is different from small companies and startups – is that the gates are used in lieu of conversations about how the software will meet compliance requirements: i.e., the transparent and collaborative discussions about what process to use for the project do not take place. By shifting to a culture of learning through conversations, gated processes can eventually be reduced to a few minimal stages or eliminated entirely.<br />
<br />
<div style="text-align: right;">
<span style="color: #d9ead3;"><span style="font-size: large;"><i><b>There is an artificial comfort in gated processes. </b></i></span></span></div>
<br />
There is an artificial comfort in gated processes: one feels secure because the gates are in place, but the comfort is naïve because the gates do not address the underlying reason the gates were created in the first place: that those who are building systems either do not know how to implement the compliance and risk management requirements, or they are not testing sufficiently for these things. Learning organizations move past this dilemma by ensuring that there is a much broader understanding of the requirements and how to test for them.<br />
<br />
Agile transformation is really about systematically creating a learning organization. You have to identify the things that people need to know, and make sure that there are people who know those things embedded in the development process, by creating a system for people to learn and share that knowledge (<a href="http://www.transition2agile.com/2014/10/how-to-rapidly-infuse-technical.html">here</a> is one approach). Ideally, everyone knows everything, but that is not practical, so there is a balance that needs to be achieved between specialists and generalists. But all need to be involved in real time or near real time.<br />
<br />
The chart at the end of this article lists some of the things that each part of the IT organization will need to learn. As you can see, it is a-lot, and that is why <i>learning</i> – not process re-engineering – is the “long pole in the tent” for Agile transformation. Learning is one of the <i>first steps</i> on the long road of changing to an Agile culture.<br />
<h2>
<span style="font-size: x-large;">Conclusions</span></h2>
Morticia’s website and the EFT Management Portal are two extremes – as business systems go. Most business applications are somewhere inbetween. That is why there is no single answer to how one should plan and execute testing under Agile.<br />
<br />
Trust the team – that works fine for Morticia’s website. Top down planning – quite a bit of that is needed for the EFT Management Portal, although we try to approach it in an Agile way by putting the team in the driver’s seat, by keeping the documentation light, by allowing things to evolve, to a degree, by doing testing repeatedly and with as much automation as possible, and by implementing a learning strategy built around coaching to help teams to learn what they need to know to address all of the things that need to be tested.<br />
<br />
In the case of the EFT Management Portal we also found that external parties demand – have a right to – oversight, and their risk management team will want to talk to our development leaders – hence we need to have development team leaders if only for the purpose of interfacing to these risk management folks – and the risk management folks will want to review our testing strategies and the ways that we measure test coverage. They will also be watching closely when our first release is deployed for demonstration: by that time, we should have already tested the application at scale in our cloud based test environment and so we should know what the outcome will be – there should be no surprises – but the first release is still a major visible milestone, even if it is not a production release, and people’s credibility rides on it to a large degree.<br />
<br />
The fact that credibility rides on a first release is cultural – but it is also human, and to a large extent independent of culture – and so even though Agile encourages tolerance for failure, that has its limits: the idea is to fail <i>early</i> to learn so that you do <u><i>not</i></u> fail when it counts and everyone is watching – including the risk management people who are tasked with finding out if you know what you are doing. Testing is Agile’s primary tool for ensuring <i>early</i> failure (feedback), so it is crucial to do the early planning needed to make sure that testing is thorough.<br />
<br />
One sign that your organization is embracing early contained failure as a strategy for ensuring long term success is when teams start using demonstrations as a way of “proving” that compliance requirements are met. Teams often look forward to being able to do this. This then continues to strengthen trust within the organization. The more an organization implicitly trusts its teams, the less process rigor is needed – but this will only occur if continual learning is implemented as a strategic way of ensuring that the teams have and continue to have the knowledge that they need.<br />
<br />
Authors (alphabetically):<br />
<a href="https://www.linkedin.com/profile/view?id=8110952" target="_blank">Scott Barnes</a><br />
<a href="https://www.linkedin.com/in/cliffberg" target="_blank">Cliff Berg</a><br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhaz5UkGbs1nicsm-CVqO0Td54r7wUB6iqYDNfotquSdBORSF0t054mOaPcsx5NJsxoQJnc8q2Q-l2xgQj0oCutmx51kFwrWDveKqGWM5ALa8tUZlRK_v91-_gI68ZibqkdRPVmT1PVJb7O/s1600/Learning_Required_For_Agile_Test_Transformation.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhaz5UkGbs1nicsm-CVqO0Td54r7wUB6iqYDNfotquSdBORSF0t054mOaPcsx5NJsxoQJnc8q2Q-l2xgQj0oCutmx51kFwrWDveKqGWM5ALa8tUZlRK_v91-_gI68ZibqkdRPVmT1PVJb7O/s1600/Learning_Required_For_Agile_Test_Transformation.jpg" height="480" width="640" /></a></div>
<span style="font-size: x-small;">As <a href="https://drive.google.com/file/d/0By4lfBwI0rt6SEhCZ3BSMU9nNGM/view?usp=sharing" target="_blank">PDF</a>.</span><br />
<br />Cliff Berghttp://www.blogger.com/profile/02103767196153470434noreply@blogger.com0tag:blogger.com,1999:blog-8391404601343318983.post-74739245346238058652014-12-22T09:40:00.001-05:002015-01-09T08:29:12.403-05:00Real Agile Testing, In Large Organizations – Part 3(Continued from <a href="http://www.transition2agile.com/2014/12/real-agile-testing-in-large_8.html">Part 2</a>)<br />
<br />
<h2>
<span style="font-size: x-large;">What about TDD and unit testing?</span></h2>
As promised, let’s talk about how <a href="https://en.wikipedia.org/wiki/Test-driven_development" target="_blank">Test-Driven Development</a> (TDD) fits into the over testing regime that we have been presenting.<br />
<br />
TDD is a powerful technique for achieving high coverage <a href="https://en.wikipedia.org/wiki/Unit_testing" target="_blank">unit tests</a> and code with low coupling. TDD is a complex issue and there is <a href="http://martinfowler.com/articles/is-tdd-dead/" target="_blank">quite a bit of controversy around it</a>, so we will not take sides here. TDD is <i>absolutely not a mandatory or necessary practice of Agile</i>, but many very smart people swear by it, so be your own judge. It is even possible that TDD works for certain personality types and styles of thinking: TDD is an inherently <a href="https://en.wikipedia.org/wiki/Inductive_reasoning" target="_blank">inductive process</a>, whereas top-down test design is a <a href="https://en.wikipedia.org/wiki/Deductive_reasoning" target="_blank">deductive process</a>, and so TDD possibly reflects a way of thinking that is natural for its proponents. (See also <a href="https://en.wikipedia.org/wiki/Top-down_and_bottom-up_design" target="_blank">this discussion</a> of top-down versus bottom-up design. The book <i><a href="https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar" target="_blank">The Cathedral and the Bazaar</a></i> also discusses the tension between top-down and bottom up design and development.)<br />
<br />
The controversy between top-down and bottom-up approaches – and the personalities that are attracted to each – might even have analogy to the <a href="http://blogs.scientificamerican.com/the-curious-wavefunction/2013/06/03/popular-physics-is-there-an-experimentalist-in-the-house/" target="_blank">well known division in the sciences</a> between those who are <i>theorists</i> and those who are <i>experimentalists</i> at heart: these two camps never seem to see eye-to-eye, but they know that they need each other. Thus, instead of getting into the TDD or no-TDD debate, we will merely explain TDD’s place in an overall testing approach, and a few things to consider when deciding whether to use it or not. Most importantly: do not let proponents of TDD convince you that TDD is a necessary Agile practice, or that teams that do not use TDD are inherently less “advanced”. These assertions are not true: TDD is a powerful design and test strategy, but there are other competing strategies (e.g., <a href="https://en.wikipedia.org/wiki/Object-oriented_analysis_and_design" target="_blank">object-oriented analysis and design</a>, <a href="https://en.wikipedia.org/wiki/Functional_design" target="_blank">functional design</a> – both of which are completely compatible with Agile – and many others).<br />
<br />
TDD operates at a unit test level (i.e., on individual code units or methods) and does not replace acceptance tests (including paradigms such as <a href="https://en.wikipedia.org/wiki/Acceptance_test-driven_development" target="_blank">acceptance test-driven development</a> (ATDD) and <a href="https://en.wikipedia.org/wiki/Behavior-driven_development" target="_blank">behavior-driven development</a> (BDD)), which operate at a feature (aka story, or scenario) level. Unit testing is what most programmers do when they write their own tests for the methods and components that they write – regardless of whether or not they use TDD. Unit testing is also well suited for testing “failure mode” requirements such as that bad data should not crash the system. Used in conjunction with TDD and a focus on failure modes, failure mode issues can be resolved far sooner which is certainly very Agile.<br />
<br />
Acceptance level testing is still critically important. Unit testing cannot replace acceptance tests, because <i>one of the most important reasons for acceptance tests is to check that the developer’s understanding of the requirements is correct</i>. If the developer misunderstands the requirements, and the developer writes the tests, then the tests will reflect that misunderstanding, yet the tests will pass! Separate people need to write a story’s acceptance tests and the story’s implementation. Therefore, TDD is a technique for improving test coverage and improving certain code attributes, and many see it as an approach to design – but it is not a replacement for acceptance tests.<br />
<br />
<div style="text-align: right;">
<span style="color: #f1c232;"><span style="font-size: large;"><i><b>One type of unit level testing that is very important,</b></i></span></span></div>
<div style="text-align: right;">
<span style="color: #f1c232;"><span style="font-size: large;"><i><b>regardless of TDD, is interface level testing.</b></i></span></span></div>
<br />
One type of unit level testing that is very important, regardless of TDD, is interface level testing. Complex systems usually have tiers or subsystems, and it is very valuable to have high coverage test suites at these interfaces. In the TDD world, such an interface is nothing special: it is merely a unit test on those components. In a non-TDD world, it is viewed as an interface regression test and one specifically plans for it. For example, a REST based Web service defines a set of “endpoints” that are essentially remote functions, and those functions define a kind of façade interface for access to the server application. There should be a comprehensive test suite at that interface, even if there are user level (e.g., browser based, using Selenium) acceptance tests. The reason is that the REST interface is a reusable interface in its own right, and is used by many developers, so changes to it have a major impact. Leaving it to the user level tests to detect changes makes it difficult to identify the source of an error. In this scenario <a href="https://en.wikipedia.org/wiki/Mock_object" target="_blank">mocking</a> is often the most advantageous way of unit level testing interfaces.<br />
<br />
Another, much more important reason to have high coverage tests on each major interface is that the user level tests might not exercise the full range of functionality of the REST interface – but the REST level tests should, so that future changes to the user level code will not access new parts of the REST interface that have not been tested yet – long after the REST code has been written. The REST interface can also be tested much more efficiently, without having to run them in a browser. In fact, the performance tests will likely be performed using that interface instead of the user level interface.<br />
<br />
Detection of change impact, at a component level, is in fact one of the arguments for Unit Testing (and TDD): if a change causes a test to fail, the test is right at the component that is failing. That helps to narrow down the impact of changes. The cost of that, however, is maintaining a large set of tests, which introduce a kind of impedance to change. Be your own judge on the tradeoff.<br />
<br />
TDD can also impact the group process: it is generally not feasible in a shared code ownership environment to have some people using TDD and others not. Thus, TDD really needs to be a team-level decision.<br />
<br />
<div style="text-align: right;">
<span style="color: #f1c232;"><span style="font-size: large;"><i><b>It is possible that the preference (or not) for TDD</b></i></span></span></div>
<div style="text-align: right;">
<span style="color: #f1c232;"><span style="font-size: large;"><i><b>should be a criteria in assembling teams.</b></i></span></span></div>
<br />
Legacy code maintenance is often a leading challenge when it comes to unit testing. TDD helps greatly to identify the impact when changes are made to an existing code base, but at the cost of maintaining a large body of tests, which can impede refactoring. Another example of a real challenge to utilizing TDD techniques is <a href="https://www4.in.tum.de/~schaetz/papers/SchaetzPretschnerHuberPhillips.pdf" target="_blank">model-based development</a> (see also this <a href="http://www.mathworks.com/model-based-design/" target="_blank">MathWorks summary</a>) – often used today for the design of real time software e.g., in embedded controllers, using tools such as <a href="http://www.mathworks.com/products/simulink/" target="_blank">Simulink</a>. These techniques are used because of the extremely high reliability of the generated code. There are ways of applying TDD in this setting (such as writing .m scripts for Simulink tests), but that is not a widespread practice. Acceptance Test Driven Development (ATDD) is potentially a better approach when using model-based development.<br />
<br />
Finally, TDD seems to favor certain types of programmers over others. By adopting TDD, you might enable some of your team to be more effective, but you might also hinder others. It is therefore possible that the preference (or not) for TDD should be a criteria in assembling teams. Making an organization-wide decision, however, might be a mistake, unless you intend to exclude deductive thinkers from all of your programming teams.<br />
<br />
The jury is still out on these issues, so you will have to use your own judgment: just be sure to allow for the fact that people think and work differently – from you. Do not presume that everyone thinks the way that you do. Do not presume that if you have found TDD to be effective (or not), that everyone else will find the same thing after trying it for long enough.<br />
<h2>
<span style="font-size: x-large;">Some other types of testing</span></h2>
There are still many types of testing that we have not covered! And all are applicable to Agile teams!<br />
<br />
<h3>
Disaster Recovery</h3>
In our EFT management portal example (see <a href="http://www.transition2agile.com/2014/12/real-agile-testing-in-large.html">Part 1</a>), the system needed to be highly secure and reliable, comply with numerous laws, and our development process must satisfy Sarbanes Oxley laws and the information demands of an intrusive oversight group. Most likely, there is also a “continuity” or “disaster recovery” requirement, in which case there will have to be an entire repeatable test strategy for simulating a disaster with failover to another set of systems in another data center or another cloud provider. That is one case where a detailed test plan <u><i>is</i></u> needed: for testing disaster recovery. However, one could argue that such a plan could be developed incrementally, and tried in successive pieces, instead of all at once.<br />
<br />
<h3>
Security</h3>
Nowadays, security is increasingly being addressed by enumerating “controls” according to a security control framework such as <a href="http://csrc.nist.gov/groups/SMA/fisma/controls.html" target="_blank">NIST FISMA Security Controls</a>. For government systems, this is mandatory. This used to be executed in a very document-centric way, but increasingly it is becoming <a href="http://www.nist.gov/manuscript-publication-search.cfm?pub_id=916095" target="_blank">more real time</a>, with security specialists working with teams on a frequent basis – e.g., once per iteration – to review controls. Most of the controls pertain to tools and infrastructure, and can be addressed through adding scanning to some of the CI/CD pipeline scripts, to be run a few times per iteration. These scans check that the OSes are hardened and that major applications such as Apache are hardened. In addition, the security folks will want to verify that the third party components in the project binary artifact repository (Nexus, etc.) are “approved” – that is, they have been reviewed by security experts, are up to date, and do not pose a risk. All this can be done using tools without knowing much about how the application actually works.<br />
<br />
<div style="text-align: right;">
<span style="color: #f1c232;"><span style="font-size: large;"><i><b>Unfortunately, we cannot test for</b></i></span></span></div>
<div style="text-align: right;">
<span style="color: #f1c232;"><span style="font-size: large;"><i><b>careful secure design: we can only build it in.</b></i></span></span></div>
<br />
However, some controls pertain to application design and data design. These are the hard ones. Again, for Morticia’s website (see <a href="http://www.transition2agile.com/2014/12/real-agile-testing-in-large.html">Part 1</a>), we don’t need to worry about that. But for the other end of the spectrum, where we know that we are a juicy target for an expert level attack – such as what occurred for <a href="http://krebsonsecurity.com/2014/05/the-target-breach-by-the-numbers/" target="_blank">Target</a>, <a href="http://www.wsj.com/articles/home-depot-breach-bigger-than-targets-1411073571" target="_blank">Home Depot</a>, and <a href="http://www.forbes.com/sites/thomasbrewster/2014/12/12/195-security-incidents-sony-pictures-hack/" target="_blank">Sony Pictures</a> in the past 12 months – we have no choice but to assume that very smart hackers will make protracted attempts to find mistakes in our system or cause our users to make mistakes that enable the hackers to get in. To protect against that, scanning tools are merely a first step – a baby step. The only things that really work are a combination of,<br />
1. Careful secure design.<br />
2. Active monitoring (intrusion detection).<br />
<br />
Unfortunately, we cannot test for careful secure design: we can only build it in. To do that, <i>we as developers need to know secure design patterns</i> – compartmentalization, least privilege, privileged context, and so on. For monitoring, all large organizations have monitoring in place, but they need the development team’s help in identifying what kinds of traffic are normal and what are not normal – <i>especially at points of interconnection to third party or partner systems</i>. Teams should conduct threat modeling, and in the process identify the traffic patterns that are normal and those that might signify an attack. This information should be passed to the network operations team. Attacks cannot be prevented, but they can often be stopped while they are in progress – before damage is done. To do that, the network operations team needs to know what inter-system traffic patterns should be considered suspicious.<br />
<br />
<h3>
Compliance with laws</h3>
Compliance with laws is a matter of decomposing the legal requirements and handling them like any other – functional or non-functional, depending on the requirement. However, while it is important for all requirements to be traceable (identifiable through acceptance criteria), it is absolutely crucial for legal compliance requirements. Otherwise, there is no way to “demonstrate” compliance, and no way to prove that sufficient diligence was applied in attempting to comply.<br />
<br />
<h3>
Performance testing</h3>
There are many facets to performance testing. If you are doing performance testing at all, four main scenario types are generally universal:<br />
1. Normal usage profile.<br />
2. Spike profile.<br />
3. Break and “soak” test.<br />
4. Ad-hoc tests.<br />
<br />
Normal usage includes low and high load periods: the goal is to simulate the load that is expected to occur over the course of normal usage throughout the year. Thus, a normal usage profile will include the expected peak period loads. One can usually run normal load profile tests for, say, an hour – this is not long duration testing. It is also not up-time testing.<br />
<br />
The purpose of spike testing is to see what happens if there is an unusual load transient: does the system slow down gracefully, and recover quickly after the transient is over? Spike testing generally consists of running an average load profile but overlaying a “spike” for a brief duration, and seeing what happens during and after the spike.<br />
<br />
Break testing is seeing what happens when the load is progressively increased until the system fails. Does it fail gracefully? This is a failure mode, and will be discussed further below. Soak testing is similar, in that lots of load is generated for a long time, to see if the system starts to degrade in some way.<br />
<br />
The last category, “ad-hoc tests”, are tests that are run by the developers in order to examine the traffic between internal system interfaces, and how that traffic changes under load. E.g., traffic between two components might increase but traffic between two others might not – indicating a possible bottleneck between the first two. Performing these tests requires intimate knowledge of the system’s design and intended behavior, and these tests are usually not left in place. However, these tests often result in monitors being designed to permanently monitor the system’s internal operation.<br />
<br />
In an Agile setting, performance tests are best run in a separate performance testing environment, on a schedule, e.g., daily. This ensures that the results are available every day as code changes, and that the tests do not disrupt other kinds of testing. Cloud environments are perfect for load testing, which might require multiple load generation machines to generate sufficient load. Performance testing is usually implemented as a Jenkins task that runs the tests on schedule.<br />
<br />
<h3>
Testing for resiliency</h3>
Acceptance criteria are usually “happy path”: that is, if the system does what is required, then the test passes. Often a few “user error” paths are thrown in. But what should happen if something goes wrong due to input that is not expected, or due to an internal error – perhaps a transient error – of some kind? If the entire system crashes when the user enters invalid input or the network connection drops, that is probably not acceptable.<br />
<br />
Failure modes are extremely important to explicitly test for. For example, suppose Morticia’s website has a requirement,<br />
<blockquote class="tr_bq">
<span style="font-family: "Courier New",Courier,monospace;">Given that I am perusing the product catalog,<br />When I click on a product,<br />Then the product is added to my shopping cart.</span></blockquote>
<br />
But what happens if I double-click on a product? What happens if I click on a product, but then hit the Back button in the browser? What happens if someone else clicks on that product at the same instant, causing it to be out of stock? You get the idea.<br />
<br />
Generally, there are two ways to address this: on a feature/action basis, and on a system/component basis. The feature oriented approach is where outcomes based story design comes into play: thinking through the failure modes when writing the story. For example, for each acceptance scenario, think of as many situations that you can about what might go wrong. Then phrase these as additional acceptance criteria. You can nest the criteria if you like: languages like <a href="http://cukes.info/gherkin.html" target="_blank">Gherkin</a> support scenario nesting and parameterized tables to help you decompose acceptance criteria into hierarchical paths of functionality.<br />
<br />
Testing for resiliency on a component basis is more technical. The test strategy should include intentional disruptions to the physical systems with systems and applications highly instrumented, to test that persistent data is not corrupted and that failover occurs properly with minimal loss of service and continuing compliance with SLAs. Memory leaks should be watched for by running the system for a long time under load. Artifacts such as exceptions written to logs should be examined and the accumulation of temporary files should be watched for. If things are happening that are not understood, the application is probably not ready for release. Applying Agile values and principles to this, this type of testing should be developed from the outset, and progressively made more and more thorough.<br />
<br />
<div style="text-align: right;">
<span style="color: #f1c232;"><span style="font-size: large;"><i><b>Concurrency testing is a special case of functional testing.</b></i></span></span></div>
<br />
Driving the system to failure is very important for high reliability systems. The intention is to ensure that the system <i>fails gracefully</i>: that it fails gradually – not catastrophically – and that there is no loss or corruption of persistent data and no loss of messages that are promised to be <a href="http://www.eaipatterns.com/DurableSubscription.html" target="_blank">durable</a>. Transactional databases and durable messaging systems are designed for this, but many web applications do not perform their transactions correctly (multiple transactions in one user action) and are vulnerable to inconsistency if a user action only partially completes. Tests should therefore check that as the system fails under load, nothing “crashes”, and each simulated update request that failed does not leave artifacts in the databases or file system, and as the system recovers, requests that completed as the system was failing do not get performed twice.<br />
<br />
<a href="https://en.wikipedia.org/wiki/Concurrent_testing" target="_blank">Concurrency testing</a> is a special case of functional testing, but it is often overlooked. When I (Cliff) was CTO of <a href="http://www.prnewswire.com/news-releases/digital-focus-celebrates-strong-growth-at-fifth-anniversary-with-300-percent-revenue-increase-76125542.html" target="_blank">Digital Focus</a> (<a href="http://investing.businessweek.com/research/stocks/private/snapshot.asp?privcapId=121052" target="_blank">acquired</a> by Command Information in 2006) we used to put our apps in our performance lab when the developers thought that the apps were done. (We should have done it sooner.) We generally started to see new kinds of failures at around ten concurrent simulated users, and then a whole new set of failures at around 100 concurrent users. The first group – at around ten users – generally were concurrency errors. The second group had to do with infrastructure: TCP/IP settings and firewalls.<br />
<br />
Regarding the first group, these are of the kind in which, say, a husband and wife have a joint bank account, and the husband accesses the account from home and the wife accesses it from her office, and they both update their account info at the same time. What happens? Does the last one win – with the other one oblivious that his or her changes were lost? Do the changes get combined? Is there an error? These conditions need to be tested for, because these things <i>will happen</i> under high volume use, and they will result in customer unhappiness and customer support calls. There need to be test scenarios written, with acceptance criteria, for all these kinds of failure mode scenarios. These should be run on a regular basis, using a simulated light load of tens of users, intentionally inducing these kinds of scenarios. This is <i>not performance testing</i> however: it is <i>functional</i> testing, done with concurrent usage.<br />
<h2>
<span style="font-size: x-large;">Is all this in the Definition of Done?</span></h2>
The <a href="http://guide.agilealliance.org/guide/definition-of-done.html" target="_blank">definition of done</a> (DoD) is an important Agile construct in which a team defines what it means for a story – any story – to be considered done. Thus, the DoD is inherently a <i>story level</i> construct. That is, it is for acceptance criteria that are written for stories. DoD is not applicable to system-wide acceptance criteria, such as performance criteria, security criteria, general legal compliance criteria that might apply to the implementation of many stories, etc.<br />
<br />
It is not practical to treat every type of requirement as part of the DoD. For example, if one has to prove performance criteria for each story, then the team could not mark off stories as complete until the performance tests are run, and each and every story would have to have its performance measured – something that is generally not necessary: typically a representative set of user actions are simulated to create a performance load. Thus, non-functional requirements or system-wide requirements are best not included in the DoD. This is shown in Figure 1 of <a href="http://www.transition2agile.com/2014/12/real-agile-testing-in-large.html">Part 1</a>, where a story is checked “done” after the story has passed its story level acceptance tests, has not broken any integration tests, and the user has tried the story in a demo environment and agrees that the acceptance criteria have been met. Ideally, this happens <i>during</i> an iteration – not at the end – otherwise, nothing gets marked as “done” until the end of an iteration. Thus, marking a story as “done” is tentative because that decision can be rejected by the Product Owner during the iteration review, even if a user has tried the story and thought that it was done. Remember that the Product Owner represents many stakeholders – not just the users.<br />
<br />
Another technique we use with larger sets of teams (think portfolio) – and especially when there are downstream types of testing (e.g., hardware integration testing) – is <b><i>definition of ready</i></b> (DoR). The state of “ready” is a precursor to the state of being “done”. This helps to ensure that the DoD – which might include complex forms of testing – can be met by the team. The team first ensures that a story meets the DoR. These are other criteria such as that the story has acceptance criteria (DoD would say the acceptance criteria have been met), certain analysis have be completed, etc. – just enough so that development and testing have a much higher likelihood of being completed within an iteration. This works with teams and programs of all sizes. We do find that for larger programs, the DoR is almost always very useful. Defining a DoR with the Product Owner is also a great way of engaging the Product Owner on non-functional issues to increase their understanding of those issues and ensure the team is being fed high quality stories.<br />
<h2>
<span style="font-size: x-large;">End Of Part 3</span></h2>
Next time in <a href="http://www.transition2agile.com/2015/01/real-agile-testing-in-large.html">Part 4</a> we will connect the dots on the organizational issues of all this!<br />
<br />
<br />
Authors (alphabetically):<br />
<a href="https://www.linkedin.com/profile/view?id=8110952" target="_blank">Scott Barnes</a><br />
<a href="https://www.linkedin.com/in/cliffberg" target="_blank">Cliff Berg</a>Cliff Berghttp://www.blogger.com/profile/02103767196153470434noreply@blogger.com1tag:blogger.com,1999:blog-8391404601343318983.post-55102718052263910152014-12-08T19:52:00.000-05:002015-01-09T08:28:33.437-05:00Real Agile Testing, In Large Organizations – Part 2(Continued from <a href="http://www.transition2agile.com/2014/12/real-agile-testing-in-large.html">Part 1</a>)<br />
<br />
Last time we saw that there is <i>no single answer</i> to the level of test planning needed for Agile projects – it depends!<br />
<br />
We also remembered that the <i>whole point</i> of testing is to achieve an acceptable level of assurance that the system meets the <i>actual</i> business need – in <i>every way that matters to the organization</i>.<br />
<br />
This time we will look at a kind of template for the pieces of an Agile test strategy. You can then add and subtract from this template for your own project – and perhaps even dispense with it altogether for a very simple project – but in that case it at least provides food for thought.<br />
<br />
<h2>
<span style="font-size: x-large;">What about technical stories?</span></h2>
Many teams use “technical stories” to specify non-functional requirements. This is ok, except that these are not really stories: you never finish them – they are actually cross-functional acceptance criteria. But casting non-functional requirements as acceptance criteria does not work perfectly either: that means that no story is done until all of the non-functional criteria are done, and that is not a practical way to run an iteration.<br />
<br />
<div style="text-align: right;">
<span style="color: #d9d2e9;"><span style="font-size: large;"><b><i>Create a “theme” for each type of</i></b></span></span></div>
<div style="text-align: right;">
<span style="color: #d9d2e9;"><span style="font-size: large;"><b><i>non-functional requirement.</i></b></span></span></div>
<br />
Thus, while the above approaches can work, it is often better to treat non-functional requirements as just that: requirements. Don’t try to fit that round peg into the story square hole. Instead, create a “<a href="https://www.scrumalliance.org/community/spotlight/mike-cohn/march-2014/agile-user-stories-epics-and-themes" target="_blank">theme</a>” for each type of non-functional requirement, e.g., “performance”, “security”, etc., with <i>theme level</i> acceptance criteria – i.e., requirements! Then write stories for the work that needs to be done; but <i>do not skip creating a strategy for how to test the requirements for each of these themes</i>. A strategy (high level plan) is needed too, in order to think through the non-functional testing and other activities in an end-to-end manner. This is a strategy that the team should develop. The strategy is the design for the testing aspects of the release train. Without it, you will find it difficult to discuss testing issues and dependencies that arise during testing, because there will be no conceptual context, and you will also find it difficult to communicate the testing strategies to stakeholders.<br />
<br />
<div style="text-align: right;">
<span style="color: #d9d2e9;"><span style="font-size: large;"><i><b>You can define exploratory testing activities<br />that provide feedback to the application’s monitoring theme. </b></i></span></span></div>
<br />
There is a side benefit. If you treat the testing pipeline as a system, then you are in a good position to identify ways to monitor the application. For example, exploratory performance testing will reveal bottlenecks, and the application can then be enhanced to monitor those bottlenecks during operation of the system. Monitoring platforms such as <a href="http://sensuapp.org/" target="_blank">Sensu</a> can be used to consolidate the monitors across the many components of the application. Thus, in your testing strategy, you can define exploratory testing activities that provide feedback to the application’s monitoring theme, resulting in stories pertaining to operational monitoring. Identifying this ahead of time – at a large grain level – is important for making sure that this type of work is not a surprise to the Product Owner and that it receives sufficient priority. The key is to treat the testing pipeline as an <a href="https://en.wikipedia.org/wiki/Aspect_%28computer_programming%29" target="_blank"><i>aspect</i></a> of the development pipeline, and design it with feedback loops, minimum latency, and sufficient coverage of each requirement category.<br />
<br />
<div style="text-align: right;">
<span style="color: #d9d2e9;"><span style="font-size: large;"><b><i>The key is to treat the testing pipeline as an <u>aspect</u></i></b></span></span></div>
<div style="text-align: right;">
<span style="color: #d9d2e9;"><span style="font-size: large;"><b><i>of the development pipeline.</i></b></span></span></div>
<br />
<h2>
<span style="font-size: x-large;">The What, Why, Where/When, How/Who, and Coverage</span></h2>
Let’s look at the What, Why, Where, When, How/Who, and Coverage.<br />
<br />
The “<b>What</b>” is the category of testing, such as “functional acceptance testing”, “performance testing”, or “exploratory testing”. If you like, these can be grouped together according to the “<a href="http://lisacrispin.com/2011/11/08/using-the-agile-testing-quadrants/" target="_blank">testing quadrants</a>”.<br />
<br />
The “<b>Why</b>” is the aspect of requirements that this type of testing is intended to address, such as “story acceptance criteria”, “system-wide performance requirements”, or “anomaly identification”.<br />
<br />
The “<b>Where</b>” is the environment(s) in which the testing will occur. In a CI/CD process, most types of testing will occur in multiple environments (as shown in Figure 1), but not necessarily all – e.g., in the example shown in Figure 1, performance testing is only being done in the “SCALE” environment. Your test strategy should reference a table or information radiator depicting all of the identified test environment types.<br />
<br />
The “<b>When</b>” is the event(s) that will trigger the testing, and the frequency if the triggering event is calendar or time based. (Examples are shown in Table 1.) The “How” is the strategy to be used for those types of tests, such as “Use JBehave/Java, Selenium”, or “Use JMeter in cloud instances”.<br />
<br />
The “<b>How</b>” should include “<b>Who</b>” – i.e., who will do what: that is, who will write the tests, who will perform them if there are manual tests, etc.<br />
<br />
<div style="text-align: right;">
<span style="color: #d9d2e9;"><span style="font-size: large;"><i><b>The Where/When and How/Who are</b></i></span></span></div>
<div style="text-align: right;">
<span style="color: #d9d2e9;"><span style="font-size: large;"><i><b>especially important if you interface with</b></i></span></span></div>
<div style="text-align: right;">
<span style="color: #d9d2e9;"><span style="font-size: large;"><i><b>specialized “enterprise” testing functions.</b></i></span></span></div>
<br />
The Where/When and How/Who columns are especially important if you interface with specialized “enterprise” testing functions of any kind, e.g., Security, Performance Testing, Independent Acceptance Testing, etc.: you want to integrate these groups in an Agile “pipeline” manner <i>so that no one is ever waiting on anyone</i>, and that requires that everyone have a very clear idea of what everyone will be doing and when.<br />
<br />
<div style="text-align: right;">
<span style="color: #d9d2e9;"><span style="font-size: large;"><i><b>Integrate these groups in an Agile “pipeline” manner</b></i></span></span></div>
<div style="text-align: right;">
<span style="color: #d9d2e9;"><span style="font-size: large;"><i><b>so that no one is ever waiting on anyone.</b></i></span></span></div>
<br />
Table 1: Sample lines of a test strategy table.<br />
<table style="border-collapse: collapse; border: 1px solid black; padding: 0px;"><tbody>
<tr><td style="border: 1px solid black;"><b>What</b></td><td style="border: 1px solid black;"><b>Why</b></td><td style="border: 1px solid black;"><b>Where, When</b></td><td style="border: 1px solid black;"><b>How (Strategy), Who</b></td><td style="border: 1px solid black;"><b>Coverage</b><br />
<b>1. How measured;</b><br />
<b>2. How assessed;</b><br />
<b>3. Sufficiency</b></td></tr>
<tr><td style="border: 1px solid black;">Functional acceptance testing</td><td style="border: 1px solid black;">Story acceptance criteria</td><td style="border: 1px solid black;">• LOCAL (Workstation or personal cloud). Continually.<br />
• Cloud “CI”. When code pushed.<br />
• Cloud TEST. Daily.</td><td style="border: 1px solid black;">Use JBehave/Java, Selenium.<br />
<br />
Acc test programmer must <i><u>not</u></i> be the story programmer.</td><td style="border: 1px solid black;">• How meas: Cobertura.<br />
• How asses: Use Gherkin executable test specs, to ensure that no acc crit are missed.<br />
• Reqd: Need 100% coverage.</td></tr>
<tr><td style="border: 1px solid black;">Performance testing</td><td style="border: 1px solid black;">System-wide performance requirements</td><td style="border: 1px solid black;">• “PERF” (in cloud). Nightly.</td><td style="border: 1px solid black;">Use JMeter in cloud instances.<br />
Perf test team and architect.</td><td style="border: 1px solid black;">QA will verify coverage of executable test specs.</td></tr>
<tr><td style="border: 1px solid black;">Exploratory</td><td style="border: 1px solid black;">To detect unanticipated anomalies</td><td style="border: 1px solid black;">• DEMO. Any time.</td><td style="border: 1px solid black;">Manual. Anyone who volunteers – but not the story’s programmer.</td><td style="border: 1px solid black;">Amount of time/effort should be indicated by the story.</td></tr>
</tbody></table>
<br />
The final column, “Coverage”, is really about thoroughness. It has three parts: (1) how test coverage will be measured, (2) how coverage will be assessed, and (3) what level of coverage is considered to be sufficient. This gets into an important issue for testing: How do you know when you are done testing? How do you know how much testing is enough?<br />
<br />
<h2>
<span style="font-size: x-large;">How much testing is enough?</span></h2>
In a traditional waterfall development setup, there is often a separate Quality Assurance (QA) function that independently assesses whether the test plan is adequate. This is usually implemented as a gate, such that the QA performs its assessment after the application has been tested. That whole approach is a non-starter for Agile projects – and even more so for <a href="https://en.wikipedia.org/wiki/Continuous_delivery" target="_blank">continuous delivery</a> (CD) – where working, tested software is produced frequently and can be deployed with little delay. But let’s not throw out the whole concept of QA – like “throwing the baby out with the bath water”. QA can play a vital role for Agile teams: independence.<br />
<br />
<div style="text-align: right;">
<span style="color: #d9d2e9;"><span style="font-size: large;"><i><b>QA can play a vital role for Agile teams: independence.</b></i></span></span></div>
<br />
My mother Morticia knows the people who are building her website: they are our cousins, and she trusts them implicitly. But the EFT Management Portal is another matter. In that case, an external technical auditor has been engaged to provide independent assessment. But what about inbetween situations? What about run-of-the-mill mission critical applications developed by most organizations? Should you just “trust the team”?<br />
<br />
<div style="text-align: right;">
<span style="color: #d9d2e9;"><span style="font-size: large;"><i><b>To “trust the team” is not to have blind trust.</b></i></span></span></div>
<br />
To answer that question, we need to clear up a common point of confusion. To “trust the team” is not to have blind trust: if there is a-lot at stake, then blind trust would be illogical and naïve. The Agile adage that one should “trust the team” does not mean to have blind trust: it means to give the team substantial (but not absolute) leeway to do the work in the way that it finds most effective. That does not relieve the team from explaining their processes, or from the responsibility to convince stakeholders that the processes (especially testing) will result in the required level of assurance. After all, some of those stakeholders are paying the bill – it’s <i>their</i> system.<br />
<br />
Self-directing teams are never without leadership and vision. Leaders need to ensure that teams have a clear understanding of the end goal (product) and why the business needs the product (vision). When vision and goals are clear, acceptance criteria and intent become much clearer. By producing what stakeholders have described and by being provided a clear set of goals and a vision for a product, teams typically are able to build significant trust with their stakeholders and the business. This trust continues and the team feels empowered.<br />
<br />
When clear goals and vision (leadership) are missing, there tend to be longer testing cycles because the testing starts to focus on ensuring the requirements are correct instead of ensuring the requirements are met.<br />
<br />
Another consideration is that teams are under great pressure to create features for the Product Owner. If the Product Owner will not have to maintain the application, then the Product Owner will not be very concerned with how maintainable the system is – that is “IT’s problem”. (When Product Owners fulfill the role because they are the responsible person for an application, they are much better within this role. When Product Owners are not responsible for the product because produced but are only responsible for delivery of a project, they are no longer Product Owners and are now back to Project Managers.) Further, the Product Owner will not have the expertise to ask about things such as “concurrency testing”, for checking that the application works correctly when multiple users try to update the same data. In fact, some software teams do not know too much about that either – so should you simply “trust the team”? Teams cannot always be staffed with all of the skills sets that are needed – resources might be constrained. These reasons are why organizations need independent trustworthy assessment of testing – as a second pair of eyes on whether the testing has been sufficient. It is just common sense.<br />
<br />
<div style="text-align: right;">
<span style="color: #d9d2e9;"><span style="font-size: large;"><i><b>Have QA work with the team on a <u>continuing basis</u> </b></i></span></span></div>
<div style="text-align: right;">
<span style="color: #d9d2e9;"><span style="font-size: large;"><i><b>– not as a “gate”.</b></i></span></span></div>
<br />
If we don’t implement QA as a gate, then how should we do it? The Agile way to do it is to have QA work with the team on a <i>continuing</i> basis, examining the team’s test strategies, spot checking actual testing code, and discussing the testing strategies with the various stakeholders to get their thoughts. QA should have a frequent ongoing presence as development proceeds, so that when the application is ready for release, no assessment is needed – it has already been done – and in fact it has been used to help the team to refine its approach to testing. QA effectively becomes an independent test on the testing process itself – a feedback loop on the testing feedback loop.<br />
<br />
How does QA decide how much testing is enough? I.e., how does QA decide what level of coverage is sufficient? That is a hard question. For functional testing there is a fairly straightforward answer: the organization should <i>start tracking the rate at which bugs are found in production</i>, and correlating that metric with the test coverage that was measured when the software was built. Over time, the organization will build a history of metrics that can provide guidance about how much coverage is effective in preventing production bugs – with sufficient assurance for that type of application.<br />
<br />
In the previous article we mentioned that story development should include analysts, developers and testers: that one should consider testing strategy as an output of each story’s development, since each story might have unique testing requirements. We have found it very effective when testing or QA teams contribute to that discussion, so that the test plan evolves during the story writing rather than after software has been produced. The testers help write acceptance criteria during the story writing sessions. One of the great advantages of this is that the developer knows exactly how the story will be testing, thus helping implementation direction.<br />
<br />
<div style="text-align: right;">
<span style="color: #d9d2e9;"><span style="font-size: large;"><i><b>Accumulate operational robustness metrics</b></i></span></span></div>
<div style="text-align: right;">
<span style="color: #d9d2e9;"><span style="font-size: large;"><i><b>over time and use those to inform judgment</b></i></span></span></div>
<div style="text-align: right;">
<span style="color: #d9d2e9;"><span style="font-size: large;"><i><b>about the level of testing that is needed.</b></i></span></span></div>
<br />
This is a little harder to do for other kinds of requirements, e.g., security requirements, performance requirements, maintainability requirements, and so on, but the concept is the same: accumulate operational robustness metrics over time and use those to inform judgment about the level of testing that is needed. We suggest that leveraging architectural themes will help teams keep an eye on key issues such as these.<br />
<br />
Back to the table’s “<b>Coverage</b>” column. Consider the example for functional tests shown as row one in the table: we specify Cobertura for #1 (measuring coverage). But Cobertura checks code paths traversed: it does not check that you have actually coded everything that needs to be tested. Thus, #2 should be something like, “Express story level acceptance criteria directly in JBehave Gherkin”. That ensures that nothing gets left out. In other words, we will be using “executable test specs”, or “<a href="https://en.wikipedia.org/wiki/Behavior-driven_development#Behavioural_specifications" target="_blank">behavioral specifications</a>”. Finally, as to what coverage is sufficient, we might specify that since we want a really, really robust application, we need 100% code coverage. <br />
<br />
The real intent behind coverage is that the more important parts of the application are well covered. We typically do not see 100% coverage over entire application code bases, but that is a nice stretch goal. The most important part of coverage though is that coverage does not stagnate at anything less than 70% and steadily grows over time.<br />
<br />
<div style="text-align: right;">
<span style="color: #d9d2e9;"><span style="font-size: large;"><i><b>To test the response time, we can write “executable” specs.</b></i></span></span></div>
<br />
Coverage is more difficult to specify for non-functional types of testing. For example, how would you do it for performance tests? The requirement is most likely expressed in SLA form, such as, “The system shall be up 99.99% of the time”, and “The response time will not be less than 0.1 second 99% of the time”.<br />
<br />
To test the response time, we can write “executable” specs of the form, “Given that the system has been operating for one hour under a normal load profile (to be defined), when we continue that load for one hour, then the response time is less than 0.1 second for 99% of requests.” Of course, not all performance testing tools provide a language like Gherkin but one can still express the criteria in executable “if, when, then” form and then write matching scripts in the syntax required by the load testing tool.<br />
<br />
Testing the up-time requirement is much harder: the only way to do it is to run the system for a long time, and to design in hot recovery mechanisms and lots of redundancy and elasticity. Defining coverage for these kinds of requirements is subjective and is basically a matter of checking that each requirement has a reasonable test.<br />
<br />
The coverage requirement for Exploratory testing is interesting: In the example of Table 1, we list it as “Amount of time/effort should be indicated by the story”. In other words, for exploratory testing, decide this when the story is written: decide at that time how thoroughly the exploratory testing should be for that story. This gets back to writing stories that focus on outcomes, as we discussed in <a href="http://www.transition2agile.com/2014/12/real-agile-testing-in-large.html">Part 1</a>.<br />
<br />
<div style="text-align: right;">
<span style="color: #d9d2e9;"><span style="font-size: large;"><i><b>The test strategy wiki page is for recording decisions on how testing is actually being done. It is a living, evolving thing.</b></i></span></span></div>
<br />
Most likely some narrative will be needed to explain the table entries, which need to be concise to fit in a cell. If the test strategy is maintained on a wiki (strongly encouraged), it is good Agile practice to use it as the scratchpad for thinking about testing and for recording decisions on how testing is actually being done. It is not a document that one creates and then forgets about: it is a living, evolving thing.<br />
<br />
(Note: We consider Sharepoint to be a wiki if (a) everyone on a team can edit the pages, (b) everyone on the team can create new pages, and (c) full change history is maintained; but if you uses Sharepoint, don’t upload documents: create the content right in Sharepoint, as pages.)<br />
<br />
<div style="text-align: right;">
<span style="color: #d9d2e9;"><span style="font-size: large;"><i><b>The test strategy should inform the decisions on</b></i></span></span></div>
<div style="text-align: right;">
<span style="color: #d9d2e9;"><span style="font-size: large;"><i><b>what environments are needed.</b></i></span></span></div>
<br />
The test strategy should inform the decisions on what environments are needed: this is an integrated decision that should be driven by the testing strategy. Since it takes time to provision environments, or to write scripts that provision cloud environments, this means that the testing strategy is something that is needed very early – enough to allow for the lead time of getting the environments set up. That is why testing strategy should be addressed during release planning, aka “sprint 0”. Ideally, a team continues to use a very similar testing process from one release to the next, or one project to the next, so that the environment architecture stays pretty much the same, and that way you always know what types of environments you will need.<br />
<br />
<div style="text-align: right;">
<span style="color: #d9d2e9;"><span style="font-size: large;"><i><b>What QA really does is <u>inform</u> us about the current state</b></i></span></span></div>
<div style="text-align: right;">
<span style="color: #d9d2e9;"><span style="font-size: large;"><i><b>of the system under test.</b></i></span></span></div>
<br />
We believe that the term “QA” is a misnomer. We prefer the term “Quality Informers”. Due to the fact that the vast majority of people who make up QA teams are not allowed to touch source code, not allowed to hire and fire and are not allowed to impact or alter budgets, they clearly have no enforceable means of quality assurance. What they do really well though is inform us about the current state of system under test. This is an important point when you consider previous paragraphs where we talked about informing and feedback.<br />
<br />
<h2>
<span style="font-size: x-large;">Not everything can be automated</span></h2>
Automation is central to Agile, and it is essential for continuous delivery. But not everything can be automated. For example, these things cannot usually be automated:<br />
1. Exploratory testing.<br />
2. Focus group testing and usability testing.<br />
3. Security penetration testing. (Basic automation is possible.)<br />
4. Up-time testing.<br />
5. Testing on every single target mobile platform.<br />
<br />
To deal with these in the context of <a href="https://en.wikipedia.org/wiki/Continuous_integration" target="_blank">continuous integration</a> (CI) and continuous delivery, the CI/CD process needs to focus on the tests that need to be run repeatedly, versus tests that can be done with sufficiently high confidence that things will not change too much. By automating tests that are repeatable, we free up more time for the type of testing that cannot be automated. For example, if usability testing is done once a month, that might be sufficient unless the entire UX paradigm changes. Security penetration (“pen”) testing should be done on a regular basis, but real (manual) penetration testing is an expensive process and so there is a cost/benefit tradeoff to consider – in many cases (depending on the level of risk), automated pen testing is sufficient, with perhaps expert manual pen testing done on a less frequent basis. Up-time testing can really only be tested in production, unless you are testing a new airplane’s system software before the first shipment and have the luxury of being able to run the software non-stop for a very long time.<br />
<br />
Today’s mobile devices present a large problem for platform compatibility testing. There are so many different versions of Android out there, and versions of Apple’s iOS, and many versions of Android have significant differences. Fortunately, there are online services that will run mobile app tests on many different devices in a “cloud”. Even Apple’s OSX operating system can now be run in a cloud.<br />
<br />
<h2>
<span style="font-size: x-large;">End Of Part 2</span></h2>
At this point, test-driven development (TDD) proponents are jumping up and down, feeling that their entire world has been sidestepped by this article, so in <a href="http://www.transition2agile.com/2014/12/real-agile-testing-in-large_22.html">part 3</a> of this article we will start off with that. Also, while the Who column of the test strategy table provides a means for coordinating testing-related activities performed by multiple parties, we have not talked about who should do what. For example, some testing activities – such as performance testing and security testing and analysis – might require special skills; and if there are multiple teams, perhaps each working on a separate sub-component or sub-system (possibly some external teams), then how should integration testing be approached? We will examine these issues in a later part of this series.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEge_Y7snWoSGp5Z3WTxB7trsWhwtfvaUPi31Eev9IrLHbHD7jsEnmHzPIGIDr6IcA_kiF4Ebw-y59k5FqeZB12yLjKUTC8k6bVnMx-QDofu3_uxb-xp74SMuIsMVkFdMqPvPkOK3kheOEut/s1600/Real_Agile_Testing_infographic.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEge_Y7snWoSGp5Z3WTxB7trsWhwtfvaUPi31Eev9IrLHbHD7jsEnmHzPIGIDr6IcA_kiF4Ebw-y59k5FqeZB12yLjKUTC8k6bVnMx-QDofu3_uxb-xp74SMuIsMVkFdMqPvPkOK3kheOEut/s1600/Real_Agile_Testing_infographic.jpg" height="480" width="640" /></a></div>
<span style="font-size: x-small;">As <a href="https://drive.google.com/open?id=0By4lfBwI0rt6YS1VSTlnejVocnc&authuser=0" target="_blank">PDF</a>.</span><br />
<br />
Authors (alphabetically):<br />
<a href="https://www.linkedin.com/profile/view?id=8110952" target="_blank">Scott Barnes</a><br />
<a href="https://www.linkedin.com/in/cliffberg" target="_blank">Cliff Berg</a><br />
<in file="" separate=""><br />
</in>Cliff Berghttp://www.blogger.com/profile/02103767196153470434noreply@blogger.com0tag:blogger.com,1999:blog-8391404601343318983.post-9463404202571224662014-12-02T10:05:00.001-05:002014-12-08T19:57:59.885-05:00Real Agile Testing, In Large Organizations – Part 1This article launches a <i><b>new section</b></i> on the challenges that organizations face when adopting Agile approaches to testing! We will start out with a four-part article series, and then add more articles over time.<br />
<br />
Agile turns traditional (waterfall oriented) testing on its head. Organizations that transition to Agile methods typically find themselves very confused – <i>What do we do with traditional testing functions? How do we integrate non-functional types of testing? Do you just leave it all up to the team? Does Agile somehow magically take care of everything? How does Agile handle all of our compliance rules and enterprise risks?</i><br />
<br />
<div style="text-align: right;">
<span style="color: #f1c232;"><span style="font-size: large;"><i><b>How does Agile handle all of our compliance rules</b></i></span></span></div>
<div style="text-align: right;">
<span style="color: #f1c232;"><span style="font-size: large;"><i><b>and enterprise risks?</b></i></span></span></div>
<br />
There is no <i>single answer</i> to any of these questions.<br />
<br />
The reason is that the approach to testing depends on (among others):<br />
• The nature of the requirements.<br />
• The types and degree of risks perceived by the organization.<br />
• Who the stakeholders are.<br />
• The types of environments that can be obtained for testing.<br />
• The skills of the development teams.<br />
<br />
For example, consider <b>Morticia’s website</b>:<br />
<blockquote class="tr_bq">
We are on a small team building a website for my grandmother, Morticia, to sell used odds and ends. Morticia expects a traffic of about five purchases per day – mostly from our many cousins around the world. My grandmother fulfills all of her orders herself from items in her attic and basement, has Lurch and Thing package them, and employs my uncle Pugsley and his kids (who are Uber drivers) to take the packages to the post office every day. It is very simple, and so we write the user stories for the website, with the acceptance criteria expressed in <a href="https://github.com/cucumber/cucumber/wiki/Gherkin" target="_blank">Gherkin</a>, code the tests in Ruby, and we are done! We are not worried too much about security, because all of the payment on the site will be handled by PayPal, which is a pretty self-contained service, and not a-lot is at stake anyway since most of the items are priced under $10.</blockquote>
<blockquote class="tr_bq">
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://img4.wikia.nocookie.net/__cb20120223211447/headhuntershorrorhouse/images/a/ac/Morticia_Addams_001.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://img4.wikia.nocookie.net/__cb20120223211447/headhuntershorrorhouse/images/a/ac/Morticia_Addams_001.jpg" height="300" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;"><a href="http://img4.wikia.nocookie.net/__cb20120223211447/headhuntershorrorhouse/images/a/ac/Morticia_Addams_001.jpg" target="_blank">Source</a></td></tr>
</tbody></table>
</blockquote>
<br />
Now let’s consider another (fictitious) example, <b>EFT Management Portal</b>:<br />
<blockquote class="tr_bq">
We are on a team in a six team program to build a website that enables banks to manage their electronic funds transfer (EFT) interconnections. There are lots of bank partners that will connect to this system via their own back end systems. We also have to comply with Sarbanes Oxley regulations, as well as all applicable State laws for each bank’s EFT endpoints. There is a great risk of fraud – both internal and external – given the nature of the application. The technology stacks include several open source, commercial, and proprietary stacks as well as mainframe systems, and there are some non-IP protocols (e.g., SWIFT) over private leased networks. As a result, we have some experts on the teams who know about these things. Finally, while the work can be done incrementally, and a one year roadmap of incremental releases has been defined, each release has to be rock solid – there can be no screw-ups. There is simply too much at stake. The first release will therefore not be live, serving more as a production quality demonstrator.</blockquote>
<br />
The test plan for the EFT management portal is quite a bit more involved than the one for my grandmother’s website. Certainly, “trusting the team” will not fly with management. In fact, management has hired an independent risk management company to verify that testing will be sufficient, and that all risks are being managed. This was insisted on by the boards of two of the primary banking partners. This risk management team wants to meet with the program manager and team leads next week to discuss the risk team’s information needs, which will certainly including knowing what the test plan is.<br />
<br />
I think that the testing approach for my grandmother’s website will be quite a bit different from the one for the EFT management portal – don’t you?<br />
<br />
<h2>
<span style="font-size: x-large;">What is the whole point of testing?</span></h2>
There are alternatives to testing. For example, the IBM “clean room” method substitutes careful review of source code, and its effectiveness is reported to be comparable to other forms of testing. From <a href="http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA326485" target="_blank">a Software Engineering Institute report</a>,<br />
<blockquote class="tr_bq">
<i>Improvements of 10-20X and more over baseline performance have been achieved. Some Cleanroom-developed systems have experienced no errors whatsoever in field use. For example, IBM developed an embedded, real-time, bus architecture, multiple-processor device controller product that experienced no errors in two years use at over 300 customer locations.</i></blockquote>
<br />
The goal is therefore not to test, but to achieve a sufficient level of assurance that the code does what the customer needs it to do. I said “need” instead of “want” because an important aspect of Agile methods is to help the customer to discover what they actually need, through early exposure to working software, which constitutes a form of exploratory testing. There has also been a great deal of recent work in attempts to apply <a href="https://en.wikipedia.org/wiki/Formal_methods" target="_blank">formal methods</a> to Agile. This is especially valuable in high assurance systems such as aircraft, medical devices, and systems with very large capital costs such as the microcode that executes in mass produced hardware. Formal methods are also of great interest for mass produced consumer devices - especially security critical devices such as routers, for which people do not often update the firmware. As the “Internet Of Things” (IOT) becomes reality, formal methods are being considered as a way to increase the reliability of the myriad devices that will be operating throughout our environment – things will be quite a mess if all of those devices are buggy, require constant updates, and all present security risks.<br />
<br />
<div style="text-align: right;">
<span style="color: #f1c232;"><span style="font-size: large;"><i><b>The goal is not to test, but to achieve a</b></i></span></span></div>
<div style="text-align: right;">
<span style="color: #f1c232;"><span style="font-size: large;"><i><b>sufficient level of assurance.</b></i></span></span></div>
<br />
The goal is therefore assurance. Testing is not a goal by itself. The question is, what are the Agile practices that help us to build software with sufficient assurance that it meets the need, including the various needs related to dependability? If you go to your bank’s website and transfer money from one account to another, do you expect to have a very high confidence that the money will not simply disappear from your accounts? If you make a purchase on the Internet, do you expect to have high confidence that the purchase will actually be fulfilled after your credit card has been charged? Thus, assurance is important even for the common activities that everyone does every day. Reliability affects a company’s reputation. When you code, do you think in terms of the required reliability of the end product?<br />
<br />
<h2>
<span style="font-size: x-large;">Planning is important in Agile!</span></h2>
First of all, we need to dispel the notion that creating a plan is not Agile. As <a href="https://en.wikiquote.org/wiki/Dwight_D._Eisenhower#1950s" target="_blank">Eisenhower said</a>, “<i>Plans are worthless, but planning is everything</i>.” Implicit in this is that creating plans is important – that is what planning does (creates a plan), but plans always change – that’s why plans are “worthless” – because they end up needing to be changed. Of course, saying that they are “worthless” is hyperbole: it would be more accurate to say that they are only a starting point. Plans are simply the recorded outcomes of a planning meeting – the decisions that were made, and any models that were used. The planning meeting is what is most important, and the plan – the recorded outcomes – is important too, because people forget.<br />
<br />
<div style="text-align: right;">
<span style="color: #f1c232;"><span style="font-size: large;"><b><i>An Agile test plan is not externally driven –</i></b></span></span></div>
<div style="text-align: right;">
<span style="color: #f1c232;"><span style="font-size: large;"><b><i>it is internally driven, by the team.</i></b></span></span></div>
<br />
One of the main Agile push-backs on test planning is that a traditional (waterfall) test plan is something created ahead of time by someone who is not on the development team. That is a non-starter for Agile projects, because Agile teams need to decide how they do their work, and testing is a central element of software development. Thus, an Agile test plan is not externally driven – it is internally driven, by the team. It is <u><i>their</i></u> test plan. It is the output of <u><i>their</i></u> discussions on how they plan to test the application.<br />
<br />
That said, other stakeholders should be present for those discussions – stakeholders such as Security, Architecture, or whatever external parties exist who have an interest in the quality of the delivered product. Further, those external parties have every right to form their own opinions on the efficacy of the test plan – that is, whether the tests will actually prove that the requirements of the stakeholders are covered.<br />
<br />
The question is not whether to plan, but what an Agile test plan and Agile test planning process really looks like. Brett Maytom, manager of the LinkedIn <a href="https://www.linkedin.com/groups?home=&gid=52030" target="_blank">Scrum Practitioners group</a>, has said in <a href="https://www.linkedin.com/groupItem?view=&item=5937678535664619524&type=member&gid=52030" target="_blank">a discussion in that group</a>,<br />
<blockquote class="tr_bq">
<i>“The bigger questions are, when to prepare it, how to represent it, how far in advance is the plan, who creates it, in what format is the test plan.”</i></blockquote>
<br />
Shuchi Singla, an Agile QA practitioner, commented in that same discussion,<br />
<blockquote class="tr_bq">
<i>“…we do need test plans, but unlike traditional formats they should be quick reference points. Rather than having 50 page bulky document a crisp sticky or may be white board information like RACI, platforms would suffice…we cannot let test plans just go. They have their importance and should stay though in KISS layout.”</i></blockquote>
<br />
There is a problem though: the very phrase “test plan” conjures up memories of waterfall test plans: large documents with all of the details, right down to the test scripts to be used – and with little input from the developers, and not able to evolve during development. We don’t want to do that – not anything close. As Shuchi Singla said, we want our test plan to be lightweight: we want our test plans to be test <i>strategies</i>. So from now on, we will refer to it as a <i>test strategy</i>. The strategy’s written form should also be highly maintainable – such as a set of wiki pages – so that it can be kept up to date as the team’s decisions about testing evolve over time. An Agile test strategy is always being refined and adjusted as the team learns more and more about the application and the things that actually need to be tested.<br />
<br />
<div style="text-align: right;">
<span style="color: #f1c232;"><span style="font-size: large;"><i><b>The very phrase “test plan” conjures up</b></i></span></span></div>
<div style="text-align: right;">
<span style="color: #f1c232;"><span style="font-size: large;"><i><b>memories of waterfall test plans, so from now on,</b></i></span></span></div>
<div style="text-align: right;">
<span style="color: #f1c232;"><span style="font-size: large;"><i><b>we will refer to it as a <u>test strategy</u>.</b></i></span></span></div>
<br />
In collaborating with a colleague <a href="https://www.linkedin.com/pub/huet-landry/4/82a/456" target="_blank">Huett Landry</a>, one of us (Cliff) found it to be very effective to have a test strategy consisting primarily of a table, with columns of essentially “<b>What</b>, <b>Why</b>, <b>Where</b>, <b>When</b>, <b>How</b>/<b>Who</b>, <b>Coverage</b>”. In a <a href="https://www.linkedin.com/groups/Integrating-shared-services-teams-agile-37631.S.5940205995882995714?view=&gid=37631&type=member&item=5940205995882995714" target="_blank">recent LinkedIn discussion</a>, Eugene Joseph, an Engineering Program Manager at Lockheed Martin, said,<br />
<blockquote class="tr_bq">
<i>“We had a Sys Admin team that was constantly being pulled in different directions by agile teams. We stood up a Kanban board a prioritized task that we put on the board. Someone will have to prioritize the task across your agile teams. One key thing we did was made sure that tasks entered had a clear specification of what, where, when, who, and how support was provided and a clear definition of done. This helped reduce communication delay since the client needing support CLEARLY specified what the needed.”</i></blockquote>
<br />
Thus, if you have existing silos, establishing a way of interacting with them – perhaps documented in a table that lists <i>who will do what, when, and how</i> – is especially important for enabling the <i>development team</i> to operate in an Agile manner.<br />
<br />
<div style="text-align: right;">
<span style="color: #f1c232;"><span style="font-size: large;"><i><b>If you have existing silos, establishing a way of</b></i></span></span></div>
<div style="text-align: right;">
<span style="color: #f1c232;"><span style="font-size: large;"><i><b>interacting with is especially important.</b></i></span></span></div>
<br />
A diagram is also very useful for identifying the up-stream and down-stream dependencies of a development and testing release train. As <a href="http://www.qualitydigest.com/march97/html/f3.htm" target="_blank">W. Edwards Deming said</a>, “You can see from a flow diagram who depends on you and whom you can depend on. You can now take joy in your work.” ☺ This enables you to see at a glance the types of testing that occur at each stage of the release train, the environments that each will need (and any contention that might result), and the latency that might occur for each testing activity. After all, continuous delivery is a <a href="https://en.wikipedia.org/wiki/Instruction_pipeline" target="_blank">pipeline</a>, and to treat it as such, it helps to view it as such. Figure 1 shows such a diagram. Note that the various environments are identified, along with the activities or events pertinent to each environment. The horizontal dashed lines are not a data flow – they represent a logical sequence. Many loops are implied in that sequence.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEig94D7B6KoQJXJbfGuw6UBN2L_yJ63CMCNUSclphTIRV9gQt9S_jt8OBm7YeirUtTGUIn1ZEDiHMWATwQbFpHf2jo_vxzTQ2dwoeZ3DjMnzP8W47SPLhPxtuXZ1uI0xm9OzWR5zTaePq8W/s1600/Real_Agile_Testing_pipeline.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEig94D7B6KoQJXJbfGuw6UBN2L_yJ63CMCNUSclphTIRV9gQt9S_jt8OBm7YeirUtTGUIn1ZEDiHMWATwQbFpHf2jo_vxzTQ2dwoeZ3DjMnzP8W47SPLhPxtuXZ1uI0xm9OzWR5zTaePq8W/s1600/Real_Agile_Testing_pipeline.jpg" height="480" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 1: A delivery pipeline (aka “release train”).</td></tr>
</tbody></table>
<br />
<h2>
<span style="font-size: x-large;">Stories that focus on outcomes – not just functionality</span></h2>
One of us (Scott) who has done a-lot of Agile work in the embedded software space, has had great success using an evolutionary approach for exploratory testing. Awareness of the desired outcome – from a functional as well as a reliability perspective – provides the tester with a clarity of focus, so that he or she can push the application or device harder and find more issues. Scott has found this approach to be very effective as a general paradigm: creating a focus on desirable outcomes, from the perspective of both functional and non-functional requirements.<br />
<br />
<div style="text-align: right;">
<span style="color: #f1c232;"><span style="font-size: large;"><b><i>Develop the testing strategy as an</i></b></span></span></div>
<div style="text-align: right;">
<span style="color: #f1c232;"><span style="font-size: large;"><b><i>output of story development.</i></b></span></span></div>
<br />
To implement this approach, story development should include analysts, developers and testers: develop the testing strategy as an output of story development. Some of the strategies end up as rows in the test strategy table, but others might be specific to a story. Being able to read specifically how something is going to be tested at the story level (because tests are part of the story detail) helps implementers of the story focus on the outcome that the user needs. The story should mention the types of non-functional testing that will occur. That way, the developer has the non-functional requirements at the top of their mind when they implement the story.<br />
<br />
<h2>
<span style="font-size: x-large;">End Of Part 1</span></h2>
In the <a href="http://www.transition2agile.com/2014/12/real-agile-testing-in-large_8.html">next article</a> we will talk about the various kinds of testing and how to make sure that they occur – in an Agile manner!<br />
<br />
Authors (alphabetically):<br />
<a href="https://www.linkedin.com/profile/view?id=8110952" target="_blank">Scott Barnes</a><br />
<a href="https://www.linkedin.com/in/cliffberg" target="_blank">Cliff Berg</a>Cliff Berghttp://www.blogger.com/profile/02103767196153470434noreply@blogger.com0tag:blogger.com,1999:blog-8391404601343318983.post-89774581333702574622014-11-25T12:19:00.001-05:002014-11-25T15:57:30.850-05:00An Agile Transformation Thanksgiving<h2>
How to become less agile through eating too much on Thanksgiving!</h2>
<br />
<b>Transformation</b>: Converting your waistline from loose casual slim and trim to post-holiday tightness and regret! This will make you <i>less</i> agile!<br />
<br />
<b>Self-organization</b>: Everyone gather in the kitchen, and just start cooking! (The more cooks, the better!)<br />
<br />
<b>Planning Session</b>: When planning the Thanksgiving meal, everyone gathers in the kitchen and talks through each dish they want. There are too many dishes, so write each dish on a post-it note, affix them all to the fridge, re-order them, stand back and make them all anyway!<br />
<br />
<b>Standup (before the meal)</b>: Once every hour, everyone stops what they are doing (hopefully cooking) and explains what they are cooking and which wine goes best with their dish. Now take a drink of that wine. Since you are a team, salute the person talking and everyone take a drink. If someone misses the drink, start over. Keep drinking until you get it right.<br />
<br />
<b>Standup (after the meal)</b>: Once every hour (unless you are asleep), everyone stops what they are doing (probably watching football), get up from your recliner (if you can) and go back to the kitchen. Tell each person (who manages to get there) what you’re going to eat next as you make your rounds.<br />
<br />
<b>Taste-driven cuisine (TDC)</b>: Taste the dish before you even make it! Pretend to dip your spoon into it, and bring it to your mouth, and prepare to go “ahh!” – but only to find the spoon empty. Keep doing that as you cook until you really do say “ahh!!!”<br />
<br />
<b>Crumb master</b>: the dog gets <i>everything</i> that gets dropped! He’s always around, sniffing here and sniffing there, poking his nose everywhere, but doesn’t really <u><i>do</i></u> anything! (except provide an essential glue that holds the family together!)<br />
<br />
<b>Culture challenges</b>: Get ready for making smalltalk with relatives who you see once a year. And be prepared to listen hard to those who you have trouble understanding, or who spit when they talk, and smile! Drink lots of wine – that helps!<br />
<br />
<b>Continuous delivery</b>: “George – bring out the first turkey!”<br />
<br />
<b>Sprint 0</b>: The “idea” you have that not eating before this meal will let you eat more. The more time you spend not eating the more you will be able to eat. Also, the amount of running that you can do after dinner (zero).<br />
<br />
<b>Executive leadership</b>: Mom is in charge. There is no servant leadership here!<br />
<br />
<b>Dealing with interruptions</b>: The dog just won’t stop barking! The doorbell keeps ringing! Kids keep running through the kitchen! “Oh no! – I just poured orange juice into the cake mix! – hey, that might be good!”<br />
<br />
<b>Automated deployment (pre-production)</b>: It’s 2014, and the guys still just sit at the table while the women serve them. ;-(<br />
<br />
<b>Automated Deployment (post-production)</b>: The rush of air felt when dinner is over and the mass exodus to the living room occurs.<br />
<br />
<b>Refactoring</b>: When you run out of wine and have to switch to beer!<br />
<br />
<b>Sustainable pace</b>: Eat slowly, or you will get full before the meal is over. Make sure you leave room for that final “Lardening Sprint” – dessert!<br />
<br />
<b>Retrospective</b>: “I can’t believe I ate the whole thing! And now it’s time to clean up – gosh, now I wish we had used fewer pots!”<br />
<br />
What are your Agile Transformation Thanksgiving ideas? (add as comments)<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhVviwvxidcNUWwFYfaQgO8Z1CpOP_jqCxuomNZmBrU8x58ATxOkp6jSPPEsVzRKrbyGZrQ3jbiM5mVmZdZ_5b6hvf15Stgx4-mrQAZhUuL-GOc5Bpno-OcI0lz0AgQedFKWxqHDk-MxmCg/s1600/agile-cat.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhVviwvxidcNUWwFYfaQgO8Z1CpOP_jqCxuomNZmBrU8x58ATxOkp6jSPPEsVzRKrbyGZrQ3jbiM5mVmZdZ_5b6hvf15Stgx4-mrQAZhUuL-GOc5Bpno-OcI0lz0AgQedFKWxqHDk-MxmCg/s1600/agile-cat.jpg" height="240" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Transformed! - Not very agile anymore</td></tr>
</tbody></table>
<br />Cliff Berghttp://www.blogger.com/profile/02103767196153470434noreply@blogger.com0tag:blogger.com,1999:blog-8391404601343318983.post-28563217199041468402014-11-18T13:52:00.001-05:002015-06-21T20:06:06.402-04:00Modes Of Leadership In Agile Transformation“There are spear chuckers and spear carriers.”<br />
<br />
That is what a friend of mine once told me. He had been captain of a nuclear submarine, and so he had a very well developed sense of what leadership was – at least in his world.<br />
<br />
The metaphor bothered me, because I am not a spear chucker or a spear carrier. I told him that I was a spear maker. He gave me a blank stare: in his world, the spear makers are military contractors, and they do their work pretty much out of site – before anyone boards the submarine.<br />
<br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhUy4KAWV7FB3ahyphenhyphenN55dGxhoWbaBoy8JROPaztgcbvrFxP8G_S3jX05w6R3wNQLaWJ67a7ss1HrvkSttryEIzh0SUAU6bjTCwRnJZJf86KKAQyCIwDYMh42rmR8nh-6HCg9KzUTkGpVamKX/s1600/SpearMaker.jpg" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="285" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhUy4KAWV7FB3ahyphenhyphenN55dGxhoWbaBoy8JROPaztgcbvrFxP8G_S3jX05w6R3wNQLaWJ67a7ss1HrvkSttryEIzh0SUAU6bjTCwRnJZJf86KKAQyCIwDYMh42rmR8nh-6HCg9KzUTkGpVamKX/s1600/SpearMaker.jpg" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">From <a href="http://arthistorysummerize.info/page/2/?s=stone+age">http://arthistorysummerize.info/page/2/?s=stone+age</a></td></tr>
</tbody></table>
Software programmers are spear makers. We are not thought of as leaders. Yet Agile requires us to be leaders: Agile does not work unless team members show leadership. More on that later.<br />
<br />
At the organization level, Agile transformation requires leadership as well. The notion that “executive leadership is necessary” is well established. And in the Agile spirit, it implies lots of self organization. But what does that look like? What types of leadership are in play?<br />
<h2>
<span style="font-size: x-large;">Leadership context</span></h2>
Two important contexts of leadership are (1) individual/self, and (2) team/organization. Individual leadership is about <a href="https://en.wikipedia.org/wiki/Personal_development" target="_blank">personal development</a>. Team leadership is about one’s interactions within a team. I will defer talking about individual leadership until the end of this article.<br />
<br />
<h3>
Team leadership context</h3>
If one has a position of explicit authority within a team – e.g., you are the team’s “boss” – then it is useful to talk about the relationships between the team leader and the subordinates. <a href="http://www.leadership-central.com/leader-member-exchange.html" target="_blank">Leader-Member Exchange Theory</a> (LMX Theory) is a widely used model for this. Relationships among peers within the team is also an important element. LMX Theory claims that an “in group” tends to form within a team. The “in group” is the portion of the team that the leader trusts more than the other team members. Getting into the “in group” requires demonstrated loyalty.<br />
<br />
<div style="text-align: right;">
<span style="color: #cfe2f3;"><span style="font-size: large;"><i><b>Leadership within a team does not always</b></i></span></span><br />
<span style="color: #cfe2f3;"><span style="font-size: large;"><i><b>take the form of explicit authority. </b></i></span></span></div>
<br />
On the other hand, leadership within a team does not always take the form of explicit authority. One can play a leadership role by winning the confidence of others in the team. Further, there can be multiple leaders within a team.<br />
<br />
Leadership in a hierarchy has other dimensions: the upward and sideways dimensions. If one has a leadership role within a team, one sometimes might have to represent the team to one’s boss, and to other parts of the organization. This time though, one is representing a team – not merely oneself. The table breaks all this down.<br />
<br />
Table 1: Contexts of leadership<br />
<table style="border: 1px solid black;"><tbody>
<tr><td><u>Individual context:</u><br />
1. <b>Inward focused</b>: Individual leadership (personal context).<br />
<br />
<u>Team or organization context (LMX Theory):</u><br />
1. <b>Inward focused</b> team leadership: managing subordinates.<br />
2. <b>Outward focused</b> leadership: representing oneself and one’s team to peers and superiors.</td></tr>
</tbody></table>
<br />
The lines between these modes of leadership are actually very blurry. For example, what constitutes a “subordinate”? If a team has an assigned leader, with explicit authority, then that person is clearly a team leader and the others are subordinates. However, there might be other leaders on the team who have earned a de facto leadership position by demonstrating good ideas, or simply by being persuasive. Leadership is often informal. The official leader might even find him or herself competing with informal leaders, putting the official leader into the position of having to continually demonstrate outward focused leadership to maintain his or her credibility to the team. Forming an “in group” is a tactic that enables a leader to hold onto their authority, by creating a buffer of “informants” and loyal supporters. On the other hand, informal leaders can arise within a group and challenge the official leader. Informal leadership is a source of “cronyism” and corruption in organizations, but can also be a source of great strength.<br />
<br />
All three of these leadership contexts are important for Agile transformation, as we will see.<br />
<h2>
<span style="font-size: x-large;">Leadership styles</span></h2>
By “style”, I am referring to the way that you exercise leadership, e.g., by being a bully, or by “killing them with kindness” – or perhaps by simply being the person with the most actionable and understandable ideas. Some schools of thought distinguish leadership styles as “modes”, reflecting that an individual can assume different modes depending on the situation. This is sometimes called <i><a href="https://en.wikipedia.org/wiki/Situational_leadership_theory" target="_blank">situational leadership</a></i>.<br />
<br />
There are limitless styles of leadership – as many as there are leaders. However, a particularly good taxonomy of styles is described in this article: <a href="http://www.asaecenter.org/Resources/ANowDetail.cfm?ItemNumber=241962" target="_blank">8 Common Leadership Styles</a>. I summarize some of those styles in the table, and add a few.<br />
<br />
Table 2: Leadership styles<br />
<table style="border: 1px solid black;"><tbody>
<tr> <td><b>Charismatic</b> – Inspires. May be egotistical. People follow because they trust and believe. Examples: Steve Jobs. Adolf Hitler.<br />
<br />
<b>Innovative</b> – Able to capitalize on situations. Leads by creating opportunities for others. Example: Elon Musk.<br />
<br />
<b>Command and Control</b> – Intensely goal focused and demanding. Leads by explicit authority. Example: a military commander in a live mission situation.<br />
<br />
<b>Laissez-Faire</b> – Sets an example, and advocates. Leads through personal credibility attained through prior achievements, reputation, or status. Example: Lawrence Lessig.<br />
<br />
<b>Pace Setter</b> – Creates a high pressure environment of high expectations. Leads through setting an example of working extremely hard. Example: Ross Perot.<br />
<br />
<b>Servant</b> – Works by enabling others. Leads through explicit authority, but exercises it only by facilitating collaboration and removing obstacles. Example: a Scrum Master.<br />
<br />
<b>Transformational</b> – Creates change at a fundamental level, enabling “breakthrough” change to create behavioral patterns that are completely new to those involved. Leads through helping others to understand themselves better and understand their situation better. Example: a group therapist.<br />
<br />
<b>Political</b> – Adept at negotiating win/wins with others. Leads through identifying – or creating – mutually beneficial situations with others. Example: any successful politician.<br />
<br />
<b>Competitive</b> – Sees everything in terms of a zero-sum game. Leads through aggressively out-thinking others. Example: managers who compete for budget in an organization.<br />
<br />
<b>Collaborative</b> – Tries to find the solution that is best for everyone as a whole, and involves others to do so. Leads through arranging discussion forums, establishing new paths for communication, and creating a large social network. Example: the authors of the Agile Manifesto.<br />
<br />
<b>Rule oriented</b> – Needs explicit authority to lead, and focuses on having clear boundaries defined for who is supposed to make each type of decision. Leads through having authority granted by an accepted source of authority. Example: a police officer.</td></tr>
</tbody></table>
<br />
Again, these styles are not definitive any more than a list of personality types is definitive: these are only named generalizations to help us to discuss approaches to leadership. You might be able to think of some styles to add to the list. In practice, people use a combination of styles with their own unique personality traits thrown in.<br />
<h2>
<span style="font-size: x-large;">Team Leadership</span></h2>
<h3>
Inward Focused</h3>
Inward focused team leadership involves the interactions between the leader and the team. In other words, it is about the internal dynamics of the team – not the rest of the organization or the outside world.<br />
<br />
Inward focused leadership tends to be relatively invisible outside the team except in its outcomes, unless there is such a severe problem that team members revolt.<br />
<br />
Inward focused leadership is the mode of leadership that is most often discussed in articles on team leadership, especially in the Agile community, which has had an inward team focus from the beginning.<br />
<br />
<h4>
Transformational approach</h4>
Good Agile coaches use transformational leadership. IT executives who want to transform their organization should also use transformational leadership. This entails viewing things as a system, performing introspection on the causes and effects, and changing things in a strategic way so that the desired new behaviors are inevitable and sustainable. A very useful tool for this purpose is <a href="https://en.wikipedia.org/wiki/Theory_of_constraints" target="_blank">constraint analysis</a>: What are the things that are preventing movement toward Agile? Then, consider the causes of those things, perhaps using the <a href="https://en.wikipedia.org/wiki/5_Whys" target="_blank">Five Whys</a> method, and remove those constraints. And do this not on your own, but by leveraging the thoughts and ideas of the people in your organization.<br />
<br />
<div style="text-align: right;">
<span style="color: #cfe2f3;"><span style="font-size: large;"><i><b>One of the goals of strategic transformational</b></i></span></span><br />
<span style="color: #cfe2f3;"><span style="font-size: large;"><i><b>leadership is to convert strategic decisions</b></i></span></span><br />
<span style="color: #cfe2f3;"><span style="font-size: large;"><i><b>into repeatable tactical decisions. </b></i></span></span></div>
<br />
One of the goals of strategic transformational leadership is to convert strategic decisions into repeatable tactical decisions that collectively advance the organization towards the strategic changes that are desired. For example, instituting Agile coaches to help teams is a repeatable tactical practice that will have a strategic impact over time.<br />
<br />
Transformational leadership is so important for Agile transformation that we will have a series of articles about it.<br />
<br />
<h4>
Servant approach</h4>
Scrum Masters use servant leadership. A servant leader is someone who leads softly, by educating, by suggesting, by facilitating, and by enabling. A servant leader sees it as his or her job to remove obstacles for the team, to instruct the team, by advise the team, and to encourage the team to identify and discuss important issues and reach decisions.<br />
<br />
<div style="text-align: right;">
<span style="color: #cfe2f3;"><span style="font-size: large;"><b><i>Servant leadership is not an abdication of authority.</i></b></span></span></div>
<br />
On the other hand, servant leadership is <u><i>not</i></u> an abdication of authority. As James Hunter puts it in his book <i>The Servant</i>, “The leader should never settle for mediocrity or second best – people have a need to be pushed to be the best they can be. It may not be what they want, but the leader should always be more concerned with needs than with wants.”<sup>1</sup><br />
<br />
For example, a servant leader might propose – might even insist on – certain collaborative routines (such as standups and the discussions that should follow), or assessment practices (such as measuring team velocity), if the leader thinks that that is what the team needs to become more effective. In other words, the leader needs to exercise judgment. There might be teams that are very innovative and can come up with even better practices for achieving the goals, and a servant leader should have an open mind, and when in doubt, lean towards deferring to the team. That is not an absolute though.<br />
<br />
<h4>
Command and control approach</h4>
This approach is appropriate for situations in which unexpected things can occur and it is difficult to have discussion to collaboratively decide what to do. For example, in a situation of urgency, such as fighting a fire or a military operation, direct command and control is essential. When seconds count, there is no time to explain a decision or ask for ideas: immediate coordinated action is needed.<br />
<br />
Collaboration is extremely important for military operations, but the collaboration occurs before and after the operation – not during. For example, Steve Crago – a former US Marine Corps member and now an Agile coach – <a href="http://sug4roadwarriors.com/2014/05/24/how-the-u-s-military-prepared-me-for-agile/" target="_blank">says</a>,<br />
<blockquote class="tr_bq">
<i>“What Scrum would call a Retrospective, the military labeled an After Action Report (AAR). AARs were conducted after every field exercise and/or mission. The difference between an AAR and a Retrospective are varied. AAR’s have a prescribed format and are usually attended by the leadership… each team would brainstorm ways in which to perform at a higher level. We spent hours and hours looking at various ways to do something; and our more experienced leaders at the Team, Squad, and Platoon level were continually showing us how to do something they had learned on previous missions and/or exercises. As I moved up the ranks, I added what I had learned experientially to the knowledge base that was imparted to me; and just like those who had gone before me, I began to train others to find a more efficient, effective way of performing tasks.”</i></blockquote>
<br />
Thus, it is often the case that different leadership styles are appropriate at different times. After a mission, a military leader transitions from command and control to a more collaborative approach. If you are a parent, you probably make these transitions all the time: you might generally want to be mostly a servant leader with your child, but if the child is in danger, you transition to a command mode and direct them what to do, and once the danger has passed, you might transition back and have a “retrospective” to discuss the dangerous situation with them and learn from it.<br />
<br />
Command and control leadership can be very destructive if it is used in the wrong situation. It does not utilize the collective insights of the team, and it can make people feel disempowered and helpless. The “bad boss” is a common problem in organizations – managers who give orders but who do not seek the input of their team, or micro-manage how team members do their work. This causes low morale and poor productivity.<br />
<br />
<h4>
Other approaches</h4>
The right approach for leading a team is to do whatever works. If the team members are miserable and are not able to have their best ideas adopted, or are not able to work in ways that are most effective for them, then the team as a whole will not be effective. That said, leaders sometimes have unusual traits that compensate for what would otherwise be destructive behavior. Steve Jobs is a famous example of a leader who was autocratic and abusive, yet he was extremely popular within his company, generating great loyalty, and led Apple to great success – twice.<br />
<br />
<div style="text-align: right;">
<span style="color: #cfe2f3;"><span style="font-size: large;"><i><b>Charismatic leaders inspire others, creating a</b></i></span></span><br />
<span style="color: #cfe2f3;"><span style="font-size: large;"><i><b>belief that there is a worthwhile goal. </b></i></span></span></div>
<br />
<a href="https://en.wikipedia.org/wiki/Richard_Barrett_%28author%29" target="_blank">Richard Barrett</a> pointed out to me once that Jobs’ success is not evidence that that bad behavior was not destructive: it is possible that if Jobs had been less abusive, then his organization might have been even more successful, or successful sooner. We cannot know. What we can know is that Jobs’ negative behaviors did not prevent success. So what was it about him that generated such a loyal following? Jobs was an example of a <a href="http://mmmtrainingsolutions.blogspot.in/2014/09/3-traits-of-inspirational-leader.html" target="_blank">charismatic or inspirational leader</a>. Charismatic leaders inspire others, creating a belief that there is a worthwhile goal. If people are committed to a goal, they will tolerate a leader’s quirks. Still, it might be that if those quirks were overcome, that people would be able to perform even better, so even charismatic leaders can have room for improvement.<br />
<br />
You might also find that different approaches work at different stages of a person’s or team’s development. When my son was in his early teens, I found to my great disappointment that he only listened when I exhibited anger, so I had to present an attitude of anger to get his attention. That was unique to him. As he grew older that changed, and I was able to use calm reason and sensitivity instead, which was much more pleasurable. A leader needs to be sensitive to what is effective, given the personalities and capabilities of the team, and where they are in their development. This adaptive approach is central to the <a href="http://www.makigami.info/cms/japanese-learning-system-japan-36" target="_blank">shuhari</a> method, in which an autocratic leader demands that the student follow instruction and rituals rigidly but once the student has reached the Ha stage, the instructor also engages in introspective discussion with the student. Whether this rigid approach is appropriate for a software team is debatable, but it could be that it is the best approach for certain things, such as when particularly sensitive software modules must be built.<br />
<br />
<h3>
Outward Focused</h3>
Outward focused team leadership is about interactions with your environment. If you are a member of a team, but not its designated leader, then your outward focused leadership is about the way that you represent yourself to the other team members. If you lead a team, outward focused leadership is about representing and advocating for the team to the rest of the organization. It includes creating the team in the first place and defining its purpose (“charter”) and scope of action. It includes representing the team in discussions for resources and authority to act, and whatever else is needed to enable the team to perform its purpose.<br />
<br />
Outward focused leadership is the mode of leadership that articles about business often emphasize because it is market facing, board facing, and it exhibits power – which is attention-getting. <a href="http://www.forbes.com/sites/robasghar/2014/11/14/why-bad-people-make-the-best-leaders/" target="_blank">This article</a> is a great example. From the article:<br />
<blockquote class="tr_bq">
<i>“The best human beings are collaborative, compassionate, empathetic and free of most defects of character. But the best leaders usually are not. By “best leaders,” I’m talking mainly about people who consistently show the ability to get things done—the ability to sell others on an idea, the ability to take them in new directions, the ability to talk their way out of a jam, the ability to come back from a setback, and so on.”</i></blockquote>
<br />
In terms of LMX Theory, outward focused leadership is about your relationships with your superiors and your peers.<br />
<br />
<h4>
Adapt to the situation</h4>
Servant leaders often have to take on a different leadership style when performing outward focused leadership. For example, if the team’s project competes with other projects for budget resources, the team’s leader needs to be somewhat aggressive on behalf of the team to ensure that its funding continues. The leadership styles that are potentially effective in that situation are <i>charismatic, innovative, political, competitive, collaborative</i>, and <i>rule oriented</i>. However, the styles that are likely to be most effective are charismatic (if you can pull it off), innovative (if you truly are), political (if you have the knack and like to schmooze), and collaborative (if you are very persuasive).<br />
<br />
<div style="text-align: right;">
<span style="color: #cfe2f3;"><span style="font-size: large;"><i><b>The right approach depends on your own</b></i></span></span><br />
<span style="color: #cfe2f3;"><span style="font-size: large;"><i><b>abilities as a leader.</b></i></span></span></div>
<br />
So the right approach depends not only on the situation, but also on your own abilities as a leader. Scott Beilke, a principal consultant at Brighton Leadership Group, <a href="http://www.cultureuniversity.com/the-sweet-spot-of-success-understanding-culture-change-and-leadership-to-accomplish-business-results/" target="_blank">puts it this way</a>:<br />
<blockquote class="tr_bq">
<i>“A Sweet Spot exists at the intersection of three areas of [<b>leader’s skills</b> and commitment to change, what change is needed, and the organization’s culture] for any business transformation (Change). It is critical for leaders to get context clarity on these areas to make the difference between a resounding successful change and a crashing failure.”</i></blockquote>
<br />
Team leaders also need to represent the team to a community. When Steve Jobs would speak about upcoming products, he was representing Apple to the world. His “One more thing” announcements were commitments about what Apple would be doing – exciting products to come. In that situation, it helps to sound authoritative, and to put on a charismatic, and possibly even a little command and control, attitude, since your objective is to sound authoritative.<br />
<br />
Leaders need to represent their teams in a more mundane context as well. If a senior manager wants to know how the team is doing, the team leader is available to explain the progress and challenges for the team – sometimes information radiators are not enough. Managers like to have a point person with whom to discuss issues one-on-one, in order to circumvent politics and be frank: i.e., to have “powerful conversations”. We have to remember that while Agile promotes transparency, it is unrealistic to think that politics does not operate in all organizations – even Agile ones – and one-on-one discussions are essential for managers to be able to work together. To enable that, teams need leaders who can speak for the team.<br />
<br />
<h4>
Leading without authority</h4>
Personal outward focused leadership is very important for Agile teams because Agile relies on a large amount of self organization – i.e., no one is going to tell you what to do at every step. Some Agile teams do not have a designated leader who has actual authority within the team: the team is expected to identify problems, discuss them, and take action. Everyone needs to exhibit leadership for this to work optimally. If only a few people on a team exhibit leadership, then they will have an unfair burden and will not be able to spend as much time as they should on their own work, and also the team will very possibly miss many issues that need resolution.<br />
<br />
<div style="text-align: right;">
<span style="color: #cfe2f3;"><span style="font-size: large;"><i><b>Informal leadership can be constructive or destructive. </b></i></span></span></div>
<br />
Informal leadership can be constructive or destructive. If a team member is able to cause others to trust him or her, that trust can be misused. In Jim Collins’ latest book, <i>From Good To Great</i>, he states that, “the first job of a new leader is to get the right people in the right seats.”<sup>2</sup> The <a href="https://en.wikipedia.org/wiki/List_of_cognitive_biases" target="_blank">sources of group dysfunction</a> are myriad. Also, groups tend to go through a series of stages in which power structures compete and eventually stabilize – and not always in a good way. In terms of the <a href="https://en.wikipedia.org/wiki/Forming-storming-norming-performing" target="_blank">Tuckman model</a> which is widely quoted in the Agile community, the team can end up in a “performing” state that is far from optimal. According to the <a href="https://en.wikipedia.org/wiki/Tuckman_Model" target="_blank">Wikipedia article on the Tuckman model</a>,<br />
<blockquote class="tr_bq">
<i>[The Storming] phase can become destructive to the team and will lower motivation if allowed to get out of control. Some teams will never develop past this stage. Supervisors of the team during this phase may be more accessible, but tend to remain directive in their guidance of decision-making and professional behavior. The team members will therefore resolve their differences and members will be able to participate with one another more comfortably.</i></blockquote>
<br />
In other words, <span style="color: #cfe2f3;"><i>a self-organizing group is not guaranteed to reach a healthy Performing stage without intervention by management</i></span>.<br />
<br />
<h4>
Extroverts and introverts</h4>
People who are extroverts tend to naturally exhibit leadership in teams. People tend to like extroverts and develop trust for them. Introverts have a more difficult time establishing trust because they interact less, and often interact less effectively. Thus, introverts can sometimes find it difficult to exhibit informal team leadership, even if they have ideas that are worth listening to. This is why many teams need an explicit leader, to ensure that everyone on the team is able to be heard, contribute, and exhibit leadership.<br />
<br />
This is especially important for Agile because IT people tend to be more introverted than the normal population. It is fascinating that in <a href="http://www.infoq.com/news/2013/02/Introverted-Intuitive-Logical" target="_blank">surveys in which IT people self-assess</a>, they report that they are extroverted; but in objective surveys, IT people are actually introverted as a group. From a 2002 paper in the International Journal of Human-Computer Studies, <a href="http://ir.lib.uwo.ca/cgi/viewcontent.cgi?article=1005&context=electricalpub" target="_blank"><i>Personality Types In Software Engineering</i></a>,<br />
<blockquote class="tr_bq">
<i>“The personality type most prominent is a combination of introversion, sensing, thinking and judging. ISTJs assume responsibility readily and tend to persevere. From the data it can be deduced that the majority of software engineers (ISTJ) are technically oriented and prefers working with facts and reason rather than with people.”</i></blockquote>
<br />
Thus, as a group, software developers are introverts but do not know it!<br />
<br />
Many introverts view Agile with some anxiety. From <a href="http://blog.founddrama.net/2012/08/agile-for-the-introvert/" target="_blank">this blog post</a>,<br />
<blockquote class="tr_bq">
<i>“…pair programming, bullpens, stand-ups, and scrums. We talk about close collaboration, about embedded customers… Who wouldn’t want to use such a system? Well… introverts.”</i></blockquote>
<br />
We need to consider this when thinking about the ways that Agile teams will self organize and be effective. In particular, if there are some extroverts on a team, we need to make sure that they do not dominate the group. We also need to make sure that discussions are occurring in a way that is effective for everyone, because <a href="http://leadershipfreak.wordpress.com/2013/02/05/10-ways-to-deal-with-quiet-people/" target="_blank">introverts and extroverts think and discuss issues differently</a>. Simply putting them all together around a whiteboard is not always the most effective approach.<br />
<h2>
<span style="font-size: x-large;">Individual Leadership</span></h2>
This is the type of leadership that you exhibit yourself when you take the initiative to improve yourself. If you realize that you need to learn a new skill, do you set out to do so, or just think about it? Do you reflect on your abilities and personality traits, in the interest of personal growth? Do you listen carefully to others when they comment on your ideas or your character? These are all elements of individual leadership.<br />
<br />
Individual leadership is extremely valuable for a happy, successful and productive life – no matter what profession you are in. As Richard Barrett says,<br />
<blockquote class="tr_bq">
<i>“Organizational transformation begins with the personal transformation of the leaders...The chief executive officer (CEO) or the leader of the organization must be willing and committed to his or her own personal transformation to change the culture. The leaders must live the change they want to see in the culture of the organization. For each member of the leadership group, personal alignment to the organization’s values and group cohesion around the vision, mission, values, and behaviors must become part of his or her personal journey.” <sup>3</sup></i></blockquote>
<br />
Taking the initiative to learn is part of individual leadership. Agile organizations need to have people who are continuous learners. Gone are the days when you learned a skill and used that skill for the duration of your career. Nowadays – at least in IT – skills change every single year. Today’s tools seem like the greatest thing, but three years from now only half them are still in use. Ways of working change too – Agile is an example of that. People can no longer wait to be trained: they have to take the initiative, and this is never-ending.<br />
<br />
Ironically, the foundational skills that are durable are the most valuable, but in the IT profession companies do not usually seek those: things like experience with object oriented design, experience building secure and maintainable systems, experience with design patterns, experience at solving problems and learning new things – all those things will get skipped over on a resume. Recruiters scan for the current tools – today they are NodeJS, Cucumber, and whatever – tomorrow they are something else entirely. The truth is, programmers need to continually learn new things in order to stay relevant – they are accustomed to this. Being proactive in learning new things is a form of self leadership. Agile expects it, demands it.<br />
<br />
In a future post I will look at the situations in an Agile transformation and the kinds of leadership that they require.<br />
<br />
<br />
<span style="font-size: x-small;">1. Page 66, “The Servant: A Simple Story About the True Essence Of Leadership”, by James Hunter, © 1998, published by Crown Business. </span><br />
<span style="font-size: x-small;">2. Jim Collins. Good to Great. New York: HarperCollins, 2001. </span><br />
<span style="font-size: x-small;">3. Barrett, Richard (2006-08-14). Building a Values-Driven Organization (Kindle Location 1143-1156). Taylor and Francis. Kindle Edition. </span>Cliff Berghttp://www.blogger.com/profile/02103767196153470434noreply@blogger.com0tag:blogger.com,1999:blog-8391404601343318983.post-27424066306232345692014-11-04T09:39:00.002-05:002014-11-04T20:49:30.577-05:00Key Transformation Decision: Adopt an Out-Of-the-Box Approach, Or Craft a Unique Approach?Organizations like quick answers. If you need to get into a new market, buy a company that is in that market. If you want to make your IT function more agile, pick an agile framework and “install” it. Such frameworks include <a href="http://www.scrumguides.org/scrum-guide.html" target="_blank">Scrum</a> and <a href="http://scaledagileframework.org/" target="_blank">Scaled Agile Framework</a> (SAFe). Both of these provide certification regimes, which organizations like because it turns the skill set into a commodity that can be purchased – i.e., “installed” in a repeatable manner.<br />
<br />
Many people in the Scrum community will object at this point: they will claim that Scrum should not be conflated with SAFe. Indeed, the two are descriptions of agile at very different levels. However, each one is a prescriptive model for how to implement agile, whereas the <a href="http://agilemanifesto.org/" target="_blank">Agile Manifesto</a> is a set of values and principles that one can implement in an infinite variety of ways. So yes, both Scrum and SAFe are “out of the box” frameworks.<br />
<br />
That is not a bad thing. Scrum is a great approach for team level agile. SAFe has some really great ideas in it for how to support agile projects in a large organization. These frameworks serve as excellent <i>models for thinking about how to do agile</i>, and in fact it might sometimes be possible to implement them exactly as they are defined. But that is not always the case.<br />
<br />
The real question is, what should an organization do to get started with agile? Should it try to adopt a framework? Or should it think through the Agile Manifesto – and other spheres of thought, including <a href="https://en.wikipedia.org/wiki/Lean_software_development" target="_blank">Lean</a>, <a href="http://www.inc.com/encyclopedia/managing-organizational-change.html" target="_blank">org change</a>, and so on – and define its own path? This is an important strategic decision, and it is important to get such key decisions right early on. (See the article <a href="http://www.transition2agile.com/p/important-to-get-key-choices-right.html">It Is Important To Get Key Choices Right</a>.)<br />
<br />
The argument for using an out-of-the-box framework is that it has all been thought through and tried and tested. But that does not mean that it can be applied successfully in every organization; nor does it mean that the path to implementing the framework will be easy. In fact, these frameworks are really future state models, but the hardest part is figuring out how to get there.<br />
<br />
<div style="text-align: right;">
<span style="color: #ffe599;"><span style="font-size: large;"><i><b>One problem with using a framework as-defined is that doing so is inherently non-agile. From that point on, the team looks to the “expert” for guidance on how to do their work.</b></i></span></span></div>
<br />
One problem with using a framework as-defined is that doing so is inherently non-agile. If you force a framework on people, and give them an expert in that framework, you have essentially taken their process away from them. <i>From that point on, they look to the “expert” for guidance on how to do their work</i>. This is completely contrary to the agile value of “Individuals and interactions over processes and tools”, and also contradicts the agile principle of “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done” – i.e., trusting people to figure out how they should do their work. Giving someone a framework and saying “do that” is telling them how to do their work, and is contrary to agile values and principles.<br />
<br />
An alternative is to bring in an expert in agile – ideally someone who is knowledgeable of multiple frameworks and multiple spheres of agile thought – and have that expert discuss the agile values and principles with the team in the context of how the team is currently doing its work. Then, work with the team to apply agile values and principles to come up with improvements to how they work. The frameworks can serve as sets of ideas for how to improve things. These improvements can be incremental or radical, depending on the team’s appetite for change – but the team is then in control of the change. <i>The team owns their own process, and does not need to ask the “expert” for permission to try something new</i>.<br />
<br />
Let me be clear here that I am not against Scrum or SAFe, or any prescriptive process – in fact, I think they are really important agile models. It is just that I think that teams should decide on their own process, and not have someone tell them that they should use Scrum or SAFe or use these in a certain way. The team needs to be able to understand every change they make to their own process, and have their own performance improvement goals for it. If you give them an entire canned process, and tell the team that all of the practices work together, then the team does not know what to expect: they have to trust the expert and accept on faith that the new process will work. They don’t truly understand it – only the “expert” does. The team has to wait until they have also become experts before they can appreciate the new process. That is not an agile way to do things. That is “big process up front”. It is command-and-control. It is all at once, rather than incremental. It is about “processes and tools” rather than individuals and interactions. It is exactly what we tell people not to do, when we tell them to “be agile” rather than “do agile”.<br />
<h2>
The Alternative: Take an Issue-Focused Approach</h2>
Rather than starting out by telling a team that they need to adopt a framework that they do not yet understand, talk to the team about their challenges. Take an issue-focused approach. Does testing result in lots of rework? Are there bottlenecks, possibly due to certain people having certain tasks that others have to wait for? Is there contention for testing environments? Is there a requirements or design document, but no one to ask about it? And do the requirements or design sometimes need to change, but changes require an onerous change control or review process? Are there third parties who need to perform tasks such as independent testing or security review, and those tasks take a long time and can potentially hold everything up, or result in lots of unanticipated rework?<br />
<br />
These are all tangible issues that agile – including frameworks like Scrum, <a href="https://en.wikipedia.org/wiki/Extreme_programming" target="_blank">eXtreme Programming</a> (XP), SAFe, Lean, and other agile models and schools of thought – can help with. For example, on the first issue about rework after tests are run, the team can discuss how it might implement a continuous integration (CI) cycle, so that tests are run locally by developers and that way there are no surprises when tests are run in a test environment. With respect to bottlenecks, the team can discuss how to enable more people to work on the items that are bottlenecks – possibly by training certain people using <a href="https://en.wikipedia.org/wiki/Pair_programming" target="_blank">pairing</a> – or if that is not feasible, perhaps the bottleneck work can be started earlier so that it is staggered with respect to dependent work, creating a kind of <a href="https://www.cise.ufl.edu/research/ParallelPatterns/PatternLanguage/AlgorithmStructure/Pipeline.htm" target="_blank">pipeline</a> or <a href="https://en.wikipedia.org/wiki/Kanban_%28development%29" target="_blank">Kanban</a> process. In fact, tangible agile solutions can be found for each of the team’s issues. The best part is, the team is not thrown into an entirely new process overnight, but instead they are inventing their own solutions for their own problems – and moving toward agile in the process.<br />
<br />
<div style="text-align: right;">
<span style="color: #ffe599;"><span style="font-size: large;"><b><i>This approach will improve productivity from the very beginning.</i></b></span></span></div>
<br />
This approach will improve productivity from the very beginning. There will be only a minimal <a href="http://stevenmsmith.com/ar-satir-change-model/" target="_blank">Satir change curve</a> dip, because the changes are incremental and not disruptive. The team will also have higher morale, because the innovations are their own, and they are in full control of their own process. And their old process has not been thrown out the window and derided as “bad” and “waterfall” – synonyms in the agile community.<br />
<br />
There is a catch with this approach as well: It will only work if there is authority behind the changes that are needed. Within the team, the team has to be empowered to make its own decisions about how it works, without interference from project management or external entities. Also, the team has to be motivated to improve things, and not stuck in its habits. Some people resist change, even if it might improve things. A team that is composed of people who resist change will not want to devise improvements to its own processes.<br />
<br />
If the team resists change, then the agile coach needs to have authority to impose a mandate on the team, such as “We need to improve velocity by 20% over the next four weeks”, or “We need to reduce testing time by 50% over the next two months”. The coach’s mandate can derive from a CIO mandate giving the coaches authority. The CIO mandate can even be specific, by mandating certain agile practices, but that is not a very agile approach – it is prescriptive, just like mandating a framework – yet it can work if the coach is around sufficiently to guide the team in those new practices. In contrast, if the team devises its own way to meet goals such as decreasing test time, they will need less guidance.<br />
<br />
Even if the team is motivated to improve its practices, they might still have to comply with externally imposed non-agile practices such as gate reviews and manual testing by an external testing group. In order to negotiate how those constraints can be relaxed, the agile coach needs authority to be able to make “deals” on behalf of the team. In that capacity, the agile coach is acting more like a project manager, even though when dealing with the team the coach acts as a coach. Leadership requires applying the right methods depending on the situation.<br />
<br />
The same lessons about imposing a framework apply at an organization level. In fact, at an organization level, it is even more important to allow people to define their own business functions. To do that, people have to first learn about agile. They have to visualize what their function would look like under agile – or even if their function would still exist. Then, they have to make concrete plans for changing their function, with the assumption that change will occur in stages – it will be unusual to get it right from the outset. All that takes time. Pushing a pre-defined set of processes on an organization will likely create a-lot of frustration because the “train is moving” and managers are still on the hook for delivery dates and meeting their various commitments, as well as complying with organization policy that is still in place. Creating entirely new processes and systems takes time, and people need to learn how to operate those new systems – and new ways of thinking to boot – and that takes even more time. This is why a framework – such as SAFe – is a great place to start for ideas, but should not be implemented “out of the box”.<br />
<h2>
The Big Framework Up Front Can Work</h2>
Transitioning a team overnight to a prescriptive agile process can work. I have seen it work – but not often. One case in which it worked well was a project at a company called BCE Emergis during the early 2000s. The project had 80 people (about 50 developers using <a href="https://en.wikipedia.org/wiki/Rational_Unified_Process" target="_blank">RUP</a>). The company decided to rapidly adopt eXtreme Programming (XP) and brought in XP coaches to help. We carved out four development teams. I was the lead of one of those teams. The rapid transition to XP worked, because each coach was highly experienced with XP, and there was at least one coach per team. Thus, the coaches were present all the time, and participated in discussions – both planned and ad-hoc.<br />
<br />
This is the “<a href="https://en.wikipedia.org/wiki/Shuhari" target="_blank">Shuhari</a>” model, or apprentice/craftsman approach: an expert (the craftsman, or master) trains an apprentice. The apprentice is expected to follow the direction of the craftsman to the letter until the apprentice learns the craft well enough that he or she can do it on his or her own. Eventually, the apprentice becomes expert enough to make his or her own judgments – even to the point of violating the practices that he or she was taught, if the situation warrants it – in other words, the apprentice has become a craftsman, and understands the reasons for the rules well enough to bend or break the rules when it makes sense to do so. For the apprentice/craftsman approach to be an effective instruction/learning strategy, a craftsman is needed who can spend a great deal of time with the apprentice. This approach does not work if the craftsman or master is seldom available. <br />
<br />
Most organizations that adopt agile do not do it in a Shuhari or apprentice/craftsman way: in most cases that I have seen, each coach has a portfolio of projects that they coach – typically from three to ten projects/teams. And for coaches, I am not including recently trained Scrum Masters, who just obtained their two day Scrum certification and have never worked on an agile project before. Those people are beginners every bit as much as the rest of the team is.<br />
<br />
Three to ten teams per coach is too many: the right ratio is 1:1. If it is not 1:1, then the team is essentially expected to use an entirely new process that they do not understand, and there is seldom anyone around to guide them. They end up trusting the process and not thinking for themselves, but no one is around to tell them what to do. This can have a very bad outcome, including testing that gets overlooked, technical work that goes undone, and important collaboration that fails to occur, and – worst of all – the organization sees poor results from agile adoption and loses confidence in it.<br />
<h2>
Conclusion</h2>
I really like the expression “fish or cut bait”. If you are going to do something a certain way, really do it. If you are going to adopt a framework, bring in the resources to do it for real – not half way. If you cannot afford those resources, use a different strategy that you can afford and do it right. If you have a few coaches and many more teams, then you cannot effectively use the Shuhari or apprentice/craftsman approach. Instead, leverage the brains on the teams to adopt agile: use the coaches to help the teams to talk through issues, giving them an agile perspective, but don’t expect the teams to adopt an entirely new way of doing things. Empower them to adjust their own processes – which they understand – gradually, learning as they do it. That is more effective if the coach is not always around, in which case the team needs to be able to think for itself, on its own, even as they are learning agile. That is <u><i>being</i></u> agile.<br />
<br />
Then again, these are complicated issues, and to say that a framework should or should not be imposed in a given type of situation is itself prescriptive. More often, the right answer is a combination of approaches: perhaps some prescription is called for, to push things along, while allowing people to innovate with their existing processes as a starting point. Judgment on the right balance is called for. Advice on that judgment is the value added by agile coaches, at both the team level and the enterprise level, and managers need to apply their experience with respect to organization change in order to find the approach that is best for their organization’s culture and circumstances.<br />
<br />
Contributors (alphabetically):<br />
<a href="https://www.linkedin.com/in/cliffberg" target="_blank">Cliff Berg</a><br />
<a href="https://www.linkedin.com/profile/view?id=38538258" target="_blank">Sekhar Burra</a><br />
<a href="https://www.linkedin.com/in/sunilmundra" target="_blank">Sunil Mundra</a><br />
<br />Cliff Berghttp://www.blogger.com/profile/02103767196153470434noreply@blogger.com0tag:blogger.com,1999:blog-8391404601343318983.post-18895059103321582152014-10-24T11:56:00.002-04:002014-10-24T13:31:46.680-04:00What To Do About Distributed TeamsA recent client of of one of us had a dilemma: their procurement department had selected the lowest cost bidder on a software contract, and that bidder was located on the other side of the country (USA). When work on the “agile” project started, the kickoff consisted of a conference call.<br />
<br />
It is a real problem that procurement is viewed as a separate function, apart from how the software development team will operate. Fixing that requires going way, way up in the organization – beyond the CIO – and if the organization is a subdivision of a large company, or a government agency, addressing the issue possibly requires going even beyond the organization itself to the owning organization, which sets procurement policies.<br />
<br />
We don’t want to get into procurement here: that is not the topic of this article (it will be a future topic). Instead, we want to look at the very common, real, and unchangeable situation that we sometimes face: when a team – or worse, only <i>part</i> of a team – is remote.<br />
<h2>Is it really a bad thing?</h2>Not too long ago, Jeff Sutherland – the “father” of Scrum – <a href="http://pdf.aminer.org/000/248/971/projected_management_model_for_physically_distributed_software_development_environment.pdf" target="_blank">published a paper</a> on a software project that was highly distributed, which he claimed had been one of highest productivity distributed software projects ever, with a productivity comparable to that of a small co-located Scrum team. Some noteworthy aspects of the project’s organization included:<br />
<br />
1. There were multiple teams, spread across six geographic locations.<br />
2. Teams were split across the functional areas of the requirements.<br />
3. Team members were purposefully spread across geographic boundaries: thus, for any given team, the members were distributed. Any member of a team, at any location, can work on any item on that team’s backlog.<br />
4. The information to be shared in a team’s standup was written up before the standup and distributed to the team’s members. This helped to overcome communication challenges over long distance phone connections, as well as language barriers.<br />
5. Standups were done in real time, despite a fourteen hour time zone difference.<br />
6. Each team had a Product Owner assigned to it. All Product Owners were co-located, and met daily, and there was a “chief” Product Owner.<br />
7. All Scrum Masters were co-located, there was a “chief” Scrum Master, and there was a “Scrum of Scrums” meeting every Monday. The Scrum Masters were also co-located with the Product Owners.<br />
8. An Architecture group, also located with the Scrum Masters, met on Monday after the Scrum of Scrums meeting and controlled the direction of the project architecture through the Scrum meetings.<br />
9. A co-located Automation Test team created scripts for an automated testing tool.<br />
10. Tests were written simultaneously with code most of the time.<br />
11. During a Sprint, the Product Owner tested features that were in the Sprint backlog – rather than waiting to the end of the Sprint.<br />
12. A shared code repository, used by all teams.<br />
13. Integration of eXtreme Programming (XP) practices, to augment Scrum practices.<br />
14. Some continuous integration practices were used, such as hourly automated builds, but there was a ways to go in this, especially with regard to test automation for acceptance tests.<br />
<br />
One of the reasons cited for the project’s high productivity was the caliber of the teams – made possible by the move to a distributed approach. This enabled the selection of a remote group in Russia, StarSoft, that had extensive experience with systems level software as well as experience using XP, rather than trying to use the best talent that could be found locally. According to Jeff Sutherland,<br />
<blockquote class="tr_bq"><i>“The local talent pool is not sufficient to expand team size and salary costs are much higher than outsourced teams...The primary driver is enhanced technical capability resulting in dramatically improved throughput of new application functionality.”</i></blockquote>In other words, using a distributed model enabled the project to recruit the best talent, rather than relying on what was available locally.<br />
<br />
In contrast to this, many organizations choose remote teams in order to get the lowest cost. That can potentially undermine success. Instead, it is wiser to find the right skills, whether they are local or remote. Looking at a wider geography can enable you to find the right resources more easily. The cost objective is self-defeating if the project is not successful.<br />
<h2>Co-location of “thought leadership”</h2>The practice used by this project that is probably the most controversial for the agile community is that Scrum Masters were all located together, as were the team architects, and the Product Owners. There is a general feeling in the agile community that leaders should be no more than facilitators, and so leaders need to be present in person to be able to facilitate. This was not possible in this project, due to the fact that each team was distributed. For the Product Owners, putting them all together is less controversial: agile teams are accustomed to this; but putting all of the Scrum Masters together, and the architects as well, is controversial because doing this effectively creates a collaborative forum that excludes the team members. Agile relies on collaboration, and having an elite “architect” group collaborate privately is viewed as not very agile. In fact, the Scrum community does not even approve of having a role such as “architect”, which is ironic because Jeff Sutherland – the author of the article – seems to feel that in this instance it was fine.<br />
<br />
Based on our own experience with both architects and agile teams, it is essential that an architect or technical lead work in a collaborative way. The kind of architect role that is effective for agile teams is one that does not base his or her work around documents, but rather discusses issues with the teams directly, as well as with other stakeholders such as Security, Release Management, the data center or cloud service group (if there is one), and so on. Architects can play a valuable role in that they (1) are aware of the organization’s larger architecture strategies, (2) are charged with thinking more long term and more end-to-end, and can do this throughout a project because they are not saddled with creating stories, (3) have (or should have) expertise in a wide range of aspects of IT beyond software development, including system architecture, scalability, security, maintainability, systems thinking, and design patterns. Certainly programmers should know these things, but they often do not, and an architect – if sufficiently qualified – can serve as a valuable mentor for the team.<br />
<br />
The last part is important: an agile architect should be a mentor – not an autocratic decision-maker. Issues should be discussed with the team, rather than decided independently, and the architect should serve as a coach, teaching the team about architecture concerns. For a distributed team, in which all of the architects are located together, this is even more important, because the architect is less accessible physically, and the co-location of the architects makes it inevitable that they will collaborate privately – that is in fact an advantage if there are multiple architects, but it must be ensured that the architects also collaborate with their teams. The “chief” architect, as Jeff Sutherland referred to the role, should make sure that this occurs: the chief architect is also a coach for the architect team and must ensure that they work in a way that is compatible with agile practices. The same applies to the “chief” Scrum Master, and the “chief” Product Owner.<br />
<br />
<table style="border: 1px solid black;"><caption>Table 1: Roles and their value for the fully distributed team cited.</caption> <tbody>
<tr style="background-color: #aaaaaa; font-weight: bold;"><td>Role</td><td>Where Located</td><td>Value of Role For Fully Distributed Teams</td></tr>
<tr><td>Scrum Master or Team Lead</td><td>All at central location</td><td>Ensure that remote communication practices are effective.</td></tr>
<tr style="background-color: #eeeeee; color: black;"><td>Product Owner</td><td>All at central location</td><td>(same as for any Scrum team)</td></tr>
<tr><td>Architect</td><td>All at central location</td><td>Ensure architectural consistency.</td></tr>
<tr style="background-color: #eeeeee; color: black;"><td>Tester</td><td>All at central location</td><td>Manual testing; automated test script development; stress testing.</td></tr>
<tr><td>Chief Scrum Master</td><td>Central location</td><td>Lead the Scrum-Of-Scrums meetings.</td></tr>
<tr style="background-color: #eeeeee; color: black;"><td>Chief Product Owner</td><td>Central location</td><td>Lead daily Product Owner meetings.</td></tr>
<tr><td>Team Member</td><td>At each location</td><td>(same as for any Scrum team)</td></tr>
<tr style="background-color: #eeeeee; color: black;"><td>Tech Lead</td><td>At each location</td><td>Coordinate technical issues across teams.</td></tr>
<tr><td>Test Lead</td><td>Central location</td><td>Coordinate testing activities.</td></tr>
</tbody></table><br />
According to Jeff Sutherland, “SirsiDynix achieved strong central control of teams distributed across geographies by centrally locating ScrumMasters, Product Owners, and Architects. This enabled them to get consistent performance across all distributed teams.”<br />
<br />
It should be noted that some of the lessons here conflict with sentiment in some parts of the agile community. The Scrum community in particular is uncomfortable with having specific lead roles such as “architect”, or indeed any “chief XYZ”. Even the concept of “control”, as expressed in the above quote by Jeff Sutherland, is objectionable to much of the Scrum community – which is ironic given Sutherland’s role in the creation of Scrum. The intention in this article is not to take a general position on these points, but to share what we have known to work given the unique challenges of a <i>distributed</i> team, recognizing that there might be other approaches that could also work. Effective leaders often are able to make any approach work: the leadership is what makes the difference.<br />
<h2>Use of remote collaboration tools</h2>Many organizations use remote meeting tools such as GoToMeeting, WebEx, Skype, and so on. These tools are really nice, in that they make it simple to set up a conference call and share screens, but they do not really solve the challenges with remote meetings. It is still hard to hear and understand people. When people are remote, they often feel that it is ok to join late, or they call in from their car (not ok if they need to see a shared screen or look at documents), or they multi-task, or they have background noise (another conversation going on in their cubicle), and so on – all of these distractions and interruptions can destroy the cadence and cohesion of a meeting: people start to emotionally disconnect. <a href="https://www.youtube.com/watch?v=DYu_bGbZiiQ" target="_blank">Here</a> is a hilarious comedy portrayal of this. Preventing these kinds of interruptions requires very strong meeting management – a skill that most agile coaches do not have, since they are accustomed to working with teams in person.<br />
<br />
One of the greatest drawbacks to a remote meeting is the inability to whiteboard. Many people think visually. Most agile coaches are accustomed to writing on a board, or putting up sticky notes, or conducting a “dot vote”. These visual techniques cannot be done easily on an ordinary computer screen, although there are touch screens that are available for this purpose, e.g, the “<a href="http://www.rentouch.ch/en/flextouch/" target="_blank">FlexTouch</a>”. In addition, for a technical meeting, it is almost always necessary to draw on a whiteboard, and the drawings can become very expansive – spanning multiple boards. This is not easy to replicate on a computer screen, although that is changing with the advent of very large “4K” screens. Even so, one needs to be able to draw on the screen.<br />
<br />
Given these challenges, a remote meeting must be facilitated very differently from an in-person meeting. Careful thought must be given to how diagramming will be done, if it is needed, and preparations and discipline must be applied to enable people to hear each other. When we facilitate a remote meeting, and someone is not easily understood, we ask them to speak up, or we repeat what they said to confirm that we understood it correctly. In the project described by Jeff Sutherland, team members were required to submit their standup statements in writing prior to the standup, enabling everyone to read it if they cannot understand what is being said. Coaches need to use these techniques. The meeting’s coach or facilitator also needs to set things up before the meeting, since it takes a few minutes (sometimes longer) to overcome technical glitches.<br />
<h2>Meet in person at the beginning?</h2>It is really essential to have the entire team meet in person for a few days – a week is recommended – at the beginning of a project so that they can collaborate most effectively on the key “conceptual pillars” of the project: the core vision and requirements, the core design concept, the team roles and collaborative processes, the development pipeline, and the testing strategies. (See <a href="http://www.transition2agile.com/2014/09/key-transformation-step-establish-agile.html" target="">this prior post</a>.) These are all very complex issues and require lots of whiteboarding and active sharing of ideas. Doing this remotely will take weeks, and it would be difficult to resolve all of these things in a collaborative way by doing it remotely: one would likely have to fall back to the non-agile approach of having someone dictate much of this. Establishing the key conceptual pillars is extremely important to ensure that risks can be managed well and that things will go smoothly and evolve, instead of having radical and disruptive conceptual changes mid-stream.<br />
<h2>How to go through stories remotely?</h2>Agile replaces the traditional practice of writing a detailed requirements document with a more fluid real-time process of having stakeholders describe what they want to developers in person, noting those requirements down as brief “stories”, and then adding details to those, primarily in the form of acceptance criteria. Developers are encouraged to reach out to stakeholders as they program to ask for clarifications, and stakeholders are encouraged to try out the software as soon as a developer thinks that it is complete, followed by a formal demonstration at the end of each iteration. This interactive exchange is more difficult if the stakeholders and developer are not geographically collocated.<br />
<br />
In the project cited above, stakeholders wrote requirements down with details ahead of time. This enabled developers to review those requirements before a sprint planning meeting, and then ask clarifying questions. This process seemed to work well for those teams. However, it is mentioned in the article that the remoteness of stakeholders made it necessary for some “multi-tasking” – that is, the developers sometimes had to put a story aside and work on another until they received feedback from a stakeholder about a question.<br />
<br />
Regarding trying out software as it is developed, we have seen it work well when remote users try out an application during an iteration by logging in remotely, as soon as a developer thinks that a story is done, rather than waiting until the review at the end of the iteration. The application can be deployed into a test area specifically intended for users to try out stories as they are completed. This reduces the risk that a story will be marked as complete, but then not accepted by the Product Owner (representing the stakeholders) at the end of the iteration. It is important that remote stakeholders have a separate test environment for trying things out, so that they do not interfere in the test environments and disrupt the testing cycle of the team.<br />
<h2>How to coach people you can’t see?</h2>One of the greatest challenges for coaching remote teams is that you cannot simply stroll up to people and see how things are going for them. Calling them out of the blue is potentially disruptive, so that leaves email. Asking in an email to schedule a time is cumbersome, and seems “managerial” – something that a coach tries to avoid. We personally recommend going out of one’s way to establish a unique relationship with each team member as soon as possible at the start of a project. Reach out to each person – don’t skip anyone – ask for a time to chat on the phone, and take notes about their perspectives and challenges, because if you can’t see them, it is harder to remember those things and associate them with the person. Primarily ask questions and listen – don’t do the talking. Then, make it your business to remove obstacles for people. Check in on things that you know they are waiting for. Advocate for them. Connect them with people who they have been trying to reach, such as someone in a support function (Testing, Release Management, etc.) from whom they need something. And have a regular, say weekly, chat with each team member about how they feel things are going, on a personal level. Keep their confidence, and be on their side. And if at some point you visit their location in person, make it a point to stop by and chat.<br />
<br />
Pair Programming is a great way to increase collaboration in Distributed teams. When teams are distributed in two or more locations, each location team will try to behave as a separate team by itself. They often try to “throw over the wall” to each other. Instead, it is very important to promote <i>One Team</i> behavior within such teams. One technique which we often use is Pair Programming, such that in each Sprint, every developer pairs with a developer at another location during the hours in which their work schedule overlaps. They both work on a single story until it is done, with a handoff from one to the other at the end of each other’s work day, but working together when their work period overlaps. One developer codes the story during the day, and later in the day he pairs up with the other developer, walks him or her through the code that was changed, and checks-in the code before leaving for the day. The other developer checks out the code and resumes coding, and records his findings in a small video (we use the Snagit tool to record) and puts the video in a shared folder which the other developer can access the next day. This way there is a collective code ownership between the team members who are not at the same location.<br />
<br />
Some other techniques which we recommend for distributed teams are:<br />
• Share the pain caused by time zone differences<br />
• Make sure that everyone has a calendar that covers the regions and cultures present on the team, so that if someone will be out for a holiday, it will not be a surprise.<br />
• Have a daily or frequently recurring optional virtual meeting for discussing issues that come up during the day. This does not replace the standup, but is an open forum for sharing ideas. This helps to overcome the fact that people are not co-located and cannot overhear each other or just walk around to each other’s desk.<br />
• Do retrospectives (every iteration) with the <i>entire</i> team<br />
• Encourage cross-region communication (for example, by using pair programming)<br />
• Actively share feedback from stakeholders with the <i>whole</i> team<br />
• Focus on delivering the value stated in the stories<br />
<h2>How to participate in ad-hoc discussions?</h2>Another severe challenge for remote coach is that agile relies on ad-hoc discussions for resolving issues that come up. If you are not there in person, then you cannot observe these discussions happening, and so you can’t lean in and hear what is going on. You can become out of the loop on things pretty quickly.<br />
<br />
In the project referenced earlier, the fully distributed nature of each team cleverly avoids this problem: each team member is apart from the rest of the team, so discussions have to be arranged. It is therefore the coach’s job to keep reminding the team that he or she wants to be included. Eventually they will get the message and will do so – as long as your participation is positive. Generally, a coach should not interfere in a discussion unless the discussion has become dysfunctional. A coach is first and foremost a facilitator. If a discussion is remote – over the phone, or via email – then a coach can play a valuable role in making sure that the communication works well, that people who are hard to understand speak up, that decisions get written down and disseminated (e.g., on the team’s wiki or – even better – on a wall in each of the remote offices), and that the discussions stay on topic (especially difficult for email exchanges). However, a coach’s presence should not be felt: it should be an enabling presence – not a contributing presence – kind of like the way ceiling lights help everyone to see in a room, but you don’t notice them per se.<br />
<h2>Dealing with regional and cultural differences</h2>Cultural differences is a topic in its own right, and we will have a separate article on that. For now, suffice it to say that the most dangerous mistake people make when leading a cross-cultural team is to assume that we’re more alike than we actually are. Some cultures are not accustomed to speaking their mind in a meeting, while others are – especially if there are people present who have a higher position (and a Scrum Master can be seen as such a person). In some cultures, people will not express an opinion unless they have had time to check their facts and do some thinking offline, or they might even consider it to be rude to speak honestly if it would be critical. Some cultures are accustomed to being given explicit work instructions while others welcome autonomy and self direction. Some cultures see their personal time as sacrosanct while others are perfectly willing to work weekends as needed. If a culture is accustomed to long summer holidays, make sure to plan around that. Some cultures value punctuality while others do not.<br />
<br />
In addition, do not underestimate the challenges of language. Even when all parties speak the same language, it can be very difficult for people to understand each other when there are multiple dialects. For example, American English, UK English, Singaporean English, and Indian English are all sufficiently different that it can be difficult to communicate verbally in real time, especially if the communication system is imperfect – which is usually the case. Idioms can be especially problematic. The distractions of communication dropouts, coupled with soft speaking and multiple language dialects can all combine to create enough distraction so that people cannot focus on the issues being discussed. If communication is challenged, it is the job of the meeting facilitator to repeat what people say if it was not clear or not loud, and to verify that all parties are following the discussion. Ask people regularly to summarize their understanding and ask people for their opinions. Do not wait for them to speak up. Plan for the extra time that this consumes: it is a cost of having distributed teams.<br />
<br />
Contributors (alphabetically):<br />
<a href="https://www.linkedin.com/in/cliffberg" target="_blank">Cliff Berg</a><br />
<a href="https://www.linkedin.com/profile/view?id=38538258" target="_blank">Sekhar Burra</a><br />
<a href="https://www.linkedin.com/in/nancysettlemurphy" target="_blank">Nancy Settle-Murphy</a> – facilitator, virtual team expert, cross-cultural trainer, OD consultant, and author of <a href="http://www.guidedinsights.com/leading-effective-virtual-teams/" target="_blank">Leading Effective Virtual Teams</a>Cliff Berghttp://www.blogger.com/profile/02103767196153470434noreply@blogger.com6tag:blogger.com,1999:blog-8391404601343318983.post-51433529999314638302014-10-10T11:00:00.002-04:002014-10-10T11:01:18.658-04:00How To Rapidly Infuse Technical Practices Into Your Agile TeamsMartin Fowler <a href="http://martinfowler.com/bliki/FlaccidScrum.html" target="_blank">once wrote</a>, “The scrum community needs to redouble its efforts to ensure that people understand the importance of strong technical practices.” Jeff Sutherland <a href="http://pdf.aminer.org/000/248/971/projected_management_model_for_physically_distributed_software_development_environment.pdf" target="_blank">has commented</a>, “It is extremely easy to integrate Scrum with XP practices even on large distributed teams. This can improve productivity, reduce project risk, and enhance software quality.” <a href="http://xprogramming.com/blog/what-is-really-essential/" target="_blank">Ron Jeffries wrote</a>, “Manual testing cannot sustain the two week delivery cycle. Therefore, for a truly successful iterative software project, automated testing is absolutely necessary.”<i><b> </b></i><br />
<br />
<div style="text-align: right;">
<span style="color: #d9ead3;"><span style="font-size: large;"><i><b>You have to trust the team to figure out what they need to learn, and that they will learn it: they should not wait to be trained.</b></i></span></span></div>
<br />
But what if your teams do not know how to do these things? Agile promotes self learning: if you are going to trust the team to know how to do its work, then <i>you have to trust them to figure out what they need to learn, and that they will learn it: they should not wait to be trained</i>. Still, it can take a long time for a team’s members to learn a whole host of new skills on their own. Agile transformation is about making this happen rather than waiting for it to happen. How can you get a team to learn the technical side of agile?<br />
<br />
One approach that we have seen work really well is to create training teams. These teams provide intensive hands-on classroom training, as well as on-site coaching as a follow-up to the training. In 2012 one of us (Scott) created such a team for training a very large IT organization in agile technical practices, and this recounts that experience.<br />
<br />
The directive was to infuse knowledge of technical practices across all of the in-house software development teams across the organization’s many locations around the country. The practices included test-driven development (TDD), test automation, automated quality analysis, and continuous integration (CI). Rather than go through a lengthy narrative on each approach taken, we will summarize the approaches here and then discuss them:<br />
<ol>
<li>Training team consisted of two members (including one of us), each with strong development experience, and experienced with many agile technical practices and tools.</li>
<li>Created a standard set of test tool stacks that could be easily installed. Started with test tool stacks to support testing for the most common development tool stacks in that environment (Java, Oracle).</li>
<li>Trained entire teams at a time in a classroom, in person, with some lecture, discussion and mostly hands-on practice.</li>
<li>The course took three weeks, with short two-hour sessions three times a week, minimizing impact on work.</li>
<li>Web based training was not used because it is more difficult to build effective web based training materials. Further, we wanted to ensure that entire teams were trained rapidly and that we had their undivided attention for a period of time.</li>
<li>Followed up with those teams after training them, in person, using a “coaching” approach.</li>
<li>Measured code quality, test coverage and practice usage after the teams had been trained, and reported their progress in a management scorecard style report.</li>
<li>Kept track of which teams had been trained, and reported that in the scorecard. This put pressure on group managers to get their teams trained.</li>
<li>We found that many (but not all) testers could be turned into test programmers in ~ 3 weeks, further enhancing the overall benefits.</li>
</ol>
<br />
The results of this were that adoption of agile technical practices advanced rapidly across the organization. Some teams were eager for the changes, and some were resistant, but most were simply supportive of the new direction and were willing to give it a try and see how it worked. In one case, a team – one of the most experienced and productive teams – rejected the use of TDD, but since management had decided to make TDD mandatory, a senior manager spoke to that team’s manager and soon after that the team was using TDD. Fortunately, this was an outlying instance, since we value the Agile Manifesto principle of trusting teams to get the job done in the way that is best for them. To be fair, TDD has a very long learning curve, and it is normal to have some people resist because it is a very substantial change in how one works.<br />
<br />
In another case a team that was given a large newly released application to support, because of the training, recognized quickly that the code they had inherited was challenged in terms of fragility and difficulty testing. The team reached out to one of the coaches, received in-depth coaching on how to deal with the problematic code and within less than a month became self-sustaining and was already seeing improvements in the code quality.<br />
<br />
Creating the initial training materials was a very substantial task. It took two experts about four months to assemble an appropriate test tool stack and create the three week course. We then started running teams through the course, and following up with those teams afterwards by traveling to their location and staying for several months, sitting with the teams to see if they needed help putting what they had learned in a classroom into practice on their actual project. Our goal was to cement in what they had learned in an actual work setting. Training experts will note that our approach was therefore both experiential and contextual.<br />
<br />
At the same time, we sought out those with an agile mindset and technical expertise for taking on the role of internal agile technical expert. This enabled the organization to have continued expertise, long after we left.<br />
<h2>
How this all works together</h2>
Training an entire team together was very effective because it was then possible to assess the outcome for the team’s work, and also because no one was missing from a team when others were not. The entire team was offline together, making themselves more productive as a group. This made it a team learning experience: they all shared a common training experience and therefore shared training reference points. It was a shared journey. Management reporting later focused on team performance with the new skills rather than on individual performance.<br />
<br />
Having a standard set of tool stacks was essential, both for training purposes, and for sharing techniques across the organization. The intention here is not to standardize and prevent the use of alternative tools, but to create a common evolving baseline to foster communication and cross training. The standard test tool stack also made it possible to rapidly stand up the tools on a tester’s workstation – appliance-like. Testers who have transitioned to becoming test programmers are often less experienced technically than software developers, and installing and maintaining complex tools is potentially frustrating for them, making automated installation very helpful.<br />
<br />
Many organizations with remote locations want to use Web based training for agile methods. There is no reason that Web based training cannot be used, and indeed there is a-lot of Web based training available for some of the tools. For example, to learn the tool called “git”, you can use <a href="https://try.github.io/levels/1/challenges/1" target="_blank">this online interactive tool</a>. However, we wanted to have an intense, immersive experience in order to ensure that developers were entirely focused on the training, in a group setting. The amount that needs to be learned is very broad and deep, and immersion is necessary. If the training were not in a classroom, then it is anticipated that people would not be allowed to devote entire days to it, which is what is needed in order to ramp up quickly. The whole point was to bite the bullet and make in investment and then reap the benefits as quickly as possible.<br />
<br />
Assessment is always part of a learning program. Any teacher knows this: you need to test students. The highly innovative <a href="https://www.khanacademy.org/" target="_blank">Khan Academy</a> system is built around continuous individual assessment through an automated dashboard and progression to the next step when assessment criteria have been met, allowing each student to progress at his or her own rate. We realized that we needed to build assessment into our training process, to both assure that it was effective and to measure its effectiveness, which we felt was true to the empiricism of agile. Thus, after a team was trained, the team was strongly encouraged to not only record and display their code quality and test coverage, but also demo to the business their progress on a regular basis. This was done by integrating their test coverage tool, code quality tool and automated build output into an aggregated dashboard, which we then shared with management in a bi-weekly presentation. Reporting test coverage was mandatory and this was strongly supported by group management. Management was able to see the test coverage of teams that had been trained, and they were able to see that more and more teams were trained over time. This helped to assure management that the very substantial investment of the team’s time in training was worthwhile. It also provided an important metric for agile adoption, since technical practices are a key part of agile. In addition to reporting test coverage, agile coaches working with each team provided subjective assessment of each team’s progress, generally focused on impediments that management could do something about or should be aware of.<br />
<br />
<div style="text-align: right;">
<span style="color: #d9ead3;"><span style="font-size: large;"><i><b>We found that many (but not all) testers could be turned into test programmers in ~ 3 weeks.</b></i></span></span></div>
<br />
One of the most interesting discoveries was that most testers can become test programmers. The IT role of “tester” is generally applied to someone who conducts manual acceptance testing, consisting of writing “scripts” and then executing those scripts each time testing is needed. These scripts are written instructions for what to do to test the application, generally consisting of clicking on links, entering data into forms, checking the results that are displayed, etc. It is enormously tedious and labor intensive. Manual testing of this kind is not compatible with agile projects because agile projects rely on <i>continuous</i> testing, and that continuous testing is what enables one to have the short two week development iterations. It is therefore imperative to shift to using automated tests wherever this is possible. The question is, what do you do with all of your testers?<br />
<br />
We found that most – but not all – testers could learn how to write automated tests. Automated tests are programs: they are <i>test programs</i>. They are executable code. This means that testers become programmers. Some testers are anxious to learn programming and are able to make the transition. Others are not. We found that among those who were, they were able to become productive test programmers after about three weeks, provided that they had a testing tool stack set up for them and the mentorship of a test automation coach.<br />
<br />
We also took the same build, measure and dashboard system and began using the same techniques for software developed by external solution providers. This enabled us to measure the code quality of that software. Code quality ties back to many things such as standards compliance, test coverage, complexity, and other attributes. Using this approach we were able to convince contract management to add quality clauses into contracts. This also separated the vendors who said they were Agile from those who really were Agile in their technical practices. It also exposed a huge problem with one very large vendor in particular which resulted in a significant reduction in cost, potential liability and support problems. Overall, the use of code quality metrics helped in both supplier and contract management. One program utilizing this platform realized a multi-million dollar savings by informing the program managers on the relative quality which resulted in a significant reduction in support and re-work.<br />
<h2>
“Our space is too complex”</h2>
The same techniques have also been successfully applied in the embedded machine systems space. While significantly more complex and overall systems complexity is higher, the same delivery mechanism, teaching/coaching approach and condensed highly impactful training has been just as effective. Cost savings are more significant in this space, especially when moving more testing away from hardware-in-the-loop testing to more automated software-in-the-loop testing, reducing capital expenditures.<br />
<br />
So far, we have not found a software space that did not benefit from this approach.<br />
<h2>
Conclusion</h2>
The general approach used here was highly effective, and it can be replicated outside of the domain of testing and continuous integration. For example, we believe that it can be applied to enterprise architecture, to governance, to release management and deployment, to security, and generally to any specialized area that is part of the solution delivery pipeline. The legacy approach of having discrete steps that are performed by different groups in sequence then gives way to an approach in which the development team performs every function, but with the support of specialists through training, coaching, automated testing, and process oversight. The role of specialized groups changes from doing to teaching; from being a gatekeeper to being a guide; from inserting speed bumps to helping teams to create a safer path.<br />
<br />
<br />
<a href="https://www.linkedin.com/in/sbarnesx" target="_blank">Scott Barnes</a><br />
<a href="https://www.linkedin.com/in/cliffberg" target="_blank">Cliff Berg</a>Cliff Berghttp://www.blogger.com/profile/02103767196153470434noreply@blogger.com0tag:blogger.com,1999:blog-8391404601343318983.post-42797935680338339582014-09-28T18:36:00.000-04:002014-10-01T21:21:51.980-04:00Key Transformation Step: Establish Agile Release Planning<span style="color: orange;"><i>The come to us at the last minute, and then complain that we can’t create their production test environment when they want it!<br /><br />They come to us at the last minute, and then despair that we don’t have any testers available and also wonder why they don’t have any automated testing set up!<br /><br />They come to us at the last minute, and then wonder why the security review is going to delay their application’s deployment!<br /><br />They scheduled their performance testing for the end, and then wonder why they have no time to fix the problems that were found!<br /><br />They ignored the enterprise architect’s advice and designed their app with no regard for enterprise standards, and then wonder why people are upset!<br /><br />They talk about continuous delivery, but we are the ones who have to operate their app, and they have not designed it be easy to operate, and so they wonder why we are having trouble restarting instances!</i></span><br />
<br />
These are common laments from “functional managers” in large organizations that are trying to go agile. Functional managers are those who are responsible for traditional development lifecycle “steps”, such as enterprise architecture, security, testing, quality assurance, release management, deployment, operations, and other “silos” of a typical legacy IT organization. Agilists often blame these silos for the problems, but that is not helpful, and in fact agilists are brought in to help to streamline things, so they need to have answers about how to replace these functions with their agile equivalents.<br />
<br />
Replacing functions is a huge step, however. A great deal of learning is required for an organization to go agile, and most organizations need intermediate steps. One of the most effective intermediate steps – one that fosters the required learning – is beefing up the release planning process, to make it more inclusive. In other words, invite each of these silos: get them in a room and talk through the issues, so that nothing is left for the end of the release when there is no time left. Allow people advance notice of what is coming, so that they have time to manage their own processes and their own workloads.<br />
<br />
Busy functional managers will not always have time to attend each project’s release planning session. They will want to send someone on their behalf – one of the technical staff. That means that you need to give them advance notice of a release planning session and what the project is about, so that they can see who is available and send the right person. You also should tell them that it will be optimal if that person can be the one who continues to work with the team throughout development, as needed: that might affect who the functional manager sends, based on that function’s resource work schedule.<br />
<br />
Not everyone needs to be in a release planning meeting from beginning to end. A release planning meeting can take from an hour to several weeks, depending on whether the project is new and how complex it is. If you expect it to take more than a few hours, it is best to plan which issues will be discussed when, and invite the right functional representatives for those time slots: they will be appreciative. However, there might be some topics for which you want everyone there. More on that in a moment.<br />
<h2>
<span style="font-size: x-large;">
Release Planning Topics</span></h2>
So what happens during this type of release planning? What things should you talk about?<br />
<br />
The answer is conceptually simple: talk through all of the top level issues that affect what will be done, who will do what, how it will be done, and how things will work. I call these the conceptual pillars:<br />
1. The core vision and high level requirements.<br />
2. The team roles and collaborative processes.<br />
3. The core design concept.<br />
4. The development pipeline.<br />
5. The testing strategies.<br />
6. The external dependencies.<br />
<br />
Most agile teams focus a great deal of attention on #1 – the release backlog. That is indeed the foundational element: it is what you will be building. So I am not going to say any more about that: everyone reading this knows all about it. There are books on how to do it, and it is part of core agile training. Teams also generally spend time on #2 – team roles – but not sufficiently, so I will discuss that below.<br />
<br />
The rest of the pillars are things that teams often miss. These things are really important for continuous delivery (CD). Without nailing these, you will have a hard time getting to CD: you will find things not working well. Let’s take them one by one.<br />
<br />
<h3>
#2: Team roles and collaborative processes</h3>
Many teams come up with a list of team roles beyond the fairly common Scrum roles of Product Owner, Scrum Master, and Team Member. The additional roles accommodate the “silo” processes that are imposed by the organization. Remember, baby steps ;-) Such “extended team” roles might include test programmer, acceptance tester, QA analyst, security analyst, agile coach, project manager, tech lead, enterprise architect, release management liaison, data center engineer, and so on. The point of this discussion is not to get into what each of these roles might do and whether it is needed: it is assumed here that the organization currently requires these roles, and the discussion here is how to accommodate them so that everyone can do their job in the most agile way possible.<br />
<br />
Agile teams make a-lot of decisions in ad-hoc discussions. The problem is, when there are extended team roles such as those listed above, those roles are easily excluded from the ad-hoc discussions, yet these discussions often impact those functions. It works the other way too: these extended team roles often make choices that affect the team. All these call for more communication: the extended team and the immediate team (development team) must collaborate on an ongoing basis, as needed. During release planning, it is important to discuss this important issue with each of the extended team roles, and collectively decide what the best method is for collaborating in an ongoing manner and keeping each other up to date. Simply asking everyone to join the standup might not be the best way: there might be too many people, and they also might not all be available at the standup time. Work out what makes sense. I am not even going to propose an approach here, because there are so many ways and each functional area will have such different collaboration needs.<br />
<br />
<h3>
#3: The core design concept</h3>
The Scaled Agile Framework (SAFe) talks about “<a href="http://scaledagileframework.com/architectural-runway/" target="_blank">architecture runway</a>”. Scott Ambler has long talked about “<a href="http://www.drdobbs.com/architecture-and-design/disciplined-agile-architecture/240007451" target="_blank">agile architecture</a>” and “<a href="http://www.agilemodeling.com/" target="_blank">agile modeling</a>”. Feature Driven Development (FDD) talks about the importance of modeling the business at the start of a project (great explanation <a href="http://www.agilemodeling.com/essays/fdd.htm" target="_blank">here</a>) to establish a shared conceptual understanding of key data and relationships. (Note: I was on the Singapore project that the article refers to.) The importance of having face to face, early discussions about the primary models and design patterns is extremely important. This is <u><i>not</i></u> “big design up front” (BDUF), in which too many details are figured out too early. Instead, early discussions about models and design get everyone on the same page, using “broad brush strokes”. This greatly catalyzes future discussion and increases the “emotional intelligence” of the team as a whole. It is about Peter Senge’s <a href="https://en.wikipedia.org/wiki/The_Fifth_Discipline" target="_blank">Five Disciplines</a>: establishing and exchanging models of understanding and working to resolve those.<br />
<br />
Up front high level modeling and analysis also informs decisions about what kinds of testing will <i>probably</i> be needed, what components and services will <i>probably</i> be needed, what the major interfaces of the system will <i>probably</i> be, and who needs to be involved when, because all of these choices vary with different technology stacks and different design requirements. And I emphasize the word “probably” in all this because up front decisions are always subject to change: they are merely a starting point.<br />
<br />
There is no better time to establish the architecture runway than at the start of the project (or release), in an all team discussion, including those members of the extended team who might be affected. For example, some technologies are easier to deploy using automation than others, and a data center representative should be present for discussions about how the design might affect deployment – that is, if continuous delivery is important to you, and if the development team does not have direct access to the production deployment environment.<br />
<br />
<h3>
#4: The development pipeline</h3>
The “pipeline” is the end-to-end process from the Product Owner’s conceptualization of features through deployment, operation, and maintenance of an application. It even extends farther than that, but this scope is fine for this discussion.<br />
<br />
Defining the pipeline consists of talking through and deciding what will happen when, why it is happening, how it will be done, who will do it, where it will occur, and what the acceptance criteria are. It extends to <i>everything</i> that is involved in the planning, creation, release, and operation of the software. Not all of these decisions need to be made up front, but it is crucial to get everyone together and agree on the basic outlines of the process, and identify decisions that still need to be made and who “has point” on those decisions. This is about designing the continuous integration and continuous delivery process as a whole, looking at it as a system.<br />
<br />
When defining the pipeline, make sure that you also define how progress will be tracked for every aspect of the pipeline. The software development team uses agile work management tools such as a story board, which makes its progress very visible. There needs to be equivalent visibility for the work of the extended team, aggregated in a manner that the development team, as well as management, can see at a glance what the rate of progress is (“velocity”) and what is holding things up (“blockages” or “impediments”). It might be hard to aggregate this information because each silo area generally has its own work management tool, but this aggregation is perhaps something that the project manager can do, if there is one. Alternatively – and this is more agile – each extended team member can update a shared task board, possibly on a project wiki, that tracks the external tasks that the development team is depending on.<br />
<br />
<h3>
#5: Testing strategies</h3>
Agile teams know a-lot about testing. Agile turns testing into programming: testing is replaced by test programming. This is not new – I did lots of this during the 1980s and I am sure many others did it way before that – but agile emphasizes the importance of it, as an enabler for continuous integration, whereby code is not checked in until it passes all the tests, and this is done frequently – often many times a day.<br />
<br />
There is a gap here though. Most agile testing practices focus on functional testing. Continuous delivery requires that we expand that, to include every kind of testing: failure mode testing, scalability testing, security testing, and whatever other kind of testing is required for production deployment. Also, many agile teams forget to plan for test data. If you will need complex test data from a business area, invite that business area to the release planning session and pin down how the test data will be created and when it will start to be available.<br />
<br />
<h4>
The Definition Of Done – Revisited</h4>
Teams often define a “definition of done” (DOD) that lists the criteria that all stories must meet in order for them to be considered “done”. The DOD usually specifies that all functional tests have passed. This is not easily extended to other kinds of tests, because non-functional tests are often not story-specific, and some kinds of tests, e.g., full performance tests, are not tests that you want to run many times during an iteration. We therefore need to expand the DOD concept in some way.<br />
<br />
One approach that I have seen work is to have the DOD apply only to tests that are story-specific. These are generally acceptance tests. There needs to be an automated suite of acceptance tests to make this feasible, and they must be organized by story, built around the each story’s acceptance criteria. That is pretty common agile practice. Other tests that are not story specific should not be covered by the DOD, but instead should be run many times during an iteration. This can be nightly for some, or nightly for others if they take a long time to run. Integration tests fall into this category, and they are often run when code is checked in. Again, it depends on the duration of and resources required by the tests.<br />
<br />
Some failure mode tests are story specific, and others are not. For example, stress tests are generally not story specific, and they should be run on a regular basis, but not necessarily every time code is checked in.<br />
<br />
Security tests are especially problematic. You might even wonder, What are security tests? Many teams now add code scanning to their CI process. Code scanning is not enough though if you want to have secure code. To have secure code, you need to make an “assurance argument” for each feature that you design, and you need to verify through analysis that the assumptions of that assurance argument are met. (There is a good discussion <a href="http://www.sei.cmu.edu/dependability/tools/assurancecase/" target="_blank">here</a>, but an “agile” approach to this should be less structured and more based on the programmer’s knowledge of secure design patterns. That is the primary topic of my book High-Assurance Design. For secure design patterns, see also the book Core Security Patterns by Steel et. al., and visit <a href="https://www.owasp.org/" target="_blank">owasp.org</a> for Web app security techniques.) Note that this is an analytical process – not a testing process. However, it can be turned into a testing process by testing that the assumptions of each assurance argument remain true. Tools such as Fortify can be used for this purpose. Not many agile teams do this today, but as security becomes more important, it is essential that teams start to learn these techniques, because security scanning will never be sufficient, as it catches only a small fraction of vulnerabilities. (See <a href="http://samate.nist.gov/docs/SA_tool_effect_QoP.pdf" target="_blank">this article</a>.)<br />
<br />
<h4>
Test Coverage</h4>
To achieve continuous delivery, you have to have confidence that your automated test suite is verifying that everything that presents a substantial risk is covered. Notice that I said “substantial”. Life is full of tradeoffs: continuous delivery carries the great benefit that you can push changes to users as quickly as you want to, but it does not eliminate all risk. Some things will slip through your tests, so you need to make sure that the risk is acceptable – not zero.<br />
<br />
The question is, how do you know how complete your tests are? For functional tests, we measure test coverage. Test coverage needs to measure how completely the requirements (functional and non-functional) are met. For continuous delivery, the non-functional tests become just as important as the functional ones. But how do you measure “coverage” for security? For performance? For reliability? For enterprise architecture compliance? For maintainability?<br />
<br />
The first step is to actually define those requirements. The next is to add them as acceptance criteria, either at a story level, or at a system level. The system level acceptance criteria apply to the tests that are not story specific. Coverage for performance means that all performance requirements are met. The same applies to each other area. Work with the extended team members to define what coverage should mean for each of their areas, and how it can best me measured or assessed, as automatically and repeatably as possible.<br />
<br />
<h3>
#6: The external dependencies</h3>
Dependencies on events beyond the development team represent immense risks that are generally beyond the control of the team. I am not talking about dependencies on the work that needs to be done by the extended team, because we already already discussed that. Here I am referring to things that are beyond the control of even the extended team: things like the arrival of equipment from a supplier, the availability of a test instance of a system from a third party, etc. This is an area in which a project manager – if you have one – can really help: by persistently pursuing external dependencies.<br />
<h2>
<span style="font-size: x-large;">
Recap</span></h2>
Functional silos like this are <i>not</i> compatible with agile. Agile
and continuous delivery work best if the development teams have full
responsibility and control for every step of the solution development
and delivery pipeline, rather than relying on external parties to
perform isolated steps independently. However, for it to be possible for
the development teams to have full control, they need to learn the many
skills and concerns that are represented by each silo area. QA exists
for a reason. Release Management exists for a reason. That learning
takes time.<br />
<br />
Eventually the silos can be converted into training
and coaching teams that teach development teams about security,
regulatory compliance rules, test automation, deployment, and all the
other things that these silos currently do. Some of the silo functions
will go away entirely, or will transform: QA can shift from checking
documents to performing actual assessment of risk coverage by the
automated tests – including the non-functional tests. Security can shift
from scrutinizing security plans to teaching teams how to conduct
threat modeling and how to use tools such as Fortify more effectively.
Testing can change from providing manual testers to teaching teams how
to set up and use test automation tools. The silos change from being
functions that “do” to functions that “teach”. That takes time though:
all those functions need to change to make that possible. They must
learn about using more automation, they must learn about teaching and
coaching, and they must learn about how development teams work. Setting
up a collaborative relationship between the teams and the silos at the
start of each project is a crucial first step.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgyEsnyUFcKBXMjwTtwX-ZowRWZXJabSr3Zlijid0ycY2Ja9ASYiNHA0vmqUTjk0OCvwH4gsnchmfifdb3IBpaOdQxJMAzJmubBkw_rzpLsVnmhSNVF98J5syzvvlzdUj7TLx8ZeWvxe71V/s1600/Conceptual+Pillars+Of+an+Agile+Project.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgyEsnyUFcKBXMjwTtwX-ZowRWZXJabSr3Zlijid0ycY2Ja9ASYiNHA0vmqUTjk0OCvwH4gsnchmfifdb3IBpaOdQxJMAzJmubBkw_rzpLsVnmhSNVF98J5syzvvlzdUj7TLx8ZeWvxe71V/s1600/Conceptual+Pillars+Of+an+Agile+Project.jpg" height="480" width="640" /></a></div>
<span style="font-size: x-small;">PDF <a href="https://drive.google.com/file/d/0By4lfBwI0rt6THduOWNuX2tWSWs/edit?usp=sharing" target="_blank">here</a>.</span>Cliff Berghttp://www.blogger.com/profile/02103767196153470434noreply@blogger.com0tag:blogger.com,1999:blog-8391404601343318983.post-30857457152515588012014-09-15T11:13:00.001-04:002014-09-15T14:49:23.278-04:00New section launched: Agile Around the World<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjOrfrj9pjiRa9hPSe-tJLTJiQMLP7GwPCCB1NtmYHXCG9c3DSDP4G_OTEv4B7QuoJ-VSteo7zMhrNk0Yd1wOJhJAeuqKNU4snm5291d7huefWVszwTh-lYGvh9IpUfj1yJw0ngdbhwDmP-/s1600/Globe.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjOrfrj9pjiRa9hPSe-tJLTJiQMLP7GwPCCB1NtmYHXCG9c3DSDP4G_OTEv4B7QuoJ-VSteo7zMhrNk0Yd1wOJhJAeuqKNU4snm5291d7huefWVszwTh-lYGvh9IpUfj1yJw0ngdbhwDmP-/s1600/Globe.png" height="198" width="640" /></a></div>
With today's interview of <a href="https://www.linkedin.com/in/madhurkathuria" target="_blank">Madhur Kathuria</a> we launch a new section, <i><b>Agile Around the World</b></i>. In this section we focus on the way that regional and international cultures impact agile adoption efforts and the strategies that are most effective. Read the interview <a href="http://www.transition2agile.com/p/sekhar-madhur-i-see-you-have-good.html">here</a>!<br />
<br />
<br />Cliff Berghttp://www.blogger.com/profile/02103767196153470434noreply@blogger.com0tag:blogger.com,1999:blog-8391404601343318983.post-31530939117209669202014-09-11T10:40:00.000-04:002014-09-13T11:18:40.640-04:00How Can Agile Support Business Agility?At the end of 2012 Iberia Airlines embarked on a transformation to return to profitability. Some of the <a href="http://www.iairgroup.com/External.File?t=2&item=g7rqBLVLuv81UAmrh20Mp6P4sIZFMOWm2doN0RkQYqRYDShR8uqRf7Z/ZFYQISiESN8CSdVu34t8q3qUYvLL2A==" target="_blank">highlights of the transformation plan</a> were:<br />
1. Stem Iberia's cash losses by mid-2013.<br />
2. Turnaround in profitability of at least €600 million from 2012 levels to align Iberia with IAG's target return on capital of 12 per cent by 2015.<br />
3. Network capacity cut by 15 per cent in 2013 to focus on profitable routes.<br />
4. Downsizing its fleet by 25 aircraft - five long haul and 20 short haul.<br />
5. Reduction of 4,500 jobs to safeguard around 15,500 posts across the airline. This is in line with capacity cuts and improved productivity across the airline.<br />
6. New commercial initiatives to boost unit revenues including increased ancillary sales and website redesign.<br />
7. Discontinue non-profitable third party maintenance and retain profitable ground handling services outside Madrid.<br />
8. The transformation will be funded from Iberia's internal resources.<br />
<br />
Basically, Iberia needed to pivot – and pivot hard and fast. Here is a quote from Rafael Sánchez-Lozano, Iberia’s CEO: “Time is not on our side. We have set a deadline of January 31, 2013 to reach agreement with our trade unions. We enter those negotiations in good faith. If we do not reach consensus we will have to take more radical action which will lead to greater reductions in capacity and jobs”.<br />
<br />
Negotiations with the union <a href="http://www.economist.com/blogs/gulliver/2013/03/strikes-iberia?zid=303&ah=27090cf03414b8c5065d64ed0dad813d" target="_blank">were ultimately successful</a> and the company has <a href="http://centreforaviation.com/analysis/iag-back-in-profit-british-airways-profit-doubles-iberia-losses-narrow--vueling-shows-its-worth-155353" target="_blank">nearly returned to profitability</a>. One of the reasons cited for the success was that, “Iberia’s move to make 3100 staff redundant and axe 23 aircraft helped it cut its operating loss by €185 million to €166 million.” [<a href="http://www.independent.co.uk/news/business/news/iag-returns-to-profitability-on-iberia-overhaul-9160554.html" target="_blank">http://www.independent.co.uk/news/business/news/iag-returns-to-profitability-on-iberia-overhaul-9160554.html</a>] But according to the same article, “…cargo revenues collapsed by almost 12 per cent, and Walsh [CEO of IAG – Iberia’s parent company] warned not to expect too much, too soon. ‘It’s going to be a better year, but the environment is still lower than where we were at the peak.’ ”<br />
<br />
From the article, “BMI and Vueling have been the only acquisitions, and today Walsh added: ‘We haven’t got anything planned at the moment, but we are always keeping our eyes open,’ and called on the Government to change its rules because ‘people want to come to London, but many don’t because they struggle with the visa regime.’ ”<br />
<br />
How might agile fit into any of this? Certainly not in the union negotiations – not unless you change the collective bargaining process, but as they say, one should “pick one’s battles”. Certainly not in the lobbying of the government to change visa policies – that is an art that happens behind the scenes with little transparency (and that itself is not very agile and is a problem – but changing that is surely an even steeper hill to climb).<br />
<br />
And one might presume that agile is not applicable in the consideration of possible acquisitions – or is it? Merger and acquisition (M&A) analysis is a highly complex financial and strategic analysis process, often supported by simulation models – along with judgment on the part of seasoned executives who have prior experience in M&A. Those kinds of decisions are not made using a “business model canvas” – there is too much at stake, and one cannot usually pivot if things don’t work out: it is game over – at least for the chief executive. Can agile apply to this process?<br />
<br />
The kinds of complex financial modeling that these kinds of businesses do for an M&A involves defining multiple scenarios and creating a model for each, and often running simulations of the scenarios to account for external variables that might change over time (interest rates, costs, demand, and indirect factors that affect these) as well as various types of future events that would affect the outcome (e.g., a new competitor appears on the scene, or there is a labor strike). The parameters of these scenarios are subject to debate, as are the scenarios themselves. Collaboration between executives and the economic analysts would surely be very valuable, rather than trusting a team of analysts to come up with the numbers and merely present them as fact. High quality models should explicitly account for uncertainty, and that uncertainty is also open for debate, because this kind of modeling is an art – not a science. The scenarios are up for debate because a scenario presumes a strategy: strategies are defined as scenarios and then compared. Strategies could be cast in understandable terms, and then the details filled in by the economic modelers, with key parameters called out. Pivoting might even work in some cases: for example, an airline could try a new strategy on some routes before scaling up the strategy. However, if things have come to a point of crisis, there might not be time for trying things out or “failing early” – one might be forced into a situation of making an existential gamble.<br />
<br />
<div style="text-align: right;">
<span style="color: #d5a6bd;"><b><span style="font-size: large;"><i>Managing in a crisis is actually easier than otherwise, because people will shift all of their priorities without resistance: survival is at stake.</i></span></b></span></div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEis79YxYRgWuYxEe5efQx4bL5EJdp2T1qTguaZnznw073qC4-J0cdPpin2cLXPTbrRjg-JTRU4M5LU9p0h9oFtsTE33YPX_PgOPBujQckGxvZeVK5IKF_t_bOnP-eJ5L3yciFtiNSwE225b/s1600/Healt13.gif" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEis79YxYRgWuYxEe5efQx4bL5EJdp2T1qTguaZnznw073qC4-J0cdPpin2cLXPTbrRjg-JTRU4M5LU9p0h9oFtsTE33YPX_PgOPBujQckGxvZeVK5IKF_t_bOnP-eJ5L3yciFtiNSwE225b/s1600/Healt13.gif" height="116" width="200" /></a></div>
Iberia was clearly in a crisis: according to Sánchez-Lozano, “As well as halting Iberia‟s financial decline we will establish a viable business that can grow profitably in the long term.” Thus, the first element of the plan was to stop the bleeding, making cuts by “suspending loss making routes and frequencies and ensuring there is effective feed for profitable long haul flights.” This immediate triage required decisive executive action – an important form of leadership in a crisis but not always the best form for long term durable changes.<br />
<br />
Managing in a crisis is actually easier than otherwise, because people will shift all of their priorities without resistance: survival is at stake. Things get more difficult when the crisis has passed. Enduring change for systemic problems is much harder to achieve. That’s why one must ask, How did we get here? Walsh said, “The boom years are definitely behind us, and I can’t see anything that will bring us back to those levels of growth.” So the environment changed: it was external factors in this case. Or was it? Why did Iberia not position itself for more resiliency? Airlines are highly competitive and operate on very thin margins, and Iberia has a union, so maybe it was not possible to build in a buffer for hard times. We cannot know from the outside.<br />
<br />
Item 6 of the plan also gets my attention: new commercial initiatives. This is always a fertile area for agile methods – including the business model canvas. Another area that comes to mind is increasing efficiency, using Lean techniques. Especially given that the airline had to restructure, and implement mergers, there was surely an opportunity for collaborative management and the application of Lean methods for defining new and better ways to operate – perhaps even innovative non-hierarchical decision-making structures. And of course, having an IT function that is ready to execute with rapid delivery is the most obvious way to support business agility.<br />
<br />
Even though much of agile has its roots in business, most people in the agile community today work in an IT setting and that setting is the bulk of their experience. If you are an agilist in an IT setting, and would like to advocate for the use of agile ideas in a broader business context, the question is, How should one engage with business stakeholders on these issues? Business stakeholders generally have years of experience in business operations and often have MBAs and financial training. They also often have market facing experience that provides them with judgment about external opportunities and risks, as well as profit-and-loss responsibility experience that grounds their judgment about operational risks and makes them very results oriented. An IT agilist seeking to have a dialog with someone from a business area on how to apply agile in a business context – rather than merely an IT software development context – needs to win the trust of the business stakeholder. That stakeholder rightly feels that they know a-lot and that they understand their business much better than someone from IT. Talking to them is therefore an opportunity to collaborate – not to teach.<br />
<br />
A good approach is to express an interest and listen, and bring lots of humility. These people do not need to be told that if they would merely “go agile” that all of their challenges would be solved. Nor will they be interested in learning an entirely new vocabulary, so it is best for an agilist to learn business equivalents for agile terms wherever there is one. Instead of “velocity”, say “throughput”. Instead of “spike”, say “prototype”. Instead of “fail fast, fail early”, say “do a prototype”. Instead of “team happiness”, say “team morale”. According to <a href="https://lindaberens.com/" target="_blank">Linda Berens</a>, an expert on human agility and a partner in HolacracyOne, “Communicate in the style the client most likely wants and using the words they most easily understand.” [<a href="https://lindaberens.com/consulting/communicating-well-with-non-technical-people/" target="_blank">https://lindaberens.com/consulting/communicating-well-with-non-technical-people/</a>]<br />
<br />
Business agility is a complex topic and we need to be careful not to presume that agile – as understood and experienced in an IT context – has all of the answers for how to run a business. However, many of the ideas are greatly applicable. The best way to find out which ones is to start a dialog, show an interest, listen before you speak, and then share your own experiences. Business people need to learn about today’s IT as much as IT people need to learn about today’s business – they simply do not know what they don’t know (that applies to both camps) – but to get them to listen, you need to get them to trust you, and the best way to do that is to acknowledge their experience, knowledge, vocabulary, and points of view.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjyuCqHClkYYSV1M8YYdhDL8EMxwwnoKimAdFcJcBs-7uC6cVEU9vKo2r_tueMPlE4wWmF2Z95X4JnyrF0ekQKlvaBJiB01yNIbiwyEeK19HPwjX3c4RAOO5bzq8LHD0fUYBkZuSkJ_Nz4A/s1600/Tips+For+Discussing+Agile+With+Business.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjyuCqHClkYYSV1M8YYdhDL8EMxwwnoKimAdFcJcBs-7uC6cVEU9vKo2r_tueMPlE4wWmF2Z95X4JnyrF0ekQKlvaBJiB01yNIbiwyEeK19HPwjX3c4RAOO5bzq8LHD0fUYBkZuSkJ_Nz4A/s1600/Tips+For+Discussing+Agile+With+Business.jpg" height="480" width="640" /></a></div>
<a href="https://drive.google.com/file/d/0By4lfBwI0rt6cUpSNjRLSmRsams/edit?usp=sharing" target="_blank"><span style="font-size: x-small;">As PDF.</span></a>Cliff Berghttp://www.blogger.com/profile/02103767196153470434noreply@blogger.com0tag:blogger.com,1999:blog-8391404601343318983.post-86554900199435685192014-09-07T14:22:00.003-04:002014-09-07T17:08:47.828-04:00DevOps and Security – How Is It Possible?Traditional IT approaches to security entail careful step-wise processes of design, review, testing, and monitoring. These steps are usually separated by gates: software is not permitted to progress to the next step until it has met the criteria of a gate review. How can such a careful and step-wise process be used in concert with a <a href="https://en.wikipedia.org/wiki/Devops" target="_blank">DevOps</a> pipeline, which requires that software be delivered to production continually and with little delay?<br />
<br />
The challenge is made more difficult by a fundamental fact about security: security is about negative requirements. That is, security requirements are often that a certain thing can<i><u>not</u></i> be done, rather that it can be done. Such negative requirements are notoriously difficult to test for, and creating automated tests for these types of requirements is even more difficult. Yet, DevOps relies on the ability to create automated tests for everything.<br />
<br />
Before I go any further, I should say a little about the lay of the land – the scope of what is encompassed by IT security. IT security is often thought of in terms of the levels of a “stack”, such as (starting from the bottom) network, OS, application platform, applications, and user (this is an over simplification). It is really, really important for applications to have a secure application platform, OS, and network: otherwise, the application cannot trust the services that it uses from those levels. In my discussion here, I am only going to talk about the application platform and up, because those are <a href="http://www.amazon.com/High-Assurance-Design-Architecting-Enterprise-Applications/dp/0321793277" target="_blank">things that I know something about</a>.<br />
<br />
Application platforms are software systems that enable programmers to create customized applications. Examples of such systems include databases and application servers. It takes a-lot of time and effort to secure these platforms, and so it is advisable to create standard configurations that can be reused across all of your software projects. In the control-oriented parlance that is used by government agencies, you can have a fixed set of application platforms that meet the requirements of the applicable controls, and those controls can then be “inherited” by systems that use those platforms – assuming that the configurations are not changed. This approach is very “DevOps friendly” because no testing of the application platforms is required during development or deployment if the application platforms use the standard configuration that has already been verified as secure. The only issue then is when to upgrade the platform, when a new version is available: that’s not a simple issue but it is beyond the scope of the discussion here.<br />
<h2>
The undiscovered country – the application level</h2>
The next level of the stack is the application level, and that is where the fun begins. However, before worrying too much about application level security, you should ask yourself how much you are worried about a <a href="https://en.wikipedia.org/wiki/Targeted_attack" target="_blank">targeted attack</a>. A targeted attack is one in which someone singles out your organization and undertakes to penetrate it, spending perhaps months to achieve their goal. Not every organization is a likely target for this level of attack. Organizations that are include those that handle large volumes of slightly sensitive information (for example, credit card numbers), or small volumes of highly sensitive information (for example, plans for nuclear weapons). If you are not in these categories, then your organization is probably safe from a targeted attack, and it is unlikely that someone will go to the trouble to discover the unique vulnerabilities in your custom application code.<br />
<br />
If your organization <i>does</i> store sensitive information, then you are a potential target at the application level, and you should be thinking about how to secure the processes used to code and deploy your custom software applications. From a DevOps perspective, the goal is to automate as much security testing as possible.<br />
<br />
The most common approach to automated security testing of application code is to use code scanning tools, aka “<a href="https://en.wikipedia.org/wiki/Static_program_analysis" target="_blank">static analysis</a>”, or “static application security testing” (SAST). This is an old method, but it is continually refreshed to support the new application languages. Static analysis has its history in code quality analysis tools, going back to “<a href="http://www.unix.com/man-page/FreeBSD/1/lint" target="_blank">lint</a>” – a Unix tool that scans C language programs and finds potential bugs. Nowadays, one of the most widely used tools for code level security scanning is Fortify, but there are <a href="https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis" target="_blank">many others</a>. And one caveat: static analysis does not work very well for dynamic languages such as Ruby and Python.<br />
<br />
Static code scanning a crucial for security. It is not a silver bullet though. In fact, it has severe limitations: (1) it only finds a fraction of the vulnerabilities [<a href="http://samate.nist.gov/docs/SA_tool_effect_QoP.pdf" target="_blank">http://samate.nist.gov/docs/SA_tool_effect_QoP.pdf</a>]; and (2) static analysis generates a-lot of false positives – and by a-lot, I mean a-lot: I am talking about thousands of false positives for every actual problem found.<br />
<br />
The false positive problem is not as bad as it sounds, because some tools allow a programmer to flag a false positive as having been checked, so that it is not generated when the tool is run again later, although doing that carries its own risks. The more severe problem is that static analysis only finds a fraction of the vulnerabilities. Consider the latest IT security debacle in the news, in which private photos of movie stars were released to the public. Many of these photos appear to have come from the personal Apple iCloud accounts of the actors, and there is evidence that those accounts were penetrated using brute force guessing of passwords (a “<a href="https://en.wikipedia.org/wiki/Dictionary_attack" target="_blank">dictionary attack</a>”) in the Find My iPhone web application. This web application was apparently vulnerable to this type of attack because it permitted the user to try passwords again and again, without limit. [<a href="http://theconversation.com/novice-mistake-may-have-been-the-cause-of-the-icloud-naked-celebrities-hack-31272" target="_blank">http://theconversation.com/novice-mistake-may-have-been-the-cause-of-the-icloud-naked-celebrities-hack-31272</a>] Static analysis would not have detected this type of error: it was due to an application logic choice made by the programmer.<br />
<br />
There are other automated tools that can come to the rescue. For example, password cracking tools would have discovered the Find My iPhone flaw; but to know to use that tool requires familiarity with the range of security testing tools and what they are used for – there are so many tools, and one cannot blindly use them all. There are also “dynamic” tools that will try to penetrate a system while it is running, and those can be helpful. However, it is often difficult for these tools to know that something that seems ok is actually not ok. For example, how would a security scanning tool know that if an administrator logs in, that the administrator should not be able to read the data of users of the system? It cannot know, because such a constraint is a business rule, and tools cannot anticipate business rules.<br />
<br />
The challenge here is quite large: any programmer can write a line of code that will subvert all of the security tools that are in place. Whether this is done intentionally or unintentionally (that is, whether it is an insider attack or merely an error), scanning tools cannot read the minds of programmers and product owners and deduce what is an intended action versus what is an inappropriate action. The only real solution here is to have programmers educate themselves about application security, so that they make fewer unintentional mistakes. There are voluminous online resources for learning about application security, such as <a href="https://www.owasp.org/" target="_blank">https://www.owasp.org</a>. (See in particular [<a href="https://www.owasp.org/index.php/Testing_Guide_Introduction" target="_blank">https://www.owasp.org/index.php/Testing_Guide_Introduction</a>]) The organization could also provide incentives for developers to obtain <a href="https://www.isc2.org/csslp/default.aspx" target="_blank">CSSLP certification</a>. This is not a lightweight certification: it requires a-lot of work to obtain this, and it is highly worthwhile. Your team should also employ security analysis practices such as <a href="https://en.wikipedia.org/wiki/Threat_model#Approaches_to_threat_modeling" target="_blank">threat modeling</a>: threat modeling is a collaborative session in which the team sits in a room and tries to come up with ways to penetrate the application, based solely on the application’s design and code. It is a thought experiment. Its value is that it gets everyone on the team thinking about security. Your architects or technical leads should also be thinking about secure design patterns, applying concepts such as <a href="https://en.wikipedia.org/wiki/Compartmentalization_%28information_security%29" target="_blank">compartmentalization</a>, <a href="https://en.wikipedia.org/wiki/Principle_of_least_privilege" target="_blank">least privilege</a>, <a href="https://en.wikipedia.org/wiki/Separation_of_duties#Application_in_information_systems" target="_blank">separation of duties</a>, and privileged contexts (for a discussion and design pattern, see my book <a href="http://assuredbydesign.com/haa/" target="_blank"><i>High-Assurance Design</i></a>, p. 219). They should also be choosing robust security frameworks so that application developers have a trustworthy toolset for implementing security functions such as authentication and authorization.<br />
<br />
Before you undertake to secure all of your code, you should also think about where the risks really are. Generally, applications have only certain modules that need to perform sensitive operations. Identify those, and put your security testing attention and code review efforts on those. It is a waste of time to do threat modeling on parts of a system that do not do anything sensitive and do not connect to anything sensitive. A good starting point is to consider what the application’s “<a href="https://en.wikipedia.org/wiki/Attack_surface" target="_blank">attack surface</a>” is.<br />
<br />
Another thing to consider is how secure your development environment is: what good is your application level security if a hacker can get into your development git repository – possibly in a public cloud protected only by a password that is itself not well protected – so that the hacker can inspect your code for vulnerabilities or possibly even insert some malicious code into it? <br />
<br />
It is also important that security be treated as a first class application requirement. In an agile context, that means writing security stories that are put into the backlog. (Here is a good article: <a href="http://www.infoq.com/articles/managing-security-requirements-in-agile-projects" target="_blank">http://www.infoq.com/articles/managing-security-requirements-in-agile-projects</a>) It also means adding security acceptance criteria to all stories that have security ramifications. Knowing enough to do that requires a focus on security, as a critical application concern, from the outset. It requires having an application security expert on the team, involved from day one. And it requires a product owner who understands the importance of security: for example, if there is a stakeholder team that communicates requirements and concerns to the product owner, there should be a security stakeholder on that team.<br />
<br />
There is also the problem of external partners: other organizations that build pieces of a system that you then connect to and trust. Attacks often occur at the weakest link. In the attack on Target, in which millions of credit card numbers were stolen, the attack began with an attack on Fazio Mechanical, a heating, air conditioning and refrigeration company – a firm that Target had contracted. [<a href="http://krebsonsecurity.com/2014/02/email-attack-on-vendor-set-up-breach-at-target/" target="_blank">http://krebsonsecurity.com/2014/02/email-attack-on-vendor-set-up-breach-at-target/</a>] Target had no direct control over how secure Fazio’s systems and procedures were, yet Target gave Fazio access to Target’s systems. The lesson here is that if you have external partners, treat them as a potential weak link, and only give them the least privileged access that they need, and monitor their access with intrusion detection tools.<br />
<h2>
Deployment processes are application level code!</h2>
People often think of deployment processes as part of infrastructure and support, but DevOps changes that. An important aspect of DevOps is to implement all processes as code that can be put under configuration control and made automatically repeatable. That means that the people who create the deployment processes are writing code, and if this code is unique to the application, then it is best treated as application code, with all of the same quality considerations – including security. This means that all of the practices that you adopt with respect to writing secure code should apply to the deployment scripts and deployment configuration files.<br />
<br />
In a DevOps world, deployment does not stop at putting the code onto servers: deployment is about building the process for putting code onto servers, and that includes testing. That testing should include security testing. You do not want to burden your development build process with full blown security testing each time a developer checks code in. Instead, there should be a series of progressively thorough security testing the farther down you are in the continuous delivery pipeline. For example, the development build process should include basic static scanning, as well as other kinds of scanning by selected tools. Down the line there should be processes that are run periodically to perform script based penetration testing, password cracking, and “<a href="https://www.owasp.org/index.php/Fuzzing" target="_blank">fuzzing</a>”. Manual penetration testing should also be done on a periodic based – not merely at the end before release. Otherwise, there will be no time to fix problems within the scope of the agile timeline.<br />
<br />
Designing all of these processes is a significant architectural effort. It is not possible to have a standard process that will be appropriate for all applications. The types of security testing that are appropriate depend on the nature of the application and on its design. Design of the security aspect of the testing pipeline is therefore a companion activity of the application design. That said, it is possible to reuse the security testing pipeline to a large degree if the basic application architecture is reused.<br />
<h2>
The user – the weakest link</h2>
In the Target security breach, one can blame the security procedures of Fazio, yet it turns out that Fazio was compromised through the use of an email malware attack. This implicates users of Fazio systems – users who might have naively clicked on malware attachments or <a href="http://www.webopedia.com/TERM/P/phishing.html" target="_blank">phishing</a> hyperlinks. In the end, users are the weakest link.<br />
<br />
The only way to mitigate against security mistakes by users is to educate them. Users who do not have sufficient knowledge of the ways that they might be tricked into compromising systems should not be given access to those systems: it is that simple. Just as driving or flying a plane requires expertise to do it safely, the same applies to using computer systems that manage sensitive information. If you want to see the range of ways that users can be tricked, check out my own taxonomy of social engineering methods in section 5.2 of <a href="http://assuredbydesign.com/haa/chs/Berg_ch05.pdf" target="_blank">this chapter</a>.<br />
<br />
In the final analysis, security is not a DevOps issue: it is a human issue.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhDmdpDdxiK3i_YFxZp2OKDiUWUhx9hw-oluj78wp4zCoO37nIMhmvlzrgWuIafZ203RpEcg1voCgQ5TnnxyR5iQL3ZiBaAt2WoRAy88BDoTi_bo0cu-fcv5qu70mmGpJxTzmOyozCDjOUi/s1600/DevOps_Security.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhDmdpDdxiK3i_YFxZp2OKDiUWUhx9hw-oluj78wp4zCoO37nIMhmvlzrgWuIafZ203RpEcg1voCgQ5TnnxyR5iQL3ZiBaAt2WoRAy88BDoTi_bo0cu-fcv5qu70mmGpJxTzmOyozCDjOUi/s1600/DevOps_Security.jpg" height="480" width="640" /></a></div>
<span style="font-size: x-small;">PDF available <a href="https://drive.google.com/file/d/0By4lfBwI0rt6Y3Rtb2h1cHY0Nm8/edit?usp=sharing" target="_blank">here</a>.</span>Cliff Berghttp://www.blogger.com/profile/02103767196153470434noreply@blogger.com1tag:blogger.com,1999:blog-8391404601343318983.post-23096189946272603242014-09-04T11:40:00.000-04:002014-09-04T19:55:31.872-04:00Does Organization Culture Impact Strategy?Zappos, a maker of shoes, has been in the news a-lot lately because of its adoption of a “holacratic” operational model in lieu of a traditional management hierarchy. Zappos expects all of its employees to make their own decisions about everything, and to work things out with others through collaboration. To scale this, they have defined a governance structure for overlapping teams and how those teams make decisions. It is significant that Zappos only hires people who can thrive in this type of environment. The <a href="http://about.zappos.com/our-unique-culture/zappos-core-values" target="_blank">Zappos core values</a> are:<br />
<br />
1. Deliver WOW Through Service<br />
2. Embrace and Drive Change<br />
3. Create Fun and A Little Weirdness<br />
4. Be Adventurous, Creative, and Open-Minded<br />
5. Pursue Growth and Learning<br />
6. Build Open and Honest Relationships With Communication<br />
7. Build a Positive Team and Family Spirit<br />
8. Do More With Less<br />
9. Be Passionate and Determined<br />
10. Be Humble<br />
<br />
If your organization is made up of people who have these values, then you pretty much have no choice but to let them have a great deal of autonomy about how they work: they will not be successful any other way, because these are all highly individualistic, creative, and self motivated people.<br />
<br />
Now consider a government agency. The <a href="http://www.fs.fed.us/fire/people/hotshots/midewin/mission.html" target="_blank">mission and core values of the US Forest Service</a> are:<br />
<br />
1. Safety - Safety will never be compromised, regardless of the work at hand.<br />
2. Tradition, Pride and Respect - Don’t rest on the Hotshot name!<br />
3. Physical fitness and mental toughness - Rise to the occasion, strive to be the best.<br />
4. Productivity - An honest day of work in return for an honest day’s pay, regardless of assignment.<br />
5. Unity and Diversity - Communication and teamwork get the job done.<br />
6. Professionalism - Constantly being watched and evaluated… the details matter.<br />
7. Training - MIHC is committed to training quality leaders, both in the classroom and on the line.<br />
<br />
Do you see any mention of passion? Of embracing change? And notice that “training” replaces “pursue growth and learning”, indicating that employees expect to be trained rather than learning on their own. There is nothing wrong with these values – they are all good things – but they emphasize different things such as safety (some Forest Service workers do field work), tradition, and professionalism.<br />
<br />
This brings to mind the comments made in a <a href="http://www.theguardian.com/commentisfree/2014/sep/02/my-first-burning-man-grover-norquist" target="_blank">recent article</a> by conservative pundit Grover Norquist about his experiences at the very bohemian <a href="https://en.wikipedia.org/wiki/Burning_Man" target="_blank">Burning Man festival</a> in Nevada: “The story of Burning Man is one of radical self-reliance…A community that comes together with a minimum of ‘rules’ demands self-reliance – that everyone clean up after themselves and help thy neighbor. Some day, I want to live 52 weeks a year in a state or city that acts like this…This is hard work. Indeed, there is entirely too much work involved at Burning Man for lazy people to get to the Playa, nevermind build a camp or feed yourself.”<br />
<br />
The last sentence is significant: people who are not interested or not able to meet the expectations of the Burning Man ethos do not attend it. The “radical self-reliance” that one sees at Burning Man is a result of its culture and <i>the kinds of people who it attracts</i>. Culture is not only a result of learned patterns of behavior and experiences: it is also a result of the natural tendencies of the individuals in a population. Nature versus nurture: they both matter.<br />
<br />
Given this, one cannot expect two very different workforces to react the same way given the same approach from their executives. It is therefore absolutely crucial to understand the culture when planning for transformation.<br />
<br />
<div style="text-align: right;">
<span style="color: #fff2cc;"><i><span style="font-size: large;">One cannot expect two very different workforces to react the same way given the same approach from their executives.</span></i></span></div>
<br />
One of the most respected methods of formal cultural assessment is the <a href="http://www.valuescentre.com/products__services/?sec=cultural_values_assessment_%28cva%29" target="_blank">Barrett Cultural Values Assessment</a>. The Barrett approach involves having staff take this assessment, and then a facilitator helps them to discuss the results, which enables <i>them</i> to account for their own cultural biases when <i>they</i> plan for change. In this approach, leadership is about guiding this process.<br />
<br />
This sounds like it might be generally applicable to all organizations, but then consider the case of Steve Jobs, who was famous for being autocratic, yet he made Apple into a huge success – twice. Barrett points out that people who have exceptional “charisma” and “reputation” can get away with being autocratic because they inspire people: people will put up with command-and-control behavior if they trust that the leader is taking them somewhere and they feel that they are making a contribution. They “feed their self-esteem by association, and shared identity,” as Barrett puts it. One might call exceptional people such as Steve Jobs “unicorns” – you hear about them, but few have seen them, and so what works for them might not work in a general repeatable manner for others. The same applies to organizations: what works for “unicorns” like Netflix, Amazon, and Google – or Zappos – might not work for other organizations that have different cultures, or different levels of financial resources for making things work at any cost.<br />
<br />
Unicorns aside, let's use an example to think this through. Consider the very last impediment listed on the chart from my <a href="http://www.transition2agile.com/2014/07/the-top-impediments-to-agile-transition.html">July 25 post</a>: “Technical skill silos need to be broken down”: in order to address that, it will likely be necessary to change how many of IT’s traditional functions work, and that will require getting senior IT functional managers to meet and discuss that. Since these individuals have been operating in silos (per the impediment’s proposition that silos need to be broken down), the manager of each of these silos has been operating in a kind of zero sum game with respect to the other silo managers, and so it is almost inevitable that there is an atmosphere of competition among them rather than an atmosphere of collaboration. Changing that behavioral dysfunction will take more than getting them to understand themselves better – it will require some very aggressive and meaningful action on the part of the CIO, possibly including changing compensation incentives, reorganizing the functions and how budgets are allocated, and creating some team efforts that can only success if each of these individuals makes an effort – in other words, truly putting them all on the same team rather than arranged as competitors. These are structural changes. The real question is how those changes will be conceived and implemented: (A) autocratically with a dictum to come up with a solution without any facilitation or guidance – i.e., “make it so”, (B) through micromanagement that dictates the details of every change, or (C) through a facilitated collaborative process that is somewhere inbetween the extremes of A and B, that is sensitive to the organizational cultural that exists at that point in time and that allows the staff to participate in defining the changes – including the required cultural changes.<br />
<br />
Which do you think would work best? But even if you pick C, there is still the question of <i>how much</i> guidance to give, and the answer to that depends on the organization's culture.<br />
<br />Cliff Berghttp://www.blogger.com/profile/02103767196153470434noreply@blogger.com0tag:blogger.com,1999:blog-8391404601343318983.post-85855168698827141862014-08-27T13:33:00.003-04:002014-08-27T15:48:09.898-04:00Are Certifications Important For Agile Transformation?One of the greatest impediments for agile transformation is obtaining the new skills that are needed. (In the article “<a href="http://www.transition2agile.com/2014/07/the-top-impediments-to-agile-transition.html">The Top Impediments To Agile Transition</a>”, skills are identified as impediments 13 and 17.) It is therefore important to understand the role of certifications in recruiting for (or training for) the required skills.<br />
<h2>
Are there certifications for the skills that are most important?</h2>
The first question to ask is what skills are needed?<br />
<br />
In my personal blog post today, “<a href="http://valuedrivenit.blogspot.com/2014/08/to-be-certified-or-not.html" target="_blank">To Be Certified – Or Not?</a>”, I share some of a discussion that occurred recently in the LinkedIn group “CIO Network”. In that discussion, many participants posted that the critical skills that are needed for IT workers are not technical, but rather are “soft”. These were variously described as “foundational skills”, “employee skills”, and “natural learner” skills. They tended to focus on the ability of people to learn new things quickly, to get the job done, to work well with others, and to have a strong work ethic. These are things that cannot easily be certified.<br />
<br />
What about technical skills? – such as Certified Scrum Master? PMI-ACP? Coaches and “scrum masters” with these certifications are often brought in to help teams to learn agile methods, and to work with managers to help the transition to more agile friendly business processes. The latter type of coaches are sometimes referred to as “agile transformation coaches”.<br />
<br />
The core rationale for bringing in certified coaches and scrum masters is that they have a well defined set of knowledge that can form a baseline for the organization as it transitions to agile. This rationale rests on the assumptions that:<br />
1. The certification is indicative of the person’s actual knowledge.<br />
2. The certification is relevant to the Agile practices and values that the organization needs.<br />
<br />
Are these true?<br />
<br />
It is not clear to me that these things are generally true. For example, if someone has an Agile certification, it is usually either Certified Scrum Master (CSM) or PMI-ACP. I have taught Scrum – as a two day course – (even though I am not Scrum certified) and I can tell you that in two days, one can only obtain a glimpse of what Agile is about. Further, Scrum emphasizes things that are very different from other methods such as eXtreme Programming (XP), Kanban, and Feature Driven Development (FDD). As such, someone having a CSM certification does not really tell me anything useful: it does not indicate to me that they are sufficiently mature in their perspective and experience to be trusted as a teacher of Agile methods.<br />
<br />
The PMI-ACP course is a little different in that it is not specifically focused on Scrum, but the PMI-ACP course that I took was very Scrum centric. (I am not ACP certified because I did not do the paperwork.) The course was three days, and while it was a really excellent course – developed by the people who developed the PMI-ACP course – someone taking only that course would still very much be a “newbie” with respect to Agile. That said, ACP requires one to have actual experience in order to qualify: I contend that that experience is the real value.<br />
<br />
Agile is not something that you can learn in two or three days. To really understand Agile, you have to have a pretty substantial career of software development behind you. In fact, I feel that it was my own experiences during the 1980s – before Agile existed – that enable me to truly understand Agile. During that time, I saw what worked and what did not work, and I therefore see Agile as a rejection of what did not work, and a return to what did. I see Agile not in terms of strict practices such as standups, but rather in terms of a set of values: focusing on what really matters and not on things that don’t actually matter, working incrementally in small chunks, elaborating a design as you go, and having continual communication among team members. A course in an Agile methodology can help one to think these values through in the context of that methodology, but one could just as easily do that by reading a book. What matters is the background of experience that helps one to put Agile into the proper perspective, so that it can inform one’s judgment.<br />
<h2>
Is certification relevant to the practices and values that the organization needs?</h2>
Organizations that bring in certified Agile coaches are essentially choosing to base their Agile adoption around Scrum. This is because Scrum certifications are by far the most dominant. Even the PMI-ACP is quite Scrum-centric. Yet, I have found that Scrum is not always the best approach for organizations with legacy processes and skill silos – at least not as a first step. If you bring in people who are certified in Scrum or a Scrum-centric concept of Agile, then be sure to also bring in some people whose primary focus has been XP, Kanban, FDD, or some other Agile approaches: that will add balance to the discussions about how to implement Agile.<br />
<br />
All of these methodologies – except for XP – focus primarily on process, yet much of Agile is very technical. Agile coaches often refer to the “technical practices” of Agile: these are things that are emphasized by XP, and by <a href="https://en.wikipedia.org/wiki/Devops" target="_blank">DevOps</a>: things like automating software builds, automating software testing, and automating deployment. (Yes, I know that DevOps is about more than just the technical practices.) These technical skills are in relatively short supply, and yet they are critical, because without automation, it is very difficult to meet the two week iteration cycle that is so prevalent in Agile projects. Without automation, what tends to happen is that testing gets chunked up – turning the Agile iteration into a mini “waterfall” project. DevOps is impossible without automation – and <a href="http://www.scriptrock.com/blog/devops-pushes-agile-limits" target="_blank">some say that DevOps is the “new Agile”</a>. Automation is critical for Agile; yet the technical practices of Agile are not supported by certifications: tools such as Jenkins, Cucumber, Selenium, Vagrant, Chef – these things are not covered by the Scrum Master or ACP certifications. Further, seeking skills in specifically these tools is foolish, because these are only a smattering of the tools out there, and that mix of tools will surely change by this time next year. It is far smarter to find people who are experienced with a range of these tools, and who are adept at learning new tools. Thus, <i>you want to find self learners</i> – and self learners are often too impatient to sit through a certification course. Some of the best people who are self learners – people like Bill Gates, Steve Jobs, Michael Dell, Larry Ellison, and Mark Zuckerberg – did not even wait around for their college degrees before they sought to implement their ideas.<br />
<h2>
Do certifications help you to get the best people that you can get?</h2>
Many people who have Agile certifications claim that those certifications have been beneficial for them, by adding focus to their work. They found that the certification process helped them to think through their prior experiences and put them into perspective, and provided a conceptual framework for thinking about issues. That clearly has value: while I personally would prefer to obtain that by reading and trying things on my own, not everyone is like that, and if certification works for someone, that is all that is important. What gives the certification value though, is that the person has substantial prior experience so that the certification learning content has context: it helps the learner to organize their knowledge. I therefore propose that a two or three day certification course does not itself represent substantial knowledge of its own: it merely provides a framework for prior knowledge.<br />
<br />
If you accept this proposition, then you must conclude that certification does not provide any kind of metric about the quality of someone’s knowledge. Certification does not prove advanced knowledge: it only proves that someone has been introduced to the most rudimentary concepts. It should therefore not be a criteria for finding the best people: only for finding the lowest common denominator. Consider this anecdote: In the article, <a href="http://www.npr.org/blogs/money/2012/06/18/155277740/why-einstein-was-disqualified-from-teaching-high-school-physics" target="_blank"><i>Why Einstein Was Not Qualified To Teach High-School Physics</i></a>, <a href="http://www.dartmouth.edu/~tedx/charleswheelan/" target="_blank">Charles Wheelan</a> shares this story:<br />
<blockquote class="tr_bq">
<i>“My wife Leah graduated Phi Beta Kappa from Dartmouth. She was a computer science major with an emphasis on math. She worked in the software industry, built a company, and then sold it. She seemed, in every respect, perfectly qualified to teach middle-school math. She found a job at a school adjacent to a public housing project on Chicago's South Side. On about day three of that job—after she had met the students, decorated the classroom, and started teaching—the principal informed Leah that she did not have a ‘middle-school math endorsement,’ which the State of Illinois requires.”</i></blockquote>
<br />
Are we doing the same thing with Agile certifications?Cliff Berghttp://www.blogger.com/profile/02103767196153470434noreply@blogger.com3tag:blogger.com,1999:blog-8391404601343318983.post-27827042809100404892014-08-18T08:05:00.002-04:002014-08-18T08:05:21.883-04:00Do not constrain projects with detailed up front requirementsMy <a href="http://www.transition2agile.com/2014/07/its-all-about-culture-right.html">prior post</a> promised to look at the root causes of the obstacles that I mentioned in my <a href="http://www.transition2agile.com/2014/07/the-top-impediments-to-agile-transition.html">July 25 post</a>. So let’s do it!<br /><br />The first “stumbling block” was, “<b><i>Need to <u>not</u> constrain projects with detail level objectives</i></b>.”<br /><br />Have you seen this happen? For example, have you come across “agile” projects that were given a detailed requirements document and then told to “do it agile”? Have you been on “agile” projects in which there was a detailed feature list with hard dates for when those must be delivered? That’s what I am talking about here.<br />
<h2>
Direct Causes</h2>
Why does that happen? It depends. Sometimes it is the result of the project sponsor – typically a business area – that charters a consulting firm to research and document the system requirements. Other times it occurs because the organization has an SDLC that mandates that a requirements document be done up front. In US government agencies the SDLC is often rooted in procurement policy such as “<a href="http://www.whitehouse.gov/sites/default/files/omb/assets/a11_current_year/capital_programming_guide.pdf" target="_blank">CPIC</a>” (see also <a href="http://fcw.com/blogs/lectern/2014/08/the-challenge-of-agile-development.aspx" target="_blank">this article</a>), which treats software development as an “acquisition” as if the agency was buying a “thing” – but custom software development fits very poorly into an acquisition model.<br />
<h2>
Root Causes</h2>
Here is where we start to ask the “<a href="https://en.wikipedia.org/wiki/Five_whys" target="_blank">five whys</a>”. Why do business areas ask consulting firms to perform an up front detailed requirements analysis? Some possible reasons are:<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<br />1. That is how they have always done it.<br />2. That puts them in control of the requirements – giving them a false feeling of confidence that all of their requirements will be met.<br />3. When they initiated the requirements analysis, they did not know that they would be using agile methods.<br />4. They just don’t know any better: they don’t understand agile well enough to know that an up front requirements analysis is wasteful.<br /><br />Number 1 seems pretty straightforward: there is no root cause for it – <i>or is there?</i> The root cause has to do with human nature and might be somewhat spooky. Have you heard of the “five monkeys experiment”? Check it out <a href="https://www.youtube.com/watch?v=i86R7AEmaXQ" target="_blank">here</a>. Even though this experiment <a href="http://www.psychologytoday.com/blog/games-primates-play/201203/what-monkeys-can-teach-us-about-human-behavior-facts-fiction" target="_blank">never actually happened</a>, it gives you pause for thought.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgYFbYqMYQvHCGXjqka8H5PaLcdnmuGcLe0DNft3nEk7f6YQhVn9DBFWJO4PTmynwIT049WMIT7C4ZCGUnVvk-itqr_V_dW2jCkE2po2FEqUmCbRQmfvWf5GpqnNC99_lWg3XD1vI-iSwky/s1600/FiveMonkeys.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgYFbYqMYQvHCGXjqka8H5PaLcdnmuGcLe0DNft3nEk7f6YQhVn9DBFWJO4PTmynwIT049WMIT7C4ZCGUnVvk-itqr_V_dW2jCkE2po2FEqUmCbRQmfvWf5GpqnNC99_lWg3XD1vI-iSwky/s1600/FiveMonkeys.png" height="238" width="320" /></a></div>
<br />
<br />
For numbers 2 through 4, we do not yet seem to be at the root causes, so let’s ask,<br /><br />2. Why does a detailed requirements document make them feel more in control than the agile process does?<br />3. Why did they not know that they would be using agile?<br />4. Why do they not know agile well enough so that they understand how requirements are done using agile?<br /><br />Before investing time to address each of these with an actual client, you should speak to the stakeholders – in this case the business areas that tend to create up front requirements – and ask them frankly why they do it. They might give you honest answers, but whether they do or not, you should be able to piece together the real reasons if you talk to enough people<span style="font-size: small;">.</span><br />
<br />
<div style="text-align: right;">
<i><span style="font-size: large;">“The most dangerous phrase in the language is ‘we’ve always done it this way.’” – Real Admiral Grace Hopper</span></i></div>
<br />
<span style="font-size: small;"> </span>Once you know what the real reasons are, you can plan to take action to address the root causes. For example, if it turns out that some business areas obtain a sense of control from having up front requirements, then you can endeavor to educate them on how agile puts them in control, by enabling them to evolve the requirements throughout development. Make sure that you work things at all of the levels or parts of the organization that are driving the behavior: in this case, it might be business area management and IT portfolio management.<br /><br />While doing this, be sure to address the <i>direct</i> causes as well: the fact that business areas initiate up front requirements efforts. Try to intercept these efforts, perhaps by asking IT portfolio managers what business areas are planning new work. Become familiar with the pipeline of work, including the work that has not yet been funded or even requested.<br /><br />Understanding root causes is an important step, but knowing what to do about them is not always so clear. For example, you might find that one root cause of some problems is that employees are not staying current with the latest techniques. What do you do? Some people are natural learners: they will read up on things – all you need to do it point them in the right direction (or even better, include them in your analysis process so that they help to figure out the root causes and what the “right” direction is!) On the other hand, some people are not as inclined to learn new things on their own. Thus, the right strategy depends on the personalities of the population that you are dealing with. In a future article I will talk about personality assessment, and more inclusive methods for finding root causes and defining solutions.<br /><br />I have presented possible actions for root cause 2 – I’ll leave 3 and 4 for you.<br /><br />We had another <i>direct</i> cause that we have not peeled apart into root causes: when an SDLC or procurement policy mandates that a requirements document be done up front. If there is no policy but the current SDLC defines a requirements phase, you need to work with IT management as well as business stakeholders to get the SDLC changed, possibly by defining an “agile version”. This might not even be necessary if agile projects can be granted exceptions from the SDLC. On the other hand, if policy defines a requirements phase, the task might be far more difficult, because you might need to involve senior management. In a government organization, this might require that the CIO “tailor” the applicable procurement policies.<br /><br />Either way, you have an education task ahead of you. Simply defining new rules will not accomplish your goal of preventing business areas from defining requirements up front. You need to educate them. Business area managers and portfolio managers are generally very senior people, and they are not usually likely to attend a course that you create, so you will likely have to meet with them one on one or in small groups, and manage as a kind of discussion where you present key ideas and they get to ask questions about how it would for their teams, and how it would affect other things they are responsible such as their budgeting process. You will need to have answers for these questions: do not go in cold. By the time you sit down with these people you should have done your homework on what all of their challenges will be, by talking to their staff and by asking those who are on your side, such as your CIO.<br /><br />In a future post I will talk about the need to assign team resources early – before work on a release begins!<br />Cliff Berghttp://www.blogger.com/profile/02103767196153470434noreply@blogger.com0tag:blogger.com,1999:blog-8391404601343318983.post-42354248230475746482014-07-30T20:36:00.000-04:002014-08-04T14:12:21.934-04:00It's All About Culture - Right?It’s all about culture.<br />
<br />
That is the general consensus today with respect to agile transformation. But what is the “culture” of an organization? It’s certainly not styles of dance, or music, or food – some of the things that make up culture in society. So what is it?<br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhwN0bSBh3Z84eJDW2MKR4l3SSV5LYpRbFWnGDBTwjzSJCLFCSzBCYRYBAGmXxs7EqomEMa8nRRfBb4-oiDeWUsGeOaDCr37IIxLvo0lTG3tcj1as2wx_77k6TgDDVH-DXNH_bOlvPAttrD/s1600/brazil16_04A.jpg" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhwN0bSBh3Z84eJDW2MKR4l3SSV5LYpRbFWnGDBTwjzSJCLFCSzBCYRYBAGmXxs7EqomEMa8nRRfBb4-oiDeWUsGeOaDCr37IIxLvo0lTG3tcj1as2wx_77k6TgDDVH-DXNH_bOlvPAttrD/s1600/brazil16_04A.jpg" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Certainly this is not "corporate culture"!</td></tr>
</tbody></table>
<br />
An <a href="http://www.atkearney.com/organization-transformation/ideas-insights/article/-/asset_publisher/LCcgOeS4t85g/content/demystifying-corporate-culture/10192" target="_blank">A. T. Kearney analysis</a> defined corporate culture as a set of systems and practices enveloping behaviors, emotions, and interpretations. Systems and practices such as strategy, goals, measures, org structure, rules and procedures, rewards and recognition, mission statements – these all serve to drive perceptions, attitudes, and behaviors that in turn push back to reshape the systems and practices in a co-evolving cycle.<br />
<br />
If its all about culture, then how do you change culture?<br />
<br />
The ADKAR model developed by Prosci is one of the most widely recognized models for organizational change. It is closely related to the <a href="https://en.wikipedia.org/wiki/Transtheoretical_model" target="_blank">Prochaska & DiClemente “Transtheoretical Model”</a>, also known as “TTM” – a model of behavioral change that is widely used by psychologists for individuals and for organizations. There are many others as well, but most of them posit a series of phases that the organization (or individual) tend to naturally go through, during which they first develop an awareness for the need to change, followed by a desire to support the change, followed by increasing knowledge on how to actually begin to change, and then followed by sufficient change that will be self sustaining.<br />
<br />
I have seen this pattern play out in my own work with organizations. It has taught me that transformation takes time, and that one must set one’s expectations and plan one’s work based on these natural phases.<br />
<br />
So how do you get things going? Where do you start? First of all, it is important to realize that change must address the range of factors that drive the current behaviors. In terms of a cultural model, you must identify the various elements of the culture, and find the “knobs” that you can turn that will push things forward, depending on where you are in the natural cycle of change: i.e., which “phase” you are in. For example, if you are in the beginning phase, in which people are merely considering whether agile is right for them, then it does not do much good to try to educate them on advanced technical practices: most people will not be willing to invest the effort required.<br />
<br />
First and foremost you should talk to all of the managers and the teams to understand how things work currently, what people’s attitudes and plans are, and to identify the impediments to change. That gives you a set of obstacles something like what I presented in my prior post.<br />
<br />
But that is only a sliver of the picture. These obstacles are not root causes. They explain things on a tactical level, but not on a cultural level. That is, they don’t explain why these obstacles exist, and what is keeping them there. To analyze the obstacles to determine root causes, it is helpful to think in terms of the culture and the places in which culture operates.<br />
<br />
Martin Proulx of Audacium has <a href="http://analytical-mind.com/2010/07/12/yet-another-agile-maturity-model-the-5-levels-of-maturity/" target="_blank">proposed a 5 level organization agile maturity model</a> – Yet another Agile Maturity Model (AMM) – consisting of five levels: Team Level, Department Level, Business Level, Project Management Level, and Management Level. His claim is that change needs to happen at all of these levels. This is an excellent model, and you might choose to use it, but I prefer to use a slightly different one, consisting of Team Level, Process Level, Functional Level, Executive Level, and Senior Executive / Strategy Level. If one lists these levels side by side with the systems and practices that drive behavior, then you have a picture of the nobs that you can turn, and where you might turn them, in order to adjust behavior over time. This is shown in the figure below.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgDRBCqsu6D_dImhr3EIrhjw33SyaAbSzaBVHfoqqCTmF2V1aRcxpM4dugb1OQrDVfBKOweNEns01Ody0Gz7_69XpkveYI9e37NJVi4OzhMWUwzNyc4H_StXZHPxCLxI5SuH78_X-hvV0vt/s1600/Dimensions_Of_Org_Behavior.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgDRBCqsu6D_dImhr3EIrhjw33SyaAbSzaBVHfoqqCTmF2V1aRcxpM4dugb1OQrDVfBKOweNEns01Ody0Gz7_69XpkveYI9e37NJVi4OzhMWUwzNyc4H_StXZHPxCLxI5SuH78_X-hvV0vt/s1600/Dimensions_Of_Org_Behavior.jpg" height="480" width="640" /></a></div>
<span style="font-size: xx-small;">As PDF: click <a href="https://drive.google.com/file/d/0By4lfBwI0rt6b2pBMHBLZ0xBdFk/edit?usp=sharing" target="_blank">here</a>.</span><br />
<br />
It is important to realize that many of these things must happen in parallel, and so transformation is not step-wise. Different groups reach “maturity” at different times, and you need to be plugged into them all. Change is messy: different parts of the organization do not progress together. Execution is in the details, and execution is everything.<br />
<br />
One more thing: this picture is not a sufficient model for your organization’s behavior: it is only a kind of menu. To create a more useful model, you have to identify the actual behaviors, and the actual causes by asking the “<a href="https://en.wikipedia.org/wiki/Five_whys" target="_blank">Five Whys</a>” (discussed in my priori post). The picture I have presented is only to help stimulate your thinking when creating your model. In fact, both the list of behavior manifestations and the organization tiers are generic – you should try to customize these to better match your own organization.<br />
<br />
We are now ready to look at the root causes of the obstacles that I presented in my prior post – that’s where we really get into some substance. I’ll save that for next time – this post is already too long!Cliff Berghttp://www.blogger.com/profile/02103767196153470434noreply@blogger.com0tag:blogger.com,1999:blog-8391404601343318983.post-88315062179720765982014-07-25T18:57:00.000-04:002014-07-25T19:16:14.601-04:00The Top Impediments To Agile TransitionManagement’s first inclination when transitioning to agile is to train development teams on agile methodologies such as Scrum, and to bring in agile coaches to help the teams to transition. While these are important steps – indeed critical steps – these are insufficient: they are analogous to giving the members of the US Congress training in conflict resolution in an effort to improve Congress’s function: better knowledge of conflict resolution is always helpful, but the systemic and deep rooted issues that are causing conflict will resist change unless they are dealt with head on – perhaps through major political or structural change.<br />
<br />
In the article “<a href="http://www.transition2agile.com/p/most-impediments-are-management-level.html">Most Impediments Are Management Level - Not Team Level</a>” we explained how most of the obstacles to realizing the agile vision in an organization are rooted in management level issues – from culture and skill set issues to policy and leadership issues – and if these are not dealt with then the development teams will find it almost impossible to function in an agile manner.<br />
<br />
We thought it would be useful to draw a map of the common impediments. When drawing such a map, however, <i>one must be careful to differentiate between immediate impediments and the root causes that drive the impediments</i>. Those who are familiar with the “<a href="https://en.wikipedia.org/wiki/Five_whys" target="_blank">Five Whys</a>” concept know that root causes often are systemic and rooted in culture and tacit behavior that is far removed from where the problem actually shows itself through some symptom or obstacle. The “first why” is merely the immediate cause of the symptom that is being identified as a problem or impediment.<br />
<br />
The chart below illustrates many of the common impediments that show themselves during an agile transition. Notice that most of these impediments are management issues: that is, in a large traditional IT organization it takes management to solve them for the whole organization - i.e., management must change things in order to enable agile to operate.<br />
<br />
The impediments in the chart are “first whys” – they are <u><i>not</i></u> root causes. In a future post I will delve into each of the impediments and examine the root causes.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<span id="goog_1857955596"></span><span id="goog_1857955597"></span></div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg1mb6qib9AJoIDo4MdLz9o6WHY70Kx6NgOxOh5EDM6rlU1mZWUr7-zTvrMf7NBpBDOsewiqJ4RmGuIf8n2cdZB9AfGiFANbDARGcV0Rqln3t2ys3KbEUIXjr3Jvc38NQPsmCKFEvcmi-o5/s1600/Top_Agile_Stumbling_Blocks.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg1mb6qib9AJoIDo4MdLz9o6WHY70Kx6NgOxOh5EDM6rlU1mZWUr7-zTvrMf7NBpBDOsewiqJ4RmGuIf8n2cdZB9AfGiFANbDARGcV0Rqln3t2ys3KbEUIXjr3Jvc38NQPsmCKFEvcmi-o5/s1600/Top_Agile_Stumbling_Blocks.png" height="480" width="640" /></a></div>
<span style="font-size: xx-small;">As PDF: click <a href="https://drive.google.com/file/d/0By4lfBwI0rt6ajk5cl9SVjZFTkk/edit?usp=sharing" target="_blank">here</a>.</span>Cliff Berghttp://www.blogger.com/profile/02103767196153470434noreply@blogger.com3tag:blogger.com,1999:blog-8391404601343318983.post-36420712268955176242014-07-13T14:52:00.003-04:002014-07-13T14:54:47.731-04:00How do we get there?<i>How do we get there?</i><br />
<br />
That is, How do we make our IT organization agile? This is the critical question that is so often overlooked. And that question is what this website endeavors to answer.<br />
<br />
We created this site because this question desperately needs attention. There is so much written on agile, and on “scaling agile”, and increasingly on what an agile IT organization might look like, but so little that answers the question of <u><i>how to bring a large, established IT organization forward</i></u>, to transform it into one that uses agile practices. Even those sources that address “scaling agile” do not fully address the problem, because the problem is not so much one of scale, but rather is one of organizational transformation.<br />
<br />
Why make so much of this? Can it be that hard? In <a href="http://transition2agile.blogspot.com/p/what.html" target="_blank">What Is Agile Transformation?</a> we talk about why agile transformation is so hard, and why it so often goes off the rails. In <a href="http://transition2agile.blogspot.com/p/blog-page_10.html" target="_blank">Agile Transformation Is a Major Org Change</a> we explain why it must be approached as an organization change - and not merely a scaling up of agile project coaching. In the business community we often hear of “<a href="https://en.wikipedia.org/wiki/Crossing_the_Chasm" target="_blank">crossing the chasm</a>”, and in the agile community we hear a-lot about the <a href="http://stevenmsmith.com/ar-satir-change-model/" target="_blank">Satir change curve</a>. These are essentially the same model when you apply them to an organization, and they each provide a basis for explaining why agile transformation can so easily get bogged down when one tries to scale up pilot agile efforts to an entire organization. Agile - to be successful - <u><i>requires changing how every single function in an IT organization works</i></u>, and some functions beyond IT (e.g., procurement).<br />
<br />
There are many established models for org change. Indeed, the field is fairly mature. (<a href="http://www.bkconnection.com/ProdDetails.asp?ID=9781576753798" target="_blank">Here</a> is a survey volume.) That is why this site brings together professionals from the fields of org change and agile, to synthesize those ideas. This synthesis is greatly needed.<br />
<br />
In order to treat agile transformation as an org transformation, we need to move from the software team level up to the executive level, and at that level we need to speak in business terms - not agile project terms. Thus, instead of the vocabulary of agile - “sprints”, “velocity”, “stories”, “product owner”, “fail early and often”, “being agile versus doing agile”, and so on, we need to refer to business models of these same ideas, and there are many. <a href="http://www.forbes.com/sites/scottallison/2012/08/31/mastering-the-rockefeller-habits-how-to-scale-a-hyper-growth-business/" target="_blank">Rockefeller Habits</a>. The ideas of <a href="https://www.deming.org/" target="_blank">Deming</a>. <a href="http://www.druckerinstitute.com/" target="_blank">Drucker</a>. <a href="http://www.kotterinternational.com/" target="_blank">Kotter</a>. <a href="https://www.stephencovey.com/" target="_blank">Covey</a>. <a href="http://www.change-management.com/adkar-book.htm" target="_blank">Jeffrey Hiatt</a>. <a href="http://www.claytonchristensen.com/" target="_blank">Clayton Christensen</a>. <a href="http://www.three-levels-of-leadership.com/blog/tag/james-scouller/" target="_blank">James Scouller</a>. <a href="http://www.tablegroup.com/pat/" target="_blank">Patrick Lencioni</a>. <a href="https://profiles.stanford.edu/robert-sutton" target="_blank">Bob Sutton</a>. <a href="http://www.wmbridges.com/" target="_blank">William Bridges</a>. <a href="http://business.leeds.ac.uk/about-us/faculty-staff/member/profile/john-hayes/" target="_blank">John Hayes</a>. <a href="http://www.gse.harvard.edu/news-impact/2013/11/remembering-professor-chris-argyris/" target="_blank">Chris Agyris</a>. <a href="http://books.google.com/books/about/Making_the_Connections.html?id=r8oID-7GvC0C" target="_blank">Bill Quirke</a>. <a href="http://tomdevane.com/" target="_blank">Tom Devane</a>. <a href="http://www.spencerjohnson.com/" target="_blank">Spencer Johnson</a>. <a href="http://www.jurgenappelo.com/" target="_blank">Jurgen Appello</a>. <a href="http://hbr.org/2003/01/one-more-time-how-do-you-motivate-employees/ar/1" target="_blank">Hertzberg</a>. The list goes on and on. We need to speak to these ideas, in these vocabularies, to be in the best position to offer agile ideas to management.<br />
<br />
One of the thought streams that is rising today is “<a href="https://en.wikipedia.org/wiki/DevOps" target="_blank">devops</a>” - the idea that one must treat software development as a continuous pipeline that extends from conceptualization of a need all the way through business and IT operations without pauses. Devops essentially applies agile ideas to the entire scope of all activities that intersect with software development and the operation of production software applications. As such, it raises the bar for what organizations can and should accomplish in their quest to adopt agile, and it depends on org change even more to be successful.<br />
<br />
In order to properly cover this vast range of topics, we have assembled an editorial board that covers these areas, as well as an advisory board of thought leaders in org change. We will have articles by guest authors with interesting and ground breaking points of view on a regular basis, with occasional articles by editorial board members. Please feel free to comment on the articles or other content - commenting is open to all.<br />
<br />
We hope that this site helps to move the ball forward in the game of agile transformation. We hope to help you to learn how to better achieve a learning organization. We hope to enable agile and get you over the chasm!<br />
<br />
Very best regards,<br />
<br />
Cliff Berg<br />
Chair, Transition2Agile Editorial BoardCliff Berghttp://www.blogger.com/profile/02103767196153470434noreply@blogger.com0