Develpreneur: Become a Better Developer and Entrepreneur

Software development works best when everyone is on the same team.  We need to pull together to be most effective.  However, the sub-groups and members of a team have differing goals.  That is why we have things like contracts.  We sometimes have to put down our plans and goals in writing.  Negotiating these things can be tedious and even can cause some negative feelings.  Therefore, we value customer collaboration over contracts. ...Through this work we have come to value:... Customer collaboration over contract negotiation Differing Values and Concerns We can all agree that some people lack honor.  Some people and organizations are a step above thieves.  I find those to be uncommon and an issue not worth worrying about for this discussion.  Nevertheless, we will run into situations where there are conflicting goals for the different groups that make up a team. These differences may be noticeable, like a vendor wanting a reasonable rate vs. a customer that prefers a discount.  On the other hand, there may be less apparent differences, such as a group that values quality over timeliness.  That give-and-take is not a detriment. Contract Negotiation The concept of contract negotiation pushes us towards the customer-vendor relationship.  One wants the most work done for their money, and the other desires the most compensation for their work.  I realize this is an over-simplification.  However, it sets the stage for negotiating multiple items within a project.  These extremes are not realistic, and that allows us to negotiate agreements that can be considered a "win-win."  This principle points to a more considerable value.  We can collaborate and build up goodwill that allows us to coast over those points of contention. Communication and Expectations Once again, we find ourselves discussing clear communication and setting expectations.  These are proactive steps that have more value than reactive contract negotiation.  Thus, customer collaboration allows us to address challenges and differing goals before they fester and become major issues.  We also can make adjustments earlier in a project when they are less costly.  Of course, all of this does not even begin to count the time spent in negotiations that can be better spent elsewhere. The Twelve Principles and Overall Manifesto Challenge of The Week: When did you last have to negotiate a contract?  Do you work towards win-win?

We started this season with a focus on satisfying the customer.  Since then, we have built a case for working software being the best way to achieve satisfaction.  Thus, comprehensive documentation is valuable.  However, not as useful to our primary goal.  Agile is often painted as anti-documentation so let's dig deeper into this comment that could be used as evidence. ...Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation We Value X Over Y The opening section of this summary says we value all of the listed items.  Rating one over the other does not mean the lesser has no value.  For example, you prefer breathing over food.  Would you argue that food is not essential?  We can take that example further.  You value air over fine cuisine.  Does that mean you do not appreciate food? It is essential to look at the eight items listed here as critical pieces of a software project.  They are all necessary.  Therefore, we cannot ignore one of them without putting the project in peril.  I feel a need to be clear on this point before moving deeper. Comprehensive Documentation Another critical point of this comparison is the idea of comprehensive documentation.  That is a point on which I think we can all agree.  Documentation (of some sort) is required with any software project.  Few would argue against that.  However, "comprehensive documentation" is another level and can be seen as a nice-to-have.  Furthermore, this is a gray area where we could argue what comprehensive documentation contains or encompasses. Working Software If "satisfy the customer" is our "why" for a project, then working software is the "how" or the "what."  We are building an application for our customers.  Falling short of that is the equivalent of "smoke and mirrors."  Even worse, it could be referred to as vaporware or even a bait-and-switch.  In any case, a customer will not be satisfied until they are at least provided with a product they can use. We need to tell them how to use it (through documentation), but more value exists in working software.  Even with Agile, we need to keep our focus on the primary goal. The Twelve Principles and Overall Manifesto Challenge of The Week: When did you last create comprehensive documentation?

We shift slightly in our tour of the Agile Manifesto to focus on the opening statements.  In this episode, we dig into the value of individuals and interactions while acknowledging processes and tools.  The essential point in these opening statements is that all of these are valuable.  However, we find some to have more value than others.  This valuation should help us decide on how to make decisions and move forward with a project. We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools A Slave To Your Tools There is a well-known bit of wisdom that says when you only have a hammer; everything is a nail.  This intellectual nugget stumbles upon how we can become a slave to our tools.  When you look at the modern IT world, this has become pervasive.  Many job positions include a long list of tools that are required or preferred.  Think about that.  We have decided that it is often more important to follow a process than solve a problem.  That is why this point is made.  We need tools and techniques.  However, we can be weakened by focusing on them too much.  A better approach is to emphasize individuals and interactions.  In other words, a similar experience over a specific tool or environment. An Army of One Many years ago, there was a marketing campaign for the U.S. Army.  The tagline was "an army of one."  There are many ways you could interpret this phrase.  However, it does highlight the individual in a team.  Success requires this granular focus.  When we ignore the individuals and attempt to force them into a process, mold, or environment, success is at risk.  We cannot take that approach and still have an environment that draws the best out of each team member. A Framework And Constraints This point does not direct us to let the "inmates run the asylum."  We still need to have a process that the team follows and tools to help get the job done.  Instead of choosing one over the other, we need to find a way to pair these items to get the best out of our team.  Therefore, start with the team and select tools and processes rather than the other way around. The Twelve Principles and Overall Manifesto Challenge of The Week: Are you using your tools or are they using you?

We take a look at overall ideas from the twelve principles of the Agile Manifesto before moving on.  There are some challenging concepts mixed in among recommendations that are very common.  All of these can be applied in areas other than software development. Likewise, their efficacy is seen there as well. We follow these principles: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. The Twelve Principles When we look at these observations and recommendations, there are themes that appear.  We also can see how software projects relate to projects in other areas or lines of business.  There are foundational concepts of a good team, working together, buy-in, and communication.  Some of the concerns addressed are rarely encountered.  However, many of the challenges to overcome still exist in many teams today. Row In The Same Direction Rowing a boat and tug-of-war are often used as allegories for teamwork.  While I would prefer to avoid them, they are just too easy to understand.  That being said, most of the twelve principles address the idea of everyone rowing in the same direction.  We want a team that is cohesive, communicates and is driven.  Motivation or a good work ethic is essential in the success of a project.  Therefore, a group of motivated individuals is more likely to succeed. Define The Team There are times that an "us vs. them" attitude can arise in a project.  This attitude is not helpful.  It will often be a drag on a project and may doom the whole thing to fail.  That is why these twelve principles return several times to defining the team and helping it work better together.  Communication is a concept we often see in project success.  Thus, the Agile Manifesto does not ignore it.  Instead of eschewing documentation, this approach embraces the most effective methods of communication. The Twelve Principles and Overall Manifesto

The final principle of the Agile Manifesto directs us to reflect on a project.  We follow those eleven principles and then evaluate how we did so we can become more effective.  This recommendation should not be a surprise.  We can only improve when we examine how we did on a task.  However, this principle points to the entire team taking that step. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. The Agile Goal is to Become More Effective We started the twelve principles with a focus on satisfying the customer.  This focus is our "why" for building software.  This final principle presents us with a "why" for using the Agile approach.  We accept that we are not perfect.  Improvement is always possible and should be pursued.  Therefore, we should have regular intervals of reflection to build our list of adjustments. Regular, Not Random When we schedule a review and a time frame to create some change, we create accountability.  It is easy to pass on work needed when there is no deadline or at least not one defined.  An irregular approach to reviews makes it hard to create habits or build momentum.  The pauses to review end up feeling like more of a distraction than productive investment.  Thus, we need to integrate these reviews into our plans and schedules.  When we do, expectations are set and then quickly graded as to whether they are met or not. Get Better In Achievable Steps The first time we do anything, we often make mistakes.  That is human nature.  We start with an idea of how to be productive.  However, there are always ways to do better the next time around.  This idea is the foundation of our "building better developers" focus.  We have a long journey of improvement ahead of us, and it is best to take it a step at a time.  The review of a project is similar.  We often will find a long list of improvements to make.  There is nothing wrong with that.  On the other hand, that list can be overwhelming.  Thus, we make adjustments and tune our process a bit at a time to keep our scope reasonable. The Twelve Principles and Overall Manifesto

We near the end of the focus on the agile principles with a bold statement.  The idea of self-organizing teams producing the best results is a strong position.  They are not merely better; they make the best products.  I tend to agree with this statement.  However, it is worth defending as it is not apparent. The best architectures, requirements, and designs emerge from self-organizing teams. The Value of Buy-In First and foremost, self-organizing teams impart to each member a level of ownership.  They are given the freedom and responsibility to "get the job done."  This structure implies that the members are trusted to find the best way to solve a problem and provide their input.  It is not different from the "employee empowerment" idea used in other areas of business.  Software is like anything else we build.  The people that feel they have been instrumental in the plan will feel a sense of ownership of the solution.  Therefore, they have a sense of investment and a natural desire for it to succeed. Self-Organizing Team Create A Best Fit Every member of a team has a unique mix of skills and experience.  This rule applies to any team and any environment.  Thus, traditional roles and labels are somewhat limiting.  The idea of being a "programmer," for example, may fail to utilize a member's testing skills or design experience.  When you drop the labels and roles form a team, they are allowed to apply skills where they are needed.  This approach opens the team up to the most efficient way to combine in solving a problem.  That path is where we find the best results. An Underestimation Problem One can look at a broad range of areas where a leader drives the team to conform to a system or plan.  This approach fits the team into the system rather than the system to the team.  When you step back and think about that dynamic, it is logical to have the team define the solution.  Any other approach essentially tells the team they do not know how to best use their skills.  This method can be demoralizing and reduce the sense of ownership.  In the sports world, the results of this method can be seen when a coach is fired, and a team "suddenly" performs much better. The Twelve Principles and Overall Manifesto

Simplicity is an integral part of satisfying the customer.  Ideally, we would provide them a button to click that does everything they want.  However, that is rarely possible.  We build complex systems that require users to select how they want to proceed.  Likewise, we include or exclude features and functions as part of meeting the requirements. Simplicity--the art of maximizing the amount of work not done--is essential. Work Not Done When we think of simplicity, the focus is often on how little we have.  This principle points to what is not included in a straightforward approach.  More importantly, this principle focuses on work not done.  When you think about it that way, simplicity is an essential piece of getting things done.  We ignore the work that is not needed.  By default, that leaves us with the shortest path from here to there. This concept can be seen in auto racing.  Every so often, a race car must make a pit stop.  During that time, there is work done to fill the vehicle and replace the tires.  A pit stop that is skipped is work not done.  The more a racer can reduce those stops, the better their time will be.  We can apply that concept to any project.  Therefore, the more work we avoid, the shorter the path to our goal. Give And Take Work less can be an easy concept to grasp.  However, it is not that simple (no pun intended).  Simplicity does not imply lower quality.  There is work that must be done.  The race driver, in our example, still needs to drive every lap.  If they run out of gas, they will fail.  Thus, some pit stops are required.  Likewise, there is work needed for any project.  This principle applies to every step from design through testing and deployment.  Our goal is not to remove tasks.  It is to remove the work we do not need to do.  Some work is good; other efforts are busywork.  That is where our objective lies. Busy Or Productive There are many ways to assess whether work is required or not.  In general, I find there is one rule we can point to for accomplishing this.  For any task, is it productive or keeping someone busy?  Does that task move forward progress towards a requirement in some way?  If it does not, then we likely have some work that does not need to be done.  Therefore, we can remove it and get closer to simplicity. The Twelve Principles and Overall Manifesto

We have mentioned time and again that the goal of agile is satisfying the customer.  However, each principle we explore provides ways to accomplish that goal.  The principle we focus on in this episode reminds us that we are still building software.  There are certain traits any good team or system will have.  Good design and technical excellence are tools for building the best solution. Continuous attention to technical excellence and good design enhances agility. Good Design, Not Good Documentation Some people say that Agile is an approach that avoids documentation and limits design.  Likewise, detractors accuse it of jumping too quickly into implementation.  This principle puts the lie to those accusations.  We can do all manner of good things but still need to pay attention to the details and plan our approach.  Therefore, good design is an essential step in any agile approach. Technical Excellence The idea of technical excellence is not some lofty goal.  It is a practical objective that leads to better software.  You can think of examples of shoddy (not excellent) work in buildings.  One that is the height of excellence will look good, withstand the elements, and generally be a better product.  Software is no different.  Our goals of sustainable, scalable, scalable, and others all hinge on how well we incorporate technical excellence.  It is not hard to find examples of lesser solutions that crash often, are slow to respond, or are impossible to extend. Needed Processes In short, this principle points out to us the critical things we need to do as part of satisfying the customer.  The Agile process is not a complete replacement for what has been done in the past.  Instead, it is a refinement of the valuable things where the less valuable ones are removed.  That may sound familiar as it is laid out in the summary.  If you remember, they pointed to some tasks as having more value than others so we will aim to do better with those greater valued tasks. The Twelve Principles and Overall Manifesto

Software development has high and low points.  Likewise, there are hectic and "slow" times that we live with as part of our work-life.  When you think of software development as a marathon, a constant pace is a goal.  You want to be able to set a pace for the team that they can run at forever.  That allows for critical success factors like embracing change and adjusting to changing requirements. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Sustainable Development Burnout and similar situations are highly detrimental to a plan.  The loss of a resource or team in such an unexpected way causes slippage or maybe even failure.  There is nothing more difficult to manage around as a critical resource that is suffering burnout.  The recovery period is seldom something that can be estimated, and you effectively have "dead weight" on the team until they do recover. A Constant Pace For Everyone It is easy for us to focus on our experiences when we evaluate processes and events.  That can lead to the "grass being greener" when we consider others.  Thus, in software development, we tend to focus on our part of the team as having a tough road ahead.  However, everyone involved in the project will have a similar experience.  It is easy to gloss over the toll a project takes on the project managers, customers, sponsors, users, and everyone else.  This process is not a marathon run only by the implementors.  It is important to note that the agile approach acknowledges the challenges for everyone and tries to alleviate them.  We are not solving issues for the implementation team alone.  These principles help lift everyone. Finding Balance Running a marathon often includes hills, weather, and other conditions that help or hinder our progress.  These are important to acknowledge.  I think we can all agree that it is easiest to run a marathon in a controlled climate and a level and smooth surface.  This principle takes that concept and applies it to software development.  While we all know there will be challenges, we can still find a steady pace that we can maintain.  A little extra effort here and backing off there will provide us with a steady pace to take us across the finish line.  We can even have that final burst to finish strong. The Twelve Principles and Overall Manifesto

There are times where it helps to state the obvious.  The most glaring truths can be lost in the details when we forget to focus or reset.  Working software as our goal is one of those truths that we need to remember.  There is so much that goes into creating a solution that can distract us from this primary goal.  However, keeping this in mind can help us sift through what is productive and what is busywork. Working software is the primary measure of progress. Keep The End in Mind First and foremost, we still want to satisfy the customer.  That is the "why" of any project.  It is our measure of success for the solution.  Likewise, working software is our "how" of the project.  A perfectly designed solution has almost no value until it is implemented.  Our final deliverable is software plus items that help satisfy the customer.  Thus, we know the software is the key deliverable.  Everything else is useful or a nice-to-have. Working Software In Steps You may know someone who never completes a task.  They can be frustrating to deal with and often are not considered successful.  Follow through, and completion are critical measures for any action or responsibility.  It is like running a race.  Nothing matters if you cannot cross the finish line.  Software is the same in that respect.  We have to deliver working software for a customer to begin assessing it.  Therefore, we cannot measure customer satisfaction until we have provided a functioning product. The Cost Of Deployments I have heard it argued that the steps required to deliver working software could be "too costly."  While there are often costs associated with providing access to working software, those are worthwhile investments.  We need to only turn back to our primary consideration.  How do you measure customer satisfaction of a product that does not function?  Smoke and mirrors can be used to build a prototype for initial feedback.  However, an accurate measure is not available until we have a functioning product. The Twelve Principles and Overall Manifesto