Autor: timhartnack

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.

Veröffentlicht am

Why Quality and Innovation Suffer in a Feature Factory Approach

In successful software development is it widely accepted that the best outcome is produced by autonomous development teams having their own product and a clear target. This means that a successful software development team can find out and to decide about how to change the product to deliver real value. The team’s product might be part of a bigger solution, but the team does not need to share the product with another team to reduce dependencies. They also have a clear product goal (could be addressed using OKR). This way a team feels responsible for their work and will deliver high quality features that meet the need of their products customers.

In contrast a lot of software development team are primarily feature factories. As a feature factory the team has little to no influence on the product as the product decisions are made by managers outside of the team. For a feature factory team, the output is more important than the outcome. Managers do not really ask the team to deliver features the team thinks the customer needs. Instead, they ask the team to implement the feature in the pace the manager estimated.

…

Less quality

One of the main difficulties of software development is delivering software of high quality. You can deliver cheap software with a high pace. Customer might buy it, but they will not stay if your product lack of quality. If you want a team to deliver quality, you need to get the team feel accountable for what they produce. In a feature factory where the team merely does what they have been told to do and not what they are convinced to be the right thing, the team will hardly deliver quality. The work produced will just be the output of the requirement. It will not be an outcome of high quality.

Less innovation

If a company uses its development teams solely for coding, they drop a big part of the possibility to innovate. Today, technology is at a point where customers can hardly imagine what is possible within the product. Therefore, engineers are a big source of innovation as they know what can possibly be done. In a feature factory environment, the development team has little influence on how the product evolves. The product change will be decided outside of the product team. In this case a company will not use the innovative potential a development team can deliver.

Less efficiency

The highest cost in product development is the work on production ready code. The more you can make sure that what you are going to build really is what will be needed afterwards the more time and money you save. A feature factory leaves out the part where the team is going to focus on what really will match the needs of a customer and will deliver a real value to the product. A feature factory team focuses on the forecasted output instead of the outcome. They need to deliver something fast instead of delivering the real thing a bit slower. Hence you do need more iterations to match customer needs, or you need to live with unhappy customers.

Less responsibility

We need teams of missionaries, not teams of mercenaries.[1]

Developing a product which fits the market you need teams of missionaries, not teams of mercenaries. If you give the decision about the product to the team, they will feel responsible for the product. A team that feels responsible for what they deliver will deliver a high-quality product. They will deliver you the innovation that is needed to stay ahead of your competitors and they will work efficiently as they focus on coding what is really needed and what really creates value.

Mercenaries will leave the team as soon as there will be any problem. Missionaries will stay with you through thick and thin times.

A feature factory team will maybe follow the directions given by managers, but they will not feel the pain of customers as well as colleagues. They just do what they’ve been told. No more, no less.

[1] https://www.svpg.com/missionaries-vs-mercenaries/

Veröffentlicht am

From Features to Outcomes: Why to Build a Outcome Based Product Roadmap

Managers want to make sure that everybody knows what the top priority is.

I can totally share this need as it is crucial to know what is currently important. The first reflex is often to create a roadmap, which contains the most important projects of the future in a particular order. But a product roadmap does not only address the goal to know what is important now, but also what will be important after the first item and even what will be important in a couple of months.

Additionally, to knowing what will be important in the future you also plan how to solve the problems of the future with your current knowledge. This suggest that you do not only have an idea what will be important in a couple of weeks but also how to tackle the problems of the future as classical roadmaps do not address the upcoming challenges but solutions instead.

The problem of planning solutions ahead is that you cannot be sure that these solutions really match the problem. Hence with finishing the roadmap item you can totally celebrate releasing it, but you have no idea which problem is solved now. Without knowing which problem has been solved you cannot be sure that you have created any value. I prefer knowing the problem to solve instead of having a solution.

Instead of using a roadmap full of assumptions of solutions, the better idea would be to have a roadmap full of problems you want to solve in the future. This way you can make sure everybody can focus on solving the most urgent problem.

In his must-read book “Inspired” Marty Cagan says that such an outcome-based roadmap is “is all about solving problems, not implementing features” [1].

An outcome-based roadmap does not state the next feature to implement but the next problem to solve. This way you do not only create real value, but you also have a possibility to measure your progress. Instead of measuring the delivery and accept upcoming work to get the feature to its full potential, you can be sure to deliver value from the very start.

Hence instead of planning to have a newly styled onboarding page you should rather plan to achieve an increase of new customers, more customer satisfaction in the onboarding or easier onboarding for people with disabilities. That gives you and your team the chance to achieve the goal in the most propriate way and the most suitable technology available. Furthermore, you can easy check if the implementation you have chosen did have any impact on your goal. Instead of celebrating the release of a feature you can celebrate the increase of new customers. Which goal looks more valuable to you?

In the phase of transition, it is tough to move from a classical project roadmap to an outcome-based roadmap in just one big step. But if you are looking for a low hanging fruit to the approach you can easily write down the purpose for any planned roadmap item. You can then use the known planning approach of a classical roadmap with additional goals to achieve and move slowly to an outcome-based roadmap.

One of the key benefits of an outcome-based roadmap is that it helps to align the product development efforts with the overall business goals and strategies. By focusing on the desired outcomes, teams can make sure that they are working on the most important and impactful areas of the product. It can also help to ensure that resources are being used effectively and efficiently to achieve the desired outcomes.

Additionally, it gives everybody on the company to fully understand why their work has an impact to the overall goal.

[1] Marty Cagan, INSPIRED: How to Create Tech Products Customers Love