104 karma · joined October 22, 2013
My attitude when looking strictly at agile doctrine is a mix of skepticism (especially after having learned and practiced agile for around 15 years now) and thinking, "Hummm...they might be onto something..." I don't often criticize the written word of how people try to describe agile, but instead try to understand "what were they trying to say?"
A point of illumination for me as to which parts of agile I was most interested in developing a deeper practical knowledge of, happened after I watched a few documentaries on Skunkworks, and how that group operated. Robert Kelly's 14 Rules and Practices does (to me) have a lot of conceptual similarities with the manifesto, especially when you see how they were practiced on some of the most difficult technical challenges humans have ever faced:
http://lockheedmartin.com/us/aeronautics/skunkworks/14rules....
I think that if someone were to pin me down and say "Tell me the doctrine you follow!!!!" and I was forced at gunpoint to give a simple single answer I would point to Kelly's 14 Rules over the manifesto.
A deeply unfortunate fact of the agile's history is that the C3 system wasn't really very successful by just about any dimension:
https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compens...
I've been told by many of Agile Manifesto acolytes that the C3 project's less-than-stellar results don't matter, but I personally think it does. At a minimum, at least you can point to Kelly's Skunkworks team, and see how they shaped modern history with their inventions and ability to deliver improbable solutions on an impossible schedule.
In summary, where Kelly's 14 and the Agile Manifesto & Principles conceptually overlap, I believe there is much worth learning.
https://neilonsoftware.com/2016/07/13/a-far-too-brief-rough-...
Yes, a specific date is absolutely what every manager at every level in the organization wants. As long a payroll is issued bi-weekly, and earnings reported quarterly, the desire for a fixed date will be a thing.
The issue is, fixes dates when it comes to new software development is a fantasy. If you really, really wanted to talk to experts about hitting dates, I'm thinking that a well-funded initiative done in collaboration with 3 of the 4 branches of the U.S. military and the most respected innovator in aviation technology would be where you would go to find them. I would like to offer up the F-35 Joint Strike/Fighter program as exhibit 'A'. Turns out, despite all that funding and discipline (and threats of what will happen if you miss a deadline), they still can't hit their dates. If they can't, what hope do we have? That's not a rhetorical excuse - that's a real question.
Is the answer Agile? Personally, I don't think it is. I think Hollywood has a far better model that anyone else does (pre-production -> production-> post-production). To get new ideas, I study how specific movies are made. One of my favorite case-studies is how they did "Max Max: Fury Road" (lots of storyboards - lots and lots and lots of storyboards). "But hollywood movies are always late/overbudget!!!", yes - which is my point. They know that and have specific adaptions that make this process work decade over decade - and generally a hell of a lot of cash in the process. At a minim, if Agile ain't workin' for everyone, we've got to try to get new ideas from somewhere. My personal choice is Hollywood.
If "The Dude" wrote a response to Ian0's original question, I would think it would have a similar sentiment to mine, though far more concise: "Yeah man...but, you know - no man."
Re: Modules, generally I do as well, but what is a "module"? A function? A class? A library? A plugin? An extension? A listener? A handler? A subscriber? A publisher? A DAO? A DTO? An in-memory service? A networked service? A microservice?
The philosophy that I subscribe to is continuous integration is not the same as "everyone check into the same branch anytime they want as often as they want" but also that it is not "everyone work in their own branch until time has run out and we have to force all of our stuff to work together." That middle ground can be very tough to find, but I find that if the CI system and the architecture are not designed to work together, devs will always thrash around between those two extremes.
My thought is as follows: McDonalds is designed around the core idea that people are fungible and that mediocrity is optimal result (by "mediocrity" I mean no better, but no worse than the average hamburger). I do not believe that software development resources are fungible due to the high degree of creativity and independent decision making required to strike the best balance of quality and time-to-market, and often mediocre results can hurt companies during critical stages of growth.
With that in mind, do we then say "If resources are not fungible and results cannot be mediocre then process cannot exist"? My answer is "no." A lack of resource fungibility does demand an individualized approach to training new resources on the process as it exists at a point in time, but provided resources do not change, the process itself should not change much outside of evidence-based optimization, i.e. "this ain't workin' so we better change somethin'"
To me, process is about expectation management. Every other aspect of a process is in support of maintaining or exceeding expectations. I believe that if a process is so catered to individual whims that no expectations can be reliably set, then there isn't a process. Having said that, I do believe you can achieve a relatively consistent level of meeting and/or exceeding expectations with a process customized to the individual needs of the team members.
Still, your point is very valid. Mine were only additional thoughts inspired by your astute observation.
https://martinfowler.com/articles/microservices.html
The opening sentence sets the tone well for the article well:
"'Microservices' - yet another new term on the crowded streets of software architecture."
A colleague of mine once said that his work (he was a business strategist) was "slowly coming into focus." We're pretty far along today in our understanding of microservices, but at the time the article was written (early 2014) microservices were "slowly coming into focus". Reading what people where thinking when the industry was trying to define them should help in understanding what they are today.
2) "When done properly" - therein lies the rub.
3) Absolutely agree, but I have seen teams screw it up time and time again. Never really figured out why that is.
I didn't and don't want to start a flame war, but needless to say once in an interview I was asked if I was a "Scrum Master" (after having about 15 years of agile experience). When I stopped laughing, I said, "No, no I am not." I don't think they got the joke, and no - I didn't get the job.
I don't think "iteration" vs "sprint" is a minor quibble. I've seen the "wrong mindset" you speak of, as people take "sprints" far too literally. It's not a sprint, it's a jog. A long, long jog. You'll be stopping for water and stretching along the way. Sprinting is a good way to pull a muscle and have all your devs quit on your one day, leaving you with a big-old case of backlog rhabdomyolysis. I took that analogy way too far.
nroach does have a point. I made a judgement call, and can see both sides of if it was a good one.
My bones ache from seeing Rational Unified Process mentioned, but of course you are correct.
I would say I was "at the point where I almost (didn't) care" about 5 years ago. I then switched jobs and was made lead of a team I cared about, and decided I wasn't done with implementing Agile. There was a time, however, when I was downright apathetic. Companies had beaten me down too much, and I didn't have the energy to fight anymore, so I completely understand.
The manifesto (to me) is how people who understood the nature and goals of Agile summarized their sprawling, complex, interconnected - and valid - thoughts. At the risk of being hyperbolic, I think of it like E = MC^2. Yes, that is a good summary of Einstein's theories, but if all you ever know of them is this summary you'll miss all the implications of what happens when you put it into practice. Probably a terrible example, but the best I could think of.
I can't find a "like" button anywhere, so I'll just say "Like".
Seriously though, glad you liked it.
I do agree with you. I about learned Agile first from my mentor (his formative years were in the 80s) who I did and do still deeply respect, but over time he and I disagreed over the nature of what Agile is and what it should result it as I gained more real-world experience.
I honestly have no answers as to specific suggestions that work for everyone. I've even asked teams where I implemented Agile practices what they though of my interpretation and the response I get is "Dunno...works fine to me."
The best advice I can offer has nothing to do specifically with Agile, but pertains to my experience customizing agile to an organization. I don't mean to plug my "book" (especially since I don't make money from it), but the best advice I can give anyone I put in here:
https://neilonsoftware.com/books/personality-patterns-of-pro...
Flawed and incomplete I know, but the best I could think to do.
1) Take on the most brutal coding tasks/features yourself. You will have to cherry-pick the upcoming work to look for things that just about any other engineer would freak out about if they got it assigned to them.
2) Knock it out of the park in terms of time-to-market and code quality. You need to do both, to eliminate the concern of, “We don’t have time to write quality code.” The code should be so clean, so well factored, so well unit tested, that you would be comfortable getting a code review from Martin Fowler, Kent Beck, and Bob Martin all at the same time. This also implies that you’re read their books, and would know how to pass their code review.
3) Call a code review with the entire team, and aggressively code review your own code. There is always room for improvement in any code, depending on hour you interpreted current requirements and future needs. This has to include phrases like, “I didn’t know what to do here so I…”, “I really which I had more time to change this to…”, “I went back-and-forth on how best to abstract this, but ultimately I chose this abstraction because.” Basically, you’re looking to show them the worst possible code review on the best possible code.
4) Depending on the personalities involved (including your own), decide how you are going to coach each engineer 1-on-1. No two people are alike, so you will need to dial your approach to each person. Some people will thing you are a show-off, some will think you intimidating, as well any another other human emotion and concern that causes someone to not seek out or not take advice. This is where your emotional IQ and communication skills will be tested.
5) When you start coaching them, don’t go after every single flaw. Try to find the underlying root cause of the problem in the code, and address that. A common problem I run into is the people just don’t understand OOP but think they do. I usually have to coach them on basics like encapsulation and cohesion, working them up to design patterns, and further up to domain modeling, all the while instructing on proper implementation technique (such as unit testing.) Once they have the fundamentals in place, you can begin fine-tuning certain implementation patterns.
6) Over time, at least one member of your team will get good. With their permission, publicly review their code. In this, you want to be very positive: “I like what they did here…”, “That’s a good way to encapsulate that problem”, “That’s a powerful abstraction, especially the way it’s used…” This Rite of Passage should then become what other engineers are striving for, as only the best engineers are getting public praise fests.
This basic formula has served me very well with my current team, in that they are one-upping themselves on code-quality. Still, however, I take on the most grueling coding tasks to set the example and lead from the front. This acts to continue to demonstrate my commitment to code quality, as well and lets the team know I would not ask them to do something that I would not do myself.
In all seriousness: Open source it. Tell the dev's to put it on Github, and let the global development community figure out what the hell is going on.