tag:blogger.com,1999:blog-78877342024-03-12T21:46:02.887-04:00Phi_laks_ophyNeel Lakshminarayanhttp://www.blogger.com/profile/00449351271095037254noreply@blogger.comBlogger24125tag:blogger.com,1999:blog-7887734.post-66475046515890630812020-03-22T18:58:00.001-04:002020-03-22T18:58:47.883-04:00Your Daily Standup Should be Boring<div dir="ltr" style="text-align: left;" trbidi="on">
<br />
<div class="MsoNormal">
If you are a Lean/Agile team you probably have a daily
standup / scrum that you are trying to complete in 15 minutes or less. You
might even be “standing up” in that effort. You are most likely failing, and
your average standup runs for half an hour or longer. And I’m not even counting
the “meeting after the standup”.<span style="mso-spacerun: yes;"> </span>You
have tried various techniques the plethora agile books prescribe, and it does
work for a week or two but then just falls back to the old pattern. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<i>Have you wondered why? <o:p></o:p></i></div>
<div class="MsoNormal">
<i><br /></i></div>
<div class="MsoNormal">
The key is to first understand why you even need the standup
in the first place. Then work assiduously to eliminate every single reason to
have the standup, but not stop it.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
You are then likely to find a couple of things:<o:p></o:p><br />
<br /></div>
<div class="MsoListParagraphCxSpFirst" style="mso-list: l2 level1 lfo1; text-indent: -.25in;">
<div style="text-align: left;">
</div>
<span style="font-family: "symbol"; text-indent: -0.25in;"><span style="mso-list: Ignore;">· </span></span><span style="text-indent: -0.25in;">There’s not much to talk about at the standup.
In fact, it’s probably boring</span><br /><span style="font-family: "symbol"; text-indent: -0.25in;"><span style="mso-list: Ignore;">·<span style="font-family: "times new roman"; font-size: 7pt; font-stretch: normal; font-variant-east-asian: normal; font-variant-numeric: normal; line-height: normal;"> </span></span></span><span style="text-indent: -0.25in;">Your standups are getting done in 15 minutes or
less</span><o:p></o:p></div>
<div class="MsoListParagraphCxSpFirst" style="mso-list: l2 level1 lfo1; text-indent: -.25in;">
<span style="text-indent: -0.25in;"><br /></span></div>
<div class="MsoListParagraphCxSpLast" style="mso-list: l2 level1 lfo1; text-indent: -.25in;">
<o:p></o:p></div>
<div class="MsoNormal">
This is a great state to aspire – a non-eventful standup
without drama. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<i>How do you get to this stage?<o:p></o:p></i><br />
<i><br /></i></div>
<div class="MsoNormal">
Let’s first look at what’s happening in the standup today.
What topics are being discussed? Very likely:<br />
<br />
<br />
<ul style="text-align: left;">
<li>Status</li>
<li>Problems</li>
<li>Solutions</li>
<li>Decisions</li>
</ul>
<br />
So, that’s what’s eating time in the standup. The crucial question
to ask is why is this coming up in the standup? Obvious answer – because people
didn’t raise it earlier. Why didn’t they raise it earlier? Your team should be
raising the issue when the event happened. Not wait till the standup.</div>
<div class="MsoNormal">
<o:p></o:p><br />
<br /></div>
<div class="MsoNormal">
Thus, the vital improvement to be implemented here is to
raise issues when the event occurred. Not hold back till the standup which is
usually a once a day event.<o:p></o:p><br />
<br /></div>
<div class="MsoNormal">
<i>Why is this important?<o:p></o:p></i><br />
<i><br /></i></div>
<div class="MsoNormal">
If you are thinking that we are looking to save a few
minutes at the standup – that’s not the driver. Although, that is desirable,
that’s not the main goal. The real cost of an extended standup is not the extra
minutes, but:<o:p></o:p><br />
<br /></div>
<div class="MsoListParagraphCxSpFirst" style="mso-list: l0 level1 lfo3; text-indent: -.25in;">
<!--[if !supportLists]--><o:p></o:p><br />
<span style="font-family: "symbol"; text-indent: -0.25in;"><span style="mso-list: Ignore;">·<span style="font-family: "times new roman"; font-size: 7pt; font-stretch: normal; font-variant-east-asian: normal; font-variant-numeric: normal; line-height: normal;">
</span></span></span><span style="text-indent: -0.25in;">Disruption to the flow by not resolving issues
soon as they occur</span><br /><span style="font-family: "symbol"; text-indent: -0.25in;"><span style="mso-list: Ignore;">·<span style="font-family: "times new roman"; font-size: 7pt; font-stretch: normal; font-variant-east-asian: normal; font-variant-numeric: normal; line-height: normal;">
</span></span></span><span style="text-indent: -0.25in;">Cost of delay by waiting for the standup</span></div>
<div class="MsoListParagraphCxSpFirst" style="mso-list: l0 level1 lfo3; text-indent: -.25in;">
<span style="text-indent: -0.25in;"><br /></span></div>
<div class="MsoListParagraphCxSpLast" style="mso-list: l0 level1 lfo3; text-indent: -.25in;">
<o:p></o:p></div>
<div class="MsoNormal">
And if you put in processes in place to resolve problems
when they occur, empower people to make decisions quickly, there’s going to be
very little to discuss at the standup. Your standup might be boring. A standup
that’s boring for the right reasons is a good thing.<o:p></o:p><br />
<br /></div>
<div class="MsoNormal">
Work hard to make the standup boring. But don’t eliminate
it. What remains to be discussed in the standup now is probably what should be
discussed in the standup.<o:p></o:p></div>
<br /></div>
Neel Lakshminarayanhttp://www.blogger.com/profile/00449351271095037254noreply@blogger.com1tag:blogger.com,1999:blog-7887734.post-17624174107413901522018-03-03T06:46:00.001-05:002018-03-04T12:55:18.699-05:00Why your company may need OKRs<div dir="ltr" style="text-align: left;" trbidi="on">
<br />
<h3 style="text-align: left;">
OKR? What's that?</h3>
<div>
Glad you asked. It's a goal setting framework. It stands for "Objectives & Key Results". Here is an example:</div>
<div>
<br /></div>
<div style="text-align: left;">
<b>Objective</b></div>
<div style="text-align: left;">
<b><br /></b></div>
<div>
Grow company revenues</div>
<div>
<br /></div>
<div>
<b>Key Results</b></div>
<ol>
<li>Hit global annual revenue of $150 million</li>
<li>Achieve 100% YOY sales growth in North America</li>
<li>Increase the average deal size by 25%</li>
</ol>
<div>
Notice how it has two key elements?</div>
<div>
<br /></div>
<div>
<b>Objective</b>: Your goal, your dream, your vision. Its <b><i>What</i> </b>you want to get done</div>
<div>
<br /></div>
<div>
<b>Key Result</b>: A very specific, measurable way to show <i><b>How </b></i>you are going to get it done</div>
<div>
<br /></div>
<h3 style="text-align: left;">
That looks like an MBO! I've been doing them for a while and I don't think I like them. I'm outta here!</h3>
<div>
<br /></div>
<div>
Wait. It is built on MBO's and KPI's but there are important differences. Tweaks really, but very key ones tuned to suit contemporary management and product development practices</div>
<div>
<br /></div>
<h3 style="text-align: left;">
<i>But first, some history</i></h3>
<div>
<br /></div>
<div>
OKR's were first implemented by Andy Grove at Intel. He built upon the concept of MBO (Management by Objectives). Then John Doerr, who watched Andy use it at Intel to great effect, introduced it at Google, and helped Google become Google. And that's how OKR's became famous. A lot of companies use them now. And Google still uses them.</div>
<div>
<br /></div>
<h3 style="text-align: left;">
So, how are OKR's different from MBO's? </h3>
<div>
<br /></div>
<div>
They differ fundamentally in three ways - Purpose, Transparency and Cadence.</div>
<div>
<br /></div>
<div>
<br /></div>
<table style="-evernote-table: true; border-collapse: collapse; margin-left: 0px; table-layout: fixed; width: 100%;"><tbody>
<tr><td style="border-color: rgb(211,211,211); border-style: solid; border-width: 1px; margin: 0px; padding: 10px; width: 33.40732519422864%;"><div>
<br /></div>
</td><td style="border-color: rgb(211,211,211); border-style: solid; border-width: 1px; margin: 0px; padding: 10px; width: 33.29633740288568%;"><h4>
MBO</h4>
</td><td style="border-color: rgb(211,211,211); border-style: solid; border-width: 1px; margin: 0px; padding: 10px; width: 33.18534961154273%;"><h4>
OKR</h4>
</td></tr>
<tr><td style="border-color: rgb(211,211,211); border-style: solid; border-width: 1px; margin: 0px; padding: 10px; width: 33.33%;"><h4>
Purpose</h4>
</td><td style="border-color: rgb(211,211,211); border-style: solid; border-width: 1px; margin: 0px; padding: 10px; width: 33.33%;"><div>
<span style="background-color: white; color: #222222; display: inline; float: none; font-family: sans-serif; font-size: 14px; font-style: normal; font-weight: 400; letter-spacing: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">A method for employers/supervisors to manage their subordinates by introducing a set of specific goals. The goals must be achieved 100%. Used to review/reward the employee during the performance review</span></div>
</td><td style="border-color: rgb(211,211,211); border-style: solid; border-width: 1px; margin: 0px; padding: 10px; width: 33.33%;"><div>
A system to prioritize, communicate and get everybody to contribute to what matters most. The goals are stretch goals and employees are not penalized for not meeting them 100%. OKR's are typically not the basis for a performance appraisal</div>
</td></tr>
<tr><td style="border-color: rgb(211,211,211); border-style: solid; border-width: 1px; margin: 0px; padding: 10px; width: 33.33%;"><h4>
Transparency</h4>
</td><td style="border-color: rgb(211,211,211); border-style: solid; border-width: 1px; margin: 0px; padding: 10px; width: 33.33%;"><div>
MBO's are confidential. They are between the manager and the employee</div>
</td><td style="border-color: rgb(211,211,211); border-style: solid; border-width: 1px; margin: 0px; padding: 10px; width: 33.33%;"><div>
OKR's are public. Everybody can and should see everyone else's OKR's</div>
</td></tr>
<tr><td style="border-color: rgb(211,211,211); border-style: solid; border-width: 1px; margin: 0px; padding: 10px; width: 33.33%;"><h4>
Cadence</h4>
</td><td style="border-color: rgb(211,211,211); border-style: solid; border-width: 1px; margin: 0px; padding: 10px; width: 33.33%;"><div>
Set yearly. Very waterfallish in nature</div>
</td><td style="border-color: rgb(211,211,211); border-style: solid; border-width: 1px; margin: 0px; padding: 10px; width: 33.33%;"><div>
Set monthly/quarterly. Lean/agile in nature</div>
</td></tr>
</tbody></table>
<div>
<br /></div>
<div>
<br /></div>
<h3 style="text-align: left;">
Okay. Why should my company or team have OKRs?</h3>
<div>
<br /></div>
<div>
Here are 10 Reasons:</div>
<div>
<br /></div>
<ol>
<li>It's a <b>communication</b> tool. It's a system to communicate what's important to the company (or team) and what's not. Now, if you are the CEO or leader of team, you know that effective communication is one of the hardest things to do. This helps. A lot</li>
<li>It promotes <b>transparency</b>. Ever wondered what matters to your CEO, company, a key executive or team? Now you know - because everyone's Objective, Key Results and grades are visible to all.</li>
<li>It <b>empowers</b>. Now that you can see everyone's OKR's, you can choose to help. Especially if it's in your area of expertize. Your objectives don't have to be handed down Top Down anymore. You can add your own. And sometimes, your objectives are so cool, that they may become a department or company objective in the near future. How empowering is that? You just made a difference!</li>
<li>It's <b>aspirational</b>. OKR's are stretch goals. <span style="background-color: white; text-align: left; widows: 1;"><span style="color: #222222;">Achieving 65% of the impossible is better than 100% of the ordinary. Even if you fail on a stretch goal, you are bound to have learned something valuabl</span>e. They are like little moon shots..</span></li>
<li>They promote <b>innovation</b>. Sure, you can have "business as usual" objectives. But you can have aspirational OKRs too. They give you permission to fail. And if you haven't failed recently, you haven't tried hard enough</li>
<li>It <b>engages</b> your team. How? Just like you can have individual OKR's, you can have team OKRs too</li>
<li>It sets <b>direction</b>. You can tell where your company is going. It's like a North Star, a beacon - constantly guiding you.</li>
<li>It <b>prioritizes</b>. You know what matters and what doesn't. Prioritization is key to execution.</li>
<li>It sets <b>alignment</b>. Now that you have direction and priorities, you can all work on the same thing. This leads to better outcomes</li>
<li>It's <b>data</b>. Good OKR's provide objective, quantifiable data points about what's being done and how well it's being done. If you are a Data Driven company, you wouldn't want to miss out on this key metric</li>
</ol>
<div>
<br /></div>
<div>
And they solve world hunger. OK, now I'm exaggerating. But if we do want to solve hunger, we should start with OKRs. </div>
<div>
<br /></div>
<div>
Seriously</div>
</div>
Neel Lakshminarayanhttp://www.blogger.com/profile/00449351271095037254noreply@blogger.comtag:blogger.com,1999:blog-7887734.post-54118205514743127522016-04-09T10:55:00.001-04:002016-04-11T11:47:35.237-04:00Top 10 Kanban Practices<div dir="ltr" style="text-align: left;" trbidi="on">
If you are a team that's been practicing Kanban for a few months, here are a few practices that will make your team more productive.<br />
<br />
<div>
<ol style="font-family: Tahoma; margin-bottom: 0mm; margin-top: 0mm; orphans: 2; text-align: -webkit-auto; widows: 2;">
<li style="color: #010101; font-family: Calibri; font-size: 11pt; margin-left: 5pt; margin-right: 0pt; padding-left: 0pt;"><span style="color: #010101; font-family: "calibri";">Stop starting, Start Finishing. Help your team get a story/feature done, rather than add a new one.</span></li>
<li style="color: #010101; font-family: Calibri; font-size: 11pt; margin-left: 5pt; margin-right: 0pt; padding-left: 0pt;"><span style="color: #010101; font-family: "calibri";">Follow WIP limits. Seeing “RED” on your board should cause discomfort and move the team to fixing it</span></li>
<li style="color: #010101; font-family: Calibri; font-size: 11pt; margin-left: 5pt; margin-right: 0pt; padding-left: 0pt;"><span style="color: #010101; font-family: "calibri";">Work from right to left. If you have the skills, pick the story on the right of the board and help move it towards DONE. Remember, organizations make money when work is done</span></li>
<li style="color: #010101; font-family: Calibri; font-size: 11pt; margin-left: 5pt; margin-right: 0pt; padding-left: 0pt;"><span style="font-size: 11pt;">If a card is spending more time in a column than it should, offer to help . Do not wait for a manager / team lead to bring this up. Also, do not wait for a standup to bring this up. Define a policy in your team on what should happen if a card is spending more time in a column.</span></li>
<li style="color: #010101; font-family: Calibri; font-size: 11pt; margin-left: 5pt; margin-right: 0pt; padding-left: 0pt;"><span style="color: #010101; font-family: "calibri";">If a task/process is not adding value, eliminate it. Do not wait for the retrospective to bring it up.</span></li>
<li style="color: #010101; font-family: Calibri; font-size: 11pt; margin-left: 5pt; margin-right: 0pt; padding-left: 0pt;"><span style="color: #010101; font-family: "calibri";">Update the board to reflect the current state of work at any time (position on the board and who’s working on it). Do not wait for the standup to move a card. The board is a communication tool and it needs to communicate the true status at all times</span></li>
<li style="font-family: Calibri; font-size: 11pt; margin-left: 5pt; margin-right: 0pt; padding-left: 0pt;"><span style="font-family: "calibri";"><span style="font-family: "calibri"; font-size: small;"><span style="font-size: 11pt;">The standup is not a “status report” - the board already conveys the status. Discuss roadblocks / improvement ideas rather than a routine discussion of cards on the board</span></span></span></li>
<li style="font-family: Calibri; font-size: 11pt; margin-left: 5pt; margin-right: 0pt; padding-left: 0pt;"><span style="font-family: "calibri";"><span style="font-family: "calibri"; font-size: small;"><span style="font-size: 11pt;">Have team members take turns running the standup. This will cause them to pay attention to what's going on in the team.</span></span></span></li>
<li style="font-family: Calibri; font-size: 11pt; margin-left: 5pt; margin-right: 0pt; padding-left: 0pt;">Gradually, look to reducing the WIP limit, thus promoting more collaboration.</li>
<li style="color: #010101; font-family: Calibri; font-size: 11pt; margin-left: 5pt; margin-right: 0pt; padding-left: 0pt;"><span style="color: #010101; font-family: "calibri";">Celebrate what got done yesterday.</span></li>
</ol>
</div>
</div>
Neel Lakshminarayanhttp://www.blogger.com/profile/00449351271095037254noreply@blogger.com0tag:blogger.com,1999:blog-7887734.post-63306214064817295862015-08-10T18:15:00.003-04:002015-08-11T10:30:34.391-04:00Why your company may need a Hackathon<div dir="ltr" style="text-align: left;" trbidi="on">
<h3 style="text-align: left;">
</h3>
<h2>
<o:p></o:p></h2>
<div class="MsoNormal" style="margin-bottom: 0.0001pt;">
<div class="separator" style="clear: both; text-align: center;">
<a href="http://mrg.bz/T1ipM1" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://mrg.bz/T1ipM1" height="476" width="640" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<span style="font-family: Tahoma, sans-serif;"><br /></span>
<span style="font-family: Tahoma, sans-serif;"><br /></span>
<span style="font-family: Tahoma, sans-serif;">A Hackathon is a creative problem solving / focused
innovation exercise where people in your company will take a fixed time-out from regular
work to solve problems or suggest new ideas. Participants will form
small groups and code solutions (prototypes). At the end of the Hackathon teams will
demonstrate the solution they've "hacked" together.</span></div>
<div class="MsoNormal" style="margin-bottom: 0.0001pt;">
<span style="font-family: Tahoma, sans-serif;"><br /></span></div>
<h3 style="margin-bottom: 0.0001pt; text-align: left;">
<span style="font-family: Tahoma, sans-serif;">Why does your company need a Hackathon?</span></h3>
<div class="MsoNormal" style="margin-bottom: 0.0001pt;">
<span style="font-family: Tahoma, sans-serif;"><br /></span></div>
<div class="MsoNormal" style="margin-bottom: 0.0001pt;">
<span style="font-family: Tahoma, sans-serif;">The hackathon is a forum to unlock the creative
potential in your team members.<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-bottom: 0.0001pt;">
<br /></div>
<div class="MsoNormal" style="margin-bottom: 0.0001pt;">
<span style="font-family: Tahoma, sans-serif;">If you are a knowledge based company - and who isn't nowadays - the ability to innovate is key to your future. The day to day tasks probably keeps your teams focused on execution but don’t offer much
opportunity to tap into their creativity. The idea is to give your teams the freedom to step outside the constraints for their day-to-day and see what
they can come up with when the ball is in their court. They'll be working on
projects they're excited about, not building something because that's what
they've been told to do.<br />
<br />
As many companies have discovered, it's pretty amazing what can done in a
Hackathon. Often these implementations / ideas turn up to be new business
opportunities. However, events like these are unpredictable. There are no
guarantees, with failures as likely as success. </span></div>
<div class="MsoNormal" style="margin-bottom: 0.0001pt;">
<span style="font-family: Tahoma, sans-serif;"><br /></span></div>
<div class="MsoNormal" style="margin-bottom: 0.0001pt;">
<span style="font-family: Tahoma, sans-serif;"><i>A hackathon is not a panacea
but instead should be part of an overall strategy to spur innovation. </i><br />
<br />
The investment is small and the reward is potentially huge.<br />
<br />
Other Benefits:<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-bottom: 0.0001pt;">
</div>
<ul type="disc">
<li class="MsoNormal"><span style="font-family: "Tahoma","sans-serif"; mso-fareast-font-family: "Times New Roman";">It's
a great team building exercise that also results in tangible outcomes for
the company in terms of solutions and new business opportunities.<o:p></o:p></span></li>
<li class="MsoNormal"><span style="font-family: "Tahoma","sans-serif"; mso-fareast-font-family: "Times New Roman";">It
sends a clear message that you value innovation <o:p></o:p></span></li>
<li class="MsoNormal"><span style="font-family: "Tahoma","sans-serif"; mso-fareast-font-family: "Times New Roman";">Creates
positive energy and helps morale. It’s also a learning experience<o:p></o:p></span></li>
<li class="MsoNormal"><span style="font-family: "Tahoma","sans-serif"; mso-fareast-font-family: "Times New Roman";">Unlocks
the creative potential in our team members<o:p></o:p></span></li>
<li class="MsoNormal"><span style="font-family: "Tahoma","sans-serif"; mso-fareast-font-family: "Times New Roman";">Helps
retain talent. And even helps attract talent (with so many companies doing Hackathons not doing it makes us "uncool")<o:p></o:p></span></li>
</ul>
<div>
<h3 style="text-align: left;">
How it works</h3>
<ol start="1" type="1">
<li class="MsoNormal"><span style="font-family: "Tahoma","sans-serif"; mso-fareast-font-family: "Times New Roman";">Employees suggest and brainstorm some ideas<o:p></o:p></span></li>
<li class="MsoNormal"><span style="font-family: "Tahoma","sans-serif"; mso-fareast-font-family: "Times New Roman";">Employees sign up for the short listed ideas and form small teams<o:p></o:p></span></li>
<li class="MsoNormal"><span style="font-family: "Tahoma","sans-serif"; mso-fareast-font-family: "Times New Roman";">Each
group is given a fixed time to come up with working code<o:p></o:p></span></li>
<li class="MsoNormal"><span style="font-family: "Tahoma","sans-serif"; mso-fareast-font-family: "Times New Roman";">At
the end of the Hackathon, every group
demos their work to all participants as well as management<o:p></o:p></span></li>
</ol>
<div>
<h3 style="text-align: left;">
Some interesting
links on Hackathons</h3>
<h2>
<o:p></o:p></h2>
<div class="MsoNormal" style="margin-bottom: 0.0001pt;">
<br /></div>
<div class="MsoNormal" style="margin-bottom: 0.0001pt;">
<a href="http://www.wired.com/2012/02/ff_hackathons/all/1"><span style="color: blue; font-family: "Tahoma","sans-serif"; mso-fareast-font-family: "Times New Roman";">http://www.wired.com/2012/02/ff_hackathons/all/1</span></a></div>
<div class="MsoNormal" style="margin-bottom: 0.0001pt;">
<a href="http://mashable.com/2010/06/30/hackathons/"><span style="color: blue; font-family: "Tahoma","sans-serif"; mso-fareast-font-family: "Times New Roman";">http://mashable.com/2010/06/30/hackathons/</span></a><span style="font-family: Tahoma, sans-serif;"><o:p></o:p></span></div>
<div class="MsoNormal" style="margin-bottom: 0.0001pt;">
<a href="http://techcrunch.com/tag/hackathon/"><span style="color: blue; font-family: "Tahoma","sans-serif"; mso-fareast-font-family: "Times New Roman";">http://techcrunch.com/tag/hackathon/</span></a><span style="font-family: Tahoma, sans-serif;"><o:p></o:p></span></div>
</div>
</div>
</div>
Neel Lakshminarayanhttp://www.blogger.com/profile/00449351271095037254noreply@blogger.com1tag:blogger.com,1999:blog-7887734.post-88184984833975971462013-04-24T21:30:00.001-04:002013-05-19T10:19:51.119-04:00The Feed Forward Loop - A learning process<div dir="ltr" style="text-align: left;" trbidi="on">
<br />
<div class="MsoNormal">
The Feed Forward loop is a process to become a “Learning
Organization”. Successful teams and eventually successful businesses are those that learn the most in the least time. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://4.bp.blogspot.com/-gb7cC4iIiLI/UXhgIszaG3I/AAAAAAAAAUg/1rYuCEbMCuc/s1600/Feed+Forward+Loop.bmp" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="243" src="http://4.bp.blogspot.com/-gb7cC4iIiLI/UXhgIszaG3I/AAAAAAAAAUg/1rYuCEbMCuc/s320/Feed+Forward+Loop.bmp" width="320" /></a></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
I call it the “Feed Forward Loop” because it’s purpose is to
fuel the next cycle. It’s a forward looking cycle that aims to deliver scientific learning in every loop. Every initiative that an agile team
starts must be targeted towards increasing learning in the shortest
possible time. For example, you should aim to learn more about the customer, the business, the market, etc. As
you know, learning is best accomplished by doing. The Feed Forward Loop facilitates that.</div>
<div class="MsoNormal">
<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
There are four steps in the loop:<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<b><i>1. Hypothesize<o:p></o:p></i></b></div>
<div class="MsoNormal">
State your assumption for the initiative that you are about to launch. What do you intend to achieve? What are your success/fail criteria?<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<b><i>2. Test<o:p></o:p></i></b></div>
<div class="MsoNormal">
Devise a method to test the initiative. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<b><i>3. Measure<o:p></o:p></i></b></div>
<div class="MsoNormal">
Measure the outcome of your test. Did it pass or fail? Did it validate your hypothesis?<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<b><i>4. Learn<o:p></o:p></i></b></div>
<div class="MsoNormal">
This is the key to the initiative. Whether the initiative succeeds or fails, there’s
always lessons to be learned. Use this learning to kick off the next cycle.<o:p></o:p></div>
</div>
Neel Lakshminarayanhttp://www.blogger.com/profile/00449351271095037254noreply@blogger.com0tag:blogger.com,1999:blog-7887734.post-88502679898217819472012-10-29T18:18:00.000-04:002012-10-29T18:18:06.367-04:00Kanban: Assets and Liabilities<div dir="ltr" style="text-align: left;" trbidi="on">
The next time you look at a Kanban board, pretend to be an accountant. Look through the eyes of an accountant. You'll probably see two columns like most accountants do - Assets and Liabilities.<br />
<br />
<i>Don't see them? </i><br />
<br />
Work that is "Done" or "Released" is an Asset. Companies make money when work is done. You'll probably find this on the right side of the board.<br />
<br />
Now look to the left. Those are your liabilities. All this work that's "In-Progress" - they are liabilities. You can be proud of them, but they are not making you money. In fact, it's quite the opposite - they are burning money.<br />
<br />
<i>So what do you do with this knowledge?</i><br />
<br />
Start converting your liabilities into assets. Don't add new work (i.e. increase liabilities), instead create more assets (i.e. complete work). Work from the right side of the board.<br />
<br />
Stop starting, Start Finishing.<br />
<br /></div>
Neel Lakshminarayanhttp://www.blogger.com/profile/00449351271095037254noreply@blogger.com1tag:blogger.com,1999:blog-7887734.post-68435429424202919822012-02-26T08:31:00.004-05:002012-02-27T07:18:34.256-05:00The Daily Kanban Stand-up<div dir="ltr" style="text-align: left;" trbidi="on">
<br />
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
Many teams
transition to Kanban from other agile processes. And often, they conduct the daily stand up just like
they used to in their previous process. Since Kanban is an evolutionary method,
in the beginning that's fine. However, very soon you'll find that changes are
necessary.</div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<br /></div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
Teams new to Kanban
use the stand up like a status meeting - often taking turns to update the team
on the status of their "tickets". Or, they keep it very
Scrum like, typically answering the following questions, with some variation, in a round robin format:</div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<br /></div>
<ol style="direction: ltr; font-family: Calibri; font-size: 11.0pt; margin-bottom: 0in; margin-left: .375in; margin-top: 0in; unicode-bidi: embed;" type="1">
<li style="margin-bottom: 0; margin-top: 0; vertical-align: middle;" value="1"><span style="font-size: 11pt;"> What did I accomplish yesterday?</span></li>
<li style="margin-bottom: 0; margin-top: 0; vertical-align: middle;" value="2"><span style="font-size: 11pt;"> What can I commit to
doing today?</span></li>
<li style="margin-bottom: 0; margin-top: 0; vertical-align: middle;" value="3"><span style="font-size: 11pt;"> What are the
impediments in the way?</span></li>
</ol>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<br /></div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
While that may have been appropriate for your past agile process, of the three questions, only the last
one is relevant in a Kanban stand up.</div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<br /></div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
(1) is unnecessary
because the cards on the board tell the story. The WIP (Work in Progress) is
visual.</div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<br /></div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
(2) is irrelevant
because work will take whatever time it will take to get done. Committing to
accomplishing the work will not necessarily make it faster. Often, that leads to
heroic effort. In addition, the focus on completing the work that has been "committed"
to can actually come in the way of continuous improvement.</div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<br /></div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
So, what
should we discuss in the stand up? I'd suggest:</div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<br /></div>
<ol style="direction: ltr; font-family: Calibri; font-size: 11.0pt; margin-bottom: 0in; margin-left: .375in; margin-top: 0in; unicode-bidi: embed;" type="1">
<li style="margin-bottom: 0; margin-top: 0; vertical-align: middle;" value="1"><span style="font-size: 11pt;">Impediments: What's impeding us?</span></li>
<li style="margin-bottom: 0; margin-top: 0; vertical-align: middle;" value="2"><span style="font-size: 11pt;">Flow: What's the flow like?</span></li>
<li style="margin-bottom: 0; margin-top: 0; vertical-align: middle;" value="3"><span style="font-size: 11pt;">Kaizen - or "Continuous
Improvement": What can we improve?</span></li>
</ol>
<div style="font-family: Calibri; font-size: 11.0pt; margin-left: .375in; margin: 0in;">
<br /></div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
Let's take a deeper
dive into these questions.</div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<br /></div>
<div style="font-family: Calibri; font-size: 11.0pt; font-style: italic; font-weight: bold; margin: 0in;">
What's impeding us?</div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
Impediments are in
the way of getting work done. Impeded work items should be marked visually on
the board - usually with a pink sticky on top of it. Team leads or managers
should focus on getting these impediments removed as quickly as possible. </div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<br /></div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
Note that you don't
have to talk about <span style="font-style: italic;">which</span> item is impeded
- that's obvious from the board. The conversation should be around resolution.</div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<br /></div>
<div style="font-family: Calibri; font-size: 11.0pt; font-style: italic; font-weight: bold; margin: 0in;">
What's the flow like?</div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
Kanban looks at
software engineering as a flow problem.
The board will show where the bottlenecks are and therefore what's
preventing the team from accomplishing more. The conversation should be around
smoothening the flow and what actions the team can take to relieve the
bottlenecks.</div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<br /></div>
<div style="font-family: Calibri; font-size: 11.0pt; font-style: italic; font-weight: bold; margin: 0in;">
What can we improve?</div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
Kanban is an
evolutionary method. It's success largely relies on a mindset that's looking to
constantly improve. These do not have to be big changes and can be a series of
small improvements. Having a brief conversation on this topic everyday will
make it clear that it is everyone's responsibility to make the process
better. When suggestions for improvement
come from the team (rather than from managers), there is greater ownership and
more likelihood of success.</div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<br /></div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
These are the core
questions. Here are some additional practices for a successful standup:</div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<br /></div>
<div style="font-family: Calibri; font-size: 11.0pt; font-weight: bold; margin: 0in;">
Ensure
the board is up to date before the stand up</div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
Many teams also use
electronic tools along with a board. It is important to keep the two
synchronized. Before kicking off the stand up, ask the team if the board is
synchronized.</div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<br /></div>
<div style="font-family: Calibri; font-size: 11.0pt; font-weight: bold; margin: 0in;">
Celebrate
the small victories</div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
The done column
on the board should ideally have two
parts. Work done for the week (or an appropriate time period) and work done
since the last stand up. You can now see what got done since yesterday. Call
attention to what got done. Recognize the effort, if only for a
moment. Bring your hands together. Yes - applaud and cheer. </div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<br /></div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
Celebrate small
victories and energize the team. And
move on.</div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<br /></div>
<div style="font-family: Calibri; font-size: 11.0pt; font-weight: bold; margin: 0in;">
Change
facilitators</div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
Encourage different
team members to take on this responsibility. When you facilitate, you'll get a
different perspective of the process. You'll also take more ownership and
funnily enough, suggest more improvements.</div>
<div style="font-family: Calibri; font-size: 11.0pt; font-weight: bold; margin: 0in;">
<br /></div>
<div style="font-family: Calibri; font-size: 11.0pt; font-weight: bold; margin: 0in;">
End
the stand up on a high note</div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
If you have a team song, team dance, a war cry
- do it. It'll always elicit a laugh and keep good cheer.</div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<br /></div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
I'd encourage you to try these practices and
improve on them. You should bring in your variations to the stand up around the
core practices. </div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<br /></div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
Remember - the goal
is to continuously improve.</div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<br /></div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<br /></div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<br /></div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<br /></div>
</div>Neel Lakshminarayanhttp://www.blogger.com/profile/00449351271095037254noreply@blogger.com2tag:blogger.com,1999:blog-7887734.post-4334960168603078922011-11-21T17:34:00.001-05:002011-11-24T08:55:30.749-05:00Kanban Introduction<div dir="ltr" style="text-align: left;" trbidi="on">
<a title="View Kanban Blog on Scribd" href="http://www.scribd.com/doc/73401076/Kanban-Blog" style="margin: 12px auto 6px auto; font-family: Helvetica,Arial,Sans-serif; font-style: normal; font-variant: normal; font-weight: normal; font-size: 14px; line-height: normal; font-size-adjust: none; font-stretch: normal; -x-system-font: none; display: block; text-decoration: underline;">Kanban Blog</a><iframe class="scribd_iframe_embed" src="http://www.scribd.com/embeds/73401076/content?start_page=1&view_mode=list&access_key=key-1u0rg1973qjns27uysu5" data-auto-height="true" data-aspect-ratio="1.33333333333333" scrolling="no" id="doc_33825" width="100%" height="600" frameborder="0"></iframe><script type="text/javascript">(function() { var scribd = document.createElement("script"); scribd.type = "text/javascript"; scribd.async = true; scribd.src = "http://www.scribd.com/javascripts/embed_code/inject.js"; var s = document.getElementsByTagName("script")[0]; s.parentNode.insertBefore(scribd, s); })();</script>
<br />
<br /></div>Neel Lakshminarayanhttp://www.blogger.com/profile/00449351271095037254noreply@blogger.com0tag:blogger.com,1999:blog-7887734.post-31128424875736552292011-09-17T09:58:00.002-04:002011-10-16T16:58:24.232-04:00WIP limits - The magic sauce in Kanban<div dir="ltr" style="text-align: left;" trbidi="on">
<br />
<div class="MsoNormal">
A software development process can be viewed as a queuing system. Little’s law states:</div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<i>Lead Time = Work In Progress / Throughput</i></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Lead time is the time that a work item (represented by a card on a Kanban board) spends in a system in various work states. We want to reduce that, so we can get more work done i.e. increase <i>throughput</i>. As you can tell from the equation, reducing WIP (work in progress) is one way of achieving that. </div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<b>Less is more</b></div>
<div class="MsoNormal">
<b><br />
</b></div>
<div class="MsoNormal">
We've all heard that and have certainly experienced that. That's an earthy way of stating Little's law. We can get more done, when we are focused and working on fewer things.</div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Why?</div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
We are not wired to work on multiple tasks at the same time. When we say we are multitasking, we are really switching our attention from one task to the other i.e switching contexts. Context switching is a waste. Studies have shown that with every additional task taken up there’s a 20% loss. If we are working on three different tasks, we’ve lost almost half the time in just context switching.</div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Grandma was right - less is more. But don't tell grandma that. Not unless you want her to limit you to just a couple of freshly baked cookies instead of the usual half dozen. </div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<b>Ok, we should limit WIP. But how do we determine the WIP limit?<o:p></o:p></b></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
We experiment.<br />
<br />
If we set the limit too high, we will continue working on multiple tasks. If we set the limit too low, we may cause bottlenecks and affect the flow of work in the system.We want the WIP limit to be optimal so we can have a smooth flow.</div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
But it’s not a science. The board will tell you. </div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<b>There are advantages to starting with a lower WIP limit<o:p></o:p></b></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Yes, they’ll cause starvation and pain. But lower limits will expose potential problems in the system. The industry uses the analogy of the WIP limit with lowering the waterline. Lowering the waterline exposes the rocks (i.e. bottlenecks and constraints). When the problems are exposed, the team can work to remove the bottlenecks and constraints until the work flows smoothly again. </div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
And so on and so forth.<br />
<br />
<b>It creates slack</b><br />
<br />
When everybody is working all the time, there's not much time to introspect, retrospect, experiment, innovate or even have lunch. As a rule of thumb, lead times go up when utilization crosses around eighty percent. High utilization is not good. We've probably experienced this when the highways begin to fill up with cars or when the CPU on the computer gets toward its capacity.<br />
<br />
<i>How do we create slack?</i><br />
<br />
We could hire additional members on the team. Imagine going to the folks that handle the purse strings and telling them that we want ten developers in the team but we only want to keep eight developers working because we've heard that utilization at above eighty percent is not good. Good luck with that :)<br />
<br />
<i>Or - we could apply WIP limits</i><br />
<br />
If we have a team of ten and we've put an overall WIP limit of 8, and assuming only one person works on an item at a time, we've taken away work from a couple of developers. In other words, we've intentionally created slack (or excess capacity). And slack is good because it will allow these two "idle" developers to do a few things such as pair up with other developers or help resolve issues at bottlenecks.<br />
<br />
And funnily enough, this will help get more work done.<br />
<br />
<b>It's an enabler for a "Pull"system</b><br />
<br />
A pull system is one where the downstream process pulls in work only when it's ready to process it. This will result in producing only what's needed, transferring work to a work station when needed and reduce inventories i.e. it will help result in a lean outcome.<br />
<br />
When we have WIP limits, we cannot take on work unless we have a "slot" available on the work station. We are consciously defining our capacity to take on work. Imagine if we did not have limits. Work would be "pushed" to us by the upstream process - whether we were ready or not. And most likely, it would just wait to be acted on. That's a waste.<br />
<br />
WIP limits make Kanban a "Pull" system.</div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<b>It's an enabler for Kaizen</b></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
It's not that we don't want to improve, but it's usually that we don't know where to start. Or what our bottlenecks/problems are. Lower work limits are a great enabler for continuous improvement (kaizen). When you run into the bottleneck, resist the temptation to immediately raise the WIP limit. Get a conversation started in the team and look to resolve the bottleneck. </div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Pound the rocks to submission. And if you still have a bottleneck, raise the limit to enable flow.</div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Trust the board. The board does not lie.</div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<b><br />
</b></div>
</div>Neel Lakshminarayanhttp://www.blogger.com/profile/00449351271095037254noreply@blogger.com0tag:blogger.com,1999:blog-7887734.post-74939038537810661512011-04-13T20:23:00.006-04:002011-04-20T11:10:34.158-04:00BDD is not about tools<div dir="ltr" style="text-align: left;" trbidi="on"><br />
<div class="MsoNormal">Many teams practicing BDD assume that the <i style="mso-bidi-font-style: normal;">tool</i> is the <i style="mso-bidi-font-style: normal;">process</i>. A lot of chatter is about:<i style="mso-bidi-font-style: normal;"><span style="color: #333333; font-size: 10pt;"><span style="font-family: 'Times New Roman';"> </span></span></i></div><div class="MsoNormal"></div><ul style="text-align: left;"><li>What BDD tool (or framework) should I use?</li>
<li>How should I use that tool?</li>
<li>Is tool X better than tool Y?</li>
<li>Etc., etc, etc. </li>
</ul><div class="MsoNormal">So much noise, that I’m afraid the intrinsic value of BDD is lost. Just because you are using a BDD tool, doesn’t mean you are practicing BDD. The tools are important, but not absolutely <i style="mso-bidi-font-style: normal;">necessary</i>. You could get a lot out of BDD without a tool. Here’s what I mean.</div><div class="MsoNormal"><br />
</div><div class="MsoNormal"><b style="mso-bidi-font-weight: normal;">BDD helps build “Software that matters”</b><b style="mso-bidi-font-weight: normal;"> </b></div><div class="MsoNormal">In order to do that, you should capture requirements as behaviors resulting in a list of “behavior specifications”. In fact, that is what gathering software requirements is all about. You should define what the software should do (i.e. behavior) and frame it in the context of the business value. </div><div class="MsoNormal"><br />
</div><div class="MsoNormal">But that’s hard. </div><div class="MsoNormal"><br />
</div><div class="MsoNormal">Waterfall teams tend to write verbose documents, that developers find hard to understand. Agile teams err on the opposite side, writing terse user stories that often do not have enough information. BDD helps bridge the gap with the notion of User Stories that have two components: (a) Narrative and (b) Scenario. The scenarios are the acceptance criteria and provide examples of how the software should behave. It helps to illustrate the narrative, providing a concise, yet vivid description of the expected business outcome.</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">You don’t need any new tools to do this.</div><div class="MsoNormal"><br />
</div><div class="MsoNormal"><b style="mso-bidi-font-weight: normal;">It provides a language to document the behavior</b></div><div class="MsoNormal">The narrative is written in the format:</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">As A [role],</div><div class="MsoNormal">I want a [feature], </div><div class="MsoNormal">so that I [benefit])</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">The scenario is written in the format:</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">Given [context]</div><div class="MsoNormal">When [even]</div><div class="MsoNormal">Then [outcome]</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">This is a very structured way to express behavior. “Given” describes the context or state of the system, “When” describes the user action or state transition and “Then” describes the outcome or expected behavior. This expression almost feels like code. Yet it is in a natural language and more importantly, is in the language of the stakeholder. Because of the reduced ambiguity, you are likely to get what you are asking for. Especially, because you are also kind enough to tell the programmer/QA Analyst why a feature is required – a very important aspect of software requirements that is often ignored. Just adopt this format for your software requirements. </div><div class="MsoNormal"><br />
</div><div class="MsoNormal">You don’t need any new tools to do this.</div><div class="MsoNormal"><br />
</div><div class="MsoNormal"><b style="mso-bidi-font-weight: normal;">But it’s more important to discuss the behavior</b></div><div class="MsoNormal">Don’t just define behaviors, discuss them. Leverage the “Power of Three” i.e. the Business Analyst (a proxy for Customer or Product Owner), the QA Analyst and the Programmer in defining behavior. You can start with having the Business Analyst write the narrative and scenarios for the user story. But be sure to have the QA Analyst and the Programmer review the user story. Good QA people can elaborate the user story. Programmers can keep the specification realistic. Discuss it together, even if only for a brief time. These three stakeholders bring very different perspectives and expertise to the table. You’ll find that the scenarios get fortified with better acceptance-tests, including behaviors that were not originally considered. At the end of the conversation you will also have a definition of “done” for the user story.</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">You don’t need any new tools to do this.<b style="mso-bidi-font-weight: normal;"></b></div><div class="MsoNormal"><br />
</div><div class="MsoNormal"><b style="mso-bidi-font-weight: normal;">It’s about baking quality in</b></div><div class="MsoNormal">Many defects occur because the requirements are ambiguous and subject to the programmer’s interpretation. BDD fixes this through the scenarios with their rigid grammar. The scenarios provide the cues to the programmer to build the right features. Defects also occur because the behaviors are not completely defined. This can be fixed by using the “Power of Three” to inspect the user stories, discuss them and finalize them. This may take some time, but the investment will pay off. As the Toyota Production System says, “Inspection to find defects is waste. Inspection to prevent defects is essential”. </div><div class="MsoNormal"><br />
</div><div class="MsoNormal">You don’t need any new tools to do this.</div><div class="MsoNormal"><br />
</div><div class="MsoNormal"><b style="mso-bidi-font-weight: normal;">Engage the stakeholders</b></div><div class="MsoNormal">Leverage the “Power of Three” at every opportunity. Include the Business and QA analysts in the design and architecture conversations. Encourage the Programmer and the Business Analyst to review the test cases. When stakeholders, especially those that are more “outside” than “inside”, get involved in design conversations, they are more likely to drive a better understanding of the need and therefore influence the behavior. </div><div class="MsoNormal"><br />
</div><div class="MsoNormal">You don’t need any new tools to do this.<br />
</div><div class="MsoNormal"><b style="mso-bidi-font-weight: normal;">However, you will need the BDD tools if…</b></div><div class="MsoNormal">You want to create “Executable Documentation” i.e. you want to record the behavior specifications in the BDD grammar in a BDD tool. Typically, these tools generate skeleton code, against which you write production code following TDD practices. Similar to the XUnit tools, initially tests will fail, and when the behavior is implemented correctly, the tests will pass. This will provide traceability from the code to the business value. More importantly, if you are disciplined, you will write just enough code to meet the behavior, thereby reducing waste.</div><div class="MsoNormal"><br />
</div><div class="MsoNormal"><b style="mso-bidi-font-weight: normal;">In conclusion</b></div><div class="MsoNormal">A lot of the intrinsic value of BDD can be realized by:</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">- Applying its User Story format</div><div class="MsoNormal">- Documenting requirements using the recommended grammar</div><div class="MsoNormal">- Leveraging the “Power of Three” to bake quality in the process</div><div class="MsoNormal">- Engaging stakeholders to ratify and discover new behavior</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">And all of this can be done without BDD specific tools. </div><div class="MsoNormal"><br />
</div><div class="MsoNormal">If you believe you are already following these best practices, then it's time to reach for the BDD tools. But not until then.</div></div>Neel Lakshminarayanhttp://www.blogger.com/profile/00449351271095037254noreply@blogger.com2tag:blogger.com,1999:blog-7887734.post-91678811114640905782011-01-22T11:48:00.000-05:002011-01-22T11:48:41.315-05:00Stress in Agile teams<div dir="ltr" style="text-align: left;" trbidi="on">People working in agile teams sometimes complain that stress levels are higher in agile projects. Now, we all know that it is not supposed to be so. After all, don't agile projects distribute work more evenly for the duration of the project? Aren't agile teams supposed to be self organized and responsible for signing up for an appropriate load of work in a sprint (can't even blame management now)?<br />
<br />
Agile experts are quick to point out that the increased stress, if that's even true, is most likely the fault of the agile coach / scrum master. Don't blame the agile methodology, they say. But then, there have always been good managers and bad managers and there certainly are good agile coaches and bad agile coaches. In many teams, the managers have now become scrum masters or agile coaches. When the same team, under the same manager that was practicing waterfall or iterative development is now practicing agile and is complaining about additional stress, could there be some truth to the statement? <br />
<br />
Let's examine possible reasons for the stress and potential ways to mitigate them.<br />
<br />
<span class="Apple-style-span" style="font-size: large;"><b>The Daily stand-up:</b> </span>This is the heart of many agile processes. This is also a potential stress point. Think about it. Day after day, you are asked to give an account of yourself in front of others. What did you do since your last stand-up? What do you plan to do today? Like it or not, you are subjecting yourself to intense scrutiny. There's no place to run and no place to hide. You cannot help wondering what your team mates think of you. You cannot help comparing yourself to Joe who always seems to get more done in the same time.<br />
<div><br />
<b>How to mitigate it: </b><br />
Emphasize to the team that skills and experience vary between individuals. Some are more skilled and experienced than others and may even be earning substantially more. Therefore, it is natural that they will produce more. Do not compare yourself with the performance of others. Just do the best you can.<br />
<br />
<b><span class="Apple-style-span" style="font-size: large;">Commitment:</span></b><br />
In agile, as in life, it's the many small promises that we make that adds to the pressure. In an agile process, specifically in the daily stand-up, we are making promises everyday. We call them commitments. It's human nature to want to meet those commitments. We are essentially honest people and we want to live up to our promises. Until we fulfill that promise, it's hanging over our heads like the proverbial sword of Damocles. And if we fail to keep the promise, we feel guilty. Even, if it's not entirely our fault.<br />
<br />
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><b>How to <span class="Apple-style-span" style="font-weight: normal;"><b>mitigate </b></span>it: </b></div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">Don't not use the word "commit". Instead, say "try". Don't say "I commit to do X". Instead say, "I'll try to do X". It's a subtle but important difference. Notice how there's no promise to deliver? Does that mean you are going to work any less harder? No. Remember, we are honest people. Our teams trust us.And we will do what we can to complete X. </div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><br />
</div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><i>But we did not commit</i>.So there is no expectation tomorrow that it will be done.We'll sleep better and perhaps even make it home in time for dinner.</div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><br />
</div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><span class="Apple-style-span" style="font-size: large;"><b>Estimates:</b></span></div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">When teams or individuals estimate tasks, they are implicitly committing to the hours. When we commit, we take on stress.</div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><br />
</div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><b>How to <span class="Apple-style-span" style="font-weight: normal;"><b>mitigate </b></span>it:</b></div>Do not ask for estimates. Instead, attempt to "right size" the tasks using techniques like T-Shirt sizing. Measure the time taken to complete the task from the time it is started. The task will start when it does and complete when it does. As the team gathers these metrics they will also become more adept at "right sizing" the tasks. The eventual outcome is a steady velocity for the team. And since the team is not providing estimate that they have to commit to, the stress is also less.And when the team is less stressed, they produce more.<br />
<br />
<span class="Apple-style-span" style="font-size: large;"><b>Conclusion</b></span><br />
Agile processes introduce stress in many subtle ways. Some of these are an outcome of the high visibility and transparency of the methodology - the very techniques that make agile so successful. This stress is not introduced intentionally - rather it is an unintended side effect. Being aware that the stress is real and tangible can help us mitigate it.<br />
<br />
Unless we acknowledge it, we cannot manage it.</div></div>Neel Lakshminarayanhttp://www.blogger.com/profile/00449351271095037254noreply@blogger.com2tag:blogger.com,1999:blog-7887734.post-92004307848380627502010-11-27T15:12:00.000-05:002010-11-27T15:12:38.366-05:00When Agile becomes RigidAgile teams are supposed to be agile. Yet, there are agile teams run by over zealous agile coaches, who in their quest to become agile have actually become rigid. In fact, very rigid. If you see the following signs, you are in one such team:<br />
<ul><li>It is the Agile coach's way or the highway. He/She will parrot prescriptions from various agile books on how it should actually be done. Forget the manual, coach. True agile is not supposed to be prescriptive. Good ideas can come from anywhere - include the team by your side that's still (Oh, my God!) practising iterative/waterfall.</li>
<li>The agile coach will not let a member of the team to participate in other important meetings/discussions in the organization, because "it will affect the team's commitments to the sprint!". Yes, the sprint is important but the organization is more important.</li>
<li>You feel like you are followinng a cult rather than a software development methodology.</li>
<li>The team is apparently "self organized" - or so the agile coach says. Repeatedly. And yet, all major decisions are from the agile coach.</li>
<li>It's easier to stop the earth's rotation than to change the schedule of the Sprint ("we have committed these deliverables to the customer"). It doesn't matter that there are existing customer who probably want a fix urgently. Oh no, nothing can come in the way of the Sprint!</li>
<li>All the fun at work is lost. It's all about commitments and not letting your team down. And yet, ironically, there's a lot of talk about "the team is a family", "active socializing", "protecting the team member from context switching". etc. You didn't hear such talk in your "waterfall" team and yet you felt like it was a family. Strange, eh?</li>
<li>Life is a series of Sprints. You are reduced to a Sprint Monkey going from one sprint to another. Even your schedule at home, revolves around these sprints ("I don't have time to throw the trash, dear. I'm in the middle of a sprint!").</li>
</ul>If you are in one such team, remind your agile coach about agility. It's not enough to follow agile practises - <em>you actually need to be agile.</em>Neel Lakshminarayanhttp://www.blogger.com/profile/00449351271095037254noreply@blogger.com0tag:blogger.com,1999:blog-7887734.post-32453895205548522742010-10-31T18:10:00.001-04:002010-10-31T18:11:51.545-04:00Stop finding Defects !Yes, please. Let's focus, instead, on "Preventing Defects".<br />
<br />
We need to develop software faster and with better quality than ever before. We cannot afford to have an extensive "bug fixing" cycle. Finding defects towards the end of the software cycle is expensive. We all know that and yet many teams continue to do just that. This is perhaps the only industry where we tolerate that process and devote extensive time in the development cycle towards finding and fixing them. We wouldn't dream of a process like that while building houses or cars. Or even while cooking a meal at home. So why do we allow that while building software?<br />
<br />
Could it be ignorance? Or complacence? Neither is acceptable in this day and age.<br />
<br />
I'd like to suggest that we have tools and techniques at our disposal that will go a long way towards preventing defectings. What is lacking is belief that it's possible. Try it in the small and the belief will come.<br />
<br />
Try BDD (Behavior Driven Development).<br />
<br />
"Finding Defects" is an industrial age activity. "Preventing Defects" is a knowledge era activity. And in case you didn't notice, we are in the knowledge era.Neel Lakshminarayanhttp://www.blogger.com/profile/00449351271095037254noreply@blogger.com0tag:blogger.com,1999:blog-7887734.post-50530743879715930122010-07-27T18:21:00.000-04:002010-07-27T18:21:44.878-04:00BDD is more than “TDD done right”BDD is more than just doing TDD right. Beginners in TDD struggle to understand that TDD is really about design and not testing. Similarly, newcomers to BDD may find it challenging to appreciate that BDD is also about collaboration between stakeholders and not just software behavior. You will find discussions on the internet on “BDD is TDD done right”. That’s certainly true, but there is much more to BDD. We will soon look at the additional value BDD offers, but first let us list why people think BDD is just TDD done right. <br />
<ol><li>TDD captures behavior or intentions just like BDD. You write a test case upfront to capture a behavior. However, the vocabulary is all test based so this is confusing. BDD fixes this by using the right vocabulary. Therefore, BDD is still TDD – but better. </li>
<li>TDD captures low-level requirements (usually at the class/method level). BDD captures high-level requirements. Therefore, BDD is still TDD - but at a higher level.</li>
<li>BDD and TDD result in a suite of tests that we can run as a regression suite. Therefore, BDD is still TDD.</li>
</ol>What then does BDD offer that is not in TDD? The value is largely in the collaborative process for defining requirements and the grammar and structure used for capturing them.<br />
<div></div>BDD captures requirements as user stories. A story has two parts – a narrative and scenarios. A requirement is not complete until it has both. We write Stories in BDD with a rigid structure. We write a narrative using a Role/Benefit/Value grammar and scenarios using a Given/When/Then grammar. Following a rigid structure like this can help adoption of a common vocabulary that leads to unambiguous requirements.<br />
<br />
However, the benefit goes beyond that.<br />
<br />
The crucial value that BDD offers is the process for creating the user stories. User stories are developed collaboratively by the key stakeholders – the Product Manager (or customer or Business Analyst), the QA resource and the developer. This level of collaboration results in:<br />
<ol><li>Developing features that truly add business value.</li>
<li>Preventing defects rather than finding defects. Think how much easier it is to write code when you have scenarios that exemplify the positive and negative behaviors and make the intention transparent to the programmer.</li>
<li>Bring QA involvement to the forefront. This is great for team dynamics because in many agile processes QA personnel feel ignored.</li>
<li>Define executable, verifiable and unambiguous requirements.</li>
<li>Provide a better definition of “DONE” for agile development. </li>
</ol>However, the benefit goes beyond that.<br />
<br />
BDD also helps you write “Software that matters”. What does this mean? Think of it as writing just enough code to meet a business requirement. You are probably thinking, “I could do that with TDD too”. Consider this. As you are writing Junit tests cases, is a stakeholder (Product Manage/Business Analyst/QA resource) with you? Probably not. Have you ever written code (probably excellent code, perhaps even following TDD practices), that was not required? Probably yes. You may not have shipped it, but you probably wrote it, found no use for it and deleted it. That is a waste. When you follow BDD, you are less likely to do this. You will reduce waste.<br />
<br />
How can we write “Software that matters”?<br />
<br />
The best way to do that is to leverage BDD and TDD. Here is an approach:<br />
<ol><li>Write requirements as user stories using the BDD grammar/structure. Do this collaboratively with the key stakeholders.</li>
<li>Enter the User Stories (feature + scenarios) in a BDD tool.</li>
<li>Write code to map the User Stories to tests.</li>
<li>Write production code using TDD to make the tests pass. </li>
</ol>As you can see, BDD is not just TDD done right. You could use just the vocabulary of BDD to improve TDD but that would be like using only some of the benefits that BDD has to offer us. When we use the the strengths of both these techniques we will have “Software that matters” along with “Software that works”. <br />
<div> </div>That is the promise of BDD.<br />
<br />
<div></div>Neel Lakshminarayanhttp://www.blogger.com/profile/00449351271095037254noreply@blogger.com7tag:blogger.com,1999:blog-7887734.post-58417355601213049122010-06-22T17:40:00.000-04:002010-06-22T17:40:32.583-04:00Agile is not about speedStudies have shown that agile methodologies shorten the software development cycle. Naturally, many assume that agile is all about speed. This is quite far from the truth.<br />
<br />
What's the usual cause of delay in software projects? Quality. Or more accurately- lack of it. For example:<br />
<br />
• Poor quality planning leads to project delays.<br />
• Poor quality requirements, leads to poor implementation<br />
• Poor quality implementation leads to defects which leads to delays<br />
• Poor quality testing, leads to disaster<br />
<br />
Agile methods infuse an intense focus on quality at all these levels. <br />
<br />
• Planning is kept simple and straightforward to achieve sprint goals. Usually, the entire team participates in planning.<br />
• Requirements are reviewed by all stakeholders and are kept minimal to achieve business value. The focus on business value ensures that only the “Minimal Marketable Features” make it to the sprint. Good requirements ensure that minimal code is written. We all know that the highest quality code is the code that isn’t written.<br />
• Peer reviews, pair programming and Test Driven Development results in higher implementation quality.<br />
• Quality is baked in at all levels. QA focuses on preventing defects rather than finding them.<br />
<br />
A team that follows all this rigor will actually be writing fewer lines of code per day than other teams. Per conventional measurements, these teams are <em>slower</em>! However, the quality of the artifacts (all artifacts – not just the code) is much higher because it receives intense scrutiny. Enforcing quality at all levels has a happy side effect of speeding up projects. If you want to deliver more, and if you want to deliver it faster - slow down and focus on quality. <br />
<br />
That's the essence of Agile methodologies.Neel Lakshminarayanhttp://www.blogger.com/profile/00449351271095037254noreply@blogger.com0tag:blogger.com,1999:blog-7887734.post-58668729097883502942010-05-16T12:10:00.001-04:002010-05-16T12:11:42.936-04:00Why are there so many Agile Coaches?Makes me wonder. <br />
<br />
Agile development must be hard. Why else would there be so many Agile coaches? When people were doing waterfall, I don't think there were that many "Waterfall Coaches". Think about it. How many of your contacts in the software world were "Waterfall Coaches"? None of my personal contacts were coaching waterfall. On the other hand, I know of at least half a dozen who are in this business - either fulltime or part time. And I'm running into many strangers who are Agile coaches. Or at least want to become one.<br />
<br />
For a methodology that is supposed to be simple, why are there so many coaches? Perhaps it is not simple. Agile is supposed to simplify but that's not the same thing as being simple. Perhaps the highly adaptive nature of agile methodologies necessitates a coach.<br />
<br />
Essentially - what does an agile coach do? If you are a team that's already practicing an agile methodology, she'll probably take a look at your methods and suggest improvements. Should I use the word prescribe changes? Funny. We choose a methodology that's not prescriptive for its ostensible benefits and then we hire a coach to prescribe methods.Neel Lakshminarayanhttp://www.blogger.com/profile/00449351271095037254noreply@blogger.com0tag:blogger.com,1999:blog-7887734.post-92201541545599144142010-05-09T10:16:00.082-04:002011-06-04T17:09:45.486-04:00The Rise of the BAQA ("BaaKwaa")<div dir="ltr" style="text-align: left;" trbidi="on">The role of the Business Analyst (BA) and Quality Assurance Engineer (QA) as we know it is changing. As agile methodologies become prevalent, they appear to have an overlap. I think of a person performing this new role as a BAQA (pronounced <i><b>BaaKwaa</b></i>). The need for people in agile teams to wear different hats is spurring this development. In recent times, this has received a boost with the development of frameworks supporting Behavior Driven Development (BDD) and Acceptance Test Driven Development (ATDD).<br />
<br />
Agile teams, and in particular teams following BDD/ATDD, write user stories in place of verbose software requirements. The user story captures the essence of the requirement expressed in a "Role/Feature/Benefit" grammar. Subsequently, acceptance criteria are written as "Givens/Events/Outcomes" to exemplify the requirement. Together, they completely define the business requirement.While the user story requires a Business Analyst's skill, the acceptance criteria requires a Quality Assurance Engineer's skill. Essentially, we now have a need for a person who can play both roles.<br />
<br />
Enter the <i><b>BaaKwaa</b></i>.<br />
<br />
Let us see the typical responsibilities of a Business Analyst and QA Engineer in a traditional methodology, such as waterfall.<br />
<br />
A Business Analyst:<br />
<br />
<ul style="text-align: left;"><li>Understands the business domain</li>
<li>Analyzes weaknesses and strengths and helps define new features</li>
<li>Writes software requirements specifications for the development team</li>
</ul><br />
A Quality Analyst:<br />
<br />
<ul style="text-align: left;"><li>Writes test cases</li>
<li>Performs tests on software programs and finds defects</li>
<li>Ensures the quality of the software</li>
</ul><br />
Here's a brief role description for a <i><b>BaaKwaa </b></i>in an agile team:<br />
<br />
<ul style="text-align: left;"><li>Write the user story (thus capturing business requirements)</li>
<li>Write the acceptance criteria (thus further expressing the requirements through examples)</li>
<li>Write the acceptance criteria in a BDD/ATDD framework in the language of the framework (example: Fitnesses, Cucumber, StoryQ, etc)</li>
<li>Verify that the implementation meets the acceptance criteria preferably through automated means.</li>
</ul><br />
I'm not suggesting that we are witnessing the demise of the specialist BA and QA. There is a role for the specialist and there always will be, just as we continue to have architects, DBA's and user interface specialists in agile teams. However, they will be required to drop their BA or QA hat quite often, and instead wear the BAQA hat.<br />
<br />
Please welcome the <i><b>BaaKwaa</b></i>.</div>Neel Lakshminarayanhttp://www.blogger.com/profile/00449351271095037254noreply@blogger.com3tag:blogger.com,1999:blog-7887734.post-30590140543701571152010-05-02T16:01:00.000-04:002010-05-02T16:01:20.054-04:00Agile: The Preacher and the PractitionerIn an Agile conference, you will find two types of attendees - the <em>preachers</em> and the <em>practitioners</em>. The preachers are the speakers, the trainers and the agile "experts". They believe implementing an agile methodology in a text book like fashion is the only way to do it. The practitioners are those who have started an agile process in their company, are struggling to make it work and are dealing with real organizational and people issues.They see value in the agile process but do not think it can be done in a textbook fashion in their organization.<br />
<br />
Here is what, for example, some of the agile preachers believe:<br />
<ul><li>SCRUM-But is evil. Not implementing an aspect of SCRUM points to an impediment that must be fixed.</li>
<li>You must have teams co-located.</li>
<li>Autotmated testing (TDD), continuous integration, etc. is a must.</li>
<li>The Product Owner is always available to answer the team's questions. </li>
<li>Team resources are fully dedicated to the sprint. </li>
<li>Deadlines can and should be stretched to acommodate quality.</li>
</ul>Here is what, for example, some of the agile practitioners have experienced:<br />
<ul><li>SCRUM-But is a reality for organizations dealing with legacy products.</li>
<li>Co-location is a luxury in today's era. Often, even in the same geographic location, some team members work from home.</li>
<li>Automated testing, continuous integration is often not possible for legacy applications.</li>
<li>The Product Owner (Product Manager in the real world) is often managing multiple projects. It is an illusion to assume the Product Owner is dedicated and available.</li>
<li>Team resources - especially QA, DBA, Architects often work on multiple projects or agile teams concurrently.</li>
<li>Deadlines are real. They are often final and products must meet them and make compromises in the process.</li>
</ul>The Agile Preacher often comes off as a white collar intellectual mostly used to working in laboratories, where things are largely under control. The Agile Practitioner, comes off as a blue collar worker, just interested in getting the job done in the real world with real people and real challenges to face.<br />
<br />
The truth, as usual, is in between. Agile Preachers must temper their language to factor reality. Agile Practitioners must try to change reality. And in this tension between the two groups is where we'll see real value being added to the Agile Process.Neel Lakshminarayanhttp://www.blogger.com/profile/00449351271095037254noreply@blogger.com0tag:blogger.com,1999:blog-7887734.post-23568677342982019112010-04-28T21:28:00.000-04:002010-04-28T21:28:21.684-04:00Agile Boston Open Space 2010I attended Agile Boston Open Space 2010 (http://www.newtechusa.com/agileboston/events/AgileBostonOpen2010.asp) today. The event was at the Microsoft Building in Waltham, Boston. Of the many conferences that I have attended, I have no hesitation in saying this gave me the most value for money. Here's why:<br />
<ol><li>Convenience: It was in my backyard - just a couple of miles from my workspot. It certainly helped that while the title had Boston in it, it wasn't in Boston. It was in Waltham (you can tell I don't like going to Boston).</li>
<li>Cost: Just $29. And that included breakfast and food. And yes - there was vegetarian food. It was just a wrap, but it was tasty. This is not a trivial matter. I'm a vegetarian and I have often found that some conferences that charge heavy fees don't pay much attention to the vegetarian fare. These people were thoughtful.</li>
<li>I got to hear Ken Schwaber for an hour.</li>
<li>I got to network with a number of smart people who were willing to teach, learn and share. I learn't about a number of misconceptions about Scrum. Just because it is highly adaptive doesn't mean that you shouldn't do some of the process that truly added value in waterfall. People didn't say that in so many words, but that was the gist of what I got from it. If it's valuable, keep it.</li>
<li>I learn't about "Open Space Technology" (<a href="http://www.openspaceworld.com/brief_history.htm">http://www.openspaceworld.com/brief_history.htm</a>) - a fabulous way to organize meetings very productively.</li>
</ol>I think it was a day very well spent.Neel Lakshminarayanhttp://www.blogger.com/profile/00449351271095037254noreply@blogger.com0tag:blogger.com,1999:blog-7887734.post-49432385585524317882010-04-17T11:47:00.000-04:002010-04-17T11:47:20.552-04:00TDD is a MisnomerWe all know, at least those of us in the software community, that TDD stands for "Test Driven Development". That's a huge misnomer. Simply because TDD is much more than about tests. Yes - tests are a core part of TDD. But TDD is also about the following:<br />
<br />
<ol><li>It's a way to capture behavior (think requirements)</li>
<li>It's a design tool (If it's easy to test, the resulting code will be elegant)</li>
<li>It captures high level documentation (think tools like agiledox)</li>
<li>It's a regression test suite.</li>
</ol><br />
The word "tests" in it leads to all kinds of confusion among TDD practitioners. What do I test? How do I test? What do I test first?<br />
<br />
Happily, we now have Behavior Driven Development - which simply removes the confusion around TDD while taking it to a whole new level.<br />
<br />
Yes - I'm beginning to like BDD a lot. It's a better TDD and more.Neel Lakshminarayanhttp://www.blogger.com/profile/00449351271095037254noreply@blogger.com0tag:blogger.com,1999:blog-7887734.post-57574108553360991642010-04-11T17:33:00.000-04:002010-04-11T17:33:31.467-04:00ScrumBut is not that badScrumBut is a practice where teams implement partial apsects of Scrum. As in - "We did Scrum BUT we did not have daily standups". Scrum pracitioners look down on teams that practice ScrumBut and perhaps for good reason. As they argue, when a team does not implement a prescribed practice in Scrum, the team is allowing for a problem to fester. <br />
<br />
For example, if a team finds that a Product Manager is unable/unwilling to participate in an agile team as a "Product Owner", using ScrumBut, the Business System Analyst may take on that role. The "Product Owner" is one of three key roles that Scrum prescribes. Not having the real Product Owner play that role is a violation of Scrum. In reality, there might be organizational hurdles, as in highly matrixed organizations, that prevent the Product Manager from participating in agile teams. Should the agile team give up their move towards adopting agile methodologies? <br />
<br />
Perhaps not. ScrumBut is an excellent way to get started with agile methodologies. Agreed that it is not likely to give the same amount of return that Scrum promises. However, it is an incremental way to adopting Scrum. It is likely to result in less of a culture shock to new teams and may provide the breathing space to winning hearts and minds. <br />
<br />
The end goal though must be to eliminate the "But" and have just "Scrum". Assuming of course, Scrum is what you want for an agile methodology.Neel Lakshminarayanhttp://www.blogger.com/profile/00449351271095037254noreply@blogger.com0tag:blogger.com,1999:blog-7887734.post-67240095682786540712009-09-05T19:07:00.003-04:002009-09-05T19:11:26.342-04:00Embrace “Automated Unit Testing” in Waterfall<em><span style="font-family:arial;">Automated Unit Testing is a process where developers programmatically test their code using test frameworks such as the XUnit framework. Code is not considered complete unless it is accompanied by a test case. Agile teams have embraced unit testing. Waterfall teams can also do so without disruption to their process.</span></em><br /><br /><span style="font-family:arial;"><strong>Introduction</strong><br />Agile software development teams have reaped significant benefits by adopting “Automated Unit Testing” as a part of the development process. For teams that are considering becoming more agile, adopting “Automated Unit Testing” would be a good start. It can be easily embraced without significant impact on the process. “Automated Unit Testing” is a process where programmers write test cases for their code using testing frameworks such as the XUnit framework. Ideally, the test cases are written first followed by the implementation of the production code. When all the tests pass, the implementation is complete.</span><br /><br /><br /><span style="font-family:arial;"><strong>Challenges in “Automated Unit Testing”</strong><br />More than the impact on the process, the challenge is in getting teams to adapt to this process. In waterfall process, development teams typically provide the implementation and throw it over the wall for QA to test. Asking programmers to prove that the code works before handing it over to QA is a significant paradigm shift. Writing tests is also hard – especially if the code has not been written in a testable way. Developers may have to spend as much time writing the test cases as the production code itself. To most developers, this seems like a waste. However, this pays off in terms of producing code with fewer defects.</span><br /><br /><br /><span style="font-family:arial;"><strong>Better late than never</strong><br />It’s never too late to write tests. Tests are most effective if they are written at the time the production code is being written. However, you could introduce them even as defects are being fixed for existing code. When a defect is fixed, insist that tests be written for it. This allows for an incremental creation of test suites. Test suites allow for your code to be flexible. Their presence lets you re-factor with confidence.</span><br /><br /><br /><span style="font-family:arial;"><strong>Conclusion</strong><br />Automated Unit Tests are a pillar of agile teams. For teams that want to adopt agile practices, this is a great way of adopting one of its pillars without disrupting existing processes. It’s never too late to adopt Automated Unit Testing. Embracing it in Waterfall also sets the stage for adopting the other important aspects of the Agile methodologies.<br /><br /><br /><br /><br /><br /><br /></span>Neel Lakshminarayanhttp://www.blogger.com/profile/00449351271095037254noreply@blogger.com0tag:blogger.com,1999:blog-7887734.post-68484731306297130522009-08-09T17:20:00.005-04:002009-08-09T17:27:10.314-04:00Embrace Upstream Testing in Waterfall<span style="font-family:arial;"><em>Upstream testing is a process where developers and testers work together from very early in the development cycle - even as features are being built. This is a flavor of an agile development methodology that can be embraced even in a waterfall process. </em></span><br /><br /><br /><strong>Introduction</strong><br />Agile software development teams have reaped significant benefits by adopting the methodology over the waterfall process. However, there are significant challenges in moving from waterfall to agile. Most teams that make the change adopt a home grown hybrid model eventually leading to a complete agile methodology. If you are in a team that is practicing waterfall and you want to be more agile, consider adopting “Upstream Testing” in your current process.<br /><br /><strong>How testing is usually done in waterfall</strong><br />In ideal waterfall, features are delivered to QA after they are completely built - in one fell swoop. More commonly, features are delivered in interim builds to QA for testing. QA tests the interim build and reports defects on them. These defects are triaged, prioritized and assigned to developers for fixing in future builds. This is usually a slow and expensive process. Often times, the developers have moved on to other features building, sometimes, on the existing defects. Fixing the defect now is more expensive and risky. Additionally, in many situations QA is not able to complete the testing of features developed in the build. As additional builds are delivered, QA is often behind in testing. The later a defect is fixed, the higher the cost. Unfortunately, since the risk of fixing is also higher with the passage of time, many defects are deferred to a later release – which is effectively a “death sentence” for the defect. The reality is that it will never get fixed, resulting in an inferior product to the customer.<br /><br /><strong>Embrace Upstream Testing </strong><br />What can waterfall organizations to do in the short term to improve the quality of their deliverables? Adopt “Upstream Testing” in your process. “Upstream Testing” is a flavor of agile testing methodology that can be embraced without causing major disruption in existing processes. Very often it can be done without even the involvement of senior management.<br /><br />In this process, QA works with software development even as features are being iteratively developed. As the developers are checking in code, the QA resources are testing the functionality on daily builds. The daily builds are not formal builds that are handed off to QA with all the bells and whistles. Instead, it is a build that is used by development to test the validity of their integration and check-ins. QA and development work off the same build. The real differentiator in this process is what happens when QA finds an issue. The tester simply reports this to the developer without registering the defect in the corporate defect tracking tool. The developer and tester agree on a fix and it is implemented right away. The tester tests the fix and the developer moves on to other features confident that not only has he unit tested it but that it has even been approved by a tester. When the formal build is done and handed off to QA for intensive and regression testing across many platforms, there are no surprises to QA and quality is already very high.<br /><br />Note that there aren’t any significant deviations from how development and testing is done. The QA and development teams continue to report to their respective managers. The organization hierarchy is preserved while still injecting agility into the process. Apart from the development and QA teams, hardly any other organization is functionally affected – in contrast to a full agile methodology which has a ripple effect throughout the organization.<br /><br /><strong>Benefits of Upstream Testing </strong><br />Since the tester and developer are working together, the quality of the deliverable is being monitored continuously – almost on a daily basis. Defects are found and fixed early. It is extremely cost effective to the organization to have this done without going through defect reporting, triages, defect assignment, Change Control Board’s and such ceremonies. Defects that might get deferred are actually fixed – because it is possible to do so. The result is a higher quality product, delivered earlier in a more cost effective manner. The social engineering aspects of “Upstream Testing” cannot be underestimated. The tester gets to understand the complexity of development and the developer begins to appreciate the value of the tester in making the developer look good.<br />Development and QA start beginning to look like a team working towards a common goal.<br /><br /><strong>Operational Challenges in Upstream Testing</strong><br />Many organizations are set up functionally. Thus, the QA and development teams report to different directors who may ultimately report to the VP of Engineering. The very nature of this organization sets up different priorities for QA and development. Very often, one of the metrics used to measure the performance of QA teams is the number of defects filed per release of a product. It is not unusual to see colorful graphs of defects found outside the QA director’s office while the development director’s office proudly displays the defects fixed.<br /><br />In “Upstream Testing” the defects filed are far fewer – because they are caught and fixed informally. The management of QA and development need to arrive at an understanding of a more mature and relevant measure of performance. This can often be challenging and needs good understanding and common goals between development and QA managers.<br /><br /><strong>Conclusion</strong><br />Upstream Testing is an agile practice that can be fairly easily introduced to teams following waterfall. It is not disruptive and fits in well with waterfall processes. It allows for defects to be caught earlier resulting in cost efficiencies. Apart from higher quality deliverables, the effect of the social engineering it introduces between development and test teams is high. If your team is following a waterfall process and looking to adopt more agile processes, consider “Upstream Testing”. It is an enabler for moving towards full fledged agile methodology in the future, while solving real problems today.Neel Lakshminarayanhttp://www.blogger.com/profile/00449351271095037254noreply@blogger.com0tag:blogger.com,1999:blog-7887734.post-30620622036403801522009-08-01T17:18:00.002-04:002009-08-01T17:44:52.582-04:00Embrace the daily stand-up in Waterfall<span style="font-family:arial;font-size:85%;"><em>The Daily Stand-up meeting is the heartbeat of Scrum, an Agile methodology. This is a process that can be easily embraced by teams following the waterfall process. </em></span><br /><span style="font-family:Arial;"></span><br /><span style="font-family:arial;"><strong>Introduction<br /></strong></span>Agile software development teams have reaped significant benefits by adopting the Scrum methodology. However, there are significant challenges in moving from a Waterfall process to an Agile process. Most teams that make the change adopt a home grown Hybrid model eventually leading to a complete Agile methodology. It has been argued by many, that a swift change from one process to another is better than a gradual change. While there are merits to the argument, the reality is that most organizations and people take time to embrace change. It is better to take the time to win hearts and minds than to force adoption of a new methodology. Change that is willingly embraced is change that can be sustained.<br /><br />Let’s say you want to adopt some Agile methodologies in your team that is currently following the waterfall process. What aspect of it should you adopt? My suggestion is to introduce the “Daily Stand-up” in your team. The “Daily Stand-up” is the heartbeat of the Scrum Agile methodology. See here for an explanation of this process:<br /><br /><a href="http://www.mountaingoatsoftware.com/daily-scrum">http://www.mountaingoatsoftware.com/daily-scrum</a><br /><br />Ask the team if they are willing to try this out for a couple of weeks. Also choose a time that is most convenient to them. Most teams will be willing to try this out. You can (and I recommend that you should) even offer the following incentives to the team, if it is in your power:<br /><br /><strong>Cancel the weekly status reports</strong><br />Most programmers dislike writing status reports. They’d rather write code. With the daily stand-up you probably don’t need weekly reports anymore. You are getting the status daily! You can use the information at the daily stand-up to update the project plan and produce a burndown chart to track progress.<br /><br />See here for description of a burndown chart:<br /><a href="http://www.mountaingoatsoftware.com/release-burndown">http://www.mountaingoatsoftware.com/release-burndown</a><br /><br />Your team members will love you for canceling the weekly status report!<br /><br /><strong>Cancel the status meeting<br /></strong>Most waterfall teams have weekly status meetings that last for an hour or more. Most programmers dislike long meetings. Since you are getting a daily update, you probably don’t need this meeting anymore. Cancel it.<br /><br />Your team members will love you for canceling the weekly status meeting!<br /><br /><strong>What’s the gain from the daily Stand-up?</strong><br />As a Project Manager you have a daily update on the progress. This is better than the weekly update from the original status meetings. You have information early that you can act upon. There is less formality in a stand-up – programmers tend to like that. Information exchanged in a stand-up often results in offline warm & fuzzy communication.<br /><br /><strong>Conclusion</strong><br />The daily stand-up contributes heavily to the success of an Agile methodology such as Scrum. If the 80/20 rule were to be applied to Scrum, the daily stand-up would show up on the “20” side. It can be easily incorporated into the Waterfall process with all the resulting benefits. Embracing it in Waterfall also sets the stage for adopting the other important aspects of the Scrum Agile methodology.Neel Lakshminarayanhttp://www.blogger.com/profile/00449351271095037254noreply@blogger.com1