Article: Pulling Power - A New Software Lifespan

Features pull story creation
Stories pull scenario (aka test case) creation
Stories pull the UI (aka interaction and graphic design)
The UI pulls coding
The code pulls more coding

Including the roles does not encourage us to think about doing the same amount of work with less people. From the word choice you used "a developer could also play the role of a BA or QA", you've identified the person as the role developer and not as a human with capabilities that can be further developed.

Like the "In order to" form a lot better than the "so that" form.

Thanks, Jason!

I particularly wanted to call out the roles so that there's an anchor for anyone who wants to go and learn the skills necessary for the job. For instance, I've seen plenty of developers take on the role of designing the UI. Some of them have taken some time to learn the ropes of interaction and graphic design; others have just plunged in. The difference in ease of usability etc. can be quite large (I wouldn't like to try myself with my current skillset!)

I'm definitely in favour of human beings widening their skillset. I'm not in favour of putting people into particular roles (often by default) without providing the time, space and support for them to learn the job in a way which allows them to be successful.

If you're already in the Lean / Kanban world then I guess you see more of your kind of cross-role work, and less of the kind I refer to - so maybe this is useful as a starting point for teams who haven't got as far as you yet.

The cross-role thing actually comes from old-school XP. I do tend to use Lean lingo like "poly-skilled" or IDEO lingo like "T-shaped people" and sometimes Agile lingo like "generalising specialist" these days.

The article has good points showing connections between different aspects of the software development process. But are the diagram and the step by step lifespan too linear? Isn't there a risk that some people would see it as support for a return to a waterfall-like mentality?

The diagram seems to be pushing the developers' contribution back to the end of the cycle, instead of using their intelligence to contribute to the whole process. It's also pushing the contribution of the UX people back to the UI design stage. Jesse James Garrett's book, "The Elements of User Experience" makes it clear that UX design is not just about surface detail. UX people should be contributing at the earlier stages of scope, stories and features too.

The diagram (and lifespan) also puts features ahead of user stories. For any given story, there may be alternative designs (different features) that could enable that story. Users and stakeholders can usually describe their goals (or problems) but may not be aware of the best design options (including features) that could support those goals. Developers and UX people may be able to identify options that users are unaware of.

Leaving all those smart and skilled people (developers and UX designers) out of those vital early stages does not seem in keeping with the spirit of the agile manifesto, and could lead some companies back towards "throw it over the wall" thinking.

I don't think that's what you are suggesting, but I think the diagram and the step by step lifespan could give people that impression.

A feature set (or theme) isn't the same thing as a feature - for instance, "stop bots spamming the site" doesn't indicate how that's going to be achieved. We break those feature sets down later than that (probably with everyone in the same room).

I should have called out usability as part of analysis more explicitly though; that would I think get the interaction designers where you want them. Thanks for that. It's also possible that they (and the devs) could be brought in as incidental stakeholders - "consistent look and feel", "intuitive interface" and "automated deployment" might be good themes.

As for supporting waterfall-like mentality - I hope not! The word "conversation" appears six times, and "feedback" ten times, for a reason! All Agile goodness still applies; there just isn't room in this outline for everything.

Release!?? "A Miracle Occurs" You seem to be missing a few steps here ...

Most products/systems (of value) require some build and assembly (and thus a build/release engineer), repeated deployment/installation (and thus an installer/sys admin), some kind of training (and thus a trainer), and measurement/monitoring (and thus some downstream analytics) to get to actual realized business value.

Of course the scope of these activities depends on the size of the organization impacted and the scope of the change intended, but a more general model would at least acknowledge their existence.

Also, (btw) I think you meant "Copper" not "Cooper" as a base metal slightly more valuable than Lead.

Also, (btw) I think you meant "Copper" not "Cooper" as a base metal slightly more valuable than Lead.

Hi Nik - "thinking of all the people who need to be involved" would include trainers, etc. As I said (prompted by Dan's reminder), "Some features may not even be software! Perhaps our software stories will sit alongside things like training, logistics, network administration, legal work, etc."

So, thanks to both you and Dan for the examples and reminders. As a dev I hardly ever got to see how my work played into the other, non-software elements of a project. I'd love for a team lead or manager to track these things alongside the software themes / stories and tell me if it makes a difference!

You may want to check out Beyond Software Architecture by Luke Hohmann to get a more comprehensive view of the other business aspects that surround software/product development.

Hi,

the comments are for sure valuable but in my point of view too negative. For me the highlight of your article is to transfer the "pull" idea to sw development on a very fine granular basis. The examples you provide are very nice and understandable. For me it is not at all like waterfall. Even in an agile world, you have to start with something (e.g. define the UI before the code).

Thanks for that
Sabine

Does the creation of open-source software involve making, protecting and saving money?
Do you not mean marginal return and not 'diminishing return'?
Can a differentiator be a false differentiator? Is Pepsi different from Coca-Cola?
You have equated vision with feature. Did you really mean to do this?

This was a great high-level view of BDD! I especially liked the way it tied on the higher-level (e.g. feature set) with low level code. Keep up the great work!!!

Hi Aidy,

Re open-source: I can only speak from the point of view of the projects I've been involved in. We created JBehave to help solve some problems that were costing projects money, so, yes. I also indirectly get money from my involvement with JBehave - I use it as a teaching tool when I coach commercially, and I save money by being able to attend conferences as a speaker.

Chris Matts says he doesn't know whether Feature Injection works for things like not-for-profits and charities. I can't see why it wouldn't, though you'd need to redefine "value". Chris prefers to speak from his experience on more capitalist projects, and I'm following his lead. If you're doing something different and try this out, please let me know how it goes!

Diminishing vs. Marginal return - they're related, see here: en.wikipedia.org/wiki/Diminishing_Return

Pepsi and Coke are very different. Read Malcolm Gladwell's "Blink" to find out more. Part of a product's appeal is also the experience associated with that product. I still hear "Holidays are coming! Holidays are coming!" in my head whenever I see Coke at Christmas. For me, they're different products - and the marketing may be the differentiator.

I don't understand what you mean by "equated vision with feature". We're implementing a vision with goals, implemented by themes, then implemented by features (at least in the software context). Yes, I really meant to do that, and I hope I've defined the word "vision" as I'm using it clearly. Can you elaborate on your comment?

I love the way this article unfolded, however, I'd consider changing the development part of the "mantra" to something more like the following:

The UI pulls developers to write tests.
Tests pull developers to write code.

Good point Matthew.
I want to thanks you Elizabeth for this amazing article. For a developer like me, that is reading about Agile methodology and try to practice, to make the change from the legacy development model and who try to make others understand that this is the path to go, but without the support of other coworkers who don't understand or care about this stuff, articles like this one are really helpfull with the objective answering questions like "How can i start with all this?" or "What examples can i follow to get the picture?"

This reading really makes me the day better, and put some light on how to put BDD to work!

Thank you very much! :)