Category: agile

Product Manager – version 2.0 @ Scrum India Dec 2011

December 30, 2011 / Asheesh Mehdiratta

The Scrum India Dec 2011 NCR meetup at Xebia, offered me a perfect opportunity to rant about my expectations from today’s Product Managers in the agile world today, as we go about our daily (product development) chores. This post was takeoff from my earlier post sometime back on bringing the business dashboard closer to the workforce on the ground and linking the agile world with the overall business objectives. Feel free to comment on my digs and leave your feedback in the comments.

Ofcourse my presentation was in the Pecha Kucha style (my first one) and think i did ok :-),but you can watch my presentation video recording at the WizIQ channel.

Overall it was interesting to hear Amit Somani (MakeMyTrip) and their struggles to get the product managers, with some controversial points by Rajat Bhalla (Vinsol). You can watch all the video recordings at the WizIQ channel (video recording sponsors).

Product Manager – version 2.0

View more presentations from Asheesh Mehdiratta

Tribal maintaineance or Sprint Retrospectives : just another tribal ceremony?

January 31, 2010 / Asheesh Mehdiratta

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?

Is your agile team usability infected ?

November 23, 2009 / Asheesh Mehdiratta

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?

Does continuous deployment help your product development strategy?

November 5, 2009 / Asheesh Mehdiratta

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 !!

Is your Agile dashboard == Business dashboard?

July 26, 2009 / Asheesh Mehdiratta

Agile dashboards include Burn down charts (productreleaseiteration), team velocity charts, backlog items (productiteration) = 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?

It appears that most organization dashboards have not evolved yet to measure both the agile denominators and their relationship to the economic denominators. Very few companies have the P&L visibility at the team execution level and this is what makes it difficult to derive or even see the above relationship (forget measuring the relationship) ! Though a limited organization set may be measuring both the indicators but in my view most organizations cannot think of sharing these financial numbers, citing trust or confidentiality as the primary reasons. Did someone say self organizing teams with responsibility?

In my view this missing linkage, offers an excellent opportunity for the agile community, to break the tradition, and challenge the latent organizational mindset. The right choice appears to be the Product owners who can (need to) step up to the plate and make this linkage visible; since they know both sides of the story and can communicate both up and down the organization streams.

Product owners talk about user stories and themes but rarely bring the project cost structure (salarysoftwarehardwaresupport team’s costs) and how the agile process is impacting the economic denominators. I feel they need to act as THE Glue and assert their voice by providing a bidirectional business dashboard for the ‘masses’ with the ROI / development costs, along with the team vision and vice versa for the business audience. This information flow to all stakeholders would allow an opportunity to question and debate while increasing the sphere of influence for everyone in the organization.

Until the above linkage is established, the various functions in the software industry are all sub-optimizing the system each sub-system meeting it’s benchmark, while reducing the overall system throughput. This surely is against the Lean principle of “optimize the whole”

Product Owners : are you listening ?

Mission Godspeed or Good Speed ?

June 13, 2009 / Asheesh Mehdiratta

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.

IPL Championships

May 15, 2009 / Asheesh Mehdiratta

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 ?

Bottoms up agility?

April 12, 2009 / Asheesh Mehdiratta

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…