Archive for Software Development

Have you gone Beyond Agile Yet?

Posted in Agile with tags , , , , , , , on February 20, 2010 by vikramadhiman

Modern Agile. Post Modern Agile, Post Agile, Beyond Agile, Agile 2.0. Buzzwords 2.0 are flying right, left and center again. At conferences, at workshops and at twitterverse. This at a time, when people and companies, are still getting used to decentralizing and moving faster. But, do we need another movement, another thought process – at this time

Part of Agile’s [or agile’s] philosophy is “inspect and adapt”.  Agile is basically the agile manifesto and the values. I read the manifesto and the values many times over : whenever I am confused, whenever I have a question or whenever someone tells me that what I am doing or saying is not”agile”. From the clutter that surrounds discourse around Agile 2.0, the one clear voice seems to be that it depends : “You should be able to question the values too.” Being liberal at heart, I will concede that. Let us look at some values and see if you could do away with the values as such.

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. There can be situations where “continuous” is not relevant and probably “early” in not relevant either.  Where exactly? For instance, in a financial application where tax laws are changing 3 months from now – you want to make sure you work towards that rather than focusing on early delivery [before the laws change in bits and pieces or focusing on usability releases while not having time for migration issues at the end].

Welcome changing requirements, even late in development Agile processes harness change for the customer’s competitive advantage. Ok! when you will word the last part of the sentence the way you have worded – pretty much no one will argue against it. However, the same phrase also means that you want to welcome changing requirements because it “can” lead to customer’s competitive advantage. What if it does not? What if its jut a whim of a product manager? What if it delays launch by a few weeks? What if the impact of change is not fully understood?

Just two examples and the generally dismissive note that people ascribe to post modern agile starts appearing like a judgment pronounced a bit too early. But 1+1 does not prove things sometimes. Hence, let us pick from the manifesto itself. The manifesto reads:

  • Indivuduals and Interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

As much as I think and re-think, I can not fault any of these above, in any context if I take out the mean and wicked sense that is. However, there maybe a need to be street smart in some situations. Hence, you want to make sure that your contracts are negotiated well even if your customer collaboration goals are high. Similarly, comprehensive documentation might be required in an outsourcing context. Responding to change vs. following a plan depends where you are. Too early in your product development, changing things frequently could result in chaos. And if your software team is fixing support bugs all the time, processes and tools might take precedence over interaction. The context varies and hence, your values would vary too. The keyword here is “context”. You might have to look beyond Agile Manifesto/ Values sometimes. Is that a radical thought?

I guess if we renamed everything to “contextual” software development or “contextual” management. Or, maybe this sounds creepy. Let’s just say Agile [consider it as an umbrella term] is one of the option available. The key is to realize that Agile [and not agile] is “one” of the option and “not” the option.

Lets Talk Agile : Excellent Presentation from Slideshare

Posted in Agile, SCRUM with tags , , , , , on December 31, 2008 by vikramadhiman

I happened to chance upon a spectacular and to-the point introduction from Denis Caron. I thought it was direct [although sometimes it just was probably too much rather than just enough] and very exciting. It touched upon the normal subjects like agile not being a silver bullet/ magic wand but also that it is not a process or methodology. Slide 24 explained the main essence of Agile pretty well:

  1. Time-box everything and stick to it!
  2. Anticipate change in everything you do.
  3. Don’t build monuments, keep it light and malleable.

And the market compulsions have been explained succinctly too : Change happens fast, our competitors will not wait for us while we get ready! and Learning faster than our competitor is our only sustainable competitive advantage

Vodpod videos no longer available.

Is Agile Software Development Equal to Cowboy Coding?

Posted in Agile with tags , , , , , , on December 30, 2008 by vikramadhiman

This is an often asked question. Almost 2-3 people ask me this in each session I conduct – online or face to face. Let’s first look at what is this Cowboy Coding. Cowboy coding is the absence of a defined method : team members do whatever they feel is right. Cowboy Coding is a term used to describe software development where the developers have autonomy over the development process. This includes control of the project’s schedule, algorithms, tools, and coding style.

Anyone who has read even the Agile Manifesto will know that this is not true.

[A] Agile software development re-evaluates plans frequently, emphasizes face-to-face communication, and values working software over use of documents. However, most Agile teams do follow defined (and often very disciplined and rigorous) processes.

[B] Project schedule is not a prerogative of the team in Agile. It is the marketing team/ leadership which takes the call on this important aspect of the project in Agile Software Development.

There are still others who say Agile Software Development is crazy Cowboy Style Programming because:

  • There is no documentation.
  • There is change – right, left, center.
  • There is no method to define the maintenance phase.

Again, all this is an individuals perception and an emphasis on definitive processes for everything. Nothing in Agile stops you from saying no documentation or little documentation – they only ask you to value the cost of the documentation – which is a good thing to do. If there is a value and cost-value graph is good, then documentation should be made. Agile is based on building frameworks and teams which accept change. This is based on a lot of engineering practices like refactoring, unit testing and automated tests [which leads to cohesion and coherence – both desired qualities of a good code anyways] as well as having a good framework for product managers and coders to interact through out the product lifecycle. Rather than working on the principle that changes caught early in the development lifecycle are easier to fix, Agile focuses on creating processes and environment where changes at any stage can be responded to readily : it makes it easy for development team to suggest alternative ways to get quicker to market as well as get feedback quickly. It also enables them to align their code and design from a business standpoint. This along with engineering practices mentioned above, helps the team respond quickly to changes. Also, it is not a question of change or no change but market environment – can any good product manager give you solid no-change requirements for anything longer than 02 months in current business environment anyways? What is best – to have a slow response to these requirements or rapid responses? If your product is now in the market, probably maintenance will be one area you want maximum attention. Nothing in Agile makes you focus less on maintenance and more on new product development. Agile is a value stream – whatever brings you value, inspect/ adapt for that. It emphasis the system as a whole with clearly defined roles – something which Cowboy Coding does not unless the only way you can derive success is by having everything entrusted to group of developers – which can very well be the case during the initial stage of your project.

Lean Thinking – An Introduction

Posted in Agile, SCRUM, WiZiQ with tags , , , , , , , on December 21, 2008 by vikramadhiman

I have done an online webinar on Lean Thinking Introduction for Beginners and Dummies on WiZiQ. This presentation has been the basis for the same – I have compiled this from various sources and keep improving it when I find an example from real world experience or web, that I feel should go here. I hope you find this a useful resource for Lean Thinking Introduction.

Lean Thinking Introduction by Vikrama Dhiman

Vodpod videos no longer available.

Are we Really Agile – A Survey

Posted in Agile with tags , , , , , on December 2, 2008 by vikramadhiman

I have been conducting various training sessions for organizations across the country and have found that it is going to quite a while for Indian organizations to become Agile. Hence, I thought it would make sense to do a brief survey on Are we Really Agile or taking Steps towards the same? The survey is primarily for Indian Organizations only.

You can participate in the survey by going to this link http://www.surveymonkey.com/s.aspx?sm=uFtT7z80mHpM7hGvLFJtZg_3d_3d