Kategorie: Agile

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.