tag:blogger.com,1999:blog-3565161834525511102024-03-14T22:05:53.779-07:00Software EngineeringFlow of experience-based thoughts on some of the practical aspects of Software EngineeringRaja Bavanihttp://www.blogger.com/profile/03107697584076683320noreply@blogger.comBlogger146125tag:blogger.com,1999:blog-356516183452551110.post-50642233418191149352020-11-06T21:36:00.003-08:002020-11-09T21:44:42.205-08:00The Deliverable<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgcgSXPQEeC0OjZM-eTSGNE4-nzwW6ZUvJlbgngzaXAjglov0Q0JVLkZEwjxqwVaeLRZzsbTkD_ElQzBhR-qXZf6olDHpBoC2qEy-JoCthQhgxm4EIqlWUPf66r3lfyBamiltEtmsT2Rsw/s1519/DT.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1001" data-original-width="1519" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgcgSXPQEeC0OjZM-eTSGNE4-nzwW6ZUvJlbgngzaXAjglov0Q0JVLkZEwjxqwVaeLRZzsbTkD_ElQzBhR-qXZf6olDHpBoC2qEy-JoCthQhgxm4EIqlWUPf66r3lfyBamiltEtmsT2Rsw/s320/DT.jpg" width="320" /></a></div><div class="separator" style="clear: both; text-align: left;"><span style="font-size: large;">IT Boom: It happened once. Will it happen again?</span></div><div class="separator" style="clear: both; text-align: left;"><br /></div><div class="separator" style="clear: both; text-align: left;">We belong to an era that gave birth
to new industries resulting in innovative technologies, abundant business
opportunities, millions of jobs and sophistication our lives. IT is one such industry.</div><p class="MsoNormal" style="line-height: 150%;"><o:p></o:p></p>
<p class="MsoNormal" style="line-height: 150%;">In early 70s, students seeking
admission to engineering programs opted for mechanical, civil and electrical
engineering. Even though some of them had an offer of admission to join the
brand new and first-hand computer-engineering program, they did not change
their mind. They wanted to avoid the unknown.<span style="mso-spacerun: yes;">
</span>During later years, this trend changed. In 90’s it became a mad rush - a
mad rush to pursue undergraduate and graduate programs in Computer Science,
Computer Engineering, Information Technology and the likes.<span style="mso-spacerun: yes;"> </span>This mad rush was not just about admissions.
There is more to it.<o:p></o:p></p>
<p class="MsoNormal" style="line-height: 150%;">Sometime in 1991, I attended a job
interview of one of the top IT companies in India.<span style="mso-spacerun: yes;"> </span>There were several job openings for software
engineers with experience ranging from two to five years.<span style="mso-spacerun: yes;"> </span>My turn came and I entered the interview room.<span style="mso-spacerun: yes;"> </span>There was a young man who greeted me and
offered me a seat.<span style="mso-spacerun: yes;"> </span>He was very vibrant
and enthusiastic.<span style="mso-spacerun: yes;"> </span>After several general
questions, that young gentle man – the interviewer, who was seemingly in a
hurry, asked me only one or may be two technical questions!<span style="mso-spacerun: yes;"> </span>The interview was over in less than five
minutes. In two weeks, I got a job offer with a firm commitment on an
opportunity abroad. It was a tempting offer. Nevertheless, I decided not to
join because I did not see any merit in their interview process.<span style="mso-spacerun: yes;"> </span>The interview was too trivial and
uninspiring.<span style="mso-spacerun: yes;"> </span>One of the two technical
questions that I answered without any efforts was, ‘How do you count the number
of records in a table using SQL?’ The other question was, ‘What are the
attributes of a file in Unix?’<span style="mso-spacerun: yes;"> </span>Those
days, relational databases and UNIX were the hot topics. There was no Internet,
Java, .Net or the likes. It was a boom time for software engineers. The demand
was extremely high. It was a mad rush.<span style="mso-spacerun: yes;"> </span><o:p></o:p></p>
<p class="MsoNormal" style="line-height: 150%;">I am sure some of you witnessed
similar experiences. It happens in a demand driven industry. Obviously!<span style="mso-spacerun: yes;"> </span>However, a demand driven industry does not
continue to remain demand driven over years!<span style="mso-spacerun: yes;">
</span>You know what happened as we celebrated the New Year 2000.<o:p></o:p></p>
<p class="MsoNormal" style="line-height: 150%;">The challenges that preoccupied our
industry during the run-up to the millennium, especially the Y2K problem, the
dot-com bubble and the events that followed the downturn, had significant
impact on all of us, our families and peripheral industries that relied on the
IT growth. Many startups vanished because of a lack of additional funding.
While the confidence and hope of product development organizations thrived after
the telecom bust, several other socioeconomic and political factors challenged
the industry. IT industry bounced back within few years and had another spurt
of growth until 2007.<span style="mso-spacerun: yes;"> </span>Next, a seemingly
isolated turmoil in the US sub-prime segment spread like a wildfire triggering
‘Global Recession’ in 2008 and even after six years since it hit our world
continues to recover gradually – it is painfully a long running recovery! <span style="mso-spacerun: yes;"> </span><span style="mso-spacerun: yes;"> </span><o:p></o:p></p>
<p class="MsoNormal" style="line-height: 150%;">Lately, we have seen the challenges
induced by the pandemic of 2020.<o:p></o:p></p>
<p class="MsoNormal" style="line-height: 150%;">Looking back, the so-called IT boom
happened once or twice.<span style="mso-spacerun: yes;"> </span>That is
history.<span style="mso-spacerun: yes;"> </span>Many pundits have predicted
that a similar boom is a distant dream. However, most businesses are upbeat,
confident and strong to face the future.<span style="mso-spacerun: yes;">
</span>They are devising innovative strategies and approaches to overcome the
new challenges.<span style="mso-spacerun: yes;"> </span>This applies to IT
professionals too.<span style="mso-spacerun: yes;"> </span>We cannot do what we
did years ago and expect the same results. We know that.<o:p></o:p></p>
<p class="MsoNormal" style="line-height: 150%;">Whether it is a boom time or a
downturn, I have consistently experienced, heard and acknowledge two things -
these are our takeaways.</p><p class="MsoNormal" style="line-height: 150%;"></p><ol style="text-align: left;"><li><span style="text-indent: -0.25in;">There
is always a scarcity of competent and experienced professionals in this
industry. Those who are competent, dauntless and adaptable survive and grow.</span></li><li><span style="text-indent: -0.25in;">In
this new economy, businesses need innovative solutions, which in turn need
expert teams and collaborative and trusted partners.</span><span style="text-indent: -0.25in;"> </span><span style="text-indent: -0.25in;">If your goal is to be one among them, you can
succeed!</span></li></ol><p></p><p class="MsoListParagraphCxSpLast" style="line-height: 150%; mso-list: l0 level1 lfo1; text-indent: -0.25in;"><o:p></o:p></p>
<p class="MsoNormal">The runway in front of you needs lot of groundwork in this
evolving landscape. How are you preparing yourself? “<a href="http://thedeliverablebook.blogspot.com/2020/05/the-deliverable-experiential-insights.html" rel="nofollow" target="_blank"><i><b>The Deliverable</b></i></a>” will help
you in this journey.<o:p></o:p></p>
<p class="MsoNormal">Read all the posts published under “<a href="http://thedeliverablebook.blogspot.com/2020/05/the-deliverable-experiential-insights.html" rel="" target="_blank"><b><i>The Deliverable</i></b></a>” – it is
free and available online.<span style="mso-spacerun: yes;"> </span>Feel free to
post your comments and questions. <span style="mso-spacerun: yes;"> </span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>Raja Bavanihttp://www.blogger.com/profile/03107697584076683320noreply@blogger.com0tag:blogger.com,1999:blog-356516183452551110.post-37327279130819162722018-08-09T05:02:00.002-07:002018-08-09T05:11:16.230-07:00The Lean Gelateria | Part 9 | Myths Not to Lean on<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="MsoNormal" style="text-align: justify;">
<b><u><a href="http://se-thoughtograph.blogspot.com/2018/07/the-lean-gelateria-part-8-muda-muri-and.html" target="_blank"><<<<<<<< Lean Gelateria | Part 8</a></u></b><br />
<br />
I find it interesting to learn
more and more about gelato just as I think about the different aspects of Lean.
Sharing thoughts, connecting my thoughts with different flavors of gelato and
landing in the world of Lean is a wonderful writing experience. I have made
this happen over the first eight parts of this series.<o:p></o:p></div>
<div class="MsoNormal" style="text-align: justify;">
<br /></div>
<div class="MsoNormal" style="text-align: justify;">
In 2001, I wrote a post on <u><a href="http://se-thoughtograph.blogspot.com/2011/12/agile-myths-and-misunderstandings.html" target="_blank">Agile Myths</a></u> leading to several comments from readers like you. If you haven’t yet, read it. Also read the first eight parts of this
series. Myths exist in every field. Knowing and thinking through myths is a
very good learning experience. There are several myths related to gelato too.
Here are some examples.</div>
<div class="MsoNormal" style="text-align: justify;">
</div>
<ol>
<li>Gelato
is not good for health. Gelato is fattening.</li>
<li>Gelato
aggravates cold. Don’t eat gelato when you have cold.</li>
<li>You
have to visit Italy to find the best gelato in the world.</li>
<li>Gelato
is not for diabetics. There is no diabetic-friendly gelato.</li>
<li>Gelato
makes you happy! (Well, if you visit the right shop you will find that this is
not a myth.)</li>
</ol>
<br />
<div class="MsoListParagraphCxSpLast" style="mso-list: l0 level1 lfo1; text-align: justify; text-indent: -.25in;">
<o:p></o:p></div>
<div class="MsoNormal" style="text-align: justify;">
<u>Source:</u> <a href="https://www.blog.emmaladolce.com/blog/2018/4/9/top-5-gelato-myths">https://www.blog.emmaladolce.com/blog/2018/4/9/top-5-gelato-myths</a>
<o:p></o:p></div>
<div class="MsoNormal" style="text-align: justify;">
<br /></div>
<div class="MsoNormal" style="text-align: justify;">
Next time when you visit your
favorite gelateria, try Hazelnut Gelato. Hazelnuts are the
nuts of the hazle tree. According to <u><a href="https://en.wikipedia.org/wiki/Hazelnut" target="_blank">Wikipedia</a></u>,
<a href="https://en.wikipedia.org/wiki/Ferrero_SpA" title="Ferrero SpA"><span style="color: windowtext; text-decoration-line: none;">Ferrero SpA</span></a><span style="text-align: start;">, the maker of </span><a href="https://en.wikipedia.org/wiki/Nutella" style="text-align: start;" title="Nutella"><span style="color: windowtext; text-decoration-line: none;">Nutella</span></a><span style="text-align: start;"> and </span><a href="https://en.wikipedia.org/wiki/Ferrero_Rocher" style="text-align: start;" title="Ferrero Rocher"><span style="color: windowtext; text-decoration-line: none;">Ferrero
Rocher</span></a><span style="text-align: start;">, uses 25% of the global supply of hazelnuts. </span>And hazelnut comes with several essential
nutrients including protein, phosphorous, manganese, zinc and magnesium.<o:p></o:p></div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEij9rHG6sdv6eVd61v2rLToMHW4PNaOVczs46zlhWyK0ulJivjeKv5gjcQ5R-aH7lu1tshSZTFjDs1aFPJaqluKiplQjqkzYFPW_HCGLNqR3qEBBmazysYhmxfSX7tBcwF0TW2MX1LqqU0/s1600/P9.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="651" data-original-width="877" height="293" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEij9rHG6sdv6eVd61v2rLToMHW4PNaOVczs46zlhWyK0ulJivjeKv5gjcQ5R-aH7lu1tshSZTFjDs1aFPJaqluKiplQjqkzYFPW_HCGLNqR3qEBBmazysYhmxfSX7tBcwF0TW2MX1LqqU0/s400/P9.jpg" width="400" /></a> </div>
<div class="MsoNormal">
Just as there are myths related to gelato, there are myths
related to Lean. Here are some
interesting ones I wanted to share.</div>
<div class="MsoNormal">
</div>
<ol style="text-align: left;">
<li>Lean is about doing more with less. It is about
cost cutting and job losses.</li>
<li>Lean is about following a set of prescribed
processes and tools.</li>
<li>Lean can prevent all problems.</li>
<li>Lean is best suited for manufacturing
environments.</li>
<li>Lean is about waste reduction only.</li>
<li>Lean means more work per team member.</li>
<li>Lean implementation in software projects cannot
be done without a specialized software or a tool.</li>
</ol>
<br />
<div class="MsoNormal">
Sources:<o:p></o:p></div>
<div class="MsoListParagraphCxSpMiddle" style="margin-left: 0in; mso-add-space: auto;">
</div>
<ol style="text-align: left;">
<li>Five
Lean Myths and the Reality of Thinking Lean - <a href="https://theleadershipnetwork.com/article/lean-myths-jeffrey-liker">https://theleadershipnetwork.com/article/lean-myths-jeffrey-liker</a></li>
<li>Top
10 Lean Manufacturing Myths - <a href="https://blog.safetyculture.com/industry-trends/top-10-lean-manufacturing-myths">https://blog.safetyculture.com/industry-trends/top-10-lean-manufacturing-myths</a></li>
</ol>
<o:p></o:p><br />
<div class="MsoListParagraphCxSpLast" style="margin-left: 0in; mso-add-space: auto;">
<o:p></o:p></div>
<div class="MsoNormal" style="text-align: justify;">
<o:p>
</o:p></div>
<div class="MsoNormal">
I know, for many of us these myths could be eye-openers. Also, I guess you have come across some more
myths on Lean. Please feel free to share those in your comments.</div>
<div class="MsoNormal">
<o:p></o:p></div>
<div class="MsoNormal">
</div>
<div class="MsoNormal" style="text-align: justify;">
<br /></div>
</div>
Raja Bavanihttp://www.blogger.com/profile/03107697584076683320noreply@blogger.com0tag:blogger.com,1999:blog-356516183452551110.post-85410271874959944992018-07-23T05:29:00.002-07:002018-08-09T05:12:17.786-07:00The Lean Gelateria | Part 8 | Muda, Muri and Mura<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="MsoNormal" style="text-align: justify;">
<b><u><a href="http://se-thoughtograph.blogspot.com/2018/06/lean-gelateria-part-7-dan-mango-and.html" target="_blank"><<<<<<<<<< Lean Gelateria | Part 7</a></u></b></div>
<div class="MsoNormal" style="text-align: justify;">
<br /></div>
<div class="MsoNormal" style="text-align: justify;">
In <u><a href="http://se-thoughtograph.blogspot.com/2018/06/the-lean-gelateria-part-5-resolutions.html" target="_blank">one of my earlier posts</a></u> I
discussed about the seven principles of Lean. ‘Eliminate Waste’ is the first principle. It very easy to remember and understand. And, it is about eliminating waste by
avoiding or removing activities that do not add value to business or contribute
to customer or improve productivity.<o:p></o:p></div>
<div class="MsoNormal" style="text-align: justify;">
<br /></div>
<div class="MsoNormal" style="text-align: justify;">
I am sure you have heard of ‘Toyota
3M Model’. It focuses on eradicating
the three enemies of Lean. Three enemies are Muda, Muri and Mura. These are
Japanese words. Muda means waste. Muri means overburden and Mura means
unevenness.<o:p></o:p></div>
<div class="MsoNormal" style="text-align: justify;">
<br /></div>
<div class="MsoNormal" style="text-align: justify;">
Let us pause on Muda, Muri and Mura and move to a different world for a while. Well, in the world of cherries,
it is worth knowing about a cherry that is Mini (small in size), Marvelous
(awesome) and Memorable (outstanding and unforgettable). It is nothing but the amarena cherry. Amarena is a dark colored cherry from the Bologna
and Modena regions of Italy. Amarena cherries are a good source of vitamin C,
potassium, magnesium and iron. Also they are free of fat, and sodium. Some experts claim that Amarena cherries
prevent heart diseases and cancer. Try Amarena gelato! I am sure you will like
its unique flavor and delicacy. In every scoop you will find one or two whole
cherries that are really chewy and delicious!<o:p></o:p></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhlaeOudRuW9yik27487SA9L-Knz4beUXtZ7k3oLtBnfHrPfL9Sk8PYWRx0PiZiKDS1m_-XLMCwf6gIP5P1nWSLPRewNpIIGOvp0Oq4UFzsmmwzyiaUYSzuGtSDSgSOGF9AoEJqq13zxn0/s1600/P8.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="557" data-original-width="849" height="256" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhlaeOudRuW9yik27487SA9L-Knz4beUXtZ7k3oLtBnfHrPfL9Sk8PYWRx0PiZiKDS1m_-XLMCwf6gIP5P1nWSLPRewNpIIGOvp0Oq4UFzsmmwzyiaUYSzuGtSDSgSOGF9AoEJqq13zxn0/s400/P8.jpg" width="400" /></a></div>
<div class="MsoNormal" style="text-align: center;">
<br /></div>
<div class="MsoNormal" style="text-align: justify;">
Coming back to ‘Toyota 3M Model’,
Muda comprises of seven types of wastes plus an additional one (non-utilized
skills). Remember the acronym DOWNTIME
to remember these seven plus one wastes.
As listed here in this table, these wastes are applicable to our
industry too.<o:p></o:p></div>
<div class="MsoNormal" style="text-align: justify;">
<br /></div>
<table border="1" cellpadding="0" cellspacing="0" class="MsoTableGrid" style="border-collapse: collapse; border: none; mso-border-alt: solid windowtext .5pt; mso-padding-alt: 0in 5.4pt 0in 5.4pt; mso-yfti-tbllook: 1184;">
<tbody>
<tr>
<td style="border: solid windowtext 1.0pt; mso-border-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt; width: 31.25pt;" valign="top" width="42"><div align="center" class="MsoNormal" style="line-height: normal; margin-bottom: .0001pt; margin-bottom: 0in; text-align: center;">
<b>#<o:p></o:p></b></div>
</td>
<td style="border-left: none; border: solid windowtext 1.0pt; mso-border-alt: solid windowtext .5pt; mso-border-left-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt; width: 3.0in;" valign="top" width="288"><div align="center" class="MsoNormal" style="line-height: normal; margin-bottom: .0001pt; margin-bottom: 0in; text-align: center;">
<b>Manufacturing
Industry<o:p></o:p></b></div>
</td>
<td style="border-left: none; border: solid windowtext 1.0pt; mso-border-alt: solid windowtext .5pt; mso-border-left-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt; width: 220.25pt;" valign="top" width="294"><div align="center" class="MsoNormal" style="line-height: normal; margin-bottom: .0001pt; margin-bottom: 0in; text-align: center;">
<b>Software
Industry<o:p></o:p></b></div>
</td>
</tr>
<tr>
<td style="border-top: none; border: solid windowtext 1.0pt; mso-border-alt: solid windowtext .5pt; mso-border-top-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt; width: 31.25pt;" valign="top" width="42"><div class="MsoNormal" style="line-height: normal; margin-bottom: .0001pt; margin-bottom: 0in; text-align: justify;">
1<o:p></o:p></div>
</td>
<td style="border-bottom: solid windowtext 1.0pt; border-left: none; border-right: solid windowtext 1.0pt; border-top: none; mso-border-alt: solid windowtext .5pt; mso-border-left-alt: solid windowtext .5pt; mso-border-top-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt; width: 3.0in;" valign="top" width="288"><div class="MsoNormal" style="line-height: normal; margin-bottom: .0001pt; margin-bottom: 0in; text-align: justify;">
Defects
- product defects, process
defects, tool defects<o:p></o:p></div>
</td>
<td style="border-bottom: solid windowtext 1.0pt; border-left: none; border-right: solid windowtext 1.0pt; border-top: none; mso-border-alt: solid windowtext .5pt; mso-border-left-alt: solid windowtext .5pt; mso-border-top-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt; width: 220.25pt;" valign="top" width="294"><div class="MsoNormal" style="line-height: normal; margin-bottom: .0001pt; margin-bottom: 0in; text-align: justify;">
Defects – all type of defects<o:p></o:p></div>
</td>
</tr>
<tr>
<td style="border-top: none; border: solid windowtext 1.0pt; mso-border-alt: solid windowtext .5pt; mso-border-top-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt; width: 31.25pt;" valign="top" width="42"><div class="MsoNormal" style="line-height: normal; margin-bottom: .0001pt; margin-bottom: 0in; text-align: justify;">
2<o:p></o:p></div>
</td>
<td style="border-bottom: solid windowtext 1.0pt; border-left: none; border-right: solid windowtext 1.0pt; border-top: none; mso-border-alt: solid windowtext .5pt; mso-border-left-alt: solid windowtext .5pt; mso-border-top-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt; width: 3.0in;" valign="top" width="288"><div class="MsoNormal" style="line-height: normal; margin-bottom: .0001pt; margin-bottom: 0in; text-align: justify;">
Overproduction – producing more units than what
customer has ordered<o:p></o:p></div>
</td>
<td style="border-bottom: solid windowtext 1.0pt; border-left: none; border-right: solid windowtext 1.0pt; border-top: none; mso-border-alt: solid windowtext .5pt; mso-border-left-alt: solid windowtext .5pt; mso-border-top-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt; width: 220.25pt;" valign="top" width="294"><div class="MsoNormal" style="line-height: normal; margin-bottom: .0001pt; margin-bottom: 0in; text-align: justify;">
Implementing features that may go unused<o:p></o:p></div>
</td>
</tr>
<tr>
<td style="border-top: none; border: solid windowtext 1.0pt; mso-border-alt: solid windowtext .5pt; mso-border-top-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt; width: 31.25pt;" valign="top" width="42"><div class="MsoNormal" style="line-height: normal; margin-bottom: .0001pt; margin-bottom: 0in; text-align: justify;">
3<o:p></o:p></div>
</td>
<td style="border-bottom: solid windowtext 1.0pt; border-left: none; border-right: solid windowtext 1.0pt; border-top: none; mso-border-alt: solid windowtext .5pt; mso-border-left-alt: solid windowtext .5pt; mso-border-top-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt; width: 3.0in;" valign="top" width="288"><div class="MsoNormal" style="line-height: normal; margin-bottom: .0001pt; margin-bottom: 0in; text-align: justify;">
Waiting – waiting of workers, production units,
or process steps<o:p></o:p></div>
</td>
<td style="border-bottom: solid windowtext 1.0pt; border-left: none; border-right: solid windowtext 1.0pt; border-top: none; mso-border-alt: solid windowtext .5pt; mso-border-left-alt: solid windowtext .5pt; mso-border-top-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt; width: 220.25pt;" valign="top" width="294"><div class="MsoNormal" style="line-height: normal; margin-bottom: .0001pt; margin-bottom: 0in; text-align: justify;">
In effective dependency management <o:p></o:p></div>
</td>
</tr>
<tr>
<td style="border-top: none; border: solid windowtext 1.0pt; mso-border-alt: solid windowtext .5pt; mso-border-top-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt; width: 31.25pt;" valign="top" width="42"><div class="MsoNormal" style="line-height: normal; margin-bottom: .0001pt; margin-bottom: 0in; text-align: justify;">
4<o:p></o:p></div>
</td>
<td style="border-bottom: solid windowtext 1.0pt; border-left: none; border-right: solid windowtext 1.0pt; border-top: none; mso-border-alt: solid windowtext .5pt; mso-border-left-alt: solid windowtext .5pt; mso-border-top-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt; width: 3.0in;" valign="top" width="288"><div class="MsoNormal" style="line-height: normal; margin-bottom: .0001pt; margin-bottom: 0in; text-align: justify;">
Non-utilized Skills<o:p></o:p></div>
</td>
<td style="border-bottom: solid windowtext 1.0pt; border-left: none; border-right: solid windowtext 1.0pt; border-top: none; mso-border-alt: solid windowtext .5pt; mso-border-left-alt: solid windowtext .5pt; mso-border-top-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt; width: 220.25pt;" valign="top" width="294"><div class="MsoNormal" style="line-height: normal; margin-bottom: .0001pt; margin-bottom: 0in; text-align: justify;">
A team member or a skill that remains non-utilized<o:p></o:p></div>
</td>
</tr>
<tr>
<td style="border-top: none; border: solid windowtext 1.0pt; mso-border-alt: solid windowtext .5pt; mso-border-top-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt; width: 31.25pt;" valign="top" width="42"><div class="MsoNormal" style="line-height: normal; margin-bottom: .0001pt; margin-bottom: 0in; text-align: justify;">
5<o:p></o:p></div>
</td>
<td style="border-bottom: solid windowtext 1.0pt; border-left: none; border-right: solid windowtext 1.0pt; border-top: none; mso-border-alt: solid windowtext .5pt; mso-border-left-alt: solid windowtext .5pt; mso-border-top-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt; width: 3.0in;" valign="top" width="288"><div class="MsoNormal" style="line-height: normal; margin-bottom: .0001pt; margin-bottom: 0in; text-align: justify;">
Transportation – Movement of products across
locations<o:p></o:p></div>
</td>
<td style="border-bottom: solid windowtext 1.0pt; border-left: none; border-right: solid windowtext 1.0pt; border-top: none; mso-border-alt: solid windowtext .5pt; mso-border-left-alt: solid windowtext .5pt; mso-border-top-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt; width: 220.25pt;" valign="top" width="294"><div class="MsoNormal" style="line-height: normal; margin-bottom: .0001pt; margin-bottom: 0in; text-align: justify;">
Avoidable travel or transportation or hand-offs<o:p></o:p></div>
</td>
</tr>
<tr>
<td style="border-top: none; border: solid windowtext 1.0pt; mso-border-alt: solid windowtext .5pt; mso-border-top-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt; width: 31.25pt;" valign="top" width="42"><div class="MsoNormal" style="line-height: normal; margin-bottom: .0001pt; margin-bottom: 0in; text-align: justify;">
6<o:p></o:p></div>
</td>
<td style="border-bottom: solid windowtext 1.0pt; border-left: none; border-right: solid windowtext 1.0pt; border-top: none; mso-border-alt: solid windowtext .5pt; mso-border-left-alt: solid windowtext .5pt; mso-border-top-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt; width: 3.0in;" valign="top" width="288"><div class="MsoNormal" style="line-height: normal; margin-bottom: .0001pt; margin-bottom: 0in; text-align: justify;">
Inventories -
Excess inventory of parts, tools, etc.<o:p></o:p></div>
</td>
<td style="border-bottom: solid windowtext 1.0pt; border-left: none; border-right: solid windowtext 1.0pt; border-top: none; mso-border-alt: solid windowtext .5pt; mso-border-left-alt: solid windowtext .5pt; mso-border-top-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt; width: 220.25pt;" valign="top" width="294"><div class="MsoNormal" style="line-height: normal; margin-bottom: .0001pt; margin-bottom: 0in; text-align: justify;">
Partially done work (WIP items)<o:p></o:p></div>
</td>
</tr>
<tr>
<td style="border-top: none; border: solid windowtext 1.0pt; mso-border-alt: solid windowtext .5pt; mso-border-top-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt; width: 31.25pt;" valign="top" width="42"><div class="MsoNormal" style="line-height: normal; margin-bottom: .0001pt; margin-bottom: 0in; text-align: justify;">
7<o:p></o:p></div>
</td>
<td style="border-bottom: solid windowtext 1.0pt; border-left: none; border-right: solid windowtext 1.0pt; border-top: none; mso-border-alt: solid windowtext .5pt; mso-border-left-alt: solid windowtext .5pt; mso-border-top-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt; width: 3.0in;" valign="top" width="288"><div class="MsoNormal" style="line-height: normal; margin-bottom: .0001pt; margin-bottom: 0in; text-align: justify;">
Motion – Avoidable physical movement of team
members <o:p></o:p></div>
</td>
<td style="border-bottom: solid windowtext 1.0pt; border-left: none; border-right: solid windowtext 1.0pt; border-top: none; mso-border-alt: solid windowtext .5pt; mso-border-left-alt: solid windowtext .5pt; mso-border-top-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt; width: 220.25pt;" valign="top" width="294"><div class="MsoNormal" style="line-height: normal; margin-bottom: .0001pt; margin-bottom: 0in; text-align: justify;">
Task switching, multi-tasking<o:p></o:p></div>
</td>
</tr>
<tr>
<td style="border-top: none; border: solid windowtext 1.0pt; mso-border-alt: solid windowtext .5pt; mso-border-top-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt; width: 31.25pt;" valign="top" width="42"><div class="MsoNormal" style="line-height: normal; margin-bottom: .0001pt; margin-bottom: 0in; text-align: justify;">
8<o:p></o:p></div>
</td>
<td style="border-bottom: solid windowtext 1.0pt; border-left: none; border-right: solid windowtext 1.0pt; border-top: none; mso-border-alt: solid windowtext .5pt; mso-border-left-alt: solid windowtext .5pt; mso-border-top-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt; width: 3.0in;" valign="top" width="288"><div class="MsoNormal" style="line-height: normal; margin-bottom: .0001pt; margin-bottom: 0in; text-align: justify;">
Excess Processing<o:p></o:p></div>
</td>
<td style="border-bottom: solid windowtext 1.0pt; border-left: none; border-right: solid windowtext 1.0pt; border-top: none; mso-border-alt: solid windowtext .5pt; mso-border-left-alt: solid windowtext .5pt; mso-border-top-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt; width: 220.25pt;" valign="top" width="294"><div class="MsoNormal" style="line-height: normal; margin-bottom: .0001pt; margin-bottom: 0in; text-align: justify;">
Too many features, rework, relearning<o:p></o:p></div>
</td>
</tr>
</tbody></table>
<div class="MsoNormal" style="text-align: justify;">
<br /></div>
<div class="MsoNormal" style="text-align: justify;">
Muri or overburden happens when
machines or team members are over utilized beyond their limits. This may lead to breakdown of machines or
absenteeism of team members. In software
industry it happens when we run a high-end software on a low-end computer with
bare minimum configuration – the machine eventually slows down and
crashes. Also, it happens when we allow
or make our team members stretch beyond limits by letting them putting extra
hours. This leads to health issues, dissatisfaction and absenteeism.<o:p></o:p></div>
<div class="MsoNormal" style="text-align: justify;">
<br /></div>
<div class="MsoNormal" style="text-align: justify;">
Mura or unevenness happens
because of fluctuations in customer demand or fluctuations in the service
levels offered by third parties. In
software projects, unevenness can happen because of fluctuations in scope or
insufficient backlog or too many changes.
This can lead to overburden or Muri and cause Muda or wastes.<o:p></o:p></div>
<div class="MsoNormal" style="text-align: justify;">
<br /></div>
<div class="MsoNormal" style="text-align: justify;">
How do we observe and apply these
in software projects? Let me share four examples with you.</div>
<div class="MsoNormal" style="text-align: justify;">
</div>
<ol>
<li>Lack
of collaboration and mindless reporting of defects can cause unevenness and
over burden.<span style="text-indent: -0.25in;"> </span><span style="text-indent: -0.25in;">This happens in large
projects where there is an independent verification team. So, it is worth
examining, ‘<u><a href="http://se-thoughtograph.blogspot.com/2014/03/is-this-bug-worth-reporting.html" target="_blank">Is this bug worth reporting?</a></u>’ and collaborate with team
members.</span><span style="text-indent: -0.25in;"> </span><span style="text-indent: -0.25in;">Mindful bug reporting is a
reflection of lean thinking in software project teams.</span></li>
<li>Sometimes documentation destroys value. It
is worth understanding <u><a href="http://se-thoughtograph.blogspot.com/2015/08/documentation-in-agile-projects-why-how.html" target="_blank">how Agile teams focus on documentation</a></u> in order to
optimize documentation efforts.</li>
<li>In
some projects, some of the underlying tools used by project teams may lead to
value erosion. So, it is worth understanding <u><a href="http://se-thoughtograph.blogspot.com/2013/06/when-tools-destroy-value.html" target="_blank">when tools destroy value</a></u> and avoid
such situations.</li>
<li>Lack
of <a href="http://se-thoughtograph.blogspot.com/2012/03/data-discipline-why-should-we-care.html" target="_blank">data discipline</a> may lead to waste or rework in the form of retesting or
unnoticed defects.</li>
</ol>
An essential aspect of practicing
Lean Thinking is about remembering these 3Ms, identifying the areas of
improvements and applying course correction. What has been your experience?<br />
<div class="MsoNormal" style="text-align: justify;">
<br />
<br />
<div style="text-align: right;">
<b><u><a href="http://se-thoughtograph.blogspot.com/2018/08/the-lean-gelateria-part-9-myths-not-to.html" target="_blank">Lean Gelateria | Part 9 >>>>>>></a></u></b></div>
<div style="text-align: left;">
<b><u><br /></u></b></div>
</div>
</div>
Raja Bavanihttp://www.blogger.com/profile/03107697584076683320noreply@blogger.com0tag:blogger.com,1999:blog-356516183452551110.post-56975077589700280692018-06-29T09:29:00.001-07:002018-07-23T05:31:20.224-07:00The Lean Gelateria | Part 7 | Dan, Mango and Kanban<div dir="ltr" style="text-align: left;" trbidi="on">
<b><u><a href="http://se-thoughtograph.blogspot.com/2018/06/the-lean-gelateria-part-6-daniel-brown.html" target="_blank"><<<<<<<<< Lean Gelateria | Part 6</a></u></b><br />
<br />
<div class="MsoNormal" style="text-align: justify;">
This is the continuation of my
previous post – ‘<b><u><a href="http://se-thoughtograph.blogspot.com/2018/06/the-lean-gelateria-part-6-daniel-brown.html" target="_blank">Daniel Brown and Mango</a></u></b>’. I suggest that you read it to
understand the first part of Dan’s story. <o:p></o:p></div>
<div class="MsoNormal" style="text-align: justify;">
<br /></div>
<div class="MsoNormal" style="text-align: justify;">
Do you remember? The first 2 hours of demo after the fourth
iteration resulted in a list of 50 items – defects, minor changes, new features,
etc. That was the first demo with Alicia
and three customer support managers! In
a way, it is good that Dan proposed a one-week acceptance testing after feature
completion. However, after a week of
acceptance testing Dan’s list had more than 275 items! Alicia was not happy! Tom, Dan’s boss, was shocked! All this resulted in an escalation! <o:p></o:p></div>
<div class="MsoNormal" style="text-align: justify;">
<br /></div>
<div class="MsoNormal" style="text-align: justify;">
Dan’s team was distressed. <o:p></o:p></div>
<div class="MsoNormal" style="text-align: justify;">
<br /></div>
<div class="MsoNormal" style="text-align: justify;">
Dan’s first priority was to resolve
all issues in this project and deliver the application. The first thing he wanted to do was to have
an open discussion with Alicia.</div>
<div class="MsoNormal" style="text-align: justify;">
<br /></div>
<div class="MsoNormal" style="text-align: justify;">
Coincidentally, Alicia initiated
a 1-1 meeting with Dan! She wanted to
understand all options in front of them to arrive at a win-win solution. They decided to meet in the neighborhood
gelateria. They chose the flavor of the day – ‘Mint and
Choco Chips’ gelato.</div>
<div class="MsoNormal" style="text-align: justify;">
<o:p></o:p></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEggB3T-s45pHRd8V42F7MkLGNyEvZv8phzeOo2M4OibWSKeHBnDOCT3gII3odPNNXQcQtrTfiG3_tTReu1u-d1DMfe3gHx1yB8U6o6eei3BZa2JMDUM90o-BpbrkjPYJDyvkHbh_48iL_0/s1600/P7JPG.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="453" data-original-width="610" height="293" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEggB3T-s45pHRd8V42F7MkLGNyEvZv8phzeOo2M4OibWSKeHBnDOCT3gII3odPNNXQcQtrTfiG3_tTReu1u-d1DMfe3gHx1yB8U6o6eei3BZa2JMDUM90o-BpbrkjPYJDyvkHbh_48iL_0/s400/P7JPG.jpg" width="400" /></a></div>
<div class="MsoNormal" style="text-align: right;">
<br /></div>
<div class="MsoNormal" style="text-align: justify;">
This meeting helped them share
their views and settle down on what to do next.
They wanted to put together a joint response and formed a governance
team of 3 - Alicia, Dan and Tom.<o:p></o:p></div>
<div class="MsoNormal" style="text-align: justify;">
<br /></div>
<div class="MsoNormal" style="text-align: justify;">
<b>Joint Response:</b> Tom, Dan, and Alicia had their first joint response
meeting to discuss the situation. The question in front of them was about
prioritizing and closing all items in a timely manner in such a way that they:</div>
<div class="MsoNormal" style="text-align: justify;">
</div>
<ol>
<li>Address
high priority items first and move on</li>
<li>Optimize
by grouping related items</li>
<li>Test
adequately to avoid failure</li>
<li>Understand
daily progress and make course correction</li>
<li>Maximize
the number of items closed per week through weekly analysis</li>
</ol>
<br />
<div class="MsoListParagraphCxSpLast" style="mso-list: l1 level1 lfo1; text-align: justify; text-indent: -.25in;">
<o:p></o:p></div>
<div class="MsoNormal" style="margin-left: 70.8pt; text-align: justify;">
<b>Visualizing the Workflow - </b>In his
discussion with Tom, Dan stressed on the need to create a visualized workflow using
a white board in a common room or work area. Dan shared his experience on how this
approach is more effective than emails and outdated tools. Tom agreed.<o:p></o:p></div>
<div class="MsoNormal" style="margin-left: 70.8pt; text-align: justify;">
<br /></div>
<div class="MsoNormal" style="margin-left: 70.8pt; text-align: justify;">
The next day,
Dan came in early, took a hard copy of prioritized work items, and created a
visual board in the meeting room. His team members helped him with their ideas.
They created about 20 to 30 rows on the board and divided each row into
multiple columns. Each column corresponded to the standard work flow – analyze,
code, test, verify, build, user acceptance, done. Each row represented a work
item with a work item identification number, short description, and other such
attributes.<o:p></o:p></div>
<div class="MsoNormal" style="margin-left: 70.8pt; text-align: justify;">
<br /></div>
<div class="MsoNormal" style="margin-left: 70.8pt; text-align: justify;">
<b>The Pull Factor:</b> From that day Dan and his team would begin their work day with a crisp meeting in front of
the white board. They also ended their work days by reviewing the items on the
white board and discussing ways to improve throughput and quality in future.
During the first few days, Dan was orchestrating the team on task assignment.
Gradually his team started not only pulling work items, but also logically
grouping work items in order to optimize the time spent in coding and testing. <o:p></o:p></div>
<div class="MsoNormal" style="margin-left: 70.8pt; text-align: justify;">
<br /></div>
<div class="MsoNormal" style="margin-left: 70.8pt; text-align: justify;">
<b>Limiting Work in Progress:</b> Based on his
experience, Dan believed that mindless context-switching is a waste of time.
This happens as a result of keeping many items open, switching back and forth,
and losing focus. He coached his team to complete as many tasks on hand as
possible before moving on to the next work item. He also shared with them the
ill effects of keeping several work-in-progress items. His team members grasped
the truth behind his suggestions.<o:p></o:p></div>
<div class="MsoNormal" style="margin-left: 70.8pt; text-align: justify;">
<br /></div>
<div class="MsoNormal" style="margin-left: 70.8pt; text-align: justify;">
<b>Collaborative Learning:</b> During these
tough weeks, every daily meeting or weekly retrospective was a learning
experience. Team members shared debugging techniques, domain-specific issues,
etc. with the rest of the team to enrich their knowledge and prevent similar
issues. Even during the first week they found ways to minimize the number of
defects by discussing and implementing simple techniques to improve quality in
each step of the workflow. <o:p></o:p></div>
<div class="MsoNormal" style="margin-left: 70.8pt; text-align: justify;">
<br /></div>
<div class="MsoNormal" style="margin-left: 70.8pt; text-align: justify;">
<b>The Outcome:</b> Eventually, Dan’s team
became faster and smarter. Dan could see an increasing trend in the completion
of work items. Seeing these positive signs, Alicia regained her trust. Within four
weeks, the list of pending items had shrunk to 20.<o:p></o:p></div>
<div class="MsoNormal" style="margin-left: 70.8pt; text-align: justify;">
By the end of
the fifth week, they only had ten low priority issues on hand. With a schedule
overrun of about 6 weeks, Alicia certified the application for user training
and implementation.<o:p></o:p></div>
<div class="MsoNormal" style="margin-left: 70.8pt; text-align: justify;">
<br /></div>
<div class="MsoNormal" style="margin-left: 70.8pt; text-align: justify;">
<b>Reflection and Recognition:</b> A week
after the initiation of user training, Tom and Alicia sponsored a dinner for
Dan and his team. On the dinner day, Dan convened a 30-minute retrospective
with his team. Alicia, Dan, and his team discussed several aspects of the
project including what went well, lessons learned, and areas of improvement. Everyone
agreed that as soon as they came across innumerable changes and new work items
they worked together to find a new approach and it helped them take charge of
the situation. The key factors that enabled them deliver results were:<o:p></o:p></div>
<div class="MsoNormal" style="margin-left: 70.8pt; text-align: justify;">
</div>
<ol style="text-align: left;"><ol><ol>
<li>Visualizing Workflow</li>
<li>Limiting Work-in-Progress and Minimizing
Context-Switching</li>
<li>Measuring and Managing Flow</li>
<li>Nurturing an Open Environment and Making
Processes and Policies Explicit</li>
<li>Identifying Improvement Opportunities</li>
</ol>
</ol>
</ol>
<br />
<div class="MsoNormal" style="margin-left: 70.8pt; text-align: justify;">
Both Alicia
and Dan agreed that they needed to consider demos to end users and
retrospectives at the end of iterations in their projects in order to minimize
the spurt of changes and ideas at project completion. <o:p></o:p></div>
<div class="MsoNormal" style="margin-left: 70.8pt; text-align: justify;">
<br /></div>
<div class="MsoNormal" style="text-align: justify;">
<b>Kanban Know-how:</b> Years after this incident Dan reads an article titled
‘Introduction to Kanban” and later attends a Kanban workshop. He is able to relate
these to his project experience – he identifies many similarities and some
improvement ideas. He feels proud of himself and his team and shares his
thoughts with his team mates. He feels proud because he can connect with the
essence of Kanban in his approach. He feels proud because his experience and
knowledge make him realize the power of Kanban!<o:p></o:p></div>
<div class="MsoNormal" style="text-align: justify;">
<br /></div>
<div class="MsoNormal" style="text-align: justify;">
With hindsight, he feels that he
could have used yellow stickers or a tool to improve effectiveness and
optimized the time spent managing the visual board. He could have hired a
Kanban coach to help his team in areas such as value stream mapping. However,
he realizes that the popularity of Kanban in the software industry has grown
only in recent years. <o:p></o:p></div>
<div class="MsoNormal" style="text-align: justify;">
<br /></div>
<div class="MsoNormal" style="text-align: justify;">
Six months after these happenings
and with a promotion at work, Dan continues to execute projects using Agile,
Lean and Kanban.<o:p></o:p></div>
<div class="MsoNormal" style="text-align: justify;">
<br /></div>
<div class="MsoNormal" style="text-align: justify;">
What has been your experience related to implementing Kanban?<br />
<br />
<div style="text-align: right;">
<b><u><a href="http://se-thoughtograph.blogspot.com/2018/07/the-lean-gelateria-part-8-muda-muri-and.html" target="_blank">Lean Gelateria | Part 8 >>>>>>>>>></a></u></b></div>
</div>
<div class="MsoNormal" style="text-align: justify;">
<br /></div>
</div>
Raja Bavanihttp://www.blogger.com/profile/03107697584076683320noreply@blogger.com0tag:blogger.com,1999:blog-356516183452551110.post-68423441886119626812018-06-29T08:08:00.000-07:002018-06-29T09:32:39.534-07:00The Lean Gelateria | Part 6 | Daniel Brown and Mango<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="MsoNormal" style="text-align: justify;">
<b><u><a href="http://se-thoughtograph.blogspot.com/2018/06/the-lean-gelateria-part-5-resolutions.html" target="_blank"><<<<<<<<<< Lean Gelateria | Part 5</a></u></b><br />
<br />
This blog post is Dan’s
story. Dan is a medium built and upbeat
UK born software engineer. He wanted to work with hi-tech teams in software
engineering and immigrated to United States during early 90s. Traveling to places
was his hobby. He spent his weekends and
vacation in travel. Dan visited India in
May’94 and spent a month. He visited all
prominent states, cities and country side.
That is when he tasted Indian mangoes of different types – <i>Alphonso,
Kesar, Dussheri, Neelam, Rumani, Banganpalli, Rajapuri, Totapuri</i> and so
on. Like most travelers, he took
pleasure in eating Indian mangoes.<o:p></o:p></div>
<div class="MsoNormal" style="text-align: justify;">
<br /></div>
<div class="MsoNormal" style="text-align: justify;">
Back in the United States, he found a
neighborhood shop that served mango ice cream. He loved it. Couple of years
later, they started offering mango gelato! These days, Dan continues to frequent that shop to have a scoop of mango
gelato!<o:p></o:p><br />
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjS_Fxd5ODSDABNF4a7M5Gh9NBxhD4Qi1Om9VfFVIHsDxkD4D0DIVsBKh-31JDJ6h8aiERupk8PD0wT_6hrhHs3TfXFkwMGcG7MvWj-M0HAGoavKxn3Hd_WCY3RMjs20shB2uPsU9BH0H8/s1600/P6.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="700" data-original-width="770" height="289" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjS_Fxd5ODSDABNF4a7M5Gh9NBxhD4Qi1Om9VfFVIHsDxkD4D0DIVsBKh-31JDJ6h8aiERupk8PD0wT_6hrhHs3TfXFkwMGcG7MvWj-M0HAGoavKxn3Hd_WCY3RMjs20shB2uPsU9BH0H8/s320/P6.jpg" width="320" /></a></div>
<div class="MsoNormal" style="text-align: center;">
<br /></div>
<div class="MsoNormal" style="text-align: justify;">
Some of his close friends started
calling him Dango (Daniel Mango) because of obvious reasons!<o:p></o:p></div>
<div class="MsoNormal" style="text-align: justify;">
<br /></div>
<div class="MsoNormal" style="text-align: justify;">
<b>Dan’s Delight:</b> On Monday after the Labor Day weekend of 2002, Dan
was on top of the world because Tom, his boss, assigned him one of the most technically
challenging projects in the company. Tom was the IT director of a large
manufacturing company that supplied electronic utilities to households through
retail outlets. Dan was one of his direct reports who played the role of
project manager in IT projects.<o:p></o:p></div>
<div class="MsoNormal" style="text-align: justify;">
<br /></div>
<div class="MsoNormal" style="text-align: justify;">
This project, named DA
(disconnected access), was about enabling their technical support team through a
state-of-the-art application to support disconnected access to their central
databases. Using this application, their support team could reach end users
living in remote areas, provide them with necessary support, collect payment,
and print invoices even if there was no connectivity to central servers. The
goal was to improve customer satisfaction and this was one of the strategic
projects of the year under the CEO’s radar.<o:p></o:p></div>
<div class="MsoNormal" style="text-align: justify;">
<br /></div>
<div class="MsoNormal" style="text-align: justify;">
<b>Customer Confidence:</b> Dan and his team of four engineers studied the
high level requirements, analyzed the pros and cons of three different
architectures, and selected the most optimal one. Considering the business
demand and the estimates, they agreed to deliver the application in three months.
Alicia was the point-of-contact in the business and she had worked with Dan on
a different project a year ago. She had more than fifteen years of experience
in her domain. In project DA, she worked closely with Dan and his team in
creating and reviewing the user interface design during the initial weeks. She was
happy with the suggestions and ideas from Dan and his team and was confident
that the team would deliver results.<o:p></o:p></div>
<div class="MsoNormal" style="text-align: justify;">
<br /></div>
<div class="MsoNormal" style="text-align: justify;">
<b>Iterative Approach:</b> Dan believed in an iterative approach and
decided with his team to execute this project in five iterations of two weeks
each. As the application incrementally evolved over these five iterations, and
the schedule was aggressive, Dan could not demonstrate the finished product to
Alicia before the end of the fourth iteration. Alicia had also invited three
customer support managers from different regions to attend the demo.<o:p></o:p></div>
<div class="MsoNormal" style="text-align: justify;">
<br /></div>
<div class="MsoNormal" style="text-align: justify;">
<b>Delayed Demo:</b> No wonder, in each step of the demo, Alicia and the
customer support managers started discussing new options and asking Dan whether
the user interaction can be improved further.
They suggested new ideas which turned into changes to the user interface
or validation aspects. After a two-hour demo, Dan and his team came out with a
list of 50 items, some of which were new features, some others were changes,
and the rest were cosmetic changes and defects.<o:p></o:p></div>
<div class="MsoNormal" style="text-align: justify;">
<br /></div>
<div class="MsoNormal" style="text-align: justify;">
<b>The Aftermath:</b> Dan had a suggestion – that Alicia and her three
managers plan a one-week acceptance testing after feature completion in order
to explore all the features and provide him with their feedback. Alicia agreed.
After a week of acceptance testing Dan’s list had more than 275 items. Alicia
was not happy with the results and Tom, Dan’s boss, was shocked. Dan’s team was
distressed that, in spite of their sincere efforts, they had to manage this
escalation. <o:p></o:p></div>
<div class="MsoNormal" style="text-align: justify;">
<br /></div>
<div class="MsoNormal" style="text-align: justify;">
Dan had to forgo his visits to
his favorite places including the neighborhood gelateria. He wanted to resolve all issues in this
project and deliver the application.<o:p></o:p></div>
<div class="MsoNormal" style="text-align: justify;">
<br /></div>
<div class="MsoNormal" style="text-align: justify;">
What did he do is coming in the <b><u><a href="http://se-thoughtograph.blogspot.com/2018/06/lean-gelateria-part-7-dan-mango-and.html" target="_blank">next part</a></u></b> of this series.<o:p></o:p></div>
<div class="MsoNormal" style="text-align: justify;">
</div>
<div class="MsoNormal" style="text-align: justify;">
<br />
<div style="text-align: right;">
<b><u><a href="http://se-thoughtograph.blogspot.com/2018/06/lean-gelateria-part-7-dan-mango-and.html" target="_blank">Lean Gelateria | Part 7 >>>>>>>></a></u></b></div>
<br /></div>
</div>
Raja Bavanihttp://www.blogger.com/profile/03107697584076683320noreply@blogger.com1tag:blogger.com,1999:blog-356516183452551110.post-79799927764562236522018-06-20T08:07:00.001-07:002018-06-29T08:36:22.006-07:00The Lean Gelateria | Part 5 | Resolutions and Principles<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="MsoNormal">
<b><u><a href="http://se-thoughtograph.blogspot.com/2018/06/lean-gelateria-part-4-imitations-galore.html" target="_blank"><<<<<<<<<<<< Lean Gelateria | Part 4</a></u></b><br />
<br /></div>
<div class="MsoNormal">
<b>New Year and
Resolutions<o:p></o:p></b></div>
<div class="MsoNormal" style="text-align: justify;">
Welcoming a new year with grand celebrations
and a list of resolutions is not uncommon.
Many of us go to places, rock with loud music, scream to welcome the
first of January, travel around the city and go home at wee hours. Some of us do it differently – we stay home with
families and welcome the new year. Some of us decide on a set of resolutions
and strive to stay focused. Some of us choose not to have any resolutions. All
of us are not the same. That’s how we are.<o:p></o:p><br />
<br /></div>
<div class="MsoNormal" style="text-align: justify;">
Sometimes, some of us who focus
on resolutions don’t succeed. When it happens, we make sure that our
resolutions get carried forward to the next year.<o:p></o:p><br />
<br /></div>
<div class="MsoNormal" style="text-align: justify;">
Sometime in 2012, Time magazine
listed the top 10 most commonly broken New Year resolutions. One of those resolutions is ‘Eat Healthier and
Diet’. A familiar one. In this busy and modernized world, it is very
challenging to eat healthier and diet. Isn't it?<o:p></o:p><br />
<br /></div>
<div class="MsoNormal" style="text-align: justify;">
What can we do? Eat whole fruits. Stay away from ice-cream and have some gelato – I mean authentic
gelato. Next
time, when you get a chance, try strawberry gelato.<o:p></o:p></div>
<div class="MsoNormal" style="text-align: justify;">
<br /></div>
<div class="MsoNormal" style="text-align: justify;">
<b>Keeping your resolutions alive<o:p></o:p></b></div>
<div class="MsoNormal" style="text-align: justify;">
How can you keep your resolutions
alive? How can you make sure that you stick to your list of resolutions? When your resolutions are based on strong
principles, it is highly probable that your resolutions stay in your mind all
the time. You keep remembering
them. However, you may get distracted
due to something or the other, deviate, violate and break some of your
resolutions. How do you avoid such
deviations or violations? If you believe
in what you want to do, have a strong purpose that supports your resolution,
and ensure focus, you will see encouraging results.<o:p></o:p><br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj_w-IXX0wSRA2iLaZHhj635hnbbj7yN6BpN1R7MVfQux574klcuSw-_cqVwtM2kgp2OHOmGScF4hR3NFzJNgwBB-1NAPrZMygNu6ffmrW4-lBoi-4q7mF_1aKRGatT1J7Jxk2HA0sXPdQ/s1600/P5.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><span style="color: black;"><img border="0" data-original-height="720" data-original-width="960" height="300" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj_w-IXX0wSRA2iLaZHhj635hnbbj7yN6BpN1R7MVfQux574klcuSw-_cqVwtM2kgp2OHOmGScF4hR3NFzJNgwBB-1NAPrZMygNu6ffmrW4-lBoi-4q7mF_1aKRGatT1J7Jxk2HA0sXPdQ/s400/P5.jpg" width="400" /></span></a></div>
<div style="text-align: center;">
<br /></div>
<b><span lang="EN">Is learning in your list?</span></b></div>
<div class="MsoNormal">
Did you plan to learn something new in 2018? Is that one of your resolutions? How do you make room for learning? Have you already started? Are you trying alternate approaches? Albert Einstein said, <i>“Insanity is doing the same thing over and over again and expecting
different results.” </i><o:p></o:p><br />
<i><br /></i></div>
<div class="MsoNormal">
Learning about Lean Thinking, Agile and Lean Software Development
is going to help you perform your day-to-day activities optimally. That could
lead to optimizing your efforts and learning further. Learning something new is
a wonderful experience.<o:p></o:p><br />
<br /></div>
<div class="MsoNormal" style="text-align: justify;">
<b>Principles that keep us lean<o:p></o:p></b></div>
<div class="MsoNormal" style="text-align: justify;">
Agile and Lean are based on
value-driven philosophy. When you
analyze the way you do things (also known as process) with Lean Thinking, you
put them under three categories - 1) processes that add value to customer, 2)
processes that add value to business and 3) processes that do not add any
value. This is because Lean is based on
the following seven principles.<br />
<br />
<ol>
<li><b>Eliminate
waste</b> - Eliminate waste by avoiding or
removing activities that do not add value to business, or contribute to
customer value add or improve product quality.</li>
<li><b>Amplify
learning</b> – Learn as a group. Share knowledge among team members. Ensure
knowledge retention and reuse.</li>
<li><b>Delay
commitment</b> - Avoid premature decisions and commitments. Encourage decision making when there are
adequate facts and fewer assumptions.</li>
<li><b>Delivery
quickly</b> – Delivery early and frequently so that you get feedback to incorporate
in the next cycle or iteration.</li>
<li><b>Empower
the team</b> - Respect people. Encourage team members to solve problems and
identify best solutions. Provide
suggestions and motivate the teams.</li>
<li><b>Build
quality in</b> - Build integrity and quality into the product from initial
stages. Do not attempt to initiate steps
to build quality into product when the product is ready for integration
testing.</li>
<li><b>Optimize
the whole</b> – Optimizing only one or two parts of the system does not improve the
system. Any improvement initiative needs
to consider the entire system as a whole. </li>
</ol>
</div>
<div class="MsoListParagraphCxSpLast" style="mso-list: l0 level1 lfo1; text-align: justify; text-indent: -.25in;">
<o:p></o:p></div>
<div class="MsoNormal" style="text-align: justify;">
<b>Let me ask you</b></div>
<div class="MsoNormal" style="text-align: justify;">
Can you give examples of wastes
in software projects? How can we
categorize waste in software engineering?<o:p></o:p><br />
<br />
<div style="text-align: right;">
<b><u><a href="http://se-thoughtograph.blogspot.com/2018/06/the-lean-gelateria-part-6-daniel-brown.html" target="_blank">Lean Gelateria | Part 6 >>>>>></a></u></b></div>
</div>
<br />
<div class="MsoNormal" style="text-align: justify;">
<br /></div>
</div>
Raja Bavanihttp://www.blogger.com/profile/03107697584076683320noreply@blogger.com0tag:blogger.com,1999:blog-356516183452551110.post-55614737110795075602018-06-17T07:06:00.004-07:002018-06-20T08:09:51.617-07:00The Lean Gelateria | Part 4 | Imitations Galore!<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="MsoNormal">
<b><u><a href="http://se-thoughtograph.blogspot.com/2018/06/the-lean-gelateria-part-3-foundation-of.html" target="_blank"><<<<<<<<<<<< Lean Gelateria | Part 3</a></u></b><br />
<b><br /></b>
<b>Do you know?<o:p></o:p></b></div>
<div class="MsoNormal">
<span style="text-align: justify;">There are tens of thousands of gelato
shops around the world. However, it is very rare to find a shop that matches
the authenticity and delicacy of Italian Gelato!</span><span style="text-align: justify;"> </span><span style="text-align: justify;">Everyone knows the recipe, the procedure or
the method.</span><span style="text-align: justify;"> </span><span style="text-align: justify;">Less than 0.1% of them
deliver authentic gelato.</span><span style="text-align: justify;"> </span><span style="text-align: justify;">Why so?</span></div>
<div class="MsoNormal" style="text-align: justify;">
<o:p></o:p></div>
<div class="MsoNormal" style="text-align: justify;">
<br /></div>
<div class="MsoNormal" style="text-align: justify;">
<b>The answer<o:p></o:p></b></div>
<div class="MsoNormal" style="text-align: justify;">
In 2011, Larry<span lang="EN"> Olmstead, wrote an article ‘The Best Gelato in
America’, in Forbes Magazine. In this
article, he says,</span></div>
<div class="MsoNormal" style="text-align: justify;">
<span lang="EN"><br /></span></div>
<div class="MsoNormal" style="text-align: justify;">
<i><span lang="EN">"I had never had standout
gelato on our shores </span></i><span lang="EN">(i.e.
United States)<i>. I’ve had okay gelato, ……
but not great gelato. The biggest problems are either “mass market” style
gelatos made from bagged mixes, which you will find in resort areas and
malls, and hipster-style gelato, which seeks to improve on the original
before mastering the original, with flavors like star anise when they can’t
perfect pistachio."<o:p></o:p></i></span></div>
<div class="MsoNormal" style="text-align: justify;">
<span lang="EN"><br /></span></div>
<div class="MsoNormal" style="text-align: justify;">
<span lang="EN">And he adds, </span><i><span lang="EN">"When it comes to gelato, I
usually go for a fruit or nut version, which I rarely do in ice cream, because
the nature of gelato amplifies the taste of the ingredients. The benchmark
gelato is pistachio, because every shop in Italy has it and Italy grows some of
the world’s best pistachios. The
easiest way to assess gelato is simply by looking at it. Good gelato has muted
natural colors, nothing bright. Pistachios are not actually electric green, and
neither are kiwis, while cantaloupes are light orange, not bright orange."</span></i></div>
<div class="MsoNormal" style="text-align: justify;">
<i><span lang="EN"><br /></span></i></div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgRuXNgy7zINGc57VSW-TJbCvKmAsK7U7t0VjB6KhXu52tu41N5ErCTsBkzQZOvgI-FPHKun4kfxDvZ4LXaLC2H_YztEcl7Enkuk5YpbNV1rDNrUsb2XNSiCAWlEZMS71p8CX0Y2yVoZtM/s1600/P4.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="720" data-original-width="960" height="300" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgRuXNgy7zINGc57VSW-TJbCvKmAsK7U7t0VjB6KhXu52tu41N5ErCTsBkzQZOvgI-FPHKun4kfxDvZ4LXaLC2H_YztEcl7Enkuk5YpbNV1rDNrUsb2XNSiCAWlEZMS71p8CX0Y2yVoZtM/s400/P4.jpg" width="400" /></a></div>
<div class="MsoNormal" style="text-align: center;">
<br /></div>
<div class="MsoNormal" style="text-align: justify;">
<b>Weak pillars don’t support</b></div>
<div class="MsoNormal" style="text-align: justify;">
In <u><a href="http://se-thoughtograph.blogspot.com/2018/06/lean-gelateria-part-2-lean-goal.html" target="_blank">Part-2</a></u> of this blog series, I mentioned that not
only MIT researchers but also thousands of senior leaders from several
corporates visited Toyota’s production lines in Japan. They studied the practices and returned home
to implement them. Most of them
implemented all such practices but failed to demonstrate results! Meanwhile, Toyota replicated its practices
in United States and started manufacturing cars there! It worked seamlessly.<o:p></o:p></div>
<div class="MsoNormal" style="text-align: justify;">
<br /></div>
<div class="MsoNormal" style="text-align: justify;">
“The pillars of Lean Thinking are
not tools and waste reduction”, says Craig Larman. <o:p></o:p></div>
<div class="MsoNormal" style="text-align: justify;">
<br /></div>
<div class="MsoNormal" style="text-align: justify;">
Toyota president Gary Convis
says, “The two pillars that support <i>The
Toyota Way</i> (also known as Lean Thinking) are, <b>Respect for People </b>and <b>Continuous
Improvement</b>”<b>. <o:p></o:p></b></div>
<div class="MsoNormal" style="text-align: justify;">
<b><br /></b></div>
<div class="MsoNormal" style="text-align: justify;">
When you have respect for people,
you harness the intellect of employees, you establish a meaningful relationship
with customers, you do not allocate wasteful work to teams, and finally you
develop teams and grow customers.<o:p></o:p></div>
<div class="MsoNormal" style="text-align: justify;">
<br /></div>
<div class="MsoNormal" style="text-align: justify;">
<b>Harnessing the intellect</b></div>
<div class="MsoNormal" style="text-align: justify;">
In 2006, Gary Hamel wrote a paper
“<i>Management Innovation</i>” in <b>Harvard Business Review</b>. In this paper he wrote, “Only after American
carmakers had exhausted every other explanation for Toyota’s success – an
undervalued yen, a docile workforce, Japanese culture, and superior automation
– were they finally able to admit that Toyota’s real advantage was its ability
to harness the intellect of ‘ordinary’ employees.”<o:p></o:p></div>
<div class="MsoNormal" style="text-align: justify;">
<br /></div>
<div class="MsoNormal" style="text-align: justify;">
In Agile 2006, Tom Poppendieck
said, “Today, GM and Ford have adopted most of the [Lean] practices. They
understand about eliminating waste. But, they neglected the other pillar of
Lean. The other foundational pillar of Lean is ‘<b>Respect People</b>’. That is the huge difference. When you respect
people, you don’t waste their work. You don’t ask them to do useless things.
You train them. You treasure their input. You enable them to do the very best job
they can. And, you give them pride in their work. Pride is the most important
compensation you can give anybody – not money.”<o:p></o:p></div>
<div class="MsoNormal" style="text-align: justify;">
Makes lot of sense! Right?</div>
<div class="MsoNormal" style="text-align: justify;">
<o:p></o:p></div>
<div class="MsoNormal" style="text-align: justify;">
<b>Let me ask you<o:p></o:p></b></div>
<div class="MsoNormal" style="text-align: justify;">
What do these two pillars of lean
mean to you? What practices relate to these two pillars?</div>
<div class="MsoNormal" style="text-align: justify;">
<br />
<div style="text-align: right;">
<b><u><a href="http://se-thoughtograph.blogspot.com/2018/06/the-lean-gelateria-part-5-resolutions.html" target="_blank">Lean Gelateria | Part 5>>>>>>>>>>></a></u></b></div>
</div>
</div>
Raja Bavanihttp://www.blogger.com/profile/03107697584076683320noreply@blogger.com0tag:blogger.com,1999:blog-356516183452551110.post-7155767468104755462018-06-13T07:27:00.000-07:002018-06-17T07:13:28.753-07:00The Lean Gelateria | Part 3 | The Foundation of Lean<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="MsoNormal">
<br />
<div class="MsoNormal">
<b style="text-align: right;"><u><<<<<<<<<< <a href="http://se-thoughtograph.blogspot.com/2018/06/lean-gelateria-part-2-lean-goal.html" target="_blank">The Lean Gelateria | Part 2 </a></u></b><br />
<b style="text-align: right;"><br /></b></div>
<b>The Gelato
Culture<o:p></o:p></b></div>
<div class="MsoNormal">
Do you know? Carpigiani
Gelato University is dedicated to the development of the gelato culture
throughout the world. According to the
faculty here, Gelato is a natural food with important nutritional value. In
fact, the ingredients of gelato are the same as those you probably use almost
every day: milk, eggs, cream, cocoa, fruit and basic building blocks like
proteins, sugar, fat, vitamins, minerals, and fiber. It is interesting to
highlight that gelato does have important nutritional value. It's nice to know
that there is a food out there that is so delicious and yet good for you!</div>
<div class="MsoNormal">
<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<b>How about Vanilla?<o:p></o:p></b></div>
<div class="MsoNormal">
I am sure you have tried vanilla ice cream with chocolate
sauce. This is not what I am talking about.
Have you ever tried vanilla gelato? Sometimes, it is prepared with a
fresh twist of lemon! Try! It is simple
and delicious! Yes, simply delicious!</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhHvfIDioXfFqTxijibls9KI1TuiLOO4mUicEp3hH4KI6Lzz0nj5rDQSVoiut68MbmfTQJuene69DrBtwBmRKXzcGm-P7C7zQ9gtitbZKFOT05DbgmnrYB7-Rz77MZuYveXDyGMc7p0wsE/s1600/P31.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><span style="color: black;"><img border="0" data-original-height="543" data-original-width="881" height="245" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhHvfIDioXfFqTxijibls9KI1TuiLOO4mUicEp3hH4KI6Lzz0nj5rDQSVoiut68MbmfTQJuene69DrBtwBmRKXzcGm-P7C7zQ9gtitbZKFOT05DbgmnrYB7-Rz77MZuYveXDyGMc7p0wsE/s400/P31.jpg" width="400" /></span></a></div>
<div class="MsoNormal">
<b>The Foundation – Eh?
Secret Anagram!<o:p></o:p></b></div>
<div class="MsoNormal">
Is it true that Kanban boards, lean tools and waste
reduction are the foundation blocks of lean?
The answer, as you may guess is ‘no’. </div>
<div class="MsoNormal">
<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
If the answer is no, what is the foundation of lean or lean
thinking? “The foundation of lean is
not tools or waste reduction”, says Craig Larman and he adds, “The more one
learns about lean, the more one appreciates that the foundation is <b>manager-teachers</b> who live and teach it
and have long hands-on experience.” <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Let me explain. In
Toyota, most new employees underwent several months of learning to understand
and internalize the foundations of lean thinking. They learned how to identify waste. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Managers practiced ‘Go See’, which means going to their
teams and seeing how things happen with their own eyes rather than believing or
learning the truth from reports or dashboards!
The Japanese term for this simple practice is ‘<i>genchi genbutsu</i>’. It means ‘Go See’ or solve problems at the
source by observing and verifying data.
When you do this you will have more than superficial understanding of
project status.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Toyota managers appreciated the importance of ‘<i>gemba</i>’ - the
real place or the place where value is created.
It is the front-line where hands-on value workers are!<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Unless you see what is happening at the workplace or unless
you sit with hands-on engineers and understand how they create, maintain and
test software you can’t come up with useful <i>kaizen</i> or improvement. This is more than MBWA or ‘Management by
Walking Around’. When you do MBWA, you
may or may not observe details. You talk to team members and build rapport.
You ask some questions, not necessarily powerful questions or deep questions all the time. And you move on. Are you happy with the effect
of your MBWA practice? Have you come up with any suggestions or ideas to your
team members on continuous improvement?
Learn more about ‘Go See’ or <i>genchi
genbutsu</i> and put it into practice!<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Once, the president of Toyota said to the management team,
“I want you actively to train your team members on how to think for
themselves.” This reflects the culture
of the management. Toyota managers were educated in lean
thinking, continuous improvement, root cause analysis, statistics, systems
thinking, etc. They were educated about how to coach their teams. ‘Good Thinking, Good Products!’, is the internal motto
here. The culture of mentoring helped
in ensuring good thinking. Managers were
hands-on experts in their domain. Team
members learned from their managers.
Managers were not directors; they were teachers of lean thinking. They worked along with their teams. They did not join meetings over phone!</div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
The foundation of lean is manager-teachers who live and
teach it and have long hands-on experience. It is not cutting cost or
implementing new tools or reducing waste.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<b>Eh? Secret Anagram!</b></div>
<div class="MsoNormal">
Anagram is a word or phrase or name formed by rearranging
the letters of another. For example, the anagram of ‘forty five’ is ‘over
fifty’.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
What is the foundation of lean? It is the anagram of ‘Eh
Secret Anagram’. Find it!<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
I am sure you got it!
I have put it bold already! <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<b>Let me ask you</b></div>
<div class="MsoNormal">
Have you experienced any of the
concepts discussed in this post?</div>
<div class="MsoNormal">
<b><u><a href="http://se-thoughtograph.blogspot.com/2018/06/lean-gelateria-part-4-imitations-galore.html" target="_blank"><br /></a></u></b>
<div style="text-align: right;">
<b><u><a href="http://se-thoughtograph.blogspot.com/2018/06/lean-gelateria-part-4-imitations-galore.html" target="_blank">Lean Gelateria | Part 4 >>>>>>></a></u></b>.</div>
<div style="text-align: right;">
<br /></div>
</div>
</div>
Raja Bavanihttp://www.blogger.com/profile/03107697584076683320noreply@blogger.com0tag:blogger.com,1999:blog-356516183452551110.post-23215255916761344592018-06-06T06:34:00.001-07:002018-06-13T07:29:39.370-07:00The Lean Gelateria | Part 2 | Lean? The Goal?<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="MsoNormal">
<b><u><a href="http://se-thoughtograph.blogspot.com/2018/06/the-lean-gelateria-part-1-lean-what-is.html" target="_blank"><<<<< The Lean Gelateria | Part 1</a></u></b><br />
<b><br /></b>
<b>Italy, Sicily and
Gelato: <o:p></o:p></b></div>
<div class="MsoNormal">
Do you know? Gelato
was invented in the 16th century in Italy.
The island of Sicily was its birthplace!
The art of gelato making was passed on and perfected in Italy until the 20th
century. That is when many Italian
families specializing in gelato making traveled to several countries in Europe
and introduced gelato across Europe. Italy has more than 35000 shops that sell ice creams and gelatos and
continues to retain the authenticity as one would say ‘If you want authentic
homemade gelato, you have to visit Italy!’<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<b>Who would say ‘No’?<o:p></o:p></b></div>
<div class="MsoNormal">
Do you say yes to chocolate? If yes, try chocolate
gelato! This is a wonderful flavor and it comes with the health benefits
of both chocolate and gelato.<br />
<br /></div>
<div class="MsoNormal">
<o:p></o:p></div>
<div class="MsoNormal">
<!--[if gte vml 1]><v:shapetype
id="_x0000_t75" coordsize="21600,21600" o:spt="75" o:preferrelative="t"
path="m@4@5l@4@11@9@11@9@5xe" filled="f" stroked="f">
<v:stroke joinstyle="miter"/>
<v:formulas>
<v:f eqn="if lineDrawn pixelLineWidth 0"/>
<v:f eqn="sum @0 1 0"/>
<v:f eqn="sum 0 0 @1"/>
<v:f eqn="prod @2 1 2"/>
<v:f eqn="prod @3 21600 pixelWidth"/>
<v:f eqn="prod @3 21600 pixelHeight"/>
<v:f eqn="sum @0 0 1"/>
<v:f eqn="prod @6 1 2"/>
<v:f eqn="prod @7 21600 pixelWidth"/>
<v:f eqn="sum @8 21600 0"/>
<v:f eqn="prod @7 21600 pixelHeight"/>
<v:f eqn="sum @10 21600 0"/>
</v:formulas>
<v:path o:extrusionok="f" gradientshapeok="t" o:connecttype="rect"/>
<o:lock v:ext="edit" aspectratio="t"/>
</v:shapetype><v:shape id="Picture_x0020_4" o:spid="_x0000_i1025" type="#_x0000_t75"
style='width:300pt;height:237pt;visibility:visible;mso-wrap-style:square'>
<v:imagedata src="file:///C:\Users\443482\AppData\Local\Temp\msohtmlclip1\01\clip_image001.jpg"
o:title=""/>
</v:shape><![endif]--><!--[if !vml]--><!--[endif]--><o:p></o:p></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhWqPRsyt2SIq9MPD6TF5emzOckDABVafGBJ_4BSF6FZeyJllixCa0NqHTQcYfEIKWi8qrrimAFqm2VzL90TsQdSaH_46Fri1f9EbN97-27S8T_mEX7vqtOjpy7nRhSqKai9FCExxNcpYA/s1600/P2.jpg" imageanchor="1"><img border="0" data-original-height="403" data-original-width="510" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhWqPRsyt2SIq9MPD6TF5emzOckDABVafGBJ_4BSF6FZeyJllixCa0NqHTQcYfEIKWi8qrrimAFqm2VzL90TsQdSaH_46Fri1f9EbN97-27S8T_mEX7vqtOjpy7nRhSqKai9FCExxNcpYA/s1600/P2.jpg" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="MsoNormal">
<b>Leaning on TPS<o:p></o:p></b></div>
<div class="MsoNormal">
In my <u><a href="http://se-thoughtograph.blogspot.com/2018/06/the-lean-gelateria-part-1-lean-what-is.html" target="_blank">previous post</a></u>, I wrote little bit about the history of
Lean. Lean refers to a manufacturing
approach or a set of manufacturing practices developed by Toyota (1950s). It was known as TPS or Toyota Production
System. Lean or Lean Thinking is a
term introduced by the researchers at MIT.
All it meant was TPS or the Toyota way of meeting customer needs. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
TPS is the backbone or root of Toyota’s outstanding
performance, customer loyalty and brand value.
GM and Ford reported losses in 2006. Toyota reported a profit of 13 plus billion US dollars! In 2007, the
market capitalization of Toyota was higher than the combined market
capitalization of the three giants (GM, Ford, Daimler-Chrysler). Toyota remained innovative and introduced
hybrid vehicles. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<b>Could visitors lean?<o:p></o:p></b></div>
<div class="MsoNormal">
Not only MIT researchers but also thousands of senior
leaders from several corporates visited Toyota’s production lines in
Japan. They studied the practices and
returned home to implement them. Most of
them implemented all such practices but failed to demonstrate results! Meanwhile, Toyota replicated its practices
in United States and started manufacturing cars there! For them, Lean worked seamlessly.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
So, what is the crux and power of Lean Thinking or Toyota
way? In Toyota, for each employee there
are ample opportunities to find problems in one’s chain of activities or role,
solve them and make improvement. Toyota
employees are nurtured in identifying problems and living with the awareness
that they hold an opportunity to solve problems This enables them improve the way they do
their day-to-day work! On the other hand
the management is committed to investing in its people and promotes the culture
of continuous improvement.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<b>The goal</b></div>
<div class="MsoNormal">
The goal of lean is to deliver value, sustainably delivery
value and sustainably deliver value fast. Let me elaborate.The goal of
lean or lean thinking or any lean initiative is to deliver value as early as
possible in short intervals or short cycles in a timely manner with high
quality. You should not try to do this
by taking short cuts or making quick fixes thereby lowering the level of
quality or perform in unsustainable pace through unsafe practices. You should do this through undeterred focus
on continuous improvement.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<b>The scope<o:p></o:p></b></div>
<div class="MsoNormal">
Every team (from functions like Service Delivery, Marketing,
Sales, Recruitment, Operations, Training, etc.,) in organizations would be
second to none in saying that the goal is to sustainably deliver value fast at
short intervals! How do we move
towards this goal? Software project
teams do this by adopting agile methodologies.
Agile methodologies have been founded on some of the lean
principles. Some software teams adopt lean
practices such as Kanban. We will discuss more on this in my subsequent posts.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
So, what is the difference between lean and agile? One of the major differences is the scope of
implementation. Agile methodologies are implemented typically in software projects (after the contract is signed and
project is created). Lean can be
implemented end-to-end.What I mean here
is lean practices can be implemented from pre-sales stage to project or
services delivery and further. Does it
sound like ‘From pre-sales, services delivery, customer
satisfaction surveys, sustenance, to account mining’? Yes. That’s correct.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<b>Is this your
question?<o:p></o:p></b></div>
<div class="MsoNormal">
You know the goal and scope of lean thinking. You may ask, "So, is it true that Kanban boards, lean tools and waste reduction are the foundation
blocks of lean?"<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Brilliant question!
Let us wait and see the answer in my next post!<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<b>Let me ask you<o:p></o:p></b></div>
<div class="MsoNormal">
Before we part, I have some questions for you. </div>
<div class="MsoNormal">
<o:p></o:p></div>
<br />
<div class="MsoNormal">
Do you have adequate opportunities to identify problem,
issues, and challenges that are directly under your influence - in your project
or day-to-day work life? Do you solve
them and see improvement? Or are you too
busy identifying and digressing on problems that are not under your sphere of
influence?<o:p></o:p></div>
<div class="MsoNormal">
<br />
<br />
<div style="text-align: right;">
<b><u><a href="http://se-thoughtograph.blogspot.com/2018/06/the-lean-gelateria-part-3-foundation-of.html" target="_blank">The Lean Gelateria | Part 3 >>>>>>>>></a></u></b></div>
</div>
</div>
Raja Bavanihttp://www.blogger.com/profile/03107697584076683320noreply@blogger.com0tag:blogger.com,1999:blog-356516183452551110.post-16186924977476543342018-06-01T06:14:00.000-07:002018-06-06T06:59:35.585-07:00The Lean Gelateria | Part 1 | Lean? What is it?<div dir="ltr" style="text-align: left;" trbidi="on">
Last night while facebooking I was going through some of the Diwali
moments of my relatives and friends.
Loads of pictures and expressions - with the lamps, rangolis, crackers,
colorful dresses, sweets, and so on! Then I remembered my regular 30-minute early morning walks.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgpyG1v_GhxL8a1B7Rdpms55ch7_7slMecni0c11OfeLpLGcpqTi4ayqokU1UOddbDkrwDJr48kXwhKx9ydlqQGf-TWhax1v2KzmRV5V0UDErHNhNpN3ubs_NoxQ2lqZv6YGDtlfvEQp2g/s1600/FB.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img alt="" border="0" data-original-height="634" data-original-width="636" height="318" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgpyG1v_GhxL8a1B7Rdpms55ch7_7slMecni0c11OfeLpLGcpqTi4ayqokU1UOddbDkrwDJr48kXwhKx9ydlqQGf-TWhax1v2KzmRV5V0UDErHNhNpN3ubs_NoxQ2lqZv6YGDtlfvEQp2g/s320/FB.jpg" title="" width="320" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div style="text-align: center;">
<br /></div>
<div class="MsoNormal">
<o:p></o:p></div>
<div class="MsoNormal">
I notice something obvious during my morning walks right after festival days. Well, I see some new folks
on my way. Probably they start or renew their walking regime right after a
festival day. It happens! For example,
Diwali, the festival of lights, offers us a variety of high-calorie sweets that
one can’t resist and it seldom lets us succeed in our attempts to remain
light. We
are heath conscious. Some of us are reactive. And some are diligent.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Aren’t many of us on the same boat? Let me put forward a tingly
question in front of you! <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
“Do't we want to be lean and fit?”<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Who would say no? I
believe every one of us wants to be lean!<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Welcome you to the lean gelateria! How about a gelato, instead of the usual ice
cream?<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Gelato is made from natural ingredients. Gelato contains
vitamins, minerals, calcium and protein. So, it is nutritious. It has lower fat as compared to traditional
ice cream. It is fresh and tasty! No wonder gelato is liked by everyone from
small children to grandparents.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Gelato has started transforming the ice cream culture all
over the world including India. One can
spot a gelateria in every shopping mall, multiplexes and prime shopping areas
of all major cities in India. Just as bakery is for different types of breads
and cakes, gelateria is for several types of gelato, sorbet, etc. FYI – Sorbet is made of fresh fruit, sugar
and water. No milk or cream. I heard that it has 0% fat and of course, it suits
those who are lactose intolerant.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgX-NrwvcJxLW7RzapKjdKIUsFMM8PBY-2-jlHfNjM0E04m3ozODFlmHgIrIjolh2lsPOIc8GbB_JQswFK6yGn_O5cAiefdX9aXZXC-UAOM90GClkmkGz-70xd4g9n83fswSVRM52EluIk/s1600/dellemoline.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="400" data-original-width="500" height="256" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgX-NrwvcJxLW7RzapKjdKIUsFMM8PBY-2-jlHfNjM0E04m3ozODFlmHgIrIjolh2lsPOIc8GbB_JQswFK6yGn_O5cAiefdX9aXZXC-UAOM90GClkmkGz-70xd4g9n83fswSVRM52EluIk/s320/dellemoline.jpg" width="320" /></a></div>
<div class="MsoNormal" style="text-align: center;">
<br /></div>
<div class="MsoNormal">
I no longer witness the thrill among us on devouring
traditional cone ice cream from a roadside shop. A familiar brand of ice cream after dinner
is less than ordinary and one wouldn’t talk about such things with friends and
colleagues!<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
So, this lean gelateria is for all of you! I am planning to serve you unique flavors
every week.<o:p></o:p></div>
<div class="MsoNormal">
Nowadays everyone is health conscious. People of all ages
aspire to be active and fit.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Yes, everyone wants to be agile and lean! This includes us and our customers. Agile
methods and lean practices provide benefits. We know that.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Do we know the difference between agile and lean?<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Agile methodology is an umbrella term that refers to a set
of methods that are evolutionary, light-weight and empirical in nature. There are several agile methods such as FDD,
XP (Extreme Programming), Scrum, SAFe and DSDM (Dynamic and Systems Development
Method) in practice today. Some of these
(for example, FDD and XP) came into light even before agile manifesto and agile
principles were scripted and announced to the world.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
By 2000, the success of agile methods such as Extreme
Programming, and SCRUM inspired the industry.
During February 2001, 17 industry experts convened at ‘The Lodge’ at
Snowbird Ski Resort in the Wasatch mountains of Utah and defined ‘Agile
Manifesto’ and ‘Agile Principles’.
Gradually, the popularity of Agile grew across the globe. Agile gurus and practitioners organized
several conferences, workshops and events to evangelize and propagate agile
methodologies. Lean Software Development
and Kanban spiced up this evolution and got adopted as best practices in Agile
Methods.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
In summary, any agile method is a way of developing and
maintaining software and it adheres to agile manifesto and agile
principles. The core of agile is about
delivering working software to customers from the early days of projects at
short intervals or iterations (of every one to four weeks) in a sustainable
pace. Agile teams deliver business value by delivering what matters the most to
the customer in short iterations.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Exceedingly often, in IT industry we manage projects that
need to be executed in a time-bound manner within budget. In such projects, project sponsors and
stakeholders find it valuable to get adequate visibility and predictability at
regular intervals or iterations. Also, considering working software the true
measure of progress and delivering business value to business users at a
consistent pace in terms of high priority feature sets has become
quintessential. Iterative and incremental
development provides an opportunity to practice continuous improvement through
the feedback received iteration-end demos and retrospectives. This leads to the
fact that methodologies that ensure adequate visibility and predictability are
the most sought-after. Agile methods deliver this promise all the time. </div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<b>Lean?
What is it?<o:p></o:p></b></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Lean refers to a manufacturing approach or a set of
manufacturing practices developed by Toyota (1950s) and evangelized in the US
and other parts of the world in 1990s. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
The founders of agile manifesto and agile principles were
influenced by lean manufacturing. Lean
manufacturing and agile methods follow a similar philosophy.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Lean is not a methodology.
It is a set of practices. Some of
the practices of lean are very unique and may not be found in typical agile
projects. Hence it is worth exploring
this subject area.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
You may hear “Lean is about reducing waste!” Let us not settle down with this definition.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
I will meet you here next week, with the special flavor of
our gelateria!<br />
<br />
<div style="text-align: right;">
<b><u><a href="http://se-thoughtograph.blogspot.com/2018/06/lean-gelateria-part-2-lean-goal.html" target="_blank">The Lean Gelateria | Part 2 | >>>>>>></a></u></b></div>
</div>
<div class="MsoNormal">
<br /></div>
</div>
Raja Bavanihttp://www.blogger.com/profile/03107697584076683320noreply@blogger.com0tag:blogger.com,1999:blog-356516183452551110.post-87656089647326807242017-04-02T03:01:00.000-07:002017-04-02T03:01:16.302-07:00Agile Program Management: The Significance of Hardening Sprints<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: left; text-indent: -0.25in;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgMVJ6nnAOuhrVprsjVh-xYL80NEdG6b5DDJDkeApToJXVf5XnjkCeJcgBhuVGwtieKjYykxtaNzf1-j2qRM62ybtLm_POOzOqwFM1Z9yZdjO8TXWuaUQbQDYWCMRllGooxcuf80XdSx1U/s1600/Hardening.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="180" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgMVJ6nnAOuhrVprsjVh-xYL80NEdG6b5DDJDkeApToJXVf5XnjkCeJcgBhuVGwtieKjYykxtaNzf1-j2qRM62ybtLm_POOzOqwFM1Z9yZdjO8TXWuaUQbQDYWCMRllGooxcuf80XdSx1U/s320/Hardening.jpg" width="320" /></a></div>
<div style="text-align: left;">
<span style="text-indent: -0.25in;">This is my ninth post in “Agile Program Management”
series. </span><span style="text-indent: -0.25in;">Hardening Sprint is a familiar
term for most practitioners. However it is a frequently misunderstood term too.
Typically an iteration or Sprint that is at the end of all Sprints in a release
cycle is planned in such a way that team members focus on (and only on)
hardening activities. When this is true, we call it a hardening Sprint.</span></div>
<div style="text-align: left;">
<span style="text-indent: -0.25in;"><br /></span><span style="text-indent: -0.25in;">In one of my earlier posts I discussed about <a href="http://se-thoughtograph.blogspot.com/2015/05/scaling-agile-hardening-sprint-and_31.html" target="_blank">how procrastination makes Hardening Sprints harder</a>.</span><span style="text-indent: -0.25in;"> </span></div>
<div style="text-align: left;">
<span style="text-indent: -0.25in;">Agile Program Management is a complex function as it
involves program managing multiple related projects. Not understanding the
significance of hardening Sprints can lead to</span></div>
<div style="text-align: left;">
</div>
<ol style="text-align: left;">
<li>Incorrect decisions or expectations on accommodating
new features in hardening Sprints,</li>
<li>Delays in release timelines because of
unexpected issues in one or more applications or products in spite of (or due
to) hardening activities</li>
<li>Procrastination and last minute surprises that
indicate risks related to product or application quality</li>
</ol>
<br />
<div style="text-align: left;">
<span style="text-indent: -0.25in;">For this, those who are involved in Agile Program Management
function need to understand what constitutes a hardening Sprint. Also they must
establish a common understanding on what constitutes a hardening Sprint across
project teams. </span></div>
<div style="text-align: left;">
<span style="text-indent: -0.25in;"><br /></span></div>
<div style="text-align: left;">
<span style="text-indent: -0.25in;">For example, SAFe suggests HIP Sprints. HIP stands for
Hardening, Innovation and Planning. </span><span style="text-indent: -0.25in;"> </span></div>
<div style="text-align: left;">
<span style="text-indent: -0.25in;"><br /></span></div>
<div style="text-align: left;">
<span style="text-indent: -0.25in;">Hardening Sprints are to stabilize code or to meet release level
‘Definition of Done’.</span><span style="text-indent: -0.25in;"><br /></span></div>
<div style="text-align: left;">
<span style="text-indent: -0.25in;">Hardening Sprints are not to be seen as an opportunity to ‘relax’
or ‘dilute’ the ‘Definition of Done’ at user story level or Sprint level in all
previous Sprints with a misunderstanding that all those can be accumulated as
technical debt and paid off during Hardening Sprints. When this happens we miss
the essence of Agile.</span><span style="text-indent: -0.25in;"> </span><span style="text-indent: -0.25in;">This approach
defies demos or reviews and retrospectives.</span><span style="text-indent: -0.25in;">
</span><span style="text-indent: -0.25in;">This does not lead to delivering 'potentially shippable' increments or user stories at
the end of Sprints.</span></div>
<div style="text-align: left;">
<span style="text-indent: -0.25in;"><br /></span><span style="text-indent: -0.25in;">Also, feature implementation or enhancements (new user
stories) are not part of hardening Sprints.</span><span style="text-indent: -0.25in;">When Agile Program Management teams understand these, they develop
the capabilities to ask powerful questions when they look at release plans or when
they govern the progress of Sprints.</span><span style="text-indent: -0.25in;">
</span><span style="text-indent: -0.25in;">Besides, when things go wrong during Hardening Sprints, they do have
enough awareness to deal with the situation and demonstrate their value to
teams.</span><span style="text-indent: -0.25in;"><br /></span></div>
<div style="text-align: left;">
<span style="text-indent: -0.25in;">Hardening Sprints do not add much to the overall
productivity or velocity of the team in terms of their ability to deliver new
features. In other words, the quantum of efforts spent in Hardening Sprints do
not add new features and corresponding Story Points to an upcoming release. Hardening
Sprints improve the stability and maintainability of releases, and ensure that
that code base is good to launch a release.</span></div>
<div style="text-align: left;">
<span style="text-indent: -0.25in;"><br /></span><span style="text-indent: -0.25in;">To conclude, let me put forward some questions. When you
review a release plan and find that there is no hardening Sprint, what are you
going to do about it?</span><span style="text-indent: -0.25in;"> </span><span style="text-indent: -0.25in;">Also, when an
hardening Sprint is approaching in your release road map, what kind of questions
will you ask to figure out if your teams are moving in the right
direction?</span><span style="text-indent: -0.25in;"> </span><span style="text-indent: -0.25in;">When there is business
pressure to accommodate all product backlog items very tightly into multiple
Sprints and deliver releases, how will you negotiate to budget for a hardening
Sprint per release?</span><span style="text-indent: -0.25in;"> </span></div>
<br />
<div class="MsoNormal">
<o:p></o:p></div>
<div class="MsoNormal">
<o:p></o:p></div>
<div class="MsoNormal">
<o:p></o:p></div>
<div class="MsoNormal">
<o:p></o:p></div>
<div class="MsoListParagraphCxSpFirst" style="mso-list: l0 level1 lfo1; text-indent: -.25in;">
<o:p></o:p></div>
<div class="MsoListParagraphCxSpMiddle" style="mso-list: l0 level1 lfo1; text-indent: -.25in;">
<o:p></o:p></div>
<div class="MsoListParagraphCxSpLast" style="mso-list: l0 level1 lfo1; text-indent: -.25in;">
<o:p></o:p></div>
<div class="MsoNormal">
<o:p></o:p></div>
<div class="MsoNormal">
<o:p></o:p></div>
<div class="MsoNormal">
<o:p></o:p></div>
<div class="MsoNormal">
<o:p></o:p></div>
<div class="MsoNormal">
<o:p></o:p></div>
<div class="MsoNormal">
<o:p></o:p></div>
<div class="MsoNormal">
<o:p></o:p></div>
<div class="MsoNormal">
<o:p></o:p></div>
</div>
Raja Bavanihttp://www.blogger.com/profile/03107697584076683320noreply@blogger.com0tag:blogger.com,1999:blog-356516183452551110.post-18567480161421441462017-02-03T20:43:00.001-08:002017-02-03T20:47:24.075-08:00Agile Program Management: Dependency and Risk Management<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh5XK0qMgW9_0Q9VFpN3sYeTf9VFi2ll1aoISWar-1CJeF78s8WDYfH9wBCwyGYoknxpbFUY8KgUShRmfJRZGLC1b1Cff0TkNvmAix1qLi-p0Emr9tAKq_DNtHh_0P4FLieirUfbMKxmOk/s1600/RnD.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="179" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh5XK0qMgW9_0Q9VFpN3sYeTf9VFi2ll1aoISWar-1CJeF78s8WDYfH9wBCwyGYoknxpbFUY8KgUShRmfJRZGLC1b1Cff0TkNvmAix1qLi-p0Emr9tAKq_DNtHh_0P4FLieirUfbMKxmOk/s320/RnD.jpg" width="320" /></a></div>
<div class="MsoNormal" style="text-align: center;">
<br /></div>
<div style="text-align: left;">
From Agile Program Management perspective how do you manage
dependencies and risks? Do you identify
what is under your control and manage those alone? Do you assume risks – do you
assume that risks will be taken care of by those who have full control on the
risks? Or do you consider those as part of your action plan? This is what I
plan to discuss in this post.</div>
<div style="text-align: left;">
<br />
There are ways to identify and handle dependencies in
projects. I had discussed this in <a href="http://se-thoughtograph.blogspot.in/2013/12/how-do-you-manage-dependencies-in-agile.html" target="_blank">one of my previous posts</a>. Also, agile methods have inbuilt mechanisms
to manage dependencies and risks such as Release Planning, Sprint Planning,
Scrum-of-Scrums, Agile Governance etc.,- provided these mechanisms operate in
an orchestrated manner. Does it happen
on the ground across all projects and situations? Well, it depends! In the name of ‘Inspect and Adapt’ some Agile
teams succumb to the ill effects of poorly managed dependencies and risks. And
of course, they retrospect, learn and improve. Or they fall in to the same
traps again and again.</div>
<div style="text-align: left;">
<br />
When it comes to Agile Program Management that involves
multiple interrelated projects, the dimension of dependency and risk management
becomes even more critical. In one of the programs I was part of we had a good
grip on internal dependencies and risks. Those were the elements on which we
had full influence or control to steer them in the right direction or implement
mitigation plans to reduce the overall impact. However, we had external
dependencies and risks too. Those were the elements on which we had either
partial or no control to steer them in the right direction. One of them was about a dependency on a third
party products. These products were evolving and the corresponding vendors had
announced dates for the next releases.
The products got released and as you may guess they were not stable
enough because of defects and performance issues. The host of applications that
we were building were being built on one or more of these products. Now you can
guess the impact!</div>
<div style="text-align: left;">
<br />
We had multiple releases to go and more or less all these
releases had dependency on the enhancements and upgrades of these third party
products – these products had a release road-map with multiple releases too. If
we assume that everything will go according to the release road-map, it is a
risk. If we become paranoid it is unhealthy and risky again. Collaboration and
continuous planning is what helps in such situations.</div>
<div style="text-align: left;">
<br />
Classical program managers resort to assuming certain entry
and exit criteria. For example, ‘Let us assume that the 3.1.2 release of the
product from our third party vendor will be ready on 10/23.’ Is that a good assumption? Or is that
assumption itself is a risk? Or should the assumption be collaboratively vetted
or validated at regular intervals? Who
is responsible for this? Agile Program
Management is. This is because, individual project teams are busy moving from
one iteration to the other. Scrum of Scrums happen in large projects. Project
teams sometimes become too busy to pursue these. Either implicitly or
explicitly they call it out or call for support. Coach them to make it explicit
so that the program management team is aware. That is what I would recommend.
And make it explicit at all appropriate levels and own it as part of Agile
Program Management. This is true for all
kinds of dependencies and risks – both internal and external. Program Management team needs to be at the
eye of the storm in such situations and have a clear focus on how to manage
situations. Else, they become an extended arm of project teams and remain
equally clueless. They lose focus and become inadequate to arrive at optimal
solutions or pragmatic decisions.</div>
<div style="text-align: left;">
<br />
It is about seeing the forest but not losing sight on
trees!<br />
</div>
<div class="MsoNormal">
<o:p></o:p></div>
<div class="MsoNormal">
<o:p></o:p></div>
<div class="MsoNormal">
<o:p></o:p></div>
<div class="MsoNormal">
<o:p></o:p></div>
<div class="MsoNormal">
<o:p></o:p></div>
<div class="MsoNormal">
<o:p></o:p></div>
</div>
Raja Bavanihttp://www.blogger.com/profile/03107697584076683320noreply@blogger.com0tag:blogger.com,1999:blog-356516183452551110.post-41936633671692720422016-12-04T06:32:00.000-08:002016-12-04T06:32:44.067-08:00Agile Program Management: Awareness Building and Knowledge Management<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: left;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhnzgE8qbGP6gZsmprXUFx03al0EAWYdZaY2NDLj72xXE12WbLglEm8VGpnxOFB60Ufs6e8iR7r_LR2z0nxtNbPrF2sbqKoQ5IWUfvJ5gkJiU8D4wDXb2k35nwHQ-Q_IztVe6sS29P5ajo/s1600/ABKM.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="181" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhnzgE8qbGP6gZsmprXUFx03al0EAWYdZaY2NDLj72xXE12WbLglEm8VGpnxOFB60Ufs6e8iR7r_LR2z0nxtNbPrF2sbqKoQ5IWUfvJ5gkJiU8D4wDXb2k35nwHQ-Q_IztVe6sS29P5ajo/s320/ABKM.JPG" width="320" /></a></div>
<div style="text-align: center;">
<br /></div>
<span style="font-size: 10.0pt; line-height: 115%;"><div style="text-align: justify;">
<span style="font-size: 10pt;">What is the
role of Agile Program Management function in these two areas – ‘Awareness
Building and Knowledge Management’?
</span><span style="font-size: 10pt;">These two areas go beyond generic training on new joiner induction or on-boarding.
I am writing this post to explain how these two areas go beyond the normal on-boarding
or induction process and why those two are important drivers in Agile Program
Management.</span></div>
</span><br />
<div style="text-align: left;">
<span style="font-size: 10.0pt; line-height: 115%;"></span></div>
<div style="text-align: justify;">
<span style="font-size: 10pt;">Typically we
get trained or certified team members to form cross-functional teams or we
induct skilled team members and put them through appropriate additional training
and/or certification programs. Once this happens, team members get into main
stream iterative/incremental delivery. Teams that are self-enabled and
high-performing experience perpetual learning that happens all the time. In
small projects that involve one or two such teams, awareness building and
knowledge management are intrinsic. Those who have been through this or those
who imagine standalone or small teams may even wonder why someone would even
worry about these two areas!</span><span style="font-size: 10pt;"> </span><span style="font-size: 10pt;">This is
because Agile is about team learning and continuous improvement.</span></div>
<br />
<div style="text-align: left;">
<span style="font-size: 10.0pt; line-height: 115%;"></span></div>
<div style="text-align: justify;">
<span style="font-size: 10pt;">Well. That
happens. That happens in small projects – projects that involve one or two or
three cross-functional teams.</span><span style="font-size: 10pt;"> </span><span style="font-size: 10pt;">How about
large projects or programs? – for example, programs that involve multiple
hundreds of team members – 400 to 1000 team members with 40 to 100
cross-functional teams that are geographically distributed?</span></div>
<br />
<div style="text-align: left;">
<span style="font-size: 10.0pt; line-height: 115%;"></span></div>
<div style="text-align: justify;">
<span style="font-size: 10pt;">I am sure
you got the context.</span><span style="font-size: 10pt;"> </span><span style="font-size: 10pt;">In most cases Agile
Program Management involves complexity in terms of team size, variety of
projects, geographical distribution and so on. This is when Agile Program
Managers cannot afford to ignore ‘Awareness Building and Knowledge Management’.</span></div>
<br />
<div style="text-align: left;">
<span style="font-size: 10.0pt; line-height: 115%;"></span></div>
<div style="text-align: justify;">
<span style="font-size: 10pt;">Awareness Building
and Knowledge Management are continuous activities. There have to be multiple
mechanisms to promote or implement these two areas. There can be mechanism such
as visual posters, lightening talks, regular or periodic sessions that involve
topics related to technologies, domain concepts, and so on. </span><span style="font-size: 10pt;"> </span><span style="font-size: 10pt;">Gamification is worth considering in large teams
to ensure continuous awareness building and knowledge management.</span></div>
<br />
<div style="text-align: left;">
<span style="font-size: 10.0pt; line-height: 115%;"></span></div>
<div style="text-align: justify;">
<span style="font-size: 10pt;">Unlike small
projects that involve one or two cross-functional teams that last for about
nine to twelve months, large programs involve tens or hundreds of
cross-functional teams and last for multiple years.</span><span style="font-size: 10pt;"> </span><span style="font-size: 10pt;">Continuous focus on awareness building and
knowledge management becomes a necessity to sustainable rigor in
execution.</span><span style="font-size: 10pt;"> </span><span style="font-size: 10pt;">Remember, a 10 percent attrition
in program of 500 team members is nothing but 50 people moving out and moving
in year on year. </span><span style="font-size: 10pt;"> </span><span style="font-size: 10pt;">When there is a churn
of this magnitude or higher, on-boarding or induction may become individual
based but not team based because you don’t get to induct a team or train a
group of individuals all the time. With consistent pressure on sustaining
velocity trends or meeting release timelines, the focus on delivering would supersede
everything else. This is where a continuous focus on awareness building and knowledge
management can strengthen the ecosystem.</span></div>
<br />
<div style="text-align: left;">
<span style="font-size: 10.0pt; line-height: 115%;"></span></div>
<div style="text-align: justify;">
<span style="font-size: 10pt;">How can we
going about this? Form a team of motivated individuals who want to contribute
to this area. Focus on a) creating an infrastructure that radiates knowledge
and improves awareness – these can be posters, email flyers, knowledge management
portal, etc. b) budgeting time for periodic knowledge sharing sessions facilitated
by team members for team members, c) involving geographically distributed teams by
sharing content or inviting them to participate.</span><span style="font-size: 10pt;"> Also,</span><span style="font-size: 10pt;"> include these in your program management radar or dashboard.</span><span style="font-size: 10pt;"> Do you have any </span><span style="font-size: 10pt;">additional ideas? Please share.</span></div>
<br />
<div style="text-align: left;">
<span style="font-size: 10.0pt; line-height: 115%;"></span></div>
<div style="text-align: justify;">
<span style="font-size: 10pt;">Have you
seen a new project team in your program repeating the same mistakes that one of
the mature teams came across couple of years ago?</span><span style="font-size: 10pt;"> </span><span style="font-size: 10pt;">Have you seen the same types of issues and
conflicts happening in new teams year after year? Have you seen a newly
inducted developer doing a wrong bug-fix most probably the same way someone did
years ago and learned a better way through experience? If yes, I am sure you
will understand how these incidents can be better understood and handled, and minimized - if applicable, through consistent focus on awareness building and knowledge sharing sessions.
Also, I am sure you don’t assume that the initial induction program or training
or certification can do the magic to stop these!</span></div>
<br />
<div style="text-align: left;">
<span style="font-size: 10.0pt; line-height: 115%;"></span></div>
<div style="text-align: justify;">
<span style="font-size: 10pt;">Tell me now. Don’t Agile Program Managers need to keep track of these two areas or have them represented
in some form (probably through a measure or metric) on their program management dashboard?</span></div>
<br />
</div>
Raja Bavanihttp://www.blogger.com/profile/03107697584076683320noreply@blogger.com1tag:blogger.com,1999:blog-356516183452551110.post-24479141782096052432016-11-18T23:40:00.002-08:002016-11-18T23:40:55.791-08:00Agile Program Management: Metrics and Dashboards<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: left; text-indent: -0.25in;">
</div>
<div style="text-align: center;">
<span style="text-indent: -0.25in;"> <div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgdu9U14cHy38OhXmaxe3sTQ1qSGSBESB_w73MNNTwsUDhq2upaEkGTUTepL3x_xMMSRHt5gfHZ9RiVIyypnLcQZoc1nLH4qzSUttxTGfQ3D4EGLgwDJnX8Nom_suIgekGmHoypomC7mxk/s1600/Metrics.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="184" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgdu9U14cHy38OhXmaxe3sTQ1qSGSBESB_w73MNNTwsUDhq2upaEkGTUTepL3x_xMMSRHt5gfHZ9RiVIyypnLcQZoc1nLH4qzSUttxTGfQ3D4EGLgwDJnX8Nom_suIgekGmHoypomC7mxk/s320/Metrics.jpg" width="320" /></a></div>
</span></div>
<br />
<div style="text-align: left; text-indent: -0.25in;">
From Agile Program Management perspective what metrics do
you consider and how do you assemble them on a dashboard for periodic
monitoring? I am writing this post to share a set of ten essential
considerations on this topic.<br /><span style="text-indent: -0.25in;"><br /></span></div>
<div style="text-align: left; text-indent: -0.25in;">
</div>
<ol style="text-align: left;">
<li>Set program level goals in such a way that the
goals are measurable (SMART goals). Make sure that there are two to three
important goals and focus on achieving them.<span style="text-indent: -0.25in;">
</span><span style="text-indent: -0.25in;">As and when you accomplish a goal, you can add one more goal to this
list.</span><span style="text-indent: -0.25in;"> </span><span style="text-indent: -0.25in;">Align your dashboard to include a
comprehensive list of parameters or metrics related to these goals.</span></li>
<li><span style="text-indent: -0.25in;">Besides, show project level metrics that require
attention at program level. If your
program consists of projects of different categories (software development,
software maintenance, test automation, etc.), create a multiple views to show
the state of these categories at a high-level.
These need not be exactly the status report or dashboard you show at project
level.</span></li>
<li>Make sure that your dashboard is simple, visible
and accessible to all stakeholders. You
cannot wait to see the dashboard of your car only whenever you stop for a
refreshment break! You need to see it all the time. Design a dashboard in such a way that it is
visible, and accessible at regular intervals – A dashboard that gets updated
daily can add more value to your program as compared to one that gets updated
once or twice a month.</li>
<li>Include both lag and lead measures. Velocity is a lag measure. You can measure it
at the end of Sprints but you cannot control it in a Sprint that passed by. Identify
lead measures related to Velocity. These are the measure or factors that impact
Velocity. Make sure that your team spend lots of energy on improving these lead
measures so that the corresponding lag measure can improve. Lead measures give
life to your dashboard. Ignoring lead measures and focusing or showing only lag
measures has very limited use or no use at all. What are your project level
lead measures? What are your program level lead measures? Find answers.</li>
<li>Include the right metrics. Is Velocity alone a good enough measure?
Don’t we need ‘Cycle Time’? Or ‘Backlog Stability’? Or ‘# User Stories deployed
in production environment’?</li>
<li>Your dashboard is not a static entity. What you
include in your dashboard can change from program to program. Also, it can change from one stage to the
other in the same program. By ‘stage’ I mean a definite period during which the
overall characteristics of a program remain the same. For example, when you begin an Agile Program,
‘Product Owner Readiness’ can be an essential parameter to include in your
dashboard because this is a leading measure to improve Velocity and Cycle
Time. Also, it is something that needs
to be known to all stakeholders including your senior management to obtain
necessary help or support in a timely manner when you are running with a very
low value on this parameter.</li>
<li>The dashboard you design and implement needs to
tell you whether the whole program is moving towards success or failure. This is not simply the Red-Green-Amber
status. This is about providing a view that shows all success critical
parameters or metrics and relating them with a key message to demonstrate or
authentically illustrate whether the program is winning or losing.</li>
<li>Practice reuse.
Attempt to reuse components across dashboards at different levels
(project, program, engagement, etc.)
This will optimize efforts and ensure the same level of truth across
dashboards.</li>
<li>Have a good mix of quantitative as well as qualitative
information to reflect what is needed, what next, and whether action is
happening on the ground or not.</li>
<li>Do not attempt to create a ‘perfect’ dashboard
to begin with. Start with a minimalist
dashboard and add more to it gradually. Practice continuous improvement! A dashboard is perfect not when you don’t have
anything else to add but when you don’t have anything else to remove from it!</li>
</ol>
<div>
<br /></div>
Do you have anything add? <div class="MsoNormal">
<o:p></o:p></div>
<div class="MsoListParagraphCxSpFirst" style="mso-list: l0 level1 lfo1; text-indent: -.25in;">
<o:p></o:p></div>
<div class="MsoListParagraphCxSpMiddle" style="mso-list: l0 level1 lfo1; text-indent: -.25in;">
<o:p></o:p></div>
<div class="MsoListParagraphCxSpMiddle" style="mso-list: l0 level1 lfo1; text-indent: -.25in;">
<o:p></o:p></div>
<div class="MsoListParagraphCxSpMiddle" style="mso-list: l0 level1 lfo1; text-indent: -.25in;">
<o:p></o:p></div>
<div class="MsoListParagraphCxSpMiddle" style="mso-list: l0 level1 lfo1; text-indent: -.25in;">
<o:p></o:p></div>
<div class="MsoListParagraphCxSpMiddle" style="mso-list: l0 level1 lfo1; text-indent: -.25in;">
<o:p></o:p></div>
<div class="MsoListParagraphCxSpMiddle" style="mso-list: l0 level1 lfo1; text-indent: -.25in;">
<o:p></o:p></div>
<div class="MsoListParagraphCxSpMiddle" style="mso-list: l0 level1 lfo1; text-indent: -.25in;">
<o:p></o:p></div>
<div class="MsoListParagraphCxSpMiddle" style="mso-list: l0 level1 lfo1; text-indent: -.25in;">
<o:p></o:p></div>
<div class="MsoListParagraphCxSpMiddle" style="mso-list: l0 level1 lfo1; text-indent: -.25in;">
<o:p></o:p></div>
<br />
<div class="MsoNormal">
<o:p></o:p></div>
</div>
Raja Bavanihttp://www.blogger.com/profile/03107697584076683320noreply@blogger.com0tag:blogger.com,1999:blog-356516183452551110.post-19476927314000732102016-05-21T19:30:00.002-07:002016-05-26T01:35:27.051-07:00Agile Program Management: Engaging with Stakeholders<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjzu92NU2ks1Nf2reXz3XnGEaHNBPk0MPVdeRRqOVAglnJajXXSaPaI6kTycvTDyP1w06i0nlv6i2CDRZFaBLfBxPPy1n1Pu9vW6hkP6FpvCUUMGPBQF8yjChUJWk-3PQOO0YiPLz7BeU8/s1600/ProgMgmt5.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="222" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjzu92NU2ks1Nf2reXz3XnGEaHNBPk0MPVdeRRqOVAglnJajXXSaPaI6kTycvTDyP1w06i0nlv6i2CDRZFaBLfBxPPy1n1Pu9vW6hkP6FpvCUUMGPBQF8yjChUJWk-3PQOO0YiPLz7BeU8/s400/ProgMgmt5.jpg" width="400" /></a></div>
<div style="text-align: left; text-indent: -0.25in;">
<br /></div>
<div style="text-align: left; text-indent: -0.25in;">
<br />
<span style="font-family: inherit;">Stakeholder management is an essential but challenging area
in Agile Program Management. Engaging
with stakeholders is as important as team collaboration without which it is
practically impossible to see tangible results when we manage multiple projects
under a program. I am writing this blog to put forward some key aspects related
to engaging with stakeholders.</span></div>
<div style="text-align: left; text-indent: -0.25in;">
<span style="font-family: inherit;"><br />What makes stakeholder management a complex thing in Agile
Program Management? One key reasons is
that stakeholder management in Agile is a combination of several aspects. When we understand those aspects, we get
enough clarity during our attempts to engage with stakeholders. In my opinion,
these aspects include</span></div>
<div style="text-align: left; text-indent: -0.25in;">
<span style="font-family: inherit;"><br />1)<span style="font-size: 7pt; font-stretch: normal;">
</span><!--[endif]-->Agile awareness and learning agility of
stakeholders<br />2)<span style="font-size: 7pt; font-stretch: normal;">
</span><!--[endif]-->Change agility of stakeholders to adopt the new
way of working<br />3)<span style="font-size: 7pt; font-stretch: normal;">
</span><!--[endif]-->Stakeholder KRAs, Expectations and expectation
management<br />4)<span style="font-size: 7pt; font-stretch: normal;">
</span><!--[endif]-->Persona and leadership style of stakeholders</span></div>
<div style="text-align: left; text-indent: -0.25in;">
<span style="font-family: inherit;"><br /></span></div>
<div style="text-align: left; text-indent: -0.25in;">
<span style="font-family: inherit;"> These are eye openers that make us understand that
stakeholder management in Agile Program Management is unique and different –
and most of the times it is a big deal.
It is not about staying in touch with stakeholders in formal and
informal ways and keeping them aware of the respective projects or the entire
program. This is about enabling them and
making them understand the new way of working – short and sustainable
iterations to delivery working software, continuous collaboration, feedback
loops, team learning, continuous improvement, and so on. It is about hand holding them to adopt the new
way of working. It is about the ability
to understand, negotiate and manage their expectations. It is about doing all
these with a good understanding of their persona and leadership styles and
gradually helping them understand the power of Servant Leadership.</span></div>
<div style="text-align: left; text-indent: -0.25in;">
<span style="font-family: inherit;"><br />“My project follows traditional lifecycle in a phased
manner. It has been twelve months since
we started. There has been a huge delay. Phase 1 and 2 must have been delivered
by now. We did not meet the goals of Phase 1 on time. Phase 1 was about to get delayed
by two months. We diluted the goals and ended Phase 1 with a delay of one
months. Phase 2 started but the project is on fire because of several issues. We want to transform this project into
Agile. The original planned delivery
date is about eighteen months from now.
Will Agile help us move faster, become aggressive and delivery on time?”
This is what one of my stakeholders
asked me years ago. He wanted me to take this troubled project, transform it
into Agile and deliver. I am sure you
have come across situations like this.</span></div>
<div style="text-align: left; text-indent: -0.25in;">
<span style="font-family: inherit;"><br />In situations like these, where do we start? How do we
proceed to handle such situations? In
addition to deep analysis, training, team building, coaching etc. one of the
key factors that plays an important role here is Stakeholder Management aligned with agile values and principles. </span></div>
<div style="text-align: left; text-indent: -0.25in;">
<span style="font-family: inherit;"><br />When we are into Agile project or program execution, we come
across questions from our stakeholders. These questions relate to one or more
of the key aspects we discussed earlier. Let me give you some examples.</span></div>
<div style="text-align: left; text-indent: -0.25in;">
<span style="font-family: inherit;"><br />1)<span style="font-size: 7pt; font-stretch: normal;">
</span><!--[endif]-->Why can’t we cut down on travel and use only
video conferencing for the entire project?<br />2)<span style="font-size: 7pt; font-stretch: normal;">
</span><!--[endif]-->Why do we need more than one video conferencing
room?<br />3)<span style="font-size: 7pt; font-stretch: normal;">
</span><!--[endif]-->How can we see a 30% increase in productivity
over the first year in our program?<br />4)<span style="font-size: 7pt; font-stretch: normal;">
</span><!--[endif]-->Why aren’t we following best practices such as
Earned Value Analysis?<br />5)<span style="font-size: 7pt; font-stretch: normal;">
</span><!--[endif]-->Whether we call it Agile or not, how can we
deliver the whole thing in three months?<br />6)<span style="font-size: 7pt; font-stretch: normal;">
</span><!--[endif]-->How about considering industry benchmarks or
organizational baselines in our project or using Function Point estimation?
What can we do to standardize across board?</span></div>
<div style="text-align: left; text-indent: -0.25in;">
<span style="font-family: inherit;"><br />In order to deal with such questions, we need to understand the learning
agility and change agility of stakeholders and their ability to adopt to the
new way of working. We need to
understand their KRAs and expectations. We need to negotiate and make sure that
the expectations are realistic and suit the new way of working. This will require some changes in leadership
styles as well.</span></div>
<div style="text-align: left; text-indent: -0.25in;">
<span style="font-family: inherit;"><br />How do you engage with stakeholders? How do you align them
with the new way of working? What are your top challenges?<br /><o:p> </o:p></span></div>
<div class="MsoNormal">
<o:p></o:p></div>
<div class="MsoNormal">
<o:p></o:p></div>
<div class="MsoListParagraphCxSpFirst" style="mso-list: l1 level1 lfo1; text-indent: -.25in;">
<o:p></o:p></div>
<div class="MsoListParagraphCxSpMiddle" style="mso-list: l1 level1 lfo1; text-indent: -.25in;">
<o:p></o:p></div>
<div class="MsoListParagraphCxSpMiddle" style="mso-list: l1 level1 lfo1; text-indent: -.25in;">
<o:p></o:p></div>
<div class="MsoListParagraphCxSpLast" style="mso-list: l1 level1 lfo1; text-indent: -.25in;">
<o:p></o:p></div>
<div class="MsoNormal">
<o:p></o:p></div>
<div class="MsoNormal">
<o:p></o:p></div>
<div class="MsoNormal">
<o:p></o:p></div>
<div class="MsoNormal">
<o:p></o:p></div>
<div class="MsoListParagraphCxSpFirst" style="mso-list: l0 level1 lfo2; text-indent: -.25in;">
<o:p></o:p></div>
<div class="MsoListParagraphCxSpMiddle" style="mso-list: l0 level1 lfo2; text-indent: -.25in;">
<o:p></o:p></div>
<div class="MsoListParagraphCxSpMiddle" style="mso-list: l0 level1 lfo2; text-indent: -.25in;">
<o:p></o:p></div>
<div class="MsoListParagraphCxSpMiddle" style="mso-list: l0 level1 lfo2; text-indent: -.25in;">
<o:p></o:p></div>
<div class="MsoListParagraphCxSpMiddle" style="mso-list: l0 level1 lfo2; text-indent: -.25in;">
<o:p></o:p></div>
<div class="MsoListParagraphCxSpLast" style="mso-list: l0 level1 lfo2; text-indent: -.25in;">
<o:p></o:p></div>
<div class="MsoNormal">
<o:p></o:p></div>
<div class="MsoNormal">
<o:p></o:p></div>
</div>
Raja Bavanihttp://www.blogger.com/profile/03107697584076683320noreply@blogger.com0tag:blogger.com,1999:blog-356516183452551110.post-29796201955437357382016-02-21T03:34:00.002-08:002016-02-25T04:46:32.410-08:00Agile Program Management: Independent Verification Teams<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjSb1ukjYpmA8OSlEjDgXF2VXvhLu15CKU0He4ZZJBdCHN7kAD7XvCvRQqbqH0HPk7t2N0IMwqYpQIIytKVSDSwBMUeyOBdJuJ0ZtkLTB0rzdd21n_JZFg04G7Aj4lhm8jM728C1yNTDt0/s1600/ProgMgmt4.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="181" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjSb1ukjYpmA8OSlEjDgXF2VXvhLu15CKU0He4ZZJBdCHN7kAD7XvCvRQqbqH0HPk7t2N0IMwqYpQIIytKVSDSwBMUeyOBdJuJ0ZtkLTB0rzdd21n_JZFg04G7Aj4lhm8jM728C1yNTDt0/s320/ProgMgmt4.jpg" width="320" /></a></div>
<div class="MsoNormal" style="margin: 0in 0in 10pt; text-align: left;">
How do Independent Verification Teams (IVT) relate to Agile
Program Management? Should Program Managers consider IVT as yet another team
and limit their responsibilities to focusing on traditional program management
activities or do something different such as understanding the purpose of IVTs,
key issues, and related metrics?<span style="mso-spacerun: yes;"> </span>Let us
find answers to these questions in this post.</div>
<div class="MsoNormal" style="margin: 0in 0in 10pt; text-align: left;">
Independent Verification Teams? What? Agile teams are
cross-functional. Agile teams deliver tested software. Why do we need IVT? <span style="mso-spacerun: yes;"> </span>Are we crazy? Are we going back to erstwhile
non-Agile methodologies? Are these your questions?</div>
<div class="MsoNormal" style="margin: 0in 0in 10pt; text-align: left;">
Good questions! <span style="mso-spacerun: yes;"> </span>When
we run large projects consisting of multiple cross-functional teams, we do need
IVTs – at least one or two IVTs.<span style="mso-spacerun: yes;">
</span>Typically, an IVT is a team of 7 to 10 with one leader and team members.
Obviously all of them are experts in testing and test automation.<span style="mso-spacerun: yes;"> </span>In an ecosystem like this, each
cross-functional team would deliver working software.<span style="mso-spacerun: yes;"> </span>When we create an integrated build of
software delivered by multiple cross-functional teams, don’t we need a team to
test the integrated build? Yes.<span style="mso-spacerun: yes;"> </span>Of
course, Yes.<span style="mso-spacerun: yes;"> </span>We need Independent
Verification Teams for this.<span style="mso-spacerun: yes;"> </span>When we
program manage multiple related projects, yes, we will need Independent
Verification Teams.</div>
<div class="MsoNormal" style="margin: 0in 0in 10pt; text-align: left;">
The number of IVTs would depend on the size of the project or program.<span style="mso-spacerun: yes;"> </span>When we see from Agile Program Management perspective, it is important that program managers know</div>
<ul style="text-align: left;">
<li><div class="MsoNormal" style="margin: 0in 0in 10pt; text-align: left;">
The purpose or goal of cross-functional teams and IVTs</div>
</li>
<li><div class="MsoNormal" style="margin: 0in 0in 10pt; text-align: left;">
The team size, composition, and distribution of team members in IVT</div>
</li>
<li><div class="MsoNormal" style="margin: 0in 0in 10pt; text-align: left;">
<!--[endif]-->The tools they use</div>
</li>
<li><div class="MsoNormal" style="margin: 0in 0in 10pt; text-align: left;">
<!--[endif]-->The right approach to measure their progress -<span style="mso-spacerun: yes;"> IVTs</span> are not going to produce working software but they need to have tangible deliverables with ‘Definition of Done’</div>
</li>
<li><div class="MsoNormal" style="margin: 0in 0in 10pt; text-align: left;">
<!--[endif]-->What can go wrong with IVTs</div>
</li>
<li><div class="MsoNormal" style="margin: 0in 0in 10pt; text-align: left;">
<!--[endif]-->Ways to maximize the benefits of IVT</div>
</li>
</ul>
<div class="MsoNormal" style="margin: 0in 0in 10pt; text-align: left;">
Yes. With IVT in place, cross-functional teams can’t
renounce their responsibility of unit testing and let IVTs find and report unit
level defects. Also, they can’t burden IVTs because of their attempt to deliver
as many user stories in every iteration. I mean, cross-functional team can’t
attempt to deliver extra user stories by cutting short on unit test automation
and/or perform selective unit testing.</div>
<div class="MsoNormal" style="margin: 0in 0in 10pt; text-align: left;">
When IVTs spend time in finding and reporting unit level
defects, IVTs may not get sufficient time to perform their role effectively and
end up accumulating technical debt.<span style="mso-spacerun: yes;"> </span>This
can happen because of lack of or delay in test automation.<span style="mso-spacerun: yes;"> </span>This can happen because of ineffective tool
usage – for example, lack of traceability of test cases or scripts to
corresponding user stories. Sounds familiar?</div>
<div class="MsoNormal" style="margin: 0in 0in 10pt; text-align: left;">
Also, delays in tool identification or any decision to
change tools late in the game is not going to enable IVTs in accomplishing
their goals.<span style="mso-spacerun: yes;"> </span>Tool identification,
adequate training and effective tool usage are very important for the team to
focus on the product or applications under development.</div>
<div class="MsoNormal" style="margin: 0in 0in 10pt; text-align: left;">
IVTs require significant expertise in terms of thought
leadership as well as execution.<span style="mso-spacerun: yes;"> </span>Their
test strategy needs to be clear enough in terms of tools, test data generation,
team composition, and all essential parameters including the technical approach
they decide to adopt.<span style="mso-spacerun: yes;"> </span>In other words, the
goals of IVT are not limited adopting tools and implementing test scripts.
There is more to it.<span style="mso-spacerun: yes;"> </span>A shared vision
among all team members in terms of ‘what’, ‘why’ and ‘how’ of their goals is
essential.</div>
<ol style="text-align: left;">
<li><div class="MsoNormal" style="margin: 0in 0in 10pt; text-align: left;">
Program managers need to know all these factors and select
the right kind of measures to know if IVTs are delivering or not.<span style="mso-spacerun: yes;"> </span>Here are some guidelines to do this.</div>
</li>
<li><div class="MsoNormal" style="margin: 0in 0in 10pt; text-align: left;">
Automation Goals:<span style="mso-spacerun: yes;"> </span>Measure automation %. This is typically a function of number of test cases automated versus total number of test cases</div>
</li>
<li><div class="MsoNormal" style="margin: 0in 0in 10pt; text-align: left;">
<!--[endif]-->Traceability: This is a function of number of test cases versus the number test cases that are traceable to user stories</div>
</li>
<li><div class="MsoNormal" style="margin: 0in 0in 10pt; text-align: left;">
<!--[endif]-->Defect Trends:<span style="mso-spacerun: yes;"> </span>Trends of defects reported by IVT</div>
</li>
<li><div class="MsoNormal" style="margin: 0in 0in 10pt; text-align: left;">
<!--[endif]-->Defect Quality:<span style="mso-spacerun: yes;"> </span>Number of unit level defects reported by IVT versus total number of defects reported by IVT</div>
</li>
<li><div class="MsoNormal" style="margin: 0in 0in 10pt; text-align: left;">
<!--[endif]-->Execution Trends:<span style="mso-spacerun: yes;"> </span>Number of automated scripts executed versus number of manual test cases executed</div>
</li>
<li><div class="MsoNormal" style="margin: 0in 0in 10pt; text-align: left;">
<!--[endif]-->Post-release or post-production defects (Defect removal efficiency)</div>
</li>
<li><div class="MsoNormal" style="margin: 0in 0in 10pt; text-align: left;">
<!--[endif]-->Technical Debt - more specifically, testing debt accumulated in terms of inadequate automation, design flaws in test automation suite, and so on.</div>
</li>
</ol>
<div class="MsoNormal" style="margin: 0in 0in 10pt; text-align: left;">
Consider Independent Verification Teams! IVTs are valuable! We
need them in large-projects as well as program consisting of multiple
interconnected projects. Does this synchronize with your experience and thoughts? Let us discuss.</div>
<div class="MsoNormal" style="margin: 0in 0in 10pt; text-align: left;">
</div>
</div>
Raja Bavanihttp://www.blogger.com/profile/03107697584076683320noreply@blogger.com0tag:blogger.com,1999:blog-356516183452551110.post-48684124515813673782016-01-29T02:52:00.000-08:002016-01-29T04:02:45.173-08:00Agile Program Management: Emerging Architecture<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjKal3FCceD7YVOr6o0cWyBdcwGOnlj-txZ1-9IdcAiy0TpqdmIqxUsD_GDyLjP1cl709FJZJw54rnu2nJMeldWa8boDXjbTujNzohTMg5FUwLZdWDgX8x9KJzkZzCfjAFyYeOOhI1lC3s/s1600/ProgMgmt3.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="214" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjKal3FCceD7YVOr6o0cWyBdcwGOnlj-txZ1-9IdcAiy0TpqdmIqxUsD_GDyLjP1cl709FJZJw54rnu2nJMeldWa8boDXjbTujNzohTMg5FUwLZdWDgX8x9KJzkZzCfjAFyYeOOhI1lC3s/s320/ProgMgmt3.jpg" width="320" /></a></div>
<div class="MsoNormal" style="margin: 0in 0in 10pt; text-align: left;">
<span style="color: black;">What does Agile Program Management have to do with Emerging
Architecture?<span style="mso-spacerun: yes;"> </span>Isn’t Emerging Architecture
a pure technical issue or concern? Why should it be under the purview of Agile
Program Management? <span style="mso-spacerun: yes;"> </span>This blog post is to
discuss these two areas and find answers to such questions.<o:p></o:p></span></div>
<div style="text-align: left;">
<span style="color: black;">
</span></div>
<div class="MsoNormal" style="margin: 0in 0in 10pt; text-align: left;">
<span style="color: black;">Think about a program consisting of multiple projects and
technologies. Let us assume that most of the projects – if not all, are running
in Agile mode.<span style="mso-spacerun: yes;"> </span>Obviously, programs include
related or interrelated projects and program management requires significant
focus on dependency management.<span style="mso-spacerun: yes;"> </span>This is
because something happening in one project may have some impact on one or more
projects.<span style="mso-spacerun: yes;"> </span>Things can get very complex at
times too.<o:p></o:p></span></div>
<div style="text-align: left;">
<span style="color: black;">
</span></div>
<div class="MsoNormal" style="margin: 0in 0in 10pt; text-align: left;">
<span style="color: black;">An emerging architecture can result in dependency
issues.<span style="mso-spacerun: yes;"> </span>This is how it can.<span style="mso-spacerun: yes;"> </span>Let us assume that Project-A comprising of 5
releases and running in Agile mode involves emerging architecture.<span style="mso-spacerun: yes;"> </span>After Release-4 the project team figures out
that they need to do a significant rework on some of the architectural
components and that work requires an additional iteration or two.<span style="mso-spacerun: yes;"> </span>The project team of Project-B is surprised
and concerned because their project is dependent of Project-A.<span style="mso-spacerun: yes;"> </span>There is a dependency issue here.<span style="mso-spacerun: yes;"> </span>Can this happen? Yes it can. And it happens
all the time.<o:p></o:p></span></div>
<div style="text-align: left;">
<span style="color: black;">
</span></div>
<div class="MsoNormal" style="margin: 0in 0in 10pt; text-align: left;">
<span style="color: black;">Why? Probably because, in Project-A there was no systematic
way of measuring Technical Debt and paying it off at regular intervals.<span style="mso-spacerun: yes;"> </span>Probably in the name of ‘Emerging
Architecture’ the team was accumulating technical debt and was unaware of the
magnitude and impact. It occurred to them after Release-4 – may be someone
noticed it while trouble shooting or it surfaced during technical discussions
and eventually it resulted in significant rework. And that rework is going to
involve rework at various places. That means a delay in schedule.<o:p></o:p></span></div>
<div style="text-align: left;">
<span style="color: black;">
</span></div>
<div class="MsoNormal" style="margin: 0in 0in 10pt; text-align: left;">
<span style="color: black;">So what is the point?<span style="mso-spacerun: yes;">
</span>At program management level this has to be a focus area – ‘Emerging
Architecture’ and its possible impact in terms of rework because of lack of
Technical Debt Management. Well, in that sense ‘Technical Debt Management’
itself can be a focus area – I am ok with this idea as long as we know about
all the sources of ‘Technical Debt’ and pay attention to all those sources.<span style="mso-spacerun: yes;"> </span><span style="mso-spacerun: yes;"> </span><o:p></o:p></span></div>
<div style="text-align: left;">
<span style="color: black;">
</span></div>
<div class="MsoNormal" style="margin: 0in 0in 10pt; text-align: left;">
<span style="color: black;">We accumulate technical debt from several sources or at
several levels. Here is a list.<span style="mso-spacerun: yes;"> </span>If you
want to add more items here, let me know.<o:p></o:p></span></div>
<div style="text-align: left;">
<span style="color: black;">
</span></div>
<div class="MsoListParagraphCxSpFirst" style="margin: 0in 0in 0pt 0.5in; mso-list: l0 level1 lfo1; text-align: left; text-indent: -0.25in;">
<!--[if !supportLists]--><span style="color: black;"><span style="mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;"><span style="mso-list: Ignore;">a)<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";">
</span></span></span><!--[endif]-->Emerging Architecture<o:p></o:p></span></div>
<div style="text-align: left;">
<span style="color: black;">
</span></div>
<div class="MsoListParagraphCxSpMiddle" style="margin: 0in 0in 0pt 0.5in; mso-list: l0 level1 lfo1; text-align: left; text-indent: -0.25in;">
<!--[if !supportLists]--><span style="color: black;"><span style="mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;"><span style="mso-list: Ignore;">b)<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";">
</span></span></span><!--[endif]-->Pending or Ignored Technical Decisions<o:p></o:p></span></div>
<div style="text-align: left;">
<span style="color: black;">
</span></div>
<div class="MsoListParagraphCxSpMiddle" style="margin: 0in 0in 0pt 0.5in; mso-list: l0 level1 lfo1; text-align: left; text-indent: -0.25in;">
<!--[if !supportLists]--><span style="color: black;"><span style="mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;"><span style="mso-list: Ignore;">c)<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";">
</span></span></span><!--[endif]-->Inadequate Designs<o:p></o:p></span></div>
<div style="text-align: left;">
<span style="color: black;">
</span></div>
<div class="MsoListParagraphCxSpMiddle" style="margin: 0in 0in 0pt 0.5in; mso-list: l0 level1 lfo1; text-align: left; text-indent: -0.25in;">
<!--[if !supportLists]--><span style="color: black;"><span style="mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;"><span style="mso-list: Ignore;">d)<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";">
</span></span></span><!--[endif]-->Messy Code<o:p></o:p></span></div>
<div style="text-align: left;">
<span style="color: black;">
</span></div>
<div class="MsoListParagraphCxSpMiddle" style="margin: 0in 0in 0pt 0.5in; mso-list: l0 level1 lfo1; text-align: left; text-indent: -0.25in;">
<!--[if !supportLists]--><span style="color: black;"><span style="mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;"><span style="mso-list: Ignore;">e)<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";">
</span></span></span><!--[endif]-->Legacy Code<o:p></o:p></span></div>
<div style="text-align: left;">
<span style="color: black;">
</span></div>
<div class="MsoListParagraphCxSpMiddle" style="margin: 0in 0in 0pt 0.5in; mso-list: l0 level1 lfo1; text-align: left; text-indent: -0.25in;">
<!--[if !supportLists]--><span style="color: black;"><span style="mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;"><span style="mso-list: Ignore;">f)<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";">
</span></span></span><!--[endif]-->Inadequate Test Automation or Lack of Test
Automation<o:p></o:p></span></div>
<div style="text-align: left;">
<span style="color: black;">
</span></div>
<div class="MsoListParagraphCxSpLast" style="margin: 0in 0in 10pt 0.5in; mso-list: l0 level1 lfo1; text-align: left; text-indent: -0.25in;">
<!--[if !supportLists]--><span style="color: black;"><span style="mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;"><span style="mso-list: Ignore;">g)<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";">
</span></span></span><!--[endif]-->Inadequate or unstable environments<o:p></o:p></span></div>
<div style="text-align: left;">
<span style="color: black;">
</span></div>
<div class="MsoNormal" style="margin: 0in 0in 10pt; text-align: left;">
<span style="color: black;">This means that Agile Program Management teams need to ask
the right questions to know if dependency issues can surface across projects
because of lack of focus on any of these sources in one or more projects.<span style="mso-spacerun: yes;"> </span>For example, the function of Agile Program
Management is not to be a mute spectator of Emerging Architecture assuming that
that is how Agile projects work.<span style="mso-spacerun: yes;"> </span>There
has to be leading questions to find out ‘So how are we tracking technical debt
related to emerging architecture and paying it off at regular intervals?’ <o:p></o:p></span></div>
<div style="text-align: left;">
<span style="color: black;">
</span></div>
<div class="MsoNormal" style="margin: 0in 0in 10pt; text-align: left;">
<span style="color: black;">Emerging Architecture is a pure technical concern. However,
it has and it can have significant bearing on Agile Program Management. I think
it should be under the purview of Agile Program Management. And this applies
to all sources that can lead to or result in technical debt.<o:p></o:p></span></div>
<div style="text-align: left;">
<span style="color: black;">
</span></div>
<div class="MsoNormal" style="margin: 0in 0in 10pt; text-align: left;">
<span style="color: black;">Have you come across projects or programs that ignored these
sources or aspects? What were the impacts or results? <o:p></o:p></span></div>
<div style="text-align: left;">
<span style="color: black;">
</span></div>
<div class="MsoNormal" style="margin: 0in 0in 10pt; text-align: left;">
<o:p><span style="color: black;"> </span></o:p></div>
<div style="text-align: left;">
<span style="color: black;">
</span></div>
</div>
Raja Bavanihttp://www.blogger.com/profile/03107697584076683320noreply@blogger.com2tag:blogger.com,1999:blog-356516183452551110.post-71489517471233829242015-12-12T02:41:00.005-08:002015-12-12T02:53:37.934-08:00Agile Program Management: Structure and Behavior<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: left;">
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiukoOwKOHGAvDTz3ngsb2zbzJ3RQIjx567iGrUOBkEWmx5uiw9nfnIZ2c4zMk986WVEp8hQ3MG2A1QgfuwxPM9kK6I2p5h-KHS42lyoyLfIsa2YudzHKRaOQXqyN6DTPN7K7r_m2_KriY/s1600/ProgMgmt2.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="211" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiukoOwKOHGAvDTz3ngsb2zbzJ3RQIjx567iGrUOBkEWmx5uiw9nfnIZ2c4zMk986WVEp8hQ3MG2A1QgfuwxPM9kK6I2p5h-KHS42lyoyLfIsa2YudzHKRaOQXqyN6DTPN7K7r_m2_KriY/s320/ProgMgmt2.jpg" width="320" /></a></div>
<span style="color: black;">I believe you read my <u><a href="http://se-thoughtograph.blogspot.in/2015/10/agile-program-management-simplest-lesson.html" target="_blank">previous post</a></u>.<span style="mso-spacerun: yes;"> </span>In that post I shared a very <u><a href="http://se-thoughtograph.blogspot.in/2015/10/agile-program-management-simplest-lesson.html" target="_blank">simple lesson</a></u>.<span style="mso-spacerun: yes;"> </span>I am writing this post to
discuss the next one.<span style="mso-spacerun: yes;"> </span>It is <strong><em>‘Architect
your team structure and feed your feature teams!'</em></strong>.</span></div>
<div style="text-align: left;">
<span style="color: black;"> </span></div>
<div style="text-align: left;">
<span style="color: black;">Let me explain.<span style="mso-spacerun: yes;"> </span>Think
about a program consisting of multiple projects.<span style="mso-spacerun: yes;"> </span>Every project has a structure according to
the methodology followed.<span style="mso-spacerun: yes;"> </span>Also at a
program level there is a structure consisting of various roles and
responsibilities in order to manage the program.<span style="mso-spacerun: yes;"> </span>Every structure has its associated behavior
whether it is at a project level or at a program level. Very true. Any
ineffective structure at a program level can have cascading effect on almost
all projects covered under the program. Obviously.</span></div>
<div style="text-align: left;">
<span style="color: black;"> </span></div>
<div style="text-align: left;">
<span style="color: black;">Hence, the lesson is ‘Architect your team structure and feed
your feature teams!</span></div>
<div style="text-align: left;">
<span style="color: black;"> </span></div>
<div style="text-align: left;">
<span style="color: black;">One may think, ‘Why feed your feature teams? Why not focus
on other areas as well?’ Well, a reasonable question. In my opinion, feeding
the feature teams or providing them well-groomed requirements or users stories
is the first and foremost need at ground level assuming that teams have
required infrastructure, tools and platforms to perform their daily activities.<span style="mso-spacerun: yes;"> </span>Providing well-groomed user stories is not
the responsibility of program managers. However, being aware and taking
necessary steps to ensure that well-groomed user stories are provided to teams
is one of their responsibilities of program managers. <span style="mso-spacerun: yes;"> </span>When program management teams are structured
right and when they ensure that groomed user stories flow from time to time or
from iteration to iteration, they get a very good view on what is happening on
the ground.<span style="mso-spacerun: yes;"> </span>They can do more. They can
do more things better.</span></div>
<div style="text-align: left;">
<span style="color: black;"> </span></div>
<div style="text-align: left;">
<span style="color: black;">This is an ongoing activity.<span style="mso-spacerun: yes;">
</span>Program management teams need to be agile. They need to go through
periodic retrospective to relook at the structure and improve it.</span></div>
<div style="text-align: left;">
<span style="color: black;"> </span></div>
<div style="text-align: left;">
<span style="color: black;">How can we structure teams? We know how to structure project
teams.<span style="mso-spacerun: yes;"> </span>How do we structure program
teams? We try to do this based on our prior experience or recommendations from
an expert or consultant or coach – or both!<span style="mso-spacerun: yes;">
</span>However, an important input to this exercise is to find an answer to the
question, ‘What kind of behavior do we expect from this team? What do we want
them to accomplish?<span style="mso-spacerun: yes;"> </span>How do their
accomplishments align with program goals?’</span></div>
<div style="text-align: left;">
<span style="color: black;"> </span></div>
<div style="text-align: left;">
<span style="color: black;">That is going to be a periodic exercise that may result in
structural changes in project teams or program teams by means of role changes –
either you introduce a new role, or make some changes to an existing role or
create additional teams or something else to make things better.</span></div>
<div style="text-align: left;">
<span style="color: black;"> </span></div>
<div style="text-align: left;">
<span style="color: black;">When this happens, and when there is a constant focus on
ensuring adequate flow of work, you have put your teams on the right track.</span></div>
<div style="text-align: left;">
<span style="color: black;"> </span></div>
<div style="text-align: left;">
<span style="color: black;">Any thoughts?<o:p></o:p></span></div>
<div style="text-align: left;">
</div>
</div>
Raja Bavanihttp://www.blogger.com/profile/03107697584076683320noreply@blogger.com2tag:blogger.com,1999:blog-356516183452551110.post-22731364103741534232015-10-04T04:24:00.000-07:002015-10-04T04:34:07.041-07:00Agile Program Management: The Simplest Lesson<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjg0SyRhK43I24N3XFSQDzWCg8dNALpK7dffj3Ep60sSpK9hfCkF8-ngQTPTp7d9jSyXlFUFqIi0VEU7Hp7C3Qf1Q1x_pe1ehNm6y7IR6pPmLaOi0LQCnAyMqcdJnaNeATJ4OpNpJfDAX0/s1600/ProgMgmt1.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="204" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjg0SyRhK43I24N3XFSQDzWCg8dNALpK7dffj3Ep60sSpK9hfCkF8-ngQTPTp7d9jSyXlFUFqIi0VEU7Hp7C3Qf1Q1x_pe1ehNm6y7IR6pPmLaOi0LQCnAyMqcdJnaNeATJ4OpNpJfDAX0/s320/ProgMgmt1.jpg" width="320" /></a></div>
<div class="MsoNormal" style="margin: 0in 0in 10pt; text-align: left;">
<span style="color: black;">Program Managing a Large-Scale Distributed Agile Program
involves several challenges such as team structuring, team induction, training,
delivering in short-iterations, team retention and attrition management, system
architecture, dependency management, risk management, software testing and
automation and so on.<span style="mso-spacerun: yes;"> </span>I am writing this post
based on a large-scale distributed Agile program we undertook with more than
300 team members across two time zones with involving multiple business
critical projects.<span style="mso-spacerun: yes;"> </span><span style="mso-spacerun: yes;"> </span>The objective of this post is to share
experiential knowledge on managing large-scale distributed agile programs and
present one of the simplest lessons. This is not it. I will be sharing many
more lessons in my subsequent posts.</span></div>
<div class="MsoNormal" style="margin: 0in 0in 10pt; text-align: left;">
<span style="color: black;">Program Management involves a higher degree of challenge and
complexity as compared to Project Management.<span style="mso-spacerun: yes;">
</span>This is because you need to cover multiple projects involving different
lifecycles, pricing models, stakeholders, integration requirements, and
dependencies. Of course, there are numerous other elements that add to this
list.<span style="mso-spacerun: yes;"> </span>When we move up from the role of a
Project Manager or Scrum Master (in Agile world) to play the role of a Program
Manager, we see program management as a role that involves managing more than
one project and we stop there. We ignore the need to understand the
possibilities of different technologies, stakeholders, regulatory needs,
integration challenges and so on.<span style="mso-spacerun: yes;"> </span>With
over simplification we tend to ignore all the important aspects and eventually
it hurts.</span></div>
<div class="MsoNormal" style="margin: 0in 0in 10pt; text-align: left;">
<span style="color: black;">So, what is the simplest lesson that we need to know? Here
it goes.</span></div>
<div class="MsoNormal" style="margin: 0in 0in 10pt; text-align: left;">
<strong><span style="color: black;">“Not all projects are the same. What worked in one project
need not apply or work in another project.”<o:p></o:p></span></strong></div>
<div style="text-align: left;">
<span style="color: black;">Obviously! We all know that.<span style="mso-spacerun: yes;">
</span>However, how many times have we seen program managers as well as
experienced project managers establishing a set of rigid rules or expectations
on projects or labeling projects based on technology or lifecycle or something
else? Here is an example.<span style="mso-spacerun: yes;"> </span>Once, a
program manager started opining that all agile projects must start doing Test
Driven Development from the beginning.<span style="mso-spacerun: yes;">
</span>Later, she mandated it.<span style="mso-spacerun: yes;"> </span>It did
not work because in some projects teams were getting ready to do automated unit
tests right before jumping in to TDD. In some other projects teams were finding
it tough to implement TDD because those projects involved data migration and
the development activities were not mature enough to bring in TDD.</span></div>
<div style="text-align: left;">
<span style="color: black;"> </span></div>
<div style="text-align: left;">
<span style="color: black;">Let me present you with another example. Years ago, I came
across a program manager who was very fond of three metrics - Schedule
Variance, Effort Variance and Defect Density.<span style="mso-spacerun: yes;">
</span>She ran program management meetings by looking at these three metrics.
She wanted these three for projects of all sorts. It did not work because there
were projects following iterative cycle. There were projects following Scrum
and there were maintenance projects running in Kanban mode.</span></div>
<div style="text-align: left;">
<span style="color: black;"> </span></div>
<div style="text-align: left;">
<span style="color: black;">Well, is this simple lesson specific to Agile Program
Management? No. It can be applied in Program Management in general.<span style="mso-spacerun: yes;"> </span>Let me give you another example.<span style="mso-spacerun: yes;"> </span>I had a Program Manager who used to manage
multiple projects and most of them were following Scrum. Some of them were
large-scale projects.<span style="mso-spacerun: yes;"> </span>She recommended
the same style, intensity and schedule of coaching – I mean Agile Coaching, for
all Agile projects that would get added under her program no matter what.<span style="mso-spacerun: yes;"> </span>She was ignoring the need to understand the
needs of the project well and custom fit a coaching solution.<span style="mso-spacerun: yes;"> </span>When an Agile Coach suggested this to her,
she did not take it on the face of it. It took us some time to sell the idea.</span></div>
<div style="text-align: left;">
<span style="color: black;"> </span></div>
<div style="text-align: left;">
<span style="color: black;">“It worked in my previous project. It must work here as
well.” <span style="mso-spacerun: yes;"> </span>This is a typical Project
Management mind block.<span style="mso-spacerun: yes;"> </span>Many rookie project
manager jump on to their second project with this belief. They bang their heads
before they learn the hard lesson. And that is of course the simplest
lesson.</span></div>
<div style="text-align: left;">
<span style="color: black;"> </span></div>
<div style="text-align: left;">
<span style="color: black;">Be open minded, listen to ideas, think logically and
collaborate with your project managers. That is one way to keep remembering
this simplest lesson and avoid fundamental mistakes.</span></div>
<div style="text-align: left;">
<span style="color: black;"> </span></div>
<div style="text-align: left;">
<span style="color: black;">Do you relate this simplest lesson to your experience or an incident happened at work? Please feel free to discuss. In my next post, I will continue with the next lesson.</span></div>
<div style="text-align: left;">
<span style="font-family: "Calibri",sans-serif; font-size: 11pt; line-height: 115%; mso-ansi-language: EN-US; mso-ascii-theme-font: minor-latin; mso-bidi-font-family: "Times New Roman"; mso-bidi-language: AR-SA; mso-bidi-theme-font: minor-bidi; mso-fareast-font-family: Calibri; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-latin; mso-hansi-theme-font: minor-latin;"><span style="font-family: Times New Roman; font-size: small;"></span></span><span style="color: black;"> </span></div>
</div>
Raja Bavanihttp://www.blogger.com/profile/03107697584076683320noreply@blogger.com3tag:blogger.com,1999:blog-356516183452551110.post-3625729991639287032015-08-27T03:16:00.003-07:002016-04-06T22:33:06.642-07:00Documentation in Agile Projects: Why? How? And What?<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhlNy5gVQ_0ZCPnnZDGdNF8coiERya-00QYcDX4tdDRDY5FT_5nVKWfFviHZQouyOiwCrGgslMNJogfHLPBoB7dTX3-Om2WAevi9R0uIrOL2D4lHJzQbFGRoGUML7mP6I2nnG8EGQ6K7JQ/s1600/AgileDoc.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="204" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhlNy5gVQ_0ZCPnnZDGdNF8coiERya-00QYcDX4tdDRDY5FT_5nVKWfFviHZQouyOiwCrGgslMNJogfHLPBoB7dTX3-Om2WAevi9R0uIrOL2D4lHJzQbFGRoGUML7mP6I2nnG8EGQ6K7JQ/s320/AgileDoc.jpg" width="320" /></a></div>
<div class="MsoNormal" style="margin: 0in 0in 10pt; text-align: left;">
<span style="color: black;">I am writing this blog post to provide a crisp treatment on a
topic that comes up quite often when we talk about Agile implementation,
adoption, transition and so on.<span style="mso-spacerun: yes;"> </span>The
first and foremost driver and a myth that causes this discussion is that <u><a href="http://se-thoughtograph.blogspot.in/2011/12/agile-myths-and-misunderstandings.html" target="_blank">Agile means ‘no documentation’</a></u>.<span style="mso-spacerun: yes;"> </span>Yes that is a
myth. <span style="mso-spacerun: yes;"> </span>Agile does not mean ‘no
documentation’.<span style="mso-spacerun: yes;"> </span>Let us begin with that
understanding and move on to understand why we need documentation in software
projects.<span style="mso-spacerun: yes;"> </span>We need documentation in
software because of the following reasons.<o:p></o:p></span></div>
<ul style="text-align: left;">
<li><span style="color: black;">
Project stakeholders need it<span style="mso-spacerun: yes;"> </span>(a business decision)<o:p></o:p></span></li>
<li><span style="color: black;">To define a contract model (external interfaces and integration parameters)<o:p></o:p></span></li>
<li><span style="font-family: "symbol"; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;"><span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"></span></span></span><!--[endif]--><span style="color: black;">To enable communication with an external group (distributed teams, other project teams)<o:p></o:p></span></li>
<li><span style="font-family: "symbol"; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;"><span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"></span></span></span><!--[endif]--><span style="color: black;">For audit / compliance reasons<o:p></o:p></span></li>
<li><span style="font-family: "symbol"; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;"><span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"></span></span></span><!--[endif]--><span style="color: black;">To think something through – when you write or document something you think further and think deep. It helps before you get into discussions! You can save a whole lot of time by doing this!<o:p></o:p></span></li>
</ul>
<div style="text-align: left;">
<span style="color: black;">There can be other reasons too. Here are some and these are
not so good reasons. Beware!</span></div>
<ul style="text-align: left;">
<li><span style="color: black;">The requester wants it! – She has the authority and thinks that it is required.<o:p></o:p></span></li>
<li><span style="color: black;">The requester mistakenly perceives documentation as project success<o:p></o:p></span></li>
<li><span style="font-family: "symbol"; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;"><span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"></span></span></span><!--[endif]--><span style="color: black;">The process says so! <o:p></o:p></span></li>
<li><span style="font-family: "symbol"; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;"><span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"></span></span></span><!--[endif]--><span style="color: black;">Someone wants to reassure someone else that everything is ok!<o:p></o:p></span></li>
<li><span style="font-family: "symbol"; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;"><span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"></span></span></span><!--[endif]--><span style="color: black;">Status Quo! We are a large organization and this is our way! </span></li>
</ul>
<div class="MsoNormal" style="margin: 0in 0in 10pt; text-align: left;">
<span style="color: black;">In traditional SDLC, we used to do
Big-Upfront-Documentation.<span style="mso-spacerun: yes;"> </span>It is a
costly affair.<span style="mso-spacerun: yes;"> </span><span style="mso-spacerun: yes;"> </span>When we know that 45% of deliver
functionality is not going to be used, the corresponding cost invested in
documentation goes unused too.<span style="mso-spacerun: yes;"> </span>So, we
need to be aware of the cost involved in big-upfront-documentation.</span></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhD3NRXyQGfuCXSPN9Ay_SQDYceljxT8RRhQGCLJ9C1y2YN0C53ymtJRzxOBAgo03Xig6kJyokfHVMOH6D2YIYr3Gzgao48RCsCE7-qXM82BMBulT9vOQvQEABJttvASBJ22TcN5YiVXa4/s1600/CostofBUFD.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><span style="color: black;"><img border="0" height="385" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhD3NRXyQGfuCXSPN9Ay_SQDYceljxT8RRhQGCLJ9C1y2YN0C53ymtJRzxOBAgo03Xig6kJyokfHVMOH6D2YIYr3Gzgao48RCsCE7-qXM82BMBulT9vOQvQEABJttvASBJ22TcN5YiVXa4/s400/CostofBUFD.jpg" width="400" /></span></a></div>
<div class="MsoNormal" style="margin: 0in 0in 10pt; text-align: center;">
<span style="color: black;"></span></div>
<div class="MsoNormal" style="margin: 0in 0in 10pt; text-align: left;">
<span style="color: black;">Our goal is to communicate. One of the mechanisms to enable
this is to create documents.<span style="mso-spacerun: yes;"> </span>However,
documentation is the least effective mode of communication as shown below.</span></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhT_o1-lU5IyvWje9jLfQuMnY3YedznRHGzeMOPxN3ncLil3QwDS924EBxzt808oWxySs4CjRfWu_5CrCotBMQwlZ8wg2BvKYMXcKLo_YjhJei6pax-Hzy4yu6C0Qd7DiOgKvf0bAjvkpQ/s1600/RichnessofCommunication.gif" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><span style="color: black;"><img border="0" height="345" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhT_o1-lU5IyvWje9jLfQuMnY3YedznRHGzeMOPxN3ncLil3QwDS924EBxzt808oWxySs4CjRfWu_5CrCotBMQwlZ8wg2BvKYMXcKLo_YjhJei6pax-Hzy4yu6C0Qd7DiOgKvf0bAjvkpQ/s400/RichnessofCommunication.gif" width="400" /></span></a></div>
<div align="center" class="MsoNormal" style="margin: 0in 0in 10pt; text-align: left;">
<span style="color: black;"></span></div>
<div class="MsoNormal" style="margin: 0in 0in 10pt; text-align: left;">
<span style="color: black;">Let me step back.<span style="mso-spacerun: yes;"> </span>Our
goal is to communicate but that is not the only goal at a project level. There are several goals
as listed here.<o:p></o:p></span></div>
<ul style="text-align: left;">
<li><div style="text-align: left;">
<span style="color: black;">
Communicate Well - Documentation is not the primary issue – communication is!<o:p></o:p></span></div>
</li>
<li><div style="text-align: left;">
<!--[endif]--><span style="color: black;">Ensure Project Success – Comprehensive documentation does not ensure project success!<o:p></o:p></span></div>
</li>
<li><div style="text-align: left;">
<span style="color: black;">Create Consumable Documentation – Documentation need not be sophisticated!<o:p></o:p></span></div>
</li>
<li><div style="text-align: left;">
<span style="color: black;">Create well-written, concise documentation<o:p></o:p></span></div>
</li>
<li><div style="text-align: left;">
<span style="color: black;">Try to be flexible enough – Avoid trying to fit everything into a standardized template<o:p></o:p></span></div>
</li>
<li><div style="text-align: left;">
<span style="color: black;">Keep the audience in mind – Usability and readability are critical.</span></div>
</li>
</ul>
<div class="MsoNormal" style="margin: 0in 0in 10pt; text-align: left;">
<span style="color: black;"></span><br />
<span style="color: black;">In traditional SDLC, we have seen so many documents – High-level
Plan, High-level Requirements and Architecture, Detailed Project Plan, Detailed
Requirements Specifications, Detailed Design Specifications, User Manual, and
so on.<span style="mso-spacerun: yes;"> </span>And in most projects, these
documents did not remain up-to-date as the software went to production and
later in to maintenance phase.<span style="mso-spacerun: yes;"> </span><span style="mso-spacerun: yes;"> </span>Maintenance teams did not find them valuable
and they started creating their own help documents.<span style="mso-spacerun: yes;"> </span>The story went on. And this is true in most
projects.<o:p></o:p></span></div>
<div style="text-align: left;">
<span style="color: black;">
In Agile world, you ask follow Agile Principles. You know
that document creation involves efforts and efforts cost money.<span style="mso-spacerun: yes;"> </span>Why invest money in documents that go out of
date?<span style="mso-spacerun: yes;"> </span>Why not do crisp documentation and
create an up-to-date set of documents that can be valuable to end users and
maintainers at logical intervals?<span style="mso-spacerun: yes;"> </span>Does it
make sense?</span><br />
<span style="color: black;"><o:p><br /></o:p></span></div>
<div style="text-align: left;">
<span style="color: black;">
</span></div>
<div class="MsoNormal" style="margin: 0in 0in 10pt; text-align: left;">
<span style="color: black;">So, Agile teams invest in documentation when they need to<o:p></o:p></span></div>
<ul style="text-align: left;">
<li><div style="text-align: left;">
<span style="color: black;">Communicate information during development<o:p></o:p></span></div>
</li>
<li><div style="text-align: left;">
<span style="color: black;">Specify something (how-to test, what to test, etc.)<o:p></o:p></span></div>
</li>
<li><div style="text-align: left;">
<span style="color: black;">Permanently record information (decisions and trade-offs)<o:p></o:p></span></div>
</li>
<li><div style="text-align: left;">
<span style="color: black;">Confirm regulations<o:p></o:p></span></div>
</li>
</ul>
<div style="text-align: left;">
<span style="color: black;">
And they know that there are 3 types or categories of
documentation.<span style="mso-spacerun: yes;"> </span>These categories are not the same and
documents belonging to these categories do not need the same type of treatment. </span></div>
<ol style="text-align: left;">
<li><div style="text-align: left;">
<span style="color: black;">Work-in-progress documentation<span style="mso-spacerun: yes;"> </span>(requirements, design, etc.)<o:p></o:p></span></div>
</li>
<li><div style="text-align: left;">
<span style="color: black;">Product documentation (API documentation, user manuals, etc.)<o:p></o:p></span></div>
</li>
<li><div style="text-align: left;">
<span style="color: black;">Handoff documentation (supports long-term viability of the project)<o:p></o:p></span></div>
</li>
</ol>
<div style="text-align: left;">
<span style="color: black;">Above all, irrespective of the SDLC we follow, it is meaningful to ask the
following questions and seek answers. That will help us know what to document and what
not to.</span></div>
<ul style="text-align: left;">
<li><div style="text-align: left;">
<span style="color: black;">When? How? How much to invest in documentation? What is necessary at what timeframe?<o:p></o:p></span></div>
</li>
<li><div style="text-align: left;">
<span style="color: black;">Do we measure the productivity of document creators? How?<o:p></o:p></span></div>
</li>
<li><div style="text-align: left;">
<span style="color: black;">Do we measure the cost of maintaining documents? How?</span></div>
</li>
<li><div style="text-align: left;">
<span style="color: black;">What do we do with stale or outdated documents?<o:p></o:p></span></div>
</li>
</ul>
<div style="text-align: left;">
<span style="color: black;">So what documents do Agile teams create? It depends on
factors such as complexity, strategic importance, user base across geographies,
and criticality of projects. Here is a sample set.</span></div>
<ul style="text-align: left;">
<li><div style="text-align: left;">
<span style="color: black;">Executive Overview/Vision/Project Charter<o:p></o:p></span></div>
</li>
<li><div style="text-align: left;">
<span style="color: black;">Project Overview<o:p></o:p></span></div>
</li>
<li><div style="text-align: left;">
<span style="color: black;">Product Backlog, User Stories<o:p></o:p></span></div>
</li>
<li><div style="text-align: left;">
<span style="color: black;">Test Cases, Test Scenarios with Test Data<o:p></o:p></span></div>
</li>
<li><div style="text-align: left;">
<span style="color: black;">Solution Design, Contract Models(Interface Specifications)<o:p></o:p></span></div>
</li>
<li><div style="text-align: left;">
<span style="color: black;">Design Decisions/Trade-offs<o:p></o:p></span></div>
</li>
<li><div style="text-align: left;">
<span style="font-family: "symbol"; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;"><span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"></span></span></span><!--[endif]--><span style="color: black;">User Manual<o:p></o:p></span></div>
</li>
<li><div style="text-align: left;">
<span style="font-family: "symbol"; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;"><span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"></span></span></span><!--[endif]--><span style="color: black;">Support Manual<o:p></o:p></span></div>
</li>
</ul>
<div style="text-align: left;">
<span style="color: black;">
This is what most Agile teams do.<span style="mso-spacerun: yes;"> And t</span>he documents they create</span></div>
<ol style="text-align: left;">
<li><div style="text-align: left;">
<span style="color: black;">Maximize stakeholder ROI<o:p></o:p></span></div>
</li>
<li><div style="text-align: left;">
<span style="color: black;">Stakeholders know TCO of the document<o:p></o:p></span></div>
</li>
<li><div style="text-align: left;">
<span style="color: black;">Remain Lean and sufficient<o:p></o:p></span></div>
</li>
<li><div style="text-align: left;">
<span style="color: black;">Are meant for specific customer or audience<o:p></o:p></span></div>
</li>
<li><div style="text-align: left;">
<span style="color: black;">Are sufficiently accurate, consistent and detailed<o:p></o:p></span></div>
</li>
<li><div style="text-align: left;">
<span style="color: black;">Fulfill the purpose</span></div>
</li>
</ol>
<div class="MsoNormal" style="margin: 0in 0in 10pt; text-align: left;">
<span style="color: black;">Are you facing challenges in accomplishing these? Let us
discuss.<o:p></o:p></span></div>
<div style="text-align: left;">
</div>
<div style="text-align: left;">
</div>
</div>
Raja Bavanihttp://www.blogger.com/profile/03107697584076683320noreply@blogger.com2tag:blogger.com,1999:blog-356516183452551110.post-36167891934443448712015-06-07T05:01:00.000-07:002015-06-07T05:01:07.089-07:00Scaling Agile: Hone Your Anticipatory Skills<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhHY0_RGpP5Mn1LwDQr7a4CDYyR6M8p4tbdNqpAH9rgSa97g_UXH5uqT_-kLfeBllGeRX3eb7EA1Gfo3f7ob4Tz3ZCKfTjwdVzsjbf0d-Fn2-22cLvWkHeosiWeOKoT5E8A9KiUDsNqR8M/s1600/ASkills.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="248" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhHY0_RGpP5Mn1LwDQr7a4CDYyR6M8p4tbdNqpAH9rgSa97g_UXH5uqT_-kLfeBllGeRX3eb7EA1Gfo3f7ob4Tz3ZCKfTjwdVzsjbf0d-Fn2-22cLvWkHeosiWeOKoT5E8A9KiUDsNqR8M/s400/ASkills.jpg" width="400" /></a></div>
<div class="MsoNormal" style="margin: 0in 0in 0pt; mso-layout-grid-align: none; text-align: left;">
<span style="color: black;"></span> </div>
<div class="MsoNormal" style="margin: 0in 0in 0pt; mso-layout-grid-align: none; text-align: left;">
<span style="color: black;">Working
on large-scale Agile projects has made me feel as if I am challenged to solve a
10,000-piece three dimensional jigsaw puzzle!<span style="mso-spacerun: yes;">
</span>When I think deep, the challenge is more than that.<span style="mso-spacerun: yes;"> </span>You have some clarity and a great level of
ambiguity on what you need to accomplish and you don’t know the number of
pieces. As you move on some pieces are ready, and visible. Some are not
visible, but you feel that you are in a dark room and you can touch and feel
and create a visual piece to some extent. Other pieces evolve as you move
forward.<span style="mso-spacerun: yes;"> </span>There are multiple people
involved in putting all these pieces together. Some of them are providing
oversight, some are giving ideas, some other are reviewing and commenting, and
the puzzle is in the process of getting solved.<span style="mso-spacerun: yes;">
</span>This analogy stretches based on your experience. And you may say, ‘It is
a lot more than that and as complex as working on multiple such puzzles and
putting them together.’<span style="mso-spacerun: yes;"> </span>Am sure, you
have been through software projects like these. You need to hone anticipatory
skills to sail through such projects.<span style="mso-spacerun: yes;">
</span>Without anticipatory skills, your contribution will not be significant
enough.</span></div>
<div class="MsoNormal" style="margin: 0in 0in 0pt; mso-layout-grid-align: none; text-align: left;">
</div>
<div class="MsoNormal" style="margin: 0in 0in 0pt; mso-layout-grid-align: none; text-align: left;">
<span style="color: black;">Do
you know? Anticipatory expertise has been observed in a number of athletes such
as Baseball players, Tennis players and so on. For more information on this,
read Dan Peterson’s article '<u><a href="http://www.axonpotential.com/the-anticipatory-skills-of-athletes/" target="_blank">The Anticipatory Skills of Athletes</a>'</u>.</span></div>
<ol style="text-align: left;">
<li><div class="MsoNormal" style="margin: 0in 0in 0pt; mso-layout-grid-align: none; text-align: left;">
<span style="color: black;">What can we do with our anticipatory skills in large-scale Agile projects. First, we can think through and ask anticipatory questions.<span style="mso-spacerun: yes;"> </span>Next, we can come up with potential action plan to handle what we anticipate. Here are some examples.</span></div>
</li>
<li><div class="MsoNormal" style="margin: 0in 0in 0pt; mso-layout-grid-align: none; text-align: left;">
<span style="color: black;">What is going to be the maturity of user story grooming for the upcoming Sprint based on past experience? How can it impact the schedule and quality of deliverables? What do we need to do about it?</span></div>
</li>
<li><div class="MsoNormal" style="margin: 0in 0in 0pt; mso-layout-grid-align: none; text-align: left;">
<span style="color: black;">What can be the impact of an upcoming architecture or design change on code quality and unit test coverage? What are our current measures and what can they be in future? How can we manage stakeholders?</span></div>
</li>
<li><div class="MsoNormal" style="margin: 0in 0in 0pt; mso-layout-grid-align: none; text-align: left;">
<span style="color: black;">What are the right sets of test cases for an upcoming Sprint? How can we optimize testing efforts and improve quality?</span></div>
</li>
<li><div class="MsoNormal" style="margin: 0in 0in 0pt; mso-layout-grid-align: none; text-align: left;">
<span style="color: black;">What are going to be the risks that we need to handle as we move forward? What is going to be the impact?</span></div>
</li>
<li><div class="MsoNormal" style="margin: 0in 0in 0pt; mso-layout-grid-align: none; text-align: left;">
<span style="color: black;">How is the current pace of work impacting team morale? What do we need to do about this?</span></div>
</li>
<li><div class="MsoNormal" style="margin: 0in 0in 0pt; mso-layout-grid-align: none; text-align: left;">
<span style="color: black;">What are going to be the structural changes in teams over the next two iterations? What do we need to do now to prepare for those changes?</span></div>
</li>
<li><div class="MsoNormal" style="margin: 0in 0in 0pt; mso-layout-grid-align: none; text-align: left;">
<span style="color: black;">How are we planning to integrate the software we produce with related projects or products? How are those projects or products performing in terms of schedule, quality and stability? What are the dependencies? How can that impact the schedule and quality of our project?</span></div>
</li>
<li><div class="MsoNormal" style="margin: 0in 0in 0pt; mso-layout-grid-align: none; text-align: left;">
<span style="color: black;">What are some of the leadership changes we foresee in future? How do we need to manage it effectively?</span></div>
</li>
<li><div class="MsoNormal" style="margin: 0in 0in 0pt; mso-layout-grid-align: none; text-align: left;">
<span style="color: black;">Based on the success rate of our build and release plans, how do we foresee success in the upcoming release? What are the corrective measures we need to put in place now?</span></div>
</li>
</ol>
<div class="MsoNormal" style="margin: 0in 0in 0pt; mso-layout-grid-align: none; text-align: left;">
<span style="color: black;">Anticipatory
skills are essential for Scrum Masters, Project Managers and the likes.<span style="mso-spacerun: yes;"> </span>Anticipatory skills are required in all kinds
of projects? When it comes to large-scale distributed Agile projects,
anticipatory skills can make you play the right cards at the right time. <span style="mso-spacerun: yes;"> </span>How well are you honing your anticipatory
skills? Are they paying off?<o:p></o:p></span></div>
<div style="text-align: left;">
<br /></div>
<span style="color: black;"><div style="text-align: left;">
</div>
<div style="text-align: left;">
<div style="text-align: left;">
<span style="color: black;"><strong><u><span style="color: black;">Related Posts:</span></u></strong></span></div>
<span style="color: black;"><span style="color: black;"></span></span><br />
<ol style="text-align: left;"><span style="color: black;">
<li><div style="text-align: left;">
<u><a href="http://se-thoughtograph.blogspot.in/2014/12/scaling-agile-what-do-architects-deliver.html" target="_blank"><span style="color: black;">Scaling Agile: What Do Architects Deliver?<o:p></o:p></span></a></u></div>
</li>
<li><div style="text-align: left;">
<u><a href="http://se-thoughtograph.blogspot.in/2015/02/scaling-agile-architecting-your-team.html" target="_blank"><span style="color: black;">Scaling Agile: Architecting Your Agile Team<o:p></o:p></span></a></u></div>
</li>
<li><div style="text-align: left;">
<u><a href="http://se-thoughtograph.blogspot.in/2015/02/scaling-agile-feeding-your-feature-teams.html" target="_blank"><span style="color: black;">Scaling Agile: Feeding Your Feature Teams<o:p></o:p></span></a></u></div>
</li>
<li><div style="text-align: left;">
<u><a href="http://se-thoughtograph.blogspot.in/2013/01/software-architecture-and-design-in.html" target="_blank"><span style="color: black;">Software Architecture and Design in Agile World<o:p></o:p></span></a></u></div>
</li>
<li><div style="text-align: left;">
<u><a href="http://se-thoughtograph.blogspot.in/2015/03/scaling-agile-emerging-architecture-and.html" target="_blank"><span style="color: black;">Scaling Agile: Emerging Architecture and Technical Debt</span></a></u></div>
</li>
<li><div style="text-align: left;">
<u><a href="http://se-thoughtograph.blogspot.com/2015/05/scaling-agile-value-of-independent.html" target="_blank"><span style="color: black;">Scaling Agile: The Value of Independent Testing</span></a></u></div>
</li>
<li><div style="text-align: left;">
<u><span style="color: black;"><a href="http://se-thoughtograph.blogspot.in/2015/05/scaling-agile-succeeding-in-release.html" target="_blank">Scaling Agile: Succeeding in Release Management</a> </span></u></div>
</li>
<li><div style="text-align: left;">
<u><a href="http://se-thoughtograph.blogspot.in/2015/05/scaling-agile-disastrous-software.html" target="_blank">Scaling Agile: Disastrous Software Factories</a></u></div>
</li>
<li><div style="text-align: left;">
<u><a href="http://se-thoughtograph.blogspot.in/2015/05/scaling-agile-transitioning-to-kanban.html" target="_blank">Scaling Agile: Transitioning to Kanban</a></u></div>
</li>
<li><div style="text-align: left;">
<u><a href="http://se-thoughtograph.blogspot.in/2015/05/scaling-agile-hardening-sprint-and_31.html" target="_blank">Scaling Agile: Hardening Sprint and the Problem of Procrastination</a></u></div>
</li>
</span></ol>
</div>
</span> </div>
Raja Bavanihttp://www.blogger.com/profile/03107697584076683320noreply@blogger.com0tag:blogger.com,1999:blog-356516183452551110.post-43088785402856420472015-05-31T00:10:00.001-07:002018-06-18T06:34:30.723-07:00Scaling Agile: Hardening Sprint and the Problem of Procrastination<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgqpio17Q4hYxHOt8w13H4TGYFf2FozduI1hLzLjLSIRejK-BLTT5rNV8cTxHQQ0jvquyN-poSwd0cD3vee0LtxoDhZFe-hTh6YeBIv23rlaKQpPw1LUJ8XJ1vfC0Ne5wT45UW6-FA-KK8/s1600/HardeningSprint.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="216" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgqpio17Q4hYxHOt8w13H4TGYFf2FozduI1hLzLjLSIRejK-BLTT5rNV8cTxHQQ0jvquyN-poSwd0cD3vee0LtxoDhZFe-hTh6YeBIv23rlaKQpPw1LUJ8XJ1vfC0Ne5wT45UW6-FA-KK8/s400/HardeningSprint.jpg" width="400" /></a></div>
<div class="MsoNormal" style="margin: 0in 0in 0pt; text-align: left;">
<span style="color: black;">“Yes, we know that this is not done right yet. We have some
rework to do and we have three more feature Sprints with a significant backlog.
We will take care of this rework in the hardening Sprint.” </span><br />
<span style="color: black;"><br /></span>
<span style="color: black;">Sounds familiar? </span><br />
<span style="color: black;"><br /></span>
<span style="color: black;">What is a hardening Sprint? Why do we plan
for a hardening Sprint?<span style="mso-spacerun: yes;"> </span>Hardening Sprint
is an iteration that happens before release readiness. It is a common practice
irrespective of the methodology one follows. The term ‘hardening’ comes from
‘code-hardening’ – providing some finishing touches, making some minor
adjustments to make things better on code base. <span style="mso-spacerun: yes;"> </span>The goal is to improve structural quality and
fix some defects too. It is not about delayed refactoring. Hardening Sprint
does not include implementation of new features – obviously!<span style="mso-spacerun: yes;"> </span>Hardening Sprint is to tie all the loose
ends, fix defects and make sure that the product is ready for release. No new
features but finishing touches, key improvements, and defect fixes. Period.</span><br />
<span style="color: black;"><br /></span></div>
<div class="MsoNormal" style="margin: 0in 0in 0pt; text-align: left;">
</div>
<div class="MsoNormal" style="margin: 0in 0in 0pt; text-align: left;">
<span style="color: black;">In large-scale Agile projects, even if we adhere to this
norm, we know there are enough challenges. This is mainly because of what is involved in hardening
the software created by multiple feature teams. And when we violate the purpose by introducing new features or major changes, we eventually face a whole lot
of challenges.</span><br />
<span style="color: black;"><br /></span></div>
<div class="MsoNormal" style="margin: 0in 0in 0pt; text-align: left;">
</div>
<div class="MsoNormal" style="margin: 0in 0in 0pt; text-align: left;">
<span style="color: black;">When we go through a whole lot of challenges in a hardening
Sprint because of reasons such as introduction of new features or user
stories or<span style="mso-spacerun: yes;"> </span>major changes to architecture/design components or any change that rattles the compatibility of
components, we must admit that probably it is because of the problem of procrastination.<span style="mso-spacerun: yes;"> Procrastination results in</span> some of these - <span style="mso-spacerun: yes;"> </span>insufficient planning or re-planning,
ineffective prioritization, inadequate story grooming, weak design, postponed
decisions, too many changes, fuzzy acceptance criteria, and so on.<span style="mso-spacerun: yes;"> All t</span>hese could make a hardening Sprint harder to
execute.</span><br />
<span style="color: black;"><br /></span></div>
<div class="MsoNormal" style="margin: 0in 0in 0pt; text-align: left;">
</div>
<div class="MsoNormal" style="margin: 0in 0in 0pt; text-align: left;">
<span style="color: black;">When we are in feature Sprints to deliver user stories or
features, we tend to give importance to things that are immediate and urgent
(not necessarily important).<span style="mso-spacerun: yes;"> </span>We tend to
do quick fixes. We accumulate technical debt.<span style="mso-spacerun: yes;">
</span>Eventually, we lose focus on long-term goals or vision.</span><br />
<span style="color: black;"><br /></span></div>
<div class="MsoNormal" style="margin: 0in 0in 0pt; text-align: left;">
</div>
<div class="MsoNormal" style="margin: 0in 0in 0pt; text-align: left;">
<span style="color: black;"><em>“Giving up on our long-term goals for
immediate gratification is procrastination.”</em><span style="mso-spacerun: yes;">
</span>This is what <strong>Dan Ariely</strong> says in Chapter-6 of his book <strong>‘Predictably
Irrational’</strong>.<span style="mso-spacerun: yes;"> </span>In this chapter he has
given multiple examples on why we can’t make ourselves do what we want to do.</span><br />
<span style="color: black;"><br /></span></div>
<div class="MsoNormal" style="margin: 0in 0in 0pt; text-align: left;">
</div>
<div class="MsoNormal" style="margin: 0in 0in 0pt; text-align: left;">
<span style="color: black;">In
large-scale Agile or projects cross-functional teams align and exhibit certain
behavior.<span style="mso-spacerun: yes;"> </span>Sometimes, the power of
dissent is forgotten or ignored.</span><br />
<span style="color: black;"><br /></span></div>
<div class="MsoNormal" style="margin: 0in 0in 0pt; text-align: left;">
</div>
<div class="MsoNormal" style="margin: 0in 0in 0pt; text-align: left;">
<span style="color: black;">What
can we do?<span style="mso-spacerun: yes;"> </span>We can do many things to make
a hardening Sprint meaningful and valuable.<span style="mso-spacerun: yes;">
</span>Here some ideas.<o:p></o:p></span></div>
<ol style="text-align: left;">
<li><div style="text-align: left;">
<span style="color: black;">
<span style="mso-fareast-font-family: Calibri;"><span style="mso-list: Ignore;"><span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"> </span></span></span><!--[endif]-->Identify the factors that make a hardening Sprint harder. <span style="mso-spacerun: yes;"> </span>Learn from experience. Check if certain bad smells are repeating when you are working on a subsequent release. If yes, find a fix.<o:p></o:p></span></div>
</li>
<li><div style="text-align: left;">
<span style="mso-fareast-font-family: Calibri;"><span style="mso-list: Ignore;"><span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"></span></span></span><!--[endif]--><span style="color: black;">Define the scope of Hardening Sprint 2 or 3 Sprints ahead in the release cycle.<span style="mso-spacerun: yes;"> </span>Assess the need for any corrective action – such as one more feature Sprint or abandoning low-priority features.<o:p></o:p></span></div>
</li>
<li><div style="text-align: left;">
<span style="mso-fareast-font-family: Calibri;"><span style="mso-list: Ignore;"><span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"></span></span></span><!--[endif]--><span style="color: black;">Assess technical debt (including testing debt – such as lack of adequate testing or lack of adequate automation). <o:p></o:p></span></div>
</li>
<li><div style="text-align: left;">
<span style="mso-fareast-font-family: Calibri;"><span style="mso-list: Ignore;"><span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"></span></span></span><!--[endif]--><span style="color: black;">Assess environment issues that may lead to a backlog of work items in the hardening Sprint.<o:p></o:p></span></div>
</li>
</ol>
<div style="text-align: left;">
<span style="color: black;">Try
all these at the end of Sprints.<span style="mso-spacerun: yes;"> </span>Don’t
procrastinate and look at all these just before the hardening Sprint begins!<o:p></o:p></span></div>
<div style="text-align: left;">
<br />
<span style="color: black;">
<br />
</span><br />
<div style="text-align: left;">
<div style="text-align: left;">
<span style="color: black;"><strong><u><span style="color: black;">Related Posts:</span></u></strong></span></div>
<span style="color: black;"><span style="color: black;"></span></span><br />
<ol style="text-align: left;"><span style="color: black;">
<li><div style="text-align: left;">
<u><a href="http://se-thoughtograph.blogspot.in/2014/12/scaling-agile-what-do-architects-deliver.html" target="_blank"><span style="color: black;">Scaling Agile: What Do Architects Deliver?<o:p></o:p></span></a></u></div>
</li>
<li><div style="text-align: left;">
<u><a href="http://se-thoughtograph.blogspot.in/2015/02/scaling-agile-architecting-your-team.html" target="_blank"><span style="color: black;">Scaling Agile: Architecting Your Agile Team<o:p></o:p></span></a></u></div>
</li>
<li><div style="text-align: left;">
<u><a href="http://se-thoughtograph.blogspot.in/2015/02/scaling-agile-feeding-your-feature-teams.html" target="_blank"><span style="color: black;">Scaling Agile: Feeding Your Feature Teams<o:p></o:p></span></a></u></div>
</li>
<li><div style="text-align: left;">
<u><a href="http://se-thoughtograph.blogspot.in/2013/01/software-architecture-and-design-in.html" target="_blank"><span style="color: black;">Software Architecture and Design in Agile World<o:p></o:p></span></a></u></div>
</li>
<li><div style="text-align: left;">
<u><a href="http://se-thoughtograph.blogspot.in/2015/03/scaling-agile-emerging-architecture-and.html" target="_blank"><span style="color: black;">Scaling Agile: Emerging Architecture and Technical Debt</span></a></u></div>
</li>
<li><div style="text-align: left;">
<u><a href="http://se-thoughtograph.blogspot.com/2015/05/scaling-agile-value-of-independent.html" target="_blank"><span style="color: black;">Scaling Agile: The Value of Independent Testing</span></a></u></div>
</li>
<li><div style="text-align: left;">
<u><span style="color: black;"><a href="http://se-thoughtograph.blogspot.in/2015/05/scaling-agile-succeeding-in-release.html" target="_blank">Scaling Agile: Succeeding in Release Management</a> </span></u></div>
</li>
<li><div style="text-align: left;">
<u><a href="http://se-thoughtograph.blogspot.in/2015/05/scaling-agile-disastrous-software.html" target="_blank">Scaling Agile: Disastrous Software Factories</a></u></div>
</li>
<li><div style="text-align: left;">
<u><a href="http://se-thoughtograph.blogspot.in/2015/05/scaling-agile-transitioning-to-kanban.html" target="_blank">Scaling Agile: Transitioning to Kanban</a></u></div>
</li>
</span></ol>
<ol style="text-align: left;"><span style="color: black;"><span style="color: black;"></span></span></ol>
</div>
<span style="color: black;">
</span><em></em></div>
</div>
Raja Bavanihttp://www.blogger.com/profile/03107697584076683320noreply@blogger.com1tag:blogger.com,1999:blog-356516183452551110.post-16167833741255610232015-05-30T23:54:00.002-07:002015-06-01T06:40:55.752-07:00Scaling Agile: Transitioning to Kanban<div dir="ltr" style="text-align: left;" trbidi="on">
<div align="center" style="text-align: left;">
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgQ4XFG_muEAC60goshNdBxn56432XdVg6RhQ_xl4o3P1t1nCx5ikdjuFHX2dII6N199qhzJHoDnCOgxPwRgJh_p6cy8BaK4886PiE08-UYRSdCAB6GVObhmzoDa02mBHanFENNidr_fVo/s1600/TKB.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="220" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgQ4XFG_muEAC60goshNdBxn56432XdVg6RhQ_xl4o3P1t1nCx5ikdjuFHX2dII6N199qhzJHoDnCOgxPwRgJh_p6cy8BaK4886PiE08-UYRSdCAB6GVObhmzoDa02mBHanFENNidr_fVo/s400/TKB.jpg" width="400" /></a></div>
<div align="center">
<span style="color: black;"></span> </div>
<span style="color: black;">Large-scale
agile projects include multiple feature teams working in rhythm over short
iterations or time-boxes one after the other.<span style="mso-spacerun: yes;">
</span>That happens when features for the first release are coded, integrated
and tested in time-boxes. <span style="mso-spacerun: yes;"> </span>When the first
release or a subsequent release goes to production, we see an emerging need for
forming one or two teams to work on daily iterations unlike 2 or 3-week iterations
of feature teams.<span style="mso-spacerun: yes;"> </span>This is because of the
need to provide timely support and daily fixes to product owners and end-users.<span style="mso-spacerun: yes;"> </span>Here, the transition from iteration-based or
Sprint-based development into Kanban becomes essential.<span style="mso-spacerun: yes;"> </span>Obviously, those one or two teams that
support end-users cannot afford to make their stakeholders wait for 2 or 3
weeks for defect fixes and patches. They need to be even more agile, and they
need to respond daily by fixing critical issues and responding to end-users. <span style="mso-spacerun: yes;"> </span>Potentially, they must be able to understand
and implement Kanban.</span></div>
<div style="text-align: left;">
</div>
<div style="text-align: left;">
<span style="color: black;">Transitioning
to Kanban comes with two key aspects. The first one is about learning and
implementing Kanban and the second one is about aligning the engineering
processes such as configuration management, build and release management, tools
etc.</span></div>
<div style="text-align: left;">
</div>
<div style="text-align: left;">
<span style="color: black;">When
you and your team are transitioning to Kanban, you need to do a good mix of
unlearning and learning.<span style="mso-spacerun: yes;"> </span>This is
because, when you do Kanban, you are not going to do Sprint Planning or Story
Point Estimation.<span style="mso-spacerun: yes;"> </span>You are not going to
do daily stand-ups with the anticipation of delivering something at the end of
the Sprint. You are going to learn about visual boards or more specifically
Kanban boards. You are going to experience how team members ‘pull’ work
items.<span style="mso-spacerun: yes;"> </span>You are going to learn the
concept of ‘Work in Progress’ and WIP Limit.<span style="mso-spacerun: yes;">
</span><span style="mso-spacerun: yes;"> </span>And of course, when you work with
virtual teams, you will need tools that support distributed Kanban teams and
offer electronic visual displays.</span></div>
<div style="text-align: left;">
</div>
<div style="text-align: left;">
<span style="color: black;">Coming
to the second aspect on engineering processes, the first step is to think
through configuration management.<span style="mso-spacerun: yes;"> </span>How
are you going to establish configuration management across multiple feature
teams that synchronously work on 2 or 3-week iterations and Kanban based production
support teams? An obvious solution is to have 2 branches – one for ongoing
development and the other for production support activities. How frequently are
you going to merge? And what is going to be the efforts involved in merging
them together?<span style="mso-spacerun: yes;"> </span>Next, how are you going
to perform independent validation or testing in the new model? What are going
to be the revised overheads or estimates? Finally, how will this new model
impact your build and release management process?</span></div>
<div style="text-align: left;">
</div>
<div style="text-align: left;">
<span style="color: black;">Are
you looking at all these aspects while transitioning to Kanban?<span style="mso-spacerun: yes;"> </span>Are there any other key factors or issues?</span><br />
</div>
<div style="text-align: left;">
<div style="text-align: left;">
<strong><u><span style="color: black;">Related Posts:</span></u></strong></div>
<span style="color: black;"></span><br />
<ol style="text-align: left;">
<li><div style="text-align: left;">
<u><a href="http://se-thoughtograph.blogspot.in/2014/12/scaling-agile-what-do-architects-deliver.html" target="_blank"><span style="color: black;">Scaling Agile: What Do Architects Deliver?<o:p></o:p></span></a></u></div>
</li>
<li><div style="text-align: left;">
<u><a href="http://se-thoughtograph.blogspot.in/2015/02/scaling-agile-architecting-your-team.html" target="_blank"><span style="color: black;">Scaling Agile: Architecting Your Agile Team<o:p></o:p></span></a></u></div>
</li>
<li><div style="text-align: left;">
<u><a href="http://se-thoughtograph.blogspot.in/2015/02/scaling-agile-feeding-your-feature-teams.html" target="_blank"><span style="color: black;">Scaling Agile: Feeding Your Feature Teams<o:p></o:p></span></a></u></div>
</li>
<li><div style="text-align: left;">
<u><a href="http://se-thoughtograph.blogspot.in/2013/01/software-architecture-and-design-in.html" target="_blank"><span style="color: black;">Software Architecture and Design in Agile World<o:p></o:p></span></a></u></div>
</li>
<li><div style="text-align: left;">
<u><a href="http://se-thoughtograph.blogspot.in/2015/03/scaling-agile-emerging-architecture-and.html" target="_blank"><span style="color: black;">Scaling Agile: Emerging Architecture and Technical Debt</span></a></u></div>
</li>
<li><div style="text-align: left;">
<u><a href="http://se-thoughtograph.blogspot.com/2015/05/scaling-agile-value-of-independent.html" target="_blank"><span style="color: black;">Scaling Agile: The Value of Independent Testing</span></a></u></div>
</li>
<li><div style="text-align: left;">
<u><a href="http://se-thoughtograph.blogspot.in/2015/05/scaling-agile-hardening-sprint-and_31.html" target="_blank"><span style="color: black;">Scaling Agile: Hardening Sprint and the Problem of Procrastination</span></a></u></div>
</li>
<li><div style="text-align: left;">
<u><span style="color: black;"><a href="http://se-thoughtograph.blogspot.in/2015/05/scaling-agile-succeeding-in-release.html" target="_blank">Scaling Agile: Succeeding in Release Management</a> </span></u></div>
</li>
<li><div style="text-align: left;">
<u><a href="http://se-thoughtograph.blogspot.in/2015/05/scaling-agile-disastrous-software.html" target="_blank">Scaling Agile: Disastrous Software Factories</a></u></div>
</li>
</ol>
</div>
</div>
Raja Bavanihttp://www.blogger.com/profile/03107697584076683320noreply@blogger.com0tag:blogger.com,1999:blog-356516183452551110.post-17979076181177312692015-05-23T06:10:00.001-07:002015-06-01T06:40:29.400-07:00Scaling Agile: Disastrous Software Factories<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgtfteW001vig24YK1YaoqTPsA0tPiReSDlHGruYWnzZeNvfTKgceTdXMFaeY5nrMDHKm6_mvkgDq8MtnCXJkhXVIv1Ye92vFdZkY4R9jFKvUMoNWdrtHN7qf1wwsELK9i12xiBbfDpxnM/s1600/DSF.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="241" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgtfteW001vig24YK1YaoqTPsA0tPiReSDlHGruYWnzZeNvfTKgceTdXMFaeY5nrMDHKm6_mvkgDq8MtnCXJkhXVIv1Ye92vFdZkY4R9jFKvUMoNWdrtHN7qf1wwsELK9i12xiBbfDpxnM/s400/DSF.jpg" width="400" /></a></div>
<div align="center" style="text-align: left;">
</div>
<div class="MsoNormal" style="margin: 0in 0in 0pt; mso-layout-grid-align: none; text-align: left;">
<span style="color: black;">Quite
often, we hear the buzz word ‘Software Factory’ in Scaling Agile conversations
and conference sessions.<span style="mso-spacerun: yes;"> </span>Those who
promote or sell the concept of ‘Scaling Agile’ attempt to indoctrinate their
audience with the belief that Scaling Agile is a definitive way to setup an
Agile Software Factory. Yes, when you add ‘Agile’ to ‘Software Factory’, it
becomes even more attractive.<span style="mso-spacerun: yes;"> </span>While
there are several case studies and white papers about how to go about setting
up an Agile Software Factory, the challenges involved in doing so are
numerous.<span style="mso-spacerun: yes;"> </span>Because of such challenges and
several other reasons, initiatives to setup such factories become
disastrous.<span style="mso-spacerun: yes;"> </span>Why do such disasters
happen? This post is to bring out a list of reasons.<span style="mso-spacerun: yes;"> </span>Here is the list.</span></div>
<ol style="text-align: left;">
<li><div class="MsoNormal" style="margin: 0in 0in 0pt; mso-layout-grid-align: none; text-align: left;">
<span style="color: black;"><strong>Vision and Leadership Commitment</strong> - Lack of vision and leadership commitment is a primary reason.<span style="mso-spacerun: yes;"> </span>Well, in many projects and programs there will be vision and leadership.<span style="mso-spacerun: yes;"> </span>However, when the vision is not set right and shared among all stakeholders including team members and when there is no inspiring leadership and leadership commitment to support and nurture the vision, results can be disastrous.</span></div>
</li>
<li><div class="MsoNormal" style="margin: 0in 0in 0pt; mso-layout-grid-align: none; text-align: left;">
<!--[endif]--><span style="color: black;"><strong>Investment in Coaching</strong> - Not investing in Agile Coaching is a definite recipe for disasters.<span style="mso-spacerun: yes;"> </span>In large programs it is necessary to invest in coaching at different levels right from teams to middle and senior management.<span style="mso-spacerun: yes;"> </span>Obviously, this means that you need a coachable ecosystem. Learnability is important. When there is rigid mindset and inability to learn and collaborate, cultural issues fuel disasters.</span></div>
</li>
<li><div class="MsoNormal" style="margin: 0in 0in 0pt; mso-layout-grid-align: none; text-align: left;">
<!--[endif]--><span style="color: black;"><strong>Focus on Cost Savings Only</strong> - Just because your ultimate goal is to set up a software factory, your focus cannot revolve around cost savings all the time.<span style="mso-spacerun: yes;"> </span>You cannot optimize your team members just as you optimize your machines in the production line.<span style="mso-spacerun: yes;"> </span>You cannot replace them just as you replace your machines. You cannot operate in shifts to save costs. You cannot forget about people and their emotions.<span style="mso-spacerun: yes;"> </span>Obviously, ‘that’ factory is different from ‘this’ factory.</span></div>
</li>
<li><div class="MsoNormal" style="margin: 0in 0in 0pt; mso-layout-grid-align: none; text-align: left;">
<!--[endif]--><span style="color: black;"><strong>Physical Infrastructure</strong> – Lack of infrastructure including open workspace, video conferencing, phones, meeting rooms, computers with necessary configuration, network connectivity, tools, etc., is the next reason for such disasters.</span></div>
</li>
<li><div class="MsoNormal" style="margin: 0in 0in 0pt; mso-layout-grid-align: none; text-align: left;">
<!--[endif]--><span style="color: black;"><strong>Intellectual and Emotional Infrastructure</strong> - Intellectual infrastructure is about skills, competencies, expertise, special groups, knowledge forums, technical excellence and so on. Emotional infrastructure is about team bonding, trusted leadership and the likes that enhance the feeling of belonging.<span style="mso-spacerun: yes;"> </span>When intellectual and emotional infrastructure are not adequate you will see symptoms such as <span style="mso-spacerun: yes;"> </span>loopholes in process implementation, <span style="mso-spacerun: yes;"> </span>poor or weak automation strategy, poor execution, lack of technical excellence, etc. leading to pool quality.</span></div>
</li>
<li><div class="MsoNormal" style="margin: 0in 0in 0pt; mso-layout-grid-align: none; text-align: left;">
<!--[endif]--><span style="color: black;"><strong>Inclusion</strong> - In virtual teams or geographically distributed teams, lack of inclusion can create chaos. We know that there are several challenges in distributed agile.<span style="mso-spacerun: yes;"> </span>When there is lack of inclusion, you see one site dictating or directing the other sites, double standards, and so on.</span></div>
</li>
<li><div class="MsoNormal" style="margin: 0in 0in 0pt; mso-layout-grid-align: none; text-align: left;">
<!--[endif]--><span style="color: black;"><strong>Governance</strong> - Though this comes as seventh, it is as significant as the first reason.<span style="mso-spacerun: yes;"> </span>Governance can make or break things.<span style="mso-spacerun: yes;"> </span>Collaborative, inclusive and supportive governance teams can do timely course correction and deliver value to customers.<span style="mso-spacerun: yes;"> </span>When the members of Governance team do not have a unified agenda, they may pull each other in different directions. That is disastrous.</span></div>
</li>
</ol>
<div class="MsoNormal" style="margin: 0in 0in 0pt; mso-layout-grid-align: none; text-align: left;">
<span style="color: black;">Do you
see your team stretching or burning out? Is that becoming a trend? Are your
team members demotivated? Are you calling your project or program a Software
Factory? Probably you do not sit through with your team members and empathize
on what is going on. You are not identifying the root causes. Revisit the seven
reasons mentioned in this blog and see how you can make some course correction
to come out of a disastrous Software Factory and make it a success. </span></div>
<div class="MsoNormal" style="margin: 0in 0in 0pt; mso-layout-grid-align: none; text-align: left;">
<span style="color: black;"><span style="mso-spacerun: yes;"> </span><o:p></o:p></span></div>
<div style="text-align: left;">
<span style="color: black;">
</span></div>
<div style="text-align: left;">
<u><span style="color: black;"><div style="text-align: left;">
<div style="text-align: left;">
<span style="color: black;"><u><span style="color: black;"><strong>Related Posts:</strong></span></u></span></div>
<span style="color: black;"><span style="color: black;"></span></span><br />
<ol style="text-align: left;"><span style="color: black;">
<li><div style="text-align: left;">
<u><a href="http://se-thoughtograph.blogspot.in/2014/12/scaling-agile-what-do-architects-deliver.html" target="_blank"><span style="color: black;">Scaling Agile: What Do Architects Deliver?<o:p></o:p></span></a></u></div>
</li>
<li><div style="text-align: left;">
<u><a href="http://se-thoughtograph.blogspot.in/2015/02/scaling-agile-architecting-your-team.html" target="_blank"><span style="color: black;">Scaling Agile: Architecting Your Agile Team<o:p></o:p></span></a></u></div>
</li>
<li><div style="text-align: left;">
<u><a href="http://se-thoughtograph.blogspot.in/2015/02/scaling-agile-feeding-your-feature-teams.html" target="_blank"><span style="color: black;">Scaling Agile: Feeding Your Feature Teams<o:p></o:p></span></a></u></div>
</li>
<li><div style="text-align: left;">
<u><a href="http://se-thoughtograph.blogspot.in/2013/01/software-architecture-and-design-in.html" target="_blank"><span style="color: black;">Software Architecture and Design in Agile World<o:p></o:p></span></a></u></div>
</li>
<li><div style="text-align: left;">
<u><a href="http://se-thoughtograph.blogspot.in/2015/03/scaling-agile-emerging-architecture-and.html" target="_blank"><span style="color: black;">Scaling Agile: Emerging Architecture and Technical Debt</span></a></u></div>
</li>
<li><div style="text-align: left;">
<u><a href="http://se-thoughtograph.blogspot.com/2015/05/scaling-agile-value-of-independent.html" target="_blank"><span style="color: black;">Scaling Agile: The Value of Independent Testing</span></a></u></div>
</li>
<li><div style="text-align: left;">
<u><a href="http://se-thoughtograph.blogspot.in/2015/05/scaling-agile-hardening-sprint-and_31.html" target="_blank"><span style="color: black;">Scaling Agile: Hardening Sprint and the Problem of Procrastination</span></a></u></div>
</li>
<li><div style="text-align: left;">
<u><a href="http://se-thoughtograph.blogspot.in/2015/05/scaling-agile-succeeding-in-release.html" target="_blank"><span style="color: black;">Scaling Agile: Succeeding in Release Management</span></a></u></div>
</li>
<li><div style="text-align: left;">
<u><a href="http://se-thoughtograph.blogspot.in/2015/05/scaling-agile-transitioning-to-kanban.html" target="_blank"><span style="color: black;">Scaling Agile: Transitioning to Kanban</span></a></u></div>
</li>
</span></ol>
</div>
</span></u></div>
</div>
Raja Bavanihttp://www.blogger.com/profile/03107697584076683320noreply@blogger.com0tag:blogger.com,1999:blog-356516183452551110.post-51005154287641249182015-05-16T04:58:00.000-07:002015-06-01T06:39:22.643-07:00Scaling Agile: Succeeding in Release Management<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: center;">
</div>
<div style="text-align: center;">
<span style="color: black;">
</span><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiuA20di13y_6tSvCN4xz3vN687-ge1eRPpa5IT4psdPe8rezpvi1LwPGvvMcrGldH0pX2TtPeft6-RRJCNiZzOXEJZVWaUbs0fUcbO1AslgaqLdIvreRvKVRj_QsrDS6qtWfMOgtBSn8M/s1600/SARM.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="237" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiuA20di13y_6tSvCN4xz3vN687-ge1eRPpa5IT4psdPe8rezpvi1LwPGvvMcrGldH0pX2TtPeft6-RRJCNiZzOXEJZVWaUbs0fUcbO1AslgaqLdIvreRvKVRj_QsrDS6qtWfMOgtBSn8M/s400/SARM.jpg" width="400" /></a><br />
<div class="separator" style="clear: both; text-align: center;">
<span style="color: black;"></span><br /></div>
<span style="color: black;">This
post on ‘Scaling Agile’ is to present a list of critical factors to succeed in
release management.<span style="mso-spacerun: yes;"> </span>What makes
large-scale Agile teams capable of ensuring successful product releases? Here
is the list.</span><br />
<ol style="text-align: left;">
<li><div class="MsoNormal" style="margin: 0in 0in 0pt; mso-layout-grid-align: none; text-align: left;">
<span style="color: black;"><strong>Roadmap and theme for releases</strong> – Have a road map and theme for all releases or as many you can envisage.<span style="mso-spacerun: yes;"> </span>This is one of the key responsibilities of product managers and sponsors.</span></div>
</li>
<li><div class="MsoNormal" style="margin: 0in 0in 0pt; mso-layout-grid-align: none; text-align: left;">
<span style="color: black;"><strong>Tech debt management</strong> -<span style="mso-spacerun: yes;"> </span>In addition to having measurable Definition of Done and Acceptance Criteria to measure the success of Sprints, have a consistent focus on technical debt management.</span></div>
</li>
<li><div class="MsoNormal" style="margin: 0in 0in 0pt; mso-layout-grid-align: none; text-align: left;">
<span style="color: black;"><strong>Don’t let a hardening Sprint result in a chaos!</strong><span style="mso-spacerun: yes;"> </span>- Plan hardening Sprint well and execute them to preserve the integrity of your product release.<span style="mso-spacerun: yes;"> </span>Don’t let a hardening sprint result in a big mess leading to an unexpected upsurge of defects.</span></div>
</li>
<li><div class="MsoNormal" style="margin: 0in 0in 0pt; mso-layout-grid-align: none; text-align: left;">
<span style="color: black;"><strong>Test Automation</strong> – The strength or weakness of test automation will reflect directly on the team experience, challenges and results of release management.<span style="mso-spacerun: yes;"> </span>Keep this in mind.</span></div>
</li>
<li><div class="MsoNormal" style="margin: 0in 0in 0pt; mso-layout-grid-align: none; text-align: left;">
<span style="color: black;"><strong>Risk-based Testing</strong> – It is important to focus on risk-based testing by identifying risk prone areas or epics or modules and testing them first.</span></div>
</li>
<li><div class="MsoNormal" style="margin: 0in 0in 0pt; mso-layout-grid-align: none; text-align: left;">
<span style="color: black;"><strong>Continuous Integration</strong> - You may have continuous integration working very well in development and staging environment. <span style="mso-spacerun: yes;"> </span>Make sure that continuous integration is applied in other environments too (e.g. Testing, User Acceptance, and Production).<span style="mso-spacerun: yes;"> </span>When you don’t do this, you are going to carry out several manual steps to complete integration. That is going to be time consuming and error prone.</span></div>
</li>
<li><div class="MsoNormal" style="margin: 0in 0in 0pt; mso-layout-grid-align: none; text-align: left;">
<span style="color: black;"><strong>Continuous Delivery and DevOps</strong> – Do you want to increase the ‘speed-to-deploy’ in product environment? Think two things – Continuous Delivery and DevOps.<span style="mso-spacerun: yes;"> </span>These will improve efficiency and result in cost savings.</span></div>
</li>
<li><div class="MsoNormal" style="margin: 0in 0in 0pt; mso-layout-grid-align: none; text-align: left;">
<span style="color: black;"><strong>Defect Management</strong> - Is your defect management process helping you in slicing and dicing data to understand product quality? Does it allow you to predict? Does it allow you to spot missing test cases?<span style="mso-spacerun: yes;"> </span>Or are you relying on a basic defect management process that helps you understand defects by priority and severity alone?<span style="mso-spacerun: yes;"> </span>Effective (and efficient) defect management is an enabler for release management.</span></div>
</li>
<li><div class="MsoNormal" style="margin: 0in 0in 0pt; mso-layout-grid-align: none; text-align: left;">
<span style="color: black;"><strong>Dependency Management</strong> – Understand all dependencies, categorize them and manage them effectively. Do not allow any dependency to create a big surprise and impact release schedule or quality.</span></div>
</li>
<li><div class="MsoNormal" style="margin: 0in 0in 0pt; mso-layout-grid-align: none; text-align: left;">
<span style="color: black;"><strong>Communication & Coordination and Stakeholder Management</strong> – These are the non-technical but essential aspects not only for release management but for all software engineering activities. Make sure that the way you communicate and coordinate among teams enables osmotic communication. Also, keep your stakeholders informed of what to expect and how release management activities are progressing. Manage their expectations well.</span></div>
</li>
</ol>
<div class="MsoNormal" style="margin: 0in 0in 0pt; mso-layout-grid-align: none; text-align: left;">
</div>
<span style="color: black;"><div style="text-align: left;">
<div style="text-align: left;">
<span style="color: black;"><strong><u><span style="color: black;">Related Posts:</span></u></strong></span></div>
<br />
<ol style="text-align: left;"><span style="color: black;">
<li><div style="text-align: left;">
<u><a href="http://se-thoughtograph.blogspot.in/2014/12/scaling-agile-what-do-architects-deliver.html" target="_blank"><span style="color: black;">Scaling Agile: What Do Architects Deliver?<o:p></o:p></span></a></u></div>
</li>
<li><div style="text-align: left;">
<u><a href="http://se-thoughtograph.blogspot.in/2015/02/scaling-agile-architecting-your-team.html" target="_blank"><span style="color: black;">Scaling Agile: Architecting Your Agile Team<o:p></o:p></span></a></u></div>
</li>
<li><div style="text-align: left;">
<u><a href="http://se-thoughtograph.blogspot.in/2015/02/scaling-agile-feeding-your-feature-teams.html" target="_blank"><span style="color: black;">Scaling Agile: Feeding Your Feature Teams<o:p></o:p></span></a></u></div>
</li>
<li><div style="text-align: left;">
<u><a href="http://se-thoughtograph.blogspot.in/2013/01/software-architecture-and-design-in.html" target="_blank"><span style="color: black;">Software Architecture and Design in Agile World<o:p></o:p></span></a></u></div>
</li>
<li><div style="text-align: left;">
<u><a href="http://se-thoughtograph.blogspot.in/2015/03/scaling-agile-emerging-architecture-and.html" target="_blank"><span style="color: black;">Scaling Agile: Emerging Architecture and Technical Debt</span></a></u></div>
</li>
<li><div style="text-align: left;">
<u><a href="http://se-thoughtograph.blogspot.com/2015/05/scaling-agile-value-of-independent.html" target="_blank"><span style="color: black;">Scaling Agile: The Value of Independent Testing</span></a></u></div>
</li>
<li><div style="text-align: left;">
<u><a href="http://se-thoughtograph.blogspot.in/2015/05/scaling-agile-hardening-sprint-and_31.html" target="_blank"><span style="color: black;">Scaling Agile: Hardening Sprint and the Problem of Procrastination</span></a></u></div>
</li>
<li><div style="text-align: left;">
<u><a href="http://se-thoughtograph.blogspot.in/2015/05/scaling-agile-disastrous-software.html" target="_blank"><span style="color: black;">Scaling Agile: Disastrous Software Factories</span></a></u></div>
</li>
<li><div style="text-align: left;">
<u><a href="http://se-thoughtograph.blogspot.in/2015/05/scaling-agile-transitioning-to-kanban.html" target="_blank"><span style="color: black;">Scaling Agile: Transitioning to Kanban</span></a></u></div>
</li>
</span></ol>
</div>
<ol style="text-align: left;"></ol>
</span><ol style="text-align: left;"></ol>
<div style="text-align: left;">
</div>
</div>
</div>
Raja Bavanihttp://www.blogger.com/profile/03107697584076683320noreply@blogger.com0