Tuesday, October 25, 2011
Agile Balanced Scorecard at Agile Tour India 2011, Pune
Thursday, March 31, 2011
7 Steps to winning Agile wars
Sharing my presentation at the Agile NCR 2011, talking about the 7 step framework for introducing bottoms up agility in your organization. Watch out for details in my next blog posts.
How did you win your wars ? leave a comment...
Asheesh Mehdiratta Agile NCR 2011
View more presentations from mehdiraa.
Saturday, January 29, 2011
Speaking at Agile NCR 2011
Delighted as I will be speaking in the Agile NCR 2011 conference, Delhi...you can catch my talk on 25th Feb 2011 (4:00PM)....http://agilencr.org/pages/agenda
I will be speaking - 7 steps to winning Agile wars ...
any thoughts on this? Shoot me an email and I will try my best to answer in my talk. wish me luck !
Sunday, January 31, 2010
Tribal maintaineance or Sprint Retrospectives : just another tribal ceremony?
Do you think that your sprint retrospective transitions the team to their cause ? or is it just another tribal ceremony?
The authors of Tribal Leadership talk about people forming tribes, which range from stages 1 to stage 5 (most evolved at stage 5). The tribal leaders in Stage 4/5 perform regular "tribal maintaineance". But do you know that this tribal maintaineance ritual matches the sprint retrospectives feedback loop (which agile teams perform after every sprint)?
Stage 4/5 tribal leaders, who regularly perform these "tribal maintaineance" or "oil changes" (as the authors speak), ask these BIG questions -
1. what's working well ?
2. what's not working ?
3. what can we do to make the things that aren't working, work ?
This indeed sounds familiar to the Agile Sprint Retrospective questions -
1. What worked well last Sprint that we should continue doing?
2. What didn’t work well last Sprint that we should stop doing?
3. What should we start doing?
But what's the difference in these stage 4/5 tribes and agile sprint retrospectives ? Do agile sprint retrospectives miss anything?
I think that the major difference in these tribes vs the sprint team answering these similar questions, is that the tribe is indirectly answering more key questions - " what's our cause ?" and "what are we proud of ?".
This tribal maintaineance activity provides the tribe a deeper understanding of their shared values. Once a tribe understands these shared values, the tribe members are united and therefore transition to a "we are great" tribe !! (stage 4), from a "I am great" (stage 3) !!
Thus this stage 4 melts all individual boundaries and the tribe members work collectively towards their noble cause. Surely Avatar's on Pandora were a united tribe with a noble and heroic cause !!
But what about your sprint teams ? do they see their cause from a sprint retrospective or is it just another tribal ceremony?
The authors of Tribal Leadership talk about people forming tribes, which range from stages 1 to stage 5 (most evolved at stage 5). The tribal leaders in Stage 4/5 perform regular "tribal maintaineance". But do you know that this tribal maintaineance ritual matches the sprint retrospectives feedback loop (which agile teams perform after every sprint)?
Stage 4/5 tribal leaders, who regularly perform these "tribal maintaineance" or "oil changes" (as the authors speak), ask these BIG questions -
1. what's working well ?
2. what's not working ?
3. what can we do to make the things that aren't working, work ?
This indeed sounds familiar to the Agile Sprint Retrospective questions -
1. What worked well last Sprint that we should continue doing?
2. What didn’t work well last Sprint that we should stop doing?
3. What should we start doing?
But what's the difference in these stage 4/5 tribes and agile sprint retrospectives ? Do agile sprint retrospectives miss anything?
I think that the major difference in these tribes vs the sprint team answering these similar questions, is that the tribe is indirectly answering more key questions - " what's our cause ?" and "what are we proud of ?".
This tribal maintaineance activity provides the tribe a deeper understanding of their shared values. Once a tribe understands these shared values, the tribe members are united and therefore transition to a "we are great" tribe !! (stage 4), from a "I am great" (stage 3) !!
Thus this stage 4 melts all individual boundaries and the tribe members work collectively towards their noble cause. Surely Avatar's on Pandora were a united tribe with a noble and heroic cause !!
But what about your sprint teams ? do they see their cause from a sprint retrospective or is it just another tribal ceremony?
Tuesday, December 15, 2009
Agile 2010 conference registration
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 !!
Subscribe to:
Posts (Atom)