Software Development : Failed to get Agile

I've just been party to a conversation about a project elsewhere in my work place, my team is not involved, I was observing passively (alright, alright, I was ear-wigging).

The conversation was quite heated, one member of staff was adamant things were fine, whilst another was adamant they were inadequate.  The two of them were at complete logger heads. The driver of the conversation ran like this:

"We're not really designing software, we're asking everyone's opinion, writing it all down and only picking the things we really need to do"

As an agile developer this is essentially how I run my team, we write every possible item down, everything and I weight them, schedule them and during out sprint hand-overs we reorg whom is going to tackle diffing parts of the system to share the experience and share different things.

This chap however, was incredulous... He expressed "WRITING EVERYTHING DOWN" as a bad thing... He only wanted to do the things he felt fit, he wanted to sit down and look at the specification, produce an analysis and ONLY do what he suggested.

This would have made perfect sense to be towards the end of my academic study of software development; before the reality struck home in the work place, and I was flabbergasted to hear this chap simply working twenty something years in the past.

I mean, he's old... This company is old... But, not that old surely?

I literally caught myself tipping my head to one side as if trying to pour those words, and the way they were said, back out of my brain.

He didn't stop there though, he sat and without knowing it essentially dismissed as absurd the complete concept of Agile development; at least Agile as I use it...

"You'd be constantly juggling which task to do next, swapping people on and off tasks.... What would you do?  Meet daily, what would be the point?"

I'm not sure whether this was genuine inflexibility or purposefully derailing the effort to adopt agile beyond the scope of my own team, whichever it was, it sounded and felt extremely awkward.

It makes me wonder quite if anyone outside my team actually uses Agile processes around here...

Development : People Error 404 (Scrum)

I talked last week about my implementing three new cards for my Scrum meetings, I'm thinking about another card... a "Person 404 Error"... When I find an empty chair, post scrum, when I expect people to be working feverishly or at least planning their tasks for the day, but instead I find them drinking a coffee in a corridor, eating an apple staring at a wall, or just bemoaning they've been up since 8, I am going to assign them a 404 card.

My reason being, the developers I'm talking about, do not have a fixed start time, they can start anytime they like, so long as they're at the scrum, the scrum is 10 to 15 minutes, and then they have to get on with their task.  Coffee collecting, and apple eating, and especially bemoaning, is not allowed after the scrum for at least an hour, results, progress and some personal planning are required of them.

So, if you're a developer who wants to do the scrum then vanish... 404 you're not found... I'll be watching... And waiting.... And I'll make sure your 404 card is in your least favourite colour!...

That means Pink for you SB!... PINK!.... You have been warned.

Development : No Tests before a Prototype

I am NOT a fan of test driven development, does this mean there isn't a place for tests whilst you work?  No, it does not, I believe there is a place for tests whilst you are working, however that place is beyond the initial hard development and broad strokes of laying out the project.

When you first begin a new project there are so many things to consider, settings, scopes, layers, inherited domains just so much you need to physically take from the design pages through your teams brains and down to the keyboard.

I could even define this as a "pre-sprint" within Scrum to push out a product that the owner can then give you that first feedback on; especially if they are none technical and from this point on, from this first step you can cycle through Scrums into Sprints and with that change you can seed your development into more expansion and maintenance of code, when you do that, when you have something to test against then you need to add those tests and start to use them as a tool.

They should not drive your development, they should drive your keeping the developed work in order.  N-Crunch, N-Unit, G-Test... All these frameworks on certain languages (like C# and Java) work very well as you can reflect out the language, but before you can reflect out something with languages like C++ or C you are stuck over-engineering your tests before that first evolution of the project.

There is a name for this first evolution, it's called a Prototype.

Not many teams value a prototype, indeed Scrum itself never mentioned them, you are meant to jump from idea to stories to backlog to releasable code, and in my opinion this is not easy, it's not really communicative of what you are doing either, especially when the product owner is the only person within the development stack whom can redirect the team, but without that first tangible something many product owners can be literally lost.

Earlier this month I talked about the idea that a product owner needed to use the software life-cycle, an old idea, but a good one... Today I'm saying before you can really start to use inline tests within your IDE and before you can start to run scrums you need a prototype, arguably an even older development paradigm.

So what is my point?  Why do I keep bringing this kind of topic to the fore?  Well, simply put I believe there are far too many teams with far too many people in them not willing to push the envelop, whom are not willing to ask questions of the process they are following, not willing to bend or twist or shape the working environment to their way of working whilst simultaneously keeping up the bests practices those processes are there to enforce.

I suppose a Scrum Master should help with this process, but I find far few do, because the division of my problems with these Agile development mantra lie in the disjoint between idea and actually hitting the keys.  At times I see teams which are literally headless, they are a dozen monkeys typing a dozen keyboards, and they're being cheered on by the Scrum master, beyond those walls however they've no idea how it applies to the company, they have no interest or feedback on the return on investment that the Product Owner is all about.

A prototype, beyond a discussion, beyond the initial design, it can form the best kind of spring board and drive the best kind of Product Owner feedback down that chain, but it has to be created unfettered, unburdened by the micro-management of a scrum or sprint, it has to be created in a linear no-none-sense holistic head-space and used as a tool.

This is not being done very often in the teams I see around me.  Perhaps because it is thought of as old school, as a "has-been", however, if you look the hyper success of some products; say Minecraft; it maybe managed however Microsoft want now, it maybe teams running sprints, however Notch started it all with a Prototype.