Tag: agile

  • The Value Of Demos and Walk-Throughs

    The Value Of Demos and Walk-Throughs

    One of the most challenging facets of building software is determining where to spend our time. Demos and walk-throughs are one of those areas that can be overlooked in the chase to save time. However, they are essential in communicating progress and gathering feedback. These require time and attention from everyone on the team, so let’s look at ways to ensure we get the most out of this investment.

    Demos and Walk-Throughs Are Not Optional

    We can start by agreeing that every project requires this activity at least once. While one can build a solution and “throw it over the wall” to the customer, I do not know anyone who accepts that approach. There are too many details, and custom software is too expensive. No one buys a house without a walk-through, and software should not be any different. A big cost equals a big investment. Therefore, we want to review the results before signing off on them. That can be accomplished without a demo, but it can be time-consuming and confusing to jump into a system and try to use it. We need context to help us assess a solution, and that is where demos and walk-throughs fit into the process.

    Your Definition, My Words

    An excellent way to be clear when we are communicating is to have someone say back to us what we told them but in their words. The same exercise can be done through a walk-through of a solution. The project starts with requirements and a solution specification to ensure everyone is on the same page. However, there can be design drift and miscommunicated goals that cause a solution to vary from the specification in subtle yet critical ways. A demo helps us detect drift sooner and possibly avoid these issues. At the very least, this helps us reduce the cost of correcting drift. The implementors explain how the solution works while showing it in action. That provides a perfect starting point for concrete discussions and feedback about the solution.

    Assumptions and Details

    When we describe a process or problem, it is easy to incorporate assumptions and gloss over details. For example, think about explaining how to tie a shoe. Write down the steps you need to take and then follow them explicitly. Most people will fail to tie their shoes. The details and assumptions hidden in the process steps do not become apparent until you test the steps by applying them.

    Modern software is highly complex and detailed. Thus, we need to test the steps and requirements we start with through regular demos and walk-throughs that explicitly follow the implemented solution. This provides us more confidence with each successful journey through a feature while also making it easy to see exactly what is being built. That reduces confusion and invites feedback to correct any drift or misunderstandings. The cost-savings and improvement of the success rate from these activities alone make them essential in any project.

    Trust and Teamwork

    The above reasons should be enough to convince anyone that demos and walk-throughs must be a part of every project. However, many more benefits come out of those meetings. The most valuable of them are trust and teamwork. A demo that includes feedback and discussion is, almost by definition, teamwork. The participants work together toward a common goal. These interactions also build trust and relationships that are essential for a strong team. Projects often hit rough patches and introduce stress into the team dynamic. When we have trust and solid relationships, these bumpy periods are easier to navigate. A lack of trust in any group or relationship will almost always make the hard times harder.

    Transparency

    We get a form of transparency as well as clarity through regular demos. The progress made and how it looks is available to all via these meetings, and that drives dialog which drives understanding. However, these benefits are not a given. Here are some things that need to be a part of the agenda to make the best use of this investment in time.

    • Have an agenda. This seems redundant, but every demo should have a plan. We want to ensure good discussion and avoid too much time spent on distractions or minor features.
    • Include regular set-asides for Q&A. Make it clear that feedback and discussion are a part of the plan and schedule time for it.
    • Provide a reason or story. A good solution will point back to the requirements and the problem definition. Each demo should be a step in the story from the whiteboard to solving the problem as defined at the beginning of the project.
    • Include more action and fewer screenshots in a demo. There should be almost no “talking through” steps and instead show the steps with inputs and outputs. This avoids possible confusion and ensures the resulting solution is a reality rather than smoke and mirrors.
    • Provide for an expanded discussion where needed. Some problems and challenges can take a lot of time to work through. A demo highlighting an issue should not be ignored or discussion constrained. Instead, provide a platform for full discussion and the best decisions to be made.
    • Avoid the firehose approach. Sometimes a lot of progress is made from one demo to the next. That can lead to information overload. Set the pace and volume of a demo so the audience can digest what they are seeing and provide timely feedback. A demo that is overwhelming in scope is more likely to miss details through sheer overwhelm.

    Remember The “Why”

    There are many benefits to these investments of time. However, we need to ensure we keep the reason for them in mind. Our goal is to show off progress and gather feedback. Thus, when we forget to make these a part of each meeting, we fall short of our goal. That limits our ROI and increases our chances for mistakes and even failure. Avoid this misstep and keep the team focused on what is expected of each meeting. The Agile Manifesto says it best when it points to the utmost goal of software should be to satisfy the customer. Use these tools to help ensure that remains the primary goal.

    Next Steps

    Feel free to schedule a time to discuss your next project with us. Every project we work on includes demos and similar discussionns on a regular basis. Often every two weeks and those include a release our customers can use to further test the features and get comfortable with the solution. We are happy to help you with investing in requirements and improving the overall success rate of software projects. 

    Our experience has taught us a lot about the pitfalls and challenges of custom software. Likewise, we have an e-book that can help you explore all the steps in building software, including a few templates. However, we ask that you share an e-mail address so we can send you a copy. We will add you to our monthly newsletter, but you can unsubscribe anytime. Your data is not shared with anyone else. Learn more about our book here.

  • Agile Patterns For Success – Team Work

    Agile Patterns For Success – Team Work

    I recently spent some time digging deep into the world of the Agile Manifesto and related methods for software development. This research included a look at agile patterns and anti-patterns. That is my focus in this article. There was an underlying theme that I kept coming across and do not see emphasized often enough. Spoiler alert, that theme is teamwork. There are many aspects of Agile that make it an effective way to approach software. However, the true power and ability to succeed comes from how it empowers the team.

    The Team Defined

    First, we need to be clear about how the team is defined in Agile. This is often the development team but can also include the scrum master and product owner. For our purposes in the article, we will focus on the development team. Many of these patterns make the entire team better. Nevertheless, I want to focus on the development team as they are the workhorses for our software project. These are the people that most impact success or failure when we build a solution.

    Unleash The Team

    It should be common sense that the biggest factor in any calculation is the one that becomes the largest focus. In sports, you hear about a player that “has to be stopped.” In politics and advertising, you hear about ket demographics. Businesses have flagship products and cornerstone customers. The odd thing is that we miss this concept when we consider teams. There may be an individual that is the most productive or effective on a team. However, the team is key, not just the individual. We have seen this played out in numerous contexts and multiple times over the years. Yes, a leader can make a sizable difference. On the other hand, most leaders are measured by how they motivate their team and increase productivity.

    The best leaders remove obstacles for their team. They reduce “red tape,” streamline processes, and empower team members. There is another way to view this. The best leaders unleash their team members to be the best team they can be. That takes us back to a focus on the team, not the leader. In case this example seems a bit abstract, managers are leaders.

    Professionals Are Professional

    The essential cog in the whole Agile Manifesto is that a development team is built of professionals. The members were hired because someone saw them as bringing value to the organization. Why would we throw that out once we place them on a team? It would seem to be common sense to trust these professionals to know how to do their job best. They know what their experience and skills are as well as where they work best.

    That leaves managers to listen to their staff and find ways to clear obstacles. It may seem trivial or lack glamour. On the other hand, it makes a statement that team members are valued as individuals. They are trusted to make the team the best it can be. Sure, there can be conflicts and a need for team members to learn how to work together. However, how often are we able to make other people like or trust each other? Managers are not miracle workers. Do not force employees into a hole. Let them define their role.

    Agile Patterns Are Not Suited For Everyone

    The second most important idea that needs to be understood in this pattern is that some teams are not suited to Agile. We need to have a team that has some experience, has self-awareness, and is driven to succeed. The team can develop these criteria as they go, but they need a starting point. A team full of similar or junior members will struggle. If there is not enough time for the members to branch out and differentiate themselves, Agile will not work. This concept goes back to that trust factor.

    When the team is trusted to “get the job done,” let them do the work. When you question whether the team can succeed, then do not burden them with Agile. They have to be able to make decisions and have confidence in those. Members that have no experience will rarely be able to do this. Instead, they will suffer from stress and lack of direction. Agile will be the worst direction to take.

    Agile patterns start and begin with the team. When you have a team that has the ability to over-achieve then turn them loose. Your trust and vote of confidence will be rewarded.

  • The Agile Manifesto – A Practical Look

    The Agile Manifesto – A Practical Look

    The Agile manifesto started an entire industry. It has even been the focus of numerous “religious” debates and arguments. However, it has a lot of wisdom within it that is often overlooked. The main ideas are as relevant today as they were when it was first crafted. Therefore, it is worth our time to review some of these wise nuggets and consider applying them throughout our software development efforts.

    The Manifesto Is Not The Agile Methodology

    We need to start by clarifying that the Agile Manifesto is not the same as the Agile Methodology for building software. The manifesto was used to create the methodology. However, they are not one and the same. Think of the methodology as an attempt to turn the manifesto ideas into reality. It is easy to see where many agile or extreme programming techniques got their start in the manifesto. Nevertheless, your opinion (and experience) of one may be noticeably different from the other.

    The manifesto came out of a desire to create better software. The first point drives that concept home. The highest priority is to satisfy the customer. This statement should be the “why” of any application and cannot be turned into a process. The Agile methodology provides a lot of ways to assist in this goal but does not guarantee it. Looking at it that way, we can easily see where a team could use Agile methodology precisely as described and still fail to deliver a successful project.

    Work As A Realist, Focused on Delivery

    There are twelve points the Agile Manifesto lays out.  These emphasize producing a solution the customer wants while acknowledging the realities of software development.  The most important of these practicalities, to me, is delivering results along the way to the final solution.  This process recognizes that customers often change their minds, communication problems exist, and showing is better than explaining.

    We all know there is often a disconnect between business representatives and technical resources.  The language does not always translate and skilled liaisons are in short supply.  Thus, we can lower the bar by deciding to be flexible from the start.  This approach is not a way to ignore requirements gathering, design, or other due diligence.  Instead, it assumes we will need to revisit those steps.

    The Manifesto Points

    Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

    Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

    Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

    Business people and developers must work together daily throughout the project.

    Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

    The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

    Working software is the primary measure of progress.

    Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

    Continuous attention to technical excellence and good design enhances agility.

    Simplicity–the art of maximizing the amount of work not done–is essential.

    The best architectures, requirements, and designs emerge from self-organizing teams.

    At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

    The Agile Manifesto

    Work Together For A Common Goal

     There are numerous rules of software development built into this manifesto that are needed for a successful product.  We already stated a focus on making the customer happy.  This statement is not arguable.  A product that does not please the customer is a failure by definition.  Another important concept that is woven throughout the manifesto is the Pareto Principle.  This rule says that 80% of our effort is spent in the last 20% of the product.  That means we can get “mostly there” relatively quickly. This focus on getting most of the way to the solution is highly valuable.  

    Let’s think about that a bit.  When you are almost done, you likely have a lot of the core functionality covered.  The “happy path” is complete and functional.  That is an essential factor in getting feedback.  You have a use for the product the customer can see and experience.  They have something concrete to assess and a solid basis for requesting changes.  

    Gaps In Knowledge

    It is not very different from taking a vehicle for a test drive.  You can get a feel for it and might even see some weaknesses.  This last factor is critical to the success of a product.  Customers should not be required to know edge cases and outliers in building a solution.  That is up to the developers.  However, these are issues that often fall into the “you do not know what you do not know” category.  When you provide a demo or partially complete solution, you give the customer a straw man to work with.  That is far more concrete and relatable than describing functionality or showing them a flow chart.

    Keep It Simple Somehow

    The focus on delivering regularly and the underlying Pareto principle ideas lead us to opportunities for the KISS approach.  It is amazing how often customers will scope out requirements to get working software in their hands sooner.  This carrot is dangled in front of them during regular demos and releases.  Yes, there are gaps.  However, a good relationship with a customer can lead to a shorter path to something they want and consider “done.”  Who would argue against that?

    Remain Flexible

    The last central theme I want to point out is the focus on change. When we create software, it is crucial to think about flexibility. We are not building a system to solve a specific problem and situation. Instead, we are trying to provide a solution that is useful in a broad range of configurations. The world is also constantly changing. Therefore, even though we can be assured of a need for new versions of our software, we need to be smart about it. A sound system is built with growth and change assumed. That means we need to prepare for it from the architecture through to each step of implementation.

    The Agile Manifesto has been around for many years. Nevertheless, it still is needed to remind software developers and teams of what is important. When we embrace these core concepts it reduces risk and improves our chances for success.