Twitter stream caught my attention, as the conversation came up around how Agile maps to the doctrine meets reality.
I like to think I’m a guy who’s travelled around to a lot of teams and tried many things, I’ve been in quite a number of teams world wide and have seen some great projects succeed others I dare not mention for their curse alone may bring bad karma.
Throughout my travels, the concept of Agile has always been this mutated religion that often gets thrown about but really doesn’t cement the virtual “it should be done as this” to “this is how it maps to reality”.
In all the teams I’ve been in one thing always was consistent, that is there is usually one or more person(s) in that team that are often the weakest link – you know, the one that if we were playing survivor they’d be the first to go.
That person often is also one that has a degree of influence and whilst a democratic philosophy is one we should aspire to in an agile setting, reality is usually there’s an alpha in the room and they often are the ones who approve your timesheet – thus, you suck it up and give way even if it’s a dumb decision.
I’ve heard often that “Well the reason that failed is you had the wrong person” followed by how the role was given to a jackass who typically had no business making decisions other than “would you like one or two biscuits to go with your hot beverage?”
That’s the problem though with this whole agile philosophy, we aspire to working with a gang of people that make you feel as if you’re coding along side a crew that have similar skills to Oceans 11. Yet when you look around often the case is you’re dealing with a crew that came from Billy-Bobs 12 and its often the 12th man is usually the cousin twice removed but was forced to be in the team due to Billy-bobs wife being a royal pain in his redneck side.
Ok, that metaphor fell to the wayside but my point is I often find the reason why agile/scrum fails is simply due to the aspirations around the said doctrine not mapping to the reality of a commercial environment.
The amount of customers I’ve had to create solutions for often have no clue as to what they are doing and its usually why they hit the panic button, allocate budget and socket in a development team to solve the said problems. If you’re lucky you get the business ownership in a place where they feel competent enough to say out loud “I actually understand my business problems and desire software to solve them” …if you’re lucky.
Do you as a developer look at the said impending car crash and simply yell “we should really stop what we are doing and look at who’s driving this car and why” or do you simply lock onto the weakness that which is a business out of control but with a really big wallet thus as a contractor exploit this until the wheels come off. Once the wheels come off you simply throw your hands in the air and do what everyone does when agile fails “You had the wrong person….”
Here is my creative thinking on a way forward.
What if you had your team divided into two parts, that is you have TEAMA working on the grind, as per design think on your feet reactive feature development whilst TEAMB looks at iteration two, figures out the weak/hot spots and devotes more time to just R&D (spiking the big issues).
Once they have that mastered or time boxed them then switch gears, own iteration two and then iteration three is then put into R&D mode followed by a rinse/repeat formula.
Would this not also include user experience?
Anyone tried this? Or did I just declare Jesus was really a female and not a guy after all thus a war breaks out and I’m likely to be crucified for challenging the status quo.