Do you only focus on increasing efficiency OR…?

 As a change agent, you are trained and would consider yourself an expert in the LEAN space, and have surely developed “EYES for Waste“.  You are always looking for that efficiency gain and how you can squeeze the most juice from your endeavours.  For some Lean practitioners, if you are not focused on reducing waste, then you at not Lean-ing at all (another discussion some other time 🙂 ).

But do you stop and pause?  or are we fascinated by the efficiency cult  that we forget to look beyond ?... read more

Do you plant New Seedlings in your team?

As you grow your garden, you need to plant New Seedlings and nurture them till they become stronger and stand on their own.

As an agile coach, do you plant New Seedlings in your team?

Do you show the team new techniques, new ideas and seed their minds?

read more here...

Fresh Innings!

To my readers, this marks not an end but a new beginning, for my rants and opinions on all things active in my world related to agile, lean, devops, change, digital, leadership, and much more.

I AM MOVING my blogging activities to agilejourneys (dot) com now, and this archive will remain AsIS always ! But I hope that you will still follow my rants :-) as I hope to trigger some thoughtful conversations on my new site. 

So come on and subscribe to my Latest UPDATES !

5 Step Recipe for building Communities of Practice

As part of organizational transformation journey, CIOs today need to move from hierarchical models to self organizing communities to deliver IT, and there is an even greater need to build and sustain "Communities of Practices" for achieving the same. If you are an internal change agent responsible for building these communities, you can learn about the 5 step recipe to building and nurturing these communities in your organization:

But before we kick-start, let us try to understand what really is a Community of Practice?

Communities of practice (CoP) are groups of people who share a concern or a passion for something they do and learn how to do it better as they interact regularly.

Typically these groups have a shared domain of interest, shared competence, and learn regularly from each other. They engage in joint activities and discussions, help each other, and share information; they are practitioners who share experiences, stories, tools, ways of addressing recurring problems — in short a shared practice. 

Below is a simple 5 step strategy to kick start and nurture your Community of Practice:

1. Establish a Sense of Urgency and leverage the Strategic objectives

Corporate honchos will typically lay down the current / future areas of focus for the organization. These are typically called as the Strategic Capabilities or future growth areas or similar sounding terms. 

The key to starting a community is to leverage these strategic objectives with an inbuilt sense of urgency, and find a key sponsor (read as TOP DOWN Support), and identify the contributions with this sponsor, as to how the community can add Value, and then focus the discussion and activities around these.

The BOTTOM UP support is always easy to find, once the Sponsor has been identified, who can then help in spreading the message across the enterprise. It is never a question of how to find the bottom up interest, but more a question of 'how to engage and guide' the early adopters and steer their passion.


2. Gather 'early' Adopters and "Run"

Start with whoever shows up and accept that there will be passionate people (few initially), but always encourage and accept different levels of participation. You will realise that the strength of participation varies from each individual. The ‘core’ (most active members) are those who participate regularly. There are others who follow the discussions or activities but do not take a leading role in making active contributions. 

Then there are those (likely the majority) who are on the periphery of the community but may become more active participants if the activities or discussions start to engage them more fully. All these levels of participation should be accepted and encouraged within the community.

There is never a critical mass required to start a community. So RUN with whoever shows up!


3. Partner with the internal and external Ecosystem

As a community guide, you will/shall/need to partner with the internal and external ecosystem for your organization.

The internal ecosystem would include your Support functions - typically Human Resources - Learning / Training departments, and the internal facilities, who can provide the required logistics, marketing muscle, sometimes manpower too and really make your community endeavours as a key part of their learning offerings. It is best to create this win-win combination to sustain your communities. 

The external ecosystem is key and would include partnership with the industry forums, and speakers, wherein the community members interact, broaden their expertise, and learn and share their stories, new learnings and upcoming trends. The key is to provide an engagement channel with your Community SPONSOR, on how to funnel the participation and share these learnings internally without getting sucked into the legal and compliance partners.  The culture of your organization may aid/resist this step-up.


4. Scale -  Horizontally 

In order to generate initial buy-in across a wider spectrum, it always makes sense to scale horizontally first, so that you can achieve critical mass for your community. This allows the members to contribute and break the ice, and helps in the initial stages in collaboration for the 'core' team, as each member brings some additional value to the conversation. We call this strategy as the - Go Wide move

It always helps to create a rhythm for the community with regular schedule of activities that brings the participants together on a regular basis, and combining familiarity and excitement, by focusing both on shared, common concerns and perspectives, but also by introducing radical or challenging perspectives for discussion or action.

5. Scale -  Vertically

Post the initial buy-in, and few first steps, there are always challenges of - What next? Who runs? When? How?

Try Vertical Scaling! - which means going deeper into the sub-topics of interest / work streams within a common umbrella, focusing on multiple aspects: roles/functions/location/on-line/offline medium

As the community needs to be refreshed every few seasons and undergoes an ownership transition, which will happens as you scale vertically now, it is OK to disengage the earlier passionate core and let a new 'core' emerge. Other options include introducing Game mechanics in the community, and allowing for non monetary rewards and publicity for the passionate volunteers.

In the end it is the Passion that always rules!

The key to building successful communities is to provide an enabling platform and a safe environment for people to share their stories without any judgement or fear of failure.

I would definitely be interested to hear if you have used these or additional steps to make your communities a success !!


Photo Source: http://bit.ly/2d39F6R

Try these 3 strategies to FIX your DevOps problems!

In my previous post, we saw the Top 3 DevOps challenges faced by organizations today. So let us review how organizations can address these challenges by leveraging the power of systems thinking, feedback loops and cultural transformation at the core, to claim the real promise of ‘agility’ for the customers and stakeholders

TOP 3 SOLUTIONS

·      Build Ownership

The goal is to foster win-win relationships, where the dev and ops team start thinking as a SINGLE UNIT, responsible for end customer delight! This requires the organizations to align the Goals for both the groups and provide the ‘right’ environment for collaboration.

Organizations which understand systems thinking, can help the Dev and Ops teams visualize the FLOW (from concept to cash), and are able to articulate the importance of cycle time, while error proofing and preventing downstream defects (aka. operational headaches).

These teams typically use Value Stream Maps, to share the areas that slow them down (or identify bottlenecks), while building a shared understanding of the complete end to end system. These exercises allow the teams to build empathy for each other’s roles and share the pains, thereby allowing the silo’d groups to start to trust each other and build better relationships over time.

·         Build Shared Practices

The long divide between Dev and Ops can be bridged by amplifying the feedback loops at every step in the end to end delivery cycle and sharing the knowledgebase and increasing transparency across both the worlds.

Organizations typically start this journey by treating Infrastructure as Code, where there is a single repository of truth and everything is version controlled. The teams start thinking about making each step of the highest quality and incorporating feedback from multiple levels – application data, process data, infrastructure dashboards, and business metrics – to highlight pain points early and design shared solutions around the problems. Refer the diagram below highlighting the areas for embedding and/or extending the teams and crossing the systemic boundaries.

Organizations can be seen experimenting with embedding Ops and Dev team members across each other’s groups, which allows for increased empathy (example – Design for Operations), learning’s and increased collaboration.

                                                                                        Source: DevOps Patterns Distilled (Velocity London 2012)

·         Build a Learning Culture

The best ways for bridging the cultural gap between dev and ops is to build a learning culture. Organizations which embrace the learning culture are good at communicating a compelling reason for the change (primarily business outcomes), measuring the new behaviours and giving feedback, creating “triggers” in the work environment that remind teams what needs to be done, and building communities (CoP’s) that support this shared learning

The leadership encourages learning from failures, and is happy to conduct experiments and take risks, promoting a healthy culture of constant innovation while aligning team goals and changing human resources policies.

In the end

Dev-Ops is a long journey and it begins with building a “we” culture among the development and operations teams with shared goals and shared incentives. The improved communication and collective ownership fosters an environment of trust, leading to sharing of ideas, tools, processes and everyone focussed on delivering business value at the end of the day.

Let me know what other solutions you have practiced with your DevOps teams.

Top 3 challenges in your DevOps journey

The 2014 State of Devops survey report clearly shows higher organizational performance linked to the performance of the IT group and it's DevOps practices. But most organizations are still struggling in their IT-DevOps journey  - "only 21% of those familiar with it are using it". In the DevOps journey the main objective of "Collaboration between the Dev and Ops" faces many challenges! Let me attempt to highlight the Top 3 challenges faced by most organizations.

TOP 3 CHALLENGES 

• No Shared Ownership

Most programs typically have Development and Operations as separate teams, with conflicting goals.

The top down goals for development teams are to build features (potentially shippable increments) at short regular intervals so that they can be deployed, with all incentives promoting 'faster' build cycle, versus the operations team goals favor operational stability with changes minimized, in order to maintain existing system reliability and high availability, with incentives for reducing operational costs.

These conflicting goals setting lead to development teams “handing off” the code to operations after development, and operations "pushing back" almost every time.

The overall impact is that the feature 'go live' date is delayed, with both the groups lacking "shared ownership" for reducing the overall feature delivery cycle time from an end customer view point.

• Physical separation

Development and Operations teams are separated by distance, and mostly do not share the same physical location or work area. Most organizations will have centralized operations teams, possibly across time zones for larger enterprises.

The silo'd physical structure is also carried in the silo'd organizational structures with different reporting heads for both the teams, thus ensuring that local optimizations rule the day, with the Operations team members managing and running multiple applications, in closely guarded areas, with restricted access or interaction opportunities with the Development teams.  

How can you relate to someone whom you have never met face to face and never talked? bye bye collaboration !!

• Cultural differences

Cultural differences are visible in the behavior and actions of both the development team and the operations teams. 

The lack of trust and transparency on both sides is what manifest in the communication gaps on both sides, with the development team having minimal visibility on deployment activities and feedback on production systems (read  infrastructure metrics), and the Real business metrics and similarly the operations teams having minimal visibility on what is the expectations on the features wrt.  scalability, run books, or reliability that they should care about to maximize the applications potential and operate as expected by the development team. 

The lack of shared evidence and the missing Shared ownership clearly comes out and creates a sense of mistrust and results in overall delivery delays.


“The developer and operations divide in IT is almost like humidity at times. You can’t see it, but you feel it,” - This quote from the Starabucks devops post sums the challenges....  

what are the challenges do you see in your devops journey?


Look out for my next post which will try to address possible solutions for these challenges...

Step by Step guide to installing Robot Framework

Robot framework has been a little tricky for most folks though now provides an installer for windows, but still it is best to know the detailed steps if you do not wish to use the Installer.

So let's get started -

Installing Robot framework - requires Python installation first as a pre-requisite.

All steps below for Windows OS (32/64 bit)

Step 1. Install Python version 2.7.8 
(supported Python version for Robot Framework version greater than 2.7)

https://www.python.org/downloads/
Installer Files:  python-2.7.8 - for 32 bit / python-2.7.8.amd64 - for 64 bit

Ex. Installed at c:\python27\

.....read more

Top 5 Agile project Myths – Smashed !

Catching a glimpse of a snake charmer on a busy Indian metropolis, is a big myth that many foreigners visiting India still cherish (wishful thinking you might say!). But the reality is that snake charming is illegal in India (India Wildlife Act) and has been for a number of years, although snake charmers do still exist and are now an ‘elusive’ sight. But the myth still exists and something similar is the case with the agile projects and the myths surrounding them.

If you take a look at the the annual state of agile surveys for last few years, they have been throwing similar results wrt 'Concerns' about Agile (read as Myths – see below Reference1), reflecting the dismal failure of the agile enthusiasts to be unable to bust the folk tales surrounding the agile projects delivery. This post hopes to therefore Smash the Top 5 agile project myths (popular faolke tales), with a pinch of sugar/salt (take your pick) for added flavour.

Source: Reference 1

Myth1– Agile projects do No Planning

The traditional projects have a Big plan upfront, and planning is highly visible, with a complete plethora of activities, draining the energy for a couple of weeks\months, and resulting in a sometimes scary GANTT chart.

But Agile projects instead focus on Continuous planning, and planning is therefore invisible!

...read more

Mr. Product Manager: Are you ready for the brave new Agile world ?

This was an interesting question, which got me thinking to rant out on the state of product managers in the Scrum India meetup in 2011.

The fact is that after couple of years later, I still see that the product management is not ready and not ready to embrace the new world. So here's my wake up call again for them (from my archives) and possibly make atleast some of them embrace the new agile world now. You can hear my rant (pecha kucha style) in the video below. Feel free to drop me a note on your experiences.

Agile Balanced Scorecard - Does it exist ?

It is indeed a difficult question to answer!  The "Agile" Balanced Scorecard may or may not exist today (the literature published is pretty scant on this), but if you are looking for developing this scorecard or modifying your existing Balanced Scorecard for your organization, then you may want to watch my video below in the Agile India Kerala 2013 conference titled - Balanced Scorecard for the Agile Enterprise
Watch the Video here

3 Simple steps to build your Continuous Delivery Dashboard

Continuous Delivery is gaining traction now, but it is never easy to get funding :-|| But using Lean Value Stream Maps you can now showcase tangible efficiency gains by following these 3 simple steps to build your Continuous Delivery dashboard.

In uncertain times, people always struggle with executive funding for resources (infrastructure asset purchases and/or dedicated people). This is where I have borrowed the Lean Value Stream maps (VSM) to showcase visible dashboards focused on process efficiency gains, resulting in hard $$$ savings, and help win executives approval, for funding the various activities under the Continuous Delivery initiatives.

Here is a basic definition for Continuous Delivery, which is a set of practices and  principles aimed at, building, testing and releasing software faster and more frequently. The practices would typically include configuration management, continuous integration, automated testing, deployment automation, build pipelines and an agile team delivering frequent releases.

.... read more

Is your engineering team leaning to "Heaven" or "Hell" ?

Listening to the legendary Eagles, Hell Freezes Over album, it always touches a high point for me with the lyrics -

I heard the mission bell
And I was thinking to myself
'This could be heaven or this could be Hell

Well the mission for the engineering team(s) is to provide a continuous flow of business value to the stakeholders, with stable teams working at a sustainable pace, while improving their technical excellence daily.

But do we really know if we are any closer to achieving this mission or are we simply stuck and wondering if we are holed up and have no way out ?

So to find the answer, take this 20 Questions survey below and SCORE your engineering team(s) to check your WAY,  and find if you are indeed leaning towards Heaven or Hell ?

For each question below, use this RATINGS SCALE below to assign a score to your response -
• 1 – 4  : No , we do not ….……you are possibly closer to HELL than you think ~~
• 5 – 7  : we try and succeed mostly…..you are moving closer to Heaven
• 8 – 10 : we do this almost every time and love it ..you are reaching HEAVEN-ly Bliss !!

Prerequisites:

1. Are using ‘High Maturity’ Engineering Practices and Tools ?
2. Do you have Sponsors commitment to Technical Excellence ?
....read more

Enterprise Customer Feedback : Lost Horizon or Last Horizon ?

Are your enterprise customers giving you the feedback when your engineering team wants it or do you lose your delivery heartbeats with late or non existent customer feedback ? To explore this further, let's rewind while fast forwarding a little.

Today the future of Business and IT is to GO Digital, with an increased need for the CMO and CIO to coordinate and deliver value to their stakeholders. But the 2013 Gartner study for CIO's indicates that this customer value delivery gap is still a major challenge with "the vast majority of IT organizations need to address fundamental gaps in their performance".

Thought it appears that the IT world has in the last decade or so made some progress with this metric of delivering customer value, (quote below) and have started to learn and some are now able to Build-IT-RIGHT now unlike the past, but still there is a long way to go....(68% still feel that customer value is not delivered by IT)

32% of the respondents felt that delivering customer value was most valued by their organization’s executives for the delivery of Scrum-based projects 
Source: State of Scrum 2013, Scrum Alliance

This intense focus on the ability to Build-IT-RIGHT is primarily thanks to the force of iterative agile delivery model with short iterations combined with some XP practices of pair programming, test driven development, and continuous delivery (including continuous integration and continuous deployment) .

But Build-IT-RIGHT assumes that the "closed loop" will always have a customer onsite, ready to provide instant feedback and ignores the dark reality of the real world scenarios. But in my experience most IT teams implementing agile methodologies today face one or more of these situations :

1. No colocated Customer with the IT team
2. No colocated Customer representative with the IT team (Product Owners are just a bad substitute!)
3. Customer feedback is non existent
4. Customer feedback rarely  - once in a year via Customer Advisory Board or similar
5. Customer feedback has long cycles typically more than 6 months 

The naysayers will indeed argue for the Cloud based application deployments which may be a rising trend with a tepid growth but the majority of the world is still run by enterprise applications hosted internally by the customer IT teams, and hence have a LOOONG phase gate approach to accepting new versions. The old IT world mindset still rules with mistrust and high risk as key factors for accepting the status-quo.

For the few lucky organizations, the new world mindset allows them to embrace the Lean Startup mode, with A/B tests as rapid feedback, Dual Scrum tracks and Continuous Delivery models. But this closing of the feedback loop is still a long way to go mainstream. Till then we are close to  there but still missing out on the Last Horizon to achieving IT and Business agility.

In Summary, with the IT teams as both a consumer and a provider of services to the business, this new mindset is an opportunity for the CIO's to conquer this LOST Horizon !

What's your experience on customer feedback (especially enterprise customers) ? Have you captured this LAST Horizon ? or are you losing the horizon ?

Don't miss the ALN - Delhi Chapter event : "Agile in IT Services"

ALN Delhi NCR Chapter is hosting the Chapter meeting this Saturday, 27th July with a focus on "Agile in IT Services". This is a FREE event with no registration charges, so spread the word please. If you wish to see the details, here's the Agenda.

Join me and other speakers from service organizations by registering your seat (only limited  seats). I will also be presenting on the PMI-ACP (Agile Certified Practitioner) Certification Overview and will talk about how you can benefit from this ACP certification in your professional careers. Drop me a personal note if you need more information.

Power of Acceptance Tests : Do you really know ?

Multiple teams struggle with story completions and miss their Definition of Done, and forget how the simple act of conversation via acceptance tests can really make them wiser and their lives less miserable !

So what really happens when you start writing acceptance tests "before" any implementation (of actual code or test code) ?

Here's what I have experienced -
1. you tell - what you think no one knows
2. you tell - what you think only some of you know
3. you know now - what everyone else thinks that you already should have known
4. you now know  - what everyone else knows
5. everyone knows now - what everybody on the team knows

In the end  : You and everyone on the team are now wiser than you were before this conversation.

So go on and use the Power of Acceptance tests and Be Wiser.

Share your experiences and let me know what you have seen.

Learning A...Z in the "x"DD world

Explaining and exploring the world of ATDD , BDD, TDD, had me wondering on the fascination in the software industry for the "x"DD acronyms and sent me looking out how the mavericks have been exploding this over in the industry evolution.

The RESULT:  My little Glossary of A...Z in the "x"DD world

ATDD - Acceptance Test Driven Development
BDD - Behavior Driven Development
CDD - Capability Driven Development
DDD - Design Driven Development / Domain Driven Design
EDD - Example Driven Development
FDD - Feature Driven Development
GDD - Goal Driven Development
HDD - Hypothesis Driven Development
IDD - Interface Driven Development
JDD - ???
KDD  - Knowledge Discovery in Databases (hmm...not in the same league)
LDD - Language Driven Development
MDD - Model Driven Development (MDA), Metrics Driven Development
NDD - ???
ODD - Object Driven Development
PDD - Plan, Performance Driven Development
QDD - Quality Driven Development
RDD - Readme Driven Development
SDD - Story Driven Development , Scenario Driven Development, Service Driven Development
TDD - Test Driven Development
UDD - ???
VDD - Value Driven Development, Value Driven Design
WDD - ???
XDD - XDA Development - Android
YDD - ???
ZDD - ???


Feel free to either start thinking about inventing in the missing ones (???) or add your variations in the comments below. I will be updating the hyperlinks to most soon.

Incase you are looking for some "x"DD recipes on the wilder side, you can check out Damien's note and Scott's take on these.

Till then, Happy "x"DD-ing !

Join me on Agile Tour,Hyderabad and get Discounts!

As part of the India Scrum Enthusiasts Community (ISEC), Agile Tour, Hyderabad conference on 3rd November 2012 is coming up shortly. If you are in Hyderabad and want to learn, hear and network with fellow agile practitioners then this is a a must-see event in the Hyderabad area. Read more on the Conference details here  - "Agile Engineering Practices, Sprint internals and ScrumAnd"

The keynote speakers include Anil Bakshi (Xebia CEO) and other interesting sessions on continuous integration, feedback, including myself talking about "Acceptance Test Driven Development using Robot Framework"

ISEC is offering a limited period DISCOUNT:   ‘Buy 1 get 1 free seat’ offer i.e. For 1 delegate registration you get 1 FREE delegate entry !!

Contact me ASAP if you are planning on attending and need the discount code details.  Enjoy the weekend !

UPDATE: 18 Nov 2012-  Watch my Presentation slide deck below and contact me for more details.

Acceptance Test Driven Development using Robot Framework from Asheesh Mehdiratta

Continuous Testing: Building Agility at Scale

As organizations scale their agile efforts and work across distributed locations, integrate products across business units, and develop solutions with their partners and become suppliers, they are facing integration challenges at an even bigger scale.  I will be discussing some of the challenges and solutions in upcoming postings.

The worlds of testing, development and the operations teams had already been struggling to collaborate in the software industry (with or without agile) and only recently have been able to reconcile to some extent, led by aggressive ALM (application lifecycle management) vendors and the upcoming DevOps movements. But the sheer size of integration due to scale complexities has further exaggerated this problem !

But the agilistas have many  tools to beat this complexity and the challenges can be  overcome by combining these. Reflecting back and recognizing the power of available techniques -  from extreme programming methodologies to the power of automated testing -  the agile toolkit offers a heavenly state of "Continuous Testing", which allows the organization to reduce the costly integration errors and provide continuous visibility to the business stakeholders while maintaining continuous high quality benchmarks.

Continuous Testing is based on the integrated framework of continuous integration (build stage) and continuous delivery (deploy stage) pipelines, which allow the engineering teams to run multiple builds and deploy cycles per change (using a continuous integration server) and performing the testing activities in parallel, across the various application life-cycle stages. The term ‘continuous testing’ was coined in 2003, to run the tests continuously to enable rapid feedback, while the source code is being changed.

I will be discussing more on the details of Continuous Testing in my upcoming series. Keep watching this space....

Agile Manufacturing - Dream on, dream ON !

If you ever thought that 'Test Driven Development' was difficult to adopt in your co-located, software teams, then see how these XTREME Agile practices, along with 'Pairing' and 'Kanban' have been applied to the Manufacturing World, which is being shaken up by WIKISPEED, breaking down the traditionally long cycles, barriers and conventions.

Watch this TED video by the founder, Joe Justice on how he is challenging the automotive world using Agile techniques and building the most ultra efficient, modular cars on the planet today, possibly paving the way to the future for "selling transportation" instead of selling cars.


If you have a similar story to share, drop in your comments and enjoy !

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.