Tuesday, December 15, 2009
Agile 2010 conference registration
Agile 2010 dates are now announced by Agile Software Community of India (ASCI), happening in Mumbai(16/17th Jan) and Bengaluru(22/23rd Jan). Here are the links for Bengaluru and Mumbai registrations. I am registering my seat now....
Monday, November 23, 2009
Is your agile team usability infected ?
Agile teams generally do acceptance tests, unit tests with every sprint but what about usability tests ? The myriad test frameworks allow continuous feedback for the functionality or 'user acceptance' tests, but the user experience tests are sadly missing or delegated to the specialist designer.
What has been your experience ? Can you build user experience (UEX) focus in your agile sprints from the beginning?
Today the agile teams are mostly generalists and quality infected, but as we find that the user experience is not always a top priority. From my experience the user experience discussion in agile projects today usually happens POST the sprint demo. The product owner and the specialist UEX designer reviews the sprint demo against an intial user interface specification and provides feedback to the team. This may sometimes result in major changes or complete redo of the functionality, not a good sign (smells ?) But it is indeed possible in my view to use the available tools to engage in discussion and do rapid prototyping and reduce the feedback cycle time.
Here's my list of popular tools which can be used for agile user experience discussions with your UEX designers and Product Owner
Ideally the agile communication for user experience discussions could range from simple paper drawings to using the quick dirty tools (see the popular tool set above), based on the user story maps (or themes and epics). The extreme user experience oriented step would be to setup a Usability lab fitted with cameras et al. as the NASA example demonstrates.
So what is your best bet ? what discussions do you have with the product owner \ UEX designer so that your agile team becomes usability infected also?
What has been your experience ? Can you build user experience (UEX) focus in your agile sprints from the beginning?
Today the agile teams are mostly generalists and quality infected, but as we find that the user experience is not always a top priority. From my experience the user experience discussion in agile projects today usually happens POST the sprint demo. The product owner and the specialist UEX designer reviews the sprint demo against an intial user interface specification and provides feedback to the team. This may sometimes result in major changes or complete redo of the functionality, not a good sign (smells ?) But it is indeed possible in my view to use the available tools to engage in discussion and do rapid prototyping and reduce the feedback cycle time.
Here's my list of popular tools which can be used for agile user experience discussions with your UEX designers and Product Owner
Ideally the agile communication for user experience discussions could range from simple paper drawings to using the quick dirty tools (see the popular tool set above), based on the user story maps (or themes and epics). The extreme user experience oriented step would be to setup a Usability lab fitted with cameras et al. as the NASA example demonstrates.
So what is your best bet ? what discussions do you have with the product owner \ UEX designer so that your agile team becomes usability infected also?
Thursday, November 5, 2009
Does continuous deployment help your product development strategy?
Can you deploy your software 50 times as day ? (yeah FIFTY) !! The folks at IMVU are doing it already..! But the more important question is if you can ripple this deployment model achievement into your overall product development strategy for achieving product differentiation in the marketplace?
The naysayers will resist and say that the product strategy is long term buddy and who cares about these minor deployment details...
But for emerging industries, where we have major technological and strategic uncertainties, and everyone is struggling to get the right business model or there is no product standardization, this deployment model also becomes one of the key links in the path to glory and market share.
To illustrate, let us imagine the IDEAL world of delivering a 'differentiated' product:
a) Product owners get 'new' requests from the customers FIFTY times a day
b) Product owners receive competitors/external environment reports FIFTY times a day
c) Project engineers can develop these 'prioritized' requests FIFTY times a day
d) Underlying platforms are available with 'features' for deployment FIFTY times a day
e) Project testers can test and deploy at customer sites the integrated product with 'new' requests FIFTY times a day
f) Of course if all the above happens then surely your 'threat from substitutes' is reduced by a factor of FIFTY if not more..
Imagine the customer *delight* when they receive their 'new' requests implemented in a single day !! WOW !!
Is this realistically possible / a necessity or just a dream? What do you think?
The folks at IMVU have certainly demonstrated the Deployment part of this linkage !!
The naysayers will resist and say that the product strategy is long term buddy and who cares about these minor deployment details...
But for emerging industries, where we have major technological and strategic uncertainties, and everyone is struggling to get the right business model or there is no product standardization, this deployment model also becomes one of the key links in the path to glory and market share.
To illustrate, let us imagine the IDEAL world of delivering a 'differentiated' product:
a) Product owners get 'new' requests from the customers FIFTY times a day
b) Product owners receive competitors/external environment reports FIFTY times a day
c) Project engineers can develop these 'prioritized' requests FIFTY times a day
d) Underlying platforms are available with 'features' for deployment FIFTY times a day
e) Project testers can test and deploy at customer sites the integrated product with 'new' requests FIFTY times a day
f) Of course if all the above happens then surely your 'threat from substitutes' is reduced by a factor of FIFTY if not more..
Imagine the customer *delight* when they receive their 'new' requests implemented in a single day !! WOW !!
Is this realistically possible / a necessity or just a dream? What do you think?
The folks at IMVU have certainly demonstrated the Deployment part of this linkage !!
Sunday, July 26, 2009
Is your Agile dashboard == Business dashboard?
Agile dashboards include Burn down charts (product\release\iteration), team velocity charts, backlog items (product\iteration) = Agile denominators
Business dashboards have managers measuring the schedule, resources, quality.. ; CXO's measuring the ROI\ ROCE\... ; and the business analysts have the Quick Ratios \ quarterly stock price\ EPS expectations to ponder = Business (Economic) denominators
But do we measure and communicate the relationship between the agile denominators and the economic denominators? Can you say that if my project agile denominators are high (low), my organization economic denominators are high (low)?
Or is the agile denominator dashboard only for the masses (teams executing projects) and the 'sacred' economic denominator dashboard for the management?
..read more
Business dashboards have managers measuring the schedule, resources, quality.. ; CXO's measuring the ROI\ ROCE\... ; and the business analysts have the Quick Ratios \ quarterly stock price\ EPS expectations to ponder = Business (Economic) denominators
But do we measure and communicate the relationship between the agile denominators and the economic denominators? Can you say that if my project agile denominators are high (low), my organization economic denominators are high (low)?
Or is the agile denominator dashboard only for the masses (teams executing projects) and the 'sacred' economic denominator dashboard for the management?
..read more
Saturday, June 13, 2009
Mission Godspeed or Good Speed ?
Captain Kirk, USS Enterprise, gets a "Godspeed" wish! Lucky chap ! you might say...but for us mortal souls "Good Speed" is what we simply crave for....but then what exactly is a Good Speed (velocity) for your agile mission ? do you know ?
Following the typical sequence for agile projects, we all estimate the story points and get the total size estimate for the project. The team velocity (or the speed) as measured historically allows us to get the number of iterations required and this turns into the project calendar release plans (voila...GM milestone here I come) ..sounds familiar.
But what about the historical velocity ? is my historical velocity good/bad ?
Scott Ambler suggests that measuring the historical velocity itself is not the end. Do Not measure velocity.
Measure the velocity trend line (== acceleration ) !
What is happening in your project ? Does the velocity trend line go up or down for your project?
If your project velocity trend line goes UP then you are in good shape (and have a "Good Speed") but if the velocity trend line goes down then you need to understand the reasons and retrospect (deeply as Esther Derby remarks).
I think that this observation is important otherwise people can start measuring the velocity ONLY for various teams across the organization at any point and it may not be all fun.
Scott Ambler also suggests that the velocity is "unlikely to be gamed". But I disagree with Scott on this since the focus on measuring up trending velocity may have it's pitfalls.
Some of these in my view could lead to the team breaking stories prematurely...adding more in the same iteration and/or shifting the additional story points to a bigger number over subsequent iterations. Beware these shifts !!
Understanding this comparison across multiple projects, both with upward velocity trend lines would need another discussion and I have to get back to Captain Kirk...(oh) Captain Kirk, no offense but I am wishing Chandrayaan Godspeed this time.
Following the typical sequence for agile projects, we all estimate the story points and get the total size estimate for the project. The team velocity (or the speed) as measured historically allows us to get the number of iterations required and this turns into the project calendar release plans (voila...GM milestone here I come) ..sounds familiar.
But what about the historical velocity ? is my historical velocity good/bad ?
Scott Ambler suggests that measuring the historical velocity itself is not the end. Do Not measure velocity.
Measure the velocity trend line (== acceleration ) !
What is happening in your project ? Does the velocity trend line go up or down for your project?
If your project velocity trend line goes UP then you are in good shape (and have a "Good Speed") but if the velocity trend line goes down then you need to understand the reasons and retrospect (deeply as Esther Derby remarks).
I think that this observation is important otherwise people can start measuring the velocity ONLY for various teams across the organization at any point and it may not be all fun.
Scott Ambler also suggests that the velocity is "unlikely to be gamed". But I disagree with Scott on this since the focus on measuring up trending velocity may have it's pitfalls.
Some of these in my view could lead to the team breaking stories prematurely...adding more in the same iteration and/or shifting the additional story points to a bigger number over subsequent iterations. Beware these shifts !!
Understanding this comparison across multiple projects, both with upward velocity trend lines would need another discussion and I have to get back to Captain Kirk...(oh) Captain Kirk, no offense but I am wishing Chandrayaan Godspeed this time.
Friday, May 15, 2009
IPL Championships
The Indian Political League (IPL) manifests itself every five years during election times in ways where every party, in truly democratic style, aims to GRAB power at any cost ! The statements and the U-Turns every passing day, are amazing to watch and maybe indicate the professionalism that a political career in India demands (maybe everywhere)?
Do we treat these U-Turns as opportunistic or acknowledge the politician as playing an agile role in the IPL Championships or scoring centuries, who can change his skin based on the demands of his customers at the 'intention' of an alliance or break one when 'threatened' ?
is it just the environment which forces this agility or is it the bets which a politician makes? is this risk management in the form of a plan B or a plan C, to protect if the bet goes wrong?
do we have this agility in our software development processes to change, based on the external environments and manage the risks? or we simply watch with amazement, and pat the political class for an exceptionally agile performance ?
Do we treat these U-Turns as opportunistic or acknowledge the politician as playing an agile role in the IPL Championships or scoring centuries, who can change his skin based on the demands of his customers at the 'intention' of an alliance or break one when 'threatened' ?
is it just the environment which forces this agility or is it the bets which a politician makes? is this risk management in the form of a plan B or a plan C, to protect if the bet goes wrong?
do we have this agility in our software development processes to change, based on the external environments and manage the risks? or we simply watch with amazement, and pat the political class for an exceptionally agile performance ?
Sunday, April 12, 2009
Bottoms up agility?
The shuffler struggles to strike a delicate balance while laying the stack of cards placing them one by one on top of each other to build a complete pyramid, ensuring that each card is aligned perfectly on the card and still be able to support the next layer to be built on the top. This sure is a Bottoms up approach !
But how did you introduce agile development for your organization ? Bottoms up or top down ??
Trying to fathom the response brought back memories of my granny who advocated that the family obey the diktats of the holy guru, a regular preacher visiting our house every week. Typical top down again !
But to really push agile development down the throat of your organization is a tough task , which even Ron Jeffrey explains and acknowledges. The entrenched power pits, political chaos and the distributed model followed would indeed doom the initiative.
So do you think that the the bottoms up approach is the only solution left ? Does the bottoms up approach always work ? how did you kick start this among your employees? is there a bright chap who has awakened and who can walk the talk ?
or do you educate the executives and open up the lights for them ?
well I am still looking for the right answers and maybe my card stack is still not ready to go up yet !! if you think that you have a solution, leave in your comments...
But how did you introduce agile development for your organization ? Bottoms up or top down ??
Trying to fathom the response brought back memories of my granny who advocated that the family obey the diktats of the holy guru, a regular preacher visiting our house every week. Typical top down again !
But to really push agile development down the throat of your organization is a tough task , which even Ron Jeffrey explains and acknowledges. The entrenched power pits, political chaos and the distributed model followed would indeed doom the initiative.
So do you think that the the bottoms up approach is the only solution left ? Does the bottoms up approach always work ? how did you kick start this among your employees? is there a bright chap who has awakened and who can walk the talk ?
or do you educate the executives and open up the lights for them ?
well I am still looking for the right answers and maybe my card stack is still not ready to go up yet !! if you think that you have a solution, leave in your comments...
Subscribe to:
Posts (Atom)