Monat: August 2023

Veröffentlicht am

Coaching Tactics for Navigating Operational Challenges

In the dynamic realm of operational agility, where change is constant and demands are unrelenting, the integration of Agile practices might seem like a daunting task. However, it is precisely in these fast-paced environments that Agile principles can have the most profound impact. This post is a journey into practical coaching strategies, tailored specifically for a predominantly operational Agile team. We will explore how to seamlessly weave Agile methodologies into the fabric of daily operational tasks, while adeptly managing the rapid, unforeseen changes that are inherent in this environment.

Coaching an operational Agile team begins with immersing oneself in their world. This means acknowledging and appreciating the unique challenges they face. These teams are responsible for maintaining system availability, attending to customer needs, and managing complex technical upkeep. Within this context, Agile principles should be introduced not as a one-size-fits-all solution, but as a set of tools that can enhance efficiency, transparency, and the ability to respond effectively within this operational landscape.

Operational agility hinges on the team’s ability to adapt swiftly. When introducing Agile practices, emphasize their inherent flexibility. Begin with foundational Agile concepts and gradually introduce practices that align with the team’s existing workflow. It’s essential to recognize that not all practices might translate seamlessly and that some adaptations will be necessary to suit the unique operational nature. The heart of operational agility lies in striking a harmonious equilibrium between planned tasks and unforeseen work. An effective coaching strategy involves introducing techniques like Kanban, which offers a visual means of managing both planned and ad hoc tasks. The use of Kanban boards can help the team navigate ongoing operational work while remaining flexible enough to accommodate emergent demands.

In the operational sphere, decisions often need to be made swiftly. Here, Agile principles can lend a guiding hand. Teach the team how to apply Agile values when it comes to prioritizing tasks. Concepts like user stories or tasks can help visualize and manage their work, and the core principles of collaboration and customer focus can serve as touchstones in their decision-making process.

For operational teams, the daily huddle of a Daily Standup can prove invaluable. Encourage the team to hold concise daily meetings to discuss progress, challenges, and any adjustments necessitated by unexpected work. This practice facilitates real-time communication, alignment, and the ability to pivot plans on the fly.

Operational excellence thrives on constant improvement. After each work cycle, facilitate Retrospectives where the team can reflect on what went well, what could have been better, and how their processes can be refined. By embracing the concept of ongoing enhancement, the team not only fine-tunes their regular tasks but also becomes better equipped to manage the unexpected.

The multifaceted nature of operational work often requires diverse skill sets. Encourage cross-functional collaboration between team members who bring varying expertise, such as software development and technical maintenance. This interplay of different perspectives enhances problem-solving and fosters a shared understanding of operational complexities.

Operational landscapes are rarely static. Teach the team the importance of flexibility and introduce them to the Agile notion of committing to a certain amount of work within a specified time frame, rather than being beholden to rigid plans. This mindset allows for rapid adaptation without compromising on deliverables.

Coaching a mostly operational Agile team demands a nuanced approach that blends understanding, flexibility, and the intrinsic tenets of Agile methodologies. By seamlessly integrating practices that celebrate adaptability, collaboration, and perpetual learning, coaches empower these teams to navigate their dynamic surroundings while upholding the standards of operational excellence. In this harmonious convergence of Agile finesse and operational mastery, the team emerges as an agile force capable of not merely surviving but thriving amid the ever-shifting operational landscape.

Within the unpredictable currents of operational demands, Agile practices serve as a guiding star, steering the team towards equilibrium and mastery in an environment defined by its constant state of flux.

Veröffentlicht am

Success vs performance in agile software development

Agile software development is a popular and effective approach to software development that emphasizes collaboration, adaptability, and customer satisfaction. In agile, success is defined as the ability to deliver high-quality software that meets the customer’s needs, within the expected timeline and budget.

Success in agile software development is different from performance. Performance refers to how well the team can execute the development process, including how fast they can deliver new features and how efficiently they can resolve bugs and issues. Success, on the other hand, is measured by the impact of the software on the customer’s business, such as increased revenue, improved customer satisfaction, or reduced operational costs.

In agile software development, the primary focus is on delivering value to the customer rather than shipping a high number of features. This is because delivering functional software that meets the customer’s needs is ultimately more important than delivering many features that may not add significant value.

When developing software, it is important to prioritize the features that will provide the most value to the customer. This requires understanding the customer’s needs, identifying the most important features, and delivering those features as quickly and efficiently as possible. In some cases, this may mean delivering a smaller number of features, but ensuring that those features are of high quality and provide significant value to the customer.

By prioritizing value over quantity, the development team can ensure that they are delivering software that meets the customer’s needs and provides real business value. This approach can also help to reduce development costs, as it allows the team to focus on the most important features and avoid spending time and resources on less important or unnecessary features.

Another benefit of focusing on value over quantity is that it can lead to greater customer satisfaction and loyalty. By delivering software that meets the customer’s needs and provides real business value, the development team can build strong relationships with their customers and earn their trust and loyalty. This can help to ensure ongoing business and revenue opportunities for the organization.

Delivering high value to customers and measuring successcan be challenging, but it is essential for evaluating the effectiveness of the development process and identifying areas for improvement. There are several metrics that can be used to measure success in agile.

Customer satisfaction

Customer satisfaction is a critical factor in measuring the success of agile software development because it directly reflects the extent to which the software meets the needs of the customer. Agile software development is centred around the idea of delivering value to the customer, and customer satisfaction is a key indicator of whether this value has been delivered.

Measuring customer satisfaction involves soliciting feedback from customers and evaluating their responses to determine how well the software meets their needs. This feedback can take many forms, including surveys, focus groups, user testing, and customer support interactions. By collecting and analysing this feedback, the development team can gain valuable insights into the features and functionality that are most important to their customers and identify areas where improvements are needed.

Customer satisfaction is important for several reasons. First, it is a direct reflection of the quality of the software and the extent to which it meets the needs of the customer. If customers are satisfied with the software, it is a strong indicator that the development team is delivering value and meeting customer needs effectively.

Second, customer satisfaction is critical for building customer loyalty and ensuring ongoing business opportunities. Customers who are satisfied with the software are more likely to continue using it, recommend it to others, and engage in ongoing business with the organization. This can help to drive revenue and ensure ongoing growth and success.

Finally, measuring customer satisfaction can help to identify areas for improvement in the development process. By soliciting feedback and evaluating customer responses, the development team can identify areas where the software is not meeting customer needs effectively and make adjustments to improve the software and ensure greater customer satisfaction in the future.

Time to market

Time-to-market is a valuable indicator for success in agile software development because it reflects the organization’s ability to deliver software quickly and efficiently, which is a key goal of agile development methodologies. Agile development emphasizes the importance of delivering functional software quickly and frequently, with the aim of providing value to the customer as soon as possible.

By measuring time-to-market, the development team can evaluate how well they are meeting this goal and identify areas where improvements can be made. A faster time-to-market indicates that the organization can deliver value to the customer more quickly, which can provide a competitive advantage in the marketplace.

In addition, a faster time-to-market can also help to reduce costs and improve efficiency. By delivering software quickly, the organization can reduce the time and resources required for development, testing, and deployment, which can help to reduce costs and increase productivity. This can help the organization to operate more efficiently and effectively, which can lead to greater profitability and growth.

Business impact

A high business impact is an important factor for measuring the success of agile development because it reflects the extent to which the software is delivering value to the organization. Agile development is focused on delivering software that meets the needs of the customer and provides real business value, and a high business impact is a key indicator that this value is being delivered.

Measuring the business impact involves evaluating the effect that the software has on the organization’s key performance indicators (KPIs) and bottom line. This can include factors such as increased revenue, improved efficiency and productivity, cost savings, and customer retention. By measuring the impact of the software on these metrics, the organization can determine how well the software is meeting business objectives and delivering value to the organization.

A high business impact is important for several reasons. First, it is a direct reflection of the effectiveness of the software in meeting business objectives and delivering value to the organization. If the software is driving positive results and contributing to the success of the organization, it is a strong indicator that the development team is delivering value and meeting business needs effectively.

Second, a high business impact is critical for driving ongoing investment and support for the software development process. If the software is delivering significant business value, it is more likely that the organization will invest in ongoing development and support, ensuring that the software continues to meet evolving business needs and remain competitive in the marketplace.

Finally, measuring the business impact can help to identify areas for improvement in the development process. By evaluating the impact of the software on key business metrics, the development team can identify areas where the software is not meeting business needs effectively and make adjustments to improve the software and ensure greater business impact in the future.

In conclusion, a high business impact is an important factor for measuring the success of agile development. It reflects the extent to which the software is delivering value to the organization, is critical for driving ongoing investment and support for the development process, and can help to identify areas for improvement in the development process. As such, it should be a key focus for any organization that is committed to delivering high-quality software and providing value to their business.

The product manager is in the best position to deliver success metrics for agile development because they have a deep understanding of both the customer’s needs and the organization’s business objectives. As the person responsible for defining the product vision, strategy, and roadmap, the product manager has a clear understanding of the goals and objectives that the software is intended to achieve, as well as the features and functionality that are most important to the customer.

Because of this deep understanding, the product manager is uniquely positioned to identify and define the key success metrics for the software development process. They can work with the development team to establish metrics that are aligned with the product vision and strategy, and that reflect the value that the software is intended to deliver to the customer and the organization.

In addition to defining success metrics, the product manager is also responsible for monitoring and reporting on progress towards those metrics throughout the development process. They can use tools such as customer feedback, user testing, and data analytics to track progress and identify areas where improvements are needed and can communicate this information to stakeholders and the development team in a way that is clear and actionable.

The scrum master can also play a role in measuring performance and success by facilitating team retrospectives and identifying areas for improvement in the development process. The CTO may be responsible for setting high-level goals and objectives for the development team, but measuring success and performance should be the responsibility of the product owner.

In conclusion, success in agile software development is defined by the ability to deliver high-quality software that meets the customer’s needs within the expected timeline and budget. Success is different from performance, which refers to how well the team executes the development process. Measuring success can be challenging, but metrics such as customer satisfaction, time to market, quality, and business impact can be used to evaluate the effectiveness of the development process. The product owner is best positioned to measure success, but the scrum master and CTO can also play a role in evaluating performance and identifying areas for improvement.

Veröffentlicht am

How to apply product-led principles to modernize outdated software systems

Legacy software systems can be a major headache for organizations that rely on them to run their business operations. These systems are often outdated, complex, and difficult to maintain, making it difficult to keep up with modern software development practices. However, product-led development methodologies can provide a solution for modernizing legacy systems. In this article, we will discuss how to apply product-led principles to modernize outdated software systems.

Legacy systems refer to outdated software systems that are still in use by an organization. These systems are often built on outdated technology and lack modern software development practices. They may be difficult to maintain and upgrade due to their complexity and interdependencies. These systems can be a major roadblock to innovation and can cause major issues when they fail.

Product-led development methodologies can provide a solution for modernizing legacy systems. Here are some ways to apply product-led principles to legacy systems.

Start with Customer Discovery

The first step in product-led development is to understand the needs and problems of the end-users. This might sound easy at first because you already do have customers using your product. The problem will be to find out which problem your software is solving. Customers will be certainly able to tell you which feature set they are using, but the question to ask is: Why.

In the context of legacy system modernization, it’s important to understand how the legacy system is currently meeting the needs of the end-users, what are the current pain points, and how they would like the system to be improved. This information can help guide the modernization efforts and ensure that the end-users’ needs are met.

This can be done through various user research methods, such as surveys, interviews, or usability tests.

Define Clear Goals and Priorities

Clear goals and priorities should be defined for the modernization project. The goals should align with the overall business strategy and consider the limitations and constraints of the legacy system. It’s important to prioritize the needs of the end-users and ensure that the modernization efforts are focused on providing value to them. Clear goals and priorities help to ensure that the modernization project stays on track and that the efforts are focused on the most important areas.

Leverage Agile Development

Agile development is an iterative development process that focuses on delivering small, incremental changes. This approach can be applied to modernizing legacy systems by breaking down the system into small, manageable pieces and focusing on one piece at a time. Agile development helps to ensure that the modernization efforts are focused, and that progress is being made in a timely manner. It also helps to ensure that the modernized system is meeting the needs of the end-users.

This step might be the biggest change for your customers. In an agile approach your customer is heavily involved in the whole development process as they know best if your product is solving any of their problems. Very often this expanded customer interactions is new for both the software developers and the customer. But the change will be worth it, as you gain understanding of the customers problems, and your customers trust in solving them.

Measure Success with Metrics

Metrics are used to track the performance of the product and the impact it has on the end-users. This approach can be applied to modernizing legacy systems by setting up metrics that track the impact of the new features or designs on the end-users. Metrics can help to ensure that the modernized system is providing value to the end-users and that the modernization efforts are on track. They can also help to identify areas for improvement and guide future modernization efforts.

Product Lifecycle Agreement

The product lifecycle strategy for legacy products in a product-led development involves managing the product from its introduction to the market to its eventual end-of-life (EOL) phase. Legacy products are those that have been in the market for a long time and may no longer be actively developed or maintained but are still in use by a significant user base. Managing the product lifecycle of legacy products is essential to ensure that they continue to meet user needs and evolve with changing technologies. While the lifecycle of a product generally includes introduction and growth phases the focus for legacy products will be on the maturity and end-of-life phase. In the maturity stage, the product’s growth slows down as it reaches its peak level of adoption. The goal of this stage is to maintain the product’s market share and profitability by focusing on cost reduction and efficient production. During this stage, product development may be focused on maintaining the product’s reliability and stability, as well as addressing any compatibility or security issues that may arise. In the end-of-life stage, the product is no longer actively developed or maintained, but may still be in use by a significant user base. The goal of this stage is to manage the product’s EOL in a way that minimizes disruption for users and maximizes the value of the product for the company. During this stage, the company may consider offering support and maintenance services to existing users, as well as providing recommendations for alternative products or upgrades.

It is important to have a transparent and well communicated (for developers as well as customers) product lifecycle plan. For legacy products it is very important to have and idea of the end-of-life. Without a clear end-of-life strategy customers will either request innovation and change on a product you cannot maintain any more or just leave your product portfolio at all because the market will easily overtake you.

Product-led development can provide a solution for modernizing legacy systems by focusing on the needs, desires, and problems of the end-users. Starting with customer discovery, defining clear goals and priorities, focusing on leveraging agile development, and measuring success with metrics can all help to ensure a successful modernization project. By taking a product-led approach to legacy system modernization, organizations can become more efficient, reduce costs, and stay ahead of the competition.

Veröffentlicht am

Quality Assurance vs. Quality Control in Scrum

Quality in software development is not just a nice-to-have; it is a fundamental pillar that underpins the success and reputation of any software endeavour. From ensuring customer satisfaction and loyalty to reducing costly defects and maintenance efforts, the pursuit of quality remains a core objective for every software development team.

In pursuit of this goal, two crucial approaches come into play—Quality Assurance (QA) and Quality Control (QC). Although often used interchangeably, they represent distinct aspects in achieving the common objective of excellence in software development. In this blog post, we will explore the differences between QA and QC in the context of Scrum and shed light on how they complement each other in creating exceptional software products.

Quality Assurance (QA) in Scrum

Quality Assurance in Scrum revolves around prevention-focused activities. It aims to embed quality into the development process from the very beginning. QA starts during the early stages of product development and continues throughout the project’s lifecycle. Here are some key characteristics of QA in Scrum

  • Defining and adhering to standards: QA establishes clear and agreed-upon standards for development, testing, and documentation. These standards serve as guidelines that the team follows to ensure consistency and quality.
  • Process improvement: QA involves continuous process improvement efforts to identify inefficiencies, bottlenecks, and potential areas of improvement in the development process. Regular retrospectives play a vital role in this aspect.
  • Training and skill development: QA emphasizes skill development and training for team members to enhance their abilities and ensure they possess the necessary expertise to deliver high-quality products.
  • Early defect prevention: QA activities focus on identifying and addressing potential defects as early as possible in the development lifecycle. This helps in avoiding costly rework and increases overall productivity.

QA can be summarized as Process-Oriented, Prevention over Detection and Documentation and Training.

While the primary focus of the Scrum Master is to facilitate the Scrum process and remove impediments, they also contribute significantly to the overall quality of the software product through their involvement in process improvement and fostering a culture of continuous improvement. Here’s how the Scrum Master plays a role in quality assurance. The Scrum Master encourages the team to adopt a quality-centric mindset. They promote the understanding that quality is everyone’s responsibility and not just the concern of the Quality Assurance or Testing team. The Scrum Master emphasizes that delivering high-quality software is crucial for long-term success.

The scrum masters involvement in retrospectives, advocating for Definition of Done, and removing impediments contributes to the overall quality of the software product and the team’s ability to continuously deliver value to customers.

Quality Control (QC) in Scrum

Quality Control in Scrum, on the other hand, centres around detection-focused activities. It involves verifying that the deliverables meet the predefined standards and requirements. QC activities occur at various stages of the development process, with the primary goal of identifying and fixing defects. Here are some key aspects of QC in Scrum:

  • Testing and validation: QC encompasses various testing practices, including functional testing, integration testing, regression testing, and user acceptance testing. These tests are designed to verify that the product meets the desired functionality and quality standards.
  • Defect identification and management: QC involves actively searching for defects, tracking them, and collaborating with the development team to resolve issues promptly.
  • Review processes: Peer reviews, code reviews, and design reviews are part of QC efforts to ensure that the developed product aligns with the established quality criteria.

QC can be summarized as product-oriented, defect identification and correction as well as validation and verification.

Es wurde kein Alt-Text für dieses Bild angegeben.

Balancing QA and QC in Scrum

Both Quality Assurance and Quality Control are integral to maintaining a high standard of software quality. To achieve software excellence in a Scrum environment, it’s essential to strike the right balance between these two approaches.

QA and QC should be viewed as complementary rather than competing forces. Implementing robust QA practices reduces the likelihood of defects, thereby reducing the amount of time and effort spent on QC activities. Conversely, effective QC practices provide valuable feedback to the development team and contribute to continuous improvement efforts in QA.

Establish valuable QA and QC

Actions for Valuable Quality Assurance (QA)

  • Define Clear Quality Standards: Establish and document clear quality standards, including coding guidelines, design principles, and testing criteria. This ensures that everyone on the team understands and follows a common set of quality guidelines.
  • Implement Code Reviews: Encourage regular code reviews among team members to promote collaboration and identify potential issues early in the development process. Code reviews help catch bugs, improve code readability, and maintain consistent coding practices.
  • Conduct Regular Knowledge Sharing Sessions: Organize knowledge sharing sessions where team members can present best practices, lessons learned, and new techniques. This fosters a culture of continuous learning and ensures that the team stays updated on the latest developments in the industry.
  • Invest in Test Automation: Develop and maintain a suite of automated tests, including unit tests, integration tests, and end-to-end tests. Test automation improves test coverage, identifies regressions, and allows faster feedback on code changes.
  • Prioritize Test-Driven Development (TDD): Encourage the adoption of Test-Driven Development, where developers write tests before implementing the code. TDD helps in focusing on requirements and ensures that test cases are closely tied to the desired functionality.
  • Implement Continuous Integration and Continuous Deployment (CI/CD): Implement CI/CD pipelines to automatically build, test, and deploy code changes. This minimizes integration issues and accelerates the delivery of features to end-users.

Actions for Valuable Quality Control (QC)

  • Perform Comprehensive Testing: Conduct various testing activities such as functional testing, regression testing, performance testing, security testing, and user acceptance testing. Rigorous testing helps identify defects and ensures that the software meets user requirements.
  • Track and Manage Defects: Use a robust defect tracking system to document and manage identified issues. Prioritize defects based on their severity and impact, and ensure timely resolution.
  • Implement Exploratory Testing: Encourage exploratory testing, where testers explore the software with an open mindset to discover hidden defects and usability issues that might not be covered by scripted tests.
  • Engage in Bug Bashes or Bug Hunts: Organize bug bashes or bug hunts where the entire team collaboratively tests the software to find as many defects as possible within a specific timeframe. This can help identify critical issues and foster a sense of shared responsibility for quality.
  • Conduct Root Cause Analysis (RCA): Whenever a significant defect is discovered, perform a root cause analysis to understand the underlying reasons for the issue. Use the findings to prevent similar issues from recurring in the future.
  • Encourage User Feedback: Gather user feedback through surveys, user interviews, or usability testing. User feedback provides valuable insights into the software’s usability, functionality, and overall quality.
  • Incorporate Test Environment Management: Maintain well-configured and consistent test environments to ensure that testing accurately represents the production environment and avoids discrepancies.

In the context of Quality Control (QC) activities, the Scrum Master plays a critical role in facilitating and supporting the team’s efforts to ensure product quality. While the primary responsibility for QC lies with the Development Team, the Scrum Master helps create an environment conducive to effective QC practices and collaborates with the team to address any impediments that may hinder the quality control process.

Veröffentlicht am

Misconceptions at the beginning of an agile transformation

In software development the introduction of scrum is primarily a management decision, and luckily developers mostly welcome this change as they expect to have more participation and freedom in what they are doing. But at the beginning of the transformation from a waterfall project to an agile development the management still sticks to some antipatterns which are crucial for an agile success. In this article I address the misconceptions you might face in the agile transformation.

Roadmap Adjustments

In a non-agile development management creates a feature roadmap and estimates which resources are needed and how much time they would spend. In most cases this does not work very well as managers estimate effort based on how good they are able to sell the features instead on how much effort it might take to actual develop it. One important aspect of changing to an agile development is, that the development teams are going to estimate the effort.

After the decision has been taken to let the development teams working the agile way, the roadmap and its promised delivery dates are often unchanged. Customers still got the old due date. Companies fear, that if their agile teams need to act to re-estimate the roadmap, they will get another result and must communicate new delivery dates, but agile working has mostly been introduced because the management estimations did not fit the actual effort. Hence it is essential for companies to recheck any roadmap and delivery dates at the very beginning of the agile transformation.

…

Agile departments

The transformation of a company to work agile is easiest if started with development, as there is the biggest impact. However, companies tend to think that working agile is restricted to the development department and it might be enough if other departments are informed about the change without a plan on how the change influences the work between the department.

So it might be that the sales department is still selling waterfall projects and do not even offer to work agile with the customer, as they not informed thoroughly about the differences and advantages of an agile customer project. Companies tend to think that agility stops at the development, but it really needs to go all the way, reaching everybody in the organisation.

The scrum master as facilitator of the agile transformation within the scrum team and beyond needs to be enabled to fulfil this task. If this need of the scrum master role is accepted within the company the agile transformation started with the development will make it to the whole company.

Be brave

Starting the agile transformation within the development is the easiest way, but this is just the beginning. Getting all the advantages agility can deliver companies need to be brave enough to transform in total.

Veröffentlicht am

5 essentials you should consider when writing a user story.

In software development a user story is a request to change or add behaviour to the product. Although the scrum guide does not mention user stories, they are widely considered as being part of the agile software development. Writing good user stories is a key aspect of delivering high value to the customer. Investing time in writing a good user story leads to spending less time in the development phase and is therefore simply a matter of cost. In this article I will give you five essential hints to write better user stories and therefore to ease the delivery of high value to your customer.

Who writes user stories?

Although it is the responsibility of the product owner that a backlog of user stories exists the product owner is not the sole writer of stories, a user story can be written by anyone.

Therefore, the given hints should be followed by everybody who feels the need to contribute to the products increment.

1. Write the story from user perspective

The software that you are going to deliver is for some user. Hence what is closer than to write the desired change from that user’s perspective. It is therefore needed that any story writer truly understands how a user interacts with the current increment as well as the user might interact with the future increment as well. Consequently, it is essential for a story writer and especially for a product owner is to get in contact with their users and their customers.

As a user might not be available at any time a helpful tool might be so called personas. A persona is a virtual user of your product which somehow shows a stereotype[1]. Use these stereotypes to identify different types of users and their different needs. Personas are a good starting point to understand the audience of your product.

[1] https://medium.com/beakerandflint/personas-74c4e1c12ee2

2. Write stories collectively

In the software development work, pair programming is known to deliver high quality implementations as there are four eyes looking at the changes done. The interaction and the exchange of ideas as well as critical thinking about the work of others on the go really puts some focus of the outcome (rather then the output). This kind of collaboration can be easily adopted to story writing as well. Having two writers instead a sole person, will boost the creativity of the story creation process and will lead to a well thought story, looking at aspects of the story a single person could not even imagine.

3. Don’t stick to the happy path only

In the creation of a story the writer might think about what a user wants to achieve by using the desired function. The writer describes the happy path in which the user is going to do all necessary steps correctly and in the correct order. Additionally, all preconditions are set correctly. Sadly, this will never reflect the real world. In the real world what can go wrong will go wrong. Thus, the unhappy path of working with the product needs to be part of the user story as well. Describe what needs to happen if the user did not meet the preconditions or even what might happen if the product itself did not react as you expect.

  • What should the error message contain?
  • How should the product behave in case of an unexpected error?
  • Which options did the user have in case he made a mistake?

4. The user story is the main input for QA

An important part of product development is quality assurance[1]. Within the quality assurance the development team checks whether the implementation matches the needs of the user. These needs are written down as part of the user story. Surely the product knowledge can be used as an entry point for quality assurance, but it needs to have some “truth” to compare to. The user story is an essential source for this truth.

Therefore, the QA process does not start at the end of the life cycle of a product change but already in the process of creating the user story. This guarantees to not only deliver quick and frequent changes to the user, but real value that can make the users life better.

[1] https://medium.com/p/9fabd1f6c66e

5. Technical details should be added by the developer

As already mentioned, writing the user story is not the sole responsibility of the story writer nor the product owner. It is truly essential that the story is complete and understandable by anybody when you start implementing it. That means that the development team needs to contribute to the story. In many cases the development team knows their product very well and get help to deliver the best value to its customers.

But as already said, the user story is written from a user centric view and needs to be understood by anybody in the chain of product delivery. This concludes that too much technical details should not be part of the story itself. Also, it is not in the responsibility of the story writer nor the product owner to deliver the technical details needed to implement the story.

Technical details are surely needed to implement a story correctly, but they are not part of the story itself. They should be added as part of a task. A task beneath the story is the right place to note the details needed for a good implementation. A story describes what is needed. The task beneath describes how it can be done.

Veröffentlicht am

Failing to Create Value: Antipatterns That Hold Back Agile Teams

Scrum is known as a framework that ensures the important things to be done first. It is often introduced in companies where different approaches of prioritizing the next workable item did go wrong. Scrum is often seen as the savoir in this scenario as it should deliver the right stuff each sprint. But more than often the same mistakes about the prioritization of workable items are done in scrum the same way as it is done in other approaches. This article describes four antipatterns regarding the prioritization.

Multiple Priorities

In Scrum the sprint backlog is ordered in a sense that if the team completes the topmost sprint backlog items the value that will be delivered has been maximized. This means that each team member should focus on completing these top items.

If each team member does have a different priority to work on, they counteract against creating the maximal value. Hence if a dev is stuck on for example the first item in the sprint backlog and asking for help, answering that one is having other priorities it is not the valuable items that are done within the sprint but the personal priorities of the dev.

Naturally, the developers do not produce a priority on their own. Multiple priorities come from multiple sources of priority. It is not the sole priority of the sprint backlog that is taken into consideration but mostly the priorities are pushed into the team from somebody else, sometimes even the product owner. Any scrum team should speak out against multiple priorities as they reduce the chance of delivering the right things first.

Es wurde kein Alt-Text für dieses Bild angegeben.

Teams outside the scrum team

The development members of a scrum team might have more responsibilities than being a fulltime developer for the team. Developers may only be half of their time available to work on sprint backlog items and need to undergo other tasks in the rest of their time. This becomes a problem if the workload about these different responsibilities is not transparent for the team, as it if often the case, or team members are totally underestimating the effort for their side quests.

Team member might even be part of another team or taken into urgent task forces during a sprint. Having obligations in different teams at the same time and the urge to fulfil both obligations will lead to not being able to focus on any of the work that needs to be done.

Development tasks a team can handle should always be executed by the team itself and within the planned sprint. Do not take development members temporarily out of the team to do something that seems more important. Let the team handle it.

Additionally, any task outside of the scrum need to be transparent and preferably consistent over time. This makes sure the team does have a good understanding of their skills and their capacity for a sprint.

Disregard the sprint backlog order

Scrum master notice that developers are working on sprint backlog items that do not have top priority even if the workable items at the top have not been finished. As described in the first section having multiple various sources of priority could lead to not focus on the workable items at the top.

Sometimes it is even due to personal preferences, skills and sometimes even convenience. Scrum master need to take action against this. Make clear that the sprint backlog is the only source of priority. Therefore, the product owner needs to know about the external priorities of any item. This way, he even might consider the product backlog item as important enough too and accepts that the developer is working on these items. If this is not the case, you need need to convince people to work in the top items first. Scrum master can help developers as well as the company to understand the process of creating value.

Tasks in progress > Developer

Having more product backlog items in progress than you have developer within the scrum team is an unmistakable sign of not focusing on the most valuable items in your sprint backlog. This might have distinct reasons. Sometimes developer do need some more information about a feature they have started developing. Sometimes they need to wait for technical impediments to be solved. Sometimes it is also due to personal preferences, skills and convenience that developer tend to start working on a new product backlog item even if others have not been finished yet.

Take care that every sprint backlog item is clearly described and did not need any more information to be started. If information is needed anyway developers should actively try to get this information and should not wait that the information is somehow finding its way itself.

If developers are regularly waiting due to the same technical impediment this needs to be observed and removed in the future. Impediments that need to be removed from the team could be a good topic for a scrum retrospective. It provides the possibility to deeply talk about the root cause of the problem and find a solution for it.

Veröffentlicht am

Onboarding team rookies the scrum way

As stated in the scrum guide a team is “is a cohesive unit of professionals focused on one objective at a time, the Product Goal[1]”. But people working together on the same goal does not make a team in a sense of effective collaboration. To get a team to a certain level if effectiveness it needs more. The team member should know what everybody is able to do and what team members can’t do. They should have trust in a sense that everybody is able to deliver value for the team. It needs knowledge about the preferred way of communication and knowledge what drives team member to perform in a sustainable way. And to get everything that is needed it needs foremost stability in these cohesive unit of professionals. If team members are exchanging the stability is lost and it needs time for everybody to get back to trust, knowledge and understanding of each other.

Nevertheless, it is in the nature of teams that team members might leave the team, while others are going to join. In the recent months I have I’ve seen a bunch of changes on the organisational level of teams as well as constant changes within scrum teams. In this article I’ll focus on the challenges of onboarding new development member in a scrum team and how the team tackled these challenges based on the five scrum values Commitment, Focus, Openness, Respect, and Courage[2].

Tackle the challenge

The biggest challenge for new team members is within the past. New team members did not participate in all the different discussions and decisions the rest of the team did to continuously improve themselves. All the little team rules that came up the last couple of months are not aware for the team rookies. Additionally, the team has built up some gut feeling about their own processes like quality assurance, the need of pair programming on certain topics or the estimation of story points. Each inexperience is small but together they sum up to some bigger friction.

Courage

“The Scrum Team members have the courage to do the right thing, to work on tough problems”

Onboarding a new colleague can be a tough problem. So many things to teach, and you want to get the team back to performance as soon as possible. Even if your team has been very stable in the past (Congratulations !), any of the team members has been in the position of being the rookie in the past. Hence the team can help a lot regarding the onboarding plan. The team should have the confidence and the courage that they know best what is needed. Give them time in advance and they will to the right thing to have the new members as part of the team as quickly as possible.

Commitment

“The Scrum Team commits to achieving its goals and to supporting each other.”

Talking about commitment to a goal people tend to think at the sprint goal and delivering value in a sprint. You should not lose sight of delivering value, but the value might get a little smaller while you onboard new colleagues. The team still commits on their goal which is to get the team member on board. This might not deliver value to the product you develop directly but a commitment to get everybody on board is a commitment to value in the long run (even for your stakeholders).

Focus

“Their primary focus is on the work of the Sprint to make the best possible progress toward these goals”

You got your team to have the courage to make a decision about the onboarding plan themselves, and you got the commitment that the onboarding is part of the sprint delivers some value for your stakeholders. As you might have already experienced stakeholder will try to get some pressure on the team and on their team members as well to deliver the task that they like to see with priority. This is regardless of the onboarding situation. But especially during the onboarding it needs a lot of focus on the task of getting the new team member into the team. The onboarding should be the task with highest priority within a sprint and everybody needs to focus on achieving this task soon. There is no possibility to postpone the onboarding to a later date.

Openness

“The Scrum Team and its stakeholders are open about the work and the challenges”

Onboarding is not a task as any other task. The people to onboard need a different attention than a software change. The value added cannot be determined as easy as for a software change and additionally you might react even more agile with people than you do with software. Nevertheless, it would be best to be open about the change in the team, the impact on the next sprints and the team’s velocity. Tell your stakeholder about the onboarding and make the effort it takes to gain domain knowledge and team process transparent to everybody.

This is where the team members need to change their focus from developing and start focus on onboarding the new colleagues.

Respect

“Scrum Team members respect each other to be capable, independent people, and are respected as such by the people with whom they work.”

Respecting other people seems to be obvious to most people. Nevertheless, it cannot be emphasized often enough. The team should be convinced that the new member will be a possibility to improve the team even more. Make sure that everybody is aware of the possible team backdrop in the short run, as it needs some effort for the onboarding. If team members know this, and stakeholders are aware there is less pressure and therefore more time to acknowledge the growing diversity of the team.

[1] https://scrumguides.org/scrum-guide.html#scrum-team

[2]https://scrumguides.org/scrum-guide.html#scrum-values

Veröffentlicht am

Delivery vs. Discovery: Finding the Right Balance

The development teams I am pleased to care about work either in Scrum or Kanban. All of them started working in Scrum, and some decided to move to Kanban instead (see also https://medium.com/@timhartnack/from-scrum-to-kanban-in-90-minutes-b3b6af4a7b0f).

Based on this experience I got asked which framework is the better to use for software development teams. The short answer: “It depends”. The rest of this article will give you some view on the insights I made.

Before I begin describing my experience in using either Scrum or Kanban, I like to point out that none of the frameworks is better than the other. Both should be used to face the problems and businesses needs you currently encounter.

At the very beginning of the business transformation to work with agile teams the teams have been told by management to use scrum to organize their daily work. As this top-down approach might not be the best, nobody in the company did have a deeper experience. Hence it was a good idea to undergo the first phase of change in this direction. The development teams did not really have a product to deliver but doing multiple unrelated customer driven changes to the existing product. Although this is not the ideal scenario for using scrum starting with a given framework worked out well. Also we had the possibility to train the way we work and using the “inspect and adapt” idea of scrum to questioning the way we work. This way we could learn about ups and downs of the framework in use.

After some teams moved to use Kanban instead of Scrum, we kept having a retrospective meeting every two weeks. This way the rear view of what happened for the bad and what happened for the good did stay within the DNA of the team.

Scrum did not fit all

While the scrum teams did not do product development by the book but customer changes instead, they struggle with the sprint goal in scrum a lot. The task that needed to be done were given at the sprint start and did not complete to a visible goal. Instead, the goal has mostly been to implement all task given the fastest way possible (but not without looking at quality). Additionally, the task to perform have been planned long ago already as the changes have been promised to the customers.

Delivery vs. discovery

As the teams face the problems described I got the first contact of a main difference between Scrum and Kanban.

Its the difference between discovery and delivery.

Scrum is a framework to discovery the most valuable change in a product. Of course, you need to know the challenges of your customers and which of them your business can solve. The solution to the customers problem instead needs to be discovered by any of your product teams. Scrum allows you to have short iterations to work on this solution in close coordination with any stakeholder. This way you thrive to implement valuable change to the product the customer can use.

Use Scrum to discover the next product change. You might not change the product the way the customer wants it but the way the customer needs it.

In the past I had the possibility to support the development teams in a big modernization project. The goal of this project has been to transform the functionality which has been highly accepted by the customer into a technological future. In such a scenario most software features are predetermined. This means that you know in advance what you should implement and in which order. This does not sound as you need to discover anything as you already know how the product should look like. This can be seen as some sort of iterative waterfall process. You did not plan the new project in any detail from the beginning, but you know the order of the high-level parts. As you refine the features in detail the development teams can already start developing. Kanban is a framework for delivery, as the team is working on the task with highest priority with expected high throughput.

Use Kanban to deliver the predetermined product changes. You get the already known features in a very fast manner.

The experience I’ve gained of the last years tells me that you should not stick to a given framework because someone told you to use it. As an alternative use the inspect and adapt idea working agile gives you to challenge the framework from time to time. Encourage your team to adopt to the given scenario and explain management the pros of using the right framework for the current scenario.

Veröffentlicht am

Quality is negotiable

People in software development often say that quality is not negotiable. But this is not true.

Not negotiating is not discussing quality and you need to discuss the level of quality that is needed and how to achieve this level every day. If you do not discuss quality everybody does have its own perspective on it. The discussion needs to happen on all levels of a company. Take the sales department. Their job is to sell features, not quality. Look at customer support. They want less features to support, but more quality, as poor quality makes their live a mess. Developer themselves want quality for each new feature but face the problem to also need to provide quality for some old legacy features they do not own. This shows that company departments might have different requirements on quality. Hence quality is not only negotiable. You have to discuss and negotiate it every day.

Negotiate on company level

To have a common understanding of the level of quality you want to achieve, this quality topic needs to be addressed on a company level. The requirements to quality and the cost it has need to be transparent in every department. Sure, sales want to sell features. But if these features do not work properly, they will not sell a second feature to the same customer. The customer support wants to have features to work properly only, but no new features will make them lose work. Quality does have a cost and return of investment. This and the different needs of everybody should be communicated well to let management decide the proper company needs of quality assurance.

Es wurde kein Alt-Text für dieses Bild angegeben.

The testing pyramid often has its base at unit test level. But to work properly it needs support by a clear and well communicated quality requirement.

Negotiate on software developer team level

Developers need to know what they should deliver. If they are told “quality is not negotiable” developers need to do what ever it takes to prevent any bug. It might include refactoring old the old legacy code. This means that any new features might take an eternity to develop. If developer know what is expected, they can negotiate on how to achieve the expected level of quality within the team

In any software development team, the first step of negotiation should be the definition of done (DOD). The DOD defines what it needs for a feature to be finished. Which tasks should the team perform, and what checks need to be done. If this is not negotiated and therefore not known to anybody, the team will not be able to deliver a sustainable level of quality and each feature implemented might contain an expectation gap. A team DOD might contain something like the following:

  • all acceptance criteria are met.
  • new code is secured by an automatic test (unit test, integration test, UI test).
  • four-eye principle: Code has been reviewed and understood by at least one other developer (Code review or pair programming).
  • Code guidelines for the components (server, client, mobile…) are met.
  • No new linting or compiler warnings exist (depends on component type).

This example is part of the DOD of one of my teams and it shows the result of an intensive discussion between all members of the development team (product owner, software developer, quality experts). Having a DOD written down is needed, but the negotiation does not stop here. For each new feature product owner, software developer and quality experts need to discuss the quality or testing strategy. Which kind of automatic tested is needed? Which edge cases need to be tested? The discussion about the testing strategy does not only impact the proper quality of the product but also the speed of development for this and upcoming features. Additionally, the four eyes principle stated in the example DOD is nothing else than a negotiation about quality. At least two developers discuss for each feature if the unit tests are suitable, the coding guidelines are kept and if the overall code quality has been increased (boy-scout-rule). They might even discuss to remove an automatic test if it does not suite any meaningful test case but increase the effort of maintenance and the performance of the overall test run.

To achieve the right balance between working software and pace of development the whole company needs to be involved in the negotiation of quality. Quality is not an act. It’s a habit of negotiation.