Lawless Agile
In march 2012 seven it-agile people (including me) formed the StartupMarch team. We decided to build a product to make online discussions more effective. In the end we had built http://www.discuss2decide.com and http://www.discumeter.com.
This blog post is about the “process” we used. We just started to build the product – without any discussion of the process to use – Scrum, Kanban, XP? We just didn’t talk about it. This is what emerged:
- Before the start of the StartupMach we only had decided on the problem to solve (online discussions) and the technology we would use (Rails). So we invested the first day for some conceptual work.
- At the second day we started the development of the first ideas. We had the first product (Duscuss2Decide) live at day 3 and the second (Discumeter) at day 5. After that we had more than 15 releases per day. The rule was simply: whatever you commit into the master (aka Trunk/Head) will go live immediately.
- Typically we started the day with an informal wrap up of the product usage (a kind of review if you want). Then we discussed what to do during the day (kind of planning). And then we did it. For both “meetings” together we invested 30 to 90 minutes.
- During the day we had 2 to 4 sync meetings to check where were and how to proceed (kind of Daily Scrum).
- We did no Task Breakdown but Story Splitting on a very tiny level. We worked with MMFs (Minimal Marketable Features) that we broke down into User Stories. Most stories were done in less than 2 hours.
- We managed work in progress by gut feeling. Normally we all would work on the stories of one MMF (single piece flow). That way a MMF normally needed one day to complete.
- We did Pair Programming in most cases and often switched pairs at the sync meetings.
- We had two retrospectives. One in the middle of march, one at the end of march.
- There were no roles. No Product Owner, no ScrumMaster, no Testers etc. Just team members. During our second retrospective we had a discussion about the roles. The conclusion was that we sometimes would have profited from a ScrumMaster for facilitating discussions and forcing us to face uncomfortable facts. And we thought that the absence of a Product Owner person was helpful. The team was not only empowered to decide on how to do the work but also on what to work on.
It was a great time. We had a lot of fun, we learned a lot and it felt very productive. Although we didn’t acquire millions of venture capital for our products, Discuss2Decide seems to have value for users. There are some regular users of the tool and most online discussions at it-agile are done with the tool today.
Will it travel?
Will the “process” travel to other contexts? I don’t know. I think there were two special ingredients that are uncommon and may have been crucial:
- With the seven team members we had roughly 45 years of experience with Agile of different flavors in the room: Scrum, XP, Kanban, FDD.
- All team members shared a common cultural background (it-agile) that showed up as an extreme openness for other’s ideas, perspectives and needs.
JAX: Auf der Suche nach dem Qualitäter
Auf der diesjährigen JAX haben Arne Roock und ich zusammen ein Theaterstück in Sherlock Holmes-Stil zum Thema Qualität in der Softwareentwicklung vorgeführt.
Scrum in project business
Scrum is for product development. Check. There is the Product Owner, the Product Backlog and the Product Increment. Check. There is no project in the Scrum framework. Check. But…
What does that mean for all the service providers that are in the project business? They develop whole software systems and single features for clients. Therefore they face a broad range if project sizes: months or years with complete teams as well as one to ten days for a single developer. Therefore one of challenges for these companies is the so called resource management: How to staff all the projects and how to ensure that everybody is working on paid tasks.
When applying Scrum to these contexts I recommend to ignore the Scrum framework for a while and think about the Scrum core. That is – in my humble opinion: a cross-functional team with end-to-end responsibility that applies inspect&adapt to the what and the how of their work.
Therefore I suggest to start with the team and not the project: form long term stable teams and reorganize work so that it matches the team concept. Every team has its Product Backlog with all the thing they plan to deliver. These may be features of a larger development project mixed with single feature requests. Assign a Product Owner and ScrumMaster to each team or even better let the teams self-select Product Owners and ScrumMasters.
E voila: Ready to start with Scrum for projects and a lot of new options will occur. The teams could take over additional responsibilities like writing the offers, managing customer relationships, hiring new team members etc. Be prepared to be surprised.
References
- Tobias Mayer discussed the cultural aspects of projects vs. teams: Team Culture, Project Culture.
- Karl Scotland suggested to favor teams over projects in Kanban, too: Linking Flow, Value and Capability.
- Jurgen Appelo says it is short-sighted to organize cross-functional teams around projects: “Teams” (The Same Mistake All Over)
Scrum for Top Managers
“As a top manager I want to introduce Scrum.”
“Don’t!”
“What?”
“Ok, you are used to say people what to do. But Scrum is about not saying people what to do. You should not start the journey to self-organisation with command&control as the first step.”
“So I am not allowed to do anything? I just have to sit here and hope that something changes for the better? You are kidding!”
“Of course you can do something. To make change happen you have to do something. But focus on the goal not on a specific approach like Scrum, XP or Kanban. So what is your primary goal?”
“I want shorter time to market and better products.”
“Fine. You could tell the team that you want to see running software demonstrated to happy customers every 14 days. And you leave it to the team how it achieves this goal. You should offer your help when impediments occur and you could offer to hire a coach. But the most important thing is: don’t interfere with the work the team is doing. Focus on their achievements.”
StartupMarch@it-agile 2012
In March 2012 seven it-agile members formed a Startup team that tried to solve common problems with online discussions. We created two products (http://www.discuss2decide.com and http://www.discumeter.com), learned a lot and had a barrel of laughs.
Me and my collegues will write and talk about our experiences with Lean Startup, customer development, agile to the extrem, continuous deployment (we had about 15 live deployments per day) and more. I will collect all these ressources at this page.
Here is, what we have by now:
- Even before we started Henning wrote about the idea of the StartupMarch: “Lean Startup March: Ich bin dabei” (german)
- Henning blogged about his impressions about only 3 days: “Lean Startup March: discuss2decide.com – 1. Auslieferung an Tag 3” (german)
- Henning wrote about Lean Startup and the sometimes limited value of numbers: “Lean Startup March: Zahlen, bitte!” (german)
- Henning created a short video with some impressions of our team. (german)
- Markus interviewed the participants before, during and after the Startup March. (german)
- Manual wrote about some of our experiences and lessons learned: “The it-agile Startup March: Lessons learned” (english)
- Doreen blogged about incremental UI design and incremental UX: “Inkrementelle Designentwicklung” (german)
- I talked about Lean Startup and our experiences at the JAX conference 2012 in Mainz. The german slides are on slideshare.
- I wrote a blog post about the “process” we used: Lawless Agile
Buchtipp: Maverick
In letzter Zeit gibt es vermehrt Diskussionen darum, wie eine agile Organisation aussehen müsste. Radical Management, Management 3.0, STOOS etc. sind die aktuellen Schlagworte. Eine sehr frühe und sehr weitreichende Implementation dieser Ideen findet sich beim basilianischen Unternehmen SemCo. Der Besitzer Ricardo Semler beschreibt in “Maverick”, die SemCo-Geschichte. Und auch wenn das Buch bereits 1993 geschrieben wurde, hat es an Aktualität bis heute nichts verloren. Ich empfehle das Buch allen, die sich für agile / empowerte / menschenfreundliche / moderne / scrummige / schlanke Organisationsstrukturen und Führungsstile interessieren.
März 6, 2012 at 8:21 nachmittags Hinterlasse einen Kommentar
Artikel “Auf der Suche nach dem Qualitäter” erschienen
Mein Bruder Arne und ich haben zusammen einen Artikel mit dem Titel “Auf der Suche nach dem Qualitäter” im “Business Technology“-Magazin veröffentlicht, das in der Ausgabe 1.2012, Heft 8 ganz unter dem Titel “Qualität” erschienen ist.
In dem Artikel beschäftigen wir uns mit der Frage, was überhaupt Qualität ist und stellen die klassische Qualitätsdefinition (“Qualität ist die Übereinstimmung der Realisierung mit den Anforderungen.”) in Frage. Wir stellen die kundenorientierte Qualitätsdefinition (“Der Kunde definiert, was Qualität ist.”) dagegen und bringen diese mit agilen Verfahren wie Scrum und Kanban in Zusammenhang. Nicht zuletzt zeigen wir auf, wie die kundenorientierte Qualitätsdefinition in der Softwareentwicklung besondere Herausforderungen an die interne Qualität des Systems stellt.
Auf der JAX-Konferenz werden wir übrigens zum gleichen Thema zu sehen sein, allerdings in einem etwas ungewöhnlicherem Format (Schauspiel).
März 5, 2012 at 5:55 nachmittags Hinterlasse einen Kommentar
it-agile: State of Play
We founded it-agile seven years ago. This is a good reason to reflect on what we have achieved regarding management and organization within it-agile. Some of the things listed below were already in place seven years ago, others are just a few days old.
We believe that our employees are it-agile with the implication that the best employees would make the best it-agile. And we do not just aim for satisfied customers, we want to delight our customers. To express these believes we have a defined purpose:
“Create fulfilling jobs for our employees to delight customers.”
We achieve this purpose by:
- Transparency and openness: Nearly every information is visible for every employee including the wages, travel expenses and time sheets of every colleague (the CEOs are just colleagues also). On a company level the economic data etc. are accessible for everyone.
- Peer groups: Employees have self selected peer groups that work with the employee on personal improvements and suggest promotions.
- Pull principle: We have implemented the pull principle for coaching and development. Customer requests are visible for the whole company and employees pull these. So employees may choose to prefer jobs in their local area and decide on themselves if they are capable of doing the job.
- Meetings at it-agile are optional. Every employee decides for himself if he attends.
- As long as the results are achieved everybody can work when and where he wants. (Of course this has to be coordinated with colleagues and customers since most of the results can’t be achieved without colleagues and customers.)
- Every employee has 30 days of slack were he can do whatever he wants: go to conferences, work on a self selected project, read books, go to trainings, … Of course it is transparent within it-agile what everybody did.
- Employees don’t apply for holidays. They decide on themselves when they take their 30 days of holiday.
- Overtime: There is no pressure for working overtimes. Sometimes employees decide themselves to work overtime to achieve important results. The overtime is collected in a work hour account. Employees decide when to withdraw time from that account.
- Expenses: Employees decide how they travel and what equipment they need for their work. They don’t ask for permission. They just buy what they need.
- Profit sharing: About 2/3 of the company profits are distributed to the employees (in principle every employee gets the same percentage).
- Company ownership: About 2/3 of the company is owned by the employees. This implies ultimate empowerment: The employees can change ANYTHING. They could even fire the CEOs or change the purpose of the company completely.
Is it successful?
We have more employees, we have higher revenues and we have higher margins today than we had in the beginning. You never can be sure if the described principles created this growth or if it just was good luck. But I think we were and are successful.
Will it travel?
In general the described concepts shouldn’t be taken as a blueprint for another organization (although there are similarities with other companies like SemCo). I think we wouldn’t have been able to start with out current state even if we had known it. I think that we observed a kind of co-evolution during the last seven years. We made a small modification to the organization of the company. That enabled a small progress of company culture. This progress in company culture then enabled the next small modification of our company structure and rules. And so on…
Will it scale?
We started it-agile with 10 people. Now we are 35. In my point of view the things we did enhanced empowerment and autonomy which are important building blocks for our growth. The changes we made enabled growth. I think for further growth we have to intensify empowerment and autonomy even more.
The Future
Since there is no big boss at it-agile you never know what will happen next. There are some very interesting and challenging discussions in the moment.
BTW 1: We are hiring agile coaches and developers. (Notice; Sometimes people seem to think they wouldn’t match our expectations and therefore don’t apply for a job at it-agile. There is only one way to find out: Let’s talk!)
BTW 2: We offer consulting to managers who want to transform their company/business unit in an agile way towards more empowerment and autonomy.
References
- Christian wrote about his first impressions at it-agile (in german), especially the transparency.
- Bernd did a presentation about some of our changes at the Lean Kanban Central Europe Conference 2011.
- Henning and Jens presented some aspects of it-agile (in german) at the XP-Days Germany 2011.
- Jens wrote about self-organization at it-agile (in german) in his blog.
- Markus wrote about mentoring and peergroups at it-agile in his blog.
- Bernd wrote about the it-agile slack model in his blog.
Vorträge “Innovation – das wahre Bottleneck?!” auf der OOP 2012
Auf der OOP 2012 habe ich einen regulären Vortrag sowie ein Pecha-Kucha zum Thema “Innovation – das wahre Bottleneck?!” gehalten.
Die Folien für beide Vorträge finden sich inkl. Foliennotizen auf Slideshare:
Inhaltlich geht es darum, dass meiner Meinung nach viele Produkte / Systeme zu wenig Nutzen erbringen und wir dieses Problem nicht dadurch lösen, dass wir Anforderungen schneller umsetzen. Wir müssen es dadurch lösen, dass wir wertvolle Features entwickeln, auch wenn wir dadurch etwas langsamer werden.
Self selected Product Owners and ScrumMasters
One of my clients (serving several customers with custom made solutions) decided to introduce Scrum. They grouped people together that worked in the same projects or for the same customers. The result were three Scrum Teams. The next step was challenging. Who should be the ScrumMasters and who should be the Product Owners? Should there be full time ScrumMasters or would it be a better fit if the ScrumMasters were also developers? Who could be a Product Owner? In one team there were several options. Would one candidate be pissed off if the management chose the other guy? In another team there seemed to be no perfect match. Should the second Product Owner candidate of the one team be transferred to the other team although this would mean loosing his experiences with his existing customers?
I introduced the idea that self organization is a powerful tool to solve challenging problem. Here we were: We had Scrum Teams that could self organize and we had a challenging problem (filling the Scrum roles). So it was decided to let the Scrum Teams decide who would be ScrumMaster and Product Owner. This was done in a workshop with all teams. The result was to some extend surprising to the management but they stuck to their commitment to let the teams decide.
I don’t know how good the selected ScrumMasters and Product Owners will manage their jobs. Independent of their future performance I think there are several interesting aspects in this story:
- The teams selected ScrumMasters and Product Owners in an hour or so. When management tried to select the roles it took much longer and provided no result.
- The Product Owners and ScrumMasters were selected by the teams and not assigned by management. I think that will help development team, ScrumMaster and Product Owner to act as ONE team without some kind of boss.
- If problems with the ScrumMasters and Product Owners would occur it should feel naturally for the Scrum Teams to select new persons for the roles.
- The management demonstrated trust into the employees and empowered the teams.
When I mentioned the self selection on Twitter there was doubt that the approach would be suitable for the Product Owner role. I can understand the doubts but like to think along these lines (assuming that there are sufficient Product Owner skills in the Scrum Team):
- If the Scrum Teams selects the person who would be selected by the management anyway, the management demonstrated at least trust into the team.
- If the Scrum Team selects another person, things really become interesting and there is great opportunity to learn something. Why does the team have another opinion than the management? Which opinion is more relevant to the success of the team? Is there a need and the possibility to reach consensus between team and management?
P.S.: I think it is totally valid for the management to assign the Product Owner. But is that really the best option – especially for a mature agile organization?
