Category Archives: process fusion

development, process, process fusion, software development, value

New Article – Things Change (And So Should Processes)

1 Comment

I wrote an article for Better Software magazine for the July/August 2013 issue about innovation in processes. The PDF of the article is available here: Things Change (And So Should Processes) and you can download the entire magazine here: Better Software July/Aug 2013.

Many teams struggle when a process lets them down because their unique situation and mix of people, technology and target market don’t fit a generic process. It’s also surprising to find out how old many of the popular processes we are trying to follow are. The technology we are creating has changed a great deal since the 1990s, so why are we surprised when processes created in the ’90s let some teams down?

Instead of feeling guilty that they aren’t following the crowd and doing what the experts tell them to do, I encourage teams to take pride in their innovation not just in technology, but in how they create powerful processes for themselves.

gamification, process, process fusion

Content Pointer: New Article – The Software Development Game

1 Comment

Better Software magazine has published a new article that I co-authored with David McFadzean called “The Software Development Game.” A PDF version is available here: SDG Feature in PDF.

David approached me in the summer of 2008 and pitched the idea of co-authoring a piece about using game-like concepts on software development teams. It turned out that David and I had both been influenced by game theory when creating policy and strategy on software development teams, but David had taken it a step further than I had: he had formalized an actual game-like structure on several teams.

It took us a while to write the piece. First of all, we wanted to observe two SDG instances that were newly created, so we took our time. Secondly, we found that the topic is massive. It was very difficult to fit our ideas into a 3000 word article. Also, we wanted to incorporate more ideas from the gamification of work movement into game play. Finally, our ideas had to pass the review of peers that we trusted, and their feedback took time to address and incorporate.

The final result is a very brief introduction to the topic. It is one powerful tool, particularly for self-organizing teams to help determine their own destiny. Instead of being told what to do by a coach, process consultant or manager, a team can use a simple framework to determine their own optimal mix of processes, tools and practices at a particular point in time. The game structure provides visibility on decisions, and can help teams align their technology focus with the visions of leadership.

We hope you find it as interesting as we do, and if you try it out on your own team, let people know how it works for you and your team.

agile, post-agilism, process fusion, TDD, test-driven development

Interesting Posts on Agile Challenges

Scrum Challenges

A couple of posts that describe how many teams are flailing and failing with Scrum:

I’ve observed similar patterns. However, my gripe with an oft-heard Agilist response: “they are failing because they just don’t get Agile” or “if Agile failed for you, it’s your (or management’s) fault” smacks of blaming the victim(s). An emerging response that I support is:

Maybe a pure form of ‘Agile’ isn’t appropriate for that team, in their context.

(Time for some Process fusion?) Philippe Kruchten has a great talk on this: Situated Agility – Context Does Matter, a Lot.

It’s also very difficult dealing with the scorched earth of a failed Scrum project after the Scrum trainers have left and the team is struggling on their own, feeling humiliated. “Are we the only ones failing? Why do we hear all these wonderful reports of how Scrum would solve all process ills? What’s wrong with us? We’re trying…” It’s hard to get them to retain the good practices they learned from Scrum and to encourage them not to throw out everything and return to a system that wasn’t working before either, but is more familiar, so it feels safer.

Rumours of Practice

TDD – more of a rumour of practice than actual practice? (much like some of what is described in the two posts above.)

Roy Osherove: Goodbye mocks, Farewell stubs

My own observations about these and other Agile practices being more of a rumour of practice than an actual practice leads me to wonder if Agile practices are another flavour of a bubble. Time will tell, but some of the behavior is troubling. It still galls me that many blindly parrot TDD as an un-alloyed good practice, instead of TDD as another tool to think about using, particularly when people might be basing their conclusions off of rumours, rather than personal experience. This irrational exhuberance is one reason why stock markets ramp up on empty speculation, real estate prices boom on over-valued properties (using mortgages that people can’t afford to pay back), and tulips are bought with abandon. (At least you can plant your tulip bulbs and enjoy beautiful flowers when the bubble bursts. What do you do with your old un-maintainable tests?)

My advice to those who may be struggling? Don’t worry about being “Agile”, (particularly if you’re trying and failing) and worry about providing value. That’s what really matters anyway. (That, and enjoying your work.) Providing value to the users of your software, and valuing the people you work with is important. Value, coupled with the skill and interest level of the team members, will trump methodology in the long run.