“Individuals and interactions over processes and tools”

Can Phones

I can sometimes go weeks, even months, having causal chats with people in workplace, without ever asking their name.  Of course there is problem of when you leave it too long to ask, then it feels rude (is that just the English :)). In a way, I think it is very english – and a common problem I see in vitually every english company I have been in.  If someone has a problem and doesnt speak up soon enough, the problem can just remain as long as it takes to be discovered. Which can end up months.  If there is fundamental flaws in project planning, then nothing is going to go right.  In a smaller/medium sized company, things may not get so bad so quick, but in a corporation … wow.  

Although corporations have modernised, it is mostly a “look and feel”, none more so demonstrated by the widely loose adoption of Agile. Many corporations felt, or were sold, that Agile meant project teams could self-manage. Sure they can – if they are really being an Agile team. I would have thought assumptions at that levels were highly risky. It just goes to demonstrate there is no substitute for fully engaging the project team with continual verbal communication. And observing same principle with clients and stakeholders. Over-reliance on processes and tools goes against the core ethos of Agile, but for some explicable reason, this is what happened. Perhaps to do with perception of non-IT people – that software is akin to a machine, when you pump in requirements and out pops the software.

We have networked tools for issue reporting, planning and general communication. The social web, though a beautiful thing, created a communication anomaly, and raised people’s expectations of communication through technology.  The web is in too early stages to be truly considered a communication tool, on same level as verbal communication.  People are not entirely honest online, and more likely to be that way, as the web provides some degree of anonymity.  We were not born with a facebook-implant, we are still primitive beings that rely on visual as well as audible communication to get our points across. You can’t avoid the necessity of face-to-face contact with clients – and on a regular basis.

A good example is on the most basic of technology – the telephone. When you are describing a situation to a client, say a problem that a new feature many cause to another feature, you cannot see the other person’s response. They may be agreeing with your every word, but may also have a puzzled look on their face, but do not want to appear ignorant. They might agree to what you say, without entirely understanding it, which is a situation that may backfire on you, later on. If you were there face-to-face, you can register people’s real reactions. In this case, you would inquire what part they didn’t understand – maybe demonstrate it if necessary. Yes, we have video-conferencing, but as you may have noticed yourself, people become self-conscious and try and mask their visual expressions.

Transparency was always going to be a big challenge for traditional business, and it’s reliance on some degrees of subterfuge. In a way, technology gave business even more tools to continue in this vein. Mistakes are a given on IT projects, but they are generally mistakes made, as part of a learning curve that exists on any IT project. Business’s inability to “go Agile”, hampered attempts of Agile implementations, because of the fundamental disparity between business and IT drivers. This problem is still widespread, and will be a while before business modernizes to the extent which IT development has. Communication and transparency – within Agile, you can’t have one without the other.

Using the Agile skeleton

Agile provides a skeleton set of rules that you can apply to any other Agile-related methodology – apply them with iron fist, then allow projects to define their own variations, especially at development level. These rules are:-

  • Full-Time ScrumMaster Identified and Team Members Available to Do Work
  • Team Agrees to Demonstrate Working Software in No More Than 30 Days
  • Stakeholders Invited to Demonstration

That is pretty loose, but get to grips with fundamentals of project team structure, and what is expected high-level, it’s a good start to developing your own Agile approach. Don’t forget, no methodology takes account of company culture, human resources or budget constrictions. Follow Agile to the letter, and it could prove very costly for you, without adding much comparative benefit.

The ScrumMaster role is a vital role, as it is he/she that keeps development on track with user stories, and is first point of contact for the business. This role is a common area of weakness – if you omit the role altogether, then you will simply have a Waterfall project (driven, as it would be, by the Product Owner). Product Owner thinks in terms of milestones, as they will have a stakeholder breathing down their neck. The Scrummaster brings some order to the input/output of requirements.

The team members include everyone that drives the daily SDLC, i.e. developers and testers. They may or may not be applying Agile software development method, but any Agile-friendly method is OK to use – best fit for the team and company. Length of Sprints is flexible and driven by realistic vision of what is possible given resources. 2 weeks is a common choice, which is sensible. A broad guide is to assume you need same amount of testing time and development time. 1 week Sprints can work, but difficult to sustain without sizeable team.

It is often stated that Agile is intended for smaller projects, and indeed SCRUM is very specific on this (ideal team size 7-12). This is a recognition that Agile was primarily for smaller projects. But if your project is large and complex, you can still apply the Agile skeleton rule, and choose a longer (and some would say more traditional) monthly release cycle. Corporation generally adopt this approach, largely because corporations are a slower machine. It doesn’t matter how dynamic or Agile your development team is. If stakeholders are rarely available, your project will slow up accordingly, as Agile assumes continual stakeholder contribution to the process.

Startup companies can adopt Agile more fully, as they have a lot more at stake for project delivery. No project, no funding, no company. So they can afford a more aggressive implementation of Agile, and SCRUM is ideal for an average startup structure. For s start everyone is usually in same building, if not on same floor. Interaction between employees is far more frequent, and feedback is very fast, up and down the chain. I have often thought the way corporations should be thinking is of each project as its own company, rather than attempting a corporation-wide strategy. While one project may suit Agile for software development method, another may be better using kanban (which is more developer-centric). Project methodology should be judged per project.

That’s not to say you cannot have an overall Agile strategy in a corporation – just adopt the Agile skeleton as the high-level framework. Then work out the development method to follow – taking parts of several methods, if appropriate.

Agile Manifesto 2001

Looking back at the original Agile Manifesto, outlined in 2001,  it is very enlightening in hindsight …

In order to succeed in the new economy, to move aggressively into the era of e-business, e-commerce, and the web, companies have to rid themselves of their Dilbert manifestations of make-work and arcane policies. This freedom from the inanities of corporate life attracts proponents of Agile Methodologies, and scares the begeebers (you can’t use the word “shit” in a professional paper) out of traditionalists. Quite frankly, the Agile approaches scare corporate bureaucrats at least those that are happy pushing process for process sake versus trying to do the best for the “customer” and deliver something timely and tangible and “as promised” because they run out of places to hide.

The Agile movement is not anti-methodology, in fact, many of us want to restore credibility to the word methodology. We want to restore a balance. We embrace modeling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes. We plan, but recognize the limits of planning in a turbulent environment. Those who would brand proponents of XP or SCRUM or any of the other Agile Methodologies as “hackers” are ignorant of both the methodologies and the original definition of the term hacker.

http://agilemanifesto.org/history.html

Firstly “Agile approaches scare corporate bureaucrats” – the opposite is generally true now, but it doesnt mean they understand it!   As with the now maligned 2.0, it is suffering from the increasing build-it-up-then-knock-it-down tabloid approach.   Also it is very naive to think that a methodology can somehow change a corporation – bloated corporations will never be “Agile” – it is against the whole ethos of what a corporation is – a large company with no real responsibility or accountability anywhere, apart from the top of the tree – the place that isn’t even involved. To be fair, Agile Manifesto has been subsequently revised, and this first effort looks childish – the above has obviously been written by a fairly bitter developer.   Mentioning the word “shit” in a blog post was no doubt shocking in 2001, but impresses me very little – and this is from the Agile originators!

So lets take the 4 core aims of Agile, still applicable in today’s version …

Individuals and interactions over processes and tools
Reality: Interaction has to happen across the board, and rarely does.

Customer collaboration over contract negotiation
Reality: This is assuming too much about the customer – for example, what happens if the customer cannot or is not willing to be fully engaged in process ongoing, apart from the initial PID (Project Initiation Document).   That would lead to cries of where is the Project Manager (whose is primarily for passing the buck to on Agile projects, when things get complicated)?  Oh, we forgot, we diluted their role effectively to observer.   And unfortunately the Product Owner is also the client.  Oh dear.

Working software over comprehensive documentation
QA Reality: Too little documentation, poor defect record maintenance, chaotic release management and shoddy release notes.  It is a turbulent time for web development, with harsh timescales, but poor record will ultimately come and bite you squarely on your behind.

Responding to change over following a plan
Reality: See above two – it is only the first point that holds true, after the lessons learnt since 2001. Without the first, the other 3 will never happen.

In  Quintessence: The fifth element for the Agile Manifesto, Uncle Bob states a fifth rule, which to me plugs the previous gap – ironically in development.

Craftsmanship over Execution

Most software development teams execute, but they don’t take care. We value execution, but we value craftsmanship more.

Agile effectively diluted the project and test managers role, instead of integrating these important roles. Development has an arrogance in approach of they-know-best. That arrogance is also good, as confidence in what you are building is important. But development do not understand business drivers outside of their own bubble, or more to the point, dont want to. This makes a joke of the manifesto, as the most common issue by far is development dictating direction too much, rather than the client requirements.

Many of the 12 Agile Guidelines are reliant on competent project and development management and a client/customer that is regularly engaged in the process.  If anyone has been on a project with all these same time, please let me know!