The WordPress.com stats helper monkeys prepared a 2011 annual report for this blog.
Here’s an excerpt:
A San Francisco cable car holds 60 people. This blog was viewed about 2,600 times in 2011. If it were a cable car, it would take about 43 trips to carry that many people.
It’s not uncommon for an organisation’s ‘mission, vision & values’ to include a set of core elements, and then to see an aspect covering customer relations. This brief post focuses on the “customers” element and how an IT change department benefits from a modern view of this relationship.
Expressions such as “the customer is always right” or “the customer is king” are familiar, however in our modern complex environment, these concepts are outdated and outmoded. This is reflected in a more modern vision where we find the customer relationship described as one more like that between trusted friends.
Trusted friends are on equal terms and is a relationship based on respect; seeing each other ‘eye to eye’. If such a friend were taking some false step, a friend with the authority of expertise, would look to readjust their thinking; even having to “just say ‘no’ when necessary”. As a practical application of this principle, an example might be a demand to skip adequate testing during delivery; whereas we would need to help our customer to see the danger of building technical debt.
Rather than being exclusively ‘delivery focussed’ we offer our customer a mature long term point of view; in effect we offer a service of ‘strategic technical conscience’.
A quote from George MacDonald sums this up well: “To be trusted is a greater compliment than being loved.”
A crucial aspect of the ‘trusted friend’ customer relationship is understanding them. We must do all we can to know our customer. Once we have a reasonable understanding of the complexity they face and the priorities they have, we must help them to understand our similar challenges. These of course include a strategy of producing robust and extensible software.
A powerful way to facilitate the mutual understanding is to employ a methodology rather than continuing an informal ad-hoc development approach. Agile for discrete projects or Lean techniques for more business-as-usual change, afford opportunity for bi-lateral engagement; understanding and sharing priorities, concerns and constraints.
In short, IT can and should be a trusted friend to our customer, and this in many cases requires us to re-evaluate our behaviour.
It’s been my experience that planning, prioritisation and activity transparency get the lion’s share of attention when teams are taking the Agile adoption journey. There may even be many who say that list covers all there is to Agile.
Of course focus on these aspects is essential, but should other valuable features be eclipsed? For example, is the adoption of pair-programming or peer-reviewing followed with the same diligence as the daily stand-up? Is the practice of ‘test first’ techniques as mature as the implementing of a Story-Wall or Kanban for instance?
Time for a metaphor!
The American muscle car versus the European sports car. The former is all about power, whereas the latter is often a balance of power and cornering. Let’s say a greenfield project is the long straight road that the muscle car is made for. Now let’s liken the winding track over the Alps to the route of the product already in production that is constantly being enhanced and refactored. Fast pace forward is useful but you’ll need to be able to adjust course without losing control.
Perhaps it’s no big surprise that the more project management side of Agile gets more focus. It’s often managers that get to set the agenda for Agile adoption and frequently they’ll focus on the classical project management aspects of software change delivery. Additionally or possibly symptomatically, Scrum is most often the framework latched onto as the Agile adoption solution. We’ll be great at moving forward at quicker a more predictable pace when we implement this aspect of Agile. We’ll be behind the wheel of a powerful machine ready to drag race with the project teams who are yet to adopt it. Yes Scrum is powerful; but it was intentionally designed as complementary to Agile practices found in other frameworks like Extreme Programming.
In many organisations the project management aspects of Agile are a massive challenge for adoption. We should continue to push for the transformation required to make that happen. But in the meantime are we missing a trick? Are we missing out on the value of adopting the rest of Agile, most of which does not require such organisation-wide transformations. Things like TDD or BDD and pair-programming are mostly in the control of the development team. There may be some resistance at first but this can be countered with some good selling: clear measurable comparisons of effort spent before and after.
The ‘test first’ approach and continuous-integration build in the ability to adapt to frequent changes in requirements. It creates courage to refactor and nibb
le away at technical debt. And pair-programming can get us headed in the right direction for achieving technical excellence and mitigating key-man risk. Thinking back to our metaphor, we swap our straight line project muscle car power for the European sports car that’s performant and adaptive; one that makes us confident to take those mountain hairpin corners.
Changing from how things have always been is never easy, even when the desire is present. At the very least however, why not make sure the agenda is properly balanced in your Agile discussions and adoption planning?
When offering directions for someone to get somewhere often the factor having the most impact on success or failure is finding a common point of reference. For example, if someone who has only ever known South London were to ask how to get to Big Ben, of how much benefit would references to North London locations be?
Perhaps we make a similar mistake with offering directions on the journey to Agile adoption. Almost without exception a challenge about whether there’s any worth in changing to Agile is met with references to Waterfall. But if Waterfall were North London, most have rarely even taken a day trip! By far the majority come from a ‘South London’ of ad-hoc software development.
For such fast paced, tough skinned development teams a Waterfall reference has no bearing on the journey they take. The most significant impact of this bad habit we must unlearn is that it’s virtually impossible for those needing directions to see any value in even setting off.
Here are a few suggested more familiar ‘landmarks’ and possible directions:
| Familiar ‘Landmark’ | Possible Direction | Benefit |
|---|---|---|
| The single page hand-written spec | Granular user stories with acceptance criteria | Small units of work with an agreed outcome |
| The occasional unscheduled catch-up | Daily ‘stand up’ around a ‘story wall’ | Clear and scheduled communication |
| The “we need it now” delivery plan | Fixed length iterations with agreed content | Constantly improving planning & estimation |
| The “there’s no time for more testing” | Test driven development & continuous integration | Time reclaimed by stable & reliable releases |
| The regular heated moment | Structured & disciplined methodology | Managed expectations & improved communications |
So the next time someone asks “what’s the point of Agile” or “aren’t we already Agile enough”, remember to offer familiar points of reference and the accompanying feature and benefit. Thus improving the chances of them seeing the value of the Agile journey.
A quick posting to highlight three blog articles; each an aspect on using Agile for maintenance, or alternatives, as the case may be:
The stats helper monkeys at WordPress.com mulled over how this blog did in 2010, and here’s a high level summary of its overall blog health:
The Blog-Health-o-Meter™ reads This blog is doing awesome!.
A Boeing 747-400 passenger jet can hold 416 passengers. This blog was viewed about 1,900 times in 2010. That’s about 5 full 747s.
In 2010, there were 4 new posts, growing the total archive of this blog to 103 posts. There were 9 pictures uploaded, taking up a total of 869kb. That’s about a picture per month.
The busiest day of the year was September 22nd with 28 views. The most popular post that day was mix agile development with waterfall project management and get fragile.
The top referring sites in 2010 were blog.mountaingoatsoftware.com, google.com, en.wordpress.com, maiaandalan.fireflyinternet.co.uk, and linkedin.com.
Some visitors came searching, mostly for agile development life cycle, vim grails, agile development, agile vs waterfall, and grails vim.
These are the posts and pages that got the most views in 2010.
mix agile development with waterfall project management and get fragile January 2010
6 comments
gantt project report gan2html.xsl October 2006
9 comments
my pain with a .Net web-service and a Java (AXIS) client July 2006
4 comments
UK TV License required for broadband BBC broadcasts? June 2006
14 comments
groovy minimalism July 2009
Recently I was labelled “religious” about Agile. For a few days thereafter I agonised about whether I have taken a purist, ideological and dogmatic stance that could block innovation. Or perhaps worse still, slow people down who are getting things done. I find myself at odds with the majority. In short, a crisis of faith!
My crisis leads to questioning what could be so wrong about tailoring Agile to fit whatever the situation calls for? What could be the harm in taking the bits of Agile that suit and discarding the less well-fitted?
I turn to the gurus and sages, the Agile thought leaders. What do they have to say about which principals are essential? the fundamentals without which Agile is just not Agile? There are a few classic quotes, for instance Alistar Cockburn and Ken Schwaber’s comments about Scrum with beginners and Ken’s request not to use the Scrum brand once it has been tinkered with – Scrum as a Framework. Interestingly, deviations far from the fundamentals are labelled “Smells”. Here are a few examples: Loss of Rhythm; Missing Pigs. It’s worth making the time to watch this presentation about Scrum at Google, in which these fundamentals stand out.
There may be some gains in taking parts of Agile and these might get things done. 
Equally there could be side-effects that build up and make people less efficient (I’ve witnessed this in action). Besides the possibility of unwanted byproducts, there’s the missed opportunity! Agile when implemented with all it’s fundamentals in-place is designed to show up weaknesses early. Done properly it highlights what a whole organisation needs to change to make itself better. It is “the canary in a coal mine“. If we only take the bits that “get things done” we only maintain the status quo, or more likely we build a legacy that slowly chokes our organisation.
In the end, as a self-styled Agile evangelist, it comes down to communication. More precisely, presentation of the message in such a way that it is palatable, without loosing it’s nutritional value – Agile seasoned with salt. Timing too, not when the appetite is present, because those on milk may feel satisfied, but timing in the sense of a gradual transition to solid food.
A common failing of those with a sense of strong faith is to couple it with a sense of elevation and even superiority over the unbelievers. Of course this polarises and alienates. A further failing then often follows, namely extremism. This characterises absolute failure! Destructive rather than the desired constructive outcome. Alienating rather than contributing. To be avoided at all costs. No, more than that: it demands reevaluation; readjustment.
In short, I have learnt from the experience. I’ve learnt that I need to make changes myself, and at the same time maintain my firmly held belief. My confident belief that the rewards of the narrow road outweigh the comforts of the broad. Wow, it’s remarkable how many religious metaphors this blog led to – ok, I’m religious about Agile, but I’m keenly aware of the need not to alienate and to collaborate allowing time for growth when we can reap the benefits together.
One common concern from many investigating Agile for the first time is how much time it demands. The day long planning meetings, writing user-stories and acceptance criteria, the desk-time with developers, daily stand-ups and attending show-and-tells.
I would assert, however, that the same time would need to be invested in a well done Waterfall project too! A properly done Waterfall project would require time invested in each of the activities that Agile demands; the difference is the distribution of the time invested. Rather than large phases Agile is spread evenly throughout. Agile doesn’t demand more time it demands just enough, just in time.
One benefit of the more even distribution of time is an even distribution of risk. Rather than investing lots of analysis time up-front without seeing anything delivered, one gets to do just enough analysis to see the highest prioritised business value delivered to production. Equally, testing as early as possible (and as automatic as possible) exposes issues as early as possible and thus reduces a build-up of time required for corrections.
It might appear that Agile could even demand less time overall. Perhaps it’s just the regularity and repetitive structured nature of time required by Agile that makes it seem more demanding.
What do you think is better, two months at the gym or two times every week by routine? A health study conducted in 2001, indicates that frequent modest exercise is better than intense but infrequent workouts, reports Germany’s Süddeutsche Zeitung. Dutch researcher Dr. Klaas Westerterp studied the minute-by-minute energy expenditure of 30 volunteers. The results indicated that rather than a person’s trying to “balance out phases of inactivity with bouts of extreme activity,” it is more effective to incorporate increased physical activity into the routine of everyday life.
A benefit of the demanding structured time Agile requires is the rhythm that creates. Some have proposed that the word cadence is a suitable term to describe what happens. The whole team, which includes the business, comes to know what to expect on a routine basis. Processes become consistent, the work/life balance becomes consistent and morale improves. Teams depending on or supporting the regular routine deliveries know where they stand. The customers get used to the steady flow of improvements that they have prioritised and confidence grows.
In fact my experience is that the concern over how much time Agile demands is simply as a result of the fact that any previous project branded Waterfall has not actually been run properly. Likely the business didn’t invest the time needed to provide a solid analysis. As a result development struggles to understand the requirements.
When/if the delivery finally makes it to testing that phase suffers from a lack of time too. The profile of the project reaches melting point and whatever has been produced get’s released. Think of the time now required in corrections and revisions to eventually produce what the business really needed. Possibly years if ever. Not really Waterfall, more water down the plug-hole!
So when someone raises the concern over how much time Agile demands I would question what sort of projects they’ve been working on up to now. Therefore the raising of the concerns around the time one must invest in Agile, actually presents an opportunity to look closely at what one expects as a return on that investment, regardless of the methodology – Agile, Fragile, Waterfall or Plug-hole.
I kick off with an obvious statement: Agile adoption in the enterprise is a huge undertaking. Wherever we find a way to make it easier it’s perfectly natural to grab at it.
One instance of an easy route to aid adoption is the alteration of standard Agile terminology to fit a more familiar traditional nomenclature. Examples might include naming a Backlog item a Work-Package; a Theme for User-Stories as a High-Level-Requirement.
Here, one could argue that making Agile more accessible by relating it back to the familiar is positive. We all think associatively. We take new things onboard more readily when we can relate it to what we already know. Many at this point will mix terminology; after all “what’s in a name?” – Shakespeare.
JULIET:
‘Tis but thy name that is my enemy;
Thou art thyself, though not a Montague.
What’s Montague? it is nor hand, nor foot,
Nor arm, nor face, nor any other part
Belonging to a man. O, be some other name!
What’s in a name? that which we call a rose
By any other name would smell as sweet;
So Romeo would, were he not Romeo call’d,
Retain that dear perfection which he owes
Without that title. Romeo, doff thy name,
And for that name which is no part of thee
Take all myself.
Juliet argues that the conflict based on a name or an origin should have no bearing on basic realities.
A similar instance of trying to fit Agile into a more familiar traditional context might be granting an over-arching functional requirement it’s own work-flow. This manifests itself in grouping a set of User-Stories and managing their progress outside of time-boxed iterations; instead, planning and tracking in terms of the functional requirement. Again, some could ask, “why not? Surely anything that makes adopting Agile easier is a good thing, no?”
No! Making it easier is actually the opposite of what’s really important here. For Agile to be truly beneficial it’s supposed to be hard. Correction; more than hard, it’s supposed to be painful! The pain exposes disfunction within an orgainsation. Once exposed that disfunction can be tackled. Only then is the full value of Agile obtained.
Traditional methodology might more readily allow weaknesses to be brushed under the carpet. The power of Agile is to expose disfunction early.
When designing Scrum Ken Schwaber and Jeff Sutherland chose new and distinctively different nameing. The aim was to make it clear from the outset that adopting Agile with that tool is intentionally different from anything previously used.
JULIET the Scrum Master:
‘Tis but thy name that is my friend;
Thou art thyself, though indeed a Sprint.
What’s Sprint? it is nor High-level-requirement, nor Work-package,
Nor task, nor function, nor any other part
Belonging to a project manager. O, be some other name!
What’s in a name? that which we call a User-Story
By any other name would not smell as sweet;
So Backlog would, were it only Backlog call’d,
Retain that dear perfection which Scrum owes
Without that title. Scrum, doff thy name not,
And for that name which is part of thee
Take all my enterprise.
Waterfall Project Management is perfect…
…for the right sort of project.
When it’s not the right project, the search for an alternative can* take two directions:
* (of course there are other directions, like RUP, but the point being made is about what happens between the two listed)
I would like to name the latter “Fragile”. The following lists some of the reasons why I think the name is a good fit.
Here’s my view of the life-cycle for the perfect Waterfall, the perfect Agile…
…and what evolves between the two if not thought through – Fragile.
Carefully thinking through using Agile throughout the whole vertical Project Management stack, must include everyone. That’s developers, business & systems analysts, testers, customer managers, IT and business, all the way to the board.
It’s a significant culture change for everyone, but it’s much better than the Fragile process and therefore worth the effort. There are of course, many experts in Fragile and only a few experts in Agile. Here are a couple of the latter and their work:
Ken Schwaber – The Enterprise and Scrum
Jochen Krebs - Agile Portfolio Management
Mike Cohn – Agile Estimating & Planning
Agile Project Management is perfect, for the right sort of project….
…Fragile Project Management is good for nothing.
Let’s stop giving Agile a bad name.
Theme: Rubric. Blog at WordPress.com.
