Archive for Agile

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

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.

Agile Christmas Greeting

Posted in Agile, Collaboration with tags , , , , , , on December 25, 2008 by vikramadhiman

Seasons Greetings !!! May this season and new year bring you:

  • closer to your team,
  • patience to understand,
  • reflection to hold reactions 
  • lots of togetherness, bonding and fun at workplace
Hope you are a harbinger of “we” and “us” and help make your team and organization a better place.

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

Scrum Exposes Bad Processes and Obstacles

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

In our last post, we discussed the Agile Retrospective technique of Start, Stop, Continue or SSC. In this, post we discuss a technique first tried by Pete Deemer [CST, co-leader of Yahoo's implementation of Scrum].

Often, as the end of a sprint, the team comes back and says things like

  • Its more stressful in Agile
  • Things are worse than before
  • Agile does not work
  • We were better off before

If as a Process Coach or Scrum Master you hear something like this, you can try this in your retrospectives:

  1. Ask the team to collectively come up with a list of things they thing are better than before/ is working well and also what is not working well/ worse than before. So, you have two lists : Better and Worse.
  2. Now ask each member to mark each item on both the lists from three possible options : Caused by Scrum [C]/ Agile, Exposed/ Made Visible by Scrum or Agile [E], Does not relate to Scrum/ Agile [U].
  3. Compile the score and let there be pin drop silence in the retrospective.
  4. The team may find a lot of C’s on the “What’s Working Well or is Better than Before” side of the board, and a lot of E’s on the “What Could Work Better or What is Worse than Before ”; this is good news, even if the “What Could Work Better” list is a long one, because the first step to solving underlying issues is making them visible, and Scrum is a powerful catalyst for that.
  5. The team’s opinion and acceptance of Agile/ Scrum would have undergone a complete 180 degrees turn.

It is often useful to keep a snapshot of the whiteboard where these lists are maintained and keep revisiting them in each of the Retrospectives. This is especially useful for the teams which are transitioning to Scrum or Agile way of working.

Agile Retrospectives Start Stop Continue

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

Revisiting the discussion on agile retrospectives, it is recognized by some as the single most effective practice/ ceremony of Agile. This could be because this exercise:

  1. Brings the team together
  2. The team inspects what it has been doing
  3. The team tries to adapt for better results

On a score of 04 based on Agile Manifesto, Agile Retrospectives would score a 02. They are about individuals and interactions and help the team respond to change. In addition, Agile Retrospectives help the team focus on 02 other principles of the Agile Manifesto : Customer Collaboration and Working Software.

There are various approaches in conducting Agile Retrospectives. One of the most common approach that is advocated by many coaches is “Start, Stop, Continue”. A very simple approach, this type of retrospective is usually conducted as follows:

1. All team members make 3 lists – what is working well and they should Continue doing, what is not working well and should be stopped, and what is something that can be explored/ Started.

2. One-by-one everyone adds their points to a central whiteboard/ list. They can do a plus 1 if what they want is already on the list.

3. After everyone has completed this, the team picks up the items with most “plus 1″.

4. They commit to “some” or “all” items in the 03 lists – Start List, Stop List, Continue List.

5. In the next retrospective, they go back to this list and evaluate how they have done [this can be done in a variety of ways too - everyone votes on whether they were successful in implementing something or not and after this a new Start, Stop, Continue List is drawn].

6. Some people like to keep it mechanical – vote and decide. Others like a lot of brainstorming, discussions and debates. Its useful to have debate on what you are planning to do. The only downside of debates in retrospectives is that more powerful or vociferous attendees may overpower others. Hence, the Scrum Master has to be really good.

This is a relatively simple approach and helps the team inspect and adapt continuously.

P.S. If you are in India, and haven’t taken this “Are we Really Agile Survey” then, I recommend you do so right away : [it will only take a couple of minutes and is straight forward multiple choice survey].

Agile Certification | Scrum Certification – Good or Bad

Posted in CSM Course, SCRUM with tags , , on December 8, 2008 by vikramadhiman

There have been murmurs in the past about certifications in the Agile community, not all of them good and almost all of them for Certified Scrum Master. Here are some blogs and articles I have read. Ian Culling has a well read ” I am a Certified ScrumMaster – BFD“, “Agile [Scrum] Certification Debate“, “Scrum Certification Test” and “Scrum Master Certification – What’s it Worth?” Some of the common criticism about CSM is:

  • Certified Scrum Master is not good enough guarantee that those who are certified are good to be a Scrum Master. Heck, its not even a guarantee that you know Scrum, forget become a Scrum Master.
  • There is no test. It only certifies that you attended a 2-day course, which is not enough.
  • There are no pre-requisites – no experience criteria, no reading criteria etc.
  • There are no follow ups suggested other than [possibly very mean] renew your membership of Scrum Alliance every year.
  • There is not enough transparency in the CSP [Certified Scrum Practitioner] and CST [Certified Scrum Trainer] certifications.
  • There can be people who don’t have a certification, that can be very good.
  • Scrum or Agile is not something you can measure. You can never check individual performance in a team based approach like Scrum or Agile.

All of these are valid arguments. It is also interesting that not many people have issue with CSP. Its CST and CSM that gets people worked up. I guess its the nomenclature. If they renamed Certified Scrum Master as Certified Scrum Beginner or Scrum Alliance Member or Certified Scrum Master – Level 1, no one would have any issue [other than probably people who take this certification only for title]. You can also counter most of arguments above by saying that all IT professional certifications are crap [someone passed MCSD, but could not answer D of Design or someone is RHCE, but knows nothing about ports].

I personally do not have anything against CSM or CSP. I was a member of Scrum Alliance for a year and then my membership lapsed in September this year. I assume I am no longer a CSM now. Its not that it affects me in any way. I think writing this blog, being active on various Agile and Scrum groups and also networking well, are more important. But that’s a personal choice. I might just renew my membership with Scrum Alliance soon. Rather than blame Scrum Alliance, I would ask people who have an issue with CSM or “some secret Agenda of SA” to let the world know what CSM really is and whether people should value CSM or CSP. I for instance, would not recruit someone or interview someone simply because he/ she is CSM. But if he/ she is CSP or CST, my view will change.

Would a stricter examination or other things help? Probably yes. I am not for experience part [you should have certain experience before you are allowed to take CSM for instance] here – there is no guarantee that 4 year experienced employee is better than 2 year one or even a 0 year one. Similarly, follow up actions after the certification can be difficult to track – will you track blog posts or something else? I think for now CSP is good. And then, may be Scrum Alliance will reword CSM to something which explains this better.


Get every new post delivered to your Inbox.