Agile in a Flash

I try not to do too many "news message style blogs", ones where all the blogger does is repeat somebody else’s message and hyperlink to it.

I would rather the majority of my posts reflect my personal experiences and add some significant value.

Still, every once in awhile something comes along that impresses me enough that I can’t resist.

Jeff Langr and Tim Ottinger are blogging about a concept called Agile in a Flash, which brilliantly, and build on the concept that real tangible, concrete tools that you can touch often have way more impact than equivalent software solutions.

This is one of the base principles of agile. I.e. planning boards that are clearly visible to that everybody passes by, are way better than software project plans. Using collaboration cards to build models with your stakeholders are way better than software models that you simply review.

Agile in a Flash builds on this concept by placing specific best practices on distinct cards, everything from technical practices like using meaningful names when creating code, to project management practices like daily standup meetings and retrospectives. What is really interesting is that power cards are also included in the deck, such as extreme measures.

The two authors have positioned using Agile in a Flash as a great way to anchor one’s thoughts, as well as a mechanism to quickly teach and provide learning to people who are not aware of some of these practices. I personally like the idea of actually placing the specific cards are actually being used by a team on the actual planning board. That way everybody in the organization who goes by the planning board will have a clear understanding of what actual practices are being followed by the team.

I think tools like this are great enablers for change management, and personally, want to brand some of these cards according to look and feel of my clients logo, and start introducing them to the various technical people that I work with on a daily basis.

..

The Dangers of Agile

The Dangers of Agile Development

For my last several posts, I’ve given some fairly philosophical submissions on the benefits of agile, how to mix it with other practices, and for the most part, described the benefits of the principles and methods that can collectively be termed "agile".

For the last several months, I’ve had the distinction to be able to serve on a software project that has been following a "purer" form of agile than I typically experience. While I originally was looking forward to this experience with relish, I now have to admit that agile brings very real risk. Not only to software development projects, but world health and safety as well...

skeptical? read on...

1) clumsy developers put project planning at risk

Agile practices state that planning, modeling and other project artifacts are best represented as physical, tactile objects like index cards being placed on particle boards. These artifacts are then placed in public places, where anybody can walk by, and get a quick understanding of where the project is currently at.

Sounds great in theory, right? Of course, what makes it obvious to me that nobody with real-world development experience has actually tried this is the obvious fact that developers are terminally out of shape, lumbering, unforgivable week, clumsy animals. Have you ever seen, a developer try to walk down the hallway without bumping into every third person, doorway or other inanimate object. In my experience, I could not go through a week of an agile project without some developer literally tripping against the agile planning board, and sending the index cards flying in every different direction. This effectively makes the project of any scale impossible to track and impossible to monitor.

2) the business will always take away your daily standup/retrospectives /whatever room from you

Supposing that for one second we decide to mitigate against clumsy developers wrecking havoc on our planning boards by moving them into slightly out-of-the-way location, such as a common planning room dedicated just for developers. Let’s just face it, developers are always going to be on the lowest totem poll. No matter what you do to reserve rooms, facilities, etc. expect to have your room taken away from you..

3) Agile practices (like co-location and pair programming) encourage the spreading of communicable diseases...

In many ways the inventors of agile delivery are completely living in a padded room devoid of any news and are completely unaware of any of the issues facing today’s world and workforce environment. Let’s face it the corporate world encourages things like working in separate cubicles, floors, and even in separate countries (i.e. off shoring) not because it’s more efficient, or cheaper, but because it is SAFE. Agile practitioners seem to think that they are very clever by trying to make everybody sit in one room, and even going so far as to forcing developers to sit right beside each other and share computers, keyboards, and other peripheral devices. Everybody take heed!! This is unsafe, and unsanitary. I have personally experienced half of my development team being taken out by one nasty virus because of these unhealthy practices espoused by agile development.

4) agile modeling guarantees your models will be vandalized

Let’s face it, in any project of large-scale, software models, diagrams, and pretty pictures are more important than your code. No one can understand the code anyway, the business is certainly never going to understand it, and your project managers will only just pretend to. On the other hand, everyone can always understand a pretty picture. Developers probably won’t even understand your code, once new developers go onto your team there just going to rewrite it anyway, but no one will redraw a pretty picture/diagram, especially if it has pretty colors.

Using agile tools (i.e. whiteboards and CRC cards) guarantees that your pretty diagrams will only be temporary in nature, eventually it will get destroyed, even if there is a Please Leave On (PLO) marker. This is especially true if somebody from the business or project management gets a hold of your white board, they will erase your models just on principle...

5) Agile delivery is destroying our environment

anybody knows the agile developers answer to anything is "I know, let’s put it on an index card...".

• Need to do some modeling? Put it on an index card...



• need to gather some requirements? Put it on an index card...


• need to fill out a change request? You got it, put it on an index card...

I think it’s a given that the need for software development teams and software development in general is only growing at an exponential rate. If even a small fraction of these teams follow agile approach, the effect will be the destroying of our forests because of all this need for an exponentially larger amount of index cards. And nobody in the agile community has actually thought about this? Not only does agile helps spread disease, it’s also destroying the environment!

6) Agile development is also an assault against fashion

One thing we also as responsible developers need to be collectively aware of. Software programmers can’t dress. They have no sense of fashion, and look ridiculous even when viewed in isolation. This is one of the other many reasons that sensible project managers try to isolate developers from each other, putting two together for a prolonged period of time is just too much of an offence to the eyes. Then along comes these agile developers and they say "hey let’s put two developers in front of one keyboard" like that’s not going to be an assault of the senses. What makes it even worse is that developers tend to make the same fashion mistakes at the exact same time...

So what is my point?

Everybody knows that agile provides some great ideas if you want to add value to software delivery projects. But what I haven’t seen is a fundamental look at the effects of agile on our health, on our sanity, and the safety of our environment...

As responsible professionals we need to look outside of our need to successfully deliver valuable software to the business, we also need to be responsible citizens of the world.

.

DSLs and the new Analyst tester

Domain specific languages (DSLs) are quickly gaining momentum and there is definite interest in how the industry can adopt DSLs in the requirements world. I think DSLs can act as a bridge to help cross the divide between an "analyst" and a "tester". While, I don't think the industry is ready to adopt DSL's in the large, there are several easy wins here that I think can be easily gained by the industry if we start small.

1) Get the analysts involved with delivery -it's time to accept that the old fashioned approach of making up requirements and throwing it over the wall has failed. Instead, embed the analysts with the developers and testers. Make them work with the team, jointly capturing requirements together and creating tests that validate that the system.

2) Executable Requirements - start writing automated acceptance tests. These acceptance tests are described one level up from "code" and can start looking like a natural language. Wikis like FitNesse (http://fitnesse.org/) are an excellent example

3) Behaviour Driven Development - the next step up from executable requirements is to embrace a DSL-like mindset to drive the design, development and testing. There are emerging frameworks that allow a tester or developer to write test cases in code that mirror the language of the business. See, http://behaviour-driven.org/

If we can get these three practices right, then I think we are half way up the hill towards understanding and using DSLs. Already there are many organizations and teams that are pushing the frontier with these practices. As these practices get adopted, the "analyst" will evolve into a capital A - "Analyst", lower case t - "tester" and the two roles will be merged into one.

TDD improved coding quality? Really?

this might seem obvious to those of us that actually do TDD, but now we actually have some empirical evidence to back us up...



http://www.infoq.com/news/2009/03/TDD-Improves-Quality

Leading Agile: The Reluctant Product Owner

A pretty good suite of posts are being put together on how to scale up the concept of an agile product owner...

I recommend checking it out@
Leading Agile: The Reluctant Product Owner