Category: Project Management


Software is Emergent 3 Part Introduction to Scrum

Filed under: Project Management — Leave a comment
August 10, 2009

Introduction to Agile / Scrum Development By Rob Dempsey.

Part 1

Your organization must change in order to gain the full effect of Agile.   If your organization will not change, you will not improve, and Agile is not for you.

In a nutshell here is the Scrum process.

Product Back Log -> Release Planning -> Sprint Cycle -> Increment -> Sprint Review -> Sprint Retrospective

Part 2

Each day you have a stand up meeting where you answer these questions.

What did you do since yesterday?  What do you plan on doing today? Is there anything getting in your way?

At the end of the cycle you review it, and discuss how you can improve the last sprint.

Part 3

Agile survey outcome says..

82% increased productivity

77% increased in quality

78% increased in stakeholder Satisfaction.

Tags:
Comment

Emotional Intelligence in Software Development

Filed under: Emotional Intelligence, Project Management — 5 Comments
August 4, 2009

In software development today, the folks developing most software programs are not the same people interacting with the users of the end product.   This often times leads to software that misses the mark when it comes to expected functionality or application flow, because it is hard to understand what someone wants when you don’t know them.

With most Software firms, as software ages, requests come in from customers either through support channels or through sales and marketing.    These requests are logged against a companies bug and feature database and are later accessed by the development teams.  A typical developer logs into either an issues database, or a feature request list, selects the feature or the bug to work on, assigns himself or herself to the problem, then proceeds to work on the problem.    If there is a question about the bug or feature, the developer will contact someone in support/marketing/sales/consulting for an explanation.    Those they contact  will give their interpretation of the feature and the developer will code to that explanation.

Today in essence customer facing people in sales, marketing, and support drive functionality within the products.    This makes sense in today’s world as these are the people closest to the customer.  They have the most experience listening to customer concerns, business scenarios, and hurdles to make the given business a success.  In IT departments in most large corporations these are the Project Managers, and Business Analysts.  However what if there was a better way?   What if we freed our development teams to just find out for themselves what is the requested feature or bug?  What if we allowed them to call the customers directly and ask them what was meant by their request?  What if we allowed them to run screen shots, and demo’s through the customer in question.  Then what?  I believe you will have two outcomes.

  • You will improve the emotional intelligence of your development teams.
  • Your software will be a lot closer to meeting the needs of the market.

First of all what is emotional intelligence?  Wikipedia tells us this;

Emotional Intelligence (EI) describes the ability, capacity, skill or, in the case of the trait EI model, a self-perceived ability, to identify, assess, and manage the emotions of one’s self, of others, and of groups[1].

What abilities does someone with emotional intelligence poses?

  1. Perceiving emotions — the ability to detect and decipher emotions in faces, pictures, voices, and cultural artifacts- including the ability to identify one’s own emotions. Perceiving emotions represents a basic aspect of emotional intelligence, as it makes all other processing of emotional information possible.
  2. Using emotions — the ability to harness emotions to facilitate various cognitive activities, such as thinking and problem solving. The emotionally intelligent person can capitalize fully upon his or her changing moods in order to best fit the task at hand.
  3. Understanding emotions — the ability to comprehend emotion language and to appreciate complicated relationships among emotions. For example, understanding emotions encompasses the ability to be sensitive to slight variations between emotions, and the ability to recognize and describe how emotions evolve over time.
  4. Managing emotions — the ability to regulate emotions in both ourselves and in others. Therefore, the emotionally intelligent person can harness emotions, even negative ones, and manage them to achieve intended goals.

In other words, someone with emotional intelligence has the able to fully understand the person or persons they are talking to.  They know the right questions to ask, and how to ask them, in order to get more information out of the people in question.  They also know how to gain the trust of others so to make those they are interacting with more comfortable, and willing to share.  These abilities are not something we are born with.  It takes time, energy, and a willingness to learn and interact with people, in order to learn them.  Most of all, a persons EQ can develop over time from simply interacting with other people.

However in today’s development shops developers spend most of their time interacting with software, and are completely detached from the world at large.    Because of this, they rarely get the opportunity to interact with customers.   Management mandates that customers – and sometimes consultants – don’t contact developers directly and that developers don’t contact the customers.

The most important aspect of software development is not which technology you choose, or the amount of lines of code you write, but whether the customer is going to be happy with what you produce.    How close you get to their vision and goal sets should be the ultimate goal of any software development project.

But by limiting the interaction our developers have with customers we limit their ability to know what the customer really wants.  For every layer of interpretive explanation, marketing->sales->product manager->project manager->developer you add risk to the process of getting the initial requirement correct.   For example; ever play that game where 20 people sit around a camp fire, and tell stories around the circle?  The first person tells a story to the second person, the second to the third, and so on.  By the time that story gets around to the 20th person it’s completely different than it was at the begging.   Well this game illustrates how people work.   Every experience consisting of sound, audio, or touch invokes different emotions and thoughts within each person, because  we all have our own vocabularies and experiences to draw from.  These thoughts and emotions are then communicated differently to the next person.

Well if we deny our developers the ability to interact with the source, how can we ever expect them to fully understand the requirements or gain Emotional Intelligence?   We can’t, which I think is how companies die, as their software gets further and further away from the actual business need.

The closer your development teams are to the actual need, the closer the developed product will be to the customers needs.  This doesn’t mean that there is no need for marketing, sales, and support, and  yes you will still have to manage time, scope, and development cycles, be they agile scrum based sprints or waterfall type methods.   However the more connected your development teams are to the needs of the customers, the more they will be able to interpret the requests, and anticipate future needs as they develop because they will understand the requests better.

Ultimately your products will be better, your development teams EQ’s will be higher, your design sessions will be better because everyone has the right information, and your customers will come back to you for more.

Tags:
Comment

Working Smarter, Videos on Agile

Filed under: Project Management — Leave a comment
July 28, 2009

I recently was perusing YouTube and found a bunch of really good videos on the Agile development process… here are some of the better highlights

This is a bit over the top, but it does show some very important aspects of the Agile method.

Agile fights against depreciation of software.

Learn about one of the most important Aspect of Agile Development – Modeling

Scope and Scale of an Agile Project

Tags:
Comment

More On Agile – The Car Again?

Filed under: Consulting, Project Management — Leave a comment
July 18, 2009

The analogy I tried hard to make in my last few posts was to dispel the notion that software development is NOT like building a Car, or a bridge, or even a home. So let us as engineers and developers, move beyond that concept and begin to think of our discipline as more fluid.  I know many in my field will not like this, especially on the east coast, but my ultimate goal is to think of us more as a combination of surfers, artists, psychologists, architects, and construction workers more so than engineers.

To summarize the problems we face with the current methods in the world of software development;

  • Businesses Change – Let’s face it, we have all come to the conclusion in the last year or so that markets don’t always go up.  They fluctuate and sometimes unfortunately they crash.   Likewise Businesses are not always successful and if they are too inflexible to the market they will fail.   To counteract this a good business is agile enough to handle the changing market conditions.   With change, comes different sets of requirements, which current development methods do not handle well.
  • Communication Is Vital – In today’s world as illustrated, though with a bit of humor, in the British Comedy “IT Crowd” software development teams, and IT persons, are often very far removed from the business.   This makes it very difficult to communicate to those developing the software what the requirements are, as well as help those in the business understand some of the hurdles in delivering a particular requirement.
  • Motivation – This is a tricky one.  But let’s be honest with ourselves for a moment.   Many people in general work better and are more focused with deadlines.  Some people don’t always need a deadline, but it is safe to say a majority of people do.
  • Inability to measure progress – In today’s world progress is measured by something called a project plan.   A project plan is a nice little graph with tasks, and bars that show percent complete.   The percent complete is usually just an estimate given to the project manager from the developer.  In most situations, the Project Manager doesn’t have any idea what criteria the developer is using for the estimate given, but simply accepts what he or she is told.

Take a look at the Principles behind the Agile Manifesto and you can see how this method for software development addresses these problems directly.

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

Business people and developers must work
together daily throughout the project.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

Continuous attention to technical excellence
and good design enhances agility.

Simplicity–the art of maximizing the amount
of work not done–is essential.

The best architectures, requirements, and designs
emerge from self-organizing teams.

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

Directly each one of these statements of commitment deals with the problems in the current process, with the ultimate goal of a happier more satisfied user base.   With all of that said however, I will admit that while this methodology has a lot of appeal to the software development community when discussing this with the money people there is some difficulty.

Mostly because the Agile method never portends to cut the development cost.   By letting the scope of the project change over time, costs of development “might” in fact go up.  I say “might” because there has been many projects that I have seen that are amazingly under estimated who end up having major overruns, and high costs of completion.

So one must weigh the cost of getting something “done” versus getting something “right” in making the ultimate choice.

It is my feeling, and the view of the Agile camp that this choice is obvious.

Tags:
Comment

Software Development Is Not Like Building a Car – Part III

Filed under: Emotional Intelligence, Project Management — Leave a comment
July 16, 2009

When implementing a project whose team is made up of customer employees, and vendor consultants, there are to be honest many competing agendas in forming that team.  The customer wishes to keep costs down, and utilize the consultants for as few hours as possible and still get the job done.   The Vendor wants their consultants to be vital to the success of the project and to be key players, thus causing the customer to rely on the consultants for a longer period of time.

It’s all money driven from a management perspective.  However despite all that, often times the team members could care less.  Their goal set is always different than those worrying about contracts and costs.   The successful implementation of the project is what is the most important to both consultants and customer employees.   So no matter what the overriding agenda is from management, typical team dynamics are always the same as if everyone worked for the same company.

So given this, why aren’t more mixed implementation teams using Agile development rather than the Waterfall method?

From my experience, teams aren’t using Agile for a few key reasons.

  • Change – Customers and Vendors do not want to change how they have been structuring contracts for years, which they view as a tried and true method.
  • Having two deliverables; Requirement Study, and Finished Product, is much easier to manage than having many deliverables. (Sprints)
  • A perception by the customer that using the Agile methodology will result in longer project times, and therefore higher costs paid to the vendor.
  • Worry by many that the overall goal set of the project is not understood with the Agile methodology so you can’t properly estimate the overall cost of the project.
  • Trust – Most managers do not trust vendor provided consultants.
These are all valid concerns, so how do we in the software industry alleviate them?

I think it is going to take a little more than just getting a few more evangelists into our industry.    Most of the above points deals with fear and trust.  Fear that something might not work is most often times more important than the know ledge that something won’t exactly work well.   So how do we as developers, implementation experts, project managers, and sales people convince the customer and our own vendors to accept this new way of doing it?    First and foremost I believe it’s up to the project teams to prove to management and sales that this  leads to happier customers.   Happier customers tend to purchase more products, and likely will invest in more services as well.   Secondly, we have to begin to think differently.  It is so easy to fall back on the old “document what your going to do, then go do it philosophy” that thinking in the Agile mode becomes an after thought.

So how to we as project teams begin to think differently?

I think it’s important that we all come to some consensus that software development and architecture design is not a process that has been perfected over thousands of years.   It’s a relatively infantile field in regards to physical construction disciplines in that one can say it’s only been around for 60 some years, and that improvement is possible.

If we all agree to this philosophy, then maybe we can begin to feel as if improvement can be made, through a new more flexible methodology.

Also I think it’s important to fully grasp the concept of what Agile is and how it improves team work, and better more directed delivery of solutions.

I would also recommend reading anything by Scott W. Ambler of IBM.  The guy is a very good speaker and accomplished writer.

see, you don’t get any of my responses from yahoo pidgin

Tags: , ,
Comment

Software Development Is Not Like Building a Car – Part II

Filed under: Emotional Intelligence, Project Management — Leave a comment
July 11, 2009

The most common questions asked by my peers and managers regarding Agile software development is this.  What is it, how can it benefit me, and how can it cut my costs down?

So what is Agile Software Development?

Agile software development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. The term was coined in the year 2001 when the Agile Manifesto was formulated.  – Wikipedia on Agile Software Development

What this means is this.  The Agile methodology allows for the design and construction of software to be more nimble and accepting of change.   As requirements change, people change, or business needs change over time, the team can refocus it’s effort on a new goal, more aligned with the strategic plan of the organization.   Like a military unit in war, when the general says march to point A initially, but then when you’re half way there, says march to point C instead, this methodology allows for development teams to have the flexibility to operate in the world in which businesses operate today.  It’s hard to plan 12, 24 or even 36 months out, because in most instances knowledge of what business environmental factors will be in place that far out is so unknown.

There are many specific agile development methods.  Most promote development iterations, teamwork, collaboration, and process adaptability throughout the life-cycle of the project. – Wikipedia on Agile Software Development

When we describe teamwork during an Agile methodology construction, we do not just mean the teams of developers and their project managers.   We also mean the stakeholders, and the end users as well.   Constant feedback, and involvement from these people, the key consumers of the end product, will help the development team drift closer to a successful, useful, and better aligned system.

What about costs?

Costs are a little different for the Agile methodology.  One must not think in terms of long term project costs, though this is somewhat  important, but the cost it takes to build each component, and if it is better to spend money one step at a time, with concrete results or simply write one big check and wait.   The difference between Agile and Waterfall regarding costs, have to do with what needs to be asked for up front.   The typical Waterfall project will go through these steps;   obtain a general idea of how long the project will take, and projection of costs.  Go ask for funding.   Start the project by doing a requirements gathering.  If this changes the length of the project go ask for more money.  If money is granted, then the teams begin the process of design, implementation, verification, and maintenance.    At any point in time, if the team runs out of funding, they will go with hat in hand and ask for more funding.  Each time funding is requested, the requester has nothing to show for the other monies that have been spent, except to say we are making progress.  Often times  a project plan will be used to illustrate progress, which will represent a virtual set of goals, with graphs showing estimated tasks, and percentage completion   This is a lot different than building a house or a car or a bridge.   A consumer of these products can see and touch them so even without being an engineer of any kind, they can make a judgment about progress.  If a bridge is half done, the consumer knows it’s not yet safe to use, but it looks like it’s half done.  If a car doesn’t have it’s engine yet, but it has a body, and 4 wheels and a steering wheel, consumers know this car can’t run but the construction teams are making progress.

In software development a stake holder needs to see screen, flow of data, or movement of parts to feel as if progress is being made.    Agile unlike Waterfall lends itself to this, by breaking the project down into iterations, which involve creating a concrete benchmark that will be achieved within the given time line, then acting upon that.   At the end of each iteration the stakeholders and end users can be shown real progress.    If the end result does not meet the new business reality, because the iterations tend to be short lived time frames and tackle small chunks of the overall system, it’s very easy to adjust the iteration’s work product.

The Agile methodology allows for project finalization to occur at the end of any iteration.  But unlike the  Waterfall method, at the end of each iteration you typically have a working product.   It might not be what was originally envisioned, but it is never the less a working system.   This allows the stakeholders to choose between funding additional work or going live with the product as it stands at the end of the iteration.   That flexibility is key to controlling costs with Agile.   I believe it’s better to allow your customer (and stakeholders are our most important customer) to be free to make that choice.

So if you’re a consulting organization, how can this work?

To be continued….

Tags: , ,
Comment

Software Development Is Not Like Building A Car – Part I

Filed under: Emotional Intelligence, Project Management — 3 Comments
July 10, 2009

I was at a meeting Wednesday with a bunch of really bright software architects discussing the concept of what engineering discipline most resembles software development.   We used home building as our most common point of discussion, and the debate got pretty heated.   The speaker – Jesse Tilly – was trying to convey to us that software unlike physical construction, takes place in a virtual world.  With abstract concepts, systems modeling, and eventual system construction the developer will develop an entire working system that the end user will never be able to touch or feel.   Systems are often responsible for moving, or manipulating data, making calls to other abstract systems in which some form of business logic is applied, or are responsible for controlling a physical component.    In most cases this is just a matter of transferring or manipulating 1′s and 0′s, and because of this and a “development environment” the software developer can often take many chances during the construction of a system that the physical engineer cannot.   Jesse at one point used the phrase, “how many times have you tried something to see if it worked.”   The answer of course is often, because when I or any other developer tries something to see it’s merit or validity, money isn’t wasted – unless tried in production – which is often avoided.

With good version control, it’s trivial to roll back to before something was tried.   To contrast this with a physical engineer; If Aerospace engineers decided to simply try something on a test flight, the pilot might end up meeting his maker sooner rather than later.

Well this did not sit well with a few of my fellow architects.   Mostly those that view what they do as a bit more like physical engineering than it really is.  I love software design a great deal so don’t get me wrong there.  Our systems are vital in our society, as they control everything from an MRI machines and Titan Rockets to your Microwave.   But with that said, with a few exceptions our discipline typically does not deal with the physical world.

Our most pressing issue is money.   How much is this going to cost?  How can I do it cheaper?   What’s the shortest and quickest way to get to point B?   This driving force of software development, I think was the point most missed in our meeting Wednesday.   In software development today, 90% of the time it is run by business decisions and not engineering principals.  So often times the cost benefit analysis overrides peer reviews, and proper techniques.

I think the largest reason for this, is because of the inflexibility of our current most widely used software construction methods.   The stakeholder would fund the project, higher the participants, be involved in the initial requirements studies, then go away for months and sometimes years waiting for the final delivery.   Often times during that project time line, the requirements would change, people would move off the project, and the initial understanding of requirements would be lost anyway.   The most common method still in use today is the waterfall method.  This method is one software engineers have borrowed from the physical engineering trade; think blue prints, plans, concrete, steel, wood, etc.   In the physical world, teams of engineers or architects, get together, design what it is they are going to build, plan out the steps to build it, then allow the construction teams to go to work.

Why does this work in the physical world?  This works because those involved are dealing with concrete ideas, and scientific laws and theories.  The requirements for a car are straight forward.  Does it run?  Does it carry passengers.   What about an airplane?  Does it fly?  Does it carry luggage?     Not to minimize the design and creation of these two products but in both instances even though people are the final consumer of these items, most of the time their input is the least important.   Take a car for example, the job of the driver is to turn left and right, to break, to accelerate and decelerate, and to control the radio.   While that is going on, thousands of parts are involved in making that car go where the driver wants it to go, by compensating or dealing with the laws of physics.

However in software design it’s all about people.  Now I realize I said earlier that a person cannot physically touch the end product of software design.   While this is a true fact, software does interact with people on a different level.  It’s all about guessing how a user will think and anticipate how they will most likely interact with the final product.    This is a lot harder, than any physical construction portends to be, and is an ongoing process. How do you as a software designer, or programmer anticipate how someone will think.   If your user base is more than 1 user, you opinion base grows.   You could code a screen one way and user A would be extremely happy, but user B would be turned off, and possibly move on to another choice.

This leads us to the questions that Software Development is asking today.   How do we get User A and User B, along with the stakeholder to be more involved in the final product? How do we generate a system that is closer to the requirements at the time of delivery?  How do we continue to encourage the stakeholder to continue funding?

Enter Agile.

To Be Continued…..

Tags: , ,
Comment

Hello World!

Filed under: Consulting, Emotional Intelligence, Enterprise Architecture, Programming, Project Management, Random Work Day Thoughts — 1 Comment
June 16, 2009

Hey everyone, this is my first Blog.  I have been a twitter fanatic for about a year now, and a facebook poster for well 2 years.   This is my first attempt to branch beyond that more personal social interaction and setup something a bit more about my professional life.   While there are many blogs out there, detailing all things Java, J2EE, Oracle and the like, there will be, and I promise this, nothing with the unique humor and outlook that I bring to the  table.

We are all unique right..  well I am a unique Geek.  I don’t really fit into your typical stereotype of your total geek, but yet I don’t fit totally into your image of a business guy either.  I straddle these two areas in my day to day life, and it’s my humor and my outlook that keeps me sane.

So as I increase my readership, I hope to learn from, as well as teach those who feel as if the world is an interesting and fascinating place, and that to operate in both the business and technical circles equally and with success, is an enjoyable experience.

Tags:
Comment
Follow

Get every new post delivered to your Inbox.