Vor ein paar Tagen erlebte ich (endlich) einmal wieder so einen Moment … einen Moment, der mich wissen lässt, dass es nicht reiner Idealismus ist zu glauben, dass Menschen Spaß an ihrer Arbeit haben und aus ihr Energie ziehen können.
Einen Moment des Leuchtens in den Augen, der Begeisterung, des Mutes, des Gestaltungswillens! Der PO – der mit dem Leuchten in den Augen – war in ein Projekt reingeraten, bei dem politische Zwänge, künstliche System- und Entwicklungstrennungen und vermehrte Absicherungsaktivitäten das Arbeiten alles andere als agil machten. Vorherige Anläufe waren bereits gescheitert bzw. die Live-Stellung war schon einige Male verschoben worden. Zur Absicherung der eigenen Abteilung ließ man höchste Vorsicht walten in der Zusammenarbeit. Man bestand auf lupenreine Schnittstellendefinitionen im Vorfeld, Abnahmen ohne Anbindung des Systems an die Schnittstelle bzw. das Frontend, parallele Abarbeitung unterschiedlicher Anforderungen und und und … Zwar wurde in 2-Wochen-Sprints gearbeitet, doch die Resultate waren für niemanden wirklich zufriedenstellend. Man hatte sich allerdings irgendwie damit abgefunden, vielleicht gerade aufgrund der Projekthistorie.
Aufgrund einer unabhängigen Anfrage des Fachbereichs/Kunden zur Umsetzbarkeit einer Funktionalität im System wurde sich der PO aber wieder darüber bewusst, was sein System eigentlich drauf hatte. Aufgrund dieses Impulses traute man sich plötzlich, das vermeintlich Offensichtliche zu denken: “Können wir nicht die Funktionalitäten, die der Kunde sich seit Jahren durch die Einführung eines neuen Systems erhofft hat, nicht auch viel einfacher im eigenen System abbilden?”
Als der PO diesen Gedanken aussprach, erinnerte er sich daran, dass er genau dies als Vision für sein neugegründetes Team vor einem Jahr formuliert hatte. Und auch damals schon war plötzlich eine Energie und Klarheit im Raum, wie sie keine schriftliche Dokumentation und Absicherung jemals erzeugen kann. Sie war positiv! Damals wie heute bei der gleichen Sache.
Diese positive Energie zeigte mir als ScrumMaster, in welche Richtung ich weiterarbeiten musste.
- Design of a complex system – Tom DeMarco
- Is educaton killing creativity?
- Design eines großen Systems – Tom DeMarco
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
What do you do for geographically distributed teams, if you want to move to agile?
First question: does the team want to move to agile? Or, does the management want to move to agile? I am serious.
I might take the same actions, but for different different reasons. In either case, the team needs to learn about what agile and lean means, and how to do agile. In both cases, the team needs help and protection from management.Why Does a Geographically Distributed Team Need Help and Protection from Management?
Managers create geographically distributed teams for many reasons. Some reasons are that there are smart people all over the world. In that case, managers create feature teams.
When managers create dispersed teams, teams with one and two people in disparate locations in far-flung locations (more than 60 meters away), managers are under the impression that “experts” can perform jobs better than teams can.
When managers think that “experts” can perform jobs better, they create bottlenecks in the work. Bottlenecks prevent flow. Bottlenecks prevent agile or lean from working. It does not matter if you want agile or lean. You won’t get either with a bottleneck. You have to overcome the bottleneck.
Can you make a geographically distributed team work in an agile way? Yes. Let’s go back to the principles.Our principles of agile or lean:
- You need to see all the work in progress.
- You want to flow work through the entire team.
- You want to see working software, sooner, rather than later.
If you, like me, don’t care how we get there, we have options.How Could a Team Take These Principles and Create Their Own Agile Approach?
Let’s take one thing at a time.
Let’s assume the team is not accustomed to working on small items of value. If you are like many of my clients, this is the case. What would it take for the team to start working on small features that deliver value?
Let’s think about the product again:
What kind of potential for release frequency does the team have? That colors the team’s thinking. The more potential for continuous deployment, the easier it is to work on small items of value.
This is where I like to introduce the notion of spikes and timeboxes. I ask the team to take their smallest feature, and work together on it. They don’t always have any notion of “together,” either. They say things such as, “We need …” and list the impediments to their ability to work together.
Now we see the need for management support.Project Management is Not a Dirty Word; Neither is Management
I know that some of you dislike the idea of agile project managers. I know some of you positively hate the idea of management in agile organizations. Let me suggest that for teams transitioning to agile, there is a place for management. That place is creating an environment in which the team learns how to self-manage.
There is no place for command-and-control project managers—never has been, never will be. Unless it’s time for lunch. Sometimes, teams need people to say, “Lunch-time!” But even that isn’t command-and-control. That’s someone saying, “I’m taking care of my need to eat. Want to come along?”
It’s the same thing for a team with a lot of risk and a lot of unknowns. A team where the normal, out-of-the-box agile solutions don’t work. Why would you let a team like that flounder?
That team needs everyone to lead. And, it often, but not always, needs someone to represent that team to management. Why? Because management doesn’t understand agile yet. That part might come now, and it might come later. But in an agile transition with many unknowns, it almost never happens at the beginning, even if management is saying, “Please go agile.”
A geographically distributed team needs management support. It does not need command-and-control. That team does need support.
That’s when I ask the person working as the project manager to start removing impediments. The team creates their own visual board. (Yes, a distributed team almost always needs a tool. I like to start with cards on a wall first, take pictures of it. Once a team knows how they like to work, then they choose a tool.) The team decides what the length of their timebox is for this feature, if they want to use iterations. They decide how to spike it. They start making decisions.
That team especially needs to understand the problem of bottlenecks, experts, and how to stop needing experts.
After they practice this a couple of times, they have the confidence they need to do this more times on their project. They can call this agile, but it might not have a real name. It’s a mishmash of timeboxes and kanban, but it works for them. Does it matter what it’s called?The Team Needs Management to Remove Obstacles
Teams might need management support. For example, I often discover geographically distributed teams don’t have enough testers. Well, you say, that team flunks the “we have all the cross-functional roles to do the work” part of agile. Yes, and what if they don’t know that? What if they want to try agile? What if they want to work through their obstacles and impediments? They need someone to represent them to their management, while they try to test as they proceed, right?
You could substitute “database admin” or “GUI designer” or whatever it is you need for tester in the above paragraph. Whenever you need someone to advocate on behalf of the team to management, you might want an agile project manager. Not someone to say, “When is the project going to be done?” Nope, not that kind of a PM. Someone to say, “What does the team need? I can help acquire that.”
PMs who provide servant leadership to the team, and represent what the team has accomplished to the rest of management can be invaluable. They can help the team understand its process and facilitate what the team can do if the team gets stuck. These are agile project management skills.
At this point, the team can try several approaches I suggested in these posts:
- Agile Lifecycles for Geographically Distributed Teams, Part 1 is for iterations and silo’d teams and a project manager.
- Agile Lifecycles for Geographically Distributed Teams, Part 2 is for kanban and silo’d teams and a project manager.
- Agile Lifecycles for Geographically Distributed Teams, Part 3 is for iterations and kanban and silo’d teams and a project manager.
You might have an even better alternative than the ones I suggested.
Do you need a project manager? No. Do you need a servant leader? In my experience, yes. Maybe in your experience, no. I would love to hear from you, if you have a geographically distributed team that does not have a servant leader.How Does This Team Evolve?
That has allowed each team to transition from the Complex to the Complicated. They now have collocated agile or lean teams. They can design their agile projects, as in Part 1. They retain the value of smart people all over the world. They don’t have the aggravation of trying to meet in different time zones for a project. They still have it for the program.
Some of my clients are still trying to make the dispersed teams work. It’s really hard. You might want to read my paper about the common problems on these teams.
Where are we now?
In Design Your Agile Project, Part 1, we discussed a straight-on approach to using whatever approach to agile, because it was obvious where you were.
In Design Your Agile Project, Part 2, we discussed looking at your system of work, and thinking about your unknowns. You need to think about your risks, and consider what you need to experiment with, to design your own agile project.
This part, part 3, is a continuation of part 2. It matters because you might need a servant leader who might be called a project manager. The title matters, because especially on a geographically distributed team, you are bridging the gap and the culture between the old way of working and the new way of working. I still think it’s Complex. Some of my clients think it’s Chaotic because they have so many impediments.
Whatever it is, you need data to take your next step.
My article, Taking the Long View in Software Development, has been published on ProjectManagement.com. Free registration is required on that site.
The point of using agile is to get finish something valuable-to-the-business quickly, to get feedback. Why? For several reasons, but the first one is so you can change the project’s priorities. The second is so you can change the project portfolio. The third is to get feedback on what you’ve done. Okay, you can exchange one, two, and three if you like. For me, those are the top three reasons to get to done every few days to two weeks. They are right behind each other in priority. Agile is all about change.
This is why every project needs to design its own way to get to done.
If you have a single collocated team, who understands how to deliver value quickly you might be in the situation described in Design Your Agile Project, Part 1.
What happens when you have more unknowns? What if your organization is “addicted” to waterfall and long projects? When you can’t see the people on your project, because everyone isn’t in the same place? When you have a lot of technical risk, such as technical debt? How about when you’re starting a program and everyone is transitioning to agile (oh please, don’t do this). Or, you’re new to agile, and you don’t have training. I have a question: would you drive a car on the road with no training, either?Rethinking What to do When Your Project or Organization is Full of Unknowns
Let’s discuss the principles of designing your agile project when you have more unknowns. Let’s start with a common problem: an organization “addicted” to waterfall and long projects. And, they’ve heard about this “agile” stuff, and they want to try it.
If you have heard about the many places Scrum has failed, this is classic. Scrum says, “replace your old culture with this new culture.” Wow, that’s a big shift. If you look at the Cynefin framework, you can see that for an organization addicted to waterfall, long projects and big requirements, they are not in Complicated. They are in Complex. Why? Because they have too many unknowns.
Here’s what I see when I do assessments in these organizations:
- Much multitasking to address emergencies.
- No project portfolio management
- Their requirements are so large, it takes them forevvveerrr to release anything
- Because their requirements are so large, and because their releases are so long, that increases the demand for emergencies: patches, interim releases, firefighting.
There could be more. This is enough.
In that case, you want to look at the Cynefin framework, and say, “What does the Complex side of the framework say?” It says we should consider emergent practice. We should not only consider out-of-the-box solutions. We have to probe-sense-respond.
What do we need to accomplish? Getting to working software, at the end of an iteration. Or, in flow. We want a feature, in flow, in a day or two, maybe three. We want completed features, with no leftover wasted work (unfinished features) at the end of an iteration. We want to be able to change what we do after the iteration, or after the feature. How do we accomplish that, from the team’s perspective? Let’s forget labels, and focus on the team.What’s the First Thing the Team Could Do?
I like to ask, “How little can we do?” Too often, the team has been asking “How much can we do?” Starting with that question helps.
Thinking in inch-pebbles, timeb0xing work, spiking work, all of that helps to learn how to work small.
Sometimes, when we have stories, and we don’t know how to break them apart, we ask, “What’s the first thing that could add value?” Maybe that’s a good question here. You could ask, “What’s the first thing the team can do?” Or, “What’s the first thing we can do that would help us get to done in a one- or two-week iteration?” Or, “How do we finish a feature in flow (kanban)?”
Often, for teams who are in the Complex side of the framework, I suggest these things:
- Start a kanban board. You need to see what your actual process is. You need the visuals.
- Decide on your work in progress limits, and stick to them, at least for a week.
- Retrospect and reflect on those limits, the progress you’ve made and anything else that arose. Where are you, as a team? What progress did you make? What do you want to keep, add, change?
Notice how this is not out-of-the-box agile or lean. It’s a way to start a team moving from the Complex to the Complicated. Once a team has been through the first week, they iterate, keeping in mind these principles:Let’s Review the Principles:
- Get to done, either in flow or iterations. Why? Because we want to develop working software.
- Keep the iterations short, either one or two weeks. Longer is not better. Why? It’s too long to allow for frequent change. Why? Because we need to allow for change in the project. That way, we can get feedback on the features, change the project’s priorities, and manage the project portfolio.
- Find a way to connect as a team, regardless of how you do so. Real-time rituals are not good if they make everybody crazy from lack of sleep. Why? We need sustainable development, even if real-time rituals are the best.
- Find a way to reflect as a team. Surrogate reflection is not good. Why? How can someone else substitute for what’s really going on in a team?
Where are we now?
Nobody has changed roles. Nobody has changed culture. We are looking at our process, and making things smaller for a while. We are reflecting. All of this in order to simplify, to move from the Complex to the Complicated.
Remember, I have only discussed what I have done with teams who are collocated, who have had problems with too-large features, long waterfall projects, and many emergencies. I haven’t addressed the issues of distributed teams yet. They are next.
I hope you stay with me as we move to part 3.
“Resource planning” or “Resource Management” or “Resource blockers” I hear these in stand-ups, or project meetings and even on CSM (Certified Scrum Master) training. People who know me watch me cringe a little each time. I have this visceral reaction that I can’t explain, my whole body cringes. Why does it matter? Some people would […]
Would you like to become a Certified Scrum Master (CSM) or Certified Scrum Product Owner (CSPO)? These classes are taught by Certified Scrum Trainer Peter Hundermark. Perhaps you are a practising Scrum professional looking to grow your skills and learning? Or a line manager grappling with the challenges that an Agile transformation presents? Scrum Sense […]
Für ein Konzert von Bodo Wartke hatte ich Karten geschenkt bekommen. Da er leider am Wochenende nicht in Berlin auftritt, fuhren wir nach Luckenwalde, um ihn zu sehen. Zu unserer Verwunderung war der Saal, der rund 700 Plätze hatte und beim Reingehen den Charme einer Turnhalle verströmte, ausverkauft. Zwar waren wir nicht die einzigen Berliner, die die einstündige Fahrt auf sich genommen hatten, es waren aber auch viele im Publikum, die man nicht unbedingt dort vermutet hätte. Eine ältere Dame vor mir genoss sogar während der Vorstellung ihren „Kurzen“, den sie wohl noch von der organisierten Busfahrt zum Konzert übrig behalten hatte.
Nichtsdestotrotz war die Stimmung toll. Das Publikum spiegelte zu jedem Moment die vom Künstler erzeugte Stimmung wider und ließ sich auf jede Frage, Mitmachaufforderung bzw. Interaktion mit Bodo Wartke ein. Nach seiner – ich glaube – dritten Zugabe, bei der er sich bei seiner Crew und beim Publikum bedankte, weil er auch diese noch spiele durfte, fasste ich kurzerhand einen Entschluss.
Ich war mir ziemlich sicher, dass es die letzte Zugabe sein würde und mir hatte der Abend sehr gut gefallen. Warum also nicht aufstehen und dem Künstler die Freude einer Standing Ovation bereiten? Klar, die Gefahr, dass ich alleine stehen würde, war natürlich vorhanden. Aber das war mir egal. Schließlich „stand“ ich ja zu meinem Aufstehen. Ich fand es klasse, was er gemacht hatte und wollte es ihm zeigen. Als er sich zum letzten Mal verbeugte, stand ich also schwungvoll und klatschend auf!
Es dauerte eine laaaaaange Sekunde bis mir jemand folgte. Ich konnte es sehen, weil es eine Person schräg hinter mir war. Und dann noch jemand, direkt neben mir. Und dann spürte ich, wie ein Movement durch den Raum ging. Hunderte von Personen standen gleichzeitig auf. Eine Wahnsinnsenergie und Dynamik. Ein tolles Gefühl irgendwie und auch ein bisschen unbeschreiblich.
Während er sich tief und lange verbeugte, machte seine Crew das Licht im Saal an. Als er wieder hochblickte, sah er den kompletten Saal stehen. Und man sah in seinen Augen die Freude, aber auch die Verwunderung! Unter Standing Ovations und von einem Ohr zum anderen grinsend verließ er, selber klatschend, rückwärts den Saal.
Mein Freund drehte sich zu mir und sagte: “Wow, you created a Movement! Und außerdem sind jetzt alle viel schneller draußen, weil sie ja schon stehen!”
Wie gesagt, natürlich wusste ich nicht, ob es funktionieren und somit den gewünschten Effekt haben würde. Aber ich bin aufgestanden, weil ich überzeugt war, dass es einen Unterschied macht. Egal, ob mir jemand folgt oder nicht.
Steht auf! Macht einen Unterschied – wenn auch nur für euch. Most likely wird jemand folgen!
After shipping out new features and changes to our product, we often get to hear how our customers feel about the changes. There are times where our customers love the changes and then there are times where the changes are just plain disliked.
This was the situation we found ourselves in after we rolled out an update to our Item detail page. We moved the comment & attachment upload box up the page and changed the item’s activity stream into a reverse-chronological order. We had actually made the changes to address customer comments that there was too much scrolling needed on that page.
It turned out that the changes, although well-intentioned for one group of customers, really disrupted another group of customers and their own Sprintly work habits. The number of complaints that came through support, Twitter and our Sprintly Customer Community had the highest velocity we had received to date. So we got together, spec’d out a solution and moved the work up our backlog.
Today we deployed a new option on the Item detail page that allows you to sort the activity stream in chronological or reverse-chronological order:
This new option will help our customers use our system more effectively. Thanks for your feedback and persistence because it has helped us get it right! Now we’re back to work on more improvements, bug fixes and new features.
By the way, we’re hiring designers and full-stack developers in Portland, San Francisco and Boulder. If you’re interested in joining the Sprint.ly and Quick Left super awesome teams, Joe and I would love to hear from you!
The more I see teams transition to agile, the more I am convinced that each team is unique. Each project is unique. Each organizational context is unique. Why would you take an off-the-shelf solution that does not fit your context? (I wrote Manage It! because I believe in a context-driven approach to project management in general.)
One of the nice things about Scrum is the inspect-and-adapt approach to it. Unfortunately, most people do not marry the XP engineering practices with Scrum, which means they don’t understand why their transition to agile fails. In fact, they think that Scrum alone, without the engineering practices, is agile. How many times do you hear “Scrum/Agile”? (I hear it too many times. Way too many.)
I like kanban, because you can see where the work is. “We have a lot of features in process.” Or, “Our testers never get to done.” (I hate when I hear that. Hate it! That’s an example of people not working as a cross-functional team to get to done. Makes me nuts. But that’s a symptom, not a cause.) A kanban board often provides more data than a Scrum board does.
Can there be guidelines for people transitioning to agile? Or guidelines for projects in a program? There can be principles. Let’s explore them.
The first one is to start by knowing how your product releases, starting with the end in mind. I’m a fan of continuous delivery of code into the code base. Can you deliver your product that way? Maybe.How Does Your Product Release?
I wish there were just two kinds of products: those that released continuously, as in Software as a Service, and those with hardware, that released infrequently. The infrequent releases release that way because of the cost to release. But, there’s a continuum of release frequency:
How expensive is it to release your product? The expense of release will change your business decision about when to release your product.
You want to separate the business decision of releasing your product from making your software releaseable.
That is, the more to the left of the continuum you are, the more you can marry your releases to your iterations or your features, if you want. Your project portfolio decisions are easier to make, and they can occur as often as you want, as long as you get to done, every feature or iteration.
The more to the right of the continuum you are, the more you need to separate the business decision of releasing from finishing features or iterations. The more to the right of the continuum, the more important it is to be able to get to done on a regular basis, so you can make good project portfolio decisions. Why? Because you often have money tied up in long-lead item expenses. You have to make decisions early for committing to hardware or Non Recurring Engineering expenses.How Complex is Your Product?
Let’s look at the Cynefin model to see if it has suggestions for how we should think about our projects:
In the meantime, take a look at the Cynefin model, and see where you think you might fall in the model.
Do you have one collocated cross-functional team who wants to transition to agile? You are in the “known knowns” situation for agile. As for your product, you are likely in the “known unknowns” situation. Are you willing to use the engineering practices and work in one- or two-week iterations? Almost anything in the agile or lean community will work for you.
As soon as you have more than one or two teams, or you have geographically distributed teams, or you are on the right hand side of the “Potential for Release Frequency” chart above, do you see how you are no longer in the “Complicated” or “Obvious” side of the Cynefin model? You have too many unknowns.Where Are We Now?
Here are my principles:
- Separate the business decision for product release from the software being releaseable all the time. Whatever you have for a product, you want the software to be releaseable.
- Understand what kind of a product you have. The closer you are to the right side of the product release frequency, the more you need a program, and the more you need a kanban to see where everything is in your organization, so you can choose to do something about them.
- Make sure your batch size is as small as you can make it, program or project. The smaller your features, the more you will see your throughput. The shorter your iteration, the more feedback you will obtain from your product owner and “the business.” You want the feedback so you can learn, and so your management can manage the project portfolio.
- Use the engineering practices. I cannot emphasize this enough. If you do not keep your stories small so that you can develop automated unit tests, automated system tests, use continuous integration, swarm around stories or pair, and use the XP practices in general, you will not have the safety net that agile provides you to practice at a sustainable pace. You will start wondering why you are always breathless, putting in overtime, never able to do what you want to do.
If you have technical debt, start to pay it down a little at a time, as you implement features. You didn’t accumulate it all at once. Pay it off a little at a time. Or, decide that you need a project to prevent the cost of delay for release. If you are a technical team, you have a choice to be professional. No one is asking you to estimate without providing your own safety net. Do not do so.
This post is for the easier transitions, the people who want to transition, the people who are collocated, the people who have more knowns than unknowns. The next post is for the people who have fewer knowns. Stay tuned.
Retrospectives are near and dear to my heart. I love facilitating them to this day and tend to try something new quite often. I have found it to be a fertile ground for learning facilitation techniques. Today I will discuss scaling retrospectives. While the scaling discussion is receiving a great deal of press in the agile world these days, we have overlooked the retrospective area in my opinion. Time for a change:
Consider the following two intents:
The intent of a team retrospective is to seize the opportunity to inspect itself and to plan for improvements the following iteration.
The intent of a program team and a portfolio team is to serve one tier below and maximize the value creation from those tiers. While I may dive into alternative approaches for the portfolio level teams in the future, for now I will focus in on the program team.
Given the two aforementioned intents, let’s take a look at the agile manifesto by grabbing just a few of the guiding principles. As we go through, think about the scaled agile team at the program team level. How could they as a team make each of these better?
Simplicity–the art of maximizing the amount of work not done–is essential.
The art of evolving a plan. Planning is an essential part of flowing work through a scaled agile system. Not having an effective planning cadence from the strategy of the organization down to the delivery teams’ user stories can kill organizations. Moreover, the way you plan may not even fit your business model. Everyone, especially the program team, is responsible for maximizing the amount of work not done to get value out of the system. So what improvements can be achieved through progressive elaboration, story mapping, etc. for your program team? What practices do they need to keep or stop doing?
Working software is the primary measure of progress.
Pop quiz hot shot. Who’s responsible for working software? Many agilists focus on the scrum delivery teams and hold their feet to the flames. While my development brethren (shout out .Net devs) should not shirk their responsibility, I’ll tell you that it’s the program team that takes on a larger portion of the responsibility because they can make a gigantic difference in how organizations deliver a solution. The program team is responsible for making strategic decisions as to when and when to not take on less than desirable software. This forces the quality decision to the correct spot. The program team should be focused on maximizing the value the delivery teams provide and any good product owner knows that a short term win by reducing quality is just that, short term and very costly in the end.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
This one is all about the organization enabling the delivery teams to do well. I would ask all program teams to pay attention to the last sentence. How can you best enable your delivery teams to get the job done? Working with them to give them a clear understanding of the vision. Slicing stories better. Helping to protect the team’s capacity. Identify what it is and go make it better.
It would be easy to look at all of the principles and discuss for the program team. While that’s too big an undertaking for this blog entry, I’ll leave you with the last manifesto principle:
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
If we have defined above, albeit a small part, what it means to be a successful program team, then we can and should easily retrospect on what it would take to make the team even better. This means that we should establish a cadence or rule as to when we will either retrospect or “stop the line” to reflect on the desired outcome for scaled teams.
Here’s what I want from you. Not many people I know are testing this stuff out. So test it with me. Give me feedback as to what you have tried. What success have you found if you tried a retrospective at the program team level? What failed? What do you need to start and stop doing? Sound familiar?
My twitter stream delivered an interesting quotation about quotations yesterday. This one, and the tweet came from Bob Marshall:A quotation is a handy thing to have about, saving one the trouble of thinking for oneself, always a laborious business.
Quotations indeed take a fairly large part among tweets and other social web shares. When something troubles us at work, whether we are looking for a solution to a technical or to an organizational problem, and if talking it out with friends and colleagues is not enough, or we are shy and/or unwilling to speak, we find outlet in sharing quotes by reputable gurus, and those quotes reflect how and what we think about this problem.
I only in part agree with the quote by A. Milne above. The habit of using quotations can be perceived as lazy thinking, sometimes. However, I don’t think that people who share quotes or links online are the lazy ones. On the contrary, they are the ones who do think. It’s just that for the time being they are shy to step forward with their opinion, expressed in their own words. It might be even scary for some, to stand out and say: yes, these are my thoughts, and my words and I’m ready to be accountable for them. We are all human, and we all have things that we are not yet ready to let out to the outer world. This might be out of fear, or out of passive-aggressive reactions, or … <insert your reason here>. We might be too lazy to care about building formal logical discourses so as to pass on the message to those who do not share our thinking right away. Some people seem to resonate naturally with each other, and with some people a heavily geared-up persuasive rhetoric has to be used. Take a moment and think: which people in your social circles throw links or tweet quotes instead of writing or speaking up? They are just not yet ready to make this leap, the shift from the safe protection of quotes and references to the scary uncertainty of how the world and others would react to what would then officially be treated as their own opinion. Absolutely, they need to be encouraged to speak out and to write up.
The scary uncertainty got hold of me and of my article on self-organization earlier this week. I expressed my own opinion, backed up by intuition and personal experience, and didn’t pay much attention to references, details and credibility proofs. If I did, it would take a book, not just one article. Anyway.
There’s another controversial subject that probably has many heads in software development thinking about it. I want to bring it forth, but this time I will take a safe protection of George Lois, an advertising guru, who wrote the book called “Damn Good Advice (For People with Talent!). Software development is a creative pursuit, at least, when it comes to the ideas part, so I was delighted to see that a recognized creativity guru thinks about teamwork along the same lines that I do. The subject of groupthink, and the dynamics of software development teams working efficiently together has preoccupied me for quite some time, but I will hold back my thoughts for now, letting George Lois speak instead:Team work might work in building an Amish barn, but it can’t create a Big Idea.
The accepted system for the creation of innovative thinking in a democratic environment is to work cooperatively in a teamlike ambience. Don’t believe it. Whatever the creative industry, when you’re confronted with the challenge of coming up with a Big Idea, always work with the most talented innovative mind available. Hopefully.. that’s you.
Avoid group grope and analysis paralysis. The greatest innovative thinker of our age remains Apple cofounder Steve Jobs, a modern-day Henry Ford. Jobs was not a consensus builder but a dictator who listened to his own intuitions, blessed with an astonishing aesthetic sense.
Everybody believes in co-creativity — not me.
Be confident of your own, edgy, solo talent.
Wait, wait. Before you throw rotten tomatoes, George Louis does give credit to teamwork, and I do, too. Here’s what goes next in the book:
Once you’ve got the Big Idea, that’s where teamwork comes in – selling the Big Idea, producing the Big Idea and bringing the Big Idea into fruition.
Ideas are cheap. As Thomas Edison is famously supposed to have said,
“Genius is one percent inspiration, ninety-nine percent perspiration.”
This weekend, March 14-16, Rally Software will be cheering on dozens of passionate entrepreneurs as they race the clock to take an idea from conception to startup. During this 54-hour Startup Weekend, entrepreneurs will pour inspiration and perspiration into their ideas to validate them and launch startups.
At Rally, we’re passionate about encouraging innovation internally and within our community. We follow Lean Startup principles in the enterprise context, and Zach Nies, Rally’s Chief Technologist, will be guiding the Startup Weekend teams on adopting these principles. It’s a process that encourages focus on “getting out of the building” to validate ideas with potential customers, and rapid cycles of “frame, build, measure, learn” to discover what customers need.
Waffle.io, a product initially created by a team of interns at Rally last summer, is an example of how Rally runs experiments to understand the needs of developers. Engaging with Startup Weekend is one way for Rally to see how small teams are formed, how they work together, and how they adopt tools to help them solve problems.
Counter to common thinking, entrepreneurs are ideal candidates for Rally. As the company grows, we need innovators who can push Rally to discover and meet our customers’ needs: not just today, but in years to come. Investing in Boulder’s startup community helps us build relationships with the next generation of entrepreneurs and leaders.
Are you an entrepreneur? Are you passionate about taking an idea to market? Join us at Startup Weekend, March 14-16, in Boulder, CO. Use coupon code RALLY to get $20 off.
If I were to single out one personal skill that matters most in work and in life in general, that would be the ability to focus. It’s ever so hard to keep focus in the digital age, with all those many distractions that lure us; and it might be especially hard for IT-specialists, people who spend most of their time cuddling with computer screens.
Digital creatives are more inclined to having their focus loosened. Their work allegedly requires a good deal of looking at how others do things. One can easily get lost in graphics, designs, promotional concepts, and have all their buckets so filled up with what someone else has created, that they would have difficulty detaching and focusing on their own thing. I’m mostly talking about UX designers, graphic designers, marketing specialists, and other roles that involve the mixture of creative and strategic thinking. It’s both a very fine line and an insidious trap: whether we absorb all the treasures of the world, re-mix them inside of us, and produce another facet of digital reality available for all people through their screens; OR we strangle our creativity by blocking its flow with passive perceptions, disrespecting our innate abilities to bring something authentic to the table. Ultimately, that would be one and the most important thing that we need, if we ever want to be fulfilled professionally and to have people enjoy software products that we create: focus on this well of creative thinking inside of us, nurture it and let it find an outlet.
How about other IT specialists? Software developers and quality assurance who, on the contrary to the creatives, seem to be too focused on their work? It’s hard to believe, but in some companies they still block access to social sites, or even to the Internet, not to let even a single second of work time sneak anywhere outside. The employers who allow such things to happen obviously mix people with machines. There’s no way a human being will work more productively if treated as an inanimate object. On the contrary, developers and QA need to be encouraged to distract from their work time after time, to be able to keep their focus on it.
These are 2 basic approaches to keeping focus in knowledge work, and any work in IT is knowledge work, as we know (tautology intended). Creatives need to be encouraged to tap inside themselves, to learn when and how to block distractions and outside influences. Technical specialists, on the contrary, experience emotional drain if they don’t have some relaxing outlets and distractions at work. It takes some high-profile personal skills to balance the focus-loosening phases, and it seems there’s no ready-made universal recipe for that. What works for someone, might not be working for someone else. My personal indicator is this: if I feel that my time is wasted — something wrong’s with the focus; if I feel that my time is spent productively — this shows that I’m well-focused. I hope we all will have this focused feel all the more often, as our work helps us learn how to do things in a productive and personally fulfilling way.
So, now I’ve spent 2 days with 600 projects managers at a PMI conference. Totally different from the usual crowds I hang out with. Fascinating to hear stories about project management successes and failures in all kinds of industries – from warzone reconstruction projects to eurovision song contest.
I was a bit nervous (OK more than a bit) getting up at the biggest-ever scandinavian gathering of project managers – and illustrating to them how the standard project model really doesn’t fit well for IT product development, and how companies like Spotify actually don’t have PMs and don’t do projects (at least not the type defined by PMI)
I was happily surprised though. Instead of getting attacked for it, scores of PMs came up to me, agreeing with me, sharing similar experiences, and inspired to try agile principles in their own projects and industries.
And biggest positive surprise of all – the final keynote by Dr. Harold Kerzner, major thought leader in PM space who has written over 50 college textbooks on project management! He listed like 30 things that are wrong with traditional project management as tought in PMI textbooks, and where it all is heading in the future. He described it as a fundamental paradigm shift from PM 1.0 to PM 2.0.
According to Dr Kerzner, agile values and methods like Scrum are examples of the future of project management, and I was positively surprised at how well his description of PM 2.0 rhymed with agile values.
So what I saw was convergence – experts and practitioners arriving at the same conclusions, coming from lots of different directions. A magical feeling.
I’ve suspected it before, but talking to all these experts has made it clear to me – agile is a universal thing, way beyond just software.
I’m so glad I took the courage to get out of my comfort zone and meet these people. I wish more agile trainers and coaches would get out of the echo-chamber of agile conferences and see what’s going on in the wider world
(some sample slides from my talk below)
Here comes a new version of iceScrum and iceScrum Pro!
The R6#13 version brings some important bug fixes. We also developed a few improvements that should please you while waiting for the big changes that will come in iceScrum R7!
At first, we expected the previous version (R6#12) to be the last of the R6 series. However, we take all the time that is needed to experiment the ideas gathered last months and ensure that the new interface will make using iceScrum much more easier and pleasant. In the meantime, we don’t want to leave you with annoying bugs so we decided to release another R6 version.R6#13 Improvements
- ICESCRUM-594 – Bugzilla integration [many thanks to TECH'advantage, the iceScrum Pro customer that sponsored this story] (iceScrum Pro, Documentation)
- ICESCRUM-622 – Define custom tags on bug tracker import (iceScrum Pro)
- ICESCRUM-649 – Custom story estimates
- ICESCRUM-652 – Update availabilities for done sprints (iceScrum Pro)
We promised additional bug trackers, after Mantis BT here comes the Bugzilla integration! You can now import stories automatically from Bugzilla issues and define rules to update the issues according to the changes made on the corresponding stories.
Until now, story estimates had to be chosen from either the Fibonacci or the Integer suite, there is now a third option called « Custom values ». Will still strongly recommend the use of the « story points » empirical unit for story estimates. However, it is now entirely up to the teams to choose the values that are meaningful to them.
When custom values are enabled, you can estimate stories by typing any value between 0 and 999.99, with a precision of two decimal places.
- ICESCRUM-651 – Availability dates are shifted by one backwards in the table header (iceScrum Pro)
Warning: if you use the iceScrum Pro availabilities and if your projects has a negative offset from UTC, which is the case of most projects based in America, then you should read the following:
If your project satisfies these two criteria, then the dates displayed in the availabilities table header are likely to be shifted by one day backwards. Despite being only a display bug, it has annoying consequences.
Here is an example: given a sprint from 11th march to 17th march, the table has 7 columns. The first column corresponds to the 11th and the last column corresponds to the 17th. However, if you project had a negative offset timezone, then the first day is mistakenly labelled 10 and so on until the last column labelled 16.
If your team has entered the availabilities according to these labels (this is likely to be the case) then all the availabilities are also shifted by one. When upgrading to R6#13, the column formerly labelled 10 will be labelled 11, and so on for every day. Consequently, we strongly recommend that your teams check the availabilities entered for current and upcoming sprints and update them accordingly.
We considered an automatic way to fix the values, which would have required moving data around between sprints. However, such an automatic fix would have no way to figure out how your teams may have worked around the issue. Because of that, an automatic data fix may cause additional troubles on top of the identified bug, leading to an inextricable mess. Thus, we abandoned this solution.
We relaxed the permissions so the Scrum Master and the Product Owner can now update availabilities for done sprints and correct the availabilities wherever it is needed (see the improvements section above).
We are sorry for the inconvenience. If you have any question or if you want more information before upgrading, feel free to contact our support team, we will be pleased to help you.
- ICESCRUM-645 – Product Owners don’t follow automatically new stories despite the setting enabled
- ICESCRUM-642 – « Browse project » not displayed for admin if no project is public
- ICESCRUM-646 – An estimated story returned to sandbox keeps its effort
- ICESCRUM-894 – Drop-downs to select view type for embedded views are too small
- ICESCRUM-643 – Product Owners aren’t available in task board user switch (iceScrum Pro)
- ICESCRUM-634 – User name with apostrophe breaks availability table (iceScrum Pro)
- ICESCRUM-644 – Availabilities aren’t created for POs when enabling availability for a project (iceScrum Pro)
- ICESCRUM-886 – Weekend availabilities generated when adding days to a sprint are not initialized to 0 (iceScrum Pro)
- ICESCRUM-648 – Changes in team composition are not reflected in availabilities (iceScrum Cloud)