TimeCamp provides fully automated time tracking and invoicing software as a service for individuals and companies. When they recently reached out to me about their new Assembla integration, I figured I would give it a whirl. Below shows how to setup and use this integration based on my experience.
It is important to note that this is a one-way integration meaning once you enable the Assembla integration, you can begin tracking time expenditures for Assembla tasks in TimeCamp, but these time expenditures do not post back to your tasks inside of Assembla.
To get started, you will need to create a TimeCamp account, login, and visit ‘Settings’ > ‘Add-ons & Integrations.’
Scroll down and click on the Assembla option. Select ‘Enable the Integration’ and you will be directed to Assembla to ‘Allow’ TimeCamp to access your projects and pull your tasks. You will then be redirected back to TimeCamp where you can select the projects you would like to import and optionally invite Assembla team members to your TimeCamp account.
Once the integration is setup, you can begin tracking time to Assembla tasks. From the main dashboard, you will select ‘Track time for [day]’ and be able to see and select tasks from your Assembla projects.
When you select a task, you can either manually enter time or click the play button to start the timer.
TimeCamp also has a desktop application that when installed, allows you track time to tasks from your desktop. By default, the desktop application is set with Tracking Mode on Auto which is supposed to automatically search for keywords in window titles, urls and application names and track time accordingly. For complete accuracy and control, I personally prefered switching the Tracking Mode to Manual so I could manually select the desired task.
After you start tracking time with TimpCamp, you can explore additional features such as computer activity tracking, reporting, and invoicing. To learn more about TimeCamp and sign up for a free trial, visit their website at www.TimeCamp.com.
There’s a great comment to my recent Management Myth: Performance Reviews Are Useful. The writer has these questions, which I have paraphrased:
1. How do bonuses work?
Here’s the problem with bonuses in a team-based organization (agile or not). How can you tell who has done which work? Who actually knows who has contributed what?
The team does. This is true whether the team is agile or not. The team always knows who has done great work, who has pulled done whatever, or if someone is hiding. It’s easier to know if someone is hiding in agile.
The team always knows who has done what. The manager can try to know, by asking for status. The manager can try to know by asking for accomplishments. But the team knows.
That’s the first problem.
The second problem is why is any knowledge worker’s pay based on a bonus? This smacks of management by objectives. You know the kind, “We’ll increase our sales by x% over this year.” All other objectives flow from that. By the time they get to you, your bonus is supposed to be based on you completing a specific project your managers were supposed to fund at the beginning of the year.
Did you read all of those “supposed to” in the previous paragraph? That’s what happens with traditional project portfolio management and big-bang funding. That’s part of the reason you end up with multitasking which makes everyone crazy. People are trying like crazy to fulfill their personal bonuses (optimizing at the lower levels) instead of doing what the organization needs. This is one of the reasons I wrote Manage Your Project Portfolio.
How many of you missed out on a bonus because some salesperson screwed up? (My hand is up.) We completed our technical projects. Sales sold stuff we didn’t have. Sales didn’t sell stuff we did have. Management didn’t decide on a reasonable strategy, even though we completed our projects. Somehow this was our fault as technical people? Come on. We did our parts. No bonus for us. This is fair? Nope.
When you provide individual bonuses, you do not guarantee better results. We have data that proves this. Read Dan Pink’s Drive: The Surprising Truth About What Motivates Us, Pfeffer & Sutton’s Hard Facts, Dangerous Half-Truths, and Total Nonsense: Profiting from Evidence-based Management, and Hope’s Beyond Budgeting: How Managers Can Break Free from the Annual Performance Trap.
If your company is basing your compensation partly on bonus, it’s because they are cheap. They are trying to tie part of your compensation to something you have no control over: revenue. Revenue sharing is fine for retirement funding. Not so fine for regular compensation.
2. How can a company know who is contributing and who isn’t?
Ask the team. They know. Who else needs to know and why?
This is why you want to push the responsibility for feedback and coaching into the team. This is why you want the manager to be a servant leader.
When the manager is a command-and-control leader, no one knows nothing.
Why would anyone step forward and take responsibility? It is no one’s interest to do so.
3. Without paperwork we introduce possibilities of lawsuits, particularly for big companies? If a man is paid less than a woman and it is found out, using your logic, discrimination lawsuits are reasonable since there is no ranking. HR likes this paperwork to try to protect the corp. Granted Netflix has a solution of 6 months severance, but do you have any other alternatives?
Let me separate this one. You don’t need paperwork to know if people are paid comparably.
You can have salary ranges for each level. You can group each level and see what you get. I did this at one of my jobs. I discovered that when I was the only female manager, I was the one paid $10k less than the men. I brought that to my manager’s attention. He hemmed and hawed. I persisted. I said the word “discrimination.” They gave me a raise to bring me parity.
I wasn’t ranked. I grouped people by salary range, that’s all. I didn’t need ranking to see this. I needed a spreadsheet.
I hadn’t done this to look at my salary by the way. I had done this to look at all of Engineering, at the request of my boss. The question is this: What problem are you trying to solve?
HR doesn’t need ranking. They need common sense, which I admit, isn’t all that common.
Paperwork doesn’t solve problems. Paperwork protects HR from lawsuits, maybe. My paperwork proved that the company was discriminating against me. I didn’t intend it that way. But that’s what it proved.
4. You are arguing that management doesn’t need to exist in the traditional sense (since paperwork has been a big part of the job). If agile has killed the ability of the manager to know what is going on and can’t review the employees, why have a manager at all? Why not replace people-oriented managers with project-oriented managers?
Managers exist to create an environment that helps people do their best job. Managers exist to create and refine the strategy and to organize with purpose. Managers provide coaching and meta feedback. Managers initiate communities of practice. Managers manage the project portfolio. Managers provide servant leadership.
Even if managers did performance reviews, they didn’t do reviews every day of the year. They didn’t rank every day of the year. They certainly didn’t keep their eyes on “their” employees every day of the year. (Okay, the micromanagers did. But most traditional managers were not micromanagers. They were poor lost souls who didn’t know what else they should be doing.)
Project managers help a project get to done. People managers should not interfere with that. In a matrix organization, that is precisely what happens. I’m not sure what happens where you are.
I have a coaching client where the people managers are the project managers. They are also doing a form of agile. It’s their form of agile. You wouldn’t recognize it as by-the-book anything. But, because the VP is in charge of all of Engineering, he can see when the system is working and when it isn’t.
We had a conversation last year, and I suggested their stories were too big. It was too difficult for the managers to make project portfolio decisions. It looked as if some people were slacking off and some were working very hard. I suggested my coachee might not have enough data.
“If you make the stories smaller and the work flows through all the teams more evenly, you won’t need as many experts. The teams will be able to complete their work, and be able to finish their work more reliably. You will have more data on the teams. They will have more data on each other. You won’t have to pluck people and move them from project to project, which makes things worse. Before you decide some people are better or worse, why not try improving the system, first?”
They decided to do that. It was quite difficult for them. It went against everything they knew how to do: architecture, estimation, planning, implementation, everything. But they decided to try. Their managers were also their project managers and guided the teams to success. My coachee, the VP, learned that the people he had thought were great were good, but there were some shining stars he had not known about. The shining stars kept their mouths shut and kept the company running. All invisible work to the VP. Not invisible to the project managers. Who happened to also be the people managers.
There is no Right Way to organize. There is no One Right Way to manage. I lean towards servant leadership, because I don’t see how to have an effective organization without it.
How can we expect people, who are responsible adults, who have mortgages, children, and enter into contracts every day of their adult lives to turn off their brains at work? Why would we want them to?
Managing knowledge workers is not trivial. You try something, you get some feedback.
But performance reviews and especially ranking? No. Give me feedback on my work on a regular basis. Not performance reviews. Not paperwork. Not ranking. Don’t compare to other people. Tell me when I’ve done something useful. Tell me when I’ve done something not as useful, and why.
What do you think about these four points, especially about the role of the manager?
Mal ehrlich: Habt ihr schon einmal einen Kollegen für eine tolle Idee, die sich am Ende nicht umsetzen ließ, vor dem ganzen Team hochleben lassen? Wann habt ihr das letzte Mal einen echten Misserfolg gefeiert? Wann habt ihr das letzte Mal einen gerissenen Sprint zum Anlass genommen, euch zu belohnen oder euch dafür zu applaudieren, dass die Wände wackeln? Ich nehme an, dass das eher selten vorkommt. Kein Grund zur Sorge. Ihr seid damit in guter Gesellschaft und gehört zu der überzeugten Mehrheit, dass man Misserfolge ebenso wenig feiert, wie man Fehler gutheißt. Fehler sind schlecht. Fehler macht man nicht und wenn, dann redet man sie klein oder schweigt sie tot. Wollt ihr wissen, was die kleine, aber bemerkenswerte Minderheit über Misserfolge und Fehler denkt?Todesmutig in die Fluten
Der „First Penguin-Award“ ist eine besondere Auszeichnung. Wer diesen Preis in seinen Händen hält, hat sich mutig und risikoreich einem noch unberührten Themenfeld gewidmet und wurde für die Neugierde, den Enthusiasmus und sein herausragendes Durchhaltevermögen belohnt, obwohl (oder in diesem Fall vielmehr weil) er bei all seinen Bemühungen gescheitert ist: „…to the one or team that took the biggest gamble while not meeting its goals“ (Pausch, 2008). Paradox. Und wirkungsvoll. Warum First Penguin? Weil hungrige Pinguine bei ihrer Beutejagd gemeinsam am Ufer eines freien Gewässers sicher auf festem Grund ausharren, statt sich ins Wasser zu stürzen, um nach Nahrung zu fischen. Im Wasser lauern mögliche Gefahren (z.B. Fressfeinde) und warten nur auf den einen, den ersten Artgenossen, der sich trotzdem todesmutig ins Wasser stürzt. Sobald dieser Bann gebrochen ist, fühlen sich auch alle anderen Pinguine in der Lage, den potentiellen Gefahren zu trotzen und folgen dem Pionier, dem ersten Pinguin.
Randy Pausch*, Erfinder dieser Gratifikation und bekannt für seine unkonventionellen Wege und Ideen, wollte diese paradoxe Intervention bei seinen Studenten als eine Einladung verstanden wissen, Fehler auch oder vielmehr vor allem als Leistung anzuerkennen. Er wollte, dass sie auf diesem Wege ein in unserer Gesellschaft beharrlich akzeptiertes Muster unterbrechen und lernen: Fehler sind nichts Schlechtes! Sie sind das genaue Gegenteil. Es sind gerade die Misserfolge in unserem Tun, die von entscheidender Bedeutung sind und uns zu ungeahnten Leistungen zu bringen. Fehler verstärken in uns eine Fähigkeit, die mit keinem Erfolg zu erzielen ist: Erfahrung. Nach dem Verständnis von Pausch ist Erfahrung das, „was du bekommst, wenn du nicht bekommen hast, was du wolltest“ (a.a.O.). Was den First Penguin Award jedoch so außergewöhnlich macht, ist die offizielle Erlaubnis, angstfrei scheitern zu dürfen, den Misserfolg als integralen Bestandteil eines Lern-/ Entwicklungsprozesses willkommen zu heißen und sicher sein zu können, dass man für seine (Fehl-)Leistung Respekt und wertschätzende Anerkennung verdient hat.
So ungewöhnlich dieses Reframing des Misserfolgs aussieht, Pausch bietet mit seiner Intervention Zutaten für ein Rezept wirksamer Führung. Die erste Zutat ist Offenheit. Jedes Ergebnis war möglich, selbst ein Scheitern galt von Anfang an als legitime Option. Offenheit bedarf jedoch, wenn sie zu einer Investition werden soll, einer zweiten Zutat: Vertrauen. Pausch vertraute darauf, dass seine Studenten ihren Job nach bestem Wissen und Gewissen erledigen würden. Er vertraute darauf, dass seine Offenheit nicht ausgenutzt und zu einem Bumerang wurde. Vertrauen zu schenken heißt also, in Vorleistung zu gehen und bedeutet für den Vertrauensgeber erstmal ein Risiko. Für den, dem dieser Vorschuss gewährt wird, ist es, was ich als dritte Zutat wirksamer Führung identifiziere. Es ist die Wertschätzung. Sie signalisiert dem Empfänger, dass er auf Augenhöhe wahrgenommen wird. Offenheit, Vertrauen und Wertschätzung, drei Zutaten, die Führung sichtbar und wirksam machen. Aus neuropsychologischer Sicht kann man vor Pauschs Idee nur den Hut ziehen. Die biochemische Ladung, die der First Penguin Award versprüht, kann kaum größer sein. Wer die Gewissheit (Certainty**) hat, dass jedes Ergebnis ein gutes Ergebnis sein wird, agiert durchwegs im Reward-Modus und kann uneingeschränkt auf seine Ressourcen zugreifen.Vom Scheitern, besser Scheitern und Siegen
Dieser Tage gewann Stanislaw Wawrinka, Schweizer Tennisspieler, die Australian Open und damit sein erstes Grand Slam Turnier. Nach Roger Federer ist er damit der zweite männliche Schweizer, dem dies gelungen ist. Die wenigsten Fachleute hatten dem mittlerweile 28-Jährigen diesen Triumph noch zugetraut. Wawrinka, ein guter Tennisspieler, scheiterte stets, wenn auch oftmals knapp, an den Topspielern. Grund dafür waren nie seine spielerischen Fähigkeiten, sondern seine mentalen. Noch ein Jahr zuvor war Wawrinka nach einem denkwürdigen Match im Achtelfinale der Australian Open mehr als unglücklich ausgeschieden. Fast zwei Sätze lang dominierte er die damalige Nummer 1 Novak Djokovic nach Belieben und überrollte ihn mit seiner aggressiven Spielweise. Plötzlich schaltete sich jedoch (wie immer) Wawrinkas Kopf ein. Djokovoc dreht die Partie, gewann das Spiel und später auch das Turnier. Kurz nach dem verlorenen Match ließ sich der Schweizer tätowieren – seine ganz persönliche Kompensation der Niederlage. Ein Zitat des irischen Schriftstellers Samuel Beckett ziert seitdem den linken Unterarm: ”Ever tried. Ever failed. No matter. Try again. Fail again. Fail better.”
Ein Jahr später versuchte er es an gleicher Stelle wieder. Und er gewann auf eine beeindruckende Weise. Nach seinem Finalsieg gegen Rafael Nadal, der aktuellen Nummer 1 der Welt, durfte er sich nicht nur Australian Open Sieger 2014 nennen, sondern er wird als der erste Spieler in die Tennisgeschichte eingehen, der bei einem Grand Slam Turnier die Nummer 1, 2 und 3 besiegen konnte. Ein wesentlicher Erfolgsfaktor war sein neuer Trainer, den er ebenfalls ein Jahr zuvor verpflichtet hatte. Magnus Norman, ehemaliger schwedischer Weltklassespieler, gelang es, die Kräfte Wawrinkas zu bündeln und seine Dämonen, die Angst, Fehler zu machen, die Angst zu scheitern, zu besiegen. Norman führte Wawrinka mit seinem Konzept auf die Siegerstraße, indem er ihn mental stärkte und ihm zeigte, dass Scheitern oftmals ein notwendiger Schritt auf dem Weg zum Triumph ist. Führung ist das, was man daraus macht: “We cannot change the cards that we are dealt, just how we play the hand“ (Randy Pausch, 2007).
*) Randy Pausch, Jahrgang 1960, Professor an der Carnegie Mellon University (Pittsburgh), starb mit im Juli 2008 im Alter von nur 47 Jahren an Bauchspeicheldrüsenkrebs. Im September 2007 hielt er seine „Last Lecture“. Im Plenum saß Jeffrey Zaslow, Journalist des „Wall Street Journals“. Fasziniert von Pauschs Philosophien und Einstellungen veröffentlichte er die Rede des todkranken Professors und löste damit ein ungeahntes Medienecho aus. Bis heute haben mehr als sechs Millionen Menschen die Last Lecture von Randy Pausch auf YouTube gesehen.
**) siehe SCARF – Brain at work by David Rock
Pausch, R. & Zaslow, J. (2008). Last Lecture. Hodder & Stoughton.
Rock, D. (2011). Brain at work. Campus
- Randy Pausch | Alice – Learning programming
- Very good, I like it, but I know you can do it better. — Randy Pausch
- Führung in Scrum | Manager | Teil 4
In the 4th of my short series of short blog posts, I look at the antipattern of people claiming "We're following the Kanban process."...
Recently, we've seen a lot of activity in the marketplace focused on "scaling Agile." It seems after a decade or so, people have been willing to admit the "Scrum of Scrums" concept just wasn't cutting it. There is now sufficient evidence of large scale failed Agile transition initiatives to know that previous decade's hypothesis about delivering large scale Agile adoption hasn't worked. Now we have a new wave. IBM has DAD (Disciplined Agile Delivery) and Dean Leffingwell and Rally Software Development have SAFe (Scaled Agile Framework). Other tool vendors in the market are encouraging emergence of "me too" scaled Agile solutions.
However this simplification rarely addresses the needs of the total business. Here's a great article on the expansion of this simplification.
The Product Manager vs Product Owner by John Peltier
Those who’ve worked with us at Sprint.ly - as customers, colleagues, and partners - know that we’re committed to our craft. We enjoy pushing the envelope on UI/UX, development methodologies, and technology. At times, this has meant needing to pull in specialists who are working at the very edges of their field to help us deliver. This is how we met Sam Breed and the Quick Left team in Boulder, CO.
Sam is a core contributor to Backbone, which lays at the foundation of our frontend architecture. His contributions to our recent performance refactor have dramatically improved the responsiveness of our application. After completing this project, two things were clear to me:
Sam and the Quick Left team are consummate craftspeople. Delivering quality code and actionable advice took precedence over their bottom line.
I wanted to spend more time working with Sam and the Quick Left team.
Sadly, I couldn’t recruit Sam and he couldn’t recruit me. This mutually sad realization, coupled with Sam’s confession that Quick Left was keen to start building their own products, led me to invite Sam out for beers.
I had an ulterior motive, though, which was to propose that we combine Quick Left’s chocolate with Sprint.ly’s peanut butter. We were building a great product, which Quick Left and their clients used, and Quick Left had an enormous engineering team ready to be aimed at the treasure trove of products swirling through our collective brains.
When our CSO, Matthew Work, first heard the idea he said simply, “That’d work.” Matt’s background at Pivotal Labs running Pivotal Tracker gave him great context to see that this symbiotic relationship had real potential.
Today I’m enormously proud, and exceedingly humbled, to announce that this potential has been realized. Sprint.ly and Quick Left are now one. We will operate offices in San Francisco, Portland, and Boulder. Our mission is to deliver great products - our own and our service customers’ - using the very best technologies and development methodologies available.
Wow. I am excite. Much coding ahead.
P.S. You can read more about this awesome news, along with FAQs, on our homepage.
It is really, really hard to design getting started experience in a tool. We’ve had many iterations and improvements, but still are not happy with the current implementation. So we’ve started from scratch and want to improve the existing experience in Targetprocess.
It is always interesting to explore how other vendors solve similar problems. This post is a quick summary of getting started experience in 15 (mostly project management) tools.1. Salesforce
Salesforce shows you a Getting Started page with several videos. This is it. Videos are quite lengthy and you have to spend about 30 minutes on watching them. It is interesting that such a sophisticated tool like Salesforce solves getting started problem with videos only.2. Trello
Trello is a super-lightweight tool for project collaboration. It’s based on an idea to create many boards and manage them. First board is actually a getting started board where you will read about all the features. It cleverly has 3 columns: Basic, Intermediate and Advanced features. If you open all these cards and actually do what they say you have a good understanding of a tool and know how to use it. Great implementation.3. Asana
Asana is similar to Trello, but much more complex (I personally don’t like it). Getting started experience is more detailed as well. First, you see a short video that actually explains a little. Video is on a separate page and it’s hard to miss it. Then you have a 3-steps wizard to define your identity, invite team members and create a team. It is quite handy and well designed. Finally, you dive into the tool. UI is loaded with many buttons and panels. The only help you have is “Videos” section at the bottom. Still Asana has a style and looks modern.4. Plan.io
Plan.io meets you with a wizard that guides you through the system. I liked it initially, but in a minute I got frustrated with too many steps. Then it became really annoying. Huge texts in popovers are not welcome to read, so I skipped them and learnt a little. And “Something is still missing” message drove me nuts in the end.5. Clarizen
Clarizen is a feature-rich project management tool. Initial wizard is OK, but I have had some “Hmm…” moments during project type selection. Then you see another wizard that shows you a 6-min video and obvious navigation panel. The tool looks heavy, with many controls and screens. It doesn’t feel hard to grasp though.6. Basecamp
Basecamp is a famous light-weight coordination software. It’s very simple. First, you see a bright welcome message. There are similar bright messages in new areas you visit, which is good. Sample project describes real features in Basecamp, so you can explore UI and learn something about the tool at the same time. Interestingly, I like Trello’s implementation of this idea more. Not sure why.7. Wrike
Before you start, you have to lie about your phone number (I’ll never understand why this field is required). Then you see a several steps wizard. While some steps make sense, I don’t think that “Assign task via email” is so important to have here. It is not so clear how to complete this Welcome Quest, I had to think a bit to find out why some steps are still there. Also Skip link is hard to find. Maybe it is intentional, but such solution has its flaws. There are several areas on top and when you put the mouse over an area icon you see a popover with a video. Quite a clever idea, but the implementation is annoying. Maybe it is good to hide these videos at some point.8. 5pm
In this traditional project management tool you see just 2 help messages after login — and this is it. Minimal effort in getting started design. I am not convinced the tool is simple enough to handle the getting started experience that way.9. Moovia
You immediately see a news feed with product updates. Maybe it is better to show a feed with product usage tips. So there is no getting started design at all.10. Redbooth
The welcome message you see is irrelevant and too lengthy. Similarly to Trello, there is a ToDo list that describes the tool itself. Empty areas helps you to make a correct action, like add a Task. System shows you good tips in the right moments. I’d say getting started in Redbooth is well-designed and usability is great.11. TeamLab
TeamLab looks complex. Right after the registration you see a video and wait while your account is being created. Good use of waiting time! Then you start a project and see three(!) yellow messages right away: one about Android app, another about email activation and the last one is a getting started wizard. Too many for me. The wizard is very short with just four steps. The system gives prompts to some actions when you navigate to a new screen, which is very handy. Help is built-in, so you don’t navigate away when you want to learn something. Quite good.12. Yodiz
This is an agile project management software. It meets you with a video (too small) and a project setup wizard. UI is not stylish for sure — too many colors, various icons and overall impression is not great. Large bright buttons with actions in empty areas are good though. The tool was easy to grasp, but I’m a domain expert :)13. Jira
Jira’s getting started experience is similar to Salesforce — it is very basic. You have a dashboard component with Getting Started steps. Small wizards are nice. Service Desk area is different and shows you quite many popovers. I got lost with them, in fact.14. TeamPulse
This agile project management tool shows you a 6-step wizard that describes main UI areas. That is it.15. TargetProcess
Targetprocess is not an easy tool. It is really flexible and has a new UI-paradigm, so we wanted to show people how to use it properly. First, you select a process to start with. Then you see a 3-minute video that explains a concept and main ideas. Then you jump into a wizard. We put significant effort into the wizard and I should say it is the most clever implementation I’ve ever seen. But it seems the wizard is very long with too many actions and steps. We have stats here. Around 70% of people abandon the wizard after step 2. It means 70% of people learn nothing from it. And even the pulsating blue dot doesn’t help to grab their attention.Summary
Let’s summarize the most popular approaches to getting started. Most show a video and provide easy access to more videos about a product (Asana, Yodiz, Targetprocess). Several tools use the tool itself to design ToDo with getting started actions (Trello, Basecamp, Asana, RedBooth). Some tools have UI wizards (TeamPulse, Targetprocess, Clarizen). RedBooth tries to give guidance to users in a good way, I think. Nothing novel, for sure.
I personally think that a long wizard doesn’t work and most people just skip it. Also it is required to unblock as many paths as possible in user interactions. If a tool demands something at some point of time, there should be an obvious way to fulfil that demand. For example, if it’s not possible to add a user story without a project, there should be a clear way to add a new project right from the “Add user story” screen.
In The Mythical Man Month, Fred Brooks explains that while cost varies with the number of men and months, progress does not. “Hence the man-month as a unit for measuring the size of a job is a dangerous and deceptive myth. It implies that men and months are interchangeable. Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them… This is true of reaping wheat or picking cotton; it is not even approximately true of systems programming.” This gave rise to Brooks’ Law: Adding manpower to a late software project makes it later.
According to the Theory of Constraints, organizations are prevented from achieving more of their goal because of one or more constraints. The theory puts forth a process, the five focusing steps, for breaking the constraint. Breaking the constraint means to continuously improve the system such that the current constraint is protected or improved such that it is no longer a constraint. Then you should repeat the process for the next constraint.
Putting these two concepts together can help you understand both of them. That’s a good idea. What follows is a look at Brooks’ Law in terms of the five focusing steps from the Theory of Constraints.
Often when there is a late project, managers add people to help with the current phase of development and/or the later phases. Typically, a project is late in development or about to enter system testing when it is discovered that it will run late. But management adds more people without considering what is the actual constraint. Dev and QA might not be the constraint. Perhaps development is held up by a review process, a third party, or delayed UI specs. Thus, they violate the 1st Rule of the Theory of Constraints: Identify the Constraint.
When managers add more people to a late project, there is seldom any adjustment of the rules and regulations or overhead that is affecting the constraint. In fact, more status meetings are usually added. Also, they have those who are the constraint work to bring the new people up to speed. They increase the burden and have the constraint do more than just those things that only the constraint can do. Thus, they violate the 2nd Rule of the Theory of Constraints: Exploit the Constraint.
Typically accompanying adding people is schedule compression. It’s common, then, to hear “Since we’re behind schedule, NOBODY better be idle!” So, everybody finds some way to be, or at least look, busy. This adds more work into the project which invariably has some impact on the constraint; it adds more code for the constraint to test, or it ends up having a dependency on the constraint, or the constraint has to field questions or support those who need to use some output from the constraint. Instead, they should leave slack in non-bottleneck activities to handle unplanned work. Thus, late projects and the add-people mentality ignores the 3rd Rule of the Theory of Constraints: Subordinate Everything to the Constraint.
The 4th Rule of the Theory of Constraints is Elevate the Constraint. There are many ways to do this: add more people, provide training, improve tooling and automation, procure faster workstations, etc. All of these things impact the constraint directly, and negatively so in the short term. Adding people tends to reduce the capability, efficiency, capacity, and throughput of the constraint in the short term due to the learning curve, time spent teaching and orienting, and time spent setting up new workstations instead of producing. More importantly, Brooks warns of the burden of intercommunication. Adding people increases the coordination required. “The added effort of communicating may fully counteract the division of the original task… Adding more people then lengthens, not shortens, the schedule.”
Thus, adding people seems to be core to Elevating the Constraint, but goes directly against the premise of Brooks’ Law. But let’s look a little more closely. Adding people isn’t core to Elevating the Constraint; it’s just an option in some situations. The Theory of Constraints is broadly applicable across industries and types of work; Brooks is concerned with scheduling and deadlines, and with software development in particular. The danger is that those involved with a software development project are intuitively familiar with Elevating the Constraint but haven’t internalized the lessons of the Mythical Man Month. If you have run up against Brooks’ Law, then you haven’t really elevated the constraint. So even here these two concepts are compatible.
The limitation at the constraint may just happen to be the number of communication paths in the system. Too many paths may be slowing down production. There are likely rules or procedures put in place to accommodate having so many people: code reviews by certain people, approval steps, written-over-verbal communication, branch and merge strategy, etc. Adding people reinforces those rules. This brings us to the 5th Rule of the Theory of Constraints: repeat the process but Don’t Let Inertia Cause a Constraint. Goldratt: “We cannot overemphasize this warning. What usually happens is that within our organization, we derive from the existence of the current constraints many rules. Sometimes formally, many times just intuitively. When a constraint is broken, it appears that we don’t bother to go back and review those rules. As a result, our systems today are limited mainly by policy constraints.” As an example, consider our hiring practices. Adding people lessens the likelihood that the organization will look for generalizing specialists that will swarm a problem. Fewer people encourages swarming, whereas more people encourages specialization.
What do you think? How else might you relate The Mythical Man Month to the Theory of Constraints?
When it needed to scale the size of its delivery teams and improve its time-to-market, Telstra -- Australia’s leading provider of mobile devices, home phones, and broadband Internet -- jumped right into Agile. At a fundamental level, the Telstra story is about moving from Agile projects with just a few people to Agile programs with hundreds of people working on many different things.
Telstra started its Agile journey with five "wagile" teams, working on four projects in a mixed Agile/waterfall environment. It scaled up to 7 fully Agile teams, working on 24 concurrent projects under a single Agile Release Train, by applying Dean Leffingwell's Scaled Agile Framework® (SAFe.) SAFe gets a lot of attention in the Agile community, but at Telstra it became much more than a buzzword or strategy. SAFe helped this large telecommunications and mobile organisation transform its Enterprise Data Warehouse (EDW) practices and shape an Agile organizational culture -- all in a matter of months.
Telsta's results speak for themselves:
- Average delivery cycle time down from 12 month to 3 months
- 6x increase in delivery frequency
- 50% reduction in cost-to-deliver
- 95% decrease in product defects
- 100% of projects delivered on time and on budget
- Happy project sponsors
- Happy teams
Vor kurzem erläuterte ich den Umgang mit einem Product Backlog in einem skalierten Umfeld, das sich mitten in der Umstellung vom klassischem Projektvorgehen zur agilen Entwicklung befindet.
Das Product Backlog bezieht sich auf das Gesamtprodukt und ist auch dementsprechend priorisiert. Die Teams arbeiten somit an den Top-Prio-Einträgen des Backlogs und stellen diese fertig, bevor sie anfangen, neue Items zu bearbeiten. Dabei ist, und hier liegt die große Änderung zu vorher, die Anzahl der Items, die gleichzeitig bearbeitet werden “dürfen” begrenzt. So viel zur Theorie.
Jemand aus dem Teilnehmerkreis brachte dann den Einwand: “Wenn die Teams nur noch das nächste Item im Backlog bearbeiten “dürfen” hat das für mich aber nichts mehr mit PULL-Prinzip zu tun.”
Diese Äußerung machte mich im ersten Moment etwas verdutzt, da ich mich freute, dass wir nun endlich damit anfangen würden, dass sich jedes Team immer etwas von oben aus dem Backlog pullt.
Definiert man das PULL-Prinzip “inhaltlich” – also so, dass sich ein Team immer genau das aus dem gesamten Backlog zieht, was es am schnellsten, am liebsten oder am besten umsetzen kann, wenden wir uns tatsächlich davon ab. Denn es führt leider in der Regel genau zu dem altbekannten Anforderungsstau. Es gibt viele Anforderungen, die nur ein Team umsetzen kann, diese sind aber sehr wichtig für das Business. Andere Teams pullen sich diese für das Business wichtigen Items nicht, weil sie wissen, dass es ein anderes Team gibt, das mehr Skills in dem Bereich hat, es anstrengend ist, sich durch fremden Code zu wühlen oder weil die notwendige absichernde Testautomatisierung nicht vorhanden ist, die verhindern würde, dass etwas Schlimmes passiert.
Aus diesem Grund definiert man das PULL-Prinzip “zeitlich”. Das Team entscheidet, wann es so weit ist, sich ein nächstes Item zu ziehen – nicht aber unbedingt welches. Wohlwissend, dass man nicht immer gleich alle Skills für die Herausforderungen des nächsten Items zur Verfügung hat, gibt man den Teams die Zeit, die sie brauchen, um es fertig zu machen und im Gesamtprodukt zum Funktionieren zu bringen. Einer der Reize des Commitments ist genau das: nicht alles vorab zu können, aber es schaffen zu wollen und einen Weg ausfindig zu machen.
Damit will ich nicht sagen, dass es immer sinnvoll ist, dass alle Teams alles können und sich jedes Item ziehen müssen, das direkt an erster Stelle steht. Trotzdem plädiere ich dafür, an den für das Business aktuell wichtigsten Themen zu arbeiten – auch wenn’s mal etwas länger dauert.
Schnapp Dir nen Snickers und accept the challenge! Die ersten Male werden hart, aber das Durchbeißen lohnt sich.
Imagine entering a bazaar where all your questions are answered by experts with wide ranging perspective, beliefs and experiences.
Think of being transformed by the learnings, exchanges, debates and discussions.
This defines the Open Space experience.
If you’ve never been part of an Open Space, I’d like to invite you to break the ice at Agile Open Northwest from February 5th – 7th in Seattle, Washington.
Been around Open Space before? Then this event’s for you. You’ll fit right in amongst some of the sharpest and brightest minds from the Pacific Northwest. This year’s event, titled “Agile – Harder Than It Looks,” brings you face to face with some of the toughest challenges facing your teams and organizations.
Here are just a few of the questions that might be tossed, turned and flipped outside down over the course of the 3-day event:
- What is the difference between Lean, Scrum, XP and other agile approaches?
- What new technical challenges face agile professionals?
- What are the latest cutting-edge developments in the agile software development world?
- How do agile frameworks and methods co-exist with project management, process control and other governance structures?
VersionOne is a proud sponsor of this event; we are thrilled to once again support the passionate agile community of the Pacific Northwest.
The event is sold out (not a surprise!), but place your name on the wait list for a possible chance to score a ticket.
Thank you Agile Open Northwest for giving VersionOne a wonderful outlet to connect with the Agile community. Pacific Northwest Agile community: you are fortunate to have this opportunity again for 2014.
Don’t miss Agile Open Northwest.
Community Marketing Manager
The word MVP (minimum viable product” has spread like a virus and can definitely be seen as a meme. But like terms such as “energy” or “quantum physics”, people sometimes use the word without really understanding how Eric Ries explains it in Lean Startup. So, here is a quick test you can use the next time someone uses “MVP” or “Minimum Viable Product”
It’s getting all too common to walk into an organization that thinks they are doing Scrum, but isn’t seeing any real benefit from their efforts. They’ll think they’re doing Scrum because everyone attends a daily standup, they plan every two weeks, have someone called a Product Owner, and another called a ScrumMaster. They know the ceremonies. They know the roles. They know the artifacts. But something isn’t working.
The reason Scrum isn’t working for them is that it isn’t the daily standup, or the roles, or the artifacts that make Scrum work. It’s the shared understanding that comes from the backlog, the visibility that happens as a result of the artifacts, the accountability that comes from having complete cross-functional teams, and the ability to measure an increment of working tested backlog every couple of weeks so you know how you are progressing.
Good Scrum teams have all the artifacts, roles, and ceremonies… but so do many of the bad ones. So, let’s break it down a little and see what’s the difference between when Scrum works well and when Scrum goes bad.The Backlog
There are lot’s of ways to successfully create a product backlog. I’ve seen Product Owners create the backlog with the team, I’ve also seen them do it solo. I’ve seen teams make the backlog up every two weeks based on real-time customer feedback. I’ve had small teams of experts create well articulated roadmaps supported by a rolling three month, risk adjusted, and estimated set of user stories. All these approaches work.
I’ve personally coached teams to use the ‘As a user, I want a feature, so that I can get some business value formula’. I’ve also coached teams to use a short, high-level description of the need and that was enough. I’ve also worked with teams that have created such comprehensive user stories that they started looking like formal use cases than user stories. It all depends on what it takes for the team to understand what’s being asked of them.
And that really get’s to the heart of the issue with the backlog. The backlog has to be clear enough to the team that they can come out of the sprint planning meeting with a pretty darn good idea of what it takes to build the software. The two most common anti-patterns are when the stories are too large and ambiguous the team isn’t clear on what’s being asked, followed closely by a backlog full of technical tasks that the developers made up themselves.
Without shared understanding of where we are going, a Scrum team is going to fail.The Team
Teams come in all shapes and sizes. I’ve seen teams made up of 2 developers and a tester. I’ve seem teams made up of 5 developers and 5 testers. I’ve also seen… but do not recommend… teams made up of 20 developers, 5 testers, and some analysts. Some teams have everyone necessary to deliver a working tested increment of product, some teams have folks from outside they depend on, some have to coordinate with other teams.
The common guidance is that a Scrum team has to be organized around a feature or a product so that there can be end-to-end accountability for delivery of the user story. In large organizations that pattern will break and you’ll have to consider using component teams or capability teams and coordinate and integrate the output of these teams in a more complex delivery framework… definitely not something covered by Scrum.
What really matters… is that whatever you have the team assigned to build… whatever part of the product they are responsible for… the team has everything necessary to build a working tested increment every several weeks. The team is fundamentally an accountability structure. If the team does not have everything necessary to deliver a working tested increment of the their backlog… they cannot be held accountable and the whole thing will begin to erode.The Product Increment
This is probably the most important part of the Scrum process. If you are working on a team that can’t produce a working tested increment of the product at the end of the sprint… you really are not doing Scrum. That said, just like teams come in all shapes and sizes… product increments can come on lots of shapes and sizes. Not every Scrum team is delivering something to an end-user every two weeks.
Some teams are responsible for putting software into production each and every sprint… sometimes even more often. Some teams can’t release that fast and have to batch up sprint outcomes and ship at the end of a quarterly release. Some teams… some products… can’t even release to customers on quarterly boundaries and have to batch up several internal releases into a year release (think tax software and ERP systems).
What matters about the product increment is that you have a measurable chunk of product that allows you to unambiguously measure how much you’ve achieved against your goal. The increment shouldn’t have technical debt. It shouldn’t have defects. It shouldn’t be waiting on someone outside the team to do their part before it has value. Anything you defer to a later sprint creates a hidden indeterminate amount of work on the backside of the project.In Summary
Scrum is an easy process to do… but not so easy to do well. You can have Product Owners, ScrumMasters, daily stand up meetings, sprint planning, sprint reviews, and sprint retrospectives. You can have backlogs and burndown charts and still have no idea where you are going.
To do Scrum well you have to have shared understanding… you have to have a backlog that is broken into small chunks, can be understood by the team, and meets Bill Wake’s INVEST criteria. NOTE: Remember this when I start talking about scaling the backlog… the reason many backlogs suck is because they don’t meet the E criteria.
To do Scrum well, you have to have a team you can hold accountable. The team has to have everything necessary to produce a working tested increment of software. If they don’t, they should have very easy access to the people they need when they need them. If that’s not possible it is impossible to commit and hold themselves accountable for delivery.
To do Scrum well, you have to be able to actually produce a working tested increment of product every couple of weeks. Teams that can’t do this have no idea what they’ve built, how fast they are going, or how much work is piling up behind them for the end of the project. Teams that can’t do this, can’t get feedback to make sure what they are building is on the right track.
I’d suggest that if you have shared understanding, complete teams, and the ability to create a working tested increment of product every couple of weeks… you are probably doing okay. If you have that and all the roles, ceremonies, and artifacts of Scrum… you are probably a very disciplined Scrum team.
If you don’t have shared understanding, complete teams, and the ability to create a working tested increment of product every couple of weeks… then that’s the problem, and that’s what you’ve got to go get fixed.
Check out the previous post, Fundamentals of Agile Transformation.
Leading self-organized teams in a Scrum environment is usually handled by ScrumMasters, right?
Therefore most managers who want to run Scrum-teams never really get in touch with the dirt and mood of walking Scrum-Teams to the front – facing all the problems of product development endeavors.
While implementing Scrum in various organizations over the last ten years I have used more and more sophisticated ideas about the how-to of scrum. We know how to work with teams, we know the details of Meeting and the way we shall create all the necessary artefacts like Backlogs.
But one thing is sill lacking – although we know how to work with the teams, we still lack ideas how to help managers to see the benefits for them in using Scrum. And I believe we Scrum consultants are the root cause of this.
The current paradigm of managers and Scrum is: The managers are not used to work directly with their teams and they do not need to have the same skills as their teams. The ideologically framed mind that the boss shall neither be the ScrumMaster nor the Product Owner (which definitely has its merit) has created one very large issue: The experience of managers was separated from the world of their development teams and with this their feelings and their possibility to learn from the real world of Scrum teams.
If we change the view on this topic, i.e. if we understand that management is the face of an organization, then we Scrum Consultants and ScrumMasters need to give managers a chance to understand the way the new agile organisation works.
However, this will only happen if we allow managers to run their own Scrum-teams as ScrumMasters and as Product Owners.
But – whenever I started talking about this idea to managers they were puzzled and confused. Over the last couple of months there were only a few who were prepared to trying this approach and they made a wonderful experience: They strengthened their bonds to their team members.
Scrum is about bringing people together and and helping them to contribute to a shared vision. And as Bernd has shown in his recent post: If Marissa Mayer is “Creating teams who work together” why shouldn’t we enable managers to run Scrum not only as framework for organizational aspects but also as managers on the floor?
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]