agile journeys

...rants by Asheesh Mehdiratta on Coaching, Transformation and Change

Page 6 of 7

what really is my secret sauce ?

In the quest to deliver business value quicker, enterprise agile transformations are common and growing, leaving the organization CXO’s confused and struggling in the myriad universe of agile process and tools. They hear Scrum, Lean, XP, Kanban, DSDM, FDD, and are asking their team which ones should I choose ? Based on my experiences with enterprise wide transformations, I would love to share as to what really is my secret sauce?

The answer is not a simple YES only Scrum works ! and NO XP does not work !

Instead the real story is about a new breed of agilistas, who are mixing the various ingredients and bringing an integration of the various methodologies to deliver the promise of faster turnarounds and keeping the CXO’s smiling. The amazing process landscape map by Mark Kennaley, as referred by Carson Holmes, summarizes this beautifully below and points to the SDLC3.0 wave approaching and becoming the new world order till we get to the next evolution.

SDLC 3.0
Courtsey: Fourth Medium Consulting

As the agile community evolves, the real adoption levels of these varied methodologies will always remain a hot topic…but now you know my secret sauce! But I would really love to hear your comments on which methodologies are actually converging in your organization? Is it Scrum and Kanban ? or Lean and XP practices with AMDD ? Tell me about your secret sauce in the comments now.

Product Manager – version 2.0 @ Scrum India Dec 2011

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 

Agile Balanced Scorecard at Agile Tour India 2011, Pune


As part of the Scrum Alliance, Agile Tour India, Pune conducted a track on Agile Enterprise and my session on “Balanced Scorecard for the Agile Enterprise” was selected. The session focused on how Balanced Scorecard has traditionally been used across multiple industries for managing the organization performance towards the achievement of it’s strategic goals. This session introduced key performance indicators for a Balanced Scorecard in an Agile context, which could lead to similar strategic focus and organizational alignment and how to capture the typical agile metrics in the overall Balanced scorecard for software projects. The session was extremely well received by the enthusiastic audience of 100+ attendees, comprising CXO’s, senior managers and development community.

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?

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

  1. Wireframesketcher
  2. MockupScreens
  3. Inkscape
  4. Balsamiq
  5. OmniGraffle
  6. Axure
  7. Morae

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?

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?

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 ?

« Older posts Newer posts »

© 2024 agile journeys

Theme by Anders NorénUp ↑