Employers ask for elite performers, but they should be careful – they could get what they ask for… If they find an elite performer, do they have the elite organization required to match the new hire?
This isn't a rant about salaries, the skills of new graduates, or the trials of dealing with recruiters, although each of those is worth a post in itself. It's about the mathematics of providing your organization with the talent it needs at the time that it needs it.
We had just under an hour to eat lunch and complete the retrospective. Second, there are about 50 volunteers - allowing everyone to have a voice in such a short time frame would be a challenge.
The rules of a stand-up are simple. Every day the team should assemble for a maximum of 15 minutes so that they can assess progress towards the Sprint Goal, and self-organize in order to overcome any impediments. In this article we look at how to use the daily stand-up as a "health check" for gauging an agile team's well-being.
Everyone is talking about the Yahoo! memo ending work from home for employees. I am reminded of an article on Rands in Repose about telecommuting.
I think that codes of conduct should be positive definitions of expected behavior rather than a series of prohibitions. Here's the code of conduct I'll use for my next conference.
Finishing a project on time and under budget is the whole point of Agile, but the budget can put some tricky constraints on the process.
In this presentation from JAXConf 2012, ThoughtWorks software architect Neal Ford investigates agile architecture and design, specifically addressing how big up-front architecture and design fail because of the unknown unknowns of a project.
There are lots of teams in small companies and start-ups who are self-managing and self-directing. They manage themselves, they set product direction, and set company priorities. When I visit big, established companies, there’s almost always an assumption that teams need close supervision.
coalition: A temporary alliance of distinct parties, persons, or states for joint action. council:
A group elected or appointed as an advisory or legislative body.
A typical problem in Agile organizations is that most Scrum and Kanban boards look messy. And office management doesn’t like a messy office. Office managers like their offices neat and tidy, hip and trendy. They particularly don’t like tons of sticky notes whirling through the corridors.
A while back I talked to a CEO of a contract development shop. He wondered how Agile could help him with fixed price, fixed scope contracts to deliver software.
Long ago, when I was a young developer at an anonymous company, one of my managers was disappointed with my progress. “I know how long the work should take. If I was doing the work, it would be done by now,” he huffed at me. There is nothing more insulting to a programmer.
Let’s discuss three negative outcomes of overloading your pipeline: You lose focus by increased task switching, Managing the waiting queue costs a lot of time, and Big releases create big headaches.
While there’s been some talk and research about project management paradigms e.g. waterfall, Project Management 2.0, ALM, with the paradigm of agile prevailing at the moment, it looks like no one has spoken about the paradigm of project management tools.
A few years ago Corey Ladas wrote an article about an Agile approach he called “Scrumban”. As the name suggests, this is a variant of Scrum with certain Lean-Kanban characteristics. What he proposed was a graduation of Scrum teams to leaner and more pull-based ways of working than Scrum itself allows.
Frequently people ask me, “How can you be so productive?” The question seems a bit strange to me, because I often consider myself not productive at all!
Enterprise-wide agile transitioning is a hot topic. Agile methods aren't just for developers any more...managers are also trying to get on board with best practices. The question is: as the present custodians of the agile process, what can developers do to help coach the "suits", and what sort of things should they be teaching them?
In everyday colloquial usage of the words Requirements and Specifications are pretty interchangeable. In general teams, and Developers in particular, don’t differentiate. There are usually one or the other, or neither, and they are both about “what the software should do.”
Influence Maps is the module in a Temenos lab that allows you to reflect, visualize (map) and articulate your personal history, and share it with the group—as detailed and deep as you choose to. Like every Temenos module, Influence Maps works on its own, too.
Anytime you find yourself looking at a class's implementation to figure out how to use the class, you're not programming to the interface, you're programming through the interface to the implementation. If you're programming through the interface, encapsulation is broken, and once encapsulation starts to break down, abstraction won't be too far behind.
Temenos is also a philosophy and mindset. In brief, deep bonds and healing result from exploring each other’s personal history (how we became who we are) and visions (who we want to be). We use the conceptual model of a container to help us perceive and understand our relationship with ourself and others.
Sometimes, just when we are walking about and we feel everything is going smoothly, then the bottom drops out of the bucket, our world suddenly of positivity, in the situation, our lives, family and friends, takes a nose dive to the other side.
Companies believe that Developers will somehow comprehend what is needed from a simple statement. In the worst cases this is a condition I refer to as: “Requirements by Project Title”. Just because Developers understand the technology doesn’t mean they understand what is needed.
Agile product planning comprises three levels: vision, product strategy, and tactics. The vision is the overarching goal, the product strategy the path to the vision, and the tactics are the steps along the way, as the following diagram illustrates: