Instead of escalating wars between departments by driving them to ever more ambitious, local goals, we need to break down the wall between development and operations. Defining overarching goals which resonate for both departments creates an environment where DevOps collaboration may thrive.
Click to continue…
Agile developers know how to estimate story points for customer features. And while transferring this knowledge over to the project team can take a few sprints, it is speedily adopted and velocity becomes a focal point of the sprint planning games. But, if the all the project participants aren’t officially on the team, a growing gap will appear between where the team wants the project to go and where the other participants thinks it should go. Story points quickly become a source of frustration and conflict instead of helping to gel the project team.
Click to continue…
Click to continue…
It’s amazing. Talking to a bunch of fellow CTOs I heard a lot of them saying: “We introduced Scrum and it works really well” and “we’re too slow to bring new features to our customers”. This piqued my curiosity. Scrum is supposed to speed up feature delivery through short iterations. How can an organization claim to run Scrum successfully but not deliver customer value fast?
Click to continue…
You’ve most probably been there: To win that one ueber-important client, your friendly sales rep sells the farm and his grandmother (well actually he sells features, which he invents right in front of the client to make sure to get the deal, but the effect is nearly the same). And not only does he sell „the grand new feature in the sky“, but he even guarantees a delivery date – and all without speaking a word to the tech guys. Sweet, huh? He is a hero. He made that huge deal and everyone is patting his shoulder. Well, besides you probably. And everyone else who now has to deliver a completely bloated feature in a totally unrealistic time frame. And, of course, there’s absolutely no room for negotiations. In fact, you’re not even allowed to talk to the client to ask a question about his requirements because the sales guy doesn’t want to make a „bad impression“.
Click to continue…
Sad but true – it’s pretty rare for managers to hire the right people.
If there are too many candidates, effective filtering is critical. Too few candidates, and it’s hard to get applications at all, much less the right ones. I want to describe the top five errors you make when trying to hire the best people.
Click to continue…
If there are too many candidates, effective filtering is critical. Too few candidates, and it’s hard to get applications at all, much less the right ones. I want to describe the top five errors you make when trying to hire the best people.
Click to continue…
Imagine an ant working at the top of a mountain. Next to it, there’s a sluice of melt water running and, at that moment, the ant removes a tiny particle from the rock face. A few hundred molecules of water quickly seize upon the shortcut, and gravity takes care of the rest. The individual rivulets on the mountain’s face eventually run together in a small brook, jostling pebbles and twigs along its bubbly trough. Running ever downwards, doubling in speed and force, the stream now catches up rocks, branches and other streams join the flow. Almost effortlessly, a mighty river is born carving its way through the massive granite over millennia. The imprint upon the surrounding landscape is a culmination of billions of tiny actions – wind, rain fall, freezes and even one tiny ant.
Click to continue…
Click to continue…
Maybe you read it long ago, or it’s been on your “to read” list for years. Or maybe you’ve never heard of it: The book “Good to Great” by James C. Collins. It describes how companies move from being average to great and how they can fail to make the transition. So, what does all this have to do with agile?
Click to continue…
In Scrum, sprints are time-boxed delivery cycles that help keep the team focused on the goal. If you don’t know which goal I’m referring to, check out Dr. Eliyahu M. Goldratt’s novel “The Goal” (hint: I think it’s something about making money).
For web development, I run weekly sprints and this surprises a lot of people – “How can you get anything done in just one week?” Truth be told, if I could, I’d run shorten this to daily cycles, but then I think it wouldn’t be Scrum anymore (Kanban, anyone?).
You’d be amazed what you can accomplish in a week – even if it’s only to convince your team that you should try your damnedest to ship one meaningful feature every 5 days. I want to challenge the idea that longer sprints help you get more done.
Click to continue…
Sitting in unnecessary meetings sucks. You know what I’m talking about: A lot of people crammed into one room, half of whom have no business with the discussion. The other half are responsible for the topic, but didn’t bother preparing for the discussion. So why are all these people sitting together? Let’s examine this from an unusual angle…
Click to continue…
Click to continue…
Desktop application development is traditionally done in waterfall development mode. Specifications and requirements are gathered over a period of months before being unleashed upon a “pool” of developers for implementation. Development times run into thousands of man days after which a “beta” product is released to the QA team (or perhaps some very brave customers). After another thousand days of bugfixing, you slap a product version onto a shrink wrapped box, burn the CD-ROM and ship.
While it may be hard to believe, this is how the majority of software development has been done for almost half-a-century. The older the company, the better the chance they follow this exact release cycle. There are annual budget meetings to determine which departments and projects will gain the largest developer pools. It’s excruciating to watch these behemoths try to introduce agile into such an environment and I believe budgets are toxic to agile development!
Click to continue…
