Develpreneur: Become a Better Developer and Entrepreneur

There is an old saw that hard work pays off.  It may seem to be a truth that only holds in some cases.  However, things tend to work out for us when we put in the time, effort and have some patience.  A recent "pay-off" reminded me that overnight success is seldom overnight. The 10000 Hour Rule There is a book that talks about how it takes ten thousand hours to master something.  That is a focus on developing a skill.  On the other hand, we develop soft skills and recognition around areas we focus on.  That is easily seen in areas like blogging, videos, and other content production.  The more you research and talk about a topic, the more you become a perceived expert.  I am not saying the expertise is not warranted, just that it is more likely to be observed by others. Visible Practice We are multi-tasking when we take some of our spare time and invest it in skills or a side hustle.  These tasks include learning that comes from doing.  Also, letting others know the area of focus through marketing or sharing content.  Better yet, we tend to do things we enjoy, which makes it easier for us to share that content in a way that entertains others. Patience One of the most substantial challenges in becoming better every day is keeping up the effort when no visible change has occurred.  This situation is similar to the guy that works out at a gym to become visibly muscular.  The day-to-day change is almost impossible to discern.  On the other hand, looking back over longer periods of time show substantial change.  We often get too focused on the present and recent past while ignoring long-term benefits.  When you avoid an attitude of "what has this work done for me lately?" you will be able to stay on track and enjoy the journey.  When you take this path, you will find that hard work pays off in more ways than you thought. Pros and Cons of a Side Hustle

In this final episode of the Agile Manifesto season, we look at the key takeaways we should have.  These items have been a focus throughout the season.  However, we can not ignore these critical aspects of "doing Agile right."  This agile principles summary will give us some items to consider as we try to improve as developers. Satisfy The Customer The final judge for any product is the customer.  You may try to provide the example of movies that have critics and reviews.  Nevertheless, the bottom line is always the essential indicator as to whether a product is successful.  We will not get our customers to use a product that does not properly solve a problem (or problems).  We must at least satisfy the customer to achieve this goal.  Therefore, it should always be our primary focus and the final arbiter of whether a decision is the best one. Agile Is Not Always The Best Fit We spent a lot of time reviewing how the Agile process is driven by the team and teamwork.  When a team is insufficient for a task, this process will not save them.  It might even make things worse.  When a team has one "weak link," we can overcome that obstacle and strengthen it.  On the other hand, multiple weak links make it too difficult to strengthen one without putting more burden on another.  One ends up trying to stop a flood by fixing one leak when many other leaks are apparent. The Customer Is Always Right This maxim is first and foremost in the world of Agile.  We implement solutions to satisfy them and use the team to do so.  The customer does not care about the process.  Thus, when you place constraints on the team or try to make them follow a process, you are missing our "why."  Make decisions based on how it will benefit the customer.  The only other excuse is an investment in getting better as the development process moves forward. Learn More About Scrum Challenge of The Week: What did you take away from this season? How will you use this agile principles summary to improve your team or self?

We are nearing the end of the season on the Agile Manifesto and more.  However, we have several agile development patterns left to consider before wrapping this up.  The themes of teamwork, communication, and satisfying the customer continue to pop up as part of this series of patterns. Swarm Agile assumes that things will happen that require us to change our approach.  These challenges may be new features that are critical, bugs, or highly underestimated tasks.  We all have seen these sorts of obstacles that threaten to derail our best-laid plans.  The swarm pattern is one way to handle such issues.  We use this pattern to assign all resources to a single item or task with the goal of "knocking it out" and clearing the way for overall progress.  We use this pattern when we see an obstacle causing continued damage or delay to our plans as long as it remains.  Think of this as removing the highest pain-point first so other needs can be met. Test-Driven Development Testing has traditionally been done after the implementation.  That is not a requirement.  We can create tests that need to be passed as part of a successful implementation.  Then the implementation is done with the tests as a goal.  We see this in education when teachers "teach to the test" instead of a more comprehensive educational approach.  In this case, we also can free up test resources to define tests throughout the sprint and avoid a flurry of testing at the end of the period.  We can even set up tests via TDD to deploy features as they are implemented because the testing is already in place and run. Pivot, Co-Location, Time-Boxing, and Refinement The are several terms and concepts that can be seen as agile development patterns even though they are also traits identified.  We see this in patterns such as pivot or time-boxing.  These are methods for implementing Agile that can easily be overlooked as a pattern.  They are not buzzwords and are instead well-defined methods for addressing agile principles.  We want to communicate, set expectations, and get better as we advance through sprints. Learn More About Scrum Challenge of The Week: How well do you implement these patterns?

We continue a review of key agile patterns with more ways to make sure it all goes right.  Each pattern is possibly overstated.  However, we need these to be a part of our process to get the benefits of an Agile approach.  As always, when we veer away from these patterns, we increase our odds of failure. Product Ownership We have mentioned the product owner as a role in Scrum.  We need this person to provide decisions.  That may seem trite or simplistic.  Nevertheless, an Agile project often requires someone to make a decision.  That may be a user experience opinion or a key business direction built into the solution.  Analysis paralysis is far too easy to fall into when so many decision points exist as they do in this process. Quality of Service We noted early on that the Agile Manifesto recommends regular and working software delivery.  This principle gives us a method for feedback from the client and builds trust with them.  That makes the quality of service one of the most essential of the key agile patterns.  Trust is built with the customer when we make promises and deliver on them.  Thus, we reduce stress and drama by stating what we will do and then following up.  It reduces or eliminates discussions around estimations and planning as the team is trusted to give their best effort.  The urge to "haggle" items into a release or squeeze estimates is reduced when our estimation skills are trusted. Relative Sizing We often talked about estimating tasks.  This pattern focuses on our ability to estimate relative differences among tasks.  For example, we need to categorize items as easy, hard, and in between.  This skill impacts our overall estimates.  When we improperly place a task in the wrong "bucket," it can completely tank our velocity.  This result is just common sense.  Correcting for a 5% mistake of estimation is far easier than 50%.  That goes both ways.  It may be nice to get a two-day task done in an hour.  However, that can completely mess with our velocity.  The tighter our estimates, the better, and that means placing tasks in the proper buckets. Servant Leadership This pattern boils down to working for the good of the team or project as opposed to ourselves.  That is critical for agile teams that function on the highest levels.  We work together to remove obstacles for others while ours are removed as well.  It allows all of us to move forward quickly while also building morale and camaraderie. Learn More About Scrum Challenge of The Week: Which of these key agile patterns would benefit you most?

In this episode, we continue a tour of patterns for Agile.  We will see definitions we need to set as well as tools for success.  A deeper review of this can be found on the DZone web site.  However, this should give you a good start on a checklist of items to include.  When you skip any of these, you reduce your odds of a successful Agile project. Increments We have talked about this before.  However, it is important to call out as one of the patterns for Agile.  We need to set the incremental schedule we will use for things like sprints and the related estimates.  The team works better when they can plan based on set time frames.  An example would be the length of a sprint.  This process's key property is a set amount of time per sprint as opposed to trying to complete stories during varying lengths of time.  Think about a sports match.  The players will not be happy if you tell them the match will end based on some random factor instead of a set score or time limit. Information Radiator Communication is key throughout this process.  The information radiator is our primary means of this communication.  There must be a mechanism for providing the current project status to team members.  This goal is often achieved through a Kanban board, whether physically in an office or digitally on a team site.  The radiator provides information on the tasks, the assignments, and the current status.  It should also be kept as up-to-date as possible. Inspect and Adapt The team will not improve if they cannot assess where they are and where they have been.  This pattern is an essential step in improving over time.  The team inspects what they have done and how they accomplished objectives.  Next, they make changes and adapt their processes to get better the next time.  This concept leads us to the next pattern. Iterate Iterating, in this context, is a science.  The goal is to get closer to the desired objective with each iteration.  It will often go hand-in-hand with the Inspect and Adapt pattern to make changes that get us closer to the desired results.  When an iteration gets further from the goal, then we need to correct it the next time. This process is sort of like guessing a number via hi-low.  You make the first guess to eliminate several possibilities.  For example, to guess a number from one to twenty, you guess ten first and eliminate half the options.  You then proceed to halve the options again and quickly get to the number.  When we iterate smartly, we have a method similar to this. Limiting Works In Progress We want to complete a story with each sprint.  There is also a desire to squeeze in as much work as possible.  On a sprint level, we want to limit items that are in progress and pushed to the next sprint.  Within a sprint, we want to complete the steps as soon as possible.  Then, the next step can be taken.  A common example is coding a task and marking it complete.  Therefore, testing or code review can begin. Learn More About Scrum Challenge of The Week: Are you missing any of these patterns?

We take a look at Agile patterns as we come to the end of this season.  There has been a lot of content covered.  However, we do not want to move on without looking at tools for implementing these practices.  Fortunately, there is an excellent DZone article on Agile patterns for those that want to dig deeper into these. Avatars An avatar is exactly what you might expect on a project.  It can take the form of a magnet, a pin color, or a miniature of some sort.  It could even be a playing piece from a board game.  This pattern aims to give each dev team member a limited number of items they can work on at a time.  When a ticket is "claimed," the avatar is used to mark it.  Thus, everyone can see who is doing what and it keeps members from being spread too thin. The Backlog This pattern is one of several of the agile patterns we will cover that have already been mentioned numerous times in our discussions.  These items are likely already known to you in some way.  However, they are still patterns we want to embrace as part of the agile process. Controlled Failure We are allowed to stop or pause tasks and even sprints as part of the Agile approach.  There are many discussions available about the challenge of addressing lost opportunity and sunk cost.  However, that is only part of what this pattern addresses.  Also, we need to be able to stop forward momentum at times to embrace change.  Controlled failure permits us to stop what we are doing to focus on something that has greater value. Done It is amazing how varied the idea of "done" can be.  Likewise, that makes it one of the agile patterns we need to address as part of communicating.  We need to agree on what certain terms and concepts mean, so the team members have a firm understanding of what is needed and communicated.  The idea of "done" and how we progress tasks is important to define.  When we do, we give the team members the tools needed to dive into tasks and complete them in the agreed manner. This pattern extends to assumptions that include testing, quality assurance, code reviews, and more.  We want to define how tasks are worked on and progressed through to deployment.  That gives us a consistent method of evaluating progress and quality. Estimating/Forecasting The scrum approach avoids specific time estimates, where possible.  Instead, we provide general forecasting around task complexity and level-of-effort.  That ambiguity requires the team to have a common understanding of what our scoring mechanism relates to.  For example, a team that uses estimates values of 1,2,3,5,8,13,21 needs to have some basis for assigning those values to tasks.  We are not saying a 1 takes one hour of work.  However, we do need to provide a framework for assigning these values.  The team will always have variations on their forecasting (based on understanding and experience).  Nevertheless, we need some common ground to keep the variations from being too broad. Learn More About Scrum Challenge of The Week: Are you missing any of these patterns?

The focus on anti-patterns continues with this episode.  We have touched on some of these challenges in other examples.  However, these scrum management anti-patterns are special in that they often point to a lack of confidence in the process.  That can reduce morale and the team's dedication to the process.  It can rapidly devolve into a negative monkey see, monkey do situation. Going Around the Scrum Master There are several reasons why a team member is tasked with specific work.  However, these directives can reduce the team's ability to self-organize.  Micro-management of a Scrum team shows a lack of respect for the Agile process and can quickly lead to the team working for their boss.  This lack of teamwork reduces overall productivity and is devastating to a scrum team.  Allow the "coach" to do their job and the team to be the best they can be. Everything is a Bug Many teams adjust priorities and even sprint scope rules to address bugs.  This can include pausing a sprint or pulling resources temporarily.  In an Agile project, many things will arise that need to be addressed but are not a bug.  When we call every desired change a bug, we ignore the idea of changing requirements and adapting to those.  We also run the risk of labeling everything as urgent or critical.  That defeats the purpose of priorities and planning. Disrupting the Sprint Flow One of the productivity boosts that occurs from sprints derives from the team being able to focus.  Distractions are exactly that.  They pull us away from a task to some degree and reduce our ability to get the job done.  When we disrupt the sprint flow, we introduce a productivity reducer to the whole team.  That will always be a negative impact on the velocity. Shifting Resources We have mentioned in other anti-patterns that we want to keep sprints similar.  That provides us a path to more direct comparison from one to the next.  That is where our best trend data will come from.  However, this breaks that and becomes one of the worst of the scrum management anti-patterns. This mistake arises when management moves resources around from sprint to sprint and team to team.  When your team members are different for each sprint, you will have a hard time building cohesion.  Teamwork can not come about instantly.  It requires the members to work together over time to build trust and comfort with each other. Learn More About Scrum Challenge of The Week: Which of these do you see in your team?  How will you fix it?

Our focus the last few episodes have been on anti-patterns relegated to a specific role.  We take a step back in this episode and review scrum team anti-patterns.  These are mistakes we make on a whole that can derail our project and reduce velocity.  These can even drive a product into failure. Deliver The Wrong Thing There are many ways this anti-pattern can make an appearance.  The story may be too vague, requirements gathering is insufficient, or the dev team misses the point of a feature—all of this boils down to a communication problem.  Yes, we have once again come to a point where our problem and solution fall under the category of communication.  This time the root cause is a failure to perform our duties fully.  We have to be diligent in our work, and cutting corners can lead to this mistake. Lack Of Urgency Any good coach knows that part of their job is motivating the team.  There needs to be a sense of urgency or some objective that the team focuses on.  A sprint has this feature built into it in the form of the working software deliverable.  Unfortunately, we have this situation that is as much everyone's failure as any of the scrum team anti-patterns. The team sets the objective and story for every sprint.  When we decide (as a team) to skip a deliverable, we open up this can of worms.  A lack of a deliverable can remove urgency in a sprint.  It is like studying a topic where there will be no test.  We are allowed to flounder and progress to our level of comfort.  Most of us will not push ourselves when this occurs. Pass The Buck Another facet of the lack of urgency is this anti-pattern.  A sprint has a mechanism for pushing items to a future sprint via rollover or returning to the backlog.  This option can be over-used and cause us to feel like a task will be covered at some point with no need to address it.  This can be seen as a Scrum master problem.  However, the team often allows tasks to fester rather than force them to the forefront. Variable Sprints We have mentioned a need to compare sprints to each other.  This objective is difficult or impossible when we change critical factors of a sprint such as duration.  The team must do what they can to protect the resources and constraints for each sprint.  When this is done, it provides a better comparison of each sprint to measure our progress truly. Learn More About Scrum Challenge of The Week: Which of these do you see in your team?  How will you fix it?

We have talked about Scrum and Agile.  However, some guidance helps us improve our odds or success.  That is an essential part of becoming a better developer.  In this episode, we look at scrum master anti-patterns and position the team for improvement and success. No Retrospective Everyone needs a plan to be productive in pursuit of a goal.  Our goal of improving with each sprint will be impossible to achieve without assessing how we are doing.  That is what a retrospective provides.  When we skip the retro, we are embracing the worst of the scrum master anti-patterns.  There are situations where we are pressed to skip over this "additional meeting."  However, it is a key factor in our improvement and should be viewed as a requirement that cannot be removed. Lack Of Support The scrum master is tasked with clearing obstacles for the team members.  That responsibility is served by listening to team members, assessing issues, and getting those obstacles out of the way.  When a scrum master does not handle these jobs, then it falls to the team to get it done.  This disrupts the flow, pulls members away from their sprint tasks, and generally bogs down the team.  Productivity and velocity will be impacted and reduce the value of the process. Flow Disruption An important piece of the scrum puzzle is team focus.  This factor gives us the steady availability of resources for each sprint to compare apples to apples from sprint to sprint.  That is where positives and negatives are the most visible.  When we have a varied amount of time and resources for each sprint, it keeps us from comparing progress.  That also makes it impossible to provide valid estimates of target dates.  We must have a known level of resources to match our estimates and achieve a target date.  Otherwise, we are trying to hit a moving target. Micromanagement The scrum master is the guardian of the development team.  This combines with flow disruption as two scrum master anti-patterns that are team obstacles.  Therefore, they go against the core reason for the role of a scrum master.  The more the dev team can be freed to focus on tasks, the more productive they are.  That is almost a direct definition of increasing sprint velocity. Learn More About Scrum Challenge of The Week: Which of these do you see in your team?  How will you fix it?

Everything in software development has good and bad patterns.  We have looked at why the agile approach is valuable.  However, we need to review agile anti-patterns to avoid problems that can erase any benefits.  There are many ways we can misuse this process.  Here are some development team mistakes we can avoid No WIP Limit There is a pride people have around multi-tasking.  However, it is not the most efficient way to get things done.  Even worse, we can end up having too many tasks in flight when a sprint ends.  This causes a broad range of challenges and can block a team from critical sprint tasks.  We should take a task, complete it, and then move on to another.  Nevertheless, we can sometimes have more than one item in progress to reduce dead-time in our day. Cherry Picking We all have things we prefer to do.  This tendency can cause problems in the Agile environment.  The team members need to focus on getting work done to help the sprint complete successfully.  Cherry-picking is one of the agile anti-patterns that can arise from team members abusing the freedom this process gives them in tasks.  Sometimes we have to pick the big, complex, or not-fun tasks to better the team. Out Of Date Work Board Communication is key.  An out of date board is one of the most dangerous agile anti-patterns.  It can cause us to duplicate effort or sit in a holding pattern when we could be productive.  This responsibility is not on the scrum master alone.  The team members should report their progress by keeping the board synchronized with the latest progress. Side Gigs Everything in a sprint should be tracked in a ticket.  That allows us to properly measure work, time, and, ultimately, our velocity.  There are always temptations to help out a co-worker (or CEO) with a side task or project.  Nevertheless, we need to track that effort.  This requirement is essential in our overall success.  Thus, do not feel bad about forcing side work requesters into the sprint backlog and process. Learn More About Scrum Challenge of The Week: Which of these do you see in your team?  How will you fix it?