tag:blogger.com,1999:blog-97572362024-03-18T02:18:33.331-07:00GrumpasaurusWhatever I think aboutChowspecialhttp://www.blogger.com/profile/05113522146511552068noreply@blogger.comBlogger105125tag:blogger.com,1999:blog-9757236.post-83532407925840956542024-01-28T15:03:00.000-08:002024-01-28T16:48:00.680-08:00Making a Distinction Between Functional Skill Set and Institutional Knowledge in Employee Development<p style="text-align: left;">Earlier in the week I did a poll on topics and the number 1 pick by an overwhelming margin (beyond Sad Ass Salad) was "Business Domain vs Functional Domain in Performance Evaluations." <span></span></p><a name='more'></a><p></p><h3 style="text-align: left;">Functional Domain vs Business Domain</h3><div>In many corporate career development guides, there aren't any distinctions between functional skill and business domain knowledge.</div><div><br /></div><div>Functional Skill Set is easiest described as the skill of the fundamental tasks needed to complete a job. Business Domain knowledge is easiest described as knowledge in company and business landscape </div><div><br /></div><div>Here are Some examples of functional vs business domain:</div><div><br /></div><div><b>Football Player:</b> a wide receiver who has amazing combine stats vs someone who is already really familiar with a team's offensive scheme.</div><div><b>Product Manager:</b> someone who can document any as-is state vs someone who really knows food delivery operations</div><div><b>Fighting Games:</b> someone who is amazing at footsies vs super familiar with the latest meta</div><span><!--more--></span><div><br /></div><h3 style="text-align: left;">Business Domain and Institutional Knowledge</h3><div><br /></div><div>But to take it a bit further, especially with software development, there's a lot of parallel between business domain and institutional knowledge. Probably the most common example of someone excelling in their position is when they are able to contribute independently to a given application's code. In many situations, it's very common for one to use that as an example of a developer thinking that this knowledge allows them to be the Lead of a given team if that app is the main focus.</div><div><br /></div><h4 style="text-align: left;">Knowing "where the bodies are buried"</h4><div><br /></div><div>Both business and institutional knowledge are foundations that are commonly built over time and exposure to the job and all the elements that come with it. </div><div><br /></div><h4 style="text-align: left;">Knowledge of Business Industry</h4><div><br /></div><div>Business industry may not be something that is common in software engineering companies but probably most commonly it is surrounding experience and knowledge of use cases that one has been exposed to in past positions. My personal experience ranged from Navair conops, to trucking logistics, to on-demand food delivery, and now, ticketed events. An explicit example where my knowledge of a coworker's previous exposure to accounting use cases allowed us to very quickly build a subledger recording system that can ultimately be imported into accounting systems such as quickbooks or netsuite.</div><div><br /></div><div>Probably the most prominent examples of hiring someone for their business domain expertise on the engineering side is Product Management, people who have already had hands-on experience in the use cases that you're looking for.</div><div><br /></div><div>Outside of engineering, sales is extremely common in hiring someone who already has an established network within the leads that you're pursuing.</div><div><br /></div><h3 style="text-align: left;">Both should be valued and nurtured</h3><div><br /></div><div>Both of these elements in one's contributions to a company are important and their strengths in either form play a large part to the makeup of your team. However, overemphasizing on one versus the other can hinder not only an employee's development but also create an imbalanced incentive structure that can lead to organizations not equipped to handle situations at hand.</div><div><br /></div><h4 style="text-align: left;">Examples of Institutional Knowledge being over valued</h4><div><br /></div><div>As a manager, it's very easy to depend on the same person over and over again work in an area they are well practiced at. This may give the impression that they are a high performer. As a result, you may find yourself with people in higher positions that may not be equipped in handling new-to-them situations.</div><div><br /></div><div>A common situation: a "lead" developer who has spent the past 5 years focuses on user facing features for an application being tasked with scaling the application for 2x annual traffic growth, where they may not be equipped to lead such a task.</div><div><br /></div><h4 style="text-align: left;">Example of Functional Skill set being over valued</h4><div><br /></div><div>Conversely, someone who focuses entirely on developing to spec without taking the time to know the context of the ask can lead to a lot of redundant conversation in reviewing rationale for requirements.</div><div><br /></div><div>However, probably the biggest impact of the line of thinking that "someone with the right skill will understand the job quickly" is reflected in the sheer breadth and scope in layoffs that we're seeing today. You want your teams to build institutional knowledge in low stress situations, not in a production incident. A lot of leadership teams are making assumptions that team members are interchangeable with little impact.</div><div><br /></div><div><br /></div><h3 style="text-align: left;">Tech Leadership and poor performance evaluation practices are responsible for the layoffs happening today</h3><div><br /></div><div>Hot Take: The tech industry is ripe with unqualified people in senior level positions commanding amazingly high salaries as a result of performance evaluations valuing little more than the institutional knowledge that they have developed, no matter how myopic it may have been. As a result, the price to productivity is at an all time low. </div><div><br /></div><div>Companies feeling that price to productivity is low are responding with layoffs and lazily blaming remote work. Any seeming culture in complacency is a direct result of management, not generational differences. </div><div><br /></div><div>In the end, having a balanced evaluation process identifying both functional skill and institutional knowledge as key areas of performance and improvement can bring you closer to having a productive team with the right incentives to succeed.</div><div><br /></div><p></p>Chowspecialhttp://www.blogger.com/profile/05113522146511552068noreply@blogger.com0tag:blogger.com,1999:blog-9757236.post-39492850857022651642024-01-21T17:51:00.000-08:002024-01-21T17:51:56.829-08:00Project Success does not equate to Individual Success in Performance Goals<blockquote><p></p><blockquote><h3 style="text-align: left;">Successfully support the <milestone> for the <project name></h3></blockquote><p></p></blockquote><p>Many managers use this boilerplate performance goal for just about any employee. It's lazy. It reflects nothing with regards to the expectations of the employee, nor does it reflect at all, in what way would one grow in their capabilities.</p><h4 style="text-align: left;">Why is it not great to tie project success to performance goals.</h4><div>Simply stating success of a project without identifying how they should be contributing to the project does not set them for success in being able to support the NEXT project on a DIFFERENT team in a more COMPLEX situation. This not only provides no guidance to the employee on what they should be improving upon, but also may not give you, as the manager, the right capabilities in succeeding should any adversity arise.</div><div><br /></div><div><b>Most importantly, many software projects fail due to circumstances that have absolutely nothing to do with the execution of the project.</b></div><h4 style="text-align: left;">Why is project success commonly tied to performance goals</h4><p></p><ul style="text-align: left;"><li>If a project succeeds, the company would make more money, therefore, there's more money in the pool to pay for raises, right?</li><li>A manager's thinking: if a project succeeds, then I succeed, and that means the individuals of the team succeeds right?</li></ul><h4 style="text-align: left;">What should performance goals include instead?</h4><p></p><p>Activity and contribution to a project should be an EXAMPLE of how you want them to be performing.</p><p>Focusing on Software Developers: </p><p></p><ul style="text-align: left;"><li>Three Basics</li><ul><li>Ability to tackle complex challenges.</li><li>Ability to interact with their colleagues in the form of clean code, communication in PRs, and overall communication with the team via chats, email, IRL</li><li>Ability to interact with stakeholders in the form of requirements feedback for clarification and further getting feedback on software behavior. </li></ul><li>The thing that I care about the most </li><ul><li>How accountable are they in production and are they able to observe the behavior of their code out in the wild?</li></ul></ul><p></p><p>If you really want to talk about it in the context of a project:</p><p></p><ul style="text-align: left;"><li>How did they contribute to projects last year, and is there any difference in contribution that htey should be doing in future projects? Spell it out.</li><li>Are these projects more or less complex that last year's projects? How does completing these projects demonstrate their skill set? Explain how this project is a more significant challenge that will test capabilities that haven't been tested before.</li></ul><p></p><p>Bottom Line: Goals should not be effectively "yeah do what you did last year but more". You need to give them explicit skills to level up and a clear example of how you plan to observe it. for some managers, that is solely based on the success of a project, and that's a shitty manager.</p><h4 style="text-align: left;">Soapbox Moment</h4><div>In developing and operating software, it all boils down to how much trust do you have in the employee. When shit hits the fan, will you call on them? When a brand new paradigm needs to be investigated, will you ask them to spike it? When another member of the team is not around, will they be able to temporarily fill in? These should all be straight forward yes/no questions and for the situations your team finds themselves in, you should have a pretty clear list of which members of your team are your primary, secondary, "bench" type people for a given situation. </div><div><br /></div><div>For each of these moments, based on an employees skills, potential, and professional interests, their goals should be balancing enhancing their skill set so that they can contribute more for your team that suits both their interests, capabilities, and team needs.</div><div><br /></div><div>Who said management is easy!?</div>Chowspecialhttp://www.blogger.com/profile/05113522146511552068noreply@blogger.com0tag:blogger.com,1999:blog-9757236.post-31770526452832586582024-01-02T17:12:00.000-08:002024-01-02T17:19:33.177-08:00Support you should expect from HR and your Org in prepping to give a Performance Eval<p>So previously we discussed the importance of being well prepared for your performance evaluation. However, every single different company is different both from an HR perspective and an Organizational perspective. However, they should all be able to provide you some foundational resources in </p><p></p><ul style="text-align: left;"><li>being able to clearly explain why they are getting the performance scores they're getting</li><li>understanding how your eval may impact their salary next year</li><li>understanding how your eval may impact their odds of a promotion next year</li></ul><p></p><h4 style="text-align: left;">What HR Should Provide</h4><div>HR should be able to provide you basic overviews of the current state of your direct report as well as some high level information on the process for </div><div><br /></div><h4 style="text-align: left;">Your direct report's job title (and tier if there is one) as well as their salary and the standard salary band for that title.</h4><div>In many organizations, raise calculations take these 3 things into account along with your performance evaluation. If there is a standard raise calculation, you'll have a decent understanding of what their raise may be.</div><div><br /></div><div><h4>Your direct report's previous performance eval, if available</h4></div><div>It's valuable to review past performance evals, not just to know where they've excelled or struggled in the past, but also to refresh your memory on past goals you've set for them and where their skill set is today versus the previous year. Especially when you observe noticeable improvement (and they're at the same job tier), that should impact your performance score today.</div><div><br /></div><h4 style="text-align: left;">Each Performance Category</h4><div>In general, performance categories are pretty broad from the HR level. This is where your own org and your seniors should be able to provide more granular guidance.</div><div><br /></div><h3 style="text-align: left;">From your org (and your seniors)</h3><div>Rather than "doesn't respond well to feedback", your org can give you more explicit guidance like "do you find yourself repeating yourself over and over in their PRs." In absence of any formal documentation, your org and your own manager should provide you with additional context in how your direct report treats their work and their teammates. </div><div><br /></div><h4 style="text-align: left;">How each Performance Category applies to your direct report's job function</h4><p style="text-align: left;"><span style="font-weight: normal;">This can provide you examples where to look or what to ask about from peers regarding their work. </span></p><p style="text-align: left;"></p><ul style="text-align: left;"><li><span style="font-weight: normal;">Aptitude => Are they entrusted with more complex challenges than others? => do they ever get assigned an 8 point story to oversee</span></li><li><span style="font-weight: normal;">Communication => Do you encounter surprises from them? => system behavior that a product owner did not anticipate and it's already in production?</span></li><li><span style="font-weight: normal;">Versatility / Team Player => do they shy away from duties that may not be their primary? => are they an asshat when they're on-call?</span></li></ul><p></p><p style="text-align: left;"><span style="font-weight: normal;">For each performance category, a discussion of situational example or a behavioral example. Sometimes it's easy to hone in on a specific situation where they may have gone the extra mile or have fallen short, but it's important to make the distinction between what may have happened at a particular instance vs an established behavioral pattern that they have exhibited (and did they improve on it when given feedback about it).</span></p><p style="text-align: left;"><span style="font-weight: normal;"><br /></span></p><h4 style="text-align: left;">Guidance on for gathering feedback if you're not a hands-on manager (because that's how the org structure is)</h4><div>If you do not directly interact your direct report (I mean... that sucks) your organization should provide you with the appropriate tooling to gather feedback from those who are better equipped than you are. Discussion with tech leads and 360 Reviews are decent subjective methods in understanding one's performance. Quantitative tools may be a method to open up a conversation with a tech lead, but generally not a great way to gauge whether one is an asset or burden to their team.</div><div><br /></div><div><br /></div><h3 style="text-align: left;">My HR nor my Org has this</h3><div>lol, buddy. sounds like you get to establish this yourself and set the precedence, should you choose to accept it. Nobody will thank you.</div>Chowspecialhttp://www.blogger.com/profile/05113522146511552068noreply@blogger.com0tag:blogger.com,1999:blog-9757236.post-81598533662875476592024-01-01T14:35:00.000-08:002024-01-05T05:49:06.306-08:00Solidifying Trust when giving Performance Evaluations<p style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">The performance evaluation is the pivotal point of the power dynamic between a manager and a direct report. </p><p style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><br /></p><p style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">In most cases, this is when a manager is making a final decision to move someone to a Performance Improvement Plan or make a recommendation for a promotion. In many cases, direct reports are using this to gauge whether they want to move to another job within the company or apply for a job elsewhere.</p><p style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><br /></p><p style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">The biggest takeaway for this post is to understand why it is extremely important to be blunt in your feedback at this important confluence of expectations, impressions, and receipts.</p><p style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><br /></p><h3 style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt; text-align: left;">A quick look at motivation</h3><p style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">Because this is my first people management post we're going to do a quick primer on motivation and the basic structure to a Performance Evaluation.</p><p style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><br /></p><p style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">There can be 3 categories in an employee's motivation: </p><p style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"></p><ul style="text-align: left;"><li>Compensation</li><li>Authority / Respect</li><li>The work, itself (interesting problem to solve, they like the outcomes the business is driving)</li></ul><p></p><p style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">We're mainly going to focus on the top two, as those are the pieces that a lot of people generally care about, especially earlier on in their careers. In the performance eval, you need to be able to answer </p><p style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"></p><ul style="text-align: left;"><li>Am I going to make more money next year?</li><li>Will I have more authority next year?</li><li>How can I make MORE money the following year? </li><li>How can I have MORE authority next year? </li></ul>Footnote: for many people at certain parts of their career, they're extremely happy where they are financially and in the work they get to do. Being able to confirm that is important. But honestly these people are few and far between.<p></p><p style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><br /></p><h3 style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt; text-align: left;">You can look at a performance eval in three parts.</h3><p style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"></p><ul style="text-align: left;"><li>Explain to them what you, as their manager, can do to help them make more money or get more authority next year</li><li>Review of their performance and how does that impact your decisions.</li><li>What should they be improving upon so that you'd pull the levers at your disposal harder for them?</li><li>Many organizations have goal planning and performance evals as two separate exercises, sometimes months in between. However, </li></ul><p></p><p style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">Many managers just go through the performance metrics and that's it. Just because you filled out the space allotted doesn't mean your work is done.</p><p style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><br /></p><h3 style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt; text-align: left;">Why they are falling short... of a PROMOTION</h3><p style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">9 times out of 10 you will not be offering someone an above average raise or a recommendation for a promotion, and this is where you need to make sure that your understanding of their efforts throughout the year is crystal clear. You need to have the receipts for both situational occurrences where they could have improved and, more importantly, behavioral / skill set patterns that may be preventing them from getting as good an evaluation as they would like.</p><p style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><br /></p><h4 style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt; text-align: left;">Why is it so important to lay it all out</h4><p style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">Everything boils down to trust. The performance eval is the pivotal spot for a manager to make or break the trust that you've been building all year. Your direct report should have a clear understanding about the process, what is in your control, and how their actions drive compensation and career track. The review itself is more reflection of your understanding of their contributions, their impact, and their skillset that allows them to help the team become successful. </p><p style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><br /></p><p style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">Goals set next year are not only a commitment from your direct report on achieving certain goals, but also a commitment from you as a manager that you will ensure that they have the opportunities to achieving them. This is the key mutual relationship between you two that need to be established for both of you and the team to succeed.</p><p style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><br /></p><p style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">It's definitely a balance</p><p style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">All of this is a balance of trust between you and your direct report that if they accomplish what you set for them, you will help them achieve more of what motivates them.</p><p style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><br /></p><p style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">In the end, what you have to be is honest and demonstrate that their work and effort hasn't gone unnoticed. The amount of effort that you put into these reviews is the clearest artifact of your commitment to a direct report's success. If they ever sense that it is half assed, they're on their way out.</p><p style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><br /></p>Chowspecialhttp://www.blogger.com/profile/05113522146511552068noreply@blogger.com0tag:blogger.com,1999:blog-9757236.post-28914779726825108252024-01-01T13:33:00.000-08:002024-01-01T13:33:11.658-08:00Man, it's been nearly 10 years.<p> Alright going to start writing up stuff again so what's happened.</p><p><br /></p><p>Since Grubhub I have been at Paypal where I was absolutely not a good match for the Braintree nor Paypal culture. </p><p>I joined Chowbus an early employee to head their operations and helped them expand up to a Series B round.</p><p>I'm now CTO at Bucket Listers where we're 1 year into operating a ticketing marketplace to promote cool things that are happening in your town.</p><p>All in all I've gotten to really flex on my convictions, some to great success and others to not so great success. I figure I have about 5 years left in my career so let's see where this all goes.</p>Chowspecialhttp://www.blogger.com/profile/05113522146511552068noreply@blogger.com0tag:blogger.com,1999:blog-9757236.post-28503975624796211942015-01-19T07:57:00.001-08:002015-01-19T08:50:10.929-08:00Logstash Examples with Data Generators<a href="http://logstash.net/" target="_blank">Logstash</a> is a pretty cool application that generically takes some input, does something with the data, and spew it out somewhere else.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://logstash.net/images/logstash.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://logstash.net/images/logstash.png" height="200" width="125" /></a></div>
<br />
<br />
It's commonly used in conjunction with <a href="http://www.elasticsearch.com/" target="_blank">Elasticsearch</a>, a Lucene based search service, and Kibana, a dashboard UI for Elasticsearch. You can easily consider this as a "Splunk without super awesome ad hoc query capabilities" but the software itself is FREE so there's that.<br />
<br />
The documentation for Logstash is pretty straightfoward, but I thought it would be nice to have some hard examples to work off of that involved the whole ELK stack:<br />
<br />
<div style="text-align: center;">
<a href="https://github.com/grumpasuarus/logstash_demos" target="_blank">Logstash Examples</a></div>
<br />
Right now it just has two examples: file and log4j.<br />
<br />
File:<br />
<ul>
<li>Write to a file</li>
<li>Logstash monitors the specific file and does some grokking before passing it to Elasticsearch</li>
<li>Load the provided kibana dashboard.<br /></li>
</ul>
<div>
log4j:</div>
<div>
<ul>
<li>Spew log4j stuff out with SocketAppender</li>
<li>Set up Logstash to monitor a port for log4j messages and grok before passing it to Elasticsearch</li>
<li>load the provided Kibana dashboard</li>
</ul>
<div>
So yeah I hope this serves as a quick and easy way for people to observe the awesomeness that is Logstash. Feel free to add your own examples to this guy as well.</div>
</div>
Chowspecialhttp://www.blogger.com/profile/05113522146511552068noreply@blogger.com21tag:blogger.com,1999:blog-9757236.post-9393194282518269722015-01-10T13:23:00.000-08:002015-01-10T13:23:05.645-08:00IT'S A TRAPWife: "How do you think I've been doing with my makeup lately?"<br />
<br />
*pause*<br />
<br />
Wife: "... IT'S A TRAP! No, seriously. You have to answer."Chowspecialhttp://www.blogger.com/profile/05113522146511552068noreply@blogger.com102tag:blogger.com,1999:blog-9757236.post-24351134221984194102014-12-23T08:39:00.000-08:002014-12-23T08:39:46.826-08:00Read the Freaking Documentation to Couchbase!Just wanted to point out a pretty awesome product with pretty awesome documentation:<br />
<br />
<div style="text-align: center;">
Couchbase.</div>
<div style="text-align: center;">
<br /></div>
<div style="text-align: left;">
We're using it for a pretty specific use case and for that, it's handling things extremely well. However, we noticed that it was using a ton of swap space to the point I was thinking we were on Windows boxes.</div>
<div style="text-align: left;">
<br /></div>
<div style="text-align: left;">
Buuuut lo and behold we didn't read all the documentation on how our nodes should be set up and here it is for v2.2 that we're using.</div>
<div style="text-align: left;">
<br /></div>
<div style="text-align: center;">
http://docs.couchbase.com/couchbase-manual-2.2/#swap-space</div>
<div style="text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjt-zmslegCi0fMbkNaLJlrMtdlZV2TLjvLBh0PYiggiykLCQKfrNw8BoL8AaAzTnIl3ZJPwFF5MiPDnmWHDfIrIBM8zK1fq65RQ_PtwrjPi0Mg2GfjXXsne-ctGH4Il-2JDd-Pow/s1600/Screen+Shot+2014-12-23+at+10.33.02+AM.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjt-zmslegCi0fMbkNaLJlrMtdlZV2TLjvLBh0PYiggiykLCQKfrNw8BoL8AaAzTnIl3ZJPwFF5MiPDnmWHDfIrIBM8zK1fq65RQ_PtwrjPi0Mg2GfjXXsne-ctGH4Il-2JDd-Pow/s1600/Screen+Shot+2014-12-23+at+10.33.02+AM.png" height="56" width="400" /></a></div>
<div style="text-align: center;">
<br /></div>
<div style="text-align: left;">
Actually that screenshot is further down in the issues section, complete with impact and JIRA issues!</div>
<div style="text-align: left;">
<br /></div>
<div style="text-align: left;">
It's actually pretty awesome to be able to track something down this easily. Obviously, other people have encountered this that has lead to issues but it's great to see the trail and the resulting recommendation.</div>
Chowspecialhttp://www.blogger.com/profile/05113522146511552068noreply@blogger.com2tag:blogger.com,1999:blog-9757236.post-91904247577761482262014-12-07T13:51:00.002-08:002014-12-07T13:51:32.647-08:00Searching Pull Requests in Stash - You Don'tA pretty popular JIRA Issue for the Stash project is this guy, STASH-3856:<br />
<br />
<div style="text-align: center;">
<a href="https://jira.atlassian.com/browse/STASH-3856" target="_blank">Search for pull requests</a></div>
<div style="text-align: center;">
<br /></div>
<div style="text-align: left;">
Specifically, the only reason why I'm searching for a pull request after the fact is to see if there were any conversation regarding a particular design decision or if there were any explicit things that were abstained from for later work. <br />
<br />
Also, it's a super quick way to see when a given feature was merged into a particular branch like Master.<br />
<br />
With that said, chances are, you're using JIRA alongside Stash. Let's be honest, the only reason to use Stash over other solutions is for its JIRA integrations. If your issues are directly associated with your Pull Requests, you should then be able to easily search your JIRA issues using its robust search features. <br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://confluence.atlassian.com/download/attachments/395707042/OD-development-panel.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="166" src="https://confluence.atlassian.com/download/attachments/395707042/OD-development-panel.png" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">JIRA Development Panel</td></tr>
</tbody></table>
So unfortunately, if you're eagerly awaiting STASH-3856 to be implemented, I highly doubt that they're going to accomplish this any time soon. There are definitely some Stash specific searches that would be nice, such as when a pull request's been merged or dismissed and when it's been updated. However, until then searching for the JIRA issue can resolve the vast majority of people's use cases. <br /><div style="text-align: center;">
<br /></div>
</div>
Chowspecialhttp://www.blogger.com/profile/05113522146511552068noreply@blogger.com0tag:blogger.com,1999:blog-9757236.post-62942760303176697282014-12-02T10:51:00.000-08:002014-12-02T10:51:16.767-08:00JIRA - Old School Greenhopper and Milestone Management with Versions<div class="separator" style="clear: both; text-align: left;">
I wouldn't be surprised if there are still a lot of organizations that are still using the Classic Boards in JIRA Agile to manage their medium to long term plans in JIRA. I want to just go over really quickly how one can manage these in the Classic Board before I talk about a much more complex scenario in a future post and I also want to go over the limitations of this approach.</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="" style="clear: both; text-align: left;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEglnPj2EZluEWucgVjv5C8aZkLjMhio-u2c66XvYDuPGt2N7FYdX4azYEM8tqhCv534nsswOJ3fTeb4AkvoTSgEm6nKYDOHys_alvOOKIZ21C6x9ZvKxvs-MfNM_ERqRX91-tqvHQ/s1600/Screen+Shot+2014-05-02+at+7.19.23+AM.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em; text-align: center;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEglnPj2EZluEWucgVjv5C8aZkLjMhio-u2c66XvYDuPGt2N7FYdX4azYEM8tqhCv534nsswOJ3fTeb4AkvoTSgEm6nKYDOHys_alvOOKIZ21C6x9ZvKxvs-MfNM_ERqRX91-tqvHQ/s1600/Screen+Shot+2014-05-02+at+7.19.23+AM.png" height="173" width="320" /></a><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEglnPj2EZluEWucgVjv5C8aZkLjMhio-u2c66XvYDuPGt2N7FYdX4azYEM8tqhCv534nsswOJ3fTeb4AkvoTSgEm6nKYDOHys_alvOOKIZ21C6x9ZvKxvs-MfNM_ERqRX91-tqvHQ/s1600/Screen+Shot+2014-05-02+at+7.19.23+AM.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em; text-align: center;"><br /></a><br />
First, you'd establish Versions in your Project that represented different Milestones with dates associated with them. From there, you'd have your actual release Versions that are directly associated with the releases that you're cutting.</div>
<div class="separator" style="clear: both; text-align: left;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjKq2Mu8ttGj6dWBcrVvAV0VF3zaaw-QLEt_LQzV6PMKxUmlvRvDQXBGC9my0w2E2I4Zed2mKnVVlFy21ANO6mFEU6XSkKmmNEUFRjs-nyv_7aJ33RCD-UIpphuAV9U6-cGqMo2tQ/s1600/Screen+Shot+2014-05-02+at+7.21.34+AM.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjKq2Mu8ttGj6dWBcrVvAV0VF3zaaw-QLEt_LQzV6PMKxUmlvRvDQXBGC9my0w2E2I4Zed2mKnVVlFy21ANO6mFEU6XSkKmmNEUFRjs-nyv_7aJ33RCD-UIpphuAV9U6-cGqMo2tQ/s1600/Screen+Shot+2014-05-02+at+7.21.34+AM.png" height="217" width="320" /></a>With the Classic Planning Board, using the SubVersion feature, you can readily see which Release versions that build up to Milestones that build up to broader Milestones. You'd associate stories to your release versions and from there, you can track the progress of your Parent Milestone versions.</div>
<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh_zOQC5iZ6ElxYNZ6NiQN-PMk8G3j0mUu7Gs7xR2zEGwLwrVuUkEZpt0dxil6W0nucS1Vvsme8PLwoc79z24v4pzYIDGaizutRPr7YogBsRfIs2n6yjzPlu5fVv4VXlTDeIchk-Q/s1600/Screen+Shot+2014-05-02+at+7.20.07+AM.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh_zOQC5iZ6ElxYNZ6NiQN-PMk8G3j0mUu7Gs7xR2zEGwLwrVuUkEZpt0dxil6W0nucS1Vvsme8PLwoc79z24v4pzYIDGaizutRPr7YogBsRfIs2n6yjzPlu5fVv4VXlTDeIchk-Q/s1600/Screen+Shot+2014-05-02+at+7.20.07+AM.png" height="183" width="320" /></a></div>
<div style="text-align: left;">
I wanted to work this particular feature in here as I still find it to be extremely useful today that few people pay attention to. That is the Merge Version feature. Essentially, if you already established a Patch release and realized that this guy isn't going to be released until the next Minor version, you just merge the Version into that Minor version. From a Git Flow perspective, this would be comparable to the idea that you had a Release Branch prepared but never merged it to Master, but rather, just merged changes (if any) back to Develop.</div>
<br />
<br />
So anyway, the biggest limitation to this approach are the following:<br />
<br />
<ul>
<li>FixVersion in JIRA suddenly becomes an overloaded Term.</li>
<li>This method is limited for a Single JIRA Project.</li>
</ul>
<div>
Specifically, Atlassian realized that using FixVersion for so many different things, especially sprints, was not going to be a good fit for organizations that require some flexibility. That is one of the core reasons why the Sprint field is a new core field for JIRA Agile. Also, when a field starts to mean multiple things, </div>
<div>
<br /></div>
<div>
Organizations can establish JIRA projects in a variety of ways for a variety of reasons. However, when you have two projects gearing towards a common milestone, a lot of organizations start getting into the habit of having versions of the same name in multiple projects and identify them as the same milestone.</div>
<div>
<br /></div>
<div>
This can lead to a lot of confusion and inflexibility in how a new project can be established. Also, you're shoehorning an association between two fields that the system doesn't natively support, you're probably using that field wrong.</div>
<div>
<br /></div>
<div>
<b>Soapbox Time:</b> It's pretty hilarious how we, as developers of software for others to use, really suck at using the tools as they are originally intended. Shoehorning functionality that doesn't exist "just because we want it that way" either means that we're just using the wrong tool or we honest don't know how we want our processes to function. </div>
<div>
<br /></div>
<div>
Anyway, if you are still using Versions in this manner in JIRA Agile, I'd be very interested in what you like or don't like about using this method. Next time, I'm going to cover the more recent JIRA Agile functionality that's be introduced circa 2011 that provide some more flexibility, but still have a lot of limitations.</div>
<div>
<br /></div>
<div>
<br /></div>
Chowspecialhttp://www.blogger.com/profile/05113522146511552068noreply@blogger.com0tag:blogger.com,1999:blog-9757236.post-18414620999184841662014-12-02T09:35:00.000-08:002015-01-10T13:26:08.044-08:00Tracking Multiple Sprint Teams with a Common Goal... or rather, a goal that YOU have that you're depending on other teams to accomplish for you...<br />
<br />
So one thing I feel that people using JIRA Agile should get used to is the notion of building and breaking down Agile boards for targeted efforts to allow them to track something very specific and eventually just get rid of the board when they're done with it.<br />
<br />
Here's a query:<br />
<br />
<b>"Epic Link" in (EPIC-1, EPIC-2, EPIC-3, EPIC-4) OR issue in (EPIC-1, EPIC-2, EPIC-3, EPIC-4) OR labels = myEffortLabel ORDER BY Rank ASC</b><br />
<br />
<br />
What this query essentially means is "Give me these Epics, give me the Issues in these Epics, and give me any issue that I happen to label it.<br />
<br />
<br />
This gives you a quick and hopefully, targeted view of a set of milestones in the form of Epics that you and other teams are driving towards. My personal observation is that the majority of teams pretty much ignore epics and epic links anyway, so establishing this linkage to the actual stories that they are working on should have minimal impact.<br />
<br />
At the very least, you can keep an eye on the general progress of a concerted effort.<br />
<br />
Just remember to clean up after yourself and delete the agile board when it's all said and done!Chowspecialhttp://www.blogger.com/profile/05113522146511552068noreply@blogger.com0tag:blogger.com,1999:blog-9757236.post-24481453737765000522014-07-11T20:18:00.001-07:002014-07-11T20:21:22.755-07:00New Job, New City... so Let's Talk St. LouisSo how long does it take for one to find apply, interview, accept a job, prepare a house for sale, move, and settle down for a weekend?<br />
<br />
About 3 months, apparently.<br />
<br />
BTW, Google "days since april 17, 2014" and you get to a nifty app that tells you how many days.<br />
<br />
So anyway, I don't usually talk about St. Louis on here as that's what's Yelp's been for. Aside from our friends in the area, I'd like to take some time to point out some things that I enjoyed in my 10 years there.<br />
<h3>
La Pizza / Protzel's Deli / Bob's Seafood</h3>
<div>
Mmmmmm....</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://s3-media1.fl.yelpcdn.com/bphoto/jEq8Kqdy8tscDKRU1ml_YA/l.jpg" imageanchor="1" style="clear: left; display: inline !important; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="http://s3-media1.fl.yelpcdn.com/bphoto/jEq8Kqdy8tscDKRU1ml_YA/l.jpg" height="200" width="112" /></a><a href="http://blogs.riverfronttimes.com/gutcheck/lapizza2.JPG" imageanchor="1" style="clear: left; display: inline !important; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="http://blogs.riverfronttimes.com/gutcheck/lapizza2.JPG" height="176" width="200" /></a><a href="http://blogs.riverfronttimes.com/gutcheck/lapizza2.JPG" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><br /></a><a href="https://pbs.twimg.com/media/BgeiYaKCAAEHRRQ.jpg" imageanchor="1" style="display: inline !important; margin-left: 1em; margin-right: 1em;"><img border="0" height="147" src="https://pbs.twimg.com/media/BgeiYaKCAAEHRRQ.jpg" width="200" /></a></div>
These are the 3 establishments that I will miss the most. Not because of what they offered, but the people who worked there. Heck, the La Pizza guys convinced the Bob's Seafood guy to let me pick up 60 lbs of live crawfish on a day they were closed. That's how awesome they are. I think I'll be hard pressed to find places comparable. On top of that, these places were within 5 miles of each other, which leads me to my next point:<br />
<h3>
Regional Convenience</h3>
<div>
Sure, you could talk about what other cities have that St. Louis doesn't have, but if it were in St. Louis, it was dead simple to get there. We lived in a spot where we could get to just about anywhere in the region in 30 minutes or less. Also, 30 minutes typically means ~20 miles away. Seriously. The other day the wife was looking for things within a mile away from our place in Chicago and she was like "that's FAR!"</div>
<div>
<br /></div>
<div>
There's no Mitsuwa in St. Louis, but it might as well be because I have no idea how often we're going to get out that far into the Chicago burbs from the city.</div>
<div>
<br /></div>
<div>
Ok, I'm lying. We have some good friends who live nearby and we'll likely use them as an excuse to go to Mitsuwa at least once a month or so.</div>
<div>
<br /></div>
<h3>
Hometown Pride</h3>
<div>
To be honest, I think just about every single midwest city suffers from some form of inferiority complex. Chicago included. St. Louis is definitely not an exception, but the passion for working towards improving the area is infectious. The atmosphere in the more urban neighborhoods is leaps and bounds more lively and optimistic than they were even a couple years ago. The Loop, the Grove, Cherokee, even Downtown, which many left for dead multiple times in the past couple of decades, all have some pretty significant work going on that I was pretty gosh darned excited for. </div>
<div>
<br /></div>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj7hoY2bbpKmmufwWbFAxRhXzSu2jSCEHCJkTfWAlay4tAz_afqZJg0_zyt_Leu95n22genuVeHlh_farUGYkzsCP4rqWKCg8uwVabkfPD52YXBqmDbpwJ8uMzcxKNSBmNVfdQKFw/s400/IMG_0972.JPG" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj7hoY2bbpKmmufwWbFAxRhXzSu2jSCEHCJkTfWAlay4tAz_afqZJg0_zyt_Leu95n22genuVeHlh_farUGYkzsCP4rqWKCg8uwVabkfPD52YXBqmDbpwJ8uMzcxKNSBmNVfdQKFw/s400/IMG_0972.JPG" height="240" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">View from the top of the City Museum<br />
http://ruff-ranch.blogspot.com/2009/07/city-museum.html</td></tr>
</tbody></table>
STL is one of those areas that is still transitioning from manufacturing to technology and sciences. They definitely have some big trials coming up on the jobs front but there're enough skilled passionate people who actually have loyalty to the area itself to establish themselves and make it work. Square, Woot, and Riot presences past or present were as much personal decisions as business decisions.<br />
<div>
<br /></div>
<div>
St. Louis has been good to us and I have nothing but fond memories of the area. It will forever be the first place I've been an "adult" at and has definitely shaped my outlook on things. See you around.<br />
<h3>
</h3>
</div>
Chowspecialhttp://www.blogger.com/profile/05113522146511552068noreply@blogger.com0tag:blogger.com,1999:blog-9757236.post-26910421965015480622014-04-27T06:42:00.002-07:002014-05-03T22:34:54.977-07:00Microservices! Rorschach Reactions.<a class="g-profile" href="https://plus.google.com/107610341080687821846" target="_blank">+Martin Fowler</a> and James Lewis of <a href="http://www.thoughtworks.com/" target="_blank">ThoughtWorks</a> have a really in-depth and thoroughly thought out article talking about Microservices. There's particularly a nice blurb in it comparing the term to the more generic <a href="http://martinfowler.com/articles/microservices.html#DecentralizedGovernance" target="_blank">SOA</a>.<br />
<br />
The context of this article is kept at a more technical execution level. I'd like to bring up some thoughts on the requirements and communication that can be involved. In reality, this is more of a Rorschach reaction to the pretty awesome images that they had on their article.<br />
<br />
Generally, three things a software development team thinks about are:<br />
<ul>
<li>What is my Deliverable?</li>
<li>How is it going to change over time? What are my requirements?</li>
<li>Who are impacted of my changes? How do I coordinate with them?</li>
</ul>
<div>
However, there's another question that, surprisingly, a lot of IT organizations are still extremely immature at handling:</div>
<div>
<ul>
<li>What deliverables need to be changed for my needs? How do I get those changes to happen?</li>
</ul>
</div>
<div>
Here's a pic from the article discussing a functionally siloed organization and the corresponding Architecture that tends to occur.</div>
<div>
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://martinfowler.com/articles/microservices/images/conways-law.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://martinfowler.com/articles/microservices/images/conways-law.png" height="330" width="400" /></a></div>
<div>
Because of <a href="http://en.wikipedia.org/wiki/Conway's_law" target="_blank">Conway's law</a>, the architecture reflects the org structure, and this is also a representation of how requirements flow. The UI folks have some user-facing use case and they need a service change from the middleware folks, who in turn, need something of the DBA guys. One common disadvantage to this is the further away you are from the original requirement, the more you get some odd telephone game situation going where the API isn't exactly what the UI guys are looking for or the DBAs decide to ignore the middleware guy's model design. This can lead to a lot of churn and rework.</div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://martinfowler.com/articles/microservices/images/PreferFunctionalStaffOrganization.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://martinfowler.com/articles/microservices/images/PreferFunctionalStaffOrganization.png" height="228" width="400" /></a></div>
<div>
<br /></div>
<div>
With a cross functional team, you have teams that are more focused on the use-facing use case, rather than entire groups of people who are only focusing on their immediate deliverable. One excellent point that is also made in the article is that large monolithic architectures can be organized "too many contexts." The article posits that this tends to be a result of cross-functional teams in a monolithic architecture, but I think this happens regardless of how your teams are organized. This is a big reason why we can get a lot of spaghetti logic, where a module may be trying to satisfy too many things at once, as opposed to being split into separate modules.</div>
<div>
<br /></div>
<div>
Something that these pictures also accurately depict is that your cross-functional teams would have fewer people of each function focusing on particular business logic and can likely be working on a particular microservice. Looking at this from a requirements flow perspective, you can potentially get resource constraints (or managers imposing them), which is one of the main reasons why functionally siloed organizations exist to begin with.</div>
<div>
<br /></div>
<div>
This comes back to the questions:</div>
<ul>
<li>What microservices need to be changed for my needs? How do I get those changes to happen?</li>
</ul>
<div>
Do you make requests to a microservice's backlog to be prioritized? How do you deal with that team's resource constraints? How do your requested changes impact other teams consuming that microservice? These questions aren't specific to microservices, but with more granular teams, this amount of "red tape" may seem daunting to more traditionally managed organizations.<br />
<br />
In addition, with that many more deliverables in the form of microservices, ensuring that the consumers of your deliverables are prepared for the changes you're making.</div>
<div>
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://martinfowler.com/articles/microservices/images/micro-deployment.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://martinfowler.com/articles/microservices/images/micro-deployment.png" height="186" width="400" /></a></div>
<div>
<br /></div>
<div>
In the left side for monoliths, consumers of modules have the option to choose which version of the module to include in their process at build/deploy time. On the right side, the consumers have the option to choose which module to utilize by communicating with the appropriate service at run-time. Fundementally, there isn't too big a difference in these dependencies, but operationally, in terms of identifying your dependencies and working with your sys admins on deployments, it is pretty different in terms of how you're communicating changes, dependencies, and to whom you're communicating to.</div>
<br />
It all boils down to how well your organization can communicate across your teams. For a small organization, physically talking or chatting on email or a chat service works out. However, with large geographically distributed teams with potentially different cultures and whatnot, this gets unwieldly very quickly.<br />
<br />
This post is getting long so I'm going to cut it here. I'm not just talking about microservices, I'm talking about any organization that has multiple internal deliverables across teams. How can a large geographically distributed organization, consisting of multiple teams, meet customer expectations while ensuring smooth operation from build, to test, to deploy? I'll run through some thoughts on the challenges and solutions that may fit your given culture.<br />
<br />
<br />Chowspecialhttp://www.blogger.com/profile/05113522146511552068noreply@blogger.com2tag:blogger.com,1999:blog-9757236.post-13706056451132869712014-04-19T08:13:00.000-07:002014-04-20T18:41:37.458-07:00JIRA Shenanigans - @mention Multiple PeopleSo previously, we talked about how the <a href="http://goo.gl/lGfu9r" target="_blank">@mention feature in JIRA is pretty nifty</a>. However, the current feature only allows you to @mention a specific profile, one at a time. Therefore, if you want to keep the conversation going in JIRA, all the participants are going to either need to be @mentioned every single time or they can be added to the Watch List. <br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://blogs.atlassian.com/wp-content/uploads/jira_watchers_and_at_mentions_watch.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://blogs.atlassian.com/wp-content/uploads/jira_watchers_and_at_mentions_watch.jpg" height="244" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Ripped off of<br />
<a href="http://blogs.atlassian.com/2013/06/using-watchers-and-mentions-effectively/" target="_blank">Atlassian Blog</a></td></tr>
</tbody></table>
If you have the appropriate permissions, you can add specific people to the Watch List yourself. They may not appreciate it, but if they don't want notifications, they can always take themselves off. I think this would be particularly interesting in how they improve upon their HipChat JIRA integration, but I digress.<br />
<br />
Enter an open request in JIRA to <a href="https://jira.atlassian.com/browse/JRA-28225" target="_blank">@mention a group</a>. This makes sense in that JIRA allows one to configure groups of profiles to be identified in various permissions, mapped to project profiles, and notifications. However, there isn't a view-only permission for groups or a way for a user to resolve the group to list of profiles, so the burden is up to the JIRA Admin to set things up, maintain them, and let others know who the group members are. There's an <a href="https://jira.atlassian.com/browse/JRA-11009" target="_blank">open request for this guy as well</a>.<br />
<br />
To take things further to allow more flexibility, I submitted a request for <a href="https://jira.atlassian.com/browse/JRA-37793" target="_blank">@mention to a Project Role</a>, allowing each project to determine which profiles or which groups should get a notification. <br />
<br />
Fortunately, there's a pretty dead simple way around this, which is to create a dummy profile whose email address is an email distribution list. <br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjBv9DZaJos0JLcbTOIZ6fA9GBYEaHfAYeBRC-0NgM-BupKI9z_P7INyeLx0Qzy18R3hhYWdYThmERCNcx_5-SNkFmIQvmgX7yXM2FwlZCLCxSYoTilMuqBF1_F3kqCUARdarA7qA/s1600/Screen+Shot+2014-04-13+at+10.05.41+AM.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjBv9DZaJos0JLcbTOIZ6fA9GBYEaHfAYeBRC-0NgM-BupKI9z_P7INyeLx0Qzy18R3hhYWdYThmERCNcx_5-SNkFmIQvmgX7yXM2FwlZCLCxSYoTilMuqBF1_F3kqCUARdarA7qA/s1600/Screen+Shot+2014-04-13+at+10.05.41+AM.png" height="40" width="400" /></a></div>
<br />
<br />
There are definitely quite a few issues/limitations with this approach. Some of the immediate things that come to mind are:<br />
<ul>
<li>It will be dependent upon your email setup as to who can view the members of the list and who can edit it. This is all dependent upon your organization.</li>
<li>This takes up a slot in you JIRA user license.</li>
<li>Unless you actively have a user for this distro in an externally managed system like LDAP or Active Directory, this requires you to create the user in the JIRA User Directory. This may require some admins to fenangle with their current setup.</li>
</ul>
<div>
So as always, one of the easiest ways to keep up with the features that you want in any of Atlassian's tools is to add yourself to the watch list in Atlassian's own JIRA issues vote on them. @ mentions can definitely be improved upon but the tool can only be as good as the feedback the developers get from those actively using it.</div>
<br />
<br />Chowspecialhttp://www.blogger.com/profile/05113522146511552068noreply@blogger.com0tag:blogger.com,1999:blog-9757236.post-64405052971986196232014-04-13T05:52:00.001-07:002014-04-13T17:19:23.509-07:00JIRA Shenanigans - @mentions are better than EmailOne feature that has drastically changed the way we use JIRA among a geographically distributed team is the @mention feature. This allows one to specifically notify someone: "hey I think this is important you should read this."<br />
<br />
We all hate the telephone game and accountability is pretty important. This is enforced in a strong way from Alice in this Dilbert comic:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://dilbert.com/dyn/str_strip/000000000/00000000/0000000/000000/00000/1000/500/1562/1562.strip.gif" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://dilbert.com/dyn/str_strip/000000000/00000000/0000000/000000/00000/1000/500/1562/1562.strip.gif" height="123" width="400" /></a></div>
<br />
The thing is that there are a couple issues with E-Mail. The main thing is that it only resides in the inbox/outbox of the recipients/sender, preventing any normal person from taking a look at the conversation later on. You'll get the whole "oh there's a thread floating around I'll forward it to you" scenario.<br />
<br />
Especially when an email is just between two people, you run the risk of some valuable communication being lost when both are not around for whatever reason that may occur.<br />
<br />
Enter JIRA Comments. Having the conversation there provides a couple things. It's a public forum so people tend to be a bit nicer there. It's query-able, as all Issue fields are, and they persist so long as nobody deleted the issue. <br />
<br />
There's this nifty <a href="https://confluence.atlassian.com/display/JIRA/Emailing+an+Issue#EmailinganIssue-mentions" target="_blank">@mention feature</a> that you can use to direct a comment at someone. This provides a notification to someone (usually in the form of a an email) with the comment. However, this adds the context of the JIRA issue and the rest of the conversation. Some annoyances from this feature comes when you're in a thread with multiple people and you want to ensure that everyone gets a notification. In this situation, <a href="https://confluence.atlassian.com/display/JIRA/Watching+and+Voting+on+an+Issue" target="_blank">Watch Feature</a> can be used to then keep up with the conversation as well as other changes.<br />
<br />
After I wrote up all that (and most of the next post) I stumbled upon this blog post by <a class="g-profile" href="http://plus.google.com/100463253648746183903" target="_blank">+Dan Radigan</a> that concisely describes <a href="http://blogs.atlassian.com/2013/06/using-watchers-and-mentions-effectively/" target="_blank">using @mentions and Watchers effectively.</a> In addition, it also has some nifty queries to help people find posts that they were mentioned in as well. Definitely check it out.<br />
<br />
This post is getting long and I want to talk about how @mentions only allow you to notify one person at a time. Wouldn't it be nice to quickly and easily notify a bunch of people at once? Well, as of this post, JIRA doesn't support that, but there's a pretty nice workaround. I'll get to that next time.Chowspecialhttp://www.blogger.com/profile/05113522146511552068noreply@blogger.com0tag:blogger.com,1999:blog-9757236.post-67649395286406200092014-04-11T06:53:00.001-07:002014-04-13T06:02:08.316-07:00KineticJS on ChromecastPretty lame looking video of my getting <a href="http://chowspecial.blogspot.com/2014/03/idlewild-boat-race-clone.html" target="_blank">that Idlewild Boat Race Clone</a> on Chromecast, but I thought that was cool.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<iframe allowfullscreen='allowfullscreen' webkitallowfullscreen='webkitallowfullscreen' mozallowfullscreen='mozallowfullscreen' width='320' height='266' src='https://www.youtube.com/embed/EWLHAnYoeJY?feature=player_embedded' frameborder='0'></iframe></div>
<br />Chowspecialhttp://www.blogger.com/profile/05113522146511552068noreply@blogger.com0tag:blogger.com,1999:blog-9757236.post-37747838116664708122014-04-05T06:18:00.004-07:002014-04-05T06:19:06.184-07:00Why Story Points are Cool<div>
Sure. Dilbert Comic.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://dilbert.com/dyn/str_strip/000000000/00000000/0000000/000000/00000/1000/800/1804/1804.strip.sunday.gif" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://dilbert.com/dyn/str_strip/000000000/00000000/0000000/000000/00000/1000/800/1804/1804.strip.sunday.gif" /></a></div>
<br />
<br />
So to carry on the conversation where some people are saying that estimates, in general, are a waste of time, I'd like to cover some situations where having Story Points are particularly useful.</div>
<div>
<br /></div>
<b>Do we agree on the requirements?</b><br />
You really shouldn't need an excuse to drag product/business end users, qa, and developers to have one last sanity check on some requirements. Getting everyone to agree, at the very least, what the requirements ARE and taking the next step to cover some technical detail as to what the effort would be. You definitely don't want "the expert" to do the estimation as this is a method of risk mitigation of "expert getting hit by bus."<br />
<div>
<br /></div>
<div>
<b>Do I have enough ready-to-work Stories in the Backlog?</b></div>
<div>
As a product owner, you need to know whether you have enough stories pokered and agreed upon by the team for the next sprint. This is dependent on knowing your team's average velocity, whether people are going to work vacation days, etc. <br />
<br />
Also, depending on your team's process, a Product Owner can ensure that the backlog consistently has a decent amount of low point stories that the team can incorporate into their own sprint. This is for teams that have the rule that a developer can bring in a story after the sprint start only if they think they can complete the added story within the same sprint.<br />
<br /></div>
<div>
<b>When are we done with Planning?</b><br />
Pretty much exactly the same thing as the previous point. More importantly, when can you end the planning meeting? <br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://a3.mzstatic.com/us/r30/Purple/v4/60/c2/34/60c234a0-45a0-d502-204e-fa1ff950789b/screen480x480.jpeg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://a3.mzstatic.com/us/r30/Purple/v4/60/c2/34/60c234a0-45a0-d502-204e-fa1ff950789b/screen480x480.jpeg" height="213" width="320" /></a></div>
<br /></div>
<div>
<br /></div>
<div>
<b>Where Story Points don't help:</b><br />
One scenario where Story Points may just be superfluous, and that is when a team typically breaks a story down to the point where they are all essentially equivalent levels of effort. This exercise is particularly useful for teams with extremely short sprint times. This all depends on what your team wants to accomplish and how they want to accomplish things. However, if just about all stories are broken down to 3 point stories, you are still running through the exercise of Pokering, but rather than asking the question "what's the level of effort for this story," you're asking "is this story a 3 or not?"<br />
<b><br /></b>
<b>... but don't get too focused on those Points</b></div>
<div>
It's really easy to latch onto some quantitative value and to start drawing conclusions. People are going as far as to asking "why are we FAILING our COMMITMENT?!" In the end, Story Points are just a tool to help us answer the following, but not used as the ONLY metric to answer:</div>
<div>
<br />
<ul>
<li><b>Are we meeting customer expectations?</b></li>
<li><b>Is there any action we can take to improve?</b></li>
</ul>
<div>
This is really hard to drive home for a lot of people and you're likely going to have a couple "electrolyte" conversations but it is truly worth it.</div>
<div>
<br /></div>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://s3.amazonaws.com/lardbiscuit/pix/agfunbags.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="161" src="https://s3.amazonaws.com/lardbiscuit/pix/agfunbags.jpg" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">... but what about our commitment?</td></tr>
</tbody></table>
<div>
<br /></div>
</div>
<div>
Either way, I hope this will provide some ideas for Product Owners in particular in using Story Points to help manage not just their own day-to-day work, but also drive home that it's just a tool to aid in efficiency and identify potential areas for improvement. We should never become slaves to our estimates.</div>
Chowspecialhttp://www.blogger.com/profile/05113522146511552068noreply@blogger.com0tag:blogger.com,1999:blog-9757236.post-42904906280548450012014-03-31T07:01:00.000-07:002014-03-31T07:03:21.175-07:00Whatever Happened to Risk when We Went Agile?There seems to be some sort of rallying cry that Story Points and, in general, estimates, should be gotten rid of entirely from any sort of software development process. I think this is, generally, a very strong kneejerk reaction to some pains through the development and release process in terms of managing expectations.<br />
<br />
Usually said pains come from someone managing expectations in the following manner:<br />
<br />
<ul>
<li>A Release is planned with a set number of User Stories define</li>
<li>Said user stories are pokered </li>
<li>Project Manager compares the sum of the user stories against the team's velocity and converts that into sprints - let's say they determined that it sums up to about 4 sprints.</li>
<li>Project Manager sets a release date approximately 4 sprints from now.</li>
<li>Project Manager attempts to hold team accountable to the Release Date. The word "commitment" seems be the word of choice, lately.</li>
</ul>
<div>
The most glaring issue with this situation is something that doesn't get mentioned a lot in the agile process: accounting for risks when managing expectations.</div>
<div>
<br /></div>
<div>
We've all probably seen various different risk charts that show likelihood vs. impact with mitigation plans associated with each. These have all but disappeared. Granted, I'm not saying that a team should get back to long drawn out risk powerpoints, but it's the team's responsibility to bring up these risks. It's usually the project manager's responsibility to communicate these risks out.</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://img.docstoccdn.com/thumb/orig/29872355.png" imageanchor="1"><img border="0" src="http://img.docstoccdn.com/thumb/orig/29872355.png" height="226" width="320" /></a></div>
<div>
I get the impression that a lot of agile teams have lost sight of actively tracking risk and reflecting it back to project stakeholders. It's not like they've gone away because you're doing Scrum. </div>
<div>
<br /></div>
<div>
Here's my unscientifically backed opinion on medium to long term estimates: shoot from the hip estimates in terms of resources and man-hours from an experienced manager, in conjunction with a development leader or two, is just as good as a thoroughly pokered out backlog. You take a look at it from a high level, identify some risks, and based on what you know from the team, manage the expectations of the stakeholders. </div>
<div>
<br /></div>
<div>
Some may argue that more vague stories with point values far exceeding your sprint threshold are just as good. I actually don't have much direct experience in trying that, but it would also be something to think about. When you get story points that are as high 100 points, to me that's pretty much the same as a shot from the hip.</div>
<div>
<br /></div>
<div>
The last thing you want, however, is to attempt to define all the lower level user stories at the beginning. You will find yourself spending an arduous amount of time at once to try to estimate something months in advance and opening yourself to the challenges that impact Waterfall.</div>
<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://dilbert.com/dyn/str_strip/000000000/00000000/0000000/000000/20000/0000/800/20867/20867.strip.sunday.gif" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://dilbert.com/dyn/str_strip/000000000/00000000/0000000/000000/20000/0000/800/20867/20867.strip.sunday.gif" height="283" width="640" /></a></div>
<br />
<br />
In the end, it all boils down to plain ole communication, including the appropriate people in the decision making process, and getting buy-in for the final decision. At the very least, you didn't spend an ungodly amount of time holed up in a room trying to think of every single thing for the next couple of months. <br />
<br />
So why poker at all? Well, there are a boat ton of uses where pokering, with Story Points in particular, is very useful. This post is getting long so I'll talk about how they help smooth out the process from sprint to sprint in the next post.<br />
<br />
<br />Chowspecialhttp://www.blogger.com/profile/05113522146511552068noreply@blogger.com0tag:blogger.com,1999:blog-9757236.post-12796035303150691682014-03-22T08:32:00.001-07:002014-03-22T17:44:05.707-07:00JIRA Shenanigans - Attach Screenshot FeatureIf there was a feature in JIRA that was both awesome and not-awesome at the same time is the Attach Screenshot feature. For an organization whose culture, for some reason, has been imbued with pasting screenshots into word documents, and then attaching the word documents in ALL of their tools, the attach screenshot feature can be both a time-saver for both the one reporting the Issue and the one consuming it.<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjI50swnpe5KFJbF441hJ5qunAS_On_PAnSzrj1VfdHypCgCXNXS-tk8LsECg8ogQlz_78T9gp7QfLvYQ6IyYMok7xNc_oetcOVA5bLl7J37ZVgE2tKdBbMVYJGxcCG8bXezDAKPQ/s3200/Screen+Shot+2014-03-22+at+9.48.39+AM.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjI50swnpe5KFJbF441hJ5qunAS_On_PAnSzrj1VfdHypCgCXNXS-tk8LsECg8ogQlz_78T9gp7QfLvYQ6IyYMok7xNc_oetcOVA5bLl7J37ZVgE2tKdBbMVYJGxcCG8bXezDAKPQ/s3200/Screen+Shot+2014-03-22+at+9.48.39+AM.png" height="61" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;"><strong style="background-color: white; border: 0px; color: #222222; font-family: Helvetica, Arial, Verdana, sans-serif; line-height: 18.979999542236328px; margin: 0px; outline: 0px; padding: 0px; text-align: start; vertical-align: baseline;">ಠ_ಠ</strong></td></tr>
</tbody></table>
<div>
<br /></div>
<div>
Of course, one can point you to JIRA Capture, which, I'll admit, is a super awesome tool for testing web applications and contains a slew of features to aid QA in recording their test sessions and providing visual aids to others of what they're observing. </div>
<div>
<br /></div>
<div>
Convincing an organization to drop more money on a tool is very hard, so let's get back to why the Attach Screenshot feature can be a pain:</div>
<div>
<br /></div>
<div>
<b>Chrome and 64-bit Java + other Java Shenanigans</b></div>
<div>
<br /></div>
<div>
<a href="https://confluence.atlassian.com/display/ONDEMANDKB/Attach+Screenshot+not+working+with+Chrome+and+Java+7" target="_blank">Here's one of the issue documented with this Java Applet (oh right, it is a Java Applet).</a></div>
<div>
<br /></div>
<div>
So straight out of the box, if you like to use Chrome and if you only have 64-bit Java installed, the applet will not work. If you're not the admin to do the solution I'm going to describe below, you're going to have to do some configuration.</div>
<div>
<br /></div>
<div>
JIRA has historically been a tool directed at more technically minded users, but this specific limitation is extremely tough to get some people to A) find a fix on their own and B) actually be able/willing to fix it. </div>
<div>
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://weknowmemes.com/wp-content/uploads/2012/07/what-do-we-say-to-the-java-update.jpeg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://weknowmemes.com/wp-content/uploads/2012/07/what-do-we-say-to-the-java-update.jpeg" height="179" width="320" /></a></div>
<div>
<br /></div>
<div>
<br /></div>
<div>
Additionally, you can easily get the question:</div>
<div>
<br /></div>
<div>
"Why should I work so hard to get a tool that we PAID for to work the way I want it to?!"</div>
<div>
<br /></div>
<div>
My answer to that is that most people don't realize other comparable tools cost way more without the customization capability, but nobody wants to hear that. It then isn't surprising that this very same culture will lead people back to the word doc attachments (without even considering that they can attach saved images). It is quite the endless cycle of violence.</div>
<div>
<br /></div>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://assets.diylol.com/hfs/cb3/af2/3b3/resized/one-does-not-simply-meme-generator-one-does-not-simply-install-linux-4ade56.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://assets.diylol.com/hfs/cb3/af2/3b3/resized/one-does-not-simply-meme-generator-one-does-not-simply-install-linux-4ade56.jpg" height="188" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">I didn't pay for Linux so it's OK that I have to <br />
spend hours to make it do what I want!</td></tr>
</tbody></table>
<div>
<br /></div>
<div>
So is JIRA going to fix this? Indeed they are! As of this posting the issue is "In Progress" so I'm hoping it shows up in their next minor version. </div>
<div>
<br /></div>
<div>
<a href="https://jira.atlassian.com/browse/JRA-31917">JIRA Issue: "Rewrite screenshot applet using not-java"</a></div>
<div>
<br /></div>
<div>
Fortunately, we don't have to wait for the next version of JIRA to get this feature. Atlassian Labs has a plugin <a href="https://marketplace.atlassian.com/plugins/com.atlassian.plugins.jira-html5-attach-images">in the Marketplace</a> that isn't dependent on any 3rd party installation. </div>
<div>
<br /></div>
<div>
Better yet, if you have troubles in your organization with making upgrades to existing tools (aka you're not going to make an upgrade to JIRA even if this feature is availble), you can install this plugin on older versions of JIRA.</div>
<div>
<br /></div>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjCcPRu4dV3QVJNL0REYZrvqcZQQ3yZDHs9_JE_6og01QmyX9RcI0xlhTrkKI9UxkM6q7t25XJ-odgLRTVVnGzm4IrmO8y3g1OnWyirv314z0uIBLOYYoLpbfMlb8eTYYPFSa3Vlw/s3200/Screen+Shot+2014-03-22+at+10.18.05+AM.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjCcPRu4dV3QVJNL0REYZrvqcZQQ3yZDHs9_JE_6og01QmyX9RcI0xlhTrkKI9UxkM6q7t25XJ-odgLRTVVnGzm4IrmO8y3g1OnWyirv314z0uIBLOYYoLpbfMlb8eTYYPFSa3Vlw/s3200/Screen+Shot+2014-03-22+at+10.18.05+AM.png" height="229" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Ripped off the Marketplace page</td></tr>
</tbody></table>
<div>
Getting a feature that works right away for all users is the best way to get adoption and can aid in quashing that Broken Window affect that may be plaguing your cultural processes. </div>
<div>
<br /></div>
<div>
While you're at it, definitely check out other features that Atlassian Labs has developed that may go into future versions. Find the appropriate feature request in JIRA, watch it, and upvote it. The more you use Atlassian's JIRA as a user, the more you can figure out how it can help your organization.</div>
<div>
<br /></div>
Chowspecialhttp://www.blogger.com/profile/05113522146511552068noreply@blogger.com1tag:blogger.com,1999:blog-9757236.post-84171772900157727542014-03-17T07:36:00.003-07:002014-03-22T17:44:15.182-07:00Random JIRA Shenanigans #1 - Development PanelI've decided to start putting in random JIRA configuration notes in here that may be of use to some people:
JIRA's 6.2 release has a pretty sweet feature called the Development Panel with a lot of great features if you're using Stash and other git tools.
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://confluence.atlassian.com/download/attachments/395707042/OD-development-panel.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="166" src="https://confluence.atlassian.com/download/attachments/395707042/OD-development-panel.png" width="320" /></a></div>
Unfortunately, we're not using any of those tools.<br />
<br />
BUT, we are using Fisheye 3.3.1 and the big bonus with this feature is that it explicitly shows us the branches an issue is being worked on. Technically, because we're using Gitflow, it shoooould be one branch...
<br />
<br />
Either way there were a couple of finicky things that we had to do that wasn't explicit in the documentation to make existing integrations with Fisheye/Crucible continue to work as expected.<br />
<br />
Initial Configuration<br />
<br />
<ul>
<li>Fully Trusted Applications Links between JIRA and Fisheye</li>
<li>All Users in Fisheye are in JIRA (but not the other way around.) Fisheye uses JIRA User Directory for Authentication</li>
</ul>
<div>
Final Configuration</div>
<div>
<ul>
<li>Edited Application Link between JIRA and Fisheye</li>
<ul>
<li>Disabled Trusted Application Link</li>
<li>Enabled 2-Leg OAUTH</li>
<ul>
<li>Impersonation Enabled.</li>
</ul>
</ul>
</ul>
<div>
The first finickiness was that I didn't have Trusted Applications disabled in the Application Link. This prevented the Development Panel to show up to begin with. A quick hit on Atlassian Answers gave me an answer:</div>
</div>
<div style="text-align: center;">
<a href="https://answers.atlassian.com/questions/271928/jira-6-2-with-fisheye-3-3-1-no-development-panel" target="_blank">Atlassian Answers Question</a></div>
<div style="text-align: center;">
<br /></div>
<div style="text-align: left;">
The next thing, however, was a little odd. I did not have Impersonation Enabled with 2-leg OAUTH. In hindsight I don't even know why I didn't do it, but when people were attempting to close their code reviews in Crucible, they were seeing this guy:</div>
<div style="text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhwt5EXMAHV9xCtfjLtFn2_-AvZumbbN5EBPHdFJZ0w-vRzafumUnlJMM7W9CACpdI6x6bqRNyarcFOi30CFcHDlu3HHJEBz34SEA8BWdwihk6oo3lQ2M82v3rCatgFX1ik3uLUXw/s1600/Screen+Shot+2014-03-17+at+9.33.17+AM.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhwt5EXMAHV9xCtfjLtFn2_-AvZumbbN5EBPHdFJZ0w-vRzafumUnlJMM7W9CACpdI6x6bqRNyarcFOi30CFcHDlu3HHJEBz34SEA8BWdwihk6oo3lQ2M82v3rCatgFX1ik3uLUXw/s1600/Screen+Shot+2014-03-17+at+9.33.17+AM.png" height="138" width="400" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
Fisheye was having an issue getting specific data for an issue in JIRA. Enabling impersonation did the trick to allow users to transition the appropriately linked issue if so desired. Specifically, because Fisheye's user base is entirely based off of JIRA's user base, we didn't have any issue with Fisheye utilizing this feature when interacting with JIRA.</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div style="text-align: left;">
<br /></div>
<div>
<br /></div>
<div>
<br /></div>
Chowspecialhttp://www.blogger.com/profile/05113522146511552068noreply@blogger.com0tag:blogger.com,1999:blog-9757236.post-66088481324645835232014-03-07T09:18:00.002-08:002014-03-28T06:41:23.112-07:00Idlewild Boat Race CloneSure. I'm going to say that Atwood's Law applies here.
<iframe allowfullscreen="" frameborder="0" height="315" src="https://dl.dropboxusercontent.com/u/13398746/boat_race_receiver.html" width="100%"></iframe>Chowspecialhttp://www.blogger.com/profile/05113522146511552068noreply@blogger.com0tag:blogger.com,1999:blog-9757236.post-80704293139275656852014-03-06T17:45:00.000-08:002014-03-07T07:22:39.809-08:00Things We're Exposed to as Children that We Forget for WorkOh Bert'n Ernie. I'd like to think that I am Bert most of the time, but I'm sure I'm guilty of being Ernie when describing the rationale for requirements to others.<br />
<br />
<br />
<div style="text-align: center;">
<iframe allowfullscreen="" frameborder="0" height="315" src="https://www.youtube.com/embed/W_2Ky_nU2ys" width="420"></iframe></div>
<br />
<br />
If you didn't catch Harrison Ford make a reference to this with Glenn Close you need to watch Air Force One NOW. But seriously. Expectations management is hard. Scope creep is a bitch.<br />
<br />
<div style="text-align: center;">
</div>
<div style="text-align: center;">
<iframe allowfullscreen="" frameborder="0" height="315" src="https://www.youtube.com/embed/nn_Y_iiN5m8" width="420"></iframe></div>
<div style="text-align: center;">
<br /></div>
<div style="text-align: left;">
This was the best Telephone game video that I could find on Youtube. It's surprising how often you see everyone in the room take little notes in their note pads to take off to their teams on what happened. Heck, I've seen this happen when people enter things in a spreadsheet, and then someone else has their own spreadsheet, and they work together to make one AWESOME spreadsheet!</div>
<div style="text-align: left;">
<br /></div>
<div style="text-align: center;">
<iframe allowfullscreen="" frameborder="0" height="315" src="https://www.youtube.com/embed/9_iSvZi1BGo" width="420"></iframe>
</div>
Chowspecialhttp://www.blogger.com/profile/05113522146511552068noreply@blogger.com0tag:blogger.com,1999:blog-9757236.post-11986383727523011972014-03-01T07:40:00.001-08:002014-03-28T06:40:54.425-07:00User Stories - Asking some QuestionsIf you're looking for me to spell out what specific elements a User Story should have, I'll just point you to test framework called Cucumber where you write "Cukes" to describe the behavior you're testing. When thinking about how you're going to test something, the User Story becomes pretty apparent.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://avatars.githubusercontent.com/u/320565" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="200" src="https://avatars.githubusercontent.com/u/320565" width="200" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">http://cukes.info/</td></tr>
</tbody></table>
<div style="text-align: center;">
<br /></div>
But rather, when Business Analysts, Developers, Product Owners, whoever is writing user stories, there are a key questions to ask that can drive what your User Story should look like and more importantly, what supplemental information may aid in the development process.<br />
<br />
<b>Whose problem are you trying to solve or alleviate?</b><br />
<b><br /></b>
If this isn't the first question you're asking, you might as well go home. Now. You're home? Step outside. Walk a block. Ok. Go home. Look at cukes again. I'm not saying you should be using Cucumber for your test framework, but they have very good ideas.<br />
<br />
<b>How can someone validate this?</b><br />
<b><br /></b>
See the cukes. <br />
<br />
<b>Who's Going to Consume Your User Story? Who participates in the release cycle? Who are responsible for validating your implementation against the User Story?</b><br />
<b><br /></b>
To me, these are all the same question. However, you may get different answers to these questions, depending on who you're asking. This is something that's very specific to your project and organization. However, all the people that may be identified as answers to these questions can benefit from reviewing the User Story. Why is that useful? How often do you find yourself having to demonstrate a feature to someone to explain to them what the feature is? How often are THEY then demonstrating it to others to explain to them what the feature is? Your organization can have a slew of handoffs where a clearly defined User Story can save time and reduce the Telephone Effect. Here's an overloaded example:<br />
<br />
<div style="text-align: center;">
<b>Product Owner -> Developer -> QA -> Training/Documentation -> Support</b></div>
<br />
In a conversation the other day, an IT manager that supports a huge bio-research organization mentioned that the largest challenge towards their adopting Scrum was that [non-developers] think that it's "just for developers." Without diving any further into the specifics, I feel that this is due, in large part, to some organizations not disseminating User Stories out to non-developers. In a more Waterfall environment, you may have a very extensive requirements and design document... that nobody reads.<br />
<br />
One potential pitfall for a User Story when it's "just for developers" is when someone, in reality, is simply writing a technical task to be done. With that, I simply point back to Cukes again.<br />
<br />
<b>Do you need buy-in for your User Story?</b><br />
<b><br /></b>
This heavily depends on your organizational culture and how much trust everyone puts into the Product Owner. However, when seeking feedback, identifying potential gotchas, or simply being able to come up with a better design, answer the following as part of your supporting material can greatly provide food for thought.<br />
<br />
<ul>
<li>What's the current behavior?</li>
<li>Why is it not optimal / desired at all?</li>
</ul>
<div>
When working towards buy-in for your User Story, it not only helps people feel more valued, but also increases the organization's trust in your being able to identify the overall direction of the product.</div>
<div>
<br /></div>
<div>
With that last sentence, if not to be more efficient, increase organizational cohesion, and increasing clarity in the process, just simply thinking about these questions when writing User Stories can make your life easier when people trust you more.</div>
<br />
<br />
<br />
<br />
<br />
<br />Chowspecialhttp://www.blogger.com/profile/05113522146511552068noreply@blogger.com0tag:blogger.com,1999:blog-9757236.post-53450309231916089012014-02-02T09:02:00.000-08:002014-03-28T06:40:26.749-07:00User Stories - How they're UsefulAll too often, organizations spend a stupid amount of time talking about what information should go into User Stories and how their content should be structured. They forget to ask the question, what do we want User Stories to do for us?<br />
<br />
Typically, people see Users Stories as a tool to answer one question: "What do the developers need to code?"<br />
<br />
<div>
In a TDD oriented environment and, surprisingly to a lesser extent, when there is a separate QA team, User Stories, people use User Stories to answer the next question: "What needs to be validated to accomplished our goal?"<br />
<br /></div>
One question that doesn't get asked, though is "How do we keep the Product Owner accountable for what we produce?"<br />
<h2 style="text-align: center;">
<b>"That's not what we talked about."</b></h2>
<div>
When demo happens, what's demoed may not match what the Product Owner may have in mind. When this happens, the conversation can quickly devolve into a "well you said..." conversation where there is no record. This both negatively impacts the team's relationship with the Product Owner and wastes valuable time.<br />
<b style="text-align: center;"><br /></b>
<b style="text-align: center;">Stories provide a snapshot of requirements at a given sprint.</b><br />
<div>
<br /></div>
With a recorded User Story, the team and Product Owner can review the Story, review what was discussed in the story (ideally relatively close to when work started), and move forward.<br />
<ul>
<li>What was ambiguous in the Story?</li>
<li>What Questions did we not ask? What did we not write down?</li>
<li>How can we improve on our stories the next time?</li>
</ul>
<br />
By improving the story development process, a team can greatly reduce rework and avoid contentious conversations with the customer.<br />
<h2 style="text-align: center;">
<b>"Is this behavior by design or is it a bug?"</b></h2>
Far into the future into production support, the User Story can further aid in answering the super contentious question: <b>"Is this behavior by design or is it a bug?"</b> This is a pretty overloaded question.<br />
<ul>
<li>When was this feature originally developed? </li>
<li>What was the expected behavior at this time?</li>
<li>Does the observed software behavior meet this?</li>
<li>Do current customer processes meet these?</li>
</ul>
The longer this question is discussed without any hard answers, the greater the negative impact it can have on the Team/Product Owner relationship. This question also greatly impacts whether the solution will be an End User behavior change, a bug fix (typically paid for by the Team budget), or a new feature (typically paid for by the Customer's budget).<br />
<br />
Without these scenarios in mind, User Story development can easily have a Fire and Forget mentality. This can lead to a lot of avoidable costs and negative impacts on customer/team relationships. Next time I'll talk about more questions people should think about when performing User Story Development.</div>
Chowspecialhttp://www.blogger.com/profile/05113522146511552068noreply@blogger.com0tag:blogger.com,1999:blog-9757236.post-10068627212792751442014-01-26T08:41:00.003-08:002014-03-28T06:40:09.518-07:00Cost Beyond Code #2Some quick feedback <a href="http://chowspecial.blogspot.com/2014/01/costs-of-software-beyond-code.html" target="_blank">on my rant</a> mainly wanted some examples of a costly situation that is a result of poorly managed requirements. I'm going to use a lot of "probably's" and "likely's" so just bear with me :P<br />
<br />
<h4 style="text-align: center;">
The Project</h4>
<div>
<br /></div>
<ul>
<li>Requirements are maintained in word docs on a shared drive (not Sharepoint) where the filenames are along the lines of "Release - June 2007" that nobody's opened in years. Essentially, they're practically un-browseable and un-searchable in any decent amount of time.</li>
<li>These requirements were never formally reviewed by anyone. People would show those groups like QA and End User Trainers "how it should work" in a 1 hour meeting.</li>
<li>Developers tend to "own" things where one feature set is entirely done by a single guy. No recorded code reviews.</li>
</ul>
<h4 style="text-align: center;">
</h4>
<h4 style="text-align: center;">
The Costly Situation</h4>
<div>
<br /></div>
<ul>
<li>Some piece of software has a feature that has been working in production for a couple years.</li>
<li>An odd behavior comes up it is keeping an order from being Billable. For arguments sake, it is a scenario that hasn't come up in an extremely long time and there's no documentation in the IT Ticketing system of how this was resolved the last time.</li>
<li>The guy who coded it is no longer with the company.</li>
<li>None of the "expert" users know how the software SHOULD react in the given scenario.</li>
</ul>
<div>
<b>Cost #1: Operations</b></div>
<div>
The earlier you have that money in the bank, the earlier you're making more money for you. If this is visible to the customer, you run the risk of their simply cancelling and going with a competitor.</div>
<div>
<br /></div>
<div>
<div>
So let's say this IT ticket rises through the different levels of support and reaches you, the developer.</div>
</div>
<div>
<br /></div>
<div>
<b>Question #1</b> - Have we ever encountered this scenario before? What did we do last time?</div>
<div>
<ul>
<li>If you're pretty immature about your requirements maintenance, chances are you're pretty immature about your bug tracking too. For me, this is a classic example of a Broken Window phenomenon in a software development project.</li>
</ul>
<div>
<b>Question (set) #2</b> - Why is this happening? Is it a bug? Did the requirements cover this when the feature was developed?</div>
</div>
<div>
<br /></div>
<div>
There's absolutely no reason for you to look up the requirements. You're not going to try to wade through 10's or even hundreds of Word docs that were meticulously documented but whoever wrote them didn't really think about how to reference back to them. If you're not a developer, the one thing left to do is at least dork around in the stage environment to reproduce the issue.</div>
<div>
<br /></div>
<div>
<b>Cost #2: Support Investigation</b></div>
<div>
Even if the issue is reproducible, without the requirements from when this feature was developed, you probably can't answer the question "is it a bug?" "Why is this happening?" Without the context of the requirements, reproducing the issue can be a significant challenge.</div>
<div>
<br /></div>
<div>
You're still going to need a developer to look into this. However, it is extremely likely that in this scenario the first 2 questions aren't even asked so one could argue that this cost in labor isn't even accrued. :P<br />
<br /></div>
<h4 style="text-align: center;">
<b>OK DEVELOPER SAVES THE DAY. Not Really.</b></h4>
<div>
<br />
Ok you're investigating the code to answer Question #2. You're likely wading through code you're unfamiliar with. At this point a lot of people will argue that this like ability of the investigator, coding conventions, and quality of code will impact how efficiently this investigation will be accomplished.</div>
<div>
<br /></div>
<div>
<b>Question #3 - </b>What is the context of this code?</div>
<div>
<br /></div>
<div>
Commit messages can help. Code quality can help. However you likely don't have any linkage from a commit message to the actual requirement. That would come in handy, but like we said, that stuff isn't there for you. So the differentiation between "this is by design" or "this is a bug" is close to impossible. It's going to take you some time to figure out what's going on in the code, describe it to somebody, and hopefully have a solution on what the user should do to keep the Order moving forward.</div>
<div>
<br /></div>
<div>
<b>Cost #3: Developer Support</b></div>
<div>
What could have been answered from a requirements lookup has now extended to any other full-up bug investigation in reproducing an issue and passing it onto a developer. You're going to have some back and forth between the developer and others in terms of trying to answer "why is this happening" question.</div>
<div>
<br /></div>
<div>
<b>Question #4 - </b>Is this by design?</div>
<div>
<br /></div>
<div>
You can't tell. Chances are this will be dependent upon your opinion of the guy who wrote it. Either way, it's going to be pretty hard to answer this question. It will be up to some pointy haired person to decide that it is a bug that needs to be resolved right away in the code, that the business needs to update their procedures to be aware of this scenario, or that some behavior change is required to go through some other channels of funding.</div>
<div>
<br /></div>
<div>
<b>Cost #4: Aftermath - </b>Because you haven't come up with what the requirements were at the time the feature was implemented, you can't hold the business accountable for what discussed, reviewed, and implemented. It is generally easier to get a customer to swallow the "this is by design" story if you have the documentation to back yourself up and simply update their processes. </div>
<div>
<br /></div>
<div>
Some people will say that some email will be required to accomplish this but that's in lieu of a decent requirements tracking system. Without this documentation, you're likely going to take up some time to discuss whether it's a bug (money from the IT Bucket) or a new feature that needs to be implemented (money from the Business Bucket). </div>
<div>
<br /></div>
<div>
Either way, in order to move forward, the relationship between business and IT runs more smoothly if the conversation goes down the path of "ok now we know what the thought was when we implemented this, but we'd still like to submit a change request," vs. "we're going to just have to agree to disagree so what are we going to do about it?" </div>
<div>
<br /></div>
<div>
There are a lot of pieces that need to be in place to reduce all the costs identified. However, requirements that are clarified, reviewed, and traceable are key to making all those pieces be in place (and alleviate the cost of that too).</div>
<div>
<br /></div>
<div>
A common reaction of all of this is <b>"Documentation is always out of date when the code is implemented"</b></div>
<div>
<br /></div>
<div>
This is what User Stories in a Scrum process are meant to alleviate. I'll talk about this in some User Story post, but I'm already getting requests for describing the costs of getting a Release out after a Release Candidate has been cut so that might just be my next post.</div>
Chowspecialhttp://www.blogger.com/profile/05113522146511552068noreply@blogger.com0