Scaling Agile appears to be a common topic these days. Of course there are good advices and bad advices on how to do that. But how do you know which is which? A few weeks back I came up with the idea of an anti-maturity model. If you have dealt with a few maturity models in the past, these usually run from level 1 to level 5, where level 5 means more mature. My anti-maturity model runs differently, with level 0 indicating that you are probably on the right track, and level MAX_INT that you are probably not doing to well. Why does this scale run differently? As part of my work, I realized there is always someone out there who can come up with an even worse way of doing things than that other guy that I thought was worst.
As all these years, I went to the Agile Testing Days in Potsdam, Germany. On Tuesday evening I received an award for being the “Most Influential Agile Testing Professional Person” 2013. Since this is an award based upon votes on the internet, I want to say thank you for voting for me.
I had prepared a speech, but didn’t deliver it fully. Here is the full thing that I prepared.
“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 2×2 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.
Currently I find myself in various roles. At times as Scrum Coach, as trainer, as sales guy. When interacting with companies in the IT domain, at times, I have the impression that stuff like “best practices”, recipes, and clear guidelines are necessary to convince managers – or at least provide them some sort of certainty.
My usual answer to questions like “how would you do X?” is mostly “sorry, it depends.” Most of these times I find myself giving a weak answer. At a recent interaction with a psychologist, I was able to see a pitfall in the questioning rather than my answer. Let me elaborate on that.
Something bothers me for a while about Kanban. These thought re-awakened during James Bach’s keynote at the Let’s Test conference in May. James was talking about the 1990′s movement into process. Processes needed to be everywhere. That’s why he became engaged with what turned out to end as the context-driven school of testing. Here is a quote that I heard in one form or another from the Kanban community:
The process needs to be defined, published and socialized — explicitly and succinctly.
(I got this from here.)
The Kanbanistas keep on confusing me with this. Here is why.
Maybe it’s just me, but the whole “which Agile project management tool should we use” debate drives me nuts.
Maybe it’s just me, who can’t understand what “Agile project management” means to start with. Try to think in products, not in projects. Your product portfolio is the bigger problem, not how you taylor the work to create multiple projects.
Maybe it’s just me, who does not understand a thing about project management, but about software development instead. I don’t know what I want, but I know how I can get it: take small steps, iterate and reflect.
Maybe it’s just me, who heavily remember Conway’s Law:
organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations
Maybe it’s just me, who also understands the other direction of that law. Once you introduce a tool, it will constrain how you think about changing your organization. That said, it will keep you away from meaningful steps once they become necessary.
Maybe it’s just me, but we shouldn’t be talking or debating about Agile project management, or about Agile tools. We should discuss about what makes us successful. Remember: A fool with a tool is still a fool.
I am currently reviewing a book on domain testing. While doing that I realized I can put up a testing challenge based on what I annoyed my colleagues with a few years back. I disabled comments on this post in order not to spoilt future visitors of my blog. You will have to find another way to respond to this.
Imagine a service which is rated on a monthly basis like Spotify, Watchever (they don’t pay me for writing this blog), pay-TV, phone lines, or mobile phones. Usually that means that you have a fixed monthly rate.
Now, the business prescribe that you have a monthly fee that you need to pay. For example for Spotify premium this is 9.99 EUR, and something else for some other service. The business rules also provide that you can cancel this service mid-month before payment. Then you will be charged only the pro-rated amount of the monthly fee for the current month. For example, if the payment period starts on the 1st of the month, and you cancel the service on the 3rd of the month on a 30 day month, you will only pay 2/30th of the monthly fee for the final month.
Unfortunately we deal with a larger system. In that system the pro-rating is transporting from the domain subsystem to the billing subsystem via the percentage of the prorating. That means that for the above scenario we will trigger some process on the billing backend with 1/15th in percent, yielding 6,666666666667 percent. The value used here is a double-precision floating point value.
Analyze this program (consisting of both subsystems) for interesting variables, what could go wrong, and how would you test it?
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.
On the bottom of James Bach’s recommendations of people there is a small paragraph:
That One German Guy
Germany has no excuse. There are TONS of smart people there. How is it only one intellectual software tester has emerged from the ISTQB-addled masses to demand my respect with his work? My theory is that Germany has a more command-and-control culture, which perhaps disparages independent thought of the kind required to achieve excellence in testing. This pains me, because I am descended from Germans and I would love to visit and teach there.
Anyway, the one German guy who shines in my community is Markus Gaertner. I’ll do a write-up on him, shortly.
Yeah, it’s about me. From time to time I am asked by James and other people in our community where the German testers actually are. Here are some folks I am in touch with, that have raised my attention, and I think will need some attention from the wider community. There is not only one guy testing in Germany, seriously.