Develpreneur: Become a Better Developer and Entrepreneur

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?