Develpreneur: Become a Better Developer and Entrepreneur

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?

It may come as a shock, but there are agile weaknesses.  These are situations where a different approach brings a lower risk.  These weaknesses also point to the strengths and attributes of a project or team that make agile the best choice for our framework.  None of these are set in stone.  Thus, knowing about the weakness is an opportunity for overcoming it. The Team Is Central Most of the Agile weaknesses center around the team and their ability to follow through on the principles or values.  The most essential of these is the ability of the team to handle cross-functional tasks.  It requires developers in the dev team rather than just several coders.  We ask team members to understand and perform duties outside of their strengths.  This ask includes requirements gathering, design, and quality assurance that is not comfortable for most junior staff. The dev team is designed to work as a team.  However, a member that always needs hand-holding from teammates may be too weak a link.  Agile is not a recommended solution for inexperienced teams.  It asks too much of them. Constant Communication The rise of remote work as a viable solution to more projects has its pros and cons.  In the agile world, this can make success more or less likely.  There is an underlying theme of steady communication that the principles require.  A remote team can achieve this.  However, the lack of face-to-face interaction can cause problems.  Team members may work different schedules or have technology issues like internet connectivity problems or personal challenges like loud children.  These obstacles can be managed to some extent.  Nevertheless, they can also cause stress on the team that makes the sprints fall apart due to too many unforeseen setbacks. What To Do A team or project that suffers from agile weaknesses has two options.  They can embrace agile and find ways to offset the shortcomings, or they can choose another framework.  For those that want to adopt agile, consider these steps. Simplify and standardize communication where possible Set up alternate communication methods before they are needed. (phone, email, and chat options for example) Emphasize team building and teamwork Adjust time buffer and estimates to minimize the impact of weaknesses Push cross-training early and often.  Build the team skills that will improve the odds for success These are just a few steps to take.  However, they can make a big difference in how smooth a project runs (or not). Learn More About Scrum Challenge of The Week: How well does your team fit the Agile process?

We have covered a broad range of topics in our discussion of Agile.  However, the goal of this approach is to fit your team and environment.  Think of it as an agile philosophy and not a well-defined or rigid process.  Your team should make the framework applicable to them, not force the team into agile methods. Make Adjustments The principles and values laid out in the agile manifesto point to one or two primary goals.  We want to satisfy the customer and do so with working software.  All of the other details of the manifesto are for helping us to accomplish those goals.  If any step or recommendation detracts or distracts, then we can skip it.  However, we should not do so lightly.  These are recommendations.  Therefore, they are probably going to be good things to follow while not always necessary. Dip A Toe In Several principles can be attempted in "little doses."  For example, you do not need to provide working software with every sprint or even a review each time.  There are plenty of sound reasons for skipping these steps at times.  Thus, rather than blindly becoming a slave to the process, allow for times where you skip a step.  The measure for these instances is whether or not it is valuable. A modification to sprints, scrum, or principles that makes it easier for you to "try out" agile is perfectly acceptable.  Your team will likely grow into a full embrace of the manifesto principles.  However, that is not needed, and you should consider any improved progress as valuable. Fit Your Style Every team has a different set of strengths and weaknesses, along with its style.  That means agile will look different for each group.  Embrace the uniqueness of the team with an agile philosophy that works for them.  Do not force them into a process that checks off the boxes of agile principles. Learn More About Scrum Challenge of The Week: What works or is broken in your process that needs to be re-invented or thrown out?

The sprint retrospective is where we take the time to assess how we did and plan for improvement.  It is essential for getting better.  Unfortunately, running this activity can be challenging and easy to underestimate for its value.  Here are some suggestions for converting the time spent in a retrospective into action items for improvement. Initial Challenges All teams start out working on how they communicate.  That is just the nature of being human beings.  It is not different in the professional world.  We have processes to clarify and terminology to agree upon.  That means an early sprint retrospective will likely have this "low hanging fruit" to address.  These items may seem trivial or surprising for an experienced team.  However, they are important issues to address to set the stage for future metrics and improvement. Quick fixes are good for earning early victories.  However, it is more important for us to address issues that build habits.  When we do things right early and often, they become habits and even traits of our team. Gather The Details Another issue that often shows up in an early sprint retrospective is a lack of details in task descriptions.  That includes validation criteria and how we determine whether we are "done" with an item.  Therefore, this information is critical to us.  It impacts how we document progress and can help avoid rework on features that are too loosely defined.  Fortunately, these areas for improvement show up early and are best when addressed sooner rather than later. Do Not Skip The Positives There is a tendency for us to focus on negatives when we want to improve.  However, that is not a productive way to look at it.  We need to continue doing the things we did well.  Therefore, it is worth our time to list those out as part of our assessment.  These items are the ones we want to keep doing well, and we should see them reoccur from sprint to sprint.  If something falls off that positive list, then we might want to take a look at it before it becomes a negative. Learn More About Scrum Challenge of The Week: Take some time for a personal retrospective and make plans for getting better in your next sprint.

We have set a goal of delivering working software as part of every sprint.  That requires sprint planning and deciding on what will be in or out of scope.  In this episode, we look at ways to craft a sprint and assist us in setting priorities and content.  The ultimate goal is to provide working software that satisfies the customer. The First Step When we start a project, there will often be an overwhelming amount of tasks in the backlog.  We will need to go through several sprints to reduce that long list of items.  Our goal is working software along the way so consider crafting a story for each sprint.  This will provide a way to tie together the tasks completed and show value to the customer. For example, we often start with foundational tasks like security, registration, authentication, a home page, etc.  We can have a story for an early sprint that is "Register The User" or "The User Home/Landing Page" or "General Site Navigation."  These may span multiple sprints or could be combined for a single sprint.  The story should tie to use cases of some form and then to the tasks in the sprint.  When you take the approach, you set some constraints for the sprint and crafting a way to communicate the progress to the customer. Fill The Bucket There is an often-used example of scheduling time that equates it to putting rocks in a container.  You have large stones that can fill the box, then smaller ones that can fill gaps and down to some sand (or water) to fill the time.  A sprint can work the same way.  We will have large items that take a lot of time/effort and then smaller things we can slip into the "cracks" in the schedule.  Start with a couple of significant/cornerstone tasks that contribute to the story and fill in around those. We will look at prioritization, and that should be approached so that the larger items are higher priority, and the least essential items are also smaller.  That will allow for the most efficient combination of small and large tasks.  We often have small amounts of time available at the end of a sprint to "fit something in" rather than large blocks of time. Priorities Many sprint planning approaches I have seen often include three categories of tasks.  These categories are: items to complete in the sprint, functions to complete, and "nice to address" features.  Our story will provide a basis for assigning those priorities. In our previous example, we mentioned a user registration story.  Some critical tasks for that would include a user registration page/form, creating a user in the system, and the process to move from registration to registered for a user.  That gives us our "must-have" items.  We can add tasks that should be included, like validation, and maybe login to show a user is registered.  The nice-to-have functions might be a registration confirmation email sent out or change password functionality. Learn More About Scrum Challenge of The Week: How do you handle your sprint planning?

Several sub-tasks are needed for proper sprint grooming.  They are essential steps in crafting a sprint plan.  These tasks are not trivial and include such on-going difficulties as estimating the time or effort required.  In this episode, we will look closer at these essential activities. Estimating Effort There is no end to the content available to assist us in estimating effort.  However, there is also no silver bullet that allows us to guarantee proper estimation.  That is not a blocking issue.  We will get better at estimating as we do it more often.  Perfection is not needed.  We do want to be as consistent as possible and be able to get close to our estimates.  This task is not for driving effort or accountability as much as it is to provide a metric for velocity.  We want to be able to say how many estimate points we typically tackle in a sprint. Effort Sizing Sprint grooming is when we select items to place in a sprint.  Therefore, we need to have a rough idea of the number of points we can implement per sprint.  We also need to have items in the backlog that have point values far lower than our velocity. Even better, we should be able to tackle one or two tickets per developer per day, where possible.  This approach gives us a comfortable granularity for progress and allows a dev team member to feel like they have accomplished something every day.  Break larger tickets into smaller and more manageable parts where reasonable. Load Up The Sprint It is important to remember that the goal of sprint grooming is not fully loading up the dev team.  There are non-implementation items like meetings and planning that will cut into a full load.  We also want to allow for some buffer in case an item is under-estimated.  A safe target seems to be around 75-80%.  A sample breakdown of this can be seen in this article. Task Life-cycle The last thing we review in this episode is the complexity around the life-cycle of a task.  This process is often biased or defined by the way the team works and ticket granularity.  For example, you might have a test status for a ticket, or testing can be a different ticket.  Every team needs to define this process and how tickets flow.  However, the details involved are specific to each team.  Therefore, note that life-cycle needs to be defined. Do not assume that what works in one team works for another. Learn More About Scrum Challenge of The Week: How do you create (and estimate) tickets?  What obstacles need to be removed?