Brandon's Notepad

February 13, 2018

Agile: Online Resources

ShortURL: http://wp.me/pb7U7-2SJ


This is a list of interesting articles and videos concerning Agile Software Development. I have read, watched, or listened to each one. They have been added here because I found the content useful, either in my current situation or for future discussions. Expect the list to grow.


Articles

The articles and ‘blog posts listed below are grouped by topic, but the topics are in no particular order. I tried to find the originating article for a topic (if possible) and then list below it (indented) other articles that respond to or built upon it.

Videos

At the moment, the list of videos is less-stringently organized than the articles in the previous section. The reason is that there are far fewer videos worth watching than there are articles to read, and I tend to favor long videos, which shortens the list even further.


 

Advertisements

January 30, 2018

Agile: A Conversion Story

ShortURL: http://wp.me/pb7U7-2SK


This is the story of how I became an Agile convert. After sixteen years of denial, I finally opened my eyes to the benefits of this wonderful framework. Writing this post was a very humbling experience. I was seriously tempted to blatantly rip off Kubrick and title this post How I Learned to Stop Worrying and Love the Scrum.


My first exposure to Agile was sometime in 2001 in the form of XP (Extreme Programming). I was active on several developer discussion forums at the time and XP started coming up as a topic more and more frequently. One of my favorite discussion points was the need for proper traceability from concise, structured requirements to design elements and ultimately to code. XP, with its paper-based story cards strewn about on tables or cork boards and then entombed in boxes or banded stacks when the project was over, seemed to mock the sheer beauty and efficiency of a well-maintained requirements database that could be easily searched and reported upon. And paired programming? What a waste of developer hours! Why dedicate two people to a single programming task? What kind of coder needs someone constantly looking over his shoulder and critiquing every little typo anyway? I conceded that such foolishness may be tolerable for small applications or short-term engagements, but it would never work for real applications, the stuff of corporate I.T. projects that took many months or even years to deliver.

I happily ignored Agile for many years after that. Doing so was easy, as none of my clients or employers used any of the Agile frameworks, that is, until about four years ago when the new CIO at my company started talking about it…a lot…and not as a joke. No one in the department seemed to be taking him seriously, so I dismissed the notion that it would actually take hold, but I also knew that I could no longer flat out ignore Agile. If the CIO was talking about it, then I had to make sure he (and everyone else) knew that adopting it would be a mistake. I didn’t want to look like I wasn’t willing to be a team player, but I also didn’t want to throw away all of the hard work we had invested in creating a very stable and controlled development environment. That CIO left the company within a year. An interim CIO seemed to like the Agile concept, but admitted openly that he had no plans to change the strategic direction of I.T., preferring to “keep the lights on” and let the permanent replacement call the shots. Whew! We were safe. So I thought. The new permanent CIO, though not heavy in development experience, arrived already convinced of the efficacy of Agile.

Any attempt to derail Agile at this point would have been what we call a serious CLM (career-limiting move). It was time to adapt. But how? Our development, test, and release policies and procedures were hardly what you might call Agile-friendly. Frankly, our Project Management policy read like an excerpt from the PMBOK. I had no idea what this was going to look like or where to even start, When one consultant started managing his development team using Scrum, I asked to shadow him so that I could learn more about how Agile was supposed to work. I admit, I would not have been disappointed had I found evidence confirming my previous notions about Agile, but I attended the team’s events with an open mind and tried to leave my skepticism at the door. By the time he left for his next assignment, I still wasn’t convinced that Agile was going to be the right fit for our department, but I had learned enough to understand how it might work if everyone got used to it and agreed to play the game.

My biggest takeaway from this exercise was that, in terms of software development, Agile wasn’t significantly different from traditional development (i.e. the waterfall methodology), in that requirements still had to be gathered, software designed, code written, the product tested, and user documentation produced. What was radically different was that it severely limited the scope of these activities for a specified, short-term period of time; thus, it allowed for course correction at any point should (read: when) requirements change.  I learned that requirements needn’t be quite so formal or design so rigid, and that documentation can be limited to a sane amount that might actually be read again later. I still felt like a lot of useful information — mostly artifacts from the development process useful internally in many ways — was going to be lost in the process.

A few months passed and I continued to monitor the growing use of Agile within the development teams. By this time, most of them had latched onto Scrum terminology in particular. Overall, things didn’t seem to be going well. The teams were struggling with many different things, and it was becoming obvious that most of them were not truly adopting the Agile mindset. Then a golden opportunity arose! I managed to volunteer to be the Scrum Master on one of the teams. “As long as it doesn’t interfere with your regular duties,” my boss said as he gave me permission to fill the role temporarily. The project was failing and the team disjoint, so I figured it was going to be a serious opportunity to experiment and see what Agile could do to improve the situation.

The first sprint was rocky and I spent half of my time figuring out how to produce a proper burndown chart in the task management system we had selected. With the second sprint I began every daily scrum with the burndown chart on the large screen in the conference room. The (positive) impact this made on the team was shocking. Tired of watching me update tasks with hours spent and hours remaining, the team started keeping their own metrics up-to-date sometime in the third sprint. By the fourth sprint, we were “flying by instrument” as I like to put it. It was beautiful! The sprint backlog (in hours) was at about 85% of capacity, leaving a little wiggle-room for error, and we trended downward more-or-less as one might expect. I’d love to report that the project had made a sweeping turn just in time and became a stunning success, but sadly, it did not. Despite the great strides the team had made, it was not happening fast enough, and management pulled the plug on our experiment. The software was eventually released for production use, late, using conventional project management, but I walked away with a completely new perspective. I finally understood why and how Agile worked! I was no longer a critic, but an advocate.

Within two months, half of the department (including myself) had been formally trained and I jumped fast at the chance to be on the Agile transformation team that would be responsible for the formal adoption of Scrum. Half a year later, I earned my certification. Looking back, it amazes me how quickly my view of Agile changed so completely. I have since learnt a great deal beyond what was covered in training, but I will have to write about such things another day.


 

January 19, 2018

Agile: My Journey

ShortURL: http://wp.me/pb7U7-2SF


About a year before I wrote this post, I set out on a journey that I was not expecting to take. I became seriously involved in Agile software development, the Scrum framework to be more specific. Prior to that time, I was not only completely uninvolved, I was an outward opponent of Agile as a result of my initial exposure to Extreme Programming (XP). What changed? Where am I headed now? That’s all part of my story.

This is a work in progress. If you find what I have posted so far to be interesting, please feel free to follow me on Twitter and/or WordPress.com.


My Journey

In the spirit of Agile, I’ve decided to document my journey in the form of stories, the sum of which constitute an epic. Cute, eh? No, I didn’t plan for it to happen this way. The stories have just emerged. This is the landing page. As I publish the parts of my story, I will link the posts to the list items below. This will take time. I am still on the journey.

  • My Conversion Story
  • Why Agile Works
  • I think I’m missing something here…
  • A (Hard) Lesson in Writing Stories
  • Let Them Eat Cupcakes
  • Team Working Agreements
  • more to come…
  • The Agile Blogger

I’m building a list ofAgile Online Resources as I go, which contains links to interesting articles and videos that have helped me on my journey.

My Goal

As with all of the content on this site, my primary goal is to record my personal notes on this topic for later use. A secondary goal is to make this information available to anyone who may find it useful. Another huge personal benefit is that the preparation required to write on this topic almost ensures that I will ingest the material

Why Now?

So, why am I writing about Agile in 2018? It’s been seventeen years since the Agile Manifesto was penned, and even then, some of the Agile variants had already been in use for ten years or more. Agile isn’t new anymore, it’s not the next big thing. In the grand scheme of things, I arrived on the Agile scene quite late and I am far from being an expert (yet). The answer is that this post (and its related content) is as much about me and my experiences as it is about Agile itself. I’d like to think that this makes the material unique, but I know that I am following where many other developers have already trod. Nonetheless, I hope that writing my thoughts will provide value.


 

December 27, 2017

The vi Text Editor

ShortURL: http://wp.me/pb7U7-2QA
Home > My Lists > Technology > Software Development References > The vi Text Editor


User Guides & Tutorials

Tips & Tricks

  • Insert contents of another file into current file using :r filename
  • Open second file in split window using :sp or :vsp. Use Ctrl+w to switch between window panes.

September 14, 2017

TFS / VSTS Customization

ShortURL: http://wp.me/pb7U7-2DL


I started working heavily with Microsoft Team Foundation Server (TFS) in the summer of 2016 and may be migrating to Visual Studio Team Servcies (VSTS) in the not-so-distant future. The need to customize TFS operations was almost immediately obvious, and the complexity of the customization only increases in proportion with the use of the tool. This page is a (growing) list of links that I’ve found useful.


Runtime Environment Variables

Environment variables are available for use during both build and release operations. These are my go-to references when I need to figure out how to get to runtime data.

Marketplace Extensions

The Visual Studio Marketplace offers many useful extensions for TFS & VSTS. Some implement or extend features such as dashboards, but the ones I’m most interested in (at least for now) are the build and release tasks. Like apps on a smart phone, these little gems eliminate the need for writing extensive scripts to compile code and deploy products. I’ve found it important to check the Marketplace often for new items as well as for updates to extensions already in use.

Favorites

Futures

Forgo

  • Hopefully, I won’t have to add any extensions in this section.

Custom Scripts & Extensions

If you can’t find what you need in the Marketplace, you can always write your own deployment scripts and extensions. These can be published or retained for internal use only, your choice. Here is a list of useful resources for beginners.

Extensions

Powershell

REST API

More to come…


April 30, 2009

Software Development References

Filed under: Information Technology,List,Programming,Software Development — Brandon @ 7:05 am

Home > My Lists > Technology > Software Development References


Collections

Analysis & Design

Programming

Version Control

Compilation

Packaging

Other


Blog at WordPress.com.