Lesson: Pick one, two, or three up front
We also discovered that sometimes one week or three week iterations are better than two week iterations. We experimented with a three week iteration for the last iteration of the two month term. It made sense for one of the projects (to be released soon), but it definitely contributed to sloppiness and missing the deadline on another project. With more time it was easy to say “We’ll deal with that tomorrow” or “We can worry about that next week.” Turns out when you start saying that you’re often already in trouble. Without a looming deadline you can feel (you can feel the pressure two weeks a lot more than three weeks), scope creeps and things get pushed off. So we decided that next time around we’ll experiment with one week, two week, and three week iterations — but that call needs to be made up front. You can’t start with one week and turn it into two or three. A team will say “This is a one weeker” or “This is a two weeker” etc.
(Link: A New Way of Working: A Two-Month Recap – (37signals))
Uncategorized
management, programming
HIPPO #1 – Highest Paid Person in the Organization
* This informal description is basically… the boss. As you might guess, no one actually uses the term “HIPPO” on the job. It represents a concept that is unwritten, though: even if you cannot see the work that the HIPPO does, that’s the person who is ultimately responsible for everything that occurs at the workplace.
(Link: HIPPO Management: Highest Paid Person in the Organization)
Uncategorized
management, tweet
Mr. Catmull amplifies Mr. Sivers’ sentiment:
If you give a good idea to a mediocre group, they’ll screw it up. If you give a mediocre idea to a good group, they’ll fix it. Or they’ll throw it away and come up with something else.
(Link: Cultivate Teams, Not Ideas)
Uncategorized
management
Codebase is developed in Ruby, using the Rails framework for the web application. In addition to this we have also developed our own libraries which power two of the most important parts of the system. Tripod is a library which provides SCM-agnositic access to repositories allowing us to easily interface with Git, Mercurial or Subversion repositories using a unified API. SCAM is our “source control access manager” and it interfaces directly with the Codebase database to control access to all repositories – regardless of the SCM, your request for access will pass through SCAM. We’ll post some blog entries with more details about our actual infrastructure in the next few weeks.
(Link: Codebase – Subversion hosting with complete project management – tickets, milestones.)
Uncategorized
collaboration, hosting, management, scm, svn
Effective executives, finally, make effective decisions. They know that this is, above all, a matter of system – of the right steps in the right sequence. They know that an effective decision is always a judgement based on “dissenting opinions” rather than on “consensus on the facts”. And they know to make many decisions fast means to make the wrong decisions. What is needed are few, but fundamental decisions. What is needed is the right strategy rather than the razzle-dazzle tactics.
(Link: Drucker – on Effective Executives)
Uncategorized
management
* Element 1. Problem rationalization. The clear rationalization that the problem was generic and could only be solved through a decision that establishes a rule or a principle.
* Element 2. Boundary conditions. The definition of the specifications that the answer to the problem has to satisfy, that is, of the “boundary conditions.”
* Element 3. The right thing to do. This is the thinking through what is “right,” that is, the solution that will fully satisfy the specifications before attention is given to the compromises, adaptations, and concessions needed to make the decision acceptable.
* Element 4. Actions. The building into the decision of the action to carry it out.
* Element 5. Feedback. The “feedback” that tests the validity and effectiveness of the decision against the actual course of events.
(Link: Drucker’s – 5 Elements of an Effective Decision Making Process)
Uncategorized
management
UCD can be too documentation-heavy, isolated and risky but Agile needs help with defining requirements and concept development. How can Agile and user centric principles work together? First let’s understand what works well with Agile and not so well with user centered design. In this regard, the work that user centered design calls the ‘design’ phase can produce buckets of documentation which isn’t read, describing interfaces specified in isolation which may not be feasibly coded in the time allotted to them. So, doing detailed design is best done in conjunction with the development team and in a way where resulting interfaces can be tweaked as you go.
(Link: Bringing User Centered Design to the Agile Environment – Boxes and Arrows: The design behind the design)
Uncategorized
agileucd, management, methodology
His theory breaks job satisfaction into two factors:
* hygiene factors such as working conditions, quality of supervision, salary, safety, and company policies
* motivation factors such as achievement, recognition, responsibility, the work itself, personal growth, and advancement
(Link: Nine Things Developers Want More Than Money)
Uncategorized
management, programming
1. Be a developer
I can’t stress this one enough. Development isn’t something that can be appreciated, it has to be experienced. HTML and JavaScript don’t cut it, you have to go out and actually do what your programmers do. Write SQL statements, create classes, build an application. When you can follow along and contribute intelligently to all the technology discussions, developers will start to trust you that you understand them and what they have to deal with. And most importantly you can help them find solutions they may not see yet.
(Link: 12 Lessons Learned for Getting Better Results from Developers)
Uncategorized
management, programming
A key lesson Jigsaw has learnt however, is that when you empower team members with a certain level of responsibility they will often exceed your expectations and perform above and beyond.
If as a project manager you have trust issues with team members and feel uneasy delegating key tasks to them, but at the same time clearly have a packed work schedule building death traps, you could start by delegating lower risk tasks to test the water.
(Link: What Jigsaw Can teach Us About Project Management)
Uncategorized
humor, management, projectmanagement, tweet
Adding those 6 factors up, 72% of project failure reasons can be connected to PDI differential. If both sides understood that single factor going in to the process, everyone would be better served in the end. Think I’m just making this all up? It’s not just the buyers that complain. High PDI country providers say the same things.
So what’s so hard about outsourcing? It’s hard because of the cultural baggage we bring to the table on both sides, and neither side necessarily realizes it because of assumed interactions. We need to be more aware of the cultural assumptions going in to projects like this, or we’re doomed to repeat them ad absurdum.
(Link: The Real Reason Outsourcing Continues To Fail | Lessons of Failure)
Uncategorized
management, offshoring, outsourcing, pdi, tweet
The cost of overcommunication within organizations was fleshed out by Fred Brooks in his 1975 book, The Mythical Man-Month. Brooks helped run the OS/360 project at IBM, building a giant operating system for the company’s mainframes. In those days, computers were large, room-size, water-cooled machines, sometimes with a massive 256,000 bytes of main memory. OS/360 was probably the largest software project ever attempted to that point. And it was monumentally late.
Every time some aspect of the project fell behind schedule, IBM assigned a few more people to the task. And what Brooks noticed, which still surprises people, is that this didn’t work. His observation came to be known as Brooks’ Law: Adding people to a late project tends to make it run later still.
(Link: A Little Less Conversation – the cost of overcommunication)
Uncategorized
brookeslaw, management, Productivity
some questions that managers might want to discuss with developers in their performance review:
* What code that you wrote this year are you most proud of?
* What code that you wrote this year would you rewrite if you had the time?
* Did you work on anything this year that you felt was a waste of time?
* How was the release schedule? Did we release too often or not often enough?
* What skills got rusty this year that you want to get back to using?
(Link: rc3.org – Performance reviews for developers)
Uncategorized
management, performancereviews, tweet
Or in a 2005 study sponsored by Hewlett-Packard, the I.Q.s of workers who responded quickly to a constant barrage of e-mails fell 10 points, double the drop of someone under the influence of marijuana. “Fast isn’t turning us into Masters of the Universe,” Mr. Honoré explained to the New York Times. “It’s turning us into Cheech and Chong.”
(Link: Slow, free range, idle parents can increase IQ and happiness – blogs – *faircompanies)
Uncategorized
kids, management
Switch the spec process from push to pull. Start with a one-page spec, no more. Then, let the team ask questions of the product manager whenever they need clarification. In exchange, the team agrees to show each piece of working code to the product manager for his approval. They’ll find points of disagreement much faster, and resolve them in realtime. Plus, the team will get better and better at interpreting the concise specs that only have to be written once. (Eventually, they may abolish specs altogether)
(Link: Lessons Learned: The product manager’s lament)
Uncategorized
management, programming
