Say YES!

Really liked this sign on my colleague’s desk.


It says:

Start With Yes


I remember an old boss who used to say:

Don’t make me get through no to get to yes. 


The idea as another colleague put it is to:

Keep a smile on your face and your focus on the customer; everything else takes care of itself. 


Basically, it’s all our jobs to make sure that the customer’s needs are being met. 


That doesn’t mean that we don’t need to differentiate between requirements and desirements or that we need to deliver the yacht in the first go around.


As a 4th colleague put it:

The customer is in the water. They want the yacht. But I can give them a boat. It gets them to where they want to go, and they no longer need to swim. We can work our way up to a yacht.


Good analogy analogy and good things to keep in mind for customer service excellence! 😉


(Source Photo: Andy Blumenthal)

Advertisements

Don’t Just Sit There

Really liked this robot (Cubebot) in the store.


Love the colors and that you can change the pose in all different ways. 


This robot is pretty darn cute!


It’s funny in this sitting position though.


Just want to say: 

Don’t just sit there, do something!


Probably not that long before robots will be all over the place.


We’ll wish for just a little privacy from the darn things, just like from our 24/7 computer gadgets that we can’t let go of now.


Yes, we’re hopelessly dependent on the technology–it’s so helpful and we love it, but we can’t turn it off. 


They won’t be sitting for long. 


Robots–big and small, alone and in swarms, male and female, strong and intricate, smart and simple, worker and homemaker, doer and helper, companion and lover, where will it stop–it won’t. 😉

(Source Photo: Andy Blumenthal)

Agile Doesn’t Mean Endless

So Agile development is great for iteratively working closely with customers to develop and refine information systems that are useful to them and the organization.


But even in Agile, there is a beginning and an end to the sprint planning and project management.


Taking Agile to somehow mean endless in terms of adding more and more requirements or scope creep is not what is intended. 


Agile has to be bound by common sense somewhere between what is needed for a minimally viable product (MVP) and what is achievable with the designated resources, objective, and scope. 


Good project managers always have to be sound arbiters and be willing to ask the tough questions and determine if something is truly a requirement or simply a wish list item that is out of scope (but of course, could perhaps make it in for future enhancements).


We need to understand the difference between genuine customer service and irrational project exuberance based on inflated expectations. 


It’s not a dangerous project bubble we want to create that can and will get busted, but rather a successful project that is delivered for our customers that help them do their jobs better, faster, and cheaper.  😉


(Source Photo: Andy Blumenthal)

DMAIC Reengineering

A colleague gave a wonderful talk the other day on process engineering.


The key steps to reduce waste (Lean) or variation/defects (Six Sigma) are as follows:


Define – Scope the project.


Measure – Benchmark current processes.


Analyze – Develop to-be processes (with a prioritized list of improvements) and plan for implementation.


Improve – Executive process improvements.


Control – Monitor/refine new processes.


It was amazing to me how similar to enterprise architecture this is in terms of: defining your “current” and “future” states and creating a transition plan and executing it.


Also, really liked the Project Scoping questions:


– What problem do you want to solve/what process do you want to improve?

– Why do you need this?

– What is the benefit?  And to whom?

– What are your objectives for this effort?

– Who are the key stakeholders?

– When is this needed and why?


I think process improvement/engineering methodologies like this can be a huge benefit to our organizations, especially where the tagline is “Why should we change–we’ve always done it this way!” 😉


(Source Photo: Andy Blumenthal)

Make The Right Move To Agile Education

So, unfortunately, our education system in this country is highly troubled


Generally, we teach by strict curriculum forcing children to learn what we consider “the fundamentals”.


But they are anything but that and kids come out not knowing how to do the very basics or survive in life. 


Test scores have not been improving–that’s not the student’s fault, but the education system, which cannot force feed what students minds are rejecting as “old school” and out of touch.


Not only don’t we fish for them, but we don’t even teach them to fish. 


We throw at them esoteric subjects to memorize, spit back, and forget. 


Wash, rinse, repeat. 


We waste years of their life and the productivity and creativity of society. 


Ever really wonder why GDP growth is only around 2% despite all the rapid technology that we are rolling out. 


It is just not drones that we are rolling off the assembly line, but human automatons as well. 


This is where agile education comes into aspect. 


Like with software development, we can gather requirements and build, and then show the customer, and then refine again and again. 


We let the development grow and mature naturally as the code takes shape. 


No more years of development and voila here’s something for you, and with the customer exclaiming loudly, “What the F*** is that!”


So too with education, we need to follow the spirit and train of thought naturally. 


Where we let the students guide the teacher to what their questions are, what they are interested in learning about, where their creative juices take them, and what is relevant. 


Rigidity in the education system leaves our students as dead ends, and not as critical thinkers and innovators.


We have a dearth of leaders we can look up to and a plethora of people that couldn’t survive the Spring without their Visa/Mastercard.  


Ever wonder why so many of our great innovators are college dropouts who built their companies in their garages instead of occupying a seat in a classroom and filling their heads with teacher rhetoric. 


Most people learn by seeing, internalizing, and doing useful things for themselves, not by listening and violently rejecting the irrelevant in their lives. 


Let us release the choking reigns of our education system. 


Teachers should be able to follow the questions and interests and natural evolution of thought and creativity and wonderment with their students. 


The mark of learning is not the answers on a standardized test, but the light bulb of critical thinking and innovation from our progeny. 


Exploration and discovery and skills to be self-sufficient and survive are far more beneficial than what we are giving our children today.


We owe them a better education, but we are not delivering because we are the automatons of yesteryear. 


(Source Photo: Andy Blumenthal)

Who You Calling Ugly Baby?

So in multiple organizations, I have heard systems referred to as ugly babies!


Whether or not it’s true, it certainly doesn’t make the IT folks that develop, run, and support that system feel very good. 


Are some of these (legacy) systems ugly?


Well, of course, they are. 


Many of them work despite themselves. 


What I mean by that is they are awkward to navigate and use. 


The functionality is flawed or outdated.


The workflows are unnecessarily complex.


The user interface is inconsistent and sloppy. 


The user experience is punishing. 


I told someone recently in using a particular system that was so convoluted:

“Is this system what they give to prisoners and make them use over and over again to punish them for hideous violent crimes?”


Seriously, that’s how it felt, even as I knew it was still lightyears ahead of what a paper process still used in other organizations looks like.


Generally better than the waterfall methodology for the systems development life cycle, I understand that one dilemma with agile development is that requirements can be spotty from sprint to sprint and instead of doing the hard work and thinking it out upfront, users are made to expect a nearly endless series of enhancements and tinkering, which isn’t practical functionally or financially either.


Even an ugly baby is still ours, and we love it and nurture it, and even help it change for the better–that’s part of our responsibility. 


Whether we parented a real baby or an IT system, we have pride of ownership and a sense of accountability to the person, system, and future. 


My father always taught me never to throw out dirty water until you have clean water. 


Similarly, we shouldn’t throw out the (ugly) baby with the bathwater. 


We need to work together–technologists and system users–to make truly functional systems and a user experience more like gaming where the players are so happy, attached (and even addicted) to it that they sometimes don’t even get up to eat or go to the bathroom. 


We should love what we have and use, and we should, therefore, work hard to make these things great.


And an ugly baby can be made gorgeous again. 😉


(Source Photo: Andy Blumenthal)

Requirements Management 101

Requirements Management.jpeg.JPG

This was a funny Dilbert on Requirements Management. 


In IT, we all know that getting requirements can be like pulling teeth. 


No one either has time or desire to provide them or perhaps they simply don’t know what they’re really after.


Knowing what you want is a lot harder than just telling someone to automate what I got because it isn’t working for me anymore!


In the comic, Dilbert shows the frustration and tension between technology providers and customers in trying to figure out what the new software should do. 


Technology Person: “Tell me what you want to accomplish.”


Business Customer: “Tell me what the software can do.”


In the end, the customer in exasperation just asks the IT person “Can you design [the software] to tell you my requirements?”


And hence, the age old dilemma of the chicken and egg–which came first with technology, the requirements or the capability–and can’t you just provide it!


(Source Comic: Dilbert By Scott Adams)