Develpreneur: Become a Better Developer and Entrepreneur

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

The season of digging deeper into the Agile Manifesto continues forward to the sixth principle.  Our primary focus is on satisfying the customer.  However, we now shift into how our approach can achieve that goal.  It is time to talk about the value of a face-to-face conversation. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Clear And Effective Communication We have often looked at setting expectations and communication as essential factors in project success.  This principle cuts to the chase concerning this challenge.  I think we all know the primary thrust of this recommendation.  Nevertheless, we quickly get pulled away from the best way to accomplish the objective.  There are many tools and methods for communication.  On the other hand, face-to-face conversation is almost always the best way to do so. Inside and Out Before we dwell too much on the face-to-face conversation portion of the principle, we need to examine the context.  Note that the follow-up is a focus on both internal and external communication.  We once again see where it is assumed that information sharing in a project applies to all members of it.  There is an underlying assumption that customers and the development team will communicate.  When you add in the face-to-face conversation piece, it adds up to those groups talking directly. Body Language and Directing Conversation We have already skipped right over conversation being the most effective way to communicate.  There is no reason to argue against that.  It is not always the case; sometimes, a presentation or report will be better.  However, those cases are rare and specific.  That being said, we need to take advantage of this method of communication. Face-to-face conversation allows body language and similar non-verbal cues to come into play.  This method allows us to dig deeper into responses when we see an answer that is hesitant or seems pained.  We can use the non-verbal cues to find out the real pain points and even opinions about a problem or our solution.  Instead of taking everything at face value, we can create a safe space that draws more profound thoughts and concerns out of the team members.  When we do this, we get the best out of each member. The Twelve Principles and Overall Manifesto

In this episode, we continue our crawl through the fifth principle of the agile manifesto.  Our focus switches from motivated individuals to the environment and the support they need.  Motivation is great.  However, we need to feed that and clear obstacles. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The Required Environment Numerous factors go into a beneficial environment.  These range from personality and emotional impact to the right tool for the job.  History is littered with incredibly skilled teams and groups that failed due to an adverse environment or lack of support.  Therefore, we should consider what makes a productive environment. The simplest way to assess an environment is whether it is conducive to completing the required tasks.  Thus, we return to the primary goal of satisfying the customer.  Implementation is not automatically productive.  We must make sure we are in line with the tasks that will satisfy our customers.  The shortest path to achieving this goal is to remove obstacles that slow or deter the team. Clear And Direct Communication Once again, we find ourselves focusing on teamwork and communication.  The groups and individuals involved in a project need to be "on the same page."  When we properly inform team members, we allow them to work to the best of their ability.  Therefore, the team works as well as it can.  Open the lines of communication for building consensus.  Thus, everyone is comfortable highlighting obstacles.  When this is accomplished, the team will be able to focus on the work required for the project. More Than Removing Documentation Administration and "red tape" can slow down progress in any project.  However, that does not allow us to equate documentation or administration with a lack of productivity.  Planning and stepping back to communicate status or ideas fully can help us plot the best route to completion.  We may also need to invest in future work by taking steps that improve tracking and estimation.  The key to clearing obstacles is first to define the actual barriers.  Thus, there will be some tasks that are needed for overall productivity and progress, even though they do not directly do so.  We want to give the team the support they need.  On the other hand, we need to do so in a way that does not sacrifice long-term benefits for a short-term gain. The Twelve Principles and Overall Manifesto

The fifth principle of the Agile Manifesto is a big one.  It starts with the idea of motivated individuals and progresses to getting the job done.  This statement could be a solid foundation for a management approach and is at the heart of many such strategies.  An introduction like that should have you ready to see where the discussion goes. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. Motivated In Part A motivated team is useful.  However, motivated individuals are essential for success in any project.  They are the lifeblood of the motivated group.  This recommendation may seem to be common sense.  We all know that leaders and cheerleaders are part of a successful team.  Thus, we recognize a need for direction as well as ways to build or improve morale. Attention To Details In my opinion, motivation and attention to detail go hand-in-hand.  For example. one will skip over the details if they are not motivated to get the job done correctly.  Lack of motivation leads to choosing shortcuts and glossing over the details.  We can see this at any point in the SDLC process. It results in missed or incomplete requirements, fragile implementation, or minimal test coverage.  A motivated individual will want the best and follow up on the details at these steps.  These team members are the ones that track down items that would otherwise "fall through the cracks."  Likewise, they push us to complete that problematic "final twenty percent" of a project. A Needed Environment We have mentioned tools and toolsets many times in our focus on becoming a better developer.  This focus applies to nearly every position, role, and career.  The whole purpose of tools is to make us more productive.  It results from reducing the challenges involved in completing a task.  A comfortable work environment provides many benefits to the worker.  These positives amount to greater productivity, higher morale, and improved longevity.  Happy and healthy employees are productive.  Thus, a pleasant environment is an essential first step towards success. The Twelve Principles and Overall Manifesto

The principle we cover in this episode is short but powerful.  It is also one that goes to the heart of defining an Agile team.  We do not focus on the technical staff and developers.  There also needs to be an inclusion of the business people.  Therefore, development in a vacuum is not valid.  Regular communication with the customer or their representatives is essential. Business people and developers must work together daily throughout the project. The Agile Team Software development has progressed to where subject matter experts and business analysts are a typical piece of the puzzle.  That has not always been the case.  Thus, it is worth looking at how defining the team as we do today is beneficial to building a solution. The Agile process often is seen as a technical one.  We started down this path for many years before the business side was pulled into it and educated on how they are needed.  This change has made a positive impact on software success rates.  However, it is hard to quantify the improvement when you have to also factor in the changes to software projects.  Smaller projects have become more prevalent.  Likewise, other Agile principles are being adopted in more projects. A Quick Turn-Around We have already talked about the regular delivery of a working product.  One of the primary reasons for this tactic is to provide a way for the customer to give feedback early and often.  When you include representatives on the team, you reduce this feedback loop even more.  There is an on-going discussion of sorts that is created when you work within a group.  There are challenges, solutions, and items that can be mulled over.  These are easy for team members to discuss and delve into.  On the other hand, those outside the team will need to be "brought up to speed."  You will find that the large number of discussions and decisions needed during a project makes it worthwhile to reduce those ramp-up times. A Different Point Of View One of the reasons projects failed in the past was missed expectations.  Developers would go into a cube for a while and then come out with a product.  This approach left it open for a developer to drift too far away from the "why" of the project.  This concept is not different from builders using a cornerstone or keystone.  When you do not measure against the foundation on a regular basis, it is easy to get off track. The Twelve Principles and Overall Manifesto

The third principle of the Agile Manifesto tells us to deliver working software frequently.  This step is an essential factor in satisfying the customer.  While we want to avoid the "are we there yet?" approach to delivering a solution, incremental is valuable.  When we take this principle to heart, we provide confidence in our progress, along with opportunities for feedback.  Therefore, we need to look at this closer for small and large applications. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Deliver Working Software Frequently These four words are sometimes easier said than done.  The implementation phase is dynamic by definition.  We should be steadily making changes as we march towards completion.  The idea of frequent milestones of working software may seem antithetical to this process.  Likewise, regular deployments can be time-consuming.  That adds time to our schedule.  However, we can plan for this and find ways to make this a worthwhile investment. Checkpoints and Testing When we look only at the cost of deployment, we miss the point.  This principle tackles the problem of communicating with the customer and building their confidence in our solution.  It also forces us to test integrations and processes that can be costly to fix at the end of the implementation period. It is well-documented that bugs cost more the later they are found.  When we include deployments early and often, we are building in some testing and sanity checks.  This deliverable can highlight flaws and bugs that otherwise would be far more expensive to address.  We can even respond to customer requests that might be too costly to handle late in implementation.  There are architecture assumptions that may need to be altered based on the end-user experience.  Early deliverables can bring those to the surface when a change is cheap and easy. The Elusive User Experience UX is a hot topic in software.  Correspondingly, some people are very good at crafting a sublime user experience.  On the other hand, customers can be picky or finicky.  Thus, the best validation of our UX is the stamp of the customer.  The only way to test this out "in the wild" is to provide deliverables the users can work with.  Clicking around and "imagining" how it will work is not the same as concrete functionality.  When we deliver working software frequently, we provide the customer with a practical example to review.  The feedback we get from this is a valuable input for a product that will satisfy those same customers. The Twelve Principles and Overall Manifesto

In this episode, we continue a walk through the twelve principles of the Agile Manifesto.  The second principle focuses on change and how it can be a competitive advantage.  Changing requirements can be a headache and cause slippage.  However, adapting to them can be a game-changer. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Satisfy The Customer I want to start the discussion about changing requirements with a call-back to our first principle.  Our primary focus is on satisfying the customer.  Therefore changing requirements signal a change in what is needed to satisfy them.  We may find these alterations frustrating and might even experience over-runs based on them.  Nevertheless, we must adapt if satisfaction is our priority. The Competitive Advantage The idea of an agile approach being an advantage applies to far beyond software development.  Agile athletes can dodge blows in boxing or tackles in football.  Likewise, they can perform gymnastic feats and score goals.  Similarly, agile organizations can adapt to the market quickly.  Therefore, you often hear about nimble start-ups that "pivot" and grab a market lead.  When agility is so valuable in most environments, it only makes sense for us to give that to our customers.  We adapt to changing requirements to help them be successful.  That goes a long way in providing satisfaction. Even Late In Development I almost chuckle at this line.  Do any of us run into changing requirements in the first half of a project?  Yes, sometimes we do.  However, it seems like late in development is the prime spot for these alterations to occur.  Maybe they are just more noticeable.  They are more costly.  Just as bugs are more expensive to fix, the later they are found, requirements are harder to adapt to later in the process.  This timing is a challenge that provides an opportunity to make a significant impact on satisfaction.  Embrace these obstacles and satisfy your customers. The Twelve Principles and Overall Manifesto