Develpreneur: Become a Better Developer and Entrepreneur

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?

We shift slightly in our tour of the Agile Manifesto to focus on the opening statements.  In this episode, we dig into the value of individuals and interactions while acknowledging processes and tools.  The essential point in these opening statements is that all of these are valuable.  However, we find some to have more value than others.  This valuation should help us decide on how to make decisions and move forward with a project. We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools A Slave To Your Tools There is a well-known bit of wisdom that says when you only have a hammer; everything is a nail.  This intellectual nugget stumbles upon how we can become a slave to our tools.  When you look at the modern IT world, this has become pervasive.  Many job positions include a long list of tools that are required or preferred.  Think about that.  We have decided that it is often more important to follow a process than solve a problem.  That is why this point is made.  We need tools and techniques.  However, we can be weakened by focusing on them too much.  A better approach is to emphasize individuals and interactions.  In other words, a similar experience over a specific tool or environment. An Army of One Many years ago, there was a marketing campaign for the U.S. Army.  The tagline was "an army of one."  There are many ways you could interpret this phrase.  However, it does highlight the individual in a team.  Success requires this granular focus.  When we ignore the individuals and attempt to force them into a process, mold, or environment, success is at risk.  We cannot take that approach and still have an environment that draws the best out of each team member. A Framework And Constraints This point does not direct us to let the "inmates run the asylum."  We still need to have a process that the team follows and tools to help get the job done.  Instead of choosing one over the other, we need to find a way to pair these items to get the best out of our team.  Therefore, start with the team and select tools and processes rather than the other way around. The Twelve Principles and Overall Manifesto Challenge of The Week: Are you using your tools or are they using you?

We take a look at overall ideas from the twelve principles of the Agile Manifesto before moving on.  There are some challenging concepts mixed in among recommendations that are very common.  All of these can be applied in areas other than software development. Likewise, their efficacy is seen there as well. We follow these principles: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. The Twelve Principles When we look at these observations and recommendations, there are themes that appear.  We also can see how software projects relate to projects in other areas or lines of business.  There are foundational concepts of a good team, working together, buy-in, and communication.  Some of the concerns addressed are rarely encountered.  However, many of the challenges to overcome still exist in many teams today. Row In The Same Direction Rowing a boat and tug-of-war are often used as allegories for teamwork.  While I would prefer to avoid them, they are just too easy to understand.  That being said, most of the twelve principles address the idea of everyone rowing in the same direction.  We want a team that is cohesive, communicates and is driven.  Motivation or a good work ethic is essential in the success of a project.  Therefore, a group of motivated individuals is more likely to succeed. Define The Team There are times that an "us vs. them" attitude can arise in a project.  This attitude is not helpful.  It will often be a drag on a project and may doom the whole thing to fail.  That is why these twelve principles return several times to defining the team and helping it work better together.  Communication is a concept we often see in project success.  Thus, the Agile Manifesto does not ignore it.  Instead of eschewing documentation, this approach embraces the most effective methods of communication. The Twelve Principles and Overall Manifesto

The final principle of the Agile Manifesto directs us to reflect on a project.  We follow those eleven principles and then evaluate how we did so we can become more effective.  This recommendation should not be a surprise.  We can only improve when we examine how we did on a task.  However, this principle points to the entire team taking that step. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. The Agile Goal is to Become More Effective We started the twelve principles with a focus on satisfying the customer.  This focus is our "why" for building software.  This final principle presents us with a "why" for using the Agile approach.  We accept that we are not perfect.  Improvement is always possible and should be pursued.  Therefore, we should have regular intervals of reflection to build our list of adjustments. Regular, Not Random When we schedule a review and a time frame to create some change, we create accountability.  It is easy to pass on work needed when there is no deadline or at least not one defined.  An irregular approach to reviews makes it hard to create habits or build momentum.  The pauses to review end up feeling like more of a distraction than productive investment.  Thus, we need to integrate these reviews into our plans and schedules.  When we do, expectations are set and then quickly graded as to whether they are met or not. Get Better In Achievable Steps The first time we do anything, we often make mistakes.  That is human nature.  We start with an idea of how to be productive.  However, there are always ways to do better the next time around.  This idea is the foundation of our "building better developers" focus.  We have a long journey of improvement ahead of us, and it is best to take it a step at a time.  The review of a project is similar.  We often will find a long list of improvements to make.  There is nothing wrong with that.  On the other hand, that list can be overwhelming.  Thus, we make adjustments and tune our process a bit at a time to keep our scope reasonable. The Twelve Principles and Overall Manifesto

We near the end of the focus on the agile principles with a bold statement.  The idea of self-organizing teams producing the best results is a strong position.  They are not merely better; they make the best products.  I tend to agree with this statement.  However, it is worth defending as it is not apparent. The best architectures, requirements, and designs emerge from self-organizing teams. The Value of Buy-In First and foremost, self-organizing teams impart to each member a level of ownership.  They are given the freedom and responsibility to "get the job done."  This structure implies that the members are trusted to find the best way to solve a problem and provide their input.  It is not different from the "employee empowerment" idea used in other areas of business.  Software is like anything else we build.  The people that feel they have been instrumental in the plan will feel a sense of ownership of the solution.  Therefore, they have a sense of investment and a natural desire for it to succeed. Self-Organizing Team Create A Best Fit Every member of a team has a unique mix of skills and experience.  This rule applies to any team and any environment.  Thus, traditional roles and labels are somewhat limiting.  The idea of being a "programmer," for example, may fail to utilize a member's testing skills or design experience.  When you drop the labels and roles form a team, they are allowed to apply skills where they are needed.  This approach opens the team up to the most efficient way to combine in solving a problem.  That path is where we find the best results. An Underestimation Problem One can look at a broad range of areas where a leader drives the team to conform to a system or plan.  This approach fits the team into the system rather than the system to the team.  When you step back and think about that dynamic, it is logical to have the team define the solution.  Any other approach essentially tells the team they do not know how to best use their skills.  This method can be demoralizing and reduce the sense of ownership.  In the sports world, the results of this method can be seen when a coach is fired, and a team "suddenly" performs much better. The Twelve Principles and Overall Manifesto