Peter Gfader

In the last “Ask a Professional Scrum Trainer” episode I got a question that was not answered during the session. We discover Non Violent Communication, good coaching questions and patience as key Scrum Master skill.

What is the best way to address recurrent problems that are identified at Retros? Those ones that you actually spend a lot of time trying to overcome but eventually come up again.

Do You build "It Right" and at the "Right Time"?

Every company has customer focus in its vision or mission statement, but is it really? As an employee of a development team, how do I know if this is the case?

Often we work harder in Scrum teams, but not necessarily smarter. Therefore the way we work has to change. Five tips for more effective agile work.

I collected lots of feedback from different students around Europe that attended my Professional Scrum Developer Training. Here some photos to give you an idea...

“I added a Refactoring Story for the next Cleanup Sprint” This is an interesting statement. Let's see how often the alarm bell rang in your head. I mean how many smells you can find in that statement... Before you scroll down to read my answers, please count to 10 and try to find 3 issues. “I added a Refactoring Story for the next Cleanup Sprint” What would you say? Let's see: 1. "I" Really? You added a new story to the backlog? Did you talk to the Product Owner about it? Is it important to him? What are his responsibilities within your team? What is he accountable for? What are your responsibilities within the team? What are you accountable for? 2. "Refactoring as a Story" First of all, the Scrum Guide (the official source for Scrum) says nothing about "User Stories". In the Scrum Guide, Jeff and Ken talk about Product Backlog Items. Everything that adds Value in the Product should go on to the Product Backlog as a Product Backlog Item. Why is the activity of refactoring a story? Should it be a task then? Does it matter to create a task for refactoring? Should you even track it somehow? What are reasons to manage 'refactoring' work? What are your skills as a developer in your team? 3. Is "Refactoring" something of value to your stakeholders? Does the Product Owner care about Refactoring the Product? Should he? What is the responsibility of a Developer? Is "refactoring" something that just happens as described in the Boy Scout rule? Should "refactoring" just be part of your professional way of working? In another blog post, I described the Hotel Room rule and why it doesn't work. 4. A "Cleanup Sprint"? What is a "Cleanup Sprint"? Does that mean you don't deliver anything of value in that "Cleanup Sprint"? You just do house cleaning that you haven't done before? When is your house clean enough? When do you stop cleaning? You don't know? Doesn't look very professional to me. 5. "Next" Are you saying you already had a Cleanup Sprint? 6. "Next Cleanup Sprint" You manage single Sprints? Are you sure? Are you adding stuff to single Sprints or to the Product Backlog? How come you put it into a Sprint and not the Product Owner who is prioritizing Backlog items? 7. Is Refactoring a Story? What is Refactoring again? Refactoring is the activity of changing the inner design without changing the outer behavior of the system. What are User Stories all about? A User Story is a placeholder for a conversation about a User need, which is about outer behavior. So having "Refactoring User Stories" doesn't make sense. In order to be transparent about them talk to the Product Owner about them and how you visualize those. It's your job There are quite a couple of issues we can find in that sentence. In my eyes, it is important to highlight that refactoring is your job. It is your professional behavior. You as a professional developer build quality into the product from day 1. Refactoring is part of making sure you build the right quality. If you as a team don't do it continuously, we get in trouble soon. Building quality is something that happens all the time and the development team is accountable for a high-quality product. What should we do in this situation? The good thing about this statement is that someone recognized a problem with code quality and wants to fix it. The thing to improve here is the behavior around it. I would start with asking the above questions. Give feedback about what you think from your perspective and ask "How did we end up in this situation?". Check whether the process, team or surrounding organization drive this behavior. What can we change or improve to make things better in the future? Are there more smells in that statement? What is your approach in dealing with this situation? Tweet a little tweet @peitor or leave a comment down below.

"Not a tester, so what are you then?" you might ask. Being that offending is generally not helpful. Unless you try to catch the attention as I do in this blog post ;-) Let's digest the situation in detail. A friend of mine attended my Scrum Developer class and caught fire during the "Testing" module where we talk about Code Quality, Testing, Test-First approaches, TDD and more. Boom! After that class, he was on a mission to convince everyone that TDD is the only way to do things. The 1st day back at work he talked about improving the team and trying TDD and got the following statement from his colleague: Henri (made up name): "I don't write any tests since I am not a tester". I know he handled the situation quite well, but he asked me for advice. One thing to consider is the underlying question to this, which might be: "How do we get people to change their behavior?" So here are my thoughts. Yourself? Things to consider for yourself: Why is the practice or tool that you are suggesting any better than the current way of doing things? Can you explain the value in the proposed change? Can you lead by example? Do you have enough patience and skills to teach others? I would try to work on yourself before trying to change others. Roles? I see this a lot, that people are focused on their role or job title, forgetting the bigger picture of the team and purpose of the work they are doing. Are we 1 team that focuses on the Sprint Goal? In a Scrum context, there is no "tester", "programmer" or "architect", we are all professional engineers that deliver value through collaboration. No matter what, do we stand together and support each other? Are we doing whatever is necessary to deliver a usable product every Sprint? Done? Henri: "I don't write any tests since I am not a tester". Ask: "How do you know when you are done?" What is on our Definition of Done? How can we build a usable, tested and fully integrated product increment every Sprint? Are we doing that already? Why not? Tests are as important as documentation Documentation is needed, and one good way to document how software *must* work are tests. I emphasize *must* since documentation only documents how the software might work. We learned too often that documentation gets out of sync too easily. I blogged about the "Why are *automated tests* so important?" on my personal blog. Quality Quality is everyone's responsibility in a Scrum Team. There is no QA Team in a Scrum context, which means the whole Scrum Team is responsible for delivering high-quality software that works and is fully tested. Quality attributes that are important: Does it work at all? Huh! Does it work well? Is it deployed and useable? Are the users able to access it? Is it useful? Is it successful? Does it make the impact we wanted to achieve? -> Yes! Value is key Testing can be fun Tests are code Are you a coder?? Yes? Tests are code. So write some tests, especially so that you can sleep better at night. Still not willing to write tests? Ask yourself: How can I help? What can I do? You can always get the team coffee Show support. We are in this together. Get test infected in 3 days in my Scrum Developer class! Recently I did a a video interview where I ask my students 3 questions about the Developer class. Check it out here https://www.youtube.com/watch?v=oLxBV4hPMkU

Ok... Let's make this a short one. I talked to lots of people about this statement and after lots of strange looks I got lots of comments about the behaviour. Especially about the "since it's crap". This is pretty obvious a very strong opinion about something. But hey! Maybe the code works, passed acceptance quality gates, the client user interface looks pretty good that uses this code piece and it is deployed in production. And maybe the company is making loads of money $$$ with it. Making lots of money (from https://www.flickr.com/photos/16210667@N02/12134787043/ ) Making lots of money.. Is my code still crap?? Ok... Let me slow down. How did this come about? The statement happened during the Daily Scrum after one of the devs finished talking about what he did. Another developer jumped in and finished this sentence with: “I reviewed your code last night and deleted all of it since it's crap” How many smells can you find in that statement and behavior? I found 5. 1. "I reviewed" What? 1 single person is the code gatekeeper and making sure that code is "right"?? 2. "Your Code" Is this your code, my code and every developer has their code area? Can we talk about "Collective Code ownership" and the advantages about it? See Martin Fowler on the topic "Collective Code Ownership" 3. "Last night" Someone is working late nights? Why is that? Is he not co-located or working different work hours? How is that affecting team work? Is this an incarnation of the "Hotel Room Rule"? The "Hotel Room Rule" as described by me on my private blog. 4. "Deleted" A code review where someone just deletes code? What about giving feedback in a constructive way? Can you provide feedback and avoid this in the future? If you are a team, focus on how we can improve together. How can we guide ourselves in the direction of Clean Code. Why CleanCode in the 1st place? More links to giving feedback in my talk about "Agile and Software Craftmanship" 5. "It's crap" What is crap about it? The style? The complexity? The overall class design? The infrastructure usage? What is it? Is this your opinion? Can we do a team code review about this? Some tips to avoid this situation: Schedule regular team code reviews (we call this DevExchanges and do that every 30 minutes after lunch). These sessions help to share knowledge and "how do we do things here" (every team is different). Did you ever have a discussion about "tabs versus whitespaces" or "member variables with a leading underscore _"? Use Merge Pull Requests and the comment feature to discuss code issues Github, Gitlab or others provide great tooling around reviewing and discussing code Provide lots of context in commit statements Context is important to know what problem are we trying to solve with the specific code. Is this a refactoring? Fix a bug? Why? Why? Why? Give feedback by asking questions. Instead of "this is crap" say "Can we improve this?" It's very hard to ask a question and be negative in it... Not impossible though Use NVC to communicate, "I see", I observe", "I realize" are great statements to start with. "I see these lines of code are crap." is not a good one;-) Non Violent Communication on Wikipedia Try mobprogramming or pair programming http://mobprogramming.org/ BTW: we made quite good experiences with remote people as well when we did Dev Exchanges distributed as described by Emilija on Distributed Development. Important to remember. Grow as a team and "The doing is more important than the result." Question to you: What do you do if you browse the codebase and you see something smelly? Put it on a list? Mark the code? Add a TODO? Send an email? Approach someone? Wait for the retrospective? Call the lead dev?

Let me quickly describe a potential situation how this came about. During the Sprint Planning, the team had agreed to deliver the top 5 Backlog items. They had some conversations about what the items are and where the problems could lie within those. The Product Owner had the feeling that just the top 5 items were not enough and that the team was not 100% busy in the next Sprint. So he went through the Backlog and asked for 1 more thing: Can you do number 721? One of the developers immediately shouted out: "The requirement #721 doesn't meet the Definition of Ready". There are a couple of issues on that team that you might recognize and a couple of issues in that statement. How many smells can you find? Think a little before doing. Don’t forget the smells ;-) There are 2 issues in the situation above that are worth highlighting as well. Deliver top 5? Did this Scrum team refine the Product Backlog ahead and plan the next Sprint together? Did they talk about dependencies and the overall Sprint Goal? What I usually see is that the Sprint Goal binds some backlog items together to a package, a potentially releasable product Increment. This can be the top 5 items, but usually it's a combination of the top items of the backlog that make sense together. ‘Sense’ in this case means from a technical and business point of view. The PO thinks the team is not 100% busy What makes the Product Owner (PO) think that? How come he doesn't trust the team? First of all I think as long as the PO is happy with the last Sprint outcomes, this should be of no concern. On the other hand I think there is a deep problem with this that the Product Owner doesn't trust the team. As the PO, is the team committed to my product and journey on building this product? Maybe talking about the overall vision helps here and doing a retrospective about these topics. 1. "Requirement #721"? How valuable is this "requirement" if it deserves just a number? Can we call it the "Twitter Integration requirement" that gives everyone a clear idea what we are about to do? In my eyes a short description is definitely helpful to have a meaningful conversation. 2. The word "Requirement" Do we have only requirements on our backlog? What about user needs on a higher level? Future potential experiments? Where are those stored and tracked? The Scrum Guide says: "The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases." 3. What is not fulfilled of the Definition of Ready? Can you be more specific? Can we collaborate and make things better? I think this is the most important one to me. Let us sit together and collaborate and make things better. Developers shouldn't be spoon fed with ready user stories that kill their engagement. 4. "Definition of Ready" The "Definition of Ready" is a smell in itself. It's going back to staged gates and silo thinking. Developers think about the “how” and a single mastermind thinks about the “what”. Collaboration and communication between a group of people can create great innovative products. One single brain is always less innovative than a group. In essence, this comes down to the thinking: "Good Requirements create good software". I think: "Great teams create great software". Where should you as a CEO spend your money? Scrum Team Consensus If a Scrum Team can't reach consensus on 1 Sprint's worth of PBI's during sprint planning, that's a smell. This is definitely something that the team should pick up in the next retrospective. Can a Development team say: Nothing is "Ready" from your end, please come back to us next week? This prevents collaboration instead of inviting it. Don’t forget the third value of the Agile Manifesto: Customer collaboration over contract negotiation. If you really need a “Definition of Ready” use the following: If a PBI can be estimated by the development team it is ready. In order to estimate it the whole team needs to talk and collaborate about the PBI -> Success! Whats next? What about the "Definition of Done"? Is that fostering silo thinking? Is that hindering collaboration?