Crazy little thing called Jira

Old School Scrum board.

As an agile coach, I have learned to consult the agile manifesto whenever I get stuck on how to proceed.  When I changed firms, I moved from a company which used Azure DevOps to one which used Jira.  It was a bit of a shock.  Fortunately, after working with the tool and reading the book “Agile Software Development with Jira,” I feel comfortable enough to work in a busy software shop which uses Jira.  The experience gives me additional insight into the differences between the two tools.  I want to talk about that insight this week on the blog.

Before I begin, it is necessary to have full disclosure. I have spent a majority of my career working with Microsoft products.  In 2008, I made the switch from Visual Source Safe 2005 to Team Foundation Server.  I have worked with the tool as it has grown and changed into its current incarnation Azure DevOps.  I also know members of the DevOps “Blackshirts,” at Microsoft and one of my mentors for the last ten years in this business runs a blog called “The TFS Whisperer." In short, I have a serious professional and cognitive bias toward Azure DevOps.  I have even authored a blog defending TFS from a blogger who considered it “destroying development capacity.”  If I were the CIO at a company, I would prefer Azure DevOps vs. Jira.

Now that I have confessed my bias, I am going to attempt to set it aside and try to compare the tools.  The first thing which sticks out to me about Jira is the ability to configure it.  When you create a project in Azure DevOps you have three off the shelf templates; Scrum, Agile and CMMI.  The templates can be customized, but it is clunky and requires a developer to do the work.  In my ten years working with Azure DevOps, I have not been able to do that task.  With Jira, they have the concept of workflows, and they are configurable.  I have witnessed project professionals’ fight about the configuration of workflows.  Azure DevOps allows you to configure boards with custom status columns referred to as “board columns,” but to update them, you have to view sprint backlogs or product backlogs to change them.  I consider this a serious limitation of the product and hope someone from Microsoft can show me how to do that inside a story or bug form.

The next issue is Jira has three types of backlog items; bugs, stories, and issues.  Azure DevOps only has two.  In Jira issues and stories behave in the same way.  I find this confusing, and I am observing my development community creating “tickets,” with no preference for them being stories or issues.  Off the shelf, Jira does not have tools to track git push/pull data.  You need to install a “hook.”  Build automation, and CI/CD features are also absent.  I find this absence to be a major stumbling point for Atlassian.  I should be able to track a story with code changes and build information seamlessly.

Finally, Jira appears to be very good at an individual project with one team, but it struggles at scale.  Issues, Bugs, and stories can fit into Epics, but there is no concept of a “feature,” or “area,” in Jira.  It makes it hard to “roll-up” stories into Epics for the business to easily see.  It also makes it hard to manage large backlogs because a backlog can only accommodate one team.  If you are attempting SAFe or LeSS you struggle to see dependencies between teams and how they time to larger product.  I am sure this is my lack of experience showing.

I do not consider Jira an anti-pattern or a necessary evil.  It is just a tool.  Like any tool, it can be used in a harmful manner and create serious damage.  As a coach, I need to be able to respond to change over following a plan.  Jira is certainly a change from how I am accustomed to working.  Fortunately, my agile coaches and mentors have given me a good working knowledge of how to manage a backlog.  If the stories and vision are clear, it does not matter what project management tool you use.  Jira is good enough, and I will accept it because working code in production is more important than the work item tracking tool which manages the process.

Until next time.

Agile and Scrum Prevent You From Cutting Off Your Own Hands

You can learn a lot about software from a table saw.

Over the weekend, my father and I collaborated on a woodworking project for my home.  As I have grown older, I appreciate the time I have with him.  Over the last seventy years, he has acquired plenty of wisdom.  He likes to share it with me from time to time.  This week I want to share my father’s wisdom with you.

We were working with a table saw constructing a gaming table for my house.  I am intimidated by power tools.  I am afraid of injuring myself or someone else.  My father said, that my fear was justified but I needed to get comfortable with power tools because, “It isn’t any harder than writing software,” he joked.

After a few hours on the table saw, my father mentioned, “We have plenty of wood son; you only have two hands,” At this moment, I realized this bit of wisdom also applied to software and Agile.

Too often, software developers are trained in isolation learning to work by themselves.  They do not learn to work with others and once they basics are mastered they develop their own “style” of programming which is often incompatible with other programmers.

You also do not see formal training in Test Driven Development and debugging code.  I realize now this is like not warring safety goggles when you are using a power tool.  The “commando code” style many developers learned needs to go away because when something goes wrong it really goes wrong with that style.

Unit tests make sure that if a class changes and functionality is disrupted a developer can find and diagnose the problem.  Otherwise, it could take hours to track down and fix the problem.  Source control systems such as Git and TFS exist to make sure everyone is working on the same code set.  This prevents one developer from overwriting the changes of another developer.  Finally, design patterns like SOLID, make sure that developers have a common reference point to discuss the architecture of software.

As a junior and intermediate developer, I rebelled against these practices.  Now that I am a senior developer and scrum master, I embrace them.  My career is testimony to this change of heart.  I have broken software builds, destroyed production servers, and over billed numerous credit cards.  The results of this carelessness were long bouts of unemployment and financial hardship.  To put it mildly, I have figuratively cut off my hand more times than I can count.

So to my fellow Scrum Masters and developers.  Slow down there is plenty of wood but you only have two hands.  It is advice, I should have followed years ago.

Until next time.

The Power of the Pivot

Sometimes you have to stop getting punched in
 the face to realize you need to make a change.

The life of a Scrum Master or Entrepreneur is filled with uncertainty.  Today’s sure thing becomes tomorrow’s dead end.  This is why I wanted to devote to this week’s blog to the power of being flexible.  In the parlance of Silicon Valley start-ups, pivoting is powerful.

According the Agile manifesto, responding to change is more important than following a plan.  This seems counter-intuitive at first but when you work in the software business for a while you understand why agile people say this.  I can’t remember how many times I have been involved in a course of action is a software project where I have been futility swimming upstream.  A slight course correction or change of approach would have sped up the project and led to success.  Unfortunately, project flexibility was not built into the project and as a developer I was doomed to work on a failing project.

If leadership was more flexible and willing to make changes in light of the current situation the chance of success might increase.  This is where we get the term pivot from.  I learned about it from a fantastic article from Vanity Fair about the purchase of Instagram by Facebook.  I highly recommend the article to anyone willing to learn about adopting to change.  In summary, Instagram’s CEO Kevin Systrom had numerous bouts of failure and frustration.  It was only after he pivoted his firm toward photography and filtering that he was able to find the success he was seeking.

I remember reading this article on a plan ride home from a corporate off site meeting.  I witnessed the new organizational chart and saw five people named project managers who I had personally trained to use Team Foundation Server.  I also noticed that I was not going to lead a software team.  I felt humiliated and my career was at a dead end.  I was filled with anger and frustration.  Something had to give, and it was clear to me that it would have to be my career at my old firm.  I got together with a few of my mentors in the agile community including Alan Dayley and they gave me the support and encouragement which I needed.  Within a month I had changed jobs and become an architect and scrum master at another company.  It is one of the few times in my career I can look back and say I did the right thing.

So my lesson is that sometimes you need to pivot to be successful. Blindly following a plan will lead to nothing be frustration and misery.  If something isn’t working try something else.  We invest too much into the sunk costs of our lives.  By pivoting or responding to change instead of following a plan, we gain a fraction of our lives back and learn to find success.  It is not as neat and orderly as we would like but in an uncertain world it is the only thing we have.

Until next time.

Why I Use TFS 2010

Team Foundation Server 2010 is not a muscle car.

Developers are a temperamental and combative in nature.  Many business people justifiably treat us like the troll under the bridge due to our gruff and matter-of-fact way of addressing controversy.  Some of us even look and smell as bad as these mythical creatures.  Nothing inspires more troll like behavior than developers debating which technology or tools are superior.  Another chapter in this ongoing discussion came from Derek Hammer and his blog “TFS is destroying your Development Capacity.”  This article is well footnoted, inflammatory, and filled with plenty of reasons not to use Microsoft’s Team Foundation Server 2010 or TFS for short.  I want to take time to answer some of his criticisms and explain why I am sticking with TFS for my business. 

Hammer’s criticisms are fairly clear:

1)      TFS version control is frustrating to use.
2)      Bug Tracking is hard to use.
3)      TFS is not flexibile enough for Agile project management.
4)      The build system is clunky.
5)      Finally, the vertical integration of the product makes it impossible to use best practice tools.

Let us start from the beginning, if you grew up in the business with Visual Source Safe and Visual Source Safe 2005, you will understand that TFS is a quantum leap forward.  Code can be exclusively checked out to one developer or several developers can work on the same code and merge it together.  Also the ability to branch and merge code is clean and easy to understand.  This makes it possible to have code in development, staging and production environments existing in source control.  This is a huge help if a problem crops up in production and it cannot be reproduced in the other environments.  The label and history functions make things easy to track and using project settings forces developers to comment check-ins and associate check-ins with work items. 

Hammer does have some legitimate gripes.  TFS forces you to be connected to the server via your “workspace.”  This is a bit of a pain for people who think source controls consists of copying and pasting folders.  Fortunately, this criticism will soon be moot because the next version of TFS will allow you to work locally and then connect to the server to synch changes.  He also talks about a simple four window three-way merge.  Personally, I have not seen this and I did not even know it was a standard.  I would like to see an example of this.  Please leave a link in the comments. 

Next, Hammer dislikes the bug tracking system.  This was what sold me on TFS.  Work items, bugs and tasks can be entered via Visual Studio or the web site which is built into the system.  The web interface in no more difficult than SharePoint and customer service reps can easily be trained on how to fill out the information.  Finally, TFS has its own API so if you are not happy with the interface you can write your own web form or MVC application to place bugs into the system. 

Moving on to Hammer’s third criticism, TFS is not suited to Agile management.  My biggest challenge as a developer and consultant has always been having the client adopt any kind of Project Management Operations.    This is particularly true in the organization that thinks project management consists of leaning over a cubical wall and asking a developer to build a website.  Thus, TFS is a fantastic introduction to agile and its principles.  I still use a white board for the project team however; TFS helps creating excel reports for management a breeze.  Also, I create custom reports all the time to view specialized data.  When I was at a client, I act as scrum master entering data into the system and leading the project.  I also spend a lot of time training others on how to use TFS to get the most out of the system.  For a mature Agile teams, TFS may seem like an impediment but for companies just getting started, it is the perfect set of training wheels.

Next, Hammer talks about how the build engine is clunky.  Without any reservations, I can agree with his criticism.  In my nearly two years working with TFS, the build system has frustrated me the most.  Often, I simply rely on Microsoft Visual Studio’s publish tool, web.config transformations and FileZila to get work done.  Fortunately, I see this changing.  The Chicago ALM group had a great meeting on Sept 14^th 2011 illustrating how to customize the build process and I look forward to more people coming forward and sharing their knowledge of the subject.  Until then, I am sticking with FileZila. 

Finally, Hammer criticizes the vertical integration of the product and how it is endemic of “The Microsoft Way.”  It has been my sad experience that most people who make decisions about technology are not technologists themselves.  Thus, they are not thinking about best practices or better ways of doing things.  To this kind of individual vertical integration is a perk and not a defect.  With TFS, they see and all in one package that is easy to install and does what is required of it.  This leaves it up to the technologists to us the tool they have been given as best they can.  If that means we write web apps for the customer service people to put bugs into the TFS system and we run reports each week and send them out as excel, so be it.

Let us compare software to automobiles for a moment, Hammer sees TFS as a clunky minivan which gets people from point “A” to point “B” with little speed or flash.  What he wants is a sport car where he can open the hood and swap out engine parts for better performance.  Talk to any Mom and they will tell you when push comes to shove they will settle for the minivan.  This is why most businesses are moving to TFS as well.   It may not be sexy and flashy but it gets the job done in a way technical and non-technical people understand; this why I am sticking with TFS.  I understand the tool.  I know that I can train other developers how to us it.  Finally, it makes sense to business people who usually pay the bills. 

As someone who used to be a troll under a bridge, I understand Hammer’s perspective.  Now as I begin my own company and transition to working with C-Level executives, I see that there is more to a technology decision that just the technology itself.