DiscoverDevelpreneur: Become a Better Developer and Entrepreneur
Develpreneur: Become a Better Developer and Entrepreneur
Claim Ownership

Develpreneur: Become a Better Developer and Entrepreneur

Author: Rob Broadhead

Subscribed: 87Played: 5,668
Share

Description

This podcast is for aspiring entrepreneurs and those that want to become a designer and implementor of great software solutions. We look at the whole skill set that makes a great developer. This includes tech skills, business and entrepreneurial skills, and life-hacking so you have the time to get the job done while still enjoying life,
175 Episodes
Reverse
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?
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?
We have already touched on the scrum ceremonies.  However, the way we perform each ceremony goes a long way towards embracing the Scrum process.  Let's take each item individually and examine how we can make the most of them.  These are investments in building a better sprint team.  They come from the Agile principles, and it is important we keep that in mind for each activity. The Daily Standup This task is the most popular of scrum ceremonies in my experience.  However, it is often misused.  A well-run standup should be so short it is not worth the time to sit down for the meeting.  A good goal is less than fifteen minutes.  That may seem brief for a meeting.  On the other hand, this is not a meeting as much as an organized method for touching base.  Think of it more as passing by a team member in the hallway rather than a discussion. The goal is for members to state how they are doing and possibly asking for time to have a meeting or working session.  Obstacles should be noted and whether the sprint is behind or ahead of schedule.  Keep the gathering topics precise and concise. Sprint Review Every sprint should have a deliverable of working software.  That is where the sprint review comes into play.  We gather the team together at the end of a sprint to walk through what was accomplished.  This ceremony is often referred to as a demo, and that is a good label.  We set a fixed amount of time (one or two hours), then we have each dev team member present their completed items. Some of the tasks we complete are non-visual.  That is ok.  We will still present something about them in the review.  A unit test, a log message, or something of that nature is enough to hang a description on and "show off" what was accomplished. Sprint Retrospective The retrospective is the improvement focused task of the scrum ceremonies.  The other two fulfill goals and focus on implementation.  This task is where we look at how we did and discuss ways to improve.  The process is simple to leave the maximum time for discussions and ideas.  We do this after a sprint completes and set aside an hour or two with the entire team. Everyone should list things the team did well and those that need improvement.  It is ok for multiple members to list similar items.  That implies items that have a more considerable overall impact on the team and project.  Once the master list is set, the group discusses possible improvements and what can be done in the next sprint.  That means some items will stay on the improvement backlog for a while.  We will have a lot to improve on when we start.  On the other hand, we should be getting better with each successive sprint. Learn More About Scrum Challenge of The Week: How can you incorporate sprint ceremonies in your current project?
The sprint process is a popular way to implement the Agile approach to software development.  Is has its detractors.  However, there are many ways that this approach can split up a large project into smaller bites.  This action of breaking something big into manageable pieces increases the chances of success.  Also, a sprint helps us address numerous principles discussed in the Agile Manifesto. Deliver Working Software A challenging part of the sprint process is the goal of delivering working software as part of completing each sprint.  We are not ignoring the SDLC steps.  Those six steps are being repeated each sprint and require a little creative thinking. Working software is not the same as useful.  We can build a solution in a sprint that is light on the usefulness scale.  For example, we can deliver software that allows a user to register and log in or a report with minimal data.  These are both steps towards our ultimate solution, and working versions advance our overall progress.  That makes them excellent ways to achieve a deliverable in a given sprint. An SDLC Approach The sprint process includes the common SDLC steps in each cycle.  Maintenance may not appear very often.  However, when you consider bugs fixes and similar backlog items as maintenance, you will see examples.  We gather requirements by moving items from the backlog.  A design period should be incorporated before implementation.  Then we code and test.  We wrap up by deploying the software and a customer review. A Matter Of Timing The SDLC steps are often done in a waterfall manner.  Thus, we design, then implement, then test.  That lays out a schedule where a little design is done in the beginning, a little testing at the end, and a lot of implementation in the middle.  We need to adjust these tasks in a sprint to keep resources (dev team members) busy throughout the sprint process.  This goal can be achieved with cross-trained members that can do the implementation and then switch gears to test the code of others.  That allows heavy testing at the end by all dev team members. However, team members have strengths and weaknesses.  It is rare to find a developer that is also good at testing (or vice versa).  Therefore, we want to utilize out testing resources early in the sprint process and not hold them ready until the final days.  We can either solve this by implementing during one sprint and testing in the next or by completing items (ready to test) early in each sprint.  Either way is feasible, but you will have challenges to work through in either case. The Twelve Principles and Overall Manifesto Challenge of The Week: Do you utilize the three sprint ceremonies?
The Agile Manifesto gave us many ideas.  These were embraced by the software development community and implemented in many ways.  Scrum is one of these implementations that has become very popular.  Thus, it is valuable for us to examine what this framework provides and how it works.  In this episode, our focus is on the roles defined as we craft an overview of Scrum. The Product Owner We build solutions to problems.  Thus, our goal of satisfying the customer requires someone that understands the problem and constraints for the solution.  That role is called the product owner in the Scrum framework.  While this can be accomplished by a small team, it is best when an individual fills the role.  Design by committee is an anti-pattern we want to avoid, and a Product Owner team steers us toward it. This role must understand what is required to satisfy the customer.  They essentially grade us on that satisfaction and guide the team towards features that accomplish that goal.  There is often a greater scope to this role that includes things like profitability.  However, if they are not an effective customer advocate, then they will suffer in this role. The Scrum Master Every team needs a coach.  Thus, that is what the Scrum Master provides.  This person helps the Product Owner and the Dev Team use Scrum most effectively.  They push the team to get better with each sprint and leverage the framework to improve quality and velocity.  This role is a type of manager.  Their primary objective is to remove obstacles that slow the team down.  Therefore, the best Scrum Masters find ways to coach the team to improve their velocity with every sprint. The Dev Team Work is required for every project.  That is the primary responsibility of the Dev Team.  This group is roughly three to nine members that drive implementation.  They work together to achieve goals and to do so better with each sprint.  However, note that the Dev Team is a group and not a list of specialists.  While highly skilled members of a Dev Team exist, the more we can move task assignments around, the more effective the team is.  We want a team that can be directed to pour resources into a task, if needed, to keep on track.  Unfortunately, some specialists are limited in their ability to accomplish this objective. The Twelve Principles and Overall Manifesto Challenge of The Week: What does your team look like?  Do the roles match Scrum?
In this episode, we reach the fourth and final value statement.  There is a larger value in responding to change than following a plan.  Planning is essential but reacting is even better.  Thus, we have another value of the Agile Manifesto that compares two things in a "1 A" and "1 B" prioritization.  However, these two concepts work together to provide us an effective way to navigate project challenges. ...Through this work we have come to value:... Responding to change over following a plan Make A Solid Plan Planning has many benefits.  While we may not enjoy the process, few argue that it is a waste of time.  I like to view it as a form of practice for the event or function we plan.  When we plan, we run through steps in our mind and write down (i.e., plan) or capture how we want to approach each one.  Planning can involve many resources.  However, it boils down to a design process.  We look at a step or event and then plan out what we need to accomplish it.  A solid plan tells us what to do.  This pre-work on the applicable tasks helps us to iron out challenges and improve our odds of success. Change Happens All of that work on a plan may be limited in value when things change.  We could even say that time was wasted.  On the other hand, let's focus on what we did when we created a plan.  It is a design process.  Thus, we consider the task, approaches to completing it, and then choose the best approach.  That means we have at least thought about alternate paths and resources.  When change happens, those alternatives help us.  We already have some options we have considered that can be used in responding to change.  It has been referred to as "go to plan B." That secondary plan does not need to be documented.  We already have some mental work that has been done along those lines.  That is a head start on getting the task completed in a different context.  We have already spent time to find a solution in a world where some or all of that change exists.  We are more nimble when we have experience in a situation.  That is true even when the experience is only a mental exercise. Know Your Destination A plan is a map to take us from where we are to a specific destination.  The change that occurs during that journey may alter the goal.  Nevertheless, we have a rough idea (the plan) of how to make the journey.  Therefore, we can adjust to change in incremental ways by adjusting milestones and our path in small ways.  This approach is far more reliable and accurate than resorting to large adjustments that are almost as bad as a shot in the dark. The Twelve Principles and Overall Manifesto Challenge of The Week: How do you handle responding to change?
Software development works best when everyone is on the same team.  We need to pull together to be most effective.  However, the sub-groups and members of a team have differing goals.  That is why we have things like contracts.  We sometimes have to put down our plans and goals in writing.  Negotiating these things can be tedious and even can cause some negative feelings.  Therefore, we value customer collaboration over contracts. ...Through this work we have come to value:... Customer collaboration over contract negotiation Differing Values and Concerns We can all agree that some people lack honor.  Some people and organizations are a step above thieves.  I find those to be uncommon and an issue not worth worrying about for this discussion.  Nevertheless, we will run into situations where there are conflicting goals for the different groups that make up a team. These differences may be noticeable, like a vendor wanting a reasonable rate vs. a customer that prefers a discount.  On the other hand, there may be less apparent differences, such as a group that values quality over timeliness.  That give-and-take is not a detriment. Contract Negotiation The concept of contract negotiation pushes us towards the customer-vendor relationship.  One wants the most work done for their money, and the other desires the most compensation for their work.  I realize this is an over-simplification.  However, it sets the stage for negotiating multiple items within a project.  These extremes are not realistic, and that allows us to negotiate agreements that can be considered a "win-win."  This principle points to a more considerable value.  We can collaborate and build up goodwill that allows us to coast over those points of contention. Communication and Expectations Once again, we find ourselves discussing clear communication and setting expectations.  These are proactive steps that have more value than reactive contract negotiation.  Thus, customer collaboration allows us to address challenges and differing goals before they fester and become major issues.  We also can make adjustments earlier in a project when they are less costly.  Of course, all of this does not even begin to count the time spent in negotiations that can be better spent elsewhere. The Twelve Principles and Overall Manifesto Challenge of The Week: When did you last have to negotiate a contract?  Do you work towards win-win?
We started this season with a focus on satisfying the customer.  Since then, we have built a case for working software being the best way to achieve satisfaction.  Thus, comprehensive documentation is valuable.  However, not as useful to our primary goal.  Agile is often painted as anti-documentation so let's dig deeper into this comment that could be used as evidence. ...Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation We Value X Over Y The opening section of this summary says we value all of the listed items.  Rating one over the other does not mean the lesser has no value.  For example, you prefer breathing over food.  Would you argue that food is not essential?  We can take that example further.  You value air over fine cuisine.  Does that mean you do not appreciate food? It is essential to look at the eight items listed here as critical pieces of a software project.  They are all necessary.  Therefore, we cannot ignore one of them without putting the project in peril.  I feel a need to be clear on this point before moving deeper. Comprehensive Documentation Another critical point of this comparison is the idea of comprehensive documentation.  That is a point on which I think we can all agree.  Documentation (of some sort) is required with any software project.  Few would argue against that.  However, "comprehensive documentation" is another level and can be seen as a nice-to-have.  Furthermore, this is a gray area where we could argue what comprehensive documentation contains or encompasses. Working Software If "satisfy the customer" is our "why" for a project, then working software is the "how" or the "what."  We are building an application for our customers.  Falling short of that is the equivalent of "smoke and mirrors."  Even worse, it could be referred to as vaporware or even a bait-and-switch.  In any case, a customer will not be satisfied until they are at least provided with a product they can use. We need to tell them how to use it (through documentation), but more value exists in working software.  Even with Agile, we need to keep our focus on the primary goal. The Twelve Principles and Overall Manifesto Challenge of The Week: When did you last create comprehensive documentation?
loading
Comments (2)

hugo

great podcast ;)

Sep 17th
Reply

BoogaTheOoga

This show is great. I find it motivating and informative.

Feb 21st
Reply
Download from Google Play
Download from App Store