Back when I studied, I worked part time in a local store. I was responsible for juice, soda, beer, wine, and other bottles of alcoholic drinks. I was responsible to order them, and to manage and refill remains over the week. Being a small shop, I also needed to be a jack of all traits. At times I had to have an eye on refilling vegetables, and fruits. At other times, I needed to refill milk, or answer inquiries from our cashiers. That said, there are some lessons I learned in that shop that helped me find my way once I joined my first job. Here are some nuggets from that time.
Over the course of the past year, I had the opportunity to work with some great trainers. I learned a lot from them, and by delivering co-trainings together. Today, I decided it was time to reflect on some of that stuff. Blog entries work great for me to do so. Here is a first blog entry in a series of entries to come.
Stick long enough into testing, and you will face an argument pro or contra traditional test cases. Most of us have been there. Most of us know what worked for them in the past. Most of us won’t agree with each other. During a particular co-training, I became aware and reminded again about process control, and realized why I think exploratory testing is better suited in most software development shops around. Let’s see what process control consists of, and check in which of the models testing falls, and where exploratory testing can help you.
“Where should our developers book their hours on when we move to Scrum?” I was asked recently at a client. I am helping them roll out their new development methodology which leverages a big deal of Scrum among 17 teams. One of the questions in the larger organization was, how to do time-tracking. I knew I needed to dive deeper into that.
At the Global Scrum Gathering in Paris, France, Henrik Kniberg kicked off the first day with his opening keynote. He was speaking about how culture overcomes process – whether you want to or not.
Kniberg defined culture are the stuff that people do without noticing it. When people carry their bodies to the Daily Stand-up just because the ScrumMaster tells them, that is process. When people get to the Daily Stand-up because that is how we do software development around, then that is culture. Kniberg explained that an Agile culture leads to better products and happier employees. In the end, we end up in a better world. (I missed some unicorns at this point.) Kniberg described how fragile Agile is. He showed the story from the Swedish police which he wrote about in Lean and Agile from the trachnes. They started a project to build a software for the officers on the streets. They introduced Agile & Lean, a gradual rollout, real users were involved, bottom-up decision making, value-driven and a suitable tech platform. The project ended in a media success with happy users and a happy team. Even they won an CIO award in the end. Skip forward a few years, and the project was overtaken by the surrounding organization. They implemented waterfall with big-bang rollouts, and an inappropriate tech platform. Real users were no longer involved, and decisions were made in a top-down manner. Overall they changed from value- to cost-driven. It was a media disaster with furious users and furious team members. This is how you can burn one billion euros, Kniberg concluded. Kniberg continued with the story of Spotify to show a positive example of a great culture. Even though Spotify doubles their employee numbers, they have industry's top-notch employee happiness. Why? Kniberg explained the Shu-Ha-Ri model. At Shu-level you follow the rules, at Ha level you start to adapt the rules as you see fit, at Ri-level you ignore the rules. Kniberg cited Scrumbutophobia, that is the fear of doing Scrum wrong. The pre-valent symptom for Scrumbutophobia is a Scrum implementation being stuck in the Shu-level focusing on the practices alone, rather than the principles. For Spotify, Kniberg explained that they focused on five principles from the Agile world, these are Continuous Improvement, Iterative development, trust, simplicity, and servant leadership. However, they found a sixth principle that had great impact: autonomous teams. In Spotify teams are called squads. Autonomous squads follow a mission, are small, and co-located. Squads organize themselves and have full end-to-end resposibility for the stuff they build - from design to commit to deploy to maintenance. Each squad has a mission. Within the scope of its mission, a squad is empowered to decide what to build, how to build it, and how to work together while doing it. Spotify steers the autonomy of squads with their mission. The broader the mission, the more autonomy the squad has. Kniberg cited Pink from his book Drive that motivation comes from autonomy, master and purpose. That is why autonomy has such a large role at Spotify. Squads follow the guideline to be autonomous, but don't suboptimize. Kniberg showed some examples from their office how they get this in place, like hang-out areas for cross-squad collaboration, sprint demos and open discussions. Kniberg continued by explaining the relationship between autonomy and alignment. He explained with a 2x2 matrix that high autonomy and high alignment lead to an innovative organization, and collaborative culture rather than conformance or people diverting into different directions. One way they applied that at Spotify was to measure dependencies between squads by asking the people. All squads at Spotify own their own quality, they sit together, have a mission, and a ProductOwner in their team. They also follow an Agile approach. Most squads do retrospectives, have a physical taskboard, do demos. Most squads also either use Scrum, or Kanban, or both, and have an Agile Coach alongside with Daily Stand-Up meetings. Some squads rely on estimates, and measure their velocity. Some also have Scrum of Scrums meetings, and maintain burn-up or burn-down charts. Kniberg showed an example from their happiness survey. The email contained the results from the latest happiness survey: 91% happy, 4% not happy. Instead of putting up how remarkable that is, the email stated that this is not sufficient for them, and if you happen to be among the 4% of the people being unhappy, please get in touch. This is how you nurture a happiness culture. Kniberg continued with concepts that I had heard at other Spotify talks before. If you happen to be at a conference with some Spotify talk, I recommend going there. To me it did not have too much to do with culture, but more with how they cared about their people. Kniberg explained how the concept of tribes combines squads, and how chapters came into play at a certain point of scaling. Kniberg showed the vicious cycle of most release processes in place. Releasing is hard, so you release seldom. Because you pile up so much stuff to release, releasing it becomes hard, of course, and this is where the vicious cycle closes. On the other hand, if you make releasing easy, you release more often automatically. One way Spotify achieves this is by decoupling as much as possible. Kniberg continued with the importance or trust. He explained how fear can kill motivation. He cited a CEO from some other large company that said
The reward for doing a good job today is having a job tomorrow.Of course, such a culture leads to fear, and blaming. Instead Kniberg showed how important failure is for learning. Citing facebook's "move fast, and break things" is something you need to build inside your culture. At Spotify they have retrospectives and post-mortems focused not on blaming but on learning. They also have blog entries on their internal blog starting with "how we shot ourselves in the foot" that expose that learning to the larger organization, and keep the blaming out the door. One thing that helps with this is to have a limited blast radius for all the components. If something goes wrong, not the whole platform goes down, but just the single piece that squad is responsible for. Of course the squad then knows they need to fix that immediately. Kniberg continued on why value & impact is more important than velocity. He explained how Spotify embodied the Lean Startup cycle in their culture. They start with an idea or problem. They build a narrative and a prototype to solve the problem. Then they build a minimal viable product, which they deploy, and analyze data to learn quickly. Kniberg showed a continuum between predictability and innovation. He put waterfall methodologies on the end with the predictability. Typically Scrum lies on the middle of that continuum. Kniberg stated that Scrum at Spotify lies more on the innovation side than typical Scrum implementations. They unleash innovation with hack days, and hack weeks which may take up to 10% of employee time. Kniberg paraphrased empirical process improvement mind-set that experiments & data are mote important than discussions and opinions. In an experiment-friendly culture, for example, when deciding between Tool A or Tool B, you try both, and compare them after some time, and then make the decision. Kniberg described that at Spotify they got rid of meetings that were useless for them. They also don't have PMO & PM roles, time reporting, hand-offs, acceptance test phase, task estimates, and all the other things you may find at other corporations. Instead they decised to keep retrospective, daily standups, google docs, git, and go to conferences. Kniberg also showed how the put improvement boards and the "Definition of Awesome" in place with multiple Kanban boards for improvements where you could zoom into a ticket to follow the whole improvement process, and the experiments they ran before. Kniberg cited lessons they learned from big projects. The first mantra is to avoid big projects whenever possible. If you can't avoid them, then sync daily to resolve squad dependencies, and demo your product weekly in order to evaluate the integrated product. Kniberg described that they also ran a big experiment: a personal bonus system. They found out it doesn't work since it was a large failure. Another bit experiment Spotify ran was a tech-wide hackweek. One whole week everyone in tech (300 people) could build whatever they wanted, with whomever they wanted, in however way they wanted. They also had a demo & party on Friday. It was a large success. Kniberg continued how to spread and nurture the culture. They have dedicated roles for culture and improvement. There are Agile coaches for some squads alongside with the People Operations team that focuses on the culture. They together form the Agile coaching community. One element to grow their culture is that every new employee is sent on a boot camp for one week. After that week, they put software into production in their second week, and demo it. Another example in Spotify's culture are social groups, like board games, movie visits, and so on. Kniberg concluded with their pain point. They have unstable squads, which means new squads are formed regularly anew, or new people come into the squad restarting the whole team building, eventually. Also, scaling breaks stuff all the time so that yesterday's "brilliant solution" is today's impediment. Cross-timezone collaboration and technical debt are two other points Kniberg mentioned. But, Spotify found out that culture has a healing effect. Although all these points seem painful, they do not last for long at Spotify. A lot from Kniberg's talk reminded me about the Spotify talk I heard at Agile 2013. I also could see things at it-agile that we struggle with, and that work for us. I think I can take some of the factors like alignment and autonomy back to implement them in our company.
Today I read an article on various approaches for Product Backlog Grooming meetings. Underlying the write-up there seemed to be some misconceptions about the purpose and goals, the duration, the participants, the approach, and how often and when to hold a Product Backlog Grooming meeting.
Probably the ugliest thing about going to conferences is that you pick up a lot of books to read. That even held for XP 2012 in Malmö, Sweden, although I just attended the first day at the tutorial of J.B. Rainsberger & Ruud Wijnands on Agile Coaching. They recommended two books from Patrick Lencioni for my to-read pile at home, The Five Dysfunctions of a Team and The Three Signs of a Miserable Job. While getting close to finishing the latter one, I noticed that the three signs of a miserable job map easily to signs that your Scrum implementation is miserable as well. Here’s the rationale.
About two years ago I read Quality Software Management Volume 2 – First-order measurement from Jerry Weinberg. In it, he explains the differences between first-order and second-order measurements. The latter is a replacement measurement. Instead of measuring the thing, we measure something that we substitute for the thing that we are measuring. For example, measuring code coverage usually is a second-order measurement for test quality. It does not really measure the quality of the underlying tests, since you don’t know how many assertions lie behind the covered lines of code. In the same book, Weinberg also provides the concept of zero-order measurements for projects. A few months ago I was surprised that these seem to be focused on traditional projects, rather than agile ones. Since then I decided to come up with zero-order measurements for agile projects. So, here are some of the things I look for when entering a new client or company.
Yesterday during my keynote at the Agile Testing Days 2012 I said I see a lot of standups, where testers report on their yesterday’s work in the following way:
Yesterday I tested the thing with the stuff. I found some bugs, and filed them. Today I will test the foo with the bar.
I think this is horrible test reporting. While concluding the fifth beta of Elisabeth Hendrickson‘s upcoming book Explore it! I found a few more hints in the same direction. On the same line I will relate good test reporting during the standup to what for example Michael Bolton talks about when it comes to test reporting – we should tell three stories during test reporting:
- a story about the product
- a story about testing
- a story about the process
In the past I have been more than skeptic about certifications. I even wrote about my minimum requirements for a certification programme that might (or might not) add value in an article called Meaningful Certification?. Despite the split between the two larger organizations (and their early leaders) on Scrum – the Scrum Alliance and Scrum.org – yesterday I noticed that the certification scam has taken on new levels with a program called Certified Scrum Manager (IAPM). Here is my honest critique about it, and I will try to rant as few as possible about it.
Today, a colleague of mine, Norbert Hölsken, started off a discussion in our internal communication channel. He asked:
How do you treat bugs on the taskboard that are found during testing? Create a new test for each bug, and put the test task back in ToDo? Or create a bug, and a bug-follow-up testing task?
As it turns out there are a lot of valid reasons to do it one way or another. Yet, the answer “it depends” does not help – neither a Scrum Coach, nor a tester working in a Scrum environment. So, I started raising some of my experiences and concerns, and some of my other colleagues replied as well.
Skip forward three hours, and I am writing a blog entry on my thoughts about it.