A number of years ago I worked with an EDI (Electronic Data Interchange) team that was troubled with a large level of WIP (Work In Process) and slow movement of work through a system with many external dependencies. Work was regularly blocked waiting for unresponsive peers from the other companies. Work would languish in partially completed states and eventually be abandoned, either because the business relationship changed or the team gave up and turned their attention towards more likely prospects.Looked like great place to apply kanban
These sounded like great problems to solve with the help of the Kanban Method and I was eager to get started. This thinking, however, set us on an educational but somewhat fruitless path. The results weren’t what we expected.Applied the Kanban Method
We mapped out the value stream, modeled it appropriately in a kanban, and used the kanban system for a while to get visibility into the process and gain understanding. That was a success.
The Kanban Method helped us confirm that each analysis, development and QA step in their value stream took little value-added time. Nothing unusual or out of the ordinary was happening in any of the stages. We weren’t worried about vacations or someone getting hit by a bus. There were no bottlenecks.
The kanban helped us discuss Lean concepts and apply them to our situation.Got some benefits but nothing real or substantial – no WIP reduction or lead time reduction
Our initial goal was to visualize the process, reduce WIP, simplify prioritization, and look for improvement in lead-time, especially through reduction in delay. We got the visualization and felt we didn’t need as much as we got. We more fully understood the amount of WIP, but limiting it would not enable any additional swarming. Perhaps we got the simplified prioritization, but that came more from understanding the system and lean principles than from the Kanban Method or the kanban (the board) itself.
We didn’t achieve the lead-time reduction. We couldn’t. The delay was outside of our control.Outside of our control
The root cause was that the team was waiting for external IT shops to complete their part of the equation. It took several rounds of interactions with multiple people outside our company to complete a job. After our team did a little processing, the work item went to sleep in a blocked state and (maybe, someday) would be woken up by the external IT shop if they should decide to respond to our pleading.
Our group would benefit greatly from setting up EDI with their numerous business partners, but the other companies had no incentive to do their part of the connection. (Perhaps you are thinking that we needed to give them a financial incentive. We explored many ideas that just didn’t fit into our sales or business model. Changing the business model was another avenue of exploration but let’s save that for another post.) The times that the external group did respond, it was likely because they had some slack time and/or thought the task was interesting or challenging.It didn’t matter anyway
It really didn’t matter anyway.
Every integration with a 3rd party is of high value to our business — worth the cost of abandonment of work on a large percentage of opportunities. Each successful company pushed through the process is so valuable that it more than covers the costs incurred with those that fail.
Therefore, it was more important to have many “at bats” or “sales calls” than it was to have a short lead-time. Well, maybe ‘important’ isn’t the right word. It’s very important to complete work quickly, but in this case, it’s achievable to have more sales calls. We couldn’t improve our lead-time no matter how important that is.
A better way to look at it is we had extra capacity and used that to push more companies through the process (or, to create demand). We reached equilibrium where a hit suspends additional tries at-bat, and more at-bats ultimately increase hits. Work with an engaged external IT guy competes with making more sales calls. More sales calls yield additional willing external partners.
Yes, that will build up significant WIP over time. Whether we control WIP or not, many of the external companies aren’t going to cooperate and finish the process. We will abandon a lot of work. We try hard to finish whatever we start, but we can’t tell which work will be abandoned before we start.
Ultimately, we considered the cost of being a low priority and deemed it worth it.Lesson learned
Until this experience, I didn’t fully understand the lean principle of Value trumping Flow and Waste Reduction, a lean principle. I was aware of it, but I only thought I understood it. I knew that sometimes we should accept uneven flow if it helps us get value, but I was thinking that would only ever be exception cases. I was thinking that the norm should be to optimize smooth flow. The implication I had missed is that smooth flow isn’t always a general prerequisite for value. Considerable waste and huge WIP and horrible flow might just get you the most value.
(Anyone can get value if you have flow. This kind of environment isn’t for sissies.)
Finally, I began to think about this situation with the EDI team as having options, rather than as a great place to apply the Kanban Method or Lean Principles. I began to see the options in the system trumping the considerable waste, huge WIP and horrible flow.
The moral of the story is that real options thinking, systems thinking and many other such concepts present or yet to come may be more appropriate in some cases than Lean/Kanban thinking. Lean/Kanban thinking is useful, but it isn’t all there is.
Somewhere in the last decade, I had a similar revelation about eXtreme Programming.
With every shiny new hammer, I find more things that look like nails.
So ein ScrumMaster-Job kann gehörig aufwühlend sein. Je nach Projektphase geht es zum Teil hoch her. Widerstand gegen die Veränderung, Unverständnis über das neue Vorgehen, Kollegen, die immer noch einen drauf setzen müssen. Da bleibt die gewünschte Anerkennung von außen oft aus und es fehlt die innere Balance, sie aus dem eigenen Herzen zu holen. Wo kommt sie dann her – die Zuversicht, dass alles gut wird und man auf dem richtigen Weg ist? Wie baut er sich auf, dieser Fels in der Brandung aka ScrumMaster?Hast Du es schon mal mit Meditation versucht?
Es gibt Schulen, die sagen, ein moderner Leader kommt ohne zu innerer Balance verhelfender Meditation nicht mehr aus. Beim Verweilen im gedankenlosen Raum der Leere tauchen sie auf – die unbequemen Sätze vom Chef heute, die ungelösten Probleme aus dem Projekt, die Reue über die harsche Antwort an den Kollegen. Dann sitzen wir da und irgendwann (mit der Übung wird es immer schneller) merken wir, was wir da gerade so denken. Jetzt wird uns bewusst, wo uns etwas aus der Bahn gebracht hat, auch wenn wir es zunächst geschafft hatten, es zur Seite zu schieben.
Es gibt viele Varianten von Meditation. Einige konzentrieren sich in erster Linie auf das Schaffen von Bewusstheit. Sind wir das nächste Mal in einer ähnlichen Situation, merken wir vielleicht schon im selben Moment: “Ach, das ist doch wie beim letzten Mal”. Und wenn uns das ein paar Mal passiert, schaffen wir es vielleicht irgendwann, uns anders zu verhalten. Jeder, der schon einmal eine Fremdsprache gelernt hat, kennt diesen Effekt. Man wird auf einen Fehler hingewiesen und wenn man ihn das nächste Mal macht, wird man unsicher. Irgendwas war hier, doch weiß man noch nicht so recht, welche Variante die richtige ist. Irgendwann weiß man Bescheid, sobald man sich die falsche Variante sagen hört und man kann sich sofort korrigieren. Und zu guter Letzt sagt man es dann gleich beim ersten Mal korrekt.
Was ich damit ausdrücken will: Verhaltensänderungen brauchen Geduld, und Meditation ist ein möglicher erster Schritt auf dem Weg dahin, indem sie uns hilft, uns jene Themen, die uns aus dem Tritt bringen, bewusst zu machen. Als zweiten Schritt braucht es die Entscheidung, es in der Zukunft anders zu machen. Und dann braucht es Geduld und Beharrlichkeit.
Und Meditation kann noch mehr. Neben der Bewusstmachung als Basis für die Veränderung hilft sie uns, gleich jetzt Frieden zu machen mit dem was ist und war. Der Raum ohne Gedanken ist ein guter Ort, um seine Wunden und Schrammen abzulegen. Man kann sie wie ein Paket einfach in die Leere geben. Ohne weiter darüber nachzudenken, taucht man selbst wieder in den gedankenlosen Raum ein. Dort verweilt man so lange, bis der nächste Gedanke auftaucht, der uns so sehr bewegt, dass er es schafft, uns aus der Leere hinaus zurück in unsere Gedankenkreise zu tragen. Und der Kreislauf beginnt von Neuem, bis das Herz Frieden hat und ruhig sitzen kann.
Wenn das Gemüt in gar zu großer Unruhe ist, braucht es eine explizite Bearbeitung der Situation. Hier hilft oft ein Gespräch mit Freunden oder der Familie. Bei beharrlichen Themen empfiehlt sich die Zusammenarbeit mit einem Coach und mit Selbstcoaching-Methoden, wie z.B. einem Tagebuch. Um kurzfristig Dampf abzulassen hat sich ebenfalls Sport sehr bewährt.
Liebe ScrumMaster, was sind Eure Rezepte bei innerer Unruhe, bei mangelndem Gleichmut und verschwundener Gelassenheit, oder gar dem Verlust der Freude und Begeisterung für Eure Arbeit?
- Führung in Scrum | der Manager | Verhalten | Teil 2
- Summer School Weekly Cartoon: Teamführung
- 25. und 26. März | offenes CSM Training in Berlin
Eine Situation unlängst in einem meiner Kundenprojekte: Die aufwändig in mehr als 5 Monaten entwickelte Software-Lösung befindet sich im großen abschließenden Test durch alle Fachbereiche. Es ist ein zeitintensives Verfahren, da viele Stakeholder involviert und jede Menge Testfälle abgearbeitet werden müssen. Ein in der Mitte des Integrationstest gefundenes und zunächst klein aussehendes Problem entwickelt sich während der Analyse zusehends zum „Show-Stopper“. Wichtige Plausibilisierungsprüfungen für den Geschäftsprozess finden wegen einer falschen Logik keine Anwendung. Das To-Do ist schnell klar: Die Methode muss umgeschrieben und verbessert werden, die Anpassungen sind überschaubar.
Was zunächst einfach klingt, gestaltet sich auf den zweiten Blick äußerst problematisch. Die Anpassung muss in einem zentralen Baustein der Geschäftsprozesslogik angepasst werden – das hat große Auswirkungen auf die Geschäftsprozesse. Die Software und Prozesse sind nur sehr mangel- und lückenhaft mit Unit Tests und automatisierten Testskripts abgesichert. Änderungen könnten großflächige Nachtests aller Geschäftsprozesse bedeuten, welche die Produktivsetzung der IT-Lösung um Wochen verzögern wurde. Gute Ideen sind nun gefragt …
Nach einem hektischen und diskussionsreichen Brainstorming hat das Team einen vermeintlich vernünftigen Weg aus der Misere gefunden:
- Die betroffene Methode soll in einem ersten Schritt umfangreich durch zahlreiche Unit Tests an den Schnittstellen abgesichert werden.
- In einem zweiten Schritt wird die Methode überarbeitet und mit Hilfe der Unit Tests auf deren gleiche Funktionsweise getestet.
- In einem dritten Schritt sollen einzelne Testfälle des Integrationstests stichprobenartig wiederholt werden.
Müsste ich eine Analogie für diese Vorgehensweise finden, würde ich die Operation am offenen Herzen wählen. Auch in der Medizin wird versucht, das Herz so gut wie möglich vom Rest der Organe bei gleichzeitiger Beibehaltung seiner Funktion zu isolieren. Beide Vorgehensweisen bergen Risiken, aber sie sind deutlich geringer als bei einem rigorosen Vorgehen ohne vorherige Absicherung bzw. Isolierung.
Wenig überraschend ist, dass die nachträgliche Absicherung der Methode deutlich aufwändiger ist, als wenn sie gleich von Beginn an testautomatisiert aufgebaut worden wäre. Gerade dieses Beispiel hat mir wieder gezeigt, wie wichtig es ist, bestehende Funktionalität gewissenhaft abzusichern, um Änderungen im Code vornehmen zu können. Denn diese Änderungen werden kommen, ganz gleich ob durch Fehler oder neue Anforderungen bedingt.
Respond to change … Start code test-driven!
- Unit Testing: Still Widely Informal / Methods and Tools
- Test Driven Development (TDD) und Scrum | Teil 1
- Certification Test is Postponed
More and more companies realize that focusing on cost savings alone is no longer good enough in today’s fast-paced world. In a competitive landscape where customers have many more options and smaller startups can easily disrupt giants, we need to shift to a value-focused mindset to remain competitive.
Value management in a portfolio context refers to strategic business value (more than the aggregate value of a collection of user stories.) Portfolio-level agility is about optimizing the delivery of that business value.
We introduced the concept of value management in "Portfolio Management for the Fast-Paced World":
“Value management asserts what value is, so we can look at the entire Lean perspective of 'concept to cash' in a value stream. This supports both a more traditional scoring model and benefits realization, as well as approaches like Lean Startup’s Build-Measure-Learn cycle. This pillar represents the portfolio demand -- the demand for development work. “
Value management is a hot topic and we'll be writing about it in the coming months. It’s also an area in which the industry has few experts so engaging with those experts wherever you can is a great way to advance your expertise.
Here's the expertise you should gain if you’re accountable for defining value:
- Adopting methods to detect business opportunities
- Defining market sizing
- Forecasting revenues in new markets
- Understanding existing customer alternatives to get their job done
- Building lightweight business cases
- Picking the “right” things to build from the many possibilities
- Measuring post-delivery value by understanding net lifecycle profits
The problem is that in a fast-paced world, there’s no time to do all those things at a level of detail prescribed in traditional product management curricula. Just as new principles of capacity planning are called for, Value management needs new ways to keep up with the accelerated rate of business. Product management practices must evolve to meet the modern needs of value management.
Agile and Lean practices are popular because they keep pace with the rate of today’s business. Applied to product management, these practices help us retool our product management practices with lighter-weight processes. For instance, minimum viable business cases help us adopt incremental funding methods to redirect funding where more value can be delivered. By the time you write a traditional business case, the opportunity may be gone. Instead, think of applying the continuous cadence planning principle to value management.
In product companies, the product manager role has historically been responsible for defining value as a set of features. In IT, line of business managers and business analysts have been the more common roles, although IT groups could greatly benefit from taking a product lifecycle approach to their work. (Topic for another blog….)
As value receives a bigger focus in organizations looking for greater business agility, various levels and dimensions of value come into play and more roles get involved in value definition. For instance, product manager and product owner are two distinct roles, each having an integral contribution to defining value: product managers define the right features to build, and product owners define how to build the features right. Together they can “Build the Right Thing" and "Build the Thing, Right”. Other roles involved in value definition include business leaders, who track which markets are worth doubling down on; and portfolio managers, who balance longer-term value with shorter-term wins.
The Scaled Agile Framework® (SAFe) has pushed the industry to take a big step forward by making a clear distinction between the product manager role and the product owner role, addressing a pitfall we documented several years ago: when development first adopts Agile practices, there's a propensity to reallocate existing product managers to the product owner role, inadvertently equating the two roles. Merging these two roles causes an organization to lose sight of the evolving business value Agile teams are expected to deliver to their business stakeholders. Prioritization then focuses on what we can do rather than what we should do, and that undermines an organization’s ability to match demand and supply, which maximizes value delivery. Thank you, SAFe, for distinguishing between the two product roles!
However, SAFe and other scaled Agile practices still come up short in guiding organizations on how to define value, and gain the expertise listed above. That’s why we’ve added Building the Right Thing to our Agile University offerings.
The class is taught by expert Linda Merrick from Rally partner Pivotal Product Management. Linda has over 29 years of product management expertise, with a deep understanding of Agile product management. Her class covers the various roles and dimensions of value definition and helps you build the capabilities your organization must acquire to reliably define value, so that development efforts are spent on building the right products and applications. For IT environments, the class also offers practical advice for taking a product approach to IT, a key factor for IT groups delivering business value.
As you enjoy the end of the summer, don’t pass on the opportunity to bring these capabilities into your organization. You may find yourself better equipped to answer the question, “What should we focus on next year?” Our next Building The Right Thing classes take place Sept 9 in gorgeous Boulder, Colorado, and Oct 14 in (not bad either) Raleigh, North Carolina. Take the opportunity to visit our Rally offices during the class breaks!
Wondering how innovation fits into value management? Browse our interactive Enterprise Lean Startup overview.Catherine Connor
We’re excited to announce Axosoft’s Version 14.3 Release! Here is what you can expect in the newest version:
Teams: Make team management a breeze by organizing your users by teams and sub-teams.
SMS settings: Let Axosoft send you text notifications on your mobile devices.
UX boost: Drag and drop images into text fields, copy and paste images into large text fields, see user gravatars in card view and more.
This is a big one. Many of our customers (that’s you!) need the ability to group users together in the system to manage their progress more easily, gain better visibility, and include the whole team. Hence the introduction of team management.
You can now assign items to teams, filter by teams, send notifications to teams and more. Teams are located under the Users and Teams section of the Organize panel. This is where you group your main team and create smaller teams within a larger grouping of users as well.
In short, anywhere you could assign an individual user to something, you can now assign a team. Plus if the team ever changes it’s easy to update the roster for the next cycle.
Ah texting. For those of you who love your mobile devices, we now give you the ability get text notifications from Axosoft (US and Canada only). Go to Tools/ System Options/ SMS settings to enable SMS settings. For hosted customers, that’s all you need to do. If you’re an installed customer, you will need to create a Twilio account to configure the SMS feature in your network.
Once enabled, go to Tools/ Notifications/ Manage to edit a notification template and enter a phone number in the recipients box. You will then get a text from Axosoft anytime an item is created, changed, or deleted.
This functionality will be free while in Beta.
It’s the little things that count. That’s why we’ve updated several smaller features to boost your everyday use of the Axosoft Suite. We’ve introduced Global Dashboard Settings to allow quick changes to your whole dashboard. For example, by clicking the gear by the huge plus sign in your dashboard, you can now update the release or sprint for a particular dashboard once you’re ready to start the next cycle.
Here’s a quick list of other new functionality you can try with this release:
Copy and Paste into large text fields (drag and drop images too, yay!)
Right click to add a worklog
ID and title always in view when scrolling in edit mode
Gravatars now included in card view
Plus join us for our API Webinar on September 3rd to learn about the latest version of our API. That wraps up what’s new in 14.3. Stay tuned for more awesomeness!
The first four Principles of Capacity Planning start us on a planning journey to run a business more effectively. Here are the topics we’ve covered so far:
- The Team as the Resource Unit
- Getting forecasting efforts Roughly Right
- Matching Supply to Demand
- Using a Continuous Planning Cadence
This post addresses the value of tolerating incomplete data in portfolio planning -- a principle that applies to both demand and supply. Here are some specific examples for each.Demand Tolerance: Detail Initiatives Only As You Get Close to Scheduling Them
When we plan out 12 to 18 months, we’ll make decisions on less-accurate data than we’ll have for, say, the upcoming quarter. In other words, we’ll be less certain as our planning horizon moves farther into the future.
Experts and highly competent professionals strive for perfection. Big planning mistakes have ruined careers. Yet to be successful, leaders must make decisions using imperfect information. Strategic planners have to navigate uncertainty and risk as investment scenarios become plans of record. To have a reasonable chance of success, we must know something about the investments we select to execute on: the rest of the information is either knowable or unknowable. There is a huge cost associated with gathering this knowledge. On the other hand, tolerating incomplete data is no excuse for ignorance.
A prominent, former presidential cabinet member advised that you not take action if you have only enough information to give you less than a 40 percent chance of being right; but that you shouldn't wait until you have enough facts to be 100 percent sure, either, because by then it’s almost always too late. This instinct is right: excessive delays in the name of information-gathering leads to analysis paralysis. Procrastination in the name of reducing risk actually increases risk. For example: one Fortune 500 organization was spending so much time to have 100 percent of the decision-making information that its approval process took years -- longer than the time required to implement the approved projects and programs.
When applied to an annual cadence, expect to be on the low end of this information-gathering range (around 40 percent.) At this point you’re planning at more of the initiative level, maybe with some features identified. With roughly right estimates, we will set ourselves up for more accurate near term plans. Within a quarter, I expect to be closer to 70% because I should have more complete information. As you embark on continuous planning cadence, the ability to manage uncertainty becomes much more tolerable because you know you will have the opportunity to inspect and adapt at more frequent intervals. In today’s fast-paced world, the cost of delay can be so high you have no choice but to get comfortable with operating on good-enough data.
One of the proven benefits of Agile software development methods is that you can adapt to necessary changes in schedule and priorities, and avoid the misalignment of scheduling work far ahead of execution. In a continuous planning cadence, annual planning becomes part of long range business commitments, forecasting and budgeting, while scheduling becomes part of rolling wave prioritization and value delivery.
Ironically, traditional sources of guidance support the notion of tolerating incomplete data. According to PMBOK, “A Planning Package is a work breakdown structure component below the control account with known work content but without detailed schedule activities.” Each organization should determine its policies for when it’s feasible to refine details and schedule them. Our experience shows that this planning horizon for prioritization and value delivery in today’s fast-paced world is about one quarter (three months.) With these rhythms, we can get better at operating on “good enough” data.Supply Tolerance: Fuss Only When You Must
When working with large customers, we’ve found that most managers have been burned by failing to pay attention to the scarce capacity of specialization areas. Examples include UX designers and DBAs, as well as expertise specific to a company technology environment, such as network or security engineers. The cost of not accounting for this scarcity of talent is an overly optimistic plan that does not match the reality of what can be delivered. This is one criticism of Agile methods to-date: they lack a good approach for handling exceptions to cross-functional teams.
The key to tolerating incomplete data is to plan at the delivery group level and, if necessary, the delivery team level. This respects the principle of the team as the resource unit and has the added advantage of simplifying the capacity planning exercise by a factor of 10 (roughly assuming 10 individuals per team.) Only when planning at the team level isn’t roughly right do we fuss more, usually because of the need to pay special attention to scarce expertise. Because managing expertise adds overhead to matching supply to demand, the goal is to fuss only where you must!
How do we fuss just enough? Let's take the example of a fictitious company that has both retail brick and mortar stores and a successful online presence. Initially, this organization had a platform delivery group that provides all the backend services. Every other delivery group was dependent on the platform group. With so many dependencies, managers were constantly scrambling to remove bottlenecks and resolve schedule conflicts. The solution was to distribute the platform delivery group onto several of the other delivery groups so they could be made “whole” (each group had what is needed to deliver value with minimal external dependencies.) By designating “platform” as an expertise, and just a little extra fussing to account for platform constraints, we can match supply and demand and have better results.Roles and Expertise
Expertise can be used to support flexible resourcing. Take, for example, an organization that has several delivery groups, with some aligned to specific products. Most of the time, each delivery group is self-sufficient in delivering their allocated work. When there’s an unusually high need for a given expertise, the delivery group can be augmented by providing additional capacity from other delivery groups for that expertise. One customer told us, “We rob teams from Peter to pay Paul all the time in order to deliver maximum value.” Expertise should only be fussed with when we must.
What about roles? Modern capacity planning strives to use role as an attribute of a team. Applying roles to teams helps identify team competencies and provide convenient capacity planning building blocks. A team’s role can be thought of as expertise. Although we value teams over individuals, we recognize that individuals are the basis of great teams (it’s commonly cited that a good programmer can outperform a mediocre one by a factor of 10.) When the team is the fundamental planning currency, the need to fuss about the roles of individuals diminishes. Thus, resist the urge to track capacity of individual roles within each team. For planning purposes, this would be artificially precise (read more about the capacity planning principle of “roughly right.”)
This blog rounds out the five principles of modern capacity planning that should help you have a less dreadful annual planning season. If you'd rather listen to an overview of these principles, check out the "Business Agility and Annual Planning: Solving the Paradox" webinar.
Most importantly, don’t waste any more time creating precisely wrong plans when you can leverage Rally’s expertise in portfolio capacity planning.Brent Barton
How diversity helps us in problem solving, creativity and overall intelligence? It helps a lot. Diverse groups of people can produce better results and radiate more creativity. But what about your own, personal diversity? Is it a good idea to accumulate knowledge from wide range of disciplines? Does knowledge of music theory help to write better code? Does knowledge from biology make you a better user experience designer? I believe yes, and here is why.Escher Butterfly Wallpaper by MPCine
Douglas Hofstadter and Emmanuel Sander wrote a very controversial book Surfaces and Essences. It is not an easy read, but it is time spent well. Authors unfold thinking process from language to high level constructs. They show how analogy-making helps us think, generate new ideas and fuel our creativity, including scientific insights.
This book deeply resonated with me. In general I agree that analogy-making is a core of our creativity. I even tried to apply knowledge from Running domain to Software Development domain and generated some quite interesting ideas like Interval development. Sure these ideas can’t be proved easily, since analogy doesn’t mean the idea is great. But still it is relatively easy to take knowledge from one domain and apply it to another domain.How can it help me?
All that brought me to the idea to increase my personal diversity and expand my knowledge beyond typical areas like system thinking, software architecture, groups dynamic, innovation models, user experience and other stuff every CEO learns. I read books and took courses about quite diverse topics already, but I did that in a chaotic way.
Suddenly it became obvious to me how all these new domains can help me to be more creative and solve problems better.What domains should I explore?
I think you should try anything you always wanted to learn, but didn’t have time to. It is quite hard to predict what analogies can be generated from unknown domains. For example, you always wanted to know how people paint, how art evolved and how Michelangelo painted a fresco of The Last Judgement on the altar wall of the Sistine Chapel. Dig into the art domain and learn as much as you can in a single year. Will it help you to be a better software developer? Why not? If you try to paint something you can train patience and learn how to sketch (everybody should sketch, you know). Michelangelo’s approaches may give you some ideas how to structure your work. As I said, it is hard to predict exact ideas that you’ll generate in the end, but I promise you will generate some.
I personally want to study biology, music theory, architecture, education, medicine, go and swimming. If a simple running domain gave me new insights, I believe larger and more complex domains will bring even more value.Why one year?
A year is a good timeframe to focus on something. It will be your new hobby for a full year. You can read 20+ books, take 1-3 online courses, maybe take offline courses, try to apply your new knowledge constantly. Small domains demand less time, but larger domains are hard to grasp in 2-3 months.
I don’t believe in quick solutions. You can read a book or two about a subject and have some fresh air in your head, but it is not enough to just scratch the surface. In 10 years you will have a decent knowledge in 10 domains. That sounds cool to me.Did you try that?
Nope. I started to dig into music theory recently. So far I’m just sharing the idea with a hope that there is always a chance you’ll like it and give it a try.
And maybe, just maybe, you’ll even find your new passion. Who knows?
This is my personal humble feedback on Agile Conference. I do make broad conclusions though, so feel free to provide your vision in comments.
I haven’t visited Agile conferences for like 5 years, the last one was in Chicago. It was pretty good. The main innovations were Kanban and UX+Agile. Many sessions were still quite boring to any experienced agile practitioner. Now I’m in Orlando. Conference becomes huge. There are so many people around. But what about sessions? In 3 days I visited exactly one session that was really interesting and useful, it was about Netflix culture at DevOps track. All the others I visited were not useful, boring, kinda OK, way too abstract or completely trivial. Maybe I was just unlucky and missed all the good talks. Maybe, but I picked carefully, to be honest. I talked to some people and received mixed feedback, but in general it looks like conference content is not great. DevOps track looks very good, BTW, and I heard many good words about it.
How do I feel about all these things you ask me? I personally see a serious stagnation and the lack of innovations in agile community. Don’t get me wrong. There are bright people with brilliant ideas, but it seems they are in opposition to the main trends. How’s that happened?
Agile is about helping businesses to kick ass. To do that, there should be innovations in various directions. We, as an agile community, should invent new ways to help business understand what is valuable and what is not. Invent new development practices and try them in various contexts. Inspect organizations as a whole and invent new ways to detect problems and solve them on a system level. But what we have at the moment?
There are many topics about Scaled Agile frameworks. I visited several sessions and I have an opinion that speakers have no clue how to really scale agility. Proposed frameworks are kinda prescriptive and heavy. They reminded me RUP-days. You really can create a good framework based on RUP, but there were few successful cases.
SAFe looks complicated and it does not address root problems on my opinion. We need real structural transformations, while SAFe implies specific receipts and says that it will work in almost any context. How is that possible? Everything is context-dependent, and that is why many agile transformation initiatives failed and will fail. People just apply a recipe without deep thinking, ignoring context-specific things and expect it to work. It won’t work in many cases, and you can’t fix it without context-awareness.
SAFe has many good practices inside. It can help companies initially and you will see some tactical success, but I also think that in the long run SAFe is a strategic disaster. It may take 5+ years to feel that, but I don’t believe that company will inject a true agile mindset starting with SAFe. It can happen, but it will be exceptional cases mostly. The really bad thing is that companies will not notice the problem. With waterfall the problem is (now) obvious, while with SAFe they will have an illusion that they are truly agile, while they are not.
So at the end of the day I have a perception that majority of speakers present some abstract theoretical frameworks with extremely poor argumentation. Why this might work? In which context? No clue.
I also wonder why we have no talks about Kanban here? Is Kanban agile or not? Agile community have personal troubles with Kanban approaches? C’mon, folks, this separation is childish.
All that sounds like rants without solutions so far. So I have some actionable proposals for the next Agile Conference. Here is my feedback:
- Add a decent mix of various disciplines. We can learn from complexity science, biology, sociology, sport, physics and other disciplines. Try to intrigue people from these disciplines to really mix their practices with our practices and invent something new finally. At least invite them to speak about things they know to stimulate our imagination and analogy thinking. Invite Dave Snowden, finally, to see his controversial view on scaling. There should be more perspectives. We need greater diversity.
- Have more real-life experience reports with real practices that work in some contextes. It will help to learn from each other and spread good practices. I know many good discussions are firing up between people, but why don’t do that on sessions as well?
- There should be more science. People over the world do great research about group dynamic, development practices, cooperative games, etc. Invite them to share their researches.
- Invite bright business people to talk about marketing, agile workspace, new hiring practices, strategy, etc. It will finally help merge Agile and business together. Nothing is separate. We should see high-level pictures and learn from them.
- 75 minutes talks? Are you kidding me? Nobody can control attention for more than 45 minutes. Split these talks and make workshops longer, since 75 minutes are not enough for a decent workshop. I’d like to see more TED-like talks, short and precise. Experiment with that at least. Inspect and adapt.
In short, Agile Conference demands more inventions, real-life reports, more science and different format. Conference organization is just perfect, it really is. I can’t imagine better. Content, however, is below average, and that is embarrassing for agile-minded community. We can do better.
The final thing is the slogan I saw yesterday. It is just unbearable to me: “Allow agile and waterfall work together” WTF?
I thought we were working on replacing waterfall and change the ways organizations work. Do we, as a community, still think it is a good idea? Or are we starting to agree with a status quo? I believe we are fucking not. There is no limit to perfection.
“Pirates are bold not safe” — These guys are doing something good
Last week, Sid Probstein, CTO of Attivio, and Andy Singleton, founder of Assembla presented a webinar about “Fast IT,” a new way of managing rapidly changing and Agile projects in areas like mobile, Web, analytics and marketing applications, while working smoothly with reliable core systems ("Core IT"). Andy discussed the dynamics of Fast IT, and Sid presented a case study of how Attivio spun up a major Business Intelligence app in two weeks with two people.
If you missed the webinar, view and download the slides.
Want an overview of Fast IT in 60 seconds? Watch the video below:
Get notified about new and exciting content around Fast IT by completing the form below:
Paying for your Assembla subscription with PayPal has never been easier. We recently added the ability to set up recurring payments with PayPal that will automatically pay for your Assembla subscription every billing period, whether that be monthly or annually. Previously, it was a manual process that required logging in and paying every time an invoice was created.
To set up automatic payments with PayPal, visit your billing page > select the PayPal option > and follow the steps.
If you have any questions or issues, please contact Assembla support at email@example.com.
Last week one of our stakeholders brought his pug dog, Lola, along to our product review meeting. “Watch out, she likes feet!” he joked but she remained quiet and well behaved throughout the meeting. Unruly is not the only place I’ve come across where dogs have been accommodated at work, another had a dog basket in their main board room. I appreciate not everyone likes dogs around but I like working for a company that’s not too stuffy to allow people flexibility to make our workplace more homely.
We’re lucky at Unruly to have a dedicated People & Places team who work closely with our Design team create a work environment that has personal touches. There are many informal meeting places around the building to make collaboration easy and it’s decorated with original artwork reflecting our culture. Little things amaze visitors as we show them around, for instance we created a two-way webcam portal between our London and New York office with a gold antique-style frame, which makes it seem more special and echoes Harry Potter where characters move around. What’s the business case? Creating an environment that allows human expression encourages creativity to flourish in our work.
The design of our workspace is not owned by a central team outside development. We recently reorganised our desks and unlike many companies, where a "Desk Move" is a dreaded logistical nightmare involving packing things up for another team to execute overnight, our developers simply got stuck into disassembling desks and lifting floor tiles themselves to get everything in the right place. Our spirit of collective ownership and taking responsibility for how our code structured seems to extend out to our surroundings. Taking care of our workspace, isn’t somebody else’s job.
Our teams use our walls and whiteboards for practical purposes but with a sense of humour too. Even electronic tools get a bit of customisation, we use Trello for our backlogs and teams can add distinctive backgrounds to make them easier to pick out.
Teams in bigger companies often find that their boards are the easiest areas to start personalising, when you introduce Kanban boards you can involve everyone on the team in designing the layout. Rather than diving straight in to moving things around, you can create a mini-version of the new layout with sticky notes. I think it’s important to give everyone on the team the opportunity to mull the proposed design over and allow time for tweaks. We’ve taken this approach with how we lay out our boards and our desks (as in the examples below).
I appreciate that many people work in organisations that don’t actively support personalisation of the workspace but you can start small with a potted plant, a team mascot, a little whiteboard artwork. You'll likely find personal touches are noticed and soon start to spread around surrounding teams. Another small step that you can take is to adopt iteration names or pictures that pick up on what’s going on in the outside world or reflect metaphorically on current mood within the team. In software development, we spend a lot of time in an office environment, taking care of your surroundings helps to take care of the people working within them.
XP is an approach that helps us to deliver valuable software iteratively, to apply it we need to setup our teams to make releasing change to customers as easy as possible. We avoid waiting around for individual team members to make changes, by applying classic XP practices -- Collective Code Ownership and Pair Programming. Each pair of developers is free to change any code that they need to without anyone vetting their changes, they ensure that all tests pass and keep code relatively clean by refactoring as they go. We share knowledge across the team by rotating pairs daily. If a pair runs into difficult decisions regarding design choices, they can call for a huddle with their team mates, sitting together in an open workspace means that's quick to do. This XP way of developing code is liberating as we can easily make changes in the right place rather than working around organisational barriers. It can be also be humbling, as our code is often improved by other developers as they pass through.
To work this way, we find it helps to build teams of extremely capable developers who can work on any area of the codebase rather than hiring a mix of frontend/backend/DBA specialists. Developers who only know enough to work in a single layer of the codebase limit who's available to pair on the piece of work which is most valuable to pick up next. At Unruly, we only hire “full-stack” developers, this gives us confidence that any pair of developers can work on any area of the codebase (within the products that their team is responsible for) without experiencing hand-offs and delays waiting for developers with a different skill set. It also helps avoid some of the friction that can spark due to single-layer thinking.
Being a full-stack developer is also much more than becoming a polyglot programmer. Laurence Gellert’s explains in his blog that there’s a greater breadth of skills that a “full-stack” developer needs. You’ll need to appreciate the environment that your live system runs within and have the technical chops to be at home with making environment changes. You'll also need to broaden your horizons beyond thinking about code and get to grips with developing a fuller understanding of the business you work in! Michael Feathers recently gave a talk in London where he used the term “Full Spectrum Developer” which neatly captures the idea that there's much more than being able to work across different software layers in a given architecture.
As the software craftsmanship movement has brought to the fore, serious developers need to take personal responsibility for improving their skills. Of course, becoming a full-stack developer is more than reading the odd business book in your spare time and writing toy programs in obscure languages when you get home from a long day at work. You can also get together with likeminded developers on a regular basis to hone your skills through Code & Coffee sessions outside work and work on pet projects like building games and mobile apps at home. But in my opinion, this only scatches the surface - you will only get to grips with being a full-spectrum developer by working in an environment that allows you to get your hands dirty across the full stack and interact directly with users and stakeholders. Typically these are startups or small companies that practice agile software development. If you take a look at our current open roles, you’ll see they’re much broader that you’d typically find in a large corporation.
As an agile coach working with product development teams at Unruly, my focus is on how we can support developers to expand their horizons, to gain a better understanding of our business and how they can help figure out the most valuable software to deliver iteratively. Our developers take responsibility for researching different strands of product development and identify the most valuable ideas to take through to implementation (I'll write-up more about how we do this in another post soon).
We also recognise that build learning time into our work week is essential for developers to stay abreast of new tools and frameworks. All of our developers get one day per week to dabble and learn new technologies — see my previous post about Gold Cards. We recognise that industry conferences can be places where you hear about new trends so developers get three days and an annual allowance to spend on attending any conference they feel is relevant to the personal development at work. Our developers also take turns running weekly coding dojos (during work time not through their lunch) to get hands-on practice time with new languages such as Go, Scala, Rust and mobile phone application development. Developers get the opportunity to share what they learned to other teams through lightning talks and this gives them practice in presenting too. All of these things are ways that organizations can support developers in broadening their horizons while at work rather than eating into their early mornings and evenings.
There are a few things for developers to weigh up when considering whether to specialise deeply or broaden their horizons. What do you sacrifice when following one path versus rewards to be gained? The main reward for full-spectrum developers is building greater confidence to dive into different technologies; you may spend less time writing code but become more able to deliver end-to-end solutions that hit the spot. As generalists, you likely have a wider choice of companies to work at and are more resiliant to industry trends. As specialists, you gain the pleasure of total immersion in a particular sphere of software while you build tolerance to the frustrations of waiting around for others to do their bit. It's up to you!
If your team uses Slack, HipChat, Flowdock, or Bigplans for communication, we have added preconfigured webhooks to make setting up these integrations painless. Once configured, you can selectively manage the Assembla events that are posted out to these apps, such as ticket activity, commits, deploys, etc., to monitor project activity in real-time, inline with other team communication.To get started, click on the desired integration below:
Ripple is a protocol for value exchange that makes it easy to transfer and trade fiat currencies, Bitcoin, or XRP - the native asset of the Ripple network.
Assembla is giving away 1000 free XRP (the Ripple native cyptocurrency) to any person with software development skills who is interested in learning about Ripple development. Get it here: https://www.assembla.com/ripple
I called Ripple Labs a few months ago to find out more about ways that their "gateway" can help us pay developers in many different countries. Essentially, we do banking for the developers on our global team. We pay internal accounts, hold the money until they ask for it, and then transfer money to them by bank wire, ATM/Payoneer, or other mechanisms. We have found that the bank wire system is embarrassingly slow and unreliable. This is the problem that Ripple is trying to fix. Their gateway is like a bank in an open-source box. It keeps accounts in any currency, including USD, other currencies, XRP, and Bitcoin. It can transfer those accounts instantly and reliably on the shared "ledger." It is also gaining exciting new features such as "multi-signature" which enables outsourcing and crowdsourcing customers to post a budget amount, and then transfer it to their hard-working suppliers through an arbitrator.
Now I am working more closely with Ripple to help them scale up their development process. I decided to make this free XRP offer for two reasons:
- Users need 20 XRP to activate a Ripple wallet. We want to remove the hassle from acquiring the XRP so new developers can get started.
- We want to build an email list of developers that might be interested in working on internal development, bounties, or bank integration projects.
If you use Assembla and Bigplans, we have added a pre-configured webhook making it easy to post Assembla events out to your Bigplans chat room. Check out below for configuration instructions.
Bigplans is a simple, integrated way to manage a distributed team. It includes a "lean" task board, real-time chat, and a unique "advisor" (a real person) that helps you get on-demand resources if you need them. For programming teams, it includes a tight integration with Assembla login and Assembla tickets.
You can use the Webhooks tool to feed Assembla events into any of your team chats. To get started, you will need the Webhook tool installed in the Assembla project you want to configure. If you do not have the Webhook tool installed, visit the Admin tab > Tools section > and click ‘Add’ next to the Webhook tool.
Once installed, click on the Webhook tool in your main navigation and select Bigplans from the list of pre-configured post options:
You will need to obtain and update the auth token in the “Content” section.
To obtain your Bigplans auth token:
Visit Bigplans and navigate to the plan you want to post Assembla events to. Click on the ‘Connect’ option in the top bar. Under the “Message API” section, there is a section called “API Token” that will display your token. If no token is set, click on the ‘Reset’ button. Copy the token ID and replace the “BIGPLANS_AUTH_TOKEN” in the Webhook tool.
Now configure what Assembla events you would like to post to your Bigplans chat room and click ‘Add and Authenticate.” Don’t forget to enable the configuration under the “Title” field.
Your Assembla events will now be posted to the configured Bigplans chat room:
If you use Assembla and Slack, we have added a pre-configured webhook making it easy to post Assembla events out to your Slack chat room/channel. Check out below for configuration instructions.
To get started, you will need the Webhook tool installed in the Assembla project you want to configure. If you do not have the Webhook tool installed, visit the Admin tab > Tools section > and click ‘Add’ next to the Webhook tool.
Once installed, click on the Webhook tool in your main navigation and select Slack from the list of pre-configured post options:
You will need to setup an incoming webhook service integration within Slack to obtain your token. To do this, visit https://YourSubdomain.slack.com/services/new/incoming-webhook, select the desired channel to post to, and click ‘Add Incoming Webhook.’
Once created, copy the provided Webhook URL and update the External URL in Assembla’s Webhook tool.
Now configure what Assembla events you would like to post to your Slack room/channel and click ‘Add and Authenticate.' Don’t forget to enable the configuration under the “Title” field.
Tip: Within the Slack “Incoming Webhook” page that you set up for this integration, you can scroll to the bottom of the page and expand the “Integration Settings” where you can add a label, change the post-to channel, and change the icon and name for your webhook bot.
Your Assembla events will now be posted to the configured Slack room/channel:
If you use Assembla and HipChat, we have added a pre-configured webhook making it easy to post Assembla events out to your HipChat chat room. Check out below for configuration instructions.
To get started, you will need the Webhook tool installed in the Assembla project you want to configure. If you do not have the Webhook tool installed, visit the Admin tab > Tools section > and click ‘Add’ next to the Webhook tool.
Once installed, click on the Webhook tool in your main navigation and select HipChat from the list of pre-configured post options:
You will need to obtain and update the auth token and room ID in the “Content” section.
To obtain your HipChat auth token:
You will need to visit https://YourSubdomain.hipchat.com/admin/api and enter your password to access the “API Auth Tokens” page. Under “Create new token” select ‘Notification’ type, provide a label, and click ‘Create.’ Copy the token ID and replace the “HIPCHAT_AUTH_TOKEN” in the Webhook tool.
To obtain your HipChat room ID:
Visit https://YourSubdomain.hipchat.com/admin/rooms and click on the desired room you would like to post Assembla events to. Copy the App ID and replace the “HIPCHAT_ROOM_ID” in the Webhook tool.
Now configure what Assembla events you would like to post to your HipChat room and click ‘Add and Authenticate.” Don’t forget to enable the configuration under the “Title” field.
Your Assembla events will now be posted to the configured HipChat room: