Markus Gärtner's Blog, page 15

Scaling Agile Anti-Maturity Model

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.

Level 5 – The Brooks

You realize that the constraint of 3-9 team members is artificial. Since you are a large organization, you need to have adaptations, and that includes team sizes of 100 team members. They already work this way for decades. Changing a working team is going interrupt their productivity. That’s not something you want to put at risk just by going to another methodology.

Level 4 – The Blue-printers

Scaling Agile is easy at this level. All you need to do is to use Scrum since almost everyone uses it. Then you run your Sprints starting with Sprint 1 – Requirements, Sprint 2 is on Architecture. Sprint 3 is on Design, Sprint 4-5 is on Programming, and Sprint 6 is to find the one to blame. Since you waste a lot of your time doing that, you won’t ship any software at all.

Of course, you can run the sprints in parallel, since you will stick with your requirements department, enterprise architects, and designers.

Level 3 – The Conways

Some of your IT teams are using agile. The larger organization though uses proven methods like project plans to adhere to that. Your teams are not cross-functional. Instead, you still have a department in place for all the testing, and you are going to stick with that, since you can’t release the crap the teams build, anyways.

Your architecture in the software maps directly to the organizational structure. You make sure to stick to those structure by introducing additional roles, like a technical counterpart for the business-facing ProductOwner that gives out architecture stories to your teams.

Level 2 – The C3POs

You realize that you have a lot of people involved. The concept of Scrum of Scrums is too limited for you to work. Since you have 42 management levels involved, you should go for a Scrum of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums, so that all your important people can serve as a ProductOwner of a ProductOwner of a ProductOwner of a ProductOwner of a ProductOwner, and so on. The technical term for that model is Chief ProductOwner, and your most senior one is afterwards called the CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCPO. You have the same structure in your ScrumMaster organization. The top-most person there is called the Master of Desaster.

Level 1 – The Downstreamers

You have tiny little teams which work together – your database team creates the database first, so that in the second sprint your business domain team can code the business domain, and your UI guys will be dealing with the user interface in sprint 3. Your ProductOwners are self-organizing, and driven by their own project managers. Your product is driven by three customers, and your ProductOwners deal with the necessary re-prioritzation for that – each on their own.

Level 0 – Emergent Scaling

You realize that scaling agile is a complex problem. That means that you need emergent practices, and can’t work from a blue-print or project plan. You realize that you should probe the underlying organization for the changes necessary, and see what happens as you incorporate little experiments while maybe scaling the organization to use Agile all over the place – including accounting, marketing, and sales.

You don’t focus on one agile methodologies or framework, but make local adaptations as necessary to provide the biggest customer benefits all the way through. Your teams deliver business value from end to end, and each of the teams works as their own start-up in the larger organization. Since you have decoupled the whole organization, you don’t need many people while still being able to ship products every second of the day.

Conclusion

If you have read thus far, congratulations. If you find there is still something you want to add, please feel free to do so.

In case you want to outline this model to your management, I also came up with a name, an abbreviation for it: ScAAMM.

Thanks!

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.

Back in 2009 I read a blog entry. A guy named Zeger van Hese wrote it on his blog. He was writing about a shy guy speaking at a conference. That guy had a quite compelling story to tell about how his team of testers discovered agile development practices, and implemented them. The guy seemed pretty nervous when he talked, Zeger wrote. That guy was me, having my first conference talk at Agile Testing Days 2009. I was anxious with all these people that influenced me in the room: Lisa Crispin, Elisabeth Hendrickson, and the evening before that I demoed my talk to Gojko Adzic and Mike Scott.

Skip forward a few years, and I am happy to receive this award. The Most Influential Agile Testing Person. Thank you.

I remember when I was confronted with being influential for the first time in my life. I was still young, a 16 year old teenager. I just gave up swimming, and stepped into a coaching position at my local swimming club. I also stepped up to organize our youth groups.

At that time I had all the terrible ideas in mind that teenagers come up with. I was smoking, drinking beer, partying all night, etc. At some point one of our more senior people took me aside and told me that it’s not a good idea to stand in front of a group of kids with a cigarette in hand. That was when I realized that I indeed had influence with my behavior on others – and that I needed to be cautious with stupid actions.

Boy, was I scared. Receiving this award – Most Influential Agile Testing Person – reminds me about this fact – and it still scares me.

Back in late 2008 I have been involved with the uprising of the Software Craftsmanship movement. From the mailing list, I remember a lively discussion from those early days. The model we had in mind was that of the ancient crafts with their mentor and apprentice model to educate the next generation of software developers. In one discussion we pointed out to the people that influenced us in order to point to our self-picked mentors.

Today, this list would be endless for me. James Bach, Michael Bolton, Elisabeth Hendrickson, Gojko Adzic, Jerry Weinberg, Johanna Rothman, my colleagues at it-agile, past and present, Matt Barcomb, Brett Schuchert, Uncle Bob Martin, Micah Martin, Steve Freeman, Kent Beck, Michael Feathers, Alistair Cockburn, Andreas Leidig, Doug Bradbury, ….

I think this list will never be complete, but these folks influenced me largely – and most of them still do.

When I took a look into the program on Saturday evening to see who will be here, and who will be speaking, I was amazed by the amount of people attending Agile Testing Days this year that influenced me. Lisa Crispin, Janet Gregory, Dan North, my early mentor Matt Heusser, my first apprentice Meike Mertsch, Tony Bruce, Ajay Balamurugadas who introduced me to Weekend Testing, Huib Schoots, Jean-Paul Varwijk, Anna Royzman, Pete Walen, James Lyndsay, Bart Knaack, the TestLab gurus, Seb Rose, J.B. Rainsberger, … even this list seems infinite, and it’s hard for me to not run into a familiar face in the hallways at this conference.

What that look on the program on Saturday evening taught me is that this conference heavily influenced me. It seems to be a large family reunion. It always has felt like that in the years past. That said, keep on being influenced, maybe by me, and also by these great people that I learned so much from on my own.

Thank you.

Time-tracking in Scrum

“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.

“Why do you need time-tracking?” “Well, you see we have customer projects alongside with the development of our product platform. Customer projects run in two phases: before feature complete, and going for the real deadline one year later. During the latter phase customers file a lot of bugs when they start testing the functionalities we delivered earlier. Sometimes we want to fix a bug for all customers, then this becomes product development effort. Otherwise we charge the project.

“We have customers that are troublesome. In the end, we want to decide which customers don’t pay off well. That’s why we want to keep track of how much development work flows into each of the customer projects.”

A long story short, the 17 teams might find work from either customer project or the platform product in the backlog. A sprint might then be filled with either a mix of items from all of these sources, or it might be just product, or just bug-fixing. Depending on the demand from the customers. Oh, they decided to start with component teams, I think I should say that as well.

I don’t think we came up with a solution that no one else in the world thought of, yet, I found it clever. We came up with the decision that the Product Owners of each of the 17 teams can deliver percentage numbers – how much work did my team for customer X, customer Y, and how much for the product – after the Sprint, or at least on a monthly basis (as this appeared to be the reporting cadence). Let’s look at the benefits of this approach.

Improved accounting

The development team costs the same amount of cash each sprint. In order to do the math for accounting, it’s sufficient to track the development on this granularity level and after the fact. In fact, it turned out to be more precise than anything in place.

Before our discussion developers also fixed bugs. Usually when it came to tracking their time the developers were struggling with where to book the particular 10 minute bugfix. Did the product manager approve to include that in his budget? Is this a bugfix just for customer X, even though customer Y needs this as well? In the end, developers ended up tracking their bugfixing efforts for the budget that was easily available to them – and that usually did not have to do anything with booking hours to the right cost center.

That said, with the old approach they were hardly able to answer their initial question: Which customer projects pay off, and which should we abandon in the future? The numbers were ambiguous because the structure behind it did not support the people who needed to use the system. With the new approach, the numbers were still vague, but a bit more reliable when it comes to answering the initial question – and therefore more helpful.

Empowering of Product Owners

The Product Owners become more empowered since they now have real accountability in regards to how they juggle the different efforts with their ordering in their product backlogs. Since they should report the percentage split among the different cost centers, they now have to deal with the accounting side of the efforts. They are now really in charge to care for the money that their development team costs, and might even have to negotiate those numbers with the project managers for the different customer projects.

The development team costs the same amount of cash each sprint. After the Sprint it reviewed, the Product Owners have a clear picture about which bugs are fixed, which backlog items have been completed (and which maybe didn’t), and how much effort was put into each of the different cost centers. By negotiating the numbers on the larger portfolio level, they now even need to really think about where to get money from. I expect these conversations to change over time into “we need to charge customer X for this thing more than we thought” or something like that.

Easier time tracking for developers

The initial thought before involving me was to create cost centers for all customer projects, and each component team. Together with separating between development efforts, bug fixing efforts, and meeting efforts this would have become a nightmare for every developer involved in the teams.

Now, the proposal included that each component team simply gets one dedicated cost center. Developers book all their hours one effort: “My Scrum Team”. We even dropped the separation between “development”, “bug fixing”, and “meetings”. That means that the overhead of the Scrum meetings, or any larger organizational meetings is now spread across the different customer projects in fair amounts. Thereby the particular pick of development methodology also flows into the contracts for future customer projects.

Simplicity

I think we did not re-invent time-tracking. In fact I am quite sure that someone already did something like that. I like the approach as it answers a reasonable question from the business perspective while it favors simplicity. The development manager talked right away with accounting and the HR department whether the approach would be feasible, and they want to give a try.

Scrum Gathering Paris: Culture > Process – Henrik Kniberg

Culture > Process

Henrik Kniberg

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.

<!-- more --!></p>
<p>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.</p>
<p>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.)</p>
<p>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.</p>
<p>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.</p>
<p>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?</p>
<p>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.</p>
<p>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.</p>
<p>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. </p>
<p>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. </p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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</p>
<blockquote><p>
The reward for doing a good job today is having a job tomorrow.
</p></blockquote>
<p>Of course, such a culture leads to fear, and blaming.</p>
<p>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.</p>
<p>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. </p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<a rel="nofollow" target="_blank" href="http://www.printfriendly.com/print/ne..." ><img src="http://www.shino.de/blog/wp-content/p..." class="sociable-img sociable-hovers" title="Print" alt="Print" /></a><a rel="nofollow" target="_blank" href="http://digg.com/submit?phase=2&ur..." ><img src="http://www.shino.de/blog/wp-content/p..." class="sociable-img sociable-hovers" title="Digg" alt="Digg" /></a><a rel="nofollow" target="_blank" href="http://www.stumbleupon.com/submit?url..." ><img src="http://www.shino.de/blog/wp-content/p..." class="sociable-img sociable-hovers" title="StumbleUpon" alt="StumbleUpon" /></a><a rel="nofollow" target="_blank" href="http://delicious.com/post?url=http%3A..." ><img src="http://www.shino.de/blog/wp-content/p..." class="sociable-img sociable-hovers" title="del.icio.us" alt="del.icio.us" /></a><a rel="nofollow" target="_blank" href="http://www.facebook.com/share.php?u=h..." ><img src="http://www.shino.de/blog/wp-content/p..." class="sociable-img sociable-hovers" title="Facebook" alt="Facebook" /></a><a rel="nofollow" target="_blank" href="http://twitter.com/home?status=Scrum%..." ><img src="http://www.shino.de/blog/wp-content/p..." class="sociable-img sociable-hovers" title="Twitter" alt="Twitter" /></a><a rel="nofollow" target="_blank" href="http://www.linkedin.com/shareArticle?..." ><img src="http://www.shino.de/blog/wp-content/p..." class="sociable-img sociable-hovers" title="LinkedIn" alt="LinkedIn" /></a><a rel="nofollow" target="_blank" href="http://www.google.com/bookmarks/mark?..." ><img src="http://www.shino.de/blog/wp-content/p..." class="sociable-img sociable-hovers" title="Google Bookmarks" alt="Google Bookmarks" /></a><br/><br/><img src="http://feeds.feedburner.com/~r/mgaert..." height="1" width="1"/>

Going for the board

Several years ago, my parents send me to a local swimming club in order to learn and practice swimming. I started learning the different techniques: breast stroke, back stroke, crawlng, and butterfly. I exercised, and attended competitions. Skip forward ten years, and as a teenager I become distracted enough to give up that sport.

At a particular down I made the decision to stop swimming.

But I felt like I needed to give something back to the community that was a major part of my life so far, that made me grow, that most of my friends were a piece of.

That’s when I decided to become a swimming trainer alongside with giving back my time to the youth to come. I started as organizer of youth events, became a secretary, joined the local outdoor swimming pool community, organized trips, competitions, and dedicated lots of my time.

More than 15 years later, together with a move in jobs, I had to give that up. I never regretted the time I dedicated. I loved being part of that, I loved being part of the different boards that I was on (3 at the same time for some years). If I happen to change jobs again, I will probably consider going back.

Although, right now, the testing community to me has become a second community that I feel I need to give something back. The couple of past years, I learned so much from other people. Then there also were those folks that did the dirt-work in the back. For several years, I have been glad to have these gals and guys, sometimes without knowing it. I feel I need to give something back.

I am going for the board of directors for the AST. The elections are open right now. I want to give something back.

But what? Based on my background, I am considering the position of the secretary. I also would like to help bring an AST-sponsored event to Europe, and finally bridge the ocean from the States. I am quite certain if I become elected, I need to find out more, and I will find out more, and refine my role on the board, so I try to not make up too many promises at this point.

If you feel I can be of service on the board, (and are a member of the AST) I would be grateful if you vote for me. You will find details in your mail that you received for the elections.

It depends – but why – and on what?

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.

Traditional Change and Process Management

The pitfall of traditional organizational change management is driven by clear structure, routines, and a blue print to roll out. According to Jason Little such programs despite their clarity and certainty show a 30 % success rate.

30 % success.

Seriously? Why? And even better, why would I introduce a change management effort that promises clear structure and success, but fails 70 % of the time? The answers to these questions are grounded deeper.

The best model that described it to me comes from understanding company culture, and how to influence that. Besides others, John Roberts did some research on Organizational Development, why it succeeds, and why it fails. We have to take a systems thinking point of view to understand his reasoning.

Every system given the constraints is perfect in what it produces. Taking the company, department, team, or whatever container you may find as a system, it produces an output that is optimal with regards to the current constraints. That output is the company culture, the department culture, or the team culture. Culture consist of shared values, beliefs, mental models, norms, and language. What does matter to us? How and why do we do business? How do we interact with each other? and so on. The bottom line is that we can only influence that output of that system by influencing some or all of the inputs. But what are the inputs that result in company on happening? Roberts also has an answer for that.

First there is the architecture. That usually is reflected in the formal architecture of the company, or the organigram. But architecture goes also beyond the formal structure of the organization. It is also grounded in the informal architecture that exist between two department leads that used to work closely together with each other. They are so used to work with each other, and override the formal architecture with their informal network to get “stuff done”. Have you been there? I have.

Another input lies in the routines of the system we are concerned about. These include the formal processes and procedures that we agreed to deal with. But just like the architecture routines are also about the informal procedures. Overall it matters how we get work done, how we gather and spread information, and how decisions are made.

The final input to the system that produces the culture of a given system lies in the people. This includes their skills, abilities, their motivations and fears, their attitudes to work and risks, and their very personal interests and preferences.

Overall we get the acronym PARC for People and Architecture and Routines produce Culture.

Limitations of traditional organizational development methods

I was once involved in a company where the CEO was replaced. What followed from this change in management was a larger reorganization of the company. The next three to four months were not so pleasant when I saw stuff happening for all the people involved, a more traditional change manager was brought in, and changed stuff regardless of the people involved. Eventually I was able to move on to greener pastures. Three years later, I heard rumors that the new CEO was replaced again.

Traditional change management efforts are great at producing certainty for managers on the routines and the architectures. New team structures are found quickly that overcome the limitations that we can see up until now. Sometimes these introductions are accompanied with interviews to grasp the status quo. The same goes for a reorganization of the development approach.

These frameworks and approaches are great at producing two pieces of the PARC mixture: the (formal) architecture, and the (formal) Routines. And from understanding the PARC model we can now reason there is also something they leave out. Mainly these are the people, and their abilities. Another thing are the informal architecture and routines. Let’s take a closer look at these in turn.

People

I admit, I work together with a personal coach. She has a background in psychology, and makes me learn a lot about psychology and underlying models all the time. A while ago she told me about a training class she was giving to an IT department. Their managers kept on asking for “best practices” and clear recipes. She explained that’s not how a psychologists thinks about human endeavors. There is not human(x, y, z) produces awesomeness.

A psychologists rather thinks in probabilities. For example if someone is resisting a change that you would like to introduce there are several possibilities why this happens. It could be that the person is resisting the change because it resonates with a terrible childhood memory where he got beaten up. Or it could be that the person fears to loose his status with the change. Or it could be that the person is not convinced, or a late adopter for anything new. All these underlying causes result in different actions that I can take to make the change more likely with that person.

Unfortunately people are not simple systems, but rather complex in nature. That means that it is hard to predict what will happen all way before interacting with people. We are rather better set off by probing some response with tiny experiments first, and then see what happens, and adapt our strategy and tactics based on that response based on heuristics. Just like Deep Blue could beat Kasparov with better calculated heuristics, we can influence people better with better heuristics (sorry, I don’t know how to make you calculate better).

So, the first ingredient that is missing from more traditional change efforts lies in the people involved. But what would be the consequences to forget about these people? High? Low? Here is an anecdote that I went through a couple of years ago.

I was part of a Scrum team with overall six team members. We were eagerly working with unit tests and TDD to produce great code. Unfortunately we failed to deliver anything for two Sprints straight, and the pressure from the ProductOwner started to pile up on us – besides the fact that we were anxious and ashamed that failed to deliver on our planned results – I mean even to the degree that we finished one story in two Sprints.

So we sat together at the team retrospective to identify and overcome the problem that was hindering us. Long story short, we found that two team members could not work together. We were using a lot of pair programming. But these two guys just couldn’t work together. After we had the issue transparent we dealt with it by stating that it would be ok for them not to pair, and find other partners, and maybe find some conflict resolution for them in the mean time.

The next Sprint we delivered twice the stuff that we planned because we dealt with that people problem.

Disclaimer: Your mileage may vary.

Informal architecture and routines

Water cooler conversations can have some dramatic effects on how much stuff gets done – positive or negative. But why do these informal structures exist, anyways?

Taking a systems thinking viewpoint here, whenever a system does not get something from the formal architecture and routines, it tries to compensate for that with informal ones.

For example, if I am working in sales, and I feel like I don’t get enough stuff to reason my next salary increase, I will explore informal ways to connect with team members to do me a favor for my favorite customer. Maybe I can circumvent the formal process through a requirements management system, the ProductOwner, team lead, or whatever you have.

Or I might decide to meet regularly with the project manager after work for lunch, and try to get some details from him that are hidden from me at my workplace.

These examples show the power of informal connections and routines. But they form a backslash when I try to introduce a different company culture by introducing formal architecture and routines. The old culture will try to find a loophole in the new structure because us humans prefer familiarity over comfort. That means in the context of the informal ingredients to the culture, that we will try to find informal architecture and routines to produce the same culture as before again. Pity if you focus solely on the formal ingredients, as you will miss out so much transformation that might happen otherwise.

Coaching, anyone?

Last week at Agile 2013 I was once again confronted with the question on “now, what does an Agile coach do?” Here is the bottom line: He keeps the people and the informal architecture and routines in mind to make culture shift. At least a good one. That means that he makes suggestions for sending people on trainings, helping them grow personally, and intervene with informal routines and architecture that undermine the desired target culture.

The problem arises with the nature of the human being. We are complex beings. So, we can’t simply roll out a blue print for change to happen. If we try that, and loose focus on the informal structure and architecture, and the people involved, we will introduce new formal ways of work that have nothing to do with the lived reality – and certainly not with the culture we strive for.

In Scrum and also in Kanban we therefore need someone with the skills to help us with transforming these missed out elements. For example, Scrum has certainly something to say about the routines (think meetings and delivery procedure) and the architecture (think about roles). We still need a coach (which could be the ScrumMaster) in place to help us with the other stuff. It’s even harder for Kanban as Kanban addresses the (formal) routines, but does not say anything about the architecture whatsoever.

So, if I were a manager, the bottom line is this: I can either choose (perceived) certainty now by rolling out a blueprint to the routines and architecture, and have a 30:70 chance this succeeds in a resulting culture that is sustainable and produced better results. Or I could deal with the uncertainty by probing my environment and the people in it, and make more informed decisions about where to go. (And we are likely to find out we need to go somewhere else after we sent the first few probes.) Does this sound familiar? For me it does.

I don’t know what you need, but I know to get it. That’s why it depends even though you are looking for more certainty.

Process in Kanban

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.

Believe the process

According to Gause and Weinberg in Exploring Requirements – Quality before Design, the Swedish Army has a dictum:

When the map and the territory don’t agree, always believe the territory.

(I wrote an article in the Better Software magazine in 2010 about this.)

When those Kanbanistas point out that the process needs to be defined, and published, it seems to me they are referring to the process map – or description – rather than the process that is lived – maybe that is also the reason why they are demanding the process is socialized.

In my experience, the process description always lags behind the process that is actually lived. It’s a case where the map (the process description) and the territory (the process that is socialized) don’t agree with each other. So, how can we get started with Kanban then?

You need to have a process

Another quote I just remember, but lost reference to, is that you need to have a process before starting to visualize your work when getting started with Kanban. I didn’t figure thus far how it would be possible to not have a process. We already covered the part in regards to the process description, that is lagging behind all the time. So let’s take a closer look on the process that is actually followed.

In my experience even though there is no defined process, there usually is a process implemented that makes people know what they are supposed to do, the rules of the infinite cooperative game in software development. For example, if you work in a matrix environment, your project manager probably is the main person who knows what the customer expects you to do next, and what could help bring the project one step forward. So, when in doubt about what to do, you go to the project manager, he helps you get new work, get over impediments, and so on. I would call that a process.

Now imagine another team that is working in a start-up. The business is not set, the founder knows which features should be built next, and has the biggest knowledge about the system. In case you don’t know what to do, you go to the team lead. He’s going to help you with the next step. I would call that a process.

Of course, it’s a bit tough to model these situations on a Kanban board. The problem with that lies in the nature that many processes are not linear in nature while a Kanban board tries to bring the current process down in a linear fashion. You have a linear flow through the board from left to right. You try to bring cards as fast to the right as possible, maybe you have a second dimension with swim lanes, or a third with colors, dots, or whatever low-level tools you might put in practice there. Still, the dimensions are at times too limited to visualize the process that is actually lived, since it might have become multi-dimensional, and not soooo linear as the Kanbanistas would like to have it.

Evolutionary change

I think the biggest rubbish spread about Kanban is that it is an evolutionary change management… thing. Why?

First, you need to have a sort of linear process described, and socialized before you can implement evolutionary change. This sounds a bit backward to me. Rather than starting from the process that is actually lived, making it transparent to the people around you, and help them to deliver better products in shorter times, Kanbanistas rely on a process model in place to start “evolution”. That sounds a bit like we need to have evolutionary theory before we can start to get out of the primordial soup.

I blogged before about the fact that introducing a Kanban board already introduces changes. How could you call such an approach evolutionary then? It’s much like the observer effect. You cannot tell whether the introduction of the board itself already lead to a variation in the process to start with. To say the least, it probably makes the people aware of the formal routine that is going to be followed in the months to come. Applying Systems Thinking tells me, that I should get a coach in touch with the team to observe what happens to their informal routines at the same time. This is going to be where the fun begins.

Conclusion

Maybe I was a bit harsh with Kanban in this post. In the past few years it has become a tool in my toolbox. Nevertheless my tester mindset keeps on challenging statements I read from the Kanban community. The biggest struggle I had with the necessity for a process – leaving open whether this means a lived process, a process description, or a process model. I am still puzzled about this. Combining these thoughts with something I learned from Dan North about Accelerated Agile Delivery, I think it’s time for the Kanban community to think about getting more in touch with Agile coaches. These guys and gals know how to bring the formal and informal routines more in line with the Agile mind-set: to ship better products in less time.

Which Agile project management tool should we use?

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

(Source: Wikipedia)

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.

Pro-rating Testing Challenge

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?

What works in Product Backlog Grooming meetings

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.

Purpose and goals

The Agile Atlas Core Scrum part mentions the Product Backlog Refinement activity. It’s not necessarily a meeting, but up to 10% of the Development Team’s Sprint time might be used on refining the backlog.

The main purpose of refining the backlog lies in rebuilding the product backlog so that adheres to the DEEP criteria: detailed appropriately, estimated, emergent, and properly ordered (originally: prioritized, but I threw in a deliberate renaming based on recent changes in the Scrum guide).

Detailed appropriately means that we have some product backlog items very detailed. These should be at the top of the current ordering, and they surely will be implemented during the next one or two sprints by the team. On the other hand we have some vague ideas about the product in the future. Some folks call these epics, like large user stories, some call the themes. What really matters is that these are too large, too undetailed to fit into one of the next sprints. We surely have to work on them, refine them, before the team will be able to forecast them in a sprint.

In between there is a large variety of details in the product backlog items. Some are very high-level, others are close to being appropriately for the next sprint.

As part of the backlog refinement activity we have to work with the product backlog to be able to fill at least the next sprint with it. That usually means that we would like to detail enough stories for the next three sprints at most. Detailing more would mean to invest much more effort into unsure work in the future – that could be waste, especially when priorities change based on feedback from the market and customers. Preparing fewer items than for the next sprint accompanies the risk that the team at the next sprint planning will be able merely to plan two stories, where five would fit in. Most teams I have seen do well with having a constant pipeline of one to two sprints worth of backlog items “sprintable” in their backlog.

The backlog also should be estimated. That means we need to do estimation on those items we worked on. These two things together, detailing items, and estimating them, is usually what teams do when they speak about the Backlog Grooming meeting. The emergent and ordering parts – not so much.

That said, the main purpose for the Backlog Grooming meeting lies in preparing enough Product Backlog Items for the next Sprint. Depending on your Product Owner’s rendevouz demand with other folks, you may also need to work on some larger stories, estimate them, and prepare them so that the scope for the current release can be communicated.

Duration and frequency

Time-boxing is a way to foster hard-to-make, critical decisions. In Scrum all meetings are time-boxed. That should also yield for the Backlog Grooming meeting.

Given the Development Team can help the Product Owner on the Product Backlog Refinement up to 10% of their time, that means we could schedule a one day long Backlog Grooming meeting with the whole team on a two week sprint length. I wouldn’t do that. It not only would mean that the team cannot work with the Product Backlog during the rest of the sprint. It would also mean that the team is pulled out of their current sprint for a full day.

What I have seen working for most teams is a weekly one hour Backlog Grooming meeting. When the Sprint starts on a Wednesday, for example, I would schedule the grooming meeting for Mondays. As a Coach or ScrumMaster I would also help the Product Owner to prepare the stories for the grooming meeting, and if there is not sufficient input for a full grooming meeting, I would either cancel the meeting, or make it shorter.

The frequency with some offset to the review, retrospective, and planning meetings helps to make sure you can still clarify open questions for the highest priority items before the planning meeting. Otherwise you would have to leave out an unclear item from the current sprint, even though it has the highest priority right now. That’s usually not a desire.

With one hour each week you also help the Development to focus on their current work most of the time. Your mileage might vary, indeed, but I would be worried if you have to use more than two hours every week on grooming your Product Backlog. That either means that the knowledge gap between the business side and your Development Team is too large, or you have too many uncertainties in your current backlog. Oh, of course, it might also mean that you are deeply into team building, and people try to distract with their hidden agendas during this meeting. Regarding the knowledge gap, you should try training some of the team members in the business domain, either on-the-job with end users and domain experts, or merely send them on a course. Regarding the uncertainties, that might mean that you need to bring a subject matter expert on your team to help them, or you need to invest more effort before being able to have an item in a sprint. These issues usually shouldn’t be solved with more grooming, a longer meeting, etc. The grooming demand instead makes you aware of a potential problem that you should tackle differently.

Participants

At least you need someone with a business domain background, one with knowledge about technical limitations, and one who can challenge the thoughts in the room for completeness, or validity. At least this includes the role of the Product Owner, a programer, and a tester. Some teams do well with just these three experts on their team. Other teams find it more useful to include everyone available in it. I usually start with the latter approach, and lower down the number participants when necessary.

Approach

With the purpose mentioned above, the Product Owner takes the first product backlog item that needs to be either estimated or become more detailed, and the team explores ways to do that. Ellen Gottesdiener and Mary Gorman’s Discover to Deliver provide some more details on this. For the estimation part things like planning poker, bucket estimation, or blink estimation come to mind.

For the detailing part, usually that means to break down backlog items by using one of the splitting cheat sheets available, or exploring ways to break a larger item down into several smaller ones by simply talking. Nonetheless you should be aware of strategies like Dimensional Planning for this as well…

The key thing here is that you should not talk through the whole Product Backlog in one hour every week. That will be dragging for everyone involved. Instead, focus on the most immediate priority. That usually is to be able to fill a sprint from the current Product Backlog. With the time-boxing to one or two hours, you might end up being partly through the backlog, and that’s absolutely ok. In the next week you will be getting deeper into with the next stuff.