I won't go into methodologies ad nauseum -- much of the web seems to be doing that anyhow; I have noticed, however, some interesting ideas during my readings of those many articles already out there.
I've recently heard of/read about SAFe; I was familiarized with Scrum and Agile when attending the 12-week bootcamp this past fall. SAFe employs a couple (very) different approaches to the Agile way of thinking as opposed to typical Agile or Scrum. Specifically, I was interested in how SAFe employs what they call extreme programming -- it's working pretty hard on how I'm beginning to think about approaching code.
Where Agile approaches projects with the rejection of top-down "waterfall" thinking, thereby allowing a more agile or flexible workflow; SAFe tries to operate on a much grander scale and accomplish the same goal. A major difference I see is how SAFe employs Extreme Programming (briefly described below).
Another difference is that SAFe teams do not work independently or autonomously. They instead rely heavily on pair-programming, and they constantly expect changes to come down the pike. There is certainly a difference in mentality I see here: the code is never quite finished, but it doesn't need to be finished -- it just needs to work. Optimization is left until the end of the project -- almost like a clean-up phase.
I'm sure Extreme Programming is nothing new in the great scheme of things, but it blew my mind.
Simplicity: Where traditional code thinks constantly about the future desiring reusability above all else, XP cares about the simplest code possible. It gambles on the needs of today over the possible needs of tomorrow. In other words, writing good, readable and simple code is favored over writing incredibly clever code (not to say the two are mutually exclusive).
Testing: XP requires all code to be tested; a bug is not considered a "flaw in logic" but an element of code that was not tested.
Continuous: The mentality that the job is never finished until the fat lady has left the building; teams expect the job to change. XP works on short bursts (very Scrum-like ain't it) in the hopes that this will improve productivity.
Bastard Scrum is a home-brew methodology I implemented which is based on both SAFe and Scrum -- basically, it consists of the usable parts of the two beforementioned and applied to a one to two-man operation.
In short, a team of one must still be as organized as a team of 400 -- it may just not be as apparently obvious. While you don't need to hold stand-up meetings with yourself, you must allow time to make those Ivy Lee-style to-do lists!
It helps me to break down these to-do lists into very short Sprints, usually 1-week long, and to also use Trello or Github Issues to track progress and goals. This works well with a two-man or three-man team to boot.
Finally, I like the idea of XP focusing less on best-future-code practices and more on a simple and readable "get-her-done" mindset. This reduces anxiety about what I'm coding; I'm focused more on moving the project forward and less on how much I'll eventually need to refactor everything.
Published: 2017-01-11