RSS

Category Archives: Agile

Enterprises – Ignoring users is killing your software adoption!

Published originally on medium on June 12, 2017

If you lead any kind of software delivery team as an executive, manager, leader, or whatever title makes you happy, take a moment to meet your delivery teams and tell them this: “..keep up your work, just remember that whatever you are building, only 25% of it is going to be really used…”

What do you think their reaction will be? In today’s enterprises, it’s a reality. There is a lot of waste: of effort, money, and creativity.

Especially, in large organizations where we have:

  • Removed the involvement of users who really need help to solve their problems
  • Added layers of communication, documentation, and processes to capture their needs, that in turn are handed over to somebody else developing the solution (with little to no context of the problem)

During my first decade in IT, I was very proud of the software solutions I was responsible for: as a developer, business analyst, and project manager. Had I known only a fraction of it made any real difference, it would certainly not have helped my motivation. I have met product owners who have NOT seen, met or had any interaction with the users that they are building the solutions for.

Agile software development tries to address the gap but, in my experience, many organizations fail at it because there is no direct user involvement. Unless the delivery teams meet the real users, they simply cannot relate to what problem the users are facing. If you don’t understand a problem, how can you solve it? Direct interaction with users helps uncovers hidden assumptions, provides the overall big picture and specific context, pains, gains of how their actions impact the business.

At times, the problem doesn’t even need something to be done by the software! Yet, we form layers of communication channels to capture user’s needs, wants and requirements and pass them through multiple teams until it reaches the delivery team — convoluting and diluting the real needs. Some enterprises provide the excuse that their users are too busy to provide inputs to the new effort that will make their lives better. (Where have I heard about it…Oh, wait!)

Picture courtesy: Alalia Lundy

Delivery partner(s) and their teams are often brought in as an afterthought and are handed over deliverables (requirements or user stories) to craft the state of the art software solution, with latest and greatest technologies.

Jeff and Josh mentioned about this problem in their book Lean UX.

From: http://www.leanuxbook.com/ by Jeff Gothelf & Josh Seiden

In the recent decade, using more and more of lean software development approach, UX (User eXperience) and modern business analysis skills, in conjunction with working side by side with users, taught me a lot.

It starts with empathy.

Empathy is the ability to understand and share the feelings of another.

We need to empathize with the users, be in their shoes. Ask yourselves, how can a person sitting in a cubicle, who has never been a part of the domain in question, can understand the needs of a user (Example: a bio-technician, a warehouse worker, salesperson etc.) who is using the software in a particular environment?

Empathy is a life skill that everyone in software needs to acquire. Some people are naturally skilled and it, others need to work at it. Understanding users and what they want is a laborious and tough skill, but one worth acquiring. Only by empathy can we create better software that has a higher user adoption rate.

One of my projects was about providing an on the ground sales team access to their data in a convenient format which they could easily update. The customer decided to move off of a commercial off the shelf (COTS) product as it was too cumbersome to use and configure. During the initial discussions of the project, we were told by the customer leadership that they wanted to have a custom built solution to tailor to their user’s needs.

Challenge was, they did not think it was important for us (delivery team) to get to know the users. It took a lot of convincing of the immediate leadership to get us access to users. Once our (User eXperience) UX team did their research and analysis, the same leaders were surprised to find things that they were completely unaware of:

  • The sales reps were not at all using the COTS product and hated it
  • They instead created shadow excel spreadsheets to help themselves track their numbers
  • Each group and every person had their own different versions of it
  • These reps spent lot of time creating and maintaining this data, spent time coordinating with other teams and still had data reporting issues

Once this detailed research was shared with the customer leadership, we saw an immediate change in their attitude and approach. A year after delivering the solution, when I checked in with the IT management we were interfacing with, they were beaming with joy and shared that the delivered solution had a very high adoption rate. The simplicity and usability of the solution had spread throughout the company and that application is one of the most successful deliveries in their company history.

I can cite more examples of success when users were involved early on and failed projects where users were an afterthought. Sometimes the user themselves don’t know what they want!

It is an iterative process, an art to research and explore what the users want. A process of skillfully drawing out assumptions and validating (or invalidating) them using multiple tools in your pocket — continuously throughout the delivery.

In my experience, when we focus on the following:

  • Do we really understand the problem?
  • Does the proposed solution solve the issue?
  • Just don’t take the information on its face value: Challenge and improve their processes, enhance the experience
  • What impact does it have on their lives (and in turn the business they represent)?

In the end, remember that business is engaging with delivery partners to solve a business problem. Business is operated by the users, involve them as early and often as possible.

So next time when you hear in your enterprise projects that “..we will have to work without involving the users directly..”, I hope you will challenge that stance and help initiate the dialogue about why user involvement and input is necessary, beneficial and economical in the long term.

Advertisements
 
Leave a comment

Posted by on June 22, 2017 in Agile, Business Analysis, UX

 

Organizational agility in practice

Posted originally on Medium on April 15th, 2017

Joseph Flahiff states in his book, “Being agile in a waterfall world”, Agile is about the ability to adapt (to changing circumstances), it is an adjective and not a noun.

For a person, agility could mean — physical agility (someone with a flexible body) or mental agility where they have the ability to learn and adapt to a new skill (language, subject etc.). For a business it is about their ability to respond to changing marketing needs or customer demands.

In the IT industry, this word has been lost it’s meaning. It has become a fashion tag that everyone claims to be associated with. You hear individuals, companies saying, “We are agile, because..

  • We do Daily stand-ups
  • We use Scrum..or any other framework
  • We use JIRA … or any such tool
  • We write User Stories..”

… the list goes on. These statements reveal a lack of understanding of the essence of agility. Such Businesses and enterprises chase the end state without changing their behavior, implement new tools or frameworks, but fail to inspect and adapt. They fail to cater to their customer’s needs — the reason for their existence.

In my nearly two decades of software career, I have experienced many businesses trying to “Go Agile” but in the last 3 years since I joined OutSystems, I have experienced what I can identify as organizational agility. During my tenure here, I have seen the core of OutSystems (the platform) evolve in a dramatic way. I started with platform version 8 and saw the product evolve in multiple increments in just few months — an already robust product, becoming the best and most extraordinary tool I have experienced in the market. It was a great feeling using the latest and greatest product and implementing enterprise grade applications for our customers. In matter of 10 to 12 weeks we completed enterprise grade projects and then tackle the next customer to solve their challenge.

OutSystems Engineering, Product and Leadership teams had a trick up their sleeve. Some of us were unaware of the change brewing. In Paulo Rosado’s words, there was an open heart surgery going on to create OutSystems 10.

It’s not just a new version of the product, but latest version that supports mobile development with offline capabilities — a redesign of a decade plus old product which has improved in increments. A reinvented product that came into being to ease enterprise customers struggling with mobile application development challenges.

Following this incredible change to the product that OutSystems developers around the globe are thrilled about the capabilities OutSystems 10 is providing them! This is a major win for the organization that has always been focused on helping customers succeed. Pivoting to put the customer right in the middle and reorganize the whole organization in the new direction. We have experienced changes and realignment in multiple departments like: Marketing, Sales, People operations, Support, Delivery-Enablement and Training.

This organizational change did not happen as a big bang. It came through a series of experiments with the product, testing those with the participating customers and by following lean-startup principles in an enterprise. The results have been outstanding with stories that make an impact.

If you have ever been through at least a departmental change, you can appreciate the impact of change at an organizational level. It is not an easy task, but at OutSystems various teams welcomed that with open and experimentation mindset, reorganized for the ultimate goal — Customer Success.

There are times when the environment can get cloudy, unstable, negative. But, even with the rapid growth the company has been experiencing, the culture at OutSystems is guided by The Small Book of the Few Big Rules and I personally really appreciate the benefits of such open, safe and supportive environments.

Conclusion

Agility does not come from copying some frameworks, but from people who can lead, a culture that enables to experiment, inspect and adapt.

 
Leave a comment

Posted by on April 22, 2017 in Agile, Musings

 

Tracks issue on Agile2017 submission form

The reason for this post is simple: I am not sure if there is a way to report discrepancies to Agile Alliance (@agilealliance) on it’s site – especially for the #Agile2017 program.

It is an attempt to collect these issues reported/observed, a running backlog and not any criticism. After all, I am a part of volunteer in #Agile2017 and want to make it the BEST conference ever.

Thanks to Dave Rooney, Chet Hendrickson and conversations on twitter, here’s the comparison:

  1. The tracks listed on the main site (with their definitions), do not match the options available on the proposal submission page.
Track available on main page Is this track available on submissions page?
Agile Companies

 

Yes (Under – Process at Scale)
Agile Foundations

 

No
Audacious Salon

 

No
Coaching & Mentoring

 

Yes (Under – People)
Collaboration Culture & Teams

 

Yes (Under – People)
Customers & Products

 

Yes (Under – Process at Scale)
Development Practices & Craftsmanship

 

Yes (Under – Technical)
DevOps Yes (Under – Technical)
Enterprise Agile Yes (Under – Process at Scale)
Experience Reports Yes (Independent Category)
Leadership Yes (Under – People)
Learning Yes (Under – People)
Project, Program & Portfolio Management

 

Yes (Under – Process at Scale)
Stalwarts

 

No
Testing & Quality

 

Yes (Under – Technical)
The Future of Agile Software Development (IEEE Software)

 

Yes (Under – Miscellaneous)
User Experience

 

Yes (Under – Technical)

In addition to this post, I have used the contact us form on Agile Alliance site to report the issue. Hoping this gets fixed soon.

If you see any such issues, please feel free to share on twitter using #Agile2017 tag, Comment here or @ me!

 

 

 

 
1 Comment

Posted by on December 14, 2016 in Agile, Volunteering

 

User Stories: My knowledge bank of “value”able reads

I have been writing user stories for more than couple of years now. I am still learning and improving. And every story I write next – I try to improve it: Bring “value” to it. As a group manager of few online agile/scrum groups, I see many experienced people struggling to understand the concept of user stories.

Even met people who claim to have quite some experience in writing user stories – but when you hand them a card and pen, they go blank.

With respect to user stories few points need to be remembered:

1) They are from “users” perspective – So PLEASE involve the customer/user of the system while writing (Better let THEM write, if your org allows that)

2) A user story w/o an acceptance criteria is like a human w/o spinal cord.

3) There’s NO such thing as a PERFECT story – the dev team with product owner and customer have to come to an agreement to say the story is GOOD to go and can be used by development team for breaking down into tasks.

With all that said which can be debated as EVERYONE has a opinion, I started putting together some knowledge base for user stories. If you can help contribute to these links, PLEASE feel free to comment on this post and help point to valuable content related to user stories:

What are user stories? http://en.wikipedia.org/wiki/User_story

INVEST: http://xp123.com/xplor/xp0308/index.shtml

@mikewcohn: http://www.mountaingoatsoftware.com/topics/user-stories

@scottwambler: http://www.agilemodeling.com/artifacts/userStory.htm

@agilescout: http://agilescout.com/presentation-writing-better-user-stories/

http://agilescout.com/agile-guide-estimating-user-stories-in-agile/

http://agilescout.com/agile-user-stories-specific-role-names/

@mlevison http://agilepainrelief.com/notesfromatooluser/2010/09/story-slicing-how-small-is-enough.html

http://agilepainrelief.com/notesfromatooluser/2010/12/more-notes-on-story-splitting.html

@peterstev: http://www.scrum-breakfast.com/2008/02/explaining-story-points-to-management.html

@davidjbland: http://www.scrumology.net/tag/story-points/

There’s a LOT of information out on internet that can help you learn about user stories – if you’re a member of scrum alliance, there are valuable reads on their site submitted by agile practitioners. But NOTHING can get you the experience unless u start writing them yourself.

So, what are you waiting for: Grab a index card, a pen (or go the digital way) and collaborate with your customer team, product owner and developers to start writing – then scratch few, negotiate, refine some more, scratch again and come up with a user story that is ready for your product backlog.

Disclaimer: The only idea regarding this post is a centralized page for me to reference valuable content on User stories. If you have pointers and suggestions, please feel free to comment.

05/13/2011: Got a GREAT read from Martin Fowler that needs to be added to this list: Conversational Stories. I am so very happy to share that I AM practicing this with my team as a Proxy PO!

 
2 Comments

Posted by on March 27, 2011 in Agile

 

Agile & Music: Suggestion for an experiment

Instruments

Who doesn’t love music? We all have different choices, tastes – but we all listen and have our favorites. I like listening to variety of music and play guitar (Disclaimer: I am not a music major or a pro).

There’s been this one thing on my mind since a long time and could not resist this post when I saw David Bland’s tweet about “Kanban-Agile Jazz“. [Don’t forget to check out the trackback link at the bottom of that article by Olaf Lewitz].

I have observed one strange coincidence when I met, read about and researched some famous agilists. Many of them play guitar (or a music instrument.

To name a few (on twitter): @mcottmeyer, @howardsublett, @dennisstevens (if I am not wrong), Dave Minor, @darianrashid (drums) and the list goes on..(you get the point).

Most importantly, the experiment that I have in mind is on the lines of what Olaf mentioned in his post:

  1. In next agile (or scrum or kanban or XP) get-together event, invite the attendees WITH their instruments
  2. Ask the attendees at the gathering to form a band by choosing among themselves
  3. Create a tune or select a song of their choice
  4. Practice for a few times and then
  5. Present for few minutes in front of the get-together audience

Yep, you’re thinking right; something like the “YouTube Symphony Orchestra” on a very small-scale.

Why do this?

  1. Fun & Entertainment
  2. Interactive and engaging
  3. Something different/Innovative than just doing “hands-on” sessions, open space, games
  4. Displaying agile principles/values: Collaboration, Self-organizing teams, Improvisation, Iterating, Practicing and Delivering

 

Jazz

As you can see from Olaf’s “White Night..” post few passionate people have used the Jazz experiment to get their point across to the audience about improvisation. After all, people get-together to discuss what they are passionate about (agility) and in that people form  small groups, get engaged in discussing topics of their interest. If people don’t find the topic interesting they use the “law of two feet” from open space in search of discussion that engages them.

So, why not meet with like-minded music (agile) enthusiasts at such events and jam?

Note of caution: Please make sure you don’t get lost in music so much that you forget the main purpose of being at the (agile) event 🙂


 
11 Comments

Posted by on December 27, 2010 in Agile, Music, Musings

 
 
%d bloggers like this: