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)

Advertisements

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)

Robots, They Are Coming

Robot.jpeg

I was so excited by this photo in the Wall Street Journal today.


YuMi, an industrial robot by ABB, is adroitly writing Chinese calligraphy. 


If you look at the photo and think for a moment, the notion of the robot doing and the person watching is truly prophetic of how we are evolving technologically and as a species. 


Yumi is made by ABB, a leading robotics company headquartered in Switzerland, that on one hand has over 300,000 robots installed worldwide, but on the other hand needs only 4,600 employees in 53 countries to produce all these fantastic and productive droids.  

This robot is a work of not just incredible science and engineering, but of art and beauty. 


It’s sleek black and white build with two incredibly agile arms and hands plus a viewing camera, enables it to do small parts assembly or even fine calligraphic work. 


YuMi stands for “You and Me” working together, collaboratively. 


While we surely will work together, the flip side is that with robotics, some people (who don’t make the transition to STEM) may not be working much at all. 


But of course, the positive side is that we are looking at an incredible capacity to do more and better with less! 


Leaving the innovation to humans, and the assembly and service to the bots, the bar will be raised on everything–both good and bad.


We will build greater things, travel and explore further, and discover ever new depths of understanding and opportunities to exploit.


But we will also edge people out of work and comfort zones, and be able to engage in new forms of conflict and war that only the power and skill of (semi-) autonomous machines could inflict. 


The robots are here, however, they are coming in much greater numbers, capabilities, and impact then we can currently fully comprehend. 😉


(Source Photo: Andy Blumenthal via WSJ)

Agile Processes As An Enabler

Bridge Up

So something that I’ve learned is that processes can be an enabler or a hinderance to progress depending on how it’s used.


On one hand, without a standardized and clear process where people know what they are supposed to do and when, we are likely to end up with a lot of chaos and not much getting done for the customer or organization.  


This is especially the case where tasks are complex and numerous people are involved requiring there to be solid coordination of team members, sync of activities, and clear communications.  


On the other hand, rigid processes that are so prescriptive that no one will get out of step for any rhyme or reason can be counter-productive, since this can hinder productivity, time to resolution, and customer service. 


For example, we all understand the importance of a help desk ticketing system in IT to document issues and deploy resources for resolution and measure performance. However, when customers, especially VIPs are in a bind and need help ASAP, it may not make sense to tell them to go open up a ticket first and foremost, instead of helping them to quickly get back online, and even opening the ticket for them and in parallel or as we get to it afterwards. 


Process should be an enabler and not obstacle to progress. Process should be followed under normal circumstances, but rigidly adhering to processes without adapting to conditions on the ground risks being out of step with the needs of the organization and a customer service model. 


(Source Photo: Andy Blumenthal)