I find it helpful to consider three questions when choosing a sprint goal: Why do we carry out the sprint? How do we reach its goal? And how do we know that the goal has been met? My sprint goal template therefore consists of three main parts: the actual goal, the method employed to reach the goal, and the metrics to determine if the goal has been met.
I’m on a plane on my way back from The Joy of Coding.
This week I was approached by two individuals seeking advice on finding employment in a programming capacity.
I don’t estimate software defects. Well, I have two exceptions: If I have a backlog of old defects to burn down, I may estimate those. If I have found some new bug that we plan to fix in some later sprint, I may estimate those (though I really don’t like to defer defect fixes). Otherwise, I don’t estimate defects.
We need to trust our teams and respect their opinions. I like this approach since it’s a very good way of spotting leaders that you weren’t aware of. People with leadership potential are rare gems and I always stay open-minded to any method that can bring me the next great leader.
Like many developers, I’ve been protected from apparently difficult customers by my managers and left to get on with the important job of “writing code”. But this week I left our office and headed out to a technology park to work directly with one of our customers, and after a couple of days of understanding each others needs I’ve rarely felt so excited about “writing code”, because I know it will be valued.
This past Saturday was international women’s day (IWD). A day that should make us men in the software industry think about why so few women study CS and why so many of those who did, never establish a career in the industry. What do we men do wrong, when women don’t feel welcome?
Usually when people think about software development, they just have the typical nerds in mind, shy but smart, introvert people sitting in (often) dark rooms hammering down obscure instruction sets on their keyboards.
Pull is the driving force behind smooth and efficient agile practice. What is its nature though, and how can we harness it? In this article we explore where pull comes from and how it propagates. Can the strange magic behind it be explained in terms of scientific management?
When I was assigned as a CTO, I was very excited. I think it’s time for me to bring the joy and delight of coding. So I wrote my plan ahead and I have a commitment to apply the Joel Test.
If we choose conformance to actuals as the definition for the “rightness” or “goodness” of an estimate, we’re certainly encouraging overestimation. It’s easier to overestimate and then waste effort as needed to be “accurate” than to underestimate and try to hit a possibly impossible target. Those who ask for estimates using this definition know this, so they are likely to arbitrarily cut the estimate in order to put pressure on development and prevent padding.
Why shouldn’t you test private methods? Because the fact you’re asking the question means the method shouldn’t be private – it’s a piece of independent behaviour that warrants testing. The hard choice, the design decision, is where you stick it.
Let’s face it; not everyone has been there and done that, when it has come to Distributed Development. And if you have, there is a high probability that you were probably in a distributed team, you mostly worked with one group or the other, but not both. These words I will probably keep repeating in the future, but I’m not apologising for them: Never be Complacent.
This week in the link roundup: Intel joins the smartwatch arms race with a $100M purchase, Facebook looks to go into low-orbit, Flexcoin shuts its doors, PHP gets a renaissance, a programmer finally admits his limitations, we learn that God created the universe on Rails, and Jurassic Park comes to your browser.
A wise, retired CIO told me, “Don’t sell me your solution, solve my problem.” That statement further solidified my belief that I am not “implementing agile” (hang with me), but rather I am solving a problem or a set of problems that commonly occur in enterprise environments.
It’s very common for organizations to track the velocity of the Agile teams over time. This is quite a reasonable datapoint to plot. Combined with other data, it might give you some insights when you look back, and insights based on data are typically more useful than insights based on opinion. Remember, though, to keep in mind what the data is, and what it is not.
Applying Agile methods to an organization on an enterprise level can be difficult. In order to ensure product quality, minimal time-to-market and increased value, avoid these mistakes when embarking on this transformation.
The key challenges around compensation, at least for me, center around figuring out how to reward individual performance without encouraging internal competition, local optimization, or one person feeling rewarded while another feels punished. You want compensation to motivate people, not to have a negative impact on performance.
Agile software development is not about productivity; it’s about working well. Yes, I think there are potential gains in productivity for most teams. Even then, the bulk of the gains are from “maximizing the work not done” rather than becoming more efficient programmers.
Old crotchety principles sometimes surprise. The dependency inversion principle has long earned respect from programmers for its prowess at smashing the rigidity and fragility of otherwise un-lubricated systems.
I am continually amazed by the state of software development. I am amazed at how broken things seem to be, and I’m amazed at what powerful tools we have to fix things.
Intuition tells us that methods like these ones suffer from a distinct code smell.
Create and manage continuous improvements teams and communities within organization to fuel your agile initiatives.
In this article we look at how and why an agile team should gather elementary metrics, including lead time, throughput, velocity, and burn. We also look at cumulative flow, and briefly consider why the "actionable metrics" of the Lean Startup movement are so important to business.
When trying to hire developers, startups and small companies now find themselves in the unfortunate predicament of having to directly compete with the unlimited resources and mass appeal of market heavyweights like Google and Facebook.