Develpreneur: Become a Better Developer and Entrepreneur

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

We start our focus on the Agile Manifesto with a deep dive into the twelve principles they address.  Thus, we begin at the first principle and will focus on that one in this episode.  This point also gives us a foundation of trying to satisfy the customer. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Satisfy The Customer Anyone that tells you Agile is primarily about anything other than the customer is misinformed.  The first item states that the highest priority is the customer.  Not only that but satisfying them.  Therefore, we are not focused on meeting requirements or even an incredible design.  Customer satisfaction is number one.  Many things go into achieving that.  However, the "why" of any software product is to satisfy the customer.  Keep that in mind as we work through the twelve principles.  Do not worry. We will be reminded of that "why" along the way. Early and Continuous Delivery Modern software development often embraces this pair of suggestions.  We are hard-pressed to open an article on software development that does not mention CI/CD or Dev Ops.  Either everyone is wrong, or this is a recipe for success. It can seem unpleasant to take this approach.  We could liken it to children on a trip asking, "are we there yet?"  However, a clear and continuous conversation about a solution is constructive.  Software is sophisticated, and showing progress can help educate the customer on what is possible and the user experience.  These are essential factors in a solution that satisfies. A Tight Focus Software development is complex.  However, that does not mean the process has to be complicated.  We can simplify things by taking small bites.  A recommended approach is assessing small steps.  We achieve this by providing incremental changes for the customer to review.  They get something easy to understand and see in the grand scheme of things.  Likewise, we avoid long periods without feedback.  Those periods can be useful.  On the other hand, they can allow us to veer far from the desired path. The Twelve Principles and Overall Manifesto

The Agile Manifesto was a game-changing paper many years ago.  That impact is still felt today.  However, there are a lot of thoughts that are expressed that are often lost.  In this season of becoming a better developer, we look at all of the truths this short document highlights.  There are twelve principles that are worth digging into. This approach will help us look for ways to learn from those that went before us. The Agile Manifesto Launched Many Modern Processes A large portion of modern development theory points back to this document.  We perform many tasks that can be directly linked back to suggestions from the twelve principles.  Examples include CI/CD, sprints, scrum, and many others.  That does not mean these ideas did not also come from other sources.  Agile just happened to contribute heavily to the adoption of them.  With that in mind, it seems we should all have a solid understanding of this foundational document. More Than Documentation A common misconception we will correct is the idea that Agile can be boiled down to a desire to avoid design and documentation.  That is not the focus of the agile manifesto.  If you want to boil down this document to one thought, it is that customer satisfaction should be the focus.  Software development is not different from other products and services.  The customer is always right, even when they do not know how to achieve their goals.  We cannot tell the customer what they need.  Instead, we need to listen and help craft a solution that genuinely satisfies what the customer needs. Productive or Busy One of the things I have learned as I have reviewed these principles is that they point to a common struggle in productivity guides.  There is a difference in being busy and being productive.  One does not necessarily equate to the other.  The Agile Manifesto provides us several ways to focus on being productive, avoid busywork, and get a solution built sooner rather than later. The Twelve Principles and Overall Manifesto

Most of us are technical in our background and focus.  However, we have many facets of business we need to understand to be successful.  The area of business agreements can be confusing and seem overly formal.  Nevertheless, the documents related to this area are an essential part of clear communication and protecting the parties covered. Read The Fine Print First, let's focus on the risks of signing business agreements.  It is not at all uncommon to be asked to sign a non-disclosure or non-compete agreement.  These often are mostly boilerplate and legalese.  However, there will be critical portions of these documents you need to understand completely.  These portions are the ones that define restrictions placed on you. The scope of topics covered. What is the timeframe for the document to be in effect? (expires in a year, two years, etc.) How existing knowledge or products are impacted A well-written agreement will address the area of work you do for a client as precisely as possible.  Thus, the business of EMR applications focused on providers would be a reasonable scope.  On the other hand, all healthcare-related software would be over-reaching.  You need to be able to continue to work for a living once your current employment or contract ends. Expectations and Compensation While many business agreements are crafted to protect the member parties, there are also a lot of details that define the work and pay.  This area is another essential part of setting clear goals and expectations.  A legal argument about compensation might be just one of the things you avoid.  I cannot begin to add up the wasted hours I have witnessed over the years related to expectations.  There should always be a clear definition of the work provided, the compensation rewarded, and any related time frames. These factors are not just required for fixed-bid projects.  Even simple time and material projects where the agreement is X dollars paid for Y hours worked can get out of hand.  There are several questions you need to be able to answer in these situations. Are there budget limitations (weekly hour limits, total spend, etc.)? How does reporting and invoicing need to work? Is a signature required or other forms of confirmation of hours worked? What are the payment terms? How should the invoice through to payment work? Are there any expectations for overtime pay or refunded hours? These are just a few questions to address while you are getting started.  They can be painful to the point of destroying a business relationship when left unhandled until an issue comes up. Clear Communication The last point to make is that business agreements are only the beginning. They provide a roadmap to doing business and providing a solution.  If you do not follow through on your promises, you can expect problems.  That is not to say that those agreements are not open to change or translation.  Be clear in your goals, progress, and any required modifications to your initial proposal.  This open communication will allow everyone to address obstacles before they become too big to overcome. Learn more: Consulting Invoices and Getting Paid

This episode sees a return to the work involved in writing a book.  First, you should consider aiming for this lofty goal.  It is not as monumental as it seems and can be a substantial confidence-booster.  Not everyone writes a book, and we have a wealth of topics from which to choose.  We also have short-form options like an e-book.  You can even attempt a children's book.  The opportunities are endless. Choose A Topic The first step is often the hardest.  That is the case when writing a book.  It is not trivial to select a topic for your book, whether it is short or a novel.  Nevertheless, this is an essential step in writing and a task that is worth completing.  I have found in my experience that selecting a topic is a morale-booster of sorts.  I have often immediately afterward had an urge to put pen to paper.  The story or progression seems to form as part of the selection process.  This side effect can get you started without writer's block. Writing Has Momentum An outline is a standard tool for writing a book or any other communication.  That framework gives us a mechanism for hanging our ideas on.  I do not find many people that also mention how writing has momentum.  Once you start putting vague ideas on paper via an outline, they often lead to other thoughts or details.  The topic can flesh itself out in your head. Then you have a flood of content available to help you write more pages than you planned or expected.  This surprise is one of the reasons I think writing to a length-based goal is not helpful.  When you leave the scope open, you can thoroughly cover your desired topic. Use The Tools Available The life of a writer sitting at a scroll or even a typewriter should be history.  While these tools may have their appeal, they are not the most productive ones available.  We have a wealth of expertise and instant editor feedback available.  Use tools like Grammarly to make yourself a better writer and easily correct typos, spelling errors, and even common grammar mistakes.  You can dramatically improve the quality of your writing with a minimal investment of time.  That is a no-brainer decision for me. Learn more: Writing A Book – What You Should Know Before You Begin